The ALPN HTTP Header Field
RFC 7639

Note: This ballot was opened for revision 04 and is now closed.

Alissa Cooper Yes

(Barry Leiba) Yes

(Jari Arkko) No Objection

Comment (2015-06-11 for -04)
No email
send info
ABNF is (has?) been fixed as a part of the Gen-ART review comments from Christer. Make sure these edits are folded in before the draft is approved.

(Alia Atlas) No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

(Benoît Claise) No Objection

Spencer Dawkins No Objection

Comment (2015-06-10 for -04)
No email
send info
I'm a no-objection, because I'm assuming that this specification doesn't also map to CoAP and DTLS. If that's a bad assumption, please tell me, and I'll look at it through those lenses.

In this text,

   The HTTP CONNECT method (Section 4.3.6 of [RFC7231]) requests that
   the recipient establish a tunnel to the identified origin server and
   thereafter forward packets, in both directions, until the tunnel is
   closed.  Such tunnels are commonly used to create end-to-end virtual
   connections, through one or more proxies.
                        ^^^^^^^^^^^
                        
it may be obvious to everyone else how to do this through multiple proxies, and I bet I could guess how given two or three guesses, but I didn't see any description in the document of how to do that. 

Is any description needed?

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-06-29)
No email
send info
Thanks for handling my discuss. 

--- OLD COMMENTS below, I didnt' check 'em.

- I can see situations where I might want to not tell the proxy
what protocol I'll be using inside TLS and when TLS1.3 hides
ALPM from the proxy (I hope:-) then could there be value
registering a "I'm not telling" ALPN value so that a UA
wouldn't have to lie to the proxy?

- I think you ought say what you expect a proxy to do if the
ALPN header field and the ALPN TLS extension value do not match
and I think that ought say that a CONNECT recipient in such
cases SHOULD NOT drop the connection solely on that basis.  If
they have some policy about it fine, but they shouldn't barf
just because there's a different order or spelling or just a
different value.

- Replicating values at multiple protocol layers produces a
common failure mode where code only uses one copy to do access
control or authorization or where two nodes in sequence use
different copies, with unexpected behaviour resulting. I think
you should call that out in the security considerations section
as it keeps happening.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Terry Manderson No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-06-09 for -04)
No email
send info
I support Stephen's discuss and comments.

It looks like the discussion on Stephen's comments addressed the concern I had as a discuss, so I removed that and will follow along with his discuss and comments to address authentication.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection