Subject: Fwd: New Version Notification for draft-nottingham-httpbis-alt-svc-00.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Oct 2013 00:57:56 -0700

We talked about using a response header for negotiation last week, a la Alternate-Protocol, and one of my action items was to isolate the Alt-Svc proposal.

This draft is a first cut at proposal. I'm particularly interested on feedback from client implementers on the straw-man interop testing proposal at the bottom.

Cheers,

P.S. Friendlier HTML attached.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-httpbis-alt-svc-00.txt
> Date: 15 October 2013 12:54:42 AM PDT
> To: Mark Nottingham <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-httpbis-alt-svc-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-nottingham-httpbis-alt-svc
> Revision:	 00
> Title:		 HTTP Alternate Services
> Creation date:	 2013-10-14
> Group:		 Individual Submission
> Number of pages: 13
> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-httpbis-alt-svc-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-nottingham-httpbis-alt-svc
> Htmlized:        http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00
> 
> 
> Abstract:
>   This document introduces "alternate services" to allow an HTTP
>   origin's resources to be available at a seperate network location,
>   possibly accessed with a different protocol configuration.
> 
>   It also specifies one means of discovering alternate services, the
>   "Alt-Svc" header field.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Oct 2013 07:42:45 -0400

Mark,

>From a security perspective this is an improvement over
draft-nottingham-http2-encryption.  Is the intent, therefore, to retire
that draft?  It does seem that someone should answer the question, "Why
not use DNS for this?"  There's even a reasonable answer, which is that
because this is a header, you are piggybacking it with data.

Eliot

On 10/15/13 3:57 AM, Mark Nottingham wrote:
> We talked about using a response header for negotiation last week, a
> la Alternate-Protocol, and one of my action items was to isolate the
> Alt-Svc proposal.
>
> This draft is a first cut at proposal. I'm particularly interested on
> feedback from client implementers on the straw-man interop testing
> proposal at the bottom.
>
> Cheers,
>
> > URL:            
> http://www.ietf.org/internet-drafts/draft-nottingham-httpbis-alt-svc-00.txt
> > Status:         
> http://datatracker.ietf.org/doc/draft-nottingham-httpbis-alt-svc
> > Htmlized:       
> http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00
> >
> >
> > Abstract:

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 10:30:09 -0700

> We talked about using a response header for negotiation last week, a la Alternate-Protocol, and one of my action items was to isolate the Alt-Svc proposal.

Brief comment:  You should identify protocols, not URI schemes.
Preferably, that identification should use the same identifiers that
are used in other places.

ALPN (and NPN) deployments currently identify "http/1.1", and there
are strings in the ALPN draft that are also (apparently) in use.  Even
if the "spdy/1" string might not be relevant, I think that "spdy/3" is
widely used.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Oct 2013 11:50:04 -0700

On 15/10/2013, at 4:42 AM, Eliot Lear <[email-masked]> wrote:

> From a security perspective this is an improvement over draft-nottingham-http2-encryption.  Is the intent, therefore, to retire that draft?  

No; that draft will be pared down to just a proposal to use ALPN protocol identifiers in a different way, to achieve the effect of using TLS for "http://" URIs. Should be updated today.

> It does seem that someone should answer the question, "Why not use DNS for this?"  There's even a reasonable answer, which is that because this is a header, you are piggybacking it with data.

And so it has been done.

---

From: Erik Nygren <[email-masked]>
Date: Tue, 15 Oct 2013 15:10:27 -0400

On Tue, Oct 15, 2013 at 7:42 AM, Eliot Lear <[email-masked]> wrote:

>  It does seem that someone should answer the question, "Why not use DNS
> for this?"  There's even a reasonable answer, which is that because this is
> a header, you are piggybacking it with data.
>

Also, the proposal calls out:

     "Potentially, there are many ways that a client could discover the
alternate service(s) associated with an origin; this document currently
defines one, the Alt-Svc HTTP Header Field (Section
3<https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=4eec3a08b8&view=att&th=141bb1ffe146a105&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P-Vj6Fz34Aqfn-A88HAaDut&sadet=1381863805889&sads=n52BEL0aHy8e1yfX6ATY1reYbCA#0.1_alt-svc>
)."
It would seem logical then that DNS could *also* be used for this with the
same alt-svc data schema and semantics, with the values obtained via DNS
and piggybacked with data being merge-able, as per:

     "Note that priorities are not specific to the mechanism that an
alternate was discovered with; i.e., there is only one “pool” of priorities
for an origin."
Piggybacking this with the HTTP response/data may have a lower deployment
barrier than introducing a new DNS RR type, plus there may be some ways of
using this that are not possible via the DNS.

      Erik

>  We talked about using a response header for negotiation last week, a la
> Alternate-Protocol, and one of my action items was to isolate the Alt-Svc
> proposal.
>
> feedback from client implementers on the straw-man interop testing proposal
> at the bottom.
>
> Cheers,
>
> > To: Mark Nottingham <[email-masked]> <[email-masked]>
> >
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Oct 2013 12:22:15 -0700

> are used in other places.

That's the intent. The strings in the draft are just straw men; happy to clarify.

> if the "spdy/1" string might not be relevant, I think that "spdy/3" is

Yes. The upcoming revision to http2-encryption will explore this a bit more. I haven't got hung up on the syntactic form yet; focus is on the semantics of the protocol identifier. 

I.e., shed colour advice gladly taken.

Cheers,