Change:
the request SHALL include an "Upgrade" header field with value "connect-udp". <ins> A UDP proxying request that does not conform to these restrictions is malformed.  The recipient of such a malformed request MUST respond with an error, and SHOULD use the 400 (Bad Request) status code. </ins> For example, if the client is configured with URI Template "https://proxy.example.org/.well-known/masque/ udp/{target_host}/{target_port}/" and wishes to open a UDP proxying

Discussion:
This PR addresses the DISCUSS component of . The COMMENT component of that review will be addressed in a subsequent PR.
LGTMNice catch, thanks Zahed Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-masque-connect-udp-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL DISCUSS: This is I think simply a oversight but I am putting a discuss so that this certainly gets addressed before the document proceeds to the next stage. Section 3.2 does not say what happens when the requirements are not met. There must be guidance on what to do in that case like there are in section 3.3, 3.4 an 3.5. COMMENT: Thanks a lot for working on this specification. I think this specification will be very useful. I don't have other major issues other than mentioned in the discuss points. Below are some comments which I believe will improve the document if addressed. Section 3: s/pct-encoding/percent-encoding and would be good to add a reference to pct-encoding (URL) Section 3.1: it took a bit of time for me to understand if we are redefining the "intermediaries" here again. We have already described what is an intermediary in the context of this document. Hence, I would suggest that we just write - if the recipient is an intermediary, it forwards .... Section 3.1: what exactly "fail the request" means? is it only a notification to some waiting processes/methods or sending the error message or both? can we be more specific here? Section 5 : reference to the QUIC DATAGRAM frame would be nicer.Section 5 : it says - "Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527 using Context ID zero. An endpoint that receives a DATAGRAM capsule using Context ID zero whose Payload field is longer than 65527 MUST abort the stream. "

I assume the HTTP Datagram and a DATAGRAM capsule is referring to the same thing, but this is confusing. Can use HTTP DATAGRAM in the second sentence as well? The DATAGRAM capsule kind of appeared in this section all on a sudden. In this section to me it seems HTTP DATAGRAM and DATAGRAM capsule is interchangeably used, if I am correct then I think it is worth mentioning this for the sake of better understanding. Section 5 : it says "If a UDP proxy knows it can only send out UDP packets of a certain length due to its underlying link MTU, it SHOULD discard incoming DATAGRAM capsules using Context ID zero whose Payload field is longer than that limit without buffering the capsule contents." It is not clear why "SHOULD" is used here? what are the other option the UDP proxy has in this case? Section 3.6: if this section should be removed then [STRUCT-FIELD] must not be in the normative section, actually should be removed from the references. Either at this stage of this document we can remove this section or we can add a note to remove normative reference when this section is removed.