- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 25 Oct 2013 05:50:57 +1300
- To: ietf-http-wg@w3.org
On 24/10/2013 11:25 a.m., Andrei Popov wrote:
> I totally agree that the name of the HTTP protocol is all uppercase, and this is how this protocol is named in the ALPN protocol IDs registry:
> "Protocol: HTTP/1.1".
>
> ALPN protocol IDs, on the other hand, are opaque octet strings, not intended for display to the user, not required to consist of printable characters, not required to match names of protocols. E.g. 0x01 could be a valid ALPN protocol ID.
Than please make it opaque and not something that to the human eye reads
like a invalid protocol token from the IANA protocol registry.
> In the early days of ALPN, a combination of printable characters happened to be chosen as the protocol ID for HTTP/1.1:
> "Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")".
"early days" wow. All of 12 months ago.
Which consultation process made that decision BTW?
* it does not appear to have included the official HTTP protocol HTTPbis
working group.
* neither does it seems to have involved anyone from IANA, since they
would likely have pointed you at the official registry of standardized
protocol names http://www.ietf.org/assignments/service-names/ - this is
THE list of protocols.
> The use of printable characters has some advantages (sometimes makes network capture analysis easier) and disadvantages (may result in more bytes on the wire).
Are you trying to say "HTTP" are not equally printable characters to the
ones chosen, without sounding like an idiot?
> We may now wish that a different protocol ID had been chosen, we may even register alternative protocol IDs for HTTP/1.1. However, an interoperable implementation will have to keep sending the old protocol ID for years to come.
Completely wrong. Handle the old specifiers from experimental ALPN draft
implementers as you would future undefined or unsupported protocol tags,
and upgrade the implementations to conform to whatever ALPN documents
becomes an RFC.
You are going to have to do that anyway. Yet seem to be treating this as
if Draft status means the document is set in stone. If the
implementations can't handle changes they are already broken.
> Based on this, I believe that registering alternative protocol IDs for HTTP/1.1 will create more confusion and inefficiency than keeping the current (possibly imperfect) protocol ID.
... and that is exacty what is being doing with this new lower-cased
protocol name which differs from how things have been done for 20 years
or more.
Amos
Received on Thursday, 24 October 2013 16:51:28 UTC