Additional text for stop sending variants.

[huitema]

Addresses Martin Duke second ballot comment (Issue #153).
Addresses Robert Wilton's Stop Sending and DOQ_NO_ERROR comments (issue #150)

[saradickinson]

Just a re-wording suggestion to make the conditions clearer?

Suggested change

	request from the client before the client indicates the STREAM FIN. If the
	server has not yet sent the response and indicated the STREAM FIN in the response
	stream or already sent a RESET_STREAM, the server MUST issue a RESET_STREAM to
	indicate that the transaction is abandoned.
	request from the client before the client indicates the STREAM FIN. The server MUST
	issue a RESET_STREAM to indicate that the transaction is abandoned unless
	* it has already done so for another reason or
	* it has already both sent the response and indicated the STREAM FIN.

[saradickinson]

New error code and text on RESET look good - thanks.

We now have clear text on what the servers should do with the DNS transaction after getting a RESET, but Robert's query was to clarify what servers should so with the DNS transaction after receiving a STOP_SENDING. I was going to suggest using exactly the same text for the 2 scenarios but your comments about STOP_SENDING being indicative made me pause, so there is currently just a 'SHOULD NOT continue to process' suggestion. I'd like to align these two scenarios better if we can?

[huitema]

Yes, SHOULD NOT makes sense. The server side is not enforceable by the client. It may also not be realistic. By the time the server starts sending, the look up of cache, authoritative, etc., has already been done. Except in the zone transfer case, of course.