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

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".

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.

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.

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 "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 partice 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.

Received on Thursday, 5 November 1998 06:32:42 UTC