Re: Comments (Part 3) on HTTP I-D Rev 05

OK, I managed to wade through all the nits...  Here are my
resolutions.
				- Jim


> From: "Adams, Glenn" <gadams@spyglass.com>
> Resent-From: Andy Norman <ange@hplb.hpl.hp.com>
> Date: Fri, 13 Nov 1998 22:40:29 GMT
> To: "'Getty, James'" <jg@pa.dec.com>,
>         "'Masinter, Larry'" <masinter@parc.xerox.com>
> Cc: "'WG - HTTP'" <http-wg@hplb.hpl.hp.com>
> Subject: Comments (Part 3) on HTTP I-D Rev 05
> -----
> Following is my third set of comments, covering sections 14.9.4 through
> 14.40. Part
> four will follow presently.
> 
> 102. Section 14.9.4, pg. 103, 3rd para., has an editors note "[jg418]"
> which should be removed.

I'll fix.  More Word droppings.

> 
> 103. Section 14.9.4, pg. 103, 4th para., would read more clearly if
> the last sentence were further elaborated, e.g., "The initial request
> (from user agent to first proxy) includes cache-validating
> conditional(s) in the request, based on the validator(s) of the local
> cached copy."

I don't think this improves things.  It implies a cache when there
may just be the one document.

> 
> 104. Section 14.9.4, pg. 103, 5th para., would read more clearly if
> the last sentence were further elaborated, e.g., "The initial request
> (from user agent to first proxy) does not include a cache-validating
> conditional; rather, the first caching proxy in the request path that
> holds a cache entry for this resource includes cache-validating
> conditional(s) in the request, based on the validator(s) of its cache
> entry."
> 

I don't think this improves things.  It implies a cache when there
may just be the one document.

> 105. Section 14.9.4, pg. 104, 2nd para., suggest changing "I.e., the
> cache MUST obey ..." to "The cache MUST obey ...". Imperatives
> shouldn't be stated as parenthetical explanations.

I can't find this one.

> 
> 106. Section 14.10, pg. 106, 1st para., suggest changing "MUST NOT be
> communicated by proxies over futher connections." to "MUST NOT be
> forwarded by proxies."

I think I like the current wording better, as it really applies
to the TCP connection...  But maybe I'm just getting tired.

> 
> 107. Section 14.10, pg. 106, 2nd para., the production used with
> Connection appears to be overly general as compared to the explanation
> in this section.  I would suggest rewriting as follows:
> 
> Connection = "Connection" ":" 1#connection-directive
> 
> connection-directive = "close" | field-name
> 
> While it is the case that both "close" and field-name can be expressed
> as token, the semantics implied by field-name corresponds better to
> the required usage, and, further, implies the additional semantics of
> section 14 regarding field names defined by this specification.
> 
> The above expression also does a better job of discriminating the
> special directive "close" from the other possible values for this
> field (i.e., field-names).
> 
> If I were designing this anew, I would have modeled this similarly to
> the expression used with the no-cache cache-response-directive:
> 
> connection-directive = "close " | "no-forward" "=" <"> 1#field-name <">
> 
> Any chance for revising this into a more consistent form?

No.  There were other tokens defined in previous drafts, and there
needs to be other tokens defined for connection management,
so leaving things as is with a open-ended token is the right
thing to do.

> 
> 108. Section 14.11, pg. 107, 1st para., has "MUST be" in relative
> clause "... and thus what decoding mechanisms MUST be ...".

yes, MUST shouldn't be capitalized

> 
> 109. Section 14.14, pg. 109, 2nd para., refers to "base URI". Is this
> concept defined in this specification? Perhaps a reference to another
> document defining this would be useful.
> 

See 3.2.1, where it is already cross referenced to the URI spec.

> 110. Section 14.14, pg. 109, 6th para., has "The meaning of the
> Content-Location header in PUT or POST requests is undefined; servers
> are free to ignore it in those cases." Suggest changing "servers are
> free to ignore" to "servers MAY ignore". Also, how about other methods
> such as DELETE, etc.
> 

We are silent on DELETE for good reason; it might be useful to
have a Content-Location on a DELETE, if the semantics were ever defined.
Same goes for PUT right now.

> 111. Section 14.15, pg. 110, 1st para., suggest changing "may
> generate" to "MAY generate".

Sure.

> 
> 112. Section 14.15, pg. 110, 1st para., has "Any recipient ... MAY
> check that the digest value ... matches ...". Is there a
> recommendation for the case where it does not match? Or is this
> implementation specific behavior?

It isn't implementation specific, it is up to the application. You remember 
these pesky applications that people build, don't you?  The reason for 
Content-MD5 is to get a strong end to end checksum of an entity.  Presumably 
the application had some need to get this integrity assurance; often this 
is not a browser.

> 
> 113. Section 14.15, pg. 110, it seems that the material discussing an
> extension to RFC 1864 (4th through 7th paragraphs) would best be moved
> to an appendix. I also found this material difficult to follow as
> presently worded.

Not going to be moved at this date.

Yes, MIME uglyness is rearing its ugly head again.  We spend lots
of time explaining how HTTP != MIME.  Sgih...

> 
> 114. Section 14.16, pg. 111, 1st para., suggest changing "It SHOULD
> indicate the total length ..." to "It SHOULD indicate by means of an
> 'instance-length' the total length ...". It may also read better if
> this is placed after the syntactical description of Content-Range;
> i.e., before the paragraph starting "The asterisk ...".

Yup.

> 
> 115. Section 14.16, pg. 111, 3rd para., suggest adding "(see section
> 14.35.1)" after "Unlike byte-range-specifier values ...".

Good suggestion.

> 116.

Handled in other mail.

> 117. Section 14.16, pg. 112, 2nd para., needs a space in "19.6.3for".

I'll fix.

> 
> 118. Section 14.18, pg. 113, 5th para., has "Clients SHOULD only send
> a Date header field in messages that include an entity body ..." which
> would read better as a prohibition: "Client SHOULD NOT send a Date
> header field in messages that do not include an entity body ...".

I prefer the positive statement.

> 
> 119. Section 14.20, pg. 114, would seem better to merge the last
> sentence of the 1st paragraph ("A server that does not ...") with the
> 2nd para.  ("The server MUST respond ..."), since they appear to
> duplicate the requirement about responding with an error status.
> 

OK.  Will do.

> 120. Section 14.20.1, pg. 115, appears to duplicate language from
> 8.2.4.

Yes, dealt with already in ROSS14.

> 
> 121. Section 14.21, pg. 116, 4th para.: suggest adding "(see section
> 14.9.3)" after "Note: if a response ...".

OK.

> 
> 122. Section 14.22, pg. 116, 1st para.: suggest removing parentheses
> around "as updated by RFC1123 [8]" to make it clear that this update
> isn't optional.
> 

OK.

> 123. Section 14.22, pg. 117, 2nd para., suggest changing "issuer's
> address" to "requester's address".

No; that would imply the system that made the request, and this is
specifically about allowing a different address.

> 
> 124. Section 14.22, pg. 117, 3rd para., has "SHOULD NOT" in a note.

OK. Fixed.

> 
> 125. Section 14.24, pg. 118, 6th para., suggest rewriting to not use
> "SHOULD" and "MUST NOT" in the context of defining a term "If-Match:"
> -- or use "SHOULD" and "MUST NOT" without placing in a definition.

No.  Not worth it.

> 
> 126. Section 14.24, pg. 118, last para., uses "MUST NOT" in a relative
> clause "to signal that ..."; suggest rewriting to make into an
> imperative related explicitly to server.

No.  Not worth it.

> 
> 127. Section 14.24, pg. 119, 1st para.: I find the fact that this
> situation is defined as undefined to be rather troubling. Can't a
> specific 4XX response (e.g., 400) be recommended instead? It has been
> stated that broken behavior should be strongly discouraged, rather
> than merely ignored or arbitrarily interpreted.
> 

We discussed this at length before, and decided leaving it undefined
was the right solution.  We can't define all outcomes of permutations
of headers in HTTP (a fundamental failing of HTTP is this mess of
headers that may or may not apply to a given method), and decided
that it was best in this case to make sure no one relied on the
behavior so that we would be able to define it in the future.

Someone (or you) can find this discussion in the mailing list archives.

> 128. Section 14.25, pg. 119, 1st para., should "an entity will not be
> returned from the server" be strengthened to "A server MUST NOT return
> an entity ..."?

I think it is written this way to allow servers that more or less
always blindly return an entity, and don't implement If-Modified-Since.
So it can't be normative.

> 
> 129. Section 14.25, pg. 119, 5th and 6th paras., starting "Note that
> the Range ..." and "Note that the If-Modified-Since ...",
> respectively, should be either indented at the same level as other
> paragraphs (e.g., see 1st para.  of pg. 120) or use standard "Note:
> ..." form.

Ok.

> 
> 130. Section 14.25, pg. 120, 1st para.: is this normative text, in
> which case "The client should ..." should be changed to "The client
> SHOULD ...", or informative text, in which case the standard "Note:
> ..." form should be used?

Informative.  I've indented the paragraph.

> 
> 131. Section 14.26, pg. 121, 3rd para., suggest rewriting to not use
> "MUST NOT" in the context of defining a term "If-None-Match:" -- or
> use "MUST NOT" without placing in a definition.

I can't get excited about this suggestion.

> 
> 132. Section 14.27, pg. 121, 1st para., suggest changing "it could use
> the Range ..." to "it MAY use the range ...".

No, this is a possibility, not a concrete situation.

> 
> 133. Section 14.27, pg. 122, 1st para., uses the term "sub-range
> operation".  This term doesn't seem to be well defined elsewhere in
> this specification.
> 

No, it is pretty well defined.  Remember, some implementations
may ask for a bunch of ranges at once (if they support multi-part).


> 134. Section 14.28, pg. 122, 1st para., why have "... the server
> SHOULD perform the requested operation as if the If-Unmodified-Since
> header were not present." while section 14.24, 2nd para., has "... the
> server MAY perform the requested method if the If-Match header field
> did not exist."? Suggest using consistent language in these sections
> "SHOULD/MAY", "operation/method", "were not present/did not exist".

Handled in separate message.

> 
> 135. Section 14.28, pg. 122, 2nd para., should note the asymmetry in
> response codes with respect to "If-Modified-Since" (section 14.25).
> Here we have 412 (Precondition Failed) while in 14.25 we have 304 (Not
> Modified). This asymmetry is odd since If-Match and If-Not-Match both
> use 412.
> 

Handled in separate message.

> 136. Section 14.29, pg. 123, 4th para., suggest removing "whenever
> feasible" since this weakens this as an unconditionally compliant
> requirement.
> 

Weakened deliberately for clock-less servers.

> 137. Section 14.35.2, pg. 127, 2nd para. has "origin servers and
> intermediate caches ought to support byte ranges when possible" seems
> to be a quasi-requirement but doesn't use standard keywords. Should
> this be "SHOULD support byte ranges" (recommended) or "MAY support
> byte ranges" (optional)?

No, we are making a recommendation here; we believe it is worth it
for most implementations to implement ranges, but can't require it.  Implying
that it is entirely optional by a bare MAY doesn't get the intent across.

> 
> 138. Section 14.35.2, pg. 127, 3rd para., 2nd bullet, has "It does not
> affect the 304 (Not Modified) response returned if the conditional is
> false." However, a 412 (Precondition Failed) response may apply as
> well.

Handled in separate message.

> 
> 139. Section 14.35.2, pg. 127, 5th para., suggest removing "," in "...
> in its cache, if that is ...".

OK.

> 
> 140. Section 14.36, pg. 127, rather than just using "[sic]" to excuse
> the misspelling "Referer", suggest adding a note indicating that this
> is a historical error maintained for compatibility sake.

Not worth the space.  In any case, this is an intellegence test,
to see if you know what [sic] means...

> 
> 141. Section 14.36, pg. 128, 3rd para., what does "partial URI" mean
> in "If the field value is a partial URI, it SHOULD be ..." Is this
> usage defined somewhere?

No, it should be "relative URI".

> 
> 142. Section 14.37, pg. 128, has "This field MAY also be used with any
> 3xx (Redirection) response to indicate the minimum time the user-agent
> is asked to wait before issuing the redirected request." Should there
> be a concurrent requirement placed on the user-agent (or client),
> e.g., "The user-agent SHOULD NOT issue a redirected request before
> ..."?

Hard to enforce, with impatient users at the drivers seat...  I can't
see that we can be stronger here; as a browser implementer, I don't
think you'd want to try to implement a SHOULD NOT in this case,
now would you?

> 
> 143. Section 14.39, pg. 129, 1st para., has "in section 3.9" which
> should read "in section 3.6".

OK. 

> 
> 144. Section 14.39, isn't t-codings syntactically ambiguous since:
> 
> transfer-extension     = token *( ";" parameter )
> parameter              = attribute "=" value
> 
> and
> 
> accept-params          = ";" "q" "=" qvalue *( accept-extension )
> 
> Perhaps it should read:
> 
> t-codings              = "trailers" | transfer-extension
> 
> and then add language indicating that accept parameters are included
> by means of the general transfer-extension parameter.

Don't think so, but I'm not the best BNF wizard on the crew.

> 
> 145. Section 14.39, pg. 129, 4th para., has "Therefore the keyword
> MUST be ...": what does "keyword" mean in this context? Shouldn't this
> read "connection-token" (or, as I suggested in my point 107,
> "field-name").

Keyword == "trailers" per the previous sentence.

> 
> 146. Section 14.39, pg. 129, 5th para., item 1, suggest changing to
> start "The presence of a TE header indicates that the "chunked"
> transfer- coding is acceptable."

Can't find this one.

> 
> 147. Section 14.39, pg. 130, item 3, if an implied "chunked" always
> gets qvalue of 1, then it will always win over lesser qvalues.
> Specifying "chunked;q=0" would permit overriding this default;
> however, the present syntax does not admit "chunked" (unless the
> syntax of t-codings is changed to:
> 
> t-codings = "trailers" | transfer-coding

Handled in separate message.

> 
> 148. Section 14.40, pg. 130, 2nd para, has "An HTTP/1.1 sender SHOULD
> ...": suggest changing to "An HTTP/1.1 message SHOULD include a
> Trailer header field if a chunked transfer-coding is used with a
> non-empty trailer."

OK.

> 
> 149. Section 14.40, pg. 130, 4th para., has "A server MUST NOT include
> any header fields unless ...". I believe this should read "A server
> MUST NOT include any header fields in the trailer of a message unless
> ...".

Handled in separate message.

> 
> 150. Section 14.40 uses language that implies "Trailer" is only used
> in response messages; however, Trailer is specified in section 4.5 as
> a general header field. Under what circumstance(s) would Trailer be
> used in a request message? Should the language of 14.40 take this into
> account?

You might use it in a PUT, for example, to add a signature.  It is correct
as is.

Received on Tuesday, 17 November 1998 18:41:02 UTC