Subject: feedback on draft-nottingham-httpbis-alt-svc

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 11:59:05 +0100

Looks good to me.

If we need this in HTTP/2 we better adopt this as WG work item ASAP.

It seems to me that having the framework + the HTTP header field in a 
stand-alone document makes sense (even if that doc normatively refs 
HTTP/2 and vice-versa). I volunteer to help editing that document if needed.

Editorial nits:

in some places: s/header/header field/

3.1.  Proposal: Alternate Services

    NOTE: This section can be incorporated into HTTP/2 directly, or it
    can be published as a standalone specification.  However, if
    Section 3.3 is accepted, it will need to be included or referenced
    from the spec, since frame type extensibility has been ruled out.

    This specification defines a new concept in HTTP, the "alternate
    service."  When an origin (see [RFC6454] has resources are accessible

s/service."/service"./
s/[6454]/[6454])/
s/has resources are/has resources that/

    Therefore, if a client becomes aware of an alternate service, the
    client SHOULD use that alternate service for all requests to the
    associated origin as soon as it is available, provided that the
    security properties of the alternate service protocol are desirable,
    as compared to the existing connection.

"is optional" and "SHOULD use" is kind of inconsistent...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Mar 2014 11:19:45 +0000

What do other folks think about this? 

Personally, I’m OK either way, although it may be more expedient to keep it separate (i.e., only move over the frame type and other HTTP/2 specific bits). 

Thanks for the offer Julian, I may take you up on that. Or, should I say, MAY.

Cheers,

On 6 Mar 2014, at 10:59 am, Julian Reschke <[email-masked]> wrote:

> It seems to me that having the framework + the HTTP header field in a stand-alone document makes sense (even if that doc normatively refs HTTP/2 and vice-versa). I volunteer to help editing that document if needed.
> 
> 
> Editorial nits:
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 12:35:15 +0100

> Personally, I’m OK either way, although it may be more expedient to keep it separate (i.e., only move over the frame type and other HTTP/2 specific bits).

Isn't that what I proposed?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Mar 2014 11:36:59 +0000

> Isn't that what I proposed?

Yes; I’m asking what other people think. I know that it *seemed* like it was just you, me and Roy for some time, but things have apparently changed...

---

From: Roberto Peon <[email-masked]>
Date: Thu, 6 Mar 2014 03:48:55 -0800

If it is needed to help with the issue of load rebalancing, then it needs
to be referred to from within the http/2 spec.
Personally, I see alt-svc as an elegant way of solving a few problems at
the same time, and so believe it is important to be able to talk about from
the HTTP/2 spec.

So, it depends on the schedule for the document as compared to http/2 and
how we tie up other aspects, I guess..
If we could assume that an alt-svc doc would get done before http/2, having
it mostly as a separate doc would be preferable I think?
-=R

On Thu, Mar 6, 2014 at 3:36 AM, Mark Nottingham <[email-masked]> wrote:

> >> Personally, I'm OK either way, although it may be more expedient to
> keep it separate (i.e., only move over the frame type and other HTTP/2
> specific bits).
> >
> Yes; I'm asking what other people think. I know that it *seemed* like it
> was just you, me and Roy for some time, but things have apparently
> changed...
>
>
> >

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 13:41:24 +0000

> how we tie up other aspects, I guess..

Unless we want to rewind on some of the decisions we've made, I only
see two options:

1. Make Alt-Svc a normative reference of HTTP/2, effectively including
its contents by reference, much as we are doing with HPACK.
2. Inline Alt-Svc.

In both cases, we don't get to publish HTTP/2 until Alt-Svc is done.

I know that we are trying to ensure that inlining doesn't happen, but
I think that in this case, there is an advantage to it.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 14:43:38 +0100

> I think that in this case, there is an advantage to it.

That's why I was bringing it up. Let's decide this ASAP; I believe if we 
do it we can have a separate document ready early enough.

Best regards, Julian

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 6 Mar 2014 05:53:45 -0800

When we say we want to do this, does that mean we have to put in Section
3.6 [1] too in the HTTP/2 spec or something normatively referenced?

[1]:
http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-3.6("Proposal:
Discovery of TLS Support for http://URIs")

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 15:00:49 +0100

On 2014-03-06 14:53, William Chan (陈智昌) wrote:
> http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-3.6
> ("Proposal: Discovery of TLS Support for http:// URIs")

Would you be ok with it if there was no requirement to implement it?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 14:00:08 +0000

On 6 March 2014 13:53, William Chan (陈智昌) <[email-masked]> wrote:
> When we say we want to do this, does that mean we have to put in Section 3.6
> [1] too in the HTTP/2 spec or something normatively referenced?

As I understand it, we more or less agreed to the header field, the
frame and the not authoritative error/status code.  I don't think that
there was strong enough agreement regarding Section 3.6, but I'll let
Mark rule on that, maybe after some discussion.

I believe that the changes would touch a number of sections in the
draft, regardless of whether it's inlined or not.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 14:04:09 +0000

> Would you be ok with it if there was no requirement to implement it?

I think that this would absolutely have to be optional.  I don't think
that we can realistically force implementations to do things with
Alt-Svc.

The big question on Section 3.6, to me, is whether we need to actively
*forbid* or discourage its use.  Otherwise, I think that you end up
with it happening as a byproduct of the other functions that Alt-Svc
defines.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 6 Mar 2014 14:13:16 +0000

> that we can realistically force implementations to do things with
As I mentioned at the mic yesterday - due to the asynchronous nature (both
in terms of time and network topology) of Alt-Svc any kind of requirement
is unenforceable in the same way that Priority is unenforceable. So no
matter your feelings on the efficacy of the approach, there is no reason to
put requirement langauge around it beyond the implicit must parse, must not
panic, etc..

---

From: Patrick McManus <[email-masked]>
Date: Thu, 6 Mar 2014 14:15:27 +0000

On Thu, Mar 6, 2014 at 2:13 PM, Patrick McManus <[email-masked]>wrote:

> in terms of time and network topology) of Alt-Svc
>

better described as asynchronous and information asymmetric.. my lexicon
failed me.

---

From: Rob Trace <[email-masked]>
Date: Fri, 7 Mar 2014 09:22:53 +0000

I would prefer that Alt-Svc is a separate document.  I think that this is a large add to the base spec where we are trying to close down issues.  I know it is not popular, but I would also be favorable to revisiting the previous discussions about extensibility, again with the caveat that there is a simple model which would not require a major overhaul of the spec.

Regardless of where it is documented, Alt-Svc needs to be optional.  This is both for Alt-Svc as a whole and for the various pieces like TLS for HTTP URIs.

Thanks!!

-Rob

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, March 6, 2014 1:41 PM
To: Roberto Peon
Cc: Mark Nottingham; Julian F. Reschke; HTTP Working Group
Subject: Re: feedback on draft-nottingham-httpbis-alt-svc

On 6 March 2014 11:48, Roberto Peon <[email-masked]> wrote:
> So, it depends on the schedule for the document as compared to http/2 
> and how we tie up other aspects, I guess..

Unless we want to rewind on some of the decisions we've made, I only see two options:

1. Make Alt-Svc a normative reference of HTTP/2, effectively including its contents by reference, much as we are doing with HPACK.
2. Inline Alt-Svc.

I know that we are trying to ensure that inlining doesn't happen, but I think that in this case, there is an advantage to it.