WGLC: p2 MUSTs

Hello,

    These comments are based on the "latest" snapshot dated Tue 30 Apr
2013 07:24:09 AM MDT at
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html

I hope these comments can be addressed by editors alone, but I apologize
in advance if some are found too controversial and should have been sent
separately.

> The CONNECT method requests that the recipient establish a tunnel to
> the destination origin server [...], until the connection is closed.

The "until the connection is closed" part is misleading and inaccurate.

There are two connections in a CONNECT tunnel: (a) between a CONNECT
sender and CONNECT recipient and (2) between CONNECT recipient the the
next HTTP hop. The tunnel termination condition is rather complex and is
detailed later in the same section. It may be a good idea to drop the
"until..." part. At least I cannot suggest a way to describe it
correctly as an ending of an already long sentence :-).


> When a tunnel intermediary detects that either side has closed its
> connection, any outstanding data that came from that side will first
> be sent to the other side and then the intermediary will close both
> connections. If there is outstanding data left undelivered, that data
> will be discarded.

These "will"s should be rephrased as intermediary MUSTs IMO. I also
suggest moving them higher, before the informal risk discussion.


> A client MUST NOT send header fields in a TRACE request containing
> sensitive data

The above rule seems too onerous to proxies. Replace "MUST NOT send"
with "MUST NOT generate"?


> 5.1.1.1 Use of the 100 (Continue) Status
> Requirements for HTTP/1.1 clients:
...
> Requirements for HTTP/1.1 proxies:

Should we explicitly exclude proxies from the first group of
requirements by saying "Requirements for user agents" instead of
"Requirements for clients"?


> MUST contain an updated Max-Forwards field with a value decremented by one (1).

A lot of proxies violate this MUST because they cannot grok and, hence,
cannot decrement large integer values. Interoperability problems might
happen when a client generates Max-Forwards with a maximum value it can
store (e.g., to count the number of hops to the origin server) but the
proxy cannot store such a large value (e.g., 64bit vs 32bit).

Perhaps we can relax this rule by allowing proxies to decrement by "at
least one", so that a huge value can be replaced with the maximum value
the proxy can represent?


> A client MUST be prepared to accept one or more 1xx

Drop "be prepared" to demand acceptance rather than preparedness?


> Proxies MUST forward 1xx responses, unless the connection between the
> proxy and its client has been closed,

This "unless" clause should be dropped as implied. Otherwise, we would
have to add it to every "MUST forward" requirement! :-)


> A sender MUST generate the IMF-fixdate format when sending an
> HTTP-date value in a header field.

Please polish to remove the implication that proxies must fix dates when
forwarding HTTP-date values. For example: "A sender MUST use the
IMF-fixdate format when generating a header field containing an
HTTP-date value".

Or perhaps simply: "A sender MUST generate HTTP-date values in the
IMF-fixdate format".



And here is a list of requirements that are missing an explicit actor on
which the requirement is placed. Most of these should be easy to
rephrase to place the requirement on the intended actor (e.g., "A proxy
MUST" instead of "header field MUST":

> the content codings MUST be listed in the order in which they were applied

> then the resource MUST disable or disallow that action

> The Expect header field MUST be forwarded

> the forwarded message MUST contain an updated Max-Forwards field

> The Max-Forwards header field MAY be ignored for all other request methods. 

> a response with an unrecognized status code MUST NOT be cached. 

Please be careful with "send" and "generate" when fixing the above
actorless rules so that the proxies do not accidentally become
responsible for policing traffic where unnecessary.


Thank you,

Alex.

Received on Tuesday, 30 April 2013 20:46:35 UTC