Original text:
3.1. The protocol defined in this document is identified using the string <del> "HTTP/2.0".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </del>  identification is required. <del> Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics described in this document. </del>  Only implementations of the final, published RFC can identify <del> themselves as "HTTP/2.0".  Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". </del>  <del> Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string.  The exception to this rule is the string included in the connection header sent by clients immediately after establishing an HTTP/2.0 connection (see ConnectionHeader); this fixed length sequence of octets does not change. </del>  Implementations of draft versions of the protocol MUST add the string <del> "-draft-" and the corresponding draft number to the identifier before the separator ('/').  For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0". </del>  Non-compatible experiments that are based on these draft versions <del> MUST instead replace the string "draft" with a different identifier. </del>  For example, an experimental implementation of packet mood-based <del> encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-emo-07/2.0".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </del>  coordinate their experiments on the ietf-http-wg@w3.org mailing list. 3.2.

Reviewer comments:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Revised text:
3.1. The protocol defined in this document is identified using the string  <ins> "h2".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </ins> identification is required.  <ins> Negotiating "h2" implies the use of the transport, security, framing and message semantics described in this document. </ins> Only implementations of the final, published RFC can identify  <ins> themselves as "h2".  Until such an RFC exists, implementations MUST NOT identify themselves using "h2". </ins>  <ins> Examples and text throughout the rest of this document use "h2" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string. </ins> Implementations of draft versions of the protocol MUST add the string  <ins> "-" and the corresponding draft number to the identifier.  For example, draft-ietf-httpbis-http2-09 is identified using the string "h2-09". </ins> Non-compatible experiments that are based on these draft versions  <ins> MUST append the string "-" and a experiment name to the identifier. </ins> For example, an experimental implementation of packet mood-based  <ins> encoding based on draft-ietf-httpbis-http2-09 might identify itself as "h2-09-emo".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </ins> coordinate their experiments on the ietf-http-wg@w3.org mailing list. 3.2.