RE: AD Evaluation of draft-ietf-httpbis-tunnel-protocol-03

>   The ALPN identifier and registry are used to identify a protocol, not
>   a single protocol layer or component.

This feels like the same issue from the other thread -- this phrasing makes it sound like you mean "protocol" to imply a stack/suite, "not a single protocol layer..."  So now we're not just overloading the ALPN registry, we're overloading the word protocol!

If it's TLS, this header copies the list from the ClientHello field; if it's not TLS, it contains the token that would be in ALPN if the client wanted to negotiate this protocol over TLS.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, May 1, 2015 9:39 AM
To: Barry Leiba
Cc: draft-ietf-httpbis-tunnel-protocol@ietf.org; draft-ietf-httpbis-tunnel-protocol.shepherd@ietf.org; HTTP Working Group
Subject: Re: AD Evaluation of draft-ietf-httpbis-tunnel-protocol-03

On 1 May 2015 at 02:26, Barry Leiba <barryleiba@computer.org> wrote:
> My comments, which I'd like to discuss and sort out before requesting 
> last call on this:
>
> Please remove the Editorial Note right after the Abstract.  The 
> references it makes have already been removed.
>
> Then please correct the URL references [5] (now [1]) and [6] (now [2]) 
> later in the document.

Those are toolchain issues.  Removing the note should fix that.  If you think that removing the note is advisable at this stage, I'll do that.

> I find the document to be confusing for a couple of reasons:
>
> 1. This header field is not used in an ALPN negotiation, right?
> That's not made clear.  The third paragraph of the Introduction is the 
> only thing that says anything about this, and it doesn't say much.  I 
> think you need to be more explicit that this provides information that 
> might/will/must (clarify) be used in an ALPN negotiation, but that the 
> HTTP CONNECT doesn't directly do that.  (In a sense, it seems that 
> calling this "ALPN" is itself the thing that causes confusion.)

Here's what I'm going to propose inserting in the following paragraph

        The ALPN header field carries an indication of client intent only.  +++An
        ALPN identifier is used only for protocol identification. No
        negotiation takes place using this header field.+++  In TLS, the final
        choice of application protocol is made by the server from the set of
        choices presented by the client.  Other protocols could negotiate
        protocols differently.

> 2. It's not at all clear what happens when we don't use TLS.  That 
> same third paragraph in the Introduction is, again, the only mention 
> we have, and it's fluffy about it.  The fourth paragraph in the Intro 
> doesn't shed much more light.
>
> Can you better explain how the contents of this header field are used, 
> both in TLS context and without TLS?

Maybe.  Here's a section that might help:

2.3.  Usage

   For a CONNECT tunnel that consequently uses a protocol that operates
   over TLS, the value of the ALPN header field contains the same list
   of ALPN identifiers that will be sent in the TLS ClientHello message
   [RFC7301].

   Where no protocol negotiation is expected to occur, such as in
   protocols that do not use TLS, the ALPN header field contains the
   single protocol that is intended to be used.  If an alternative form
   of protocol negotiation is possible, the ALPN header field contains
   the set of protocols that might be negotiated.

   The ALPN identifier and registry are used to identify a protocol, not
   a single protocol layer or component.

All of these changes can be reviewed here:
https://github.com/httpwg/http-extensions/compare/barry?expand=1


If these make sense, I will merge that branch.

Received on Friday, 1 May 2015 18:14:54 UTC