Draft: draft-ietf-masque-connect-udp

Commentary: : police_officer :
Unlike TCP, UDP is connection-less.  The proxy that opens the UDP
socket has no way of knowing whether the destination is reachable.
Therefore it needs to respond to the request without waiting for a
packet from the target.  However, if the target_host is a DNS name,
the proxy MUST perform DNS resolution before replying to the HTTP
request.  If DNS resolution fails, the proxy MUST fail the request
and SHOULD send details using the Proxy-Status header PROXY-STATUS.
Unlike TCP, UDP is connection-less.  The proxy that opens the UDP
socket has no way of knowing whether the destination is reachable.
Therefore it needs to respond to the request without waiting for a
packet from the target.  However, if the target_host is a DNS name,
the proxy MUST perform DNS resolution before replying to the HTTP
request.  If DNS resolution fails, the proxy MUST fail the request
and SHOULD send details using the Proxy-Status header field PROXY-
STATUS.
the request SHALL include a single Host header containing the
origin of the proxy.
the request SHALL include a single "Connection" header with value
"Upgrade".
the request SHALL include a single "Upgrade" header with value
"connect-udp".
the request SHALL include a single Host header field containing
the origin of the proxy.
the request SHALL include a single "Connection" header field with
value "Upgrade".
the request SHALL include a single "Upgrade" header field with
value "connect-udp".
the reponse SHALL include a single "Connection" header with value
"Upgrade".
the response SHALL include a single "Upgrade" header with value
"connect-udp".
the reponse SHALL include a single "Connection" header field with
value "Upgrade".
the response SHALL include a single "Upgrade" header field with
value "connect-udp".
In order to allow implementations to support multiple draft versions
of this specification during its development, we introduce the
"connect-udp-version" header.  When sent by the client, it contains a
list of draft numbers supported by the client (e.g., "connect-udp-
version: 0, 2").  When sent by the proxy, it contains a single draft
number selected by the proxy from the list provided by the client
(e.g., "connect-udp-version: 2").  Sending this header is RECOMMENDED
but not required.  The "connect-udp-version" header field is a List
Structured Field, see STRUCT-FIELD.  Each list member MUST be an
Integer.
In order to allow implementations to support multiple draft versions
of this specification during its development, we introduce the
"connect-udp-version" header field.  When sent by the client, it
contains a list of draft numbers supported by the client (e.g.,
"connect-udp-version: 0, 2").  When sent by the proxy, it contains a
single draft number selected by the proxy from the list provided by
the client (e.g., "connect-udp-version: 2").  Sending this header
field is RECOMMENDED but not required.  The "connect-udp-version"
header field is a List Structured Field, see STRUCT-FIELD.  Each list
member MUST be an Integer.
Registration is the action by which an endpoint informs its peer of
the semantics and format of a given context ID.  This document does
not define how registration occurs.  Future extensions MAY use HTTP
headers or capsules to register contexts.  Depending on the method
being used, it is possible for datagrams to be received with Context
IDs which have not yet been registered, for instance due to
reordering of the datagram and the registration packets during
transmission.
Registration is the action by which an endpoint informs its peer of
the semantics and format of a given context ID.  This document does
not define how registration occurs.  Future extensions MAY use HTTP
header fields or capsules to register contexts.  Depending on the
method being used, it is possible for datagrams to be received with
Context IDs which have not yet been registered, for instance due to
reordering of the datagram and the registration packets during
transmission.