Re: Fwd: [httpbis] #523: Gen-ART Last Call review draft-ietf-httpbis-p1-messaging-25

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

Received on Sunday, 8 December 2013 09:51:20 UTC