* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #502 (closed design: incorporated)

Opened 12 months ago

Last modified 12 months ago

APPSDIR review of draft-ietf-httpbis-p1-messaging-24

Reported by: julian.reschke@gmx.de Owned by: draft-ietf-httpbis-p1-messaging@tools.ietf.org
Priority: normal Milestone: 25
Component: p1-messaging Severity: In IETF LC
Keywords: Cc:
Origin: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10641.html

Description (last modified by fielding@gbiv.com) (diff)

Major issues: None


Minor issues:

In Section 2.6:

"Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages. In other words, they MUST NOT blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages."

The first RFC 2119 requirement (see above) states that the intermediary has to send its own HTTP-version while the second RFC 2119 requirement prohibits the intermediary from blindly forwarding the first line of the HTTP message. The intent of the first requirement seems clear to me. I suggest having the second requirement as clarifying text instead of a RFC 2119 requirement. - see [2458]


"A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known."

The client would have to track the version supported by the server once it knows that information. A server can be one or more HTTP implementations. In practice these implementations will likely support HTTP 1.1. I'll list the "and whose major version is no higher than the highest version supported ..." as an issue. Is the intent to ensure that the client can work with HTTP 2.0?

WONTFIX


"A server MAY send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's request."

Why is this a RFC 2119 "may"?


In Section 5.7:

"An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly."

I don't understand why an intermediary would forward a message to itself. Please note that I do not consider this prohibition as an issue.

Because they do. WONTFIX


In Section 6.1:

"Recipients that trigger certain connection behavior based on the presence of connection options MUST do so based on the presence of the connection-option rather than only the presence of the optional header field. In other words, if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient MUST ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially conformant.

I am flagging the usage of a requirement followed by the "must ignore" requirement as an issue as the "in other words" suggest that it is a clarification of the first requirement.


In Section 6.4

"A client SHOULD limit the number of simultaneous open connections that it maintains to a given server."

There is an explanation about why a specific number is not included for this recommendation in the paragraphs following the above text. I read Issue #131. I don't see any discussion of the tradeoffs in Section 6.4. The is a note about servers may reject an excessive number of connections from a client if they deem that it is abusive. - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0386.html


The HTTP Transfer Coding namespace (Section 8.4) is currently "First Come First Served". The new registration procedure required IETF Review. What is the reason for the change? -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0356.html


In Section 8.5.1:

'The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.'

Why is this a RFC 2119 "should"?

"The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted."

I suggest using plain English instead of RFC 2119 key words for the above (and for the rest of the text in Section 8.5.1). - see #509


Nits:

For Section 8.1, the Message Header Field Names registry is at http://www.iana.org/assignments/message-headers/ [2435]

For Section 8.2, the URI Schemes registry is at http://www.iana.org/assignments/uri-schemes/ [2435]

In Section 8.4, the RFC 2119 key words are not needed as that section is about a procedure for registration. Plain English is usually clear enough. - see #509

Change History

comment:1 Changed 12 months ago by julian.reschke@gmx.de

From [2435]:

Fix a few IANA URIs (see #502).

comment:2 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:3 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:4 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:5 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:6 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:7 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:8 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:9 Changed 12 months ago by julian.reschke@gmx.de

From [2458]:

turn a redundant use of RFC2119 keywords into prose (see #502)

comment:10 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:11 Changed 12 months ago by julian.reschke@gmx.de

  • Severity changed from In WG Last Call to In IETF LC

comment:12 Changed 12 months ago by fielding@gbiv.com

From [2468]:

rephrase a MAY send 505; addresses #502

comment:13 Changed 12 months ago by fielding@gbiv.com

"A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known."

The client would have to track the version supported by the server once it knows that information. A server can be one or more HTTP implementations. In practice these implementations will likely support HTTP 1.1.

Yes, today.

I'll list the "and whose major version is no higher than the highest version supported ..." as an issue.

Why?

Is the intent to ensure that the client can work with HTTP 2.0?

No. The intent is that the client send a message using an HTTP version that is interoperable with the server.

comment:14 Changed 12 months ago by fielding@gbiv.com

"A server MAY send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's request."

Why is this a RFC 2119 "may"?

Rewritten in [2468]

comment:15 Changed 12 months ago by fielding@gbiv.com

  • Description modified (diff)

comment:16 Changed 12 months ago by fielding@gbiv.com

From [2471]:

reduce two MUSTs to a clarified ought; addresses #502

comment:17 Changed 12 months ago by fielding@gbiv.com

  • Description modified (diff)

In Section 6.1:

"Recipients that trigger certain connection behavior based on the presence of connection options MUST do so based on the presence of the connection-option rather than only the presence of the optional header field. In other words, if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient MUST ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially conformant.

I am flagging the usage of a requirement followed by the "must ignore" requirement as an issue as the "in other words" suggest that it is a clarification of the first requirement.

Rewritten as a single ought, with explanation, in [2471].

comment:18 Changed 12 months ago by julian.reschke@gmx.de

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 25
Note: See TracTickets for help on using tickets.