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

I'm not certain which form is preferred, sending comments en masse or
individually. If the
latter is desired, let me know and I'll break these out. Of the
following, comments 6, 10, 22,
25, 30, 37, 38, and 41 are potentially substantive issues. These
comments cover sections
1-11; I intend to complete my comments later this week on the remaining
sections.

1. Section 1.2 fails to state that implementations that fail
to satisfy statements marked as "REQUIRIED" would not qualify
as compliant. Otherwise, suggest replacing REQUIRED with MUST or
MUST NOT for the sake of consistency.

2. Section 1.2 should indicate the status of these keywords in
"Notes". Are the use of these keywords in notes normative?

3. Section 2.1, pg. 15, "implied *LWS", contains what appears
to be an editorial note "[jg13]".

4. Section 2.2, pg. 16, definition of "CTL", fails to consider that
ASCII (and ISO646-1993) consider SPACE (040) to be a control character
of the same status as DEL (177).

5. Section 2.2, pg. 17, 1st para., has a forward reference to
"parameter value". Should add a cross reference to the section that
defines this non-terminal.

6. Section 3.4, pg. 21, specifies that "the definition associated with
a MIME character set name MUST fully specify the mapping ...". Should
this not be a requirement placed on the registrant of a MIME character
set and not an HTTP implementation? Or, is this requirement really
stating that any HTTP implementation must maintain a table of registered
character sets known to satisfy this requirement and MUST NOT use any
character set not present in this table? Overall, this seems an onerous
requirement for an HTTP implementation.

7. Section 3.6, pg. 24, 3rd para., states "... (IANA) acts as a registry
for transfer-coding value tokens" and goes on to list the initial set
of registered tokens in which Content-Encoding tokens are included.
Should
this not state "acts as a registry for transfer and content coding value
tokens"?

8. Section 3.6, pg. 25, 5th para., uses the term "optional metadata"
without
providing further definition of what such "metadata" might be. Suggest
an
example here or clarification.

9. Section 3.6, pg. 25, 6th para., discusses a "situation" regarding
interoperability failure. This "situation" should be described more
fully
or an example given to make clear what the problem is.

10. Section 3.7.1, pg. 26, 1st para., states "An entity-body transferred
via HTTP messages MUST be represented in the appropriate canonical form
prior to its transmission except for "text" types ...". Is it actually
the
case that servers are validating canonical status of entity bodies? This
contradicts the "entity-body as payload" philosophy.

11. Section 3.7.1, pg. 26, 2nd para., uses the phrases "allows" and
"allows
the use of". Should these be rephrased using the "MAY" keyword? The same
comment applies elsewhere when the work "allows" or "permitted" is used.

12. Section 3.7.2, pg. 27, 2nd para., states "In all other cases, an
HTTP
user agent SHOULD follow the same or similar behavior as a MIME user
agent
would ...". This "implied" behavior needs to be made explicit. What is
the behavior of a MIME user agent in this context?

13. Section 3.7.2, pg. 27, 4th para., contains a note regarding
"multipart/
form-data". Why is this specific type given a special note? How about
"multipart/byte-ranges"?

14. Section 3.8, pg. 28, 1st para., states "Product tokens SHOULD be
short
and to the point." and "They MUST NOT be used for advertising or other
non-essential information." As an implementer, how can one interpret
these
requirements? Either make quantify them or remove them.

15. Section 3.9 refers to "short 'floating point' numbers". I would
suggest
replacing this with "real numbers" since both "short" and "floating
point"
seems to implementation specific.

16. Section 3.10 never actually says that RFC1766 language tags "MUST"
be
used. I'd suggest adding stronger language here.

17. Section 4.2, pg. 31, 4th para., states "It MUST be possible ...". I
would suggest replacing this with a statement that uses the converse
using the
form "MUST NOT ... unless ..."; e.g., "Multiple header fields MUST NOT
be
combined into one header unless ...".

18. Section 4.3, pg. 31, 5th para., states "The presence of a
message-body
in a request is signaled by the inclusion of Content-Length or Transfer-
Encoding header field ...".  However, "multipart/byte-ranges" may
include
a message-body without either of these headers.

19. Section 4.4, pg. 32, 2nd para., has the relative Section "... which
MUST
NOT ...". This is not a requirement, so should not use these keywords.
Suggest
using "does not".

20. Section 4.4, pg. 32, last para., the "Note" uses "may" and "must".
If
keyword usage in notes is not normative, then this should be stated in
Section 1.2.

21. Section 4.4, pg. 32, 1st para., uses the phrase "cannot be". Suggest
rephrasing to use "MUST NOT".

22. Section 4.4, pg. 32, 5th para., states "HTTP/1.1 user agents MUST
notify the user when an invalid length is received and detected." This
does
not seem to be reflected by current industry practice (cf. IE4 and
Netscape
Communicator 4 behavior). If this standard is intended to capture
current
practice, then this is a broadening of current practice. I'd suggest
using
the keyword "MAY" instead.

23. Section 5.1.2, pg. 35, 3rd para., has "three options" when four
are described.

24. Section 5.1.2, pg. 35, 5th para., uses the keyword "REQUIRED"
instead
of "MUST". It seems that "MUST" is given preference throughout this
document. The same comment applies to the use of "OPTIONAL" vs. "MAY".

25. Section 7.2.1, pg. 41, 4th para., gives considerable flexibility to
a recipient regarding the heuristic guessing of an entity's content
type.
In particular, no default interpretation is dictated. In contrast, no
flexibility is given in the heuristic determination of a "text" content
type's
character set (cf. Section 3.4, where a default of ISO8859-1 is
dictated).
I wonder why the two quite different approaches are maintained. In
particular,
I do know that the requirements of Section 3.4 will "break" many
existing
implementations which assume that the "default" is applied as a no more
than
a default heuristic in the absence of an explicit CHARSET and not as an
immediate override to any heuristics. I fully expect our East Asian
customers
to require this feature of Section 3.4 to be permanently disabled to
accommodate
existing practice.

26. Section 8.1.3, p. 43, 1st para., has the typo "in14.10." Should
instead
read "in section 14.10.".

27. Section 8.1.4, pg. 44, 6th para., has the phrase "... SHOULD
maintain
AT MOST 2 connections ..."; since "AT MOST" is not a keyword, suggest
rephrasing his requirement using "SHOULD NOT maintain more than 2
connections".

28. Section 8.2.3, pg. 45, has the phrase "(Confirmation by user-agent
software with semantic understanding of the application MAY substitute
for use confirmation.)" This appears to controvert the stronger language
in Section 8.1.4, para. 4, which does not have this parenthetical note.

29. Section 8.2.4, pg. 45, 1st para., uses the term "end-client". This
term seems to be nonstandard with other terminology regarding
communicating
parties in the HTTP context.

30. Section 9, pg. 48, 2nd para., appears to be partially redundant with
Section 5.1.2, pg. 35, line 2078 (in file). Furthermore, does this
requirement
actually hold for forms of Request-URI other than abs_path? For example,
does an OPTIONS * HTTP/1.1 request require a Host header?

31. Section 9.2., pg. 49, 2nd para., states "Response to this method are
not cachable." Should this be made stronger with either MUST NOT or
SHOULD NOT?
The same comment applies in a variety of other context regarding the
suitability or non-suitability of caching a response.

32. Section 9.3, pg. 50, 4th para., uses the expression "if and only if
...".
Suggest using "MUST NOT unless" instead.

33. Section 9.6, pg. 51, 1st para., uses the phrase "the origin server
can 
create ...". Suggest using MAY instead. Should review other uses of
"can"
in this document for similar substitution. Same comment applies to uses
of
"cannot" which in most cases should be replaced with "MUST NOT".

34. Section 9.6, pg. 52, 3rd para., uses the phrase "server" where
"origin
server" appears to be implied. Suggest reviewing uses of "server" for
possible
narrower semantics.

35. Section 9.8, pg. 53, 3rd para., note "Responses to this method MUST
NOT
be cached." while most other methods have "Responses to this method are
not
cachable." (cf. Section 9.6, 9.7). Suggest making this language more
consistent.

36. Section 9.9 may wish to substitute its reference [44] with the new
I-D
<draft-luotonen-web-proxy-tunneling-01.txt>. However, note that the
argument to the CONNECT method prescribed by this I-D is not conformant
with the specification of "Request URI" in Section 5.1.2. Perhaps the
reference to the tunneling draft should be removed altogether with this
keyword just stated as "reserved"?

37. Section 10.2.5, pg. 56, 2nd para., states "any new or updated
metainformation SHOULD be applied to the document currently in the user
agent's active view." This conditional requirement seems to be place a
constraint on UA semantics outside the scope of HTTP proper. Suggest
changing SHOULD to MAY.

38. Section 10.2.6 states "the user agent SHOULD reset the document
view".
This conditional requirement seems to place a constraint on UA semantics
outside the scope of HTTP proper. Suggest changing SHOULD to MAY.

39. Section 10.2.7, pg. 56, 1st para., uses "MUST" in the past tense.
Suggest rephrasing this to not use past tense.

40. Section 10.2.7, pg. 57, 2nd para., states "the response MUST include
all of the entity-headers that would have been returned ...".  Which
entity-headers are these precisely?

41. Section 10.3.2, pg. 58, 1st para., states "The requested resource
has been assigned a new permanent URI and any future references to
this resource SHOULD be done using one of the returned URIs." This is
an onerous requirement on UAs unless they happen to have link editing
capabilities. Should be qualified to not apply to UAs without such
capability; otherwise, no UA of this type will ever be unconditionally
compliant. Alternatively, change this requirement to MAY.

42. Section 10.3.2, pg. 58, 2nd para., states "the entity of the
response
SHOULD contain a short hypertext note ...". Suggest formalizing this to
state a specific content type or, alternatively, not use the term
hypertext.
The same comment applies in a number of other Sections: search for
"short
hypertext note".

43. Section 10.3.3, pg. 58, 1st para., states "This response is only
cachable if indicated by a Cache-Control or Expires header field." In
contrast,
other Sections (cf. 10.3.1, 10.3.2, etc.) have "This response is
cachable
unless indicated otherwise." Suggest making these more consistent if
possible
or referring to Section 13.4.

44. Section 10.3.6 has a note describing "significant security
consequences".
Could these consequences be detailed somewhere in this specification?

45. Section 10.3.7 has a typo. Change "... specification, and is no
longer ..."
to "... specification, is no longer ...".

46. Section 10.4, pg. 61, 1st para., has a superfluous comma after "the
response".

47. Section 10.4.8 has "This code is similar to 401 (Unauthorized), but
indicates that the client MUST first authenticate ..." This doesn't seem
to be a requirement but a statement of fact. Suggest changing to "but
indicates that the client did not first authenticate itself or its
credentials were not accepted ...".

48. Section 10.4.10, pg. 63, 2nd para., has the phrase "the server
might".
Suggest changing to "the server MAY". Should review other uses of
"might"
in this specification.

49. Section 10.4.10, pg. 63, 2nd para., has the phrase "would likely".
Suggest
rephrasing to use MAY or SHOULD instead.

50. Section 10.4.11 has "This response is cachable ...". Suggest
rephrasing
as "MAY be cached". It may be useful here to point out that this is the
only
cachable 4XX response (according to Section 13.4).

51. Section 11 uses the term "OPTIONAL" as a keyword in a non-keyword
context.


Glenn Adams
Spyglass, Inc., Cambridge, Mass.

Received on Tuesday, 27 October 1998 05:38:26 UTC