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
to
follow this with additional comments over the next few days. Most of the
comments
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.
Should
this not state "acts as a registry for transfer and content coding value
tokens"?

8. Clause 3.6, pg. 25, 5th para., uses the term "optional metadata"
without
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
fully
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
the
case that existing servers are validating canonical status of entity
bodies?

11. Clause 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. 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
agent
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
"multipart/
form-data". Why is this specific type given a special note? How about
"multipart/byte-ranges"?

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

15. Clause 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. 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
header
unless ...".

18. Clause 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. Clause 4.4, pg. 32, 2nd para., has the relative clause "... which
MUST
NOT ...". This is not a requirement, so should not use these keywords.
Suggest
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
intended
to capture current practice, then this is a broadening of current
practice.
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
type.
In particular, no default interpretation is dictated. In contrast, no
flexibility is given in the hueristic guessing of a "text" content
type's
character set (cf. clause 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 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
accommodate
existing practice.

26. Clause 8.1.3, p. 43, 1st para., has the typo "in14.10." Should
instead
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
connections".

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

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

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

36. Clause 9.9 may wish to substitute its reference [44] with the new
I-D
<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
to
MAY.

38. Clause 10.2.6 states "the user agent SHOULD reset the document
view".
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
hypertext.
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
caching
not suitability.

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

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

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

50. Clause 10.4.11 has "This response is cachable ...". Suggest
rephrasing
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