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.

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

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

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.

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

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?

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

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.

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.

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

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?

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.

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

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

116. Section 14.16, pg. 111, 5th para., has 'A response with status
code 206 (Partial Content) MUST NOT include a Content-Range field with
a content-range-spec of "*"'. It isn't clear how to interpret this
since it is not possible for the value of content-range-spec to be
merely "*".  Perhaps this means 'with a content-range-spec which uses
"*" as the instance-length'? If this is the case, then perhaps it
would be better to change the definition of instance-length to:

instance-length = 1*DIGIT | "*"

And then say '... MUST NOT include a Content-Range field with an
instance-length of "*"'.

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

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

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.

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

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

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.

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

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

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.

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.

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.

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

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.

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?

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.

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

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.

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

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.

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

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)?

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.

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

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.

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?

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

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

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.

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

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

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

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

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

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?

Received on Monday, 16 November 1998 09:47:35 UTC