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

> From: "Adams, Glenn" <gadams@spyglass.com>
> Date: Mon, 2 Nov 1998 19:42:17 -0600
> To: "'Masinter, Larry'" <masinter@parc.xeroc.com>,
>         "'Getty, James'"
>          <jg@pa.dec.com>
> Cc: "'WG - HTTP'" <http-wg@hplb.hpl.hp.com>
> Subject: Comments (Part 2) on HTTP I-D Rev 05
> -----
> Alternative 1 --
>   This text
> 
> Following is my second set of comments, covering sections 12 through
> 14.9.3. Part
> three will follow presently.
> 
> 52. Section 12 uses the phrase "agent-driven negotiation"; suggest
> adding a note explaining that "agent" refers to "user agent".

It isn't necessarily a user agent.

> 
> 53. Section 12.2, pg. 68, 1st para., has "(this specification reserves
> the field-name Alternates)", however this field name is not described
> in section 14 as a reserved field name nor otherwise elaborated
> elsewhere in this specification.

Yes, this is left to the content negotiation people to define.
It is inappropriate to do more than reserve it, so that others
don't usurp the header name.  It should be "header-name" however.

> 
> 54. Throughout the whole of section 13 it is often unclear as to
> whether a requirement or statement is meant to apply only to a proxy
> cache, to a user agent cache, or to both. For example, in 13.1.1, the
> 6th paragraph has "If the cache can not [sic] communicate with the
> origin server ..." which appears to apply to either a proxy or a user
> agent cache. On the other hand, the 7th paragraph has "If a cache
> receives a response (...) that it would normally forward to the
> requesting client ..." which appears to apply to a proxy cache only.
> Suggest editing the entirety of section 13 to clarify applicability to
> these different caches.

"cache" is the general term.  There can be client or proxy caches,
and if it applies to both, the general term is used.  Saying
"proxy and client cache" all the time would just get confusing,
verbose and painful.  

We also don't want to get caught up in terminological problems that can 
occur if a proxy is on the client system.  Web caching systems also often 
get implemented as pretty separate parts of browsers, rather than all 
entangled, and so such requirements can apply to client caches (or caches 
on clients) as well, to illustrate the slippery slope, potentially.

If you want to point out particular places you think there are problems,
we can go into things further, but I'm not going to entertain 
"editing the entirety of section 13" at this late date.

> 
> 55. Section 13, pg. 69, 3rd para., has "the protocol requires that
> transparency be relaxed ... only ... only ..."; suggest changing to use
> the keyword phrase "MUST NOT relax transparency unless" to make clear
> the requirement.
> 
> 56. Section 13.1.1, pg. 70, 1st para., has "A correct cache MUST
> respond with the most up-to-date response ..."; since caching is always
> optional, this would read better as "A cache MUST NOT respond with a
> response held by the cache that is appropriate to the request (...)
> unless it meets one of the following conditions:".
> 
> 57. Section 13.1.1, pg. 70, numbered item (3) implies that 4XX and 5XX
> responses are cachable. While this is true for 410, under what
> circumstances should any 5XX response be cached?
> 
> 58. Section 13.1.2, 4th para., has "whether the Warning MUST or MUST
> NOT be deleted ..." which does not state a requirement per se: use
> "is or is not to be deleted ...".
> 
> 59. Section 13.1.2, 5th para., has "Warnings in responses that are
> passed to HTTP/1.0 caches carry an extra warning-date field, which
> prevents a future HTTP/1.1 recipient from believing an erroneously
> cached Warning."  I can't interpret this statement based on information
> in this section.  Please explain it further and state as a requirement
> if indeed it is a requirement.
> 
> 60. Section 13.1.2, 7th para., has "a server might provide the same
> warning with texts in both English and Basque". How would a UA
> discrimitate among different warnings using different languages unless
> the language were explicitly marked? Unfortunately, RFC2047 does not
> address this issue. I'd suggest permitting the extensions specified by
> RFC2231 (which updates RFC2047) to be used to provide explicit language
> tagging of quoted strings.
> 
> 61. Section 13.1.3, 2nd para., has "if there is any apparent conflict
> between header values, the most restrictive interpretation is applied
> ...".  Change "is applied" to "MUST" or "SHOULD" "be applied".
> 
> 62. Section 13.1.4, 1st para., change "the user agent might allow ..."
> to "the user agent MAY allow ...".
> 
> 63. Section 13.1.4, 2nd para., has "the user agent SHOULD explicitly
> indicate to the user ..." while section 13.1.5, 1st para., has "This
> allows the client software to alert the user". This later statement
> appears to make the indication/alert optional rather than recommended
> as implied by the former.
> 
> 64. Section 13.2.3, 3rd para., has "HTTP/1.1 requires origin servers to
> send a Date header, if possible, with every response ..." seems to be
> stating a conditional imperative. Rather than paraphrasing section
> 14.18 and possibly confusing the requirements regarding Date header
> transmission, I'd suggest rephrasing this to simply refer to a Date
> header, if present, and to state what must be done in the case that a
> Date header is not present.
> 
> 65. Section 13.2.3, pg. 76, 1st para. after pseudo code block, has "the
> server MUST"; suggest changing to "the proxy server MUST".
> 
> 66. Section 13.3, pg. 78, 1st para., suggest changing "it first has to
> check" with "it will normally check" to make this read more as a
> statement of fact than a requirement.
> 
> 67. Section 13.3.3, pg. 81, next to last paragraph, has "A cache or
> origin server ...". Change to "A caching proxy or origin server ...".
> 
> 68. Section 13.3.4, pg. 83, 2nd para., starts "A note on rationale:
> ..."  Suggest changing this to a standard note form, i.e., use "Note:"
> prefix with indented block paragraph.
> 
> 69. Section 13.4, pg. 83, 2nd para., starts "Note that ...". Suggest
> changing this to a standard note form, i.e., use "Note:" prefix with
> indented block paragraph. Further, this note has "some HTTP/1.0 caches
> are known to violate this expectation without providing any Warning."
> What warning should be provided in this case?
> 
> 70. Section 13.4, pg. 83, 3rd para., has "so that the server can
> indicate that certain resource entities, or portions thereof, MUST NOT
> be cached ..." which does not appear to state a specific requirement
> per se. Suggest changing to "... are not to be cached ...".
> 
> 71. Section 13.4, pg. 84, 1st para., starts "Note that ...". Suggest
> changing this to a standard note form.
> 
> 72. Section 13.4, pg. 84, 3rd para.: suggest giving status codes 302
> and 307 as examples of responses which are not cachable by default but
> which may be explicitly marked as cachable by using Expires or the
> "public" cache-control directive.
> 
> 73. Section 13.5, 1st para., remove comma in "to requests, for use ...".
> 
> 74. Section 13.5.1, pg. 84, 1st para, 1st bullet, has "End-to-end
> headers which MUST be ...". The use of MUST and SHOULD keywords in
> relative clauses is problematic and should be avoided since it does not
> state a requirement per se. Most such instances can be replaced by some
> form of "is" to express simple fact; e.g., "End-to-end headers which
> are ...".
> 
> 75. Section 13.5.1, pg. 84, 4th para., has "Hop-by-hop headers
> introduced in future versions of HTTP MUST be listed in a Connection
> header ..."  stipulates a requirement on the authors and/or
> implementors of future versions of HTTP, and not on implementors of
> HTTP/1.1. Suggest rephrasing this appropriately.
> 
> 76. Section 13.5.2, pg. 85, 4th para., has " ... of the following
> fields in message that ..." which needs an article "a" before "message".
> 
> 77. Section 13.5.2, pg. 85, 5th para., has "if not already present, it
> MUST add a Warning 214 (...) if one does not already appear ..." which
> uses redundant language about "already present"/"already appear[ing]".
> 
> 78. Section 13.5.3, pg. 86, 5th para., has "all such old headers are
> replaced." which sounds like a requirement: "... MUST be replaced."
> 
> 79. Section 13.6, pg. 87, 3rd para., has "When the cache receives a
> subsequent request whose Request-URI specifies one or more cache
> entries including a Vary header field, ...". Suggest changing "one or
> more cache entries including a Vary header field" to "one or more cache
> entries of previous responses which contained a Vary header field".
> Further, it appears that this paragraph implies a caching proxy
> context, but it is not clear that this would not also apply to a user
> agent cache. The next paragraph (end of pg. 87 and beginning of pg. 88)
> appears to be framed as applying only to a proxy. Again it isn't clear
> that this does not apply to a UA cache.
> 
> 80. Section 13.8, pg. 88, 1st para., implies the context of a caching
> proxy, requiring a 206 response when forwarding a partial response. In
> the case of a user agent cache that receives and wishes to use a
> partial response, it would seem that a Warning should be added by the
> UA cache to the response it generatese for internal UA consumption.
> However, there appears to be no Warning code that would serve this
> purpose.
> 
> 81. Section 13.11, 1st para., has "All methods that might be expected
> to cause modifications to the origin server's resources MUST be written
> through to the origin server. This currently includes all methods
> except for GET and HEAD." It would be better here to specify the
> methods that must be written through explicitly: PUT and DELETE. It
> isn't clear that OPTIONS, POST, or TRACE fall in this category; and
> then there's CONNECT, which doesn't fit into either of the above
> groups of methods.
> 
> 82. Section 14, pg. 91: suggest adding a sentence to each header
> defined by this section that states whether the header is end-to-end or
> hop-by-hop and whether the header is cachable by default, cachable by
> explicit cache directive, or never cachable.
> 
> 83. Section 14.1, pg. 92, 6th para., has "the most specific reference
> has precedence"; suggest using "SHOULD" or "MUST" "take precedence".
> 
> 84. Section 14.2, pg. 93, 3rd para., is quite confusing: suggest
> rewriting without using the term "mentioned". Also, this para. seems to
> be stating that if any "iso-8859-1;q=1" is always implied unless
> otherwise explicitly present. This means that:
> 
>     Accept-Charset: iso-8859-5, unicode-1-1;q=0.9
> 
> really means
> 
>     Accept-Charset: iso-8859-1;q=1, iso-8859-5;q=1, unicode-1-1;q=0.9
> 
> (in which case 8859-1 would be given equal billing with 8859-5). And
> that consequently the only way to exclude 8859-1 is to specify
> 
>     Accept-Charset: iso-8859-1;q=0, iso-8859-5, unicode-1-1;q=0.9
> 
> Is this the intended usage? If so, I find this not only convoluted but
> seriously sub-optimal. This emphasis on 8859-1 as default really is too
> much. Why go so far overboard?
> 
> 84. Section 14.2, pg. 93, 4th para., has "the server SHOULD send an
> error response with the 406 (not acceptable) status code, though the
> sending of an unacceptable response is also allowed." The effect of the
> final clause of this statement is to downgrade SHOULD to MAY.  Either
> remove the final clause or change to MAY. [My preference is to remove
> the final clause.]  Note that the semantics stated here are expressly
> different from Accept and Accept-Encoding which do require 406
> responses for unconditionally compliant implementations.  This
> inconsistency will make it difficult or impossible to implement
> agent-driven content negotiation based on Accept-Charset variants.
> 
> 85. Section 14.3, pg. 94, 1st para., has "A server tests whether ...";
> suggest changing to "A server MUST test ...".
> 
> 86. Section 14.3, pg. 94, last para., has "This means that qvalues will
> not work and are not permitted with x-gzip or x-compress." This appears
> to be stating a compatibility requirement, in which case MUST or SHOULD
> is better (in which case this note would have to be made normative).
> 
> 87. Section 14.4, pg. 95, next to last para., has "recommended" and
> "MUST NOT" in a note. Either make this normative (not a note) and use
> SHOULD and MUST NOT consistently or use "ought" and "ought not",
> respectively.
> 
> 88. Section 14.4 does not contain language as found in other Accept-*
> headers that recommends a 406 response in the case the server cannot
> satisfy the request based on its variant set for the specified URI.
> This precludes implementing client-side content negotiation along this
> variance axis. Suggest adding the required language or a note
> indicating why it is not present and what this means for client-side
> negotiation.
> 
> 89. Section 14.5. I find "Accept-Ranges" to be inconsistent in its name
> and usage with other Accept-* headers. This really should have been
> handled with Expect. Unless you can change this to use Expect (and I
> doubt you can at this stage), I'd suggest adding a note to indicate
> this inconsistency. I'd also urge adding a mechanism which does use
> Expect and deprecates the use of Accept-Ranges in a future version of
> HTTP. [If "Allow-Ranges" had been used instead, at least this would be
> consistent with the "Allow" header usage.]
> 
> Regarding the actual use of Accept-Ranges, which response would be
> appropriate for a server which sends "Accept-Ranges: none" in response
> to a Range request?  406? Some mention of the appropriate response
> should be made here.
> 
> 90. Section 14.8, pg. 97-98, seems to imply a caching proxy when
> referring to "shared cache"; however, this seems to apply as well to a
> shared cache on a user agent. Suggest making it clear which kinds of
> caches are addressed by these paragraphs.
> 
> 91. Throughout the whole of section 14.9, it is often unclear as to
> whether a requirement or statement is meant to apply only to a proxy
> cache, to a user agent cache, or to both.
> 
> 92. Section 14.9, pg. 98, 1st para., has "that MUST be obeyed by all
> caching mechanisms" which does not specify a requirement per se (note
> use of MUST in relative clause).
> 
> 93. Section 14.9, pg. 99, 1st para., has "When a directive appears
> without any 1#field-name parameter, the directive applies to the entire
> request or response." At the present, no cache-request-directive
> employs a 1#field-name parameter (see pg. 98); consequently all request
> directives apply to the entire request in all cases.
> 
> 94. Section 14.9.1, pg. 99, 2nd para., has "Indicates that the response
> is cachable by any cache, ...". Suggest changing "is cachable" to "MAY
> be cached".
> 
> 95. Section 14.9.1, pg. 99, last para., has keyword MUST NOT in
> resultative clause "Indicates that ..."; suggest rephrasing as
> imperative, e.g., "A response containing the cache directive 'private'
> MUST NOT be cached by a shared cache.".
> 
> 96. Section 14.9.1, pg. 100, 2nd para. under "no-cache", has "the
> specified field-name(s) MUST NOT be sent in the response to a
> subsequent request without successful revalidation with the origin
> server." followed by "This allows an origin server to prevent the
> re-use of certain header fields in a response, while still allowing
> caching of the rest of the response." I find this rather confusing. My
> reading of this is that a cache can, indeed, retain and reuse a field
> specified in a no-cache directive as long as it revalidates the entry
> with the origin server.  Furthermore, it appears that "no-cache" with
> no field name is to be interpreted identically to must-revalidate. I
> have always interpreted no-cache without a field-name to mean don't
> cache the response under any circumstances. Which is it?
> 
> 97. Section 14.9.2, pg. 100, 1st para., needs to do a better job of
> defining "store" without using keywords in the term or definition.
> Also, it would be better to place this definition at the beginning of
> this section. I would suggest a rewrite as follows:
> 
> "The purpose of the no-store directive is to prevent the inadvertent
> release or retention of sensitive information. In the present context,
> 'store' means to intentionally retain data in non-volatile storage.
> The no-store directive applies to the entire message, and MAY be sent
> either in a response or in a request. If sent in a request, a cache
> MUST NOT store any part of the request or its response. If sent in a
> response, a cache MUST NOT store any part of either the response or the
> request that elicitied it. This directive applies to both shared and
> non-shared caches."
> 
> In this rewrite, I've removed the statement about removing data from
> volatile storage, since this doesn't seem to apply to the semantics of
> this directive.  In particular, many caches employ a volatile and a
> non-volatile component.  The described semantics appears to strictly
> address use of the non-volatile component, and not the volatile
> component. If this is not the case, then these semantics would appear
> to broaden the stated intention found in the last paragraph on pg.
> 100. Furthermore, this directive applies equally to a user agent cache
> as well as a caching proxy, so language aimed at proxies (e.g., "after
> forwarding it") appears to be overly narrow in scope.
> 
> 98. Section 14.9.3, pg. 101, 2nd para., has "the max-age directive
> overrides the Expires header".  What is the imperative status of this
> statement? Should this read "MUST override"?
> 
> 99. Section 14.9.3, pg. 101, 5th para. (s-maxage), has "i.e., that the
> shared cache MUST NOT ..." which doesn't state a requirement per se.
> Rewrite to avoid using MUST NOT in an explanatory relative clause
> (particularly one using "i.e.").
> 
> 100. Section 14.9.3, pg. 101, 5th para. (s-maxage), has "The s-maxage
> directive is always ignored by a private cache". Should this read "A
> private cache MUST ignore the s-maxage directive."?
> 
> 101. Section 14.9.3, pg. 102, 7th para., has "only if this does not
> conflict with any MUST-level requirements"; suggest rephrasing as "with
> any conditionally compliant requirements" to avoid using MUST in this
> context which is not stating a requirement per se.
> 
> 
> Alternative 2 --
>   Enclosed HTML page: NoName.htm (30 KBytes)

Received on Friday, 13 November 1998 12:15:29 UTC