Subject: Re: [IANA #801638] Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jan 2015 10:16:46 -0800

Thanks Pearl,

I assume that the "NOT OK" refers to the need for expert review.  Or
are you concerned about us requesting a specific number (421) for the
last action?

On 13 January 2015 at 09:50, Pearl Liang via RT
<[email-masked]> wrote:
> a new method will be registered as follows:
>
> Method Name: PRI
> Safe: No
> Idempotent: No
> Reference: [ RFC-to-be ]
>
> Question: just to double check if the new requested method "PRI" is an abbreviation.
> It appears that RFC7231 does not require a full name.

That is correct.  Method names don't require a full name.  In this
case, a full name could be confusing, since this is a defensive
registration only.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 13 Jan 2015 15:37:06 -0800

It should be registered as safe and idempotent (YES to both).

....Roy

> On Jan 13, 2015, at 10:16 AM, Martin Thomson <[email-masked]> wrote:
> 
> Thanks Pearl,
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 14 Jan 2015 21:48:52 +1300

> It should be registered as safe and idempotent (YES to both).

Disagree.

Idempotent requires being repeatable. The client is permitted by
HTTP/2 to pipeline many requests immediately which may affect the
server state with HTTP/2 non-idempotent messages before the initial
SETTINGS arrives from server. PRI is only retriable if the server
response is an HTTP/1.x format error message indicating an h2 server
never got the HTTP/2 payload.

Safe requires no effect on the server, and implies cacheability. As
above the simple act of delivering PRI and some initial payload bytes
can be an entire HTTP/2 transaction for an unsafe method. Neither is
the server response (in HTTP/2 format) to this message cacheable.

Amos

> 
>> On Jan 13, 2015, at 10:16 AM, Martin Thomson wrote:
>> 
>> Thanks Pearl,
>> 
>> I assume that the "NOT OK" refers to the need for expert review.
>> Or are you concerned about us requesting a specific number (421)
>> for the last action?
>> 
>>> Method Name: PRI Safe: No Idempotent: No Reference: [ RFC-to-be
>>> ]
>>> 
>>> Question: just to double check if the new requested method
>>> "PRI" is an abbreviation. It appears that RFC7231 does not
>>> require a full name.
>> 
>> That is correct.  Method names don't require a full name.  In
>> this case, a full name could be confusing, since this is a
>> defensive registration only.
>> 
>

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Tue, 13 Jan 2015 19:55:29 +0000

Hi Martin,

> are you concerned about us requesting a specific number (421) for the

Yes, the former.  If you have already received the approval from the designated 
experts, respectively, please let us know.

> case, a full name could be confusing, since this is a defensive

AOK.  Btw, that is not the reason for IANA not okay.

Thanks,
~pl

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Tue, 13 Jan 2015 17:51:34 +0000

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-http2-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are eight actions which must be completed.

IANA has questions about some of the requested actions that require Expert Review 
according to the relevant defining RFCs.

First, in the Application-Layer Protocol Negotiation (ALPN) Protocol IDs subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values/

two new protocol IDs will be registered as follows:

Protocol: HTTP/2 over TLS
Identification Sequence: 0x68 0x32 ("h2")
Reference: [ RFC-to-be ]

Protocol: HTTP/2 over TCP
Identification Sequence: 0x68 0x32 0x63 ("h2c")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new entry is created in the IANA matrix located at:

https://www.iana.org/protocols

called "Hypertext Transfer Protocol (HTTP) 2 Parameters"  

Third, in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Frame Type registry. Maintainence of the registry for values 0x00 and 0xef is done via IETF Review or IESG Approval as defined by RFC 5226. Values between 0xf0 and 0xff are reserved for experimental use.

There are initial values in this new registry as follows:

+---------------+------+----------------+
| Frame Type    | Code | Reference      |
+---------------+------+----------------+
| DATA          | 0x0  | [ RFC-to-be ]  |
| HEADERS       | 0x1  | [ RFC-to-be ]  |
| PRIORITY      | 0x2  | [ RFC-to-be ]  |
| RST_STREAM    | 0x3  | [ RFC-to-be ]  |
| SETTINGS      | 0x4  | [ RFC-to-be ]  |
| PUSH_PROMISE  | 0x5  | [ RFC-to-be ]  |
| PING          | 0x6  | [ RFC-to-be ]  |
| GOAWAY        | 0x7  | [ RFC-to-be ]  |
| WINDOW_UPDATE | 0x8  | [ RFC-to-be ]  |
| CONTINUATION  | 0x9  | [ RFC-to-be ]  |
+---------------+------+----------------+

Fourth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Settings Registry. Maintenance of the registry for values 0x0000 to 0xefff is done through Expert Review as defined in RFC 5226. Values between 0xf000 and 0xffff are reserved for experimental use.

There are initial registrations in the new registry as follows:

+------------------------+------+---------------+---------------+
| Name                   | Code | Initial Value | Reference     |
+------------------------+------+---------------+---------------+
| HEADER_TABLE_SIZE      | 0x1  | 4096          | [ RFC-to-be ] |
| ENABLE_PUSH            | 0x2  | 1             | [ RFC-to-be ] |
| MAX_CONCURRENT_STREAMS | 0x3  | (infinite)    | [ RFC-to-be ] |
| INITIAL_WINDOW_SIZE    | 0x4  | 65535         | [ RFC-to-be ] |
| MAX_FRAME_SIZE         | 0x5  | 16384         | [ RFC-to-be ] |
| MAX_HEADER_LIST_SIZE   | 0x6  | (infinite)    | [ RFC-to-be ] |
+------------------------+------+---------------+---------------+

Fifth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Error Code registry. Maintenance of the registry is done through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------------------+------+----------------------+---------------+
| Name                | Code | Description          | Reference     |
+---------------------+------+----------------------+---------------+
| NO_ERROR            | 0x0  | Graceful shutdown    | [ RFC-to-be ] |
| PROTOCOL_ERROR      | 0x1  | Protocol error       | [ RFC-to-be ] |
|                     |      | detected             |               |
| INTERNAL_ERROR      | 0x2  | Implementation fault | [ RFC-to-be ] |
| FLOW_CONTROL_ERROR  | 0x3  | Flow control limits  | [ RFC-to-be ] |
|                     |      | exceeded             |               |
| SETTINGS_TIMEOUT    | 0x4  | Settings not         | [ RFC-to-be ] |
|                     |      | acknowledged         |               |
| STREAM_CLOSED       | 0x5  | Frame received for   | [ RFC-to-be ] |
|                     |      | closed stream        |               |
| FRAME_SIZE_ERROR    | 0x6  | Frame size incorrect | [ RFC-to-be ] |
| REFUSED_STREAM      | 0x7  | Stream not processed | [ RFC-to-be ] |
| CANCEL              | 0x8  | Stream cancelled     | [ RFC-to-be ] |
| COMPRESSION_ERROR   | 0x9  | Compression state    | [ RFC-to-be ] |
|                     |      | not updated          |               |
| CONNECT_ERROR       | 0xa  | TCP connection error | [ RFC-to-be ] |
|                     |      | for CONNECT method   |               |
| ENHANCE_YOUR_CALM   | 0xb  | Processing capacity  | [ RFC-to-be ] |
|                     |      | exceeded             |               |
| INADEQUATE_SECURITY | 0xc  | Negotiated TLS       | [ RFC-to-be ] |
|                     |      | parameters not       |               |
|                     |      | acceptable           |               |
| HTTP_1_1_REQUIRED   | 0xd  | Use HTTP/1.1 for the | [ RFC-to-be ] |
|                     |      | request              |               |
+---------------------+------+----------------------+---------------+

Sixth, in the Permanent Message Header Field Registry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/

a new header field will be registered as follows: 

Header Field Name: HTTP2-Settings
Template: 
Protocol: http
Status: Standard
Reference: [ RFC-to-be ]

This registry is maintained via Expert Review and Expert review will need to be completed for this registration before your document can be approved for publication as an RFC.

Seventh, in the Hypertext Transfer Protocol (HTTP) Method Registry located at:

http://www.iana.org/assignments/http-methods/

Method Name: PRI
Safe: No
Idempotent: No
Reference: [ RFC-to-be ]

Eighth, in the Hypertext Transfer Protocol (HTTP) Status Code Registry located at:

http://www.iana.org/assignments/http-status-codes/

a new status code will be registered as follows:

Value: 421
Description: Misdirected Request
Reference: [ RFC-to-be ]

IANA understands that these eight actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.  

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. 

Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)

On Wed Dec 31 15:31:14 2014, [email-masked] wrote:
> 
> The IESG has received a request from the Hypertext Transfer Protocol WG
> (httpbis) to consider the following document:
> - 'Hypertext Transfer Protocol version 2'
>   <draft-ietf-httpbis-http2-16.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-01-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This specification describes an optimized expression of the semantics
>    of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more
>    efficient use of network resources and a reduced perception of
>    latency by introducing header field compression and allowing multiple
>    concurrent messages on the same connection.  It also introduces
>    unsolicited push of representations from servers to clients.
> 
>    This specification is an alternative to, but does not obsolete, the
>    HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>    http://datatracker.ietf.org/ipr/1737/
>    http://datatracker.ietf.org/ipr/2122/
>    http://datatracker.ietf.org/ipr/1692/
>    http://datatracker.ietf.org/ipr/2506/
> 
> 
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 14 Jan 2015 11:40:10 -0800

On Jan 14, 2015, at 12:48 AM, Amos Jeffries wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

The other requests are not part of the PRI method, which is just
being used to snowplow the connection.  The same snowplowing is
done every time the client opens a new connection to the server.
Hence, the request is repeated and has the same effect every time.

> Safe requires no effect on the server, and implies cacheability.

Neither of those assumptions is true, and in any case the PRI
method being defined does nothing and contains nothing.  Whatever
else that is sent on the connection after the initial PRI message
is irrelevant to the semantics of the PRI message, which is to do
nothing but cause an abort (hopefully with 405) from non-compliant
recipients.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 15 Jan 2015 14:58:37 +1300

On 15/01/2015 8:40 a.m., Roy T. Fielding wrote:
>> HTTP/2 to pipeline many requests immediately which may affect
>> the server state with HTTP/2 non-idempotent messages before the
>> initial SETTINGS arrives from server. PRI is only retriable if
>> the server response is an HTTP/1.x format error message
>> indicating an h2 server never got the HTTP/2 payload.
> 

- From the HTTP/1.1 perspective they are part of its payload, just like
an hypothetical implementation that does not understand CONNECT would
treat the tunnel data as part of that methods payload.

4.2.1. Safe Methods
"
   Of the request methods defined by this specification, the GET, HEAD,
   OPTIONS, and TRACE methods are defined to be safe.
"

Note how CONNECT is not listed as safe. It is likewise omitted from
the idempotent list.

> method being defined does nothing and contains nothing.

- From a naive HTTP/1.1 servers perspective it "contains" the entire
HTTP/2 data stream, just like a CONNECT "contains" ("switches to" if
you prefer) whatever arbitrary protocol is in the tunnel. Due to
(correct) lack of Content-Length header in the magic.

As to my statement,
4.2.1. Safe Methods
"
   ... the client does not request, and does
   not expect, any state change on the origin server as a result of
   applying a safe method to a target resource.
...
   The purpose of distinguishing between safe and unsafe methods is to
   allow automated retrieval processes (spiders) and cache performance
   optimization (pre-fetching) to work without fear of causing harm.
"

target resource of PRI parses as being the server ("*").

To avoid breaking whatever was going on well behaved interception
intermediaries are required to accept any request with a conforming
request-line (which this is) and relay unknown ones to the destination
server.

> Whatever else that is sent on the connection after the initial PRI
> message is irrelevant to the semantics of the PRI message, which is
> to do nothing but cause an abort (hopefully with 405) from
> non-compliant recipients.

A only 1.1-compliant recipient will abort it due to 405 or 505
conditions on arrival. Safe and Idempotent situations will never be
reached.

The unsafe/non-idempotent is for intermediaries in the naive case
which relay unknown request-lines transparently to a server. This may
be from admin configuration on forward/reverse proxies or TCP IP
details on interceptors.
 In that case HTTP/1.1 headers (ie Transfer-Encoding:chunked) and
version label may be added by the intermediary. Which immediately
breaks any receiving 1.1 implementations from being able to 405/505
the method.

The intent when I requested this get registered was to aid HTTP/1
implementers who see it as a method occuring but not implementing or
understanding enough HTTP/2 to handle it correctly. There is a lot of
complex (and useless) code pathways that can be simply skipped in
HTTP/1 implementations only if it is treated as both Unsafe and
non-Idempotent. All of which aids HTTP/2 performance and transit over
non-HTTP/2 aware intermediaries.
 ** The cases where it can be treated as safe or idempotent without
side effects by an intermediary require developers have enough HTTP/2
knowledge to safely identify those cases and do the processing properly.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Jan 2015 13:14:24 -0800

> It should be registered as safe and idempotent (YES to both).

Tracked at https://github.com/http2/http2-spec/issues/682

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 23 Jan 2015 14:13:18 -0800

> treat the tunnel data as part of that methods payload.

No, it wouldn't, since the request message framing is not method
dependent.  The request message ends at the blank line.

> Note how CONNECT is not listed as safe. It is likewise omitted from

That's because the semantics of tunnels are not defined to be safe
nor idempotent.  They are simply unknown.  PRI (as used in the h2
preface at "http://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-3.5")
is known to be both and depends upon it being safe and idempotent.

> (correct) lack of Content-Length header in the magic.

*sigh* ... RFC7230, sec 3.3:

   The presence of a message body in a request is signaled by a
   Content-Length or Transfer-Encoding header field.  Request message
   framing is independent of method semantics, even if the method does
   not define any use for a message body.

> request-line (which this is) and relay unknown ones to the destination

Interception intermediaries do not implement HTTP.

The asterisk-form "*" is not used in HTTP/1.1 for anything other than
OPTIONS (Section 5.3 of [RFC7230]).  But that doesn't matter in this case
because the protocol is HTTP/2.0 and there is no "destination server"
other than the IP address (no Host, no full URI, nowhere else to go).
If the intermediary is smart enough to have read the HTTP method
registration flag for a previously unknown method and to make code
pathway assumptions based on that, then it had better be looking at
the protocol version as well (since method semantics can be changed
with major protocol revisions).

> which relay unknown request-lines transparently to a server.

No.  While that may be your focus and why you choose to interpret
their use, the definitions have no dependency at all on intermediaries.
An intermediary must relay unknown methods unless it has been specifically
configured not to do so, regardless of the safe or idempotent flags,
because failing to do so will block extensibility.  That has no relevance
to an intermediary that does know the PRI method well enough to know
whether it has been flagged as safe, in which case it would be absolutely
moronic for said implementation to go ahead and forward it given that
the message it is forwarding is not even HTTP/1.1.

> This may

Honestly, I can't begin to explain how many other things that would break.
Generally speaking, intermediaries that make shit up when forwarding
request messages for which they don't even speak the protocol are already so
hopelessly broken that I would rather have the data center catch fire
and explode than attempt to rationalize their existence.

> knowledge to safely identify those cases and do the processing properly.

The method is being registered as a defense against others using the
same method name for something totally different.  This is reserving the
name.  It isn't going to be registered incorrectly just because of a
code pathway that theoretically might exist on some future not-yet-implemented
and non-HTTP-compliant interception proxy.  The obvious fix for such a
code pathway is the HTTP-version, rather than falsely stating the simple
answers to the two mathematical definitions in the out-of-band registration
flags of a method that is never supposed to be implemented.

....Roy