Comments (Part 1): Hypertext Transfer Protocol -- HTTP/1.1 to Dra ft Standard

Unfortunately, I have only had an opportunity to review this I-D for the
past few
days. However, I have assembled an initial set of 51 comments. I expect
follow this with additional comments over the next few days. Most of the
pertain to form as opposed to technical substance. However, comments 6,
10, 22,
25, 30, 37, 38, and 41 are potentially substantive issues.

1. Clause 1.2 fails to state that implementations that fail
to satisfy statements marked as "REQUIRIED" would not qualify
as comopliant.

2. Clause 1.2 should indicate the status of these keywords in
"Notes"; i.e., is the use of these keywords in notes normative?

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

4. Clause 2.2, definition of "CTL", on pg. 16, fails to note that
ASCII (and ISO 646:IRV) consider SPACE (040) to be a control character
of the same status as DEL (177).

5. Clause 2.2, pg. 17, first paragraph, has a forward reference to
"parameter value". Should add a cross reference to the section that
defines this non-terminal.

6. Clause 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. Clause 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. Clause 3.6, pg. 25, 5th para., uses the term "optional metadata"
providing further definition of what such "metadata" might be.

9. Clause 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 was.

10. Clause 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 ...". This requirement
appears to be overly onerous for HTTP implementations. Is it actually
case that existing servers are validating canonical status of entity

11. Clause 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. Clause 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
would ...". This "implied" behavior needs to be made explicit. What is
the behavior of a MIME user agent in this context?

13. Clause 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. Clause 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 I interpret these
requirements? Either make them explicit or remove them.

15. Clause 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. Clause 3.10 never actually says that RFC1766 language tags "MUST" be
used. I'd suggest adding stronger language here.

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

18. Clause 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. Clause 4.4, pg. 32, 2nd para., has the relative clause "... which
NOT ...". This is not a requirement, so should not use these keywords.
using "does not".

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

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

22. Clause 4.4, pg. 32, 5th para., states "HTTP/1.1 user agents MUST
notify the user when an invalid length is received and detected." I have
verified that the latest releases of Internet Explorer and Netscape
Communicator do not implement this requirement. If this standard is
to capture current practice, then this is a broadening of current
I'd suggest using the keyword "SHOULD" or "MAY" instead.

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

24. Clause 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. Clause 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 hueristic guessing of a "text" content
character set (cf. clause 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 clause 3.4 will "break" many existing
implementations which assume that the default is applied as 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 clause 3.4 to be permanently disabled to
existing practice.

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

27. Clause 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

28. Clause 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 clause 8.1.4, para. 4, which does not have this parenthetical note.

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

30. Clause 9, pg. 48, 2nd para., appears to be partially redundant with
clause 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. Clause 9.2., pg. 49, 2nd para., states "Response to this method are
not cachable." Should this be made strong with either MUST NOT or SHOULD
The same comment applies in a variety of other context regarding the
suitability or non-suitability of caching a response.

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

33. Clause 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 should be substituted with "MUST NOT".

34. Clause 9.6, pg. 52, 3rd para., uses the phrase "server" where
server" is implied. Suggest reviewing uses of "server" for possible

35. Clause 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. clause 9.6, 9.7).

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

37. Clause 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 placed on
UA semantics outside the scope of HTTP proper. Suggest changing SHOULD

38. Clause 10.2.6 states "the user agent SHOULD reset the document
This conditional requirement seems to be placed on UA semantics outside
the scope of HTTP proper. Suggest changing SHOULD to MAY.

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

40. Clause 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. Clause 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. Clause 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
The same comment applies in a number of other clauses: search for "short
hypertext note".

43. Clause 10.3.3, pg. 58, 1st para., states "This response is only
cachable if indicated by a Cache-Control or Expires header field." Why
the conditionalization used here and not elsewhere regarding response
cachability? Furthermore, these headers indicate non-suitability of
not suitability.

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

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

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

47. Clause 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. Clause 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. Clause 10.4.10, pg. 63, 2nd para., has the phrase "would likely".
rephrasing to use RECOMMENDED or MAY.

50. Clause 10.4.11 has "This response is cachable ...". Suggest
as "MAY be cached". Is this the only 4XX response which is cachable?

51. Claues 11 uses the term "OPTIONAL" as a keyword but this is not
a keyword context.

Glenn Adams
Director, Software Architecture
Spyglass, Inc.
One Cambridge Center
Cambridge, MA 02142
Tel: 617-679-4652, Fax: 617-621-9582

Received on Tuesday, 27 October 1998 05:00:59 UTC