Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#408 closed editorial (incorporated)

p1 feedback

Reported by: mnot@… Owned by: draft-ietf-httpbis-p1-messaging@…
Priority: normal Milestone: 22
Component: p1-messaging Severity: In WG Last Call
Keywords: Cc:

Description

  • 1. Introduction -- "However since multiple clients might act in parallel..." Should also mention that other interfaces to the underlying data can change its state.
  • 1. Introduction -- three paragraphs, starting with "HTTP is a generic interface protocol..." would fit better in Section 2 Architecture.
  • 1. Introduction -- "One consequence of HTTP flexibility..." --> "...HTTP's flexibility..."
  • 2.1 Client/Server? Messaging -- "..refer to whichever component sent a given message..." --> "...refer to any component that sends a given message..." (aligns with similar text nearby)
  • 2.6 Protocol Versioning - should reference the 505 status code in P2
  • 2.7.1 http URI Scheme - "... because the name delegation process depends on TCP for establishing authority." --> "... because the name delegation process uses the TCP port number (among other things) to establish identity."
  • 2.7.2 https URI scheme - same as above
  • 2.7.1 http URI Scheme, last para - '...when transmitting an "http" URI in a message.' --> '...when transmitting an "http" URI in a request-target.'
  • 2.7.1 Stick with "an HTTP" or "a HTTP".
  • 3.1.1 "A server MUST be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message." This repeats the ABNF requirement in the conformance section; should be removed.
  • 3.1.1 "...at a minimum, request-line lengths of up to 8000 octets." Remove "up to"; redundant.
  • 3.2 Header Fields -- talks about there being no limit on the number of header fields in a message. This should reference 3.2.3, which indicates how respond when they're too long (or that content should be moved here). Should also reference rfc6585 for 431 Request Header Fields too Large.
  • 3.2 Header Fields -- The advice regarding Set-Cookie2 in the note at the end appears to endorse that header; however, it has been obsoleted. This text should be removed.
  • 3.2.1. Whitespace -- uses "produce" instead of "generate" (as per the language in the conformance section).
  • 3.2.2. Field Parsing -- uses "produce" instead of "generate" (as per the language in the conformance section).
  • 3.2.4 Field value components -- there are two instances of "Senders SHOULD NOT escape octets..." these requirements need to be scoped to senders *that generate* the indicated components; those merely forwarding messages shouldn't be required to fix them up.
  • 3.3.1 Transfer-Coding -- "The "chunked transfer-coding (Section 4.1) MUST be implemented..." This paragraph specifies that "chunked" MUST be last two times; once is enough.
  • 3.3.1 Transfer-Coding -- "If more than one Transfer-Encoding header field is present in a message, the multiple field-value MUST be combined into one field-value, according to the algorithm defined in Section 3.2, before determining the message body length." This doesn't make a lot of sense -- what's the motivation?
  • 3.3.3 Message Body Length -- "The provided Content-Length header MUST be removed, prior to forwarding the message..." --> "The provided Content-Length header MUST be removed by senders prior to forwarding the message..." (make requirement target explicit)
  • 3.4 Handling Incomplete Messages -- "Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, MUST result in closure of connection..." It's not clear what target this requirement applies to -- clients? It should be explicit.
  • 3.4 Handling Incomplete Messages -- "... cannot be assumed to convey the full semantics of the response and MUST be treated as an error." Specify target '... by recipients."
  • 3.4 Handling Incomplete Messages -- "A user agent MUST NOT render..." --> "A user agent MUST NOT consider..."
  • 3.5 Message Parsing Robustness -- "If terminating the request message body with a line-ending is desired, then the client MUST include the terminating CRLF octets as part of the message body length." I think the correct target for the requirement here is user agent, not client.
  • 5.6, 5.7 and 5.8 -- it seems like 5.6 Message forwarding should really be a top-level section (perhaps with the word "intermediary" in it), with the current 5.7 and 5.8 under it. At the very least, 5.7 should be 5.6.1 and 5.8 should be 5.6.2.
  • 5.6 Message Forwarding -- "...exclude fields that are only intended for the incoming connection." --> "...exclude fields that are only scoped to the incoming connection."
  • 5.8 Message Transforming --> Message Transformation
  • 5.9 Associating a Response to a Request -- "A client that uses persistent connections and sends more than one request per connection..." --> "A client that has more than one outstanding request on a connection..."

Change History (6)

comment:1 Changed 6 years ago by fielding@…

  1. Introduction -- "However since multiple clients might act in parallel..." Should also mention that other interfaces to the underlying data can change its state.

Not needed -- it would just clutter the paragraph.

  1. Introduction -- three paragraphs, starting with "HTTP is a generic interface protocol..." would fit better in Section 2 Architecture.

Nope, they introduce the protocol.

  1. Introduction -- "One consequence of HTTP flexibility..." --> "...HTTP's flexibility..."

Replacing with "this"

2.1 Client/Server?? Messaging -- "..refer to whichever component sent a given message..." --> "...refer to any component that sends a given message..." (aligns with similar text nearby)

Okay.

2.6 Protocol Versioning - should reference the 505 status code in P2

It already does.

2.7.1 http URI Scheme - "... because the name delegation process depends on TCP for establishing authority." --> "... because the name delegation process uses the TCP port number (among other things) to establish identity."

No, it depends on TCP (the only way to check with authority is to connect).

2.7.2 https URI scheme - same as above

Same answer.

2.7.1 http URI Scheme, last para - '...when transmitting an "http" URI in a message.' --> '...when transmitting an "http" URI in a request-target.'

It applies to all header fields as well.

2.7.1 Stick with "an HTTP" or "a HTTP".

an HTTP (we do not expect the reader to expand the acronym)

3.1.1 "A server MUST be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message." This repeats the ABNF requirement in the conformance section; should be removed.

Okay.

3.1.1 "...at a minimum, request-line lengths of up to 8000 octets." Remove "up to"; redundant.

Okay.

3.2 Header Fields -- talks about there being no limit on the number of header fields in a message. This should reference 3.2.3, which indicates how respond when they're too long (or that content should be moved here). Should also reference rfc6585 for 431 Request Header Fields too Large.

3.2.3 is poorly worded -- it should not say anything about total header block length. If we want to integrate RFC6585, this should be a separate issue.

3.2 Header Fields -- The advice regarding Set-Cookie2 in the note at the end appears to endorse that header; however, it has been obsoleted. This text should be removed.

Already removed.

3.2.1. Whitespace -- uses "produce" instead of "generate" (as per the language in the conformance section).

3.2.2. Field Parsing -- uses "produce" instead of "generate" (as per the language in the conformance section).

Done in general.

3.2.4 Field value components -- there are two instances of "Senders SHOULD NOT escape octets..." these requirements need to be scoped to senders *that generate* the indicated components; those merely forwarding messages shouldn't be required to fix them up.

Okay.

comment:2 Changed 6 years ago by fielding@…

From [2030]:

(editorial) Deal with first half of mnot p1 feedback; addresses #408

comment:3 Changed 6 years ago by fielding@…

3.3.1 Transfer-Coding -- "The "chunked transfer-coding (Section 4.1) MUST be implemented..." This paragraph specifies that "chunked" MUST be last two times; once is enough.

Okay.

3.3.1 Transfer-Coding -- "If more than one Transfer-Encoding header field is present in a message, the multiple field-value MUST be combined into one field-value, according to the algorithm defined in Section 3.2, before determining the message body length." This doesn't make a lot of sense -- what's the motivation?

Okay, deleted (we'll just assume the framing parser isn't clueless about multiple same-name fields)

3.3.3 Message Body Length -- "The provided Content-Length header MUST be removed, prior to forwarding the message..." --> "The provided Content-Length header MUST be removed by senders prior to forwarding the message..." (make requirement target explicit)

Okay.

3.4 Handling Incomplete Messages -- "Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, MUST result in closure of connection..." It's not clear what target this requirement applies to -- clients? It should be explicit.

Okay.

3.4 Handling Incomplete Messages -- "... cannot be assumed to convey the full semantics of the response and MUST be treated as an error." Specify target '... by recipients."

Rewritten.

3.4 Handling Incomplete Messages -- "A user agent MUST NOT render..." --> "A user agent MUST NOT consider..."

On the block already ... moving to security considerations.

3.5 Message Parsing Robustness -- "If terminating the request message body with a line-ending is desired, then the client MUST include the terminating CRLF octets as part of the message body length." I think the correct target for the requirement here is user agent, not client.

Sure.

5.6, 5.7 and 5.8 -- it seems like 5.6 Message forwarding should really be a top-level section (perhaps with the word "intermediary" in it), with the current 5.7 and 5.8 under it. At the very least, 5.7 should be 5.6.1 and 5.8 should be 5.6.2.

The latter, with 5.9 moved above it.

5.6 Message Forwarding -- "...exclude fields that are only intended for the incoming connection." --> "...exclude fields that are only scoped to the incoming connection."

Fields are not scoped.

5.8 Message Transforming --> Message Transformation

Okay.

5.9 Associating a Response to a Request -- "A client that uses persistent connections and sends more than one request per connection..." --> "A client that has more than one outstanding request on a connection..."

Okay.

comment:4 Changed 6 years ago by fielding@…

From [2031]:

(editorial) Deal with second half of mnot p1 feedback; addresses #408

comment:5 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 22
  • Resolution set to incorporated
  • Status changed from new to closed

comment:6 Changed 6 years ago by fielding@…

From [2033]:

Move new user agent requirement on rendering incomplete responses to a suggestion in security considerations. Addresses #408 and #415

Consolidate more stuff on persistent connection reuse. Addresses #396

Note: See TracTickets for help on using tickets.