More comments on the HTTP/1.1 draft

35.  Section 16.5.1, first sentence: replace "use" with "using".


36.  Section 17.5, last paragraph, 2nd sentence: replace "server of proxy" with
"server or proxy".


37.  Section 18.16.  The second sentence suggests that a server should *not*
provide a Content-Location header in response to a GET on a generic resource
when the returned entity does *not* correspond to "a specific, non-negotiated
location that which can be accessed with the Content-Location URI".  But this
condition is not mutually exclusive with the condition of the third sentence,
which *does* recommend returning a Content-Location header.  I suspect the
resolution is something on the order of "content providers shouldn't cause both
conditions to obtain in the same instance".  Also, the "which" in the second
sentence should be a "that".


38.  Section 18.18.2, last sentence asserts that entity shrinkage invalidates
byte-range-specs.  Section 7.14.2's criterion for byte-range-spec invalidity
(the last-byte-pos is less than the first-byte-pos) is independent of the
actual entity length.


39.  Section 18.18.2, last paragraph.  Note that a Range header can include
multiple byte-range-specs.  If some of them are invalid, are only they ignored
or the whole header?  If multiple Range headers are present, does invalidity in
one cause them all to be ignored?


40.  Section 18.20, last sentence says a receiver need only accept RFC1123
format dates; section 7.3 says a receiver should accept three different
formats.  Same issue also appears in third paragraph of 18.22.


41.  Section 18.33.  Why does the displayed syntax accept an empty list of
pers-param, given that the following text requires a non-empty set of
parameters?


42.  Section 18.37 says methods defined in 9.1.1 should not be explicitly
mentioned.  But the displayed example mentions "OPTIONS", which is defined in
9.1.1.


43.  Section 18.46, first sentence has mismatched parentheses.


That's all folks.

Mike

Received on Friday, 17 May 1996 23:20:40 UTC