This is a multi-part message in MIME format, created by Pachyderm.
The parts are separated by "--1" lines.
The first part is a covering note, the others are attachments.
--1
Content-Type: text/plain
For some reason, this has not appeared in the mailing list archive.
If at first you don't succeed, try, try again.
- Jim
--1
Content-Type: message/rfc822
Content-Disposition: inline
Received: by src-mail.pa.dec.com; id AA22317; Mon, 2 Nov 1998 17:41:39 -0800
Received: from mail1.digital.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM)
id AA10410; Mon, 2 Nov 1998 17:40:32 -0800
Received: from spybem01.nap.spyglass.com (spybem01.nap.spyglass.com [208.200.99.7])
by mail1.digital.com (8.9.1a/8.9.1/WV2.0a) with ESMTP id RAA16691
for <jg@pa.dec.com>; Mon, 2 Nov 1998 17:40:28 -0800 (PST)
Received: by spybem01.nap.spyglass.com with Internet Mail Service (5.5.1960.3)
id <VX96LJA0>; Mon, 2 Nov 1998 19:42:20 -0600
Message-Id: <D181361D7C86D011925700805FFE898E019715F1@spybem01.nap.spyglass.com>
From: "Adams, Glenn" <gadams@spyglass.com>
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
Date: Mon, 2 Nov 1998 19:42:17 -0600
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
boundary="---- =_NextPart_001_01BE06CB.322E32AE"
Status:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------ =_NextPart_001_01BE06CB.322E32AE
Content-Type: text/plain;
charset="iso-8859-1"
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 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.
------ =_NextPart_001_01BE06CB.322E32AE
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
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 if any =
"iso-8859-1;q=3D1" is always implied unless
otherwise explicitly present. =
This means that:
= Accept-Charset: iso-8859-5, unicode-1-1;q=3D0.9
really means
= Accept-Charset: iso-8859-1;q=3D1, iso-8859-5;q=3D1, = unicode-1-1;q=3D0.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=3D0, iso-8859-5, = unicode-1-1;q=3D0.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.
------ =_NextPart_001_01BE06CB.322E32AE-- --1--