Re: HTTP/2, "h2t" and protocol identifiers in general

On 1 March 2014 15:19, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 1/03/2014 3:25 p.m., Matthew Kerwin wrote:
> > On 1 March 2014 11:57, Amos Jeffries wrote:
> >
> >> On 1/03/2014 5:09 a.m., Mark Nottingham wrote:
> >>>
> >>> I'd be OK with "h2" for TLS and something like "h2p" (for "plaintext").
> >>
> >>
> >> FWIW: I prefer the orginal proposal where the 't' signified the
> >> injection of TLS layer between HTTP/2 and TCP.
> >>
> >>
> > And my two cents, because I love painting sheds: I prefer 'h2s' for
> HTTP/2
> > over TLS, for its symmetry with http/https.
> >
>
> I thought about suggesting that, but we are actually wanting to *detach*
> the symmetry.
>
>  => h2t in the proxy cases TLS without meaning HTTPS specifically.
>
>
I suppose so. In that case, does the token have to be quite so short? I
know there was this discussion: <
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0941.html> but
it seems using a single letter after "h2" is a tiny bit of an issue. A
token that could be misinterpreted by a hurried implementer will eventually
cause someone some grief.

Here are my suggestions, in order of preference, and then I'll stop arguing
about paint colour (even though it matches my level of expertise
wonderfully):

1. "h2tls" and "h2tcp" -- these aren't protocol-stack-based identifiers, we
just avoid a default and explicitly differentiate between TLS and just-TCP.
2. "h2" for TCP+HTTP and "h2tls" for TLS -- because HTTP/2 makes no claims
about its transport (and TCP is an internet default), while TLS is an
explicit variation.
3. "h2" for TLS and "h2tcp" for just-TCP -- because TLS is likely going to
be the most common use-case, so it could be a justifiable default.
4. "h2" for TLS and "h2c" for "HTTP/2 in cleartext", in line with @mnot's
earlier suggestion.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/