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

From: Barry Leiba <[email-masked]>
Date: Fri, 1 May 2015 10:26:34 +0100

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.

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.)

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?

Barry

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 May 2015 09:39:00 -0700

> Then please correct the URL references [5] (now [1]) and [6] (now [2])

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.

> 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.

> 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.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 1 May 2015 18:14:20 +0000

>   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:[email-masked]] 
Sent: Friday, May 1, 2015 9:39 AM
To: Barry Leiba
Cc: [email-masked]; [email-masked]; HTTP Working Group
Subject: Re: AD Evaluation of draft-ietf-httpbis-tunnel-protocol-03

> Then please correct the URL references [5] (now [1]) and [6] (now [2]) 

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.

        The ALPN header field carries an indication of client intent only.  +++An

2.3.  Usage

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 May 2015 11:26:34 -0700

> 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 overloa…

On the contrary, protocol layers != protocols.

> 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.

Except that if it was over TLS it would be a different thing entirely.

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 02 May 2015 21:02:11 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Mike Bishop" <[email-masked]>
Cc: "Barry Leiba" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>; 
"[email-masked]" 
<[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 2/05/2015 6:26:34 a.m.
Subject: Re: AD Evaluation of draft-ietf-httpbis-tunnel-protocol-03

>>  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!
>
I disagree

IP is a protocol
TCP is a protocol
TLS is a protocol
HTTP is a 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.
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 May 2015 13:08:37 +1000

For quite some time, we've used NPN and ALPN to denote a "protocol stack" - e.g., "h2" vs. "h2c"*.

However, this confusion does still keep coming up. I think what we need here is some explanatory text that spells out how ALPN is being used — and that this text should also turn up in other places that use ALPN like this (such as Alt-Svc).

Cheers,

* See also: <https://github.com/http2/http2-spec/issues/417>

> On 3 May 2015, at 7:02 am, Adrien de Croy <[email-masked]> wrote:
> 
> 
> 
> Cc: "Barry Leiba" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "HTTP Working Group" <[email-masked]>

--
Mark Nottingham   https://www.mnot.net/

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 May 2015 08:49:12 +0100

> However, this confusion does still keep coming up. I think what we need
> here is some explanatory text that spells out how ALPN is being used -- and
> that this text should also turn up in other places that use ALPN like this (such
> as Alt-Svc).

Indeed: all I'm looking for is explanation, not a substantive change.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2015 21:39:26 +0100

Where are we with this?

Barry

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 14:01:02 -0700

> If these make sense, I will merge that branch.

I haven't seen any response to that.  I'm happy to accept that the new
section is not needed, but we are stalling on the issue of what ALPN
__means__ and while I adopt the view I've tried to articulate (and the
one Mark describes), it's not clear that this is the consensus view.
I will defer to my betters on this.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2015 22:27:39 +0100

> I will defer to my betters on this.

I'm OK to go with what you have in that update.  I just wanted to hear
from the doc shepherd.

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 May 2015 14:16:52 +1000

I've left a few editorial-ish notes on the change sets; see:

https://github.com/httpwg/http-extensions/commit/0320e7623976b3b2773df9845879df9b6153199a
https://github.com/httpwg/http-extensions/commit/12fd300c80e1336084c6f102317aba8ec2047ece

Once Martin decides what to do with those, I think we're OK.

Cheers,

> On 13 May 2015, at 7:27 am, Barry Leiba <[email-masked]> wrote:
> 
>>> Where are we with this?
>> 
>> from upthread:
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 May 2015 11:21:58 -0700

> Once Martin decides what to do with those, I think we're OK.

Suggestions accepted and PR merged.  Do you want a revised draft?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 May 2015 14:44:10 -0400

> Suggestions accepted and PR merged.  Do you want a revised draft?

Yes, please.

Barry