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

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.
this not state "acts as a registry for transfer and content coding value

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

9. Section 3.6, pg. 25, 6th para., discusses a "situation" regarding
interoperability failure. This "situation" should be described more
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
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
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
user agent SHOULD follow the same or similar behavior as a MIME user
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
form-data". Why is this specific type given a special note? How about

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

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

16. Section 3.10 never actually says that RFC1766 language tags "MUST"
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
combined into one header unless ...".

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

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

20. Section 4.4, pg. 32, last para., the "Note" uses "may" and "must".
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
not seem to be reflected by current industry practice (cf. IE4 and
Communicator 4 behavior). If this standard is intended to capture
practice, then this is a broadening of current practice. I'd suggest
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"
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
In particular, no default interpretation is dictated. In contrast, no
flexibility is given in the heuristic determination of a "text" content
character set (cf. Section 3.4, where a default of ISO8859-1 is
I wonder why the two quite different approaches are maintained. In
I do know that the requirements of Section 3.4 will "break" many
implementations which assume that the "default" is applied as a no more
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
to require this feature of Section 3.4 to be permanently disabled to
existing practice.

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

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

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
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
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
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
create ...". Suggest using MAY instead. Should review other uses of
in this document for similar substitution. Same comment applies to uses
"cannot" which in most cases should be replaced with "MUST NOT".

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

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

36. Section 9.9 may wish to substitute its reference [44] with the new
<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
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
SHOULD contain a short hypertext note ...". Suggest formalizing this to
state a specific content type or, alternatively, not use the term
The same comment applies in a number of other Sections: search for
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
other Sections (cf. 10.3.1, 10.3.2, etc.) have "This response is
unless indicated otherwise." Suggest making these more consistent if
or referring to Section 13.4.

44. Section 10.3.6 has a note describing "significant security
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

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
Suggest changing to "the server MAY". Should review other uses of
in this specification.

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

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

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

Glenn Adams
Spyglass, Inc., Cambridge, Mass.

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