Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol

On Fri, Mar 27, 2015 at 01:17:35AM +0000, Adrien de Croy wrote:
> 
> Hi Mark
> 
> thanks for explaining this position.  I guess my own reasons for my mail 
> were to dispute claims that the draft did not introduce ambiguity and 
> allowed full description of the protocol stack.
> 
> Whether or not there is appetite for further uses of the header at the 
> current time (e.g. relating to parsing / enforcement), and whether we 
> should preclude future possible uses of it by IMO getting it so badly 
> wrong are 2 independent issues  and I would be interested in learning of 
> proposed usage of the header in its current form by middle-box vendors.
> 
> But even aside from all that, I'm not keen on proliferation of RFCs 
> which are ambiguous, as this tends to lead to interop problems.
> 
> I think it's a perfectly valid desire to wish to indicate what sort of 
> thing is being tunneled for purposes of choosing service levels, however 
> precluding the ability to easily verify a client assertion seems to be 
> dangerous.
> 
> How about defining 2 headers?
> 
> Tunnel-TLS-ALPN to be used if the next layer is TLS
> Tunnel-ALPN if it's not TLS

I've been asking as well to explicitly use the ALPN word instead of
"Protocol" to make it explicit that we were designating the protocol
transported *over* TLS so that we could keep "Tunnel-Protocol" for
later purposes (eg: I don't think that TLS has its own ALPN identifier).

Please Martin, as you can see, the name "Tunnel-Protocol" is extremely
confusing as it uses something generic to indicate something specific.
We've had a lot of confusion on HTTP in the past (eg: content-length
that became ambiguous with compression as it used to designate the
framing for some implementations and the original contents for others).
Let's be clear here.

I'm fine with several proposals, as long as there's the ALPN name in
the header name to indicate that whatever value is advertised must be
a valid, registered ALPN token. Mentionning TLS before as Adrien
suggests would be even better, but I guess that without it we can
still understand that ALPN being TLS-only, TLS is implied.

Thanks,
Willy

Received on Friday, 27 March 2015 06:50:17 UTC