Meral,
some more comments inline:
-[Page 5] in the intro, right after it says "This HTTP/1.1 specification
obsoletes and moves to historic status RFC 2616....", it would
help to add a reference to Appendix B and mention this is where the
differences with RFC2616 is listed.
That would be somewhat misleading as we have "changes from 2616"
sections in all six parts.
[Page 5,6], Section 1, this statement is not clear. Are we talking about
one HTTP transaction changing info on the server/data base?
"
If the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message-
forwarding intermediaries.
"
We talk about observable changes because that's all what's relevant for
the protocol.
-[Page 11], Section 2.3, "Instead, an interception proxy filters or
redirects outgoing TCP port 80 packets (and occasionally other common
port
traffic)."
Not sure if "occasionally other common port traffic" means port 443?
...
Nope (at least that's my understanding).
-[Page 13], not a comment for this draft but in general, has the WG
considered a BCP for general error handling, in line with the example
given after this sentence:
"
HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies.
"
No.
-[Page 15], if the statement below is a well-known and often happening
scenario it would help to give at least
one example of how a client can deduce that by going to a lower
version of
HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"
A client MAY send a lower request version if it is known that the
server incorrectly implements the HTTP specification, but only after
the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., Server) that
the server improperly handles higher request versions.
"
The idea is that if the server is known not to implement 1.1 properly
than 1.0 is the only available feedback. I thought that's clear enough.
-[Page 15],can the server send this error message to refuse service based
on e.g. connection identification or other reasons? Then how can the
client
address the problem if in reality it was not related to the version of
HTTP?
"
A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.
"
This status code is for signaling that the server doesn't support the
request protocol version. Nothing more.
-[Page 16], would it be ok to use MAY? If so it would be clearer to use
MAY. : "A recipient MAY..."
"
A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
"
Exactly how is that clearer?
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting
identifiers".
suggestion: if another word than "minting" (e.g. generating, creating),
could be used it would be easier to read that section.
(also used in section 2.7.2)
I believe the term "minting" is very commonly used.
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port
80 is assumed (the default reserved port for WWW services).
"
It's a statement of fact, no interop requirement.
-[Page 17], "non-interim" , not clear how it can be determines as non-
interim (no other message in between? or under a certain peruiod of
time?)
Also the term "authoritative" is introduced and should be defined in this
context.
"
If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [Part2], then
that response is considered an authoritative answer to the client's
request.
"
As defined in Part2, Section 6; that is, a status code other that 1xx.
-[Page 21], Should it be section 5.3?
"
Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), ...
"
No.
-[Page 21], just verifying is it three or tree?
"
..., since no whitespace is allowed in the three components.
"
It is "three".
-[Page 52], refers to an obsoleted RFC. Maybe repeating the
explanation in
this draft would be a better idea.
"
A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients).
"
I think it's preferable not to inline that information; I think some
people already complained about the spec being too long ;-)
...
Best regards, Julian
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
