Subject: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 11:54:59 -0700

There was some discussion about this at the IETF89 httpbis session, and I
see that there's an altsvc branch in the github http2 repo (
https://github.com/http2/http2-spec/commits/altsvc) with a commit (
https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99)
that marks this draft as a normative reference.

I wanted to doublecheck what peoples' thoughts on this matter were. I feel
like there was some form of rough consensus assessed in the session,
although the exact details were very ambiguous to me. Currently the alt-svc
draft lists 4 use cases that could be addressed with various proposals:

(1) Upgrading HTTP/1 (" The first use case for Alternate Services is
upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without
the use of SSL or TLS).") as an alternative to HTTP Upgrade.
(2) Using TLS with http:// URIs
(3) Mitigating Load Asymmetry
(4) Segmenting Clients that Support TLS SNI

There are two mechanisms proposed for addressing these use cases. They are
the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.

My personal gauge of the rough consensus at the IETF89 httpbis session was
there was rough consensus for meeting use cases (3) and (4), both of which
require the ALTSVC frame, but not the Alt-Svc response header. Furthermore,
I think there was rough consensus around incorporating the ALTSVC frame
directly into the core HTTP/2 spec, although I remember Rob's disagreement
here (thinking that we should bring back extensible frames, and if that
doesn't get in, we use should MAY rather than SHOULD in the spec as to how
clients should handle this advisory frame).

I think that use case (1) did not get discussed at all, and (2) got raised
very briefly by Pat, but tabled due to lack of time. Both these use cases
rely on the Alt-Svc HTTP response header. I therefore do not believe
there's a rough consensus on including the Alt-Svc HTTP response header.
But perhaps further discussion will reach such a consensus.

I'd like to hear thoughts from folks on, what parts of the alt-svc draft
would be acceptable for inclusion in the HTTP/2 core spec or as a normative
reference.

FWIW, my thought would be to include the ALTSVC frame in the core spec,
with a normative reference to a standalone specification of section 3.1 in
the alt-svc draft.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Mar 2014 20:52:57 +0100

On 2014-03-19 19:54, William Chan (陈智昌) wrote:
> There was some discussion about this at the IETF89 httpbis session, and
> I see that there's an altsvc branch in the github http2 repo
> (https://github.com/http2/http2-spec/commits/altsvc) with a commit
> (https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99)
> I wanted to doublecheck what peoples' thoughts on this matter were. I
> feel like there was some form of rough consensus assessed in the
> session, although the exact details were very ambiguous to me. Currently
> the alt-svc draft lists 4 use cases that could be addressed with various
> proposals:
>
> There are two mechanisms proposed for addressing these use cases. They
> are the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.
>
> My personal gauge of the rough consensus at the IETF89 httpbis session
> was there was rough consensus for meeting use cases (3) and (4), both of
> which require the ALTSVC frame, but not the Alt-Svc response header.
> Furthermore, I think there was rough consensus around incorporating the
> ALTSVC frame directly into the core HTTP/2 spec, although I remember
> Rob's disagreement here (thinking that we should bring back extensible
> frames, and if that doesn't get in, we use should MAY rather than SHOULD
> in the spec as to how clients should handle this advisory frame).
>
> I think that use case (1) did not get discussed at all, and (2) got
> raised very briefly by Pat, but tabled due to lack of time. Both these
> use cases rely on the Alt-Svc HTTP response header. I therefore do not
> believe there's a rough consensus on including the Alt-Svc HTTP response
> header. But perhaps further discussion will reach such a consensus.

I recall that we discussed it, both at the meeting and here on the 
mailing list. The response header field is advisory; no client will be 
required to honor it.

> would be acceptable for inclusion in the HTTP/2 core spec or as a
> normative reference.
>
> with a normative reference to a standalone specification of section 3.1
> in the alt-svc draft.

I believe we had reached rough consensus to include the header field as 
well; but it's good that you are bringing this up now.

Best regards, Julian

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Mar 2014 16:09:04 -0400

Hey Will -

My understanding of consensus was that the frame was to be done in the core
document and the header/error code would be referred to separately and
Julian would edit that document. The split is mostly because the
header/error-code are not wire protocol bits for http/2. There are not MUST
requirements around honoring them other than not SESSION-ERRORing when you
parse them.

I think you'll find you need the header to adequately address the SNI case
if you'd like to do that discovery from plaintext http/1 - a likely case if
SNI is the blocker to effectively hosting https://.

More pertinent of course is the fact that this is one plan for
bootstrapping http/2 - and if its going to be used, like upgrade which I
consider far messier, it should be documented to get consistency among
those parties that wish to use it.

-P

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Mar 2014 13:11:45 -0700

> well; but it's good that you are bringing this up now.

I don't believe that we need to make a normative dependency on a
header field definition.  The existence (or absence) of a header field
shouldn't block progress on the frame definition.

That said, it's unclear to me whether a decoupling like this will have
any material impact on anything.  The hardest part of this work is in
defining what it means to add a new route to a given
origin/authority/server; the mechanical process of representing that
on the wire is pretty trivial.

I guess the concern here is the larger one: what is permitted to
re-route to what.  I would have thought that to be largely client
policy controlled, but I'm happy to have that discussion if people
feel like a standard should be setting this policy.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 13:15:38 -0700

On Wed, Mar 19, 2014 at 1:09 PM, Patrick McManus <[email-masked]>wrote:

> Hey Will -
>
> My understanding of consensus was that the frame was to be done in the
> core document and the header/error code would be referred to separately and

I hadn't thought it through to be honest. I was mostly trusting y'all in
your draft:
http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-2.4says

"This use case can be met if Section 3.1 and Section 3.3 are accepted"

Note that Section 3.3 is the ALTSVC frame. Section 3.2, which was not
mentioned here, is the HTTP Alt-Svc response header.

> On Wed, Mar 19, 2014 at 2:54 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> feel like there was some form of rough consensus assessed in the session,
>> ALTSVC frame directly into the core HTTP/2 spec, although I remember Rob's
>> disagreement here (thinking that we should bring back extensible frames,
>> and if that doesn't get in, we use should MAY rather than SHOULD in the
>> spec as to how clients should handle this advisory frame).
>>
>> raised very briefly by Pat, but tabled due to lack of time. Both these use
>> cases rely on the Alt-Svc HTTP response header. I therefore do not believe

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 13:18:21 -0700

On Wed, Mar 19, 2014 at 1:15 PM, William Chan (陈智昌)
<[email-masked]>wrote:

>> I think you'll find you need the header to adequately address the SNI
>> case if you'd like to do that discovery from plaintext http/1 - a likely
>> case if SNI is the blocker to effectively hosting https://.
>>
>
Oops, I missed responding to this part. My understanding is that Rob was
the main person looking to upgrading from HTTP/1.1 to HTTP/2 in cleartext,
and that they prefer HTTP Upgrade. So if you're including this for his
benefit, I think that may have been a mistake. But I should let Rob speak
for himself.

>
>>
>> -P
>>
>> On Wed, Mar 19, 2014 at 2:54 PM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>
>>> I see that there's an altsvc branch in the github http2 repo (
>>> upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e.,
>>> without the use of SSL or TLS).") as an alternative to HTTP Upgrade.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 13:23:45 -0700

> on the wire is pretty trivial.

I agree that we don't need to make a normative dependency on a header field
definition. My interest in removing this as a normative dependency is
because many people are confused about the HTTP/2 spec explicitly defining
how to do TLS for http:// URIs. Yet, my feeling is that some/many/dunno of
us don't want to block the HTTP/2 spec on this, and want to decouple that.
Therefore, I think we should discuss explicitly decoupling that from what
we're depending on in HTTP/2.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Mar 2014 16:44:14 -0400

On Wed, Mar 19, 2014 at 4:18 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> On Wed, Mar 19, 2014 at 1:15 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

I wasn't trying to suggest this should subsume upgrade for Rob's case - I
was trying, perhaps unclearly, to highlight the analogy between alt-svc and
upgrade and for that matter ALPN too. Upgrade is one method for
bootstrapping http/2 that we expect will be used in the wild and (even
though you and I don't intend to implement it). It does, imo. make sense to
document it so that those interested can have an interoperable definition.

The same can be said of ALPN and Alt-Svc.

I don't think you'll find the next alt-svc document particularly
threatening to the schedule - the header is just a different serialization
of the frame and importantly it also includes a necessary error code which
is relevant to resolving issues when following the frame as well as the
header.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Mar 2014 21:46:13 +0100

On 2014-03-19 21:23, William Chan (陈智昌) wrote:
> ...
> I agree that we don't need to make a normative dependency on a header
> field definition. My interest in removing this as a normative dependency
> is because many people are confused about the HTTP/2 spec explicitly
> defining how to do TLS for http:// URIs. Yet, my feeling is that
> some/many/dunno of us don't want to block the HTTP/2 spec on this, and
> want to decouple that. Therefore, I think we should discuss explicitly
> decoupling that from what we're depending on in HTTP/2.
> ...

Again, the header field can be used by a server to indicate an 
alternative service. There is (or shouldn't be) any requirement to honor it.

Would you feel better if the header field would be in yet another spec?

Best regards, Julian

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 14:05:42 -0700

On Wed, Mar 19, 2014 at 1:46 PM, Julian Reschke <[email-masked]>wrote:

> Again, the header field can be used by a server to indicate an alternative
> service. There is (or shouldn't be) any requirement to honor it.
>

Sorry, I guess I wasn't explicit enough. Yes. I'd feel better if it were in
a spec that weren't listed as a normative reference from within HTTP/2. I
suspect this is the reason that people are confused about whether or not
HTTP/2 supports opportunistic encryption. That and Mark's blogpost [1]
which says: "Based on Patrick’s implementation experience as well as the
impetus of the STRINT discussion, HTTPbis agreed in London to incorporate —
but not require support for — opportunistic encryption in HTTP/2, based
upon the Alternate Services approach." I don't remember any consensus for
this, and therefore, I wanted to explicitly discuss this on the mailing
list to clarify. Because, as Mark also notes in the same blogpost, we
discussed it very extensively and inconclusively in Zurich. And when Pat
raise it up as a topic of discussion in London, I recall Mark explicitly
tabling the topic in order to move on. So I don't want us to accidentally
rewrite consensus here. If we're going to explicitly make HTTP/2
incorporate opportunistic encryption, let's explicitly agree to do so. Not
just accidentally because it's part of a document that's normatively
referenced.

[1] - http://www.mnot.net/blog/2014/03/17/trying_out_tls_for_http_urls

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 11:17:41 +1100

On 20 Mar 2014, at 5:54 am, William Chan (陈智昌) <[email-masked]> wrote:

> There was some discussion about this at the IETF89 httpbis session, and I see that there's an altsvc branch in the github http2 repo (https://github.com/http2/http2-spec/commits/altsvc) with a commit (https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99) that marks this draft as a normative reference.

There's also a revised httpbis-alt-svc in the works:
  https://github.com/mnot/I-D/tree/master/httpbis-alt-svc

... which you really need to read when looking at that branch.

Neither has yet been brought to the WG; I'm still working on them in consultation with Martin, Patrick and Julian (but almost done).

> I wanted to doublecheck what peoples' thoughts on this matter were. I feel like there was some form of rough consensus assessed in the session, although the exact details were very ambiguous to me. Currently the alt-svc draft lists 4 use cases that could be addressed with various proposals:
> 
> (1) Upgrading HTTP/1 (" The first use case for Alternate Services is upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without the use of SSL or TLS).") as an alternative to HTTP Upgrade.
> There are two mechanisms proposed for addressing these use cases. They are the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.
> 
> My personal gauge of the rough consensus at the IETF89 httpbis session was there was rough consensus for meeting use cases (3) and (4), both of which require the ALTSVC frame, but not the Alt-Svc response header. Furthermore, I think there was rough consensus around incorporating the ALTSVC frame directly into the core HTTP/2 spec, although I remember Rob's disagreement here (thinking that we should bring back extensible frames, and if that doesn't get in, we use should MAY rather than SHOULD in the spec as to how clients should handle this advisory frame).
> 
> I think that use case (1) did not get discussed at all

Correct. I suspect we'll get to that, if the folks who are interested in doing h2c want to.

> , and (2) got raised very briefly by Pat, but tabled due to lack of time.

No, we discussed it pretty extensively; look at the minutes:
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#315-http-uris-over-tls
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#alt-svc-http-header-field
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#discovery-of-tls-support-for-http-uris

> Both these use cases rely on the Alt-Svc HTTP response header. I therefore do not believe there's a rough consensus on including the Alt-Svc HTTP response header. But perhaps further discussion will reach such a consensus.

My impression at the meeting was that we roughly agreed to document how to use TLS for http:// URIs without requiring it, which means we need the Alt-Svc header. I discussed this with Martin and Julian, and we agreed that we'd put that in the alt-svc document, since it's separable (and potentially applicable to HTTP/1 for other use cases); that is what we're about to propose to the WG.

From a judging consensus standpoint -- of course we can talk about it more. However, I will note that there's a *significant* amount of interest in this mechanism from many in the security community, we have an implementation in one major browser, and it's not required to implement or use. So, my feeling is that an argument to omit it from the document is going to need to be a very persuasive one -- one that's stronger than "we think it's a bad idea." 

One way to do that would be to get "don't do this" advice from the Security Area, but so far all of the input I've had from that direction is "do this."

> I'd like to hear thoughts from folks on, what parts of the alt-svc draft would be acceptable for inclusion in the HTTP/2 core spec or as a normative reference.
> 
> FWIW, my thought would be to include the ALTSVC frame in the core spec, with a normative reference to a standalone specification of section 3.1 in the alt-svc draft.

Will, please be patient and wait until we actually have a proposal (a few hours to a day, I think); basing discussion on work-in-progress is not going to be helpful.

Thanks,

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 17:38:33 -0700

On Wed, Mar 19, 2014 at 5:17 PM, Mark Nottingham <[email-masked]> wrote:

> Neither has yet been brought to the WG; I'm still working on them in
> consultation with Martin, Patrick and Julian (but almost done).
>

Ah, fair enough.

> https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#discovery-of-tls-support-for-http-uris

I don't know if we can in good faith claim that we discussed using TLS with
http:// URIs in any detail. I do recall very clearly that Pat wanted to
discuss this further, but we moved forward to cover new topics like load
assymetry. For the first section about http:// URIs over TLS, a lot of that
was just me confirming that Chrome had indeed experimented with this and it
is feasible in terms of deployment. I hope no one interpreted that as my
supporting opportunistic encryption.

>
>
> > Both these use cases rely on the Alt-Svc HTTP response header. I
> therefore do not believe there's a rough consensus on including the Alt-Svc
> HTTP response header. But perhaps further discussion will reach such a
> consensus.
>
> My impression at the meeting was that we roughly agreed to document how to
> use TLS for http:// URIs without requiring it, which means we need the
> Alt-Svc header. I discussed this with Martin and Julian, and we agreed that
> we'd put that in the alt-svc document, since it's separable (and
> potentially applicable to HTTP/1 for other use cases); that is what we're
> about to propose to the WG.
>

Agreeing to documenting it doesn't mean agreeing to it being a normative
reference in HTTP/2. If that is the case, then I must say that it was not
clear at the session and should be rediscussed on the mailing list.

>
> From a judging consensus standpoint -- of course we can talk about it
> more. However, I will note that there's a *significant* amount of interest
> in this mechanism from many in the security community, we have an
> implementation in one major browser, and it's not required to implement or
> use. So, my feeling is that an argument to omit it from the document is
> going to need to be a very persuasive one -- one that's stronger than "we
> think it's a bad idea."

> One way to do that would be to get "don't do this" advice from the
> Security Area, but so far all of the input I've had from that direction is
> "do this."
>

I agree that it'd be a tall order to refuse to outright document it at all,
given the interest. I'm more concerned with the perception that HTTP/2 is
explicitly supporting opportunistic encryption, which we clearly did not
agree to in Zurich. An independent document clearly decoupled from HTTP/2
would

> Will, please be patient and wait until we actually have a proposal (a few
> hours to a day, I think); basing discussion on work-in-progress is not
> going to be helpful.
>

I think you perceived my mentioning of your commits as me impatiently
responding to something that's in progress. If so, then that's an error. My
email was more in response to comments I've heard in response to your blog
post about HTTP/2 supporting opportunistic encryption. There is wide
confusion about this, therefore I felt compelled to ask what we have
actually achieved consensus on. I just happened to see your commits when I
was searching for the latest status of how Alt-Svc is referenced in the
HTTP/2 spec. I actually didn't know you had a branch until earlier today.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 11:47:51 +1100

On 20 Mar 2014, at 11:38 am, William Chan (陈智昌) <[email-masked]> wrote:

> I don't know if we can in good faith claim that we discussed using TLS with http:// URIs in any detail.

Again, we can have more discussion if you think it will help; however, I don't see the positions on either side changing in the timeline we're trying to meet.

> I do recall very clearly that Pat wanted to discuss this further, but we moved forward to cover new topics like load assymetry. For the first section about http:// URIs over TLS, a lot of that was just me confirming that Chrome had indeed experimented with this and it is feasible in terms of deployment. I hope no one interpreted that as my supporting opportunistic encryption.

I don't think that's the case, and I think everyone understands that Chrome doesn't want to do this.

> Agreeing to documenting it doesn't mean agreeing to it being a normative reference in HTTP/2. If that is the case, then I must say that it was not clear at the session and should be rediscussed on the mailing list.

We're going to propose that the alt-svc draft be a normative reference in HTTP/2 because the ALTSVC frame uses the concepts in there, not for any other reason. If you look at the -04 version of the alt-svc draft, you'll see that opportunistic / http://-over-TLS isn't mentioned, except for a very indirect one-sentence reference to the use case in the Introduction. Nor does it require implementation of or support for the Alt-Svc HTTP header field.

Given that, are you still concerned about the reference?

> I agree that it'd be a tall order to refuse to outright document it at all, given the interest. I'm more concerned with the perception that HTTP/2 is explicitly supporting opportunistic encryption, which we clearly did not agree to in Zurich.

Not sure how Zurich comes into it; London is the most recent meeting where this was discussed.

> An independent document clearly decoupled from HTTP/2 would 

..?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 18:05:03 -0700

On Wed, Mar 19, 2014 at 5:47 PM, Mark Nottingham <[email-masked]> wrote:

> Again, we can have more discussion if you think it will help; however, I
> don't see the positions on either side changing in the timeline we're
> trying to meet.
>

I agree that positions are unlikely to change. Therefore, I'm surprised
that the evaluation of the consensus has changed from Zurich to London. If
this was actually what we were discussing in httpbis in London, I do not
think it was clear to everyone present.

>
> > I do recall very clearly that Pat wanted to discuss this further, but we
> moved forward to cover new topics like load assymetry. For the first
> section about http:// URIs over TLS, a lot of that was just me confirming
> that Chrome had indeed experimented with this and it is feasible in terms
> of deployment. I hope no one interpreted that as my supporting
> opportunistic encryption.
>
> >> My impression at the meeting was that we roughly agreed to document how
> to use TLS for http:// URIs without requiring it, which means we need the
> We're going to propose that the alt-svc draft be a normative reference in
> HTTP/2 because the ALTSVC frame uses the concepts in there, not for any
> other reason. If you look at the -04 version of the alt-svc draft, you'll
> see that opportunistic / http://-over-TLS isn't mentioned, except for a
> very indirect one-sentence reference to the use case in the Introduction.
> Nor does it require implementation of or support for the Alt-Svc HTTP
> header field.
>

This mitigates my concerns greatly. I eagerly await the next version of the
draft so I can comment on it more definitively.

> > I agree that it'd be a tall order to refuse to outright document it at
> all, given the interest. I'm more concerned with the perception that HTTP/2
> is explicitly supporting opportunistic encryption, which we clearly did not
> agree to in Zurich.
>

It's because of what I said before - I don't think it was actually
discussed in any real detail in London. I very distinctly remember Pat
saying we should discussing opportunistic encryption in the httpbis session
and getting tabled. And I know several people who were confused about
whether or not there was an appropriate time to raise opportunistic
encryption as a topic of discussion.

> > An independent document clearly decoupled from HTTP/2 would

If we have any document describing how to do opportunistic encryption, I
don't want it normatively referenced from HTTP/2. That's just my personal
opinion. But I personally don't think there was consensus in London for
this either, which is why I sent my email primarily to see if there was
indeed consensus.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 12:38:13 +1100

On 20 Mar 2014, at 12:05 pm, William Chan (陈智昌) <[email-masked]> wrote:

> This mitigates my concerns greatly. I eagerly await the next version of the draft so I can comment on it more definitively.

OK. Do you understand that the pull request on the altsvc branch (for the http2 spec itself) contains the documentation for http:// over TLS?

<https://github.com/http2/http2-spec/compare/altsvc#diff-8894168382f6487e5e38c4306e613a88R455>

Regardless, I'm a bit confused by your pushback. You don't seem to mind that we document this as an option, but have great concerns about *where* it's documented. From the standpoint of our specs, the important thing is what is required (with RFC2119 language), not now many documents it's factored into (which I consider largely an editorial concern; if we start re-factoring documents as a means of political compromise, it leads to bad things). 

> It's because of what I said before - I don't think it was actually discussed in any real detail in London. I very distinctly remember Pat saying we should discussing opportunistic encryption in the httpbis session and getting tabled. And I know several people who were confused about whether or not there was an appropriate time to raise opportunistic encryption as a topic of discussion.

I've asked a few people, and their recollection (and mine) is different from yours. The minutes also seem to support my interpretation. 

In any case, we're discussing it now.

Cheers,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Mar 2014 19:39:41 -0700

On Wed, Mar 19, 2014 at 6:38 PM, Mark Nottingham <[email-masked]> wrote:

> >> We're going to propose that the alt-svc draft be a normative reference
> in HTTP/2 because the ALTSVC frame uses the concepts in there, not for any
> > This mitigates my concerns greatly. I eagerly await the next version of
> the draft so I can comment on it more definitively.
>
> OK. Do you understand that the pull request on the altsvc branch (for the
> http2 spec itself) contains the documentation for http:// over TLS?
>

Whoa, really? No, I did not understand that. I'm glad we're discussing this
now. Thanks for pointing that out.

> <
> https://github.com/http2/http2-spec/compare/altsvc#diff-8894168382f6487e5e38c4306e613a88R455
> >
>
> Regardless, I'm a bit confused by your pushback. You don't seem to mind
> that we document this as an option, but have great concerns about *where*
> it's documented. From the standpoint of our specs, the important thing is
> what is required (with RFC2119 language), not now many documents it's
> factored into (which I consider largely an editorial concern; if we start
> re-factoring documents as a means of political compromise, it leads to bad
> things).
>

Sorry, I'm not trying to be dense here. I'm honestly just confused about
what the status is of all the opportunistic encryption stuff. And my
primary objective here is to clear up that confusion. My concern with the
"where" it's documented is what people consider as part of HTTP/2. My
personal opinion is that opportunistic encryption should not be considered
a feature that we're adding in HTTP/2, therefore I definitely don't want it
in the core spec, and to a lesser degree, I also don't want it as a
normative reference, since my understanding is that implies that HTTP/2 has
a normative dependency on opportunistic encryption.

> I've asked a few people, and their recollection (and mine) is different
> from yours. The minutes also seem to support my interpretation.
>

I'd appreciate those people coming up and stating that. I'm honestly just
saying what I remember, and I'm fine with people disagreeing with my
understanding of what happened. I just don't want it to happen quietly. I
mean, Pat, is my description that far off from what you remember? I
remember you telling me that Stephen was confused about when was
appropriate for him to argue the case for opportunistic encryption. And I
remember being at the mic when the hum was taken and saying that I wasn't
sure what we were agreeing to in the hum.

> In any case, we're discussing it now.

And I'm happy with that. I want to re-emphasize that my primary purpose
with this thread is to make sure we get clarity on something that I thought
was vague. If everyone else says they believe that the working group
consensus indeed is to document http:// over TLS in the core HTTP/2 spec,
then clearly I misunderstood, but am fine with being wrong about that
understanding.

---

From: Rob Trace <[email-masked]>
Date: Thu, 20 Mar 2014 06:52:43 +0000

My recollection is the same as Will’s with regard to the discussion and consensus in London.

It is correct that we are interested in using Upgrade and not Alt-Svc for upgrading HTTP URIs from HTTP 1.1 to HTTP/2.  I am not aware of anyone who is planning on implementing Alt-Svc for this scenario, but maybe there is someone out there who wants to support this/.. In addition, we are not planning on implementing TLS for HTTP URIs at this time and we definitely prefer explicit TLS with HTTPS URIs.  We are not planning on supporting the asymmetric load balancing or the SNI scenarios at this time.

I agree that most people have not changed their position since London.  In particular, I do not want to see the Alt-Svc work further delaying HTTP/2. Again my recollection was that there was strong consensus that this work was not going to block HTTP/2.  It follows that this reference should not be normative to prevent creating a dependency.

I am looking forward to the updated text which will give us something definitive to discuss..

Thanks!!

-Rob

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Chan (???)
Sent: Wednesday, March 19, 2014 7:40 PM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

On Wed, Mar 19, 2014 at 6:38 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

Whoa, really? No, I did not understand that. I'm glad we're discussing this now. Thanks for pointing that out.

Sorry, I'm not trying to be dense here. I'm honestly just confused about what the status is of all the opportunistic encryption stuff. And my primary objective here is to clear up that confusion. My concern with the "where" it's documented is what people consider as part of HTTP/2. My personal opinion is that opportunistic encryption should not be considered a feature that we're adding in HTTP/2, therefore I definitely don't want it in the core spec, and to a lesser degree, I also don't want it as a normative reference, since my understanding is that implies that HTTP/2 has a normative dependency on opportunistic encryption.

I'd appreciate those people coming up and stating that. I'm honestly just saying what I remember, and I'm fine with people disagreeing with my understanding of what happened. I just don't want it to happen quietly. I mean, Pat, is my description that far off from what you remember? I remember you telling me that Stephen was confused about when was appropriate for him to argue the case for opportunistic encryption. And I remember being at the mic when the hum was taken and saying that I wasn't sure what we were agreeing to in the hum.

And I'm happy with that. I want to re-emphasize that my primary purpose with this thread is to make sure we get clarity on something that I thought was vague. If everyone else says they believe that the working group consensus indeed is to document http:// over TLS in the core HTTP/2 spec, then clearly I misunderstood, but am fine with being wrong about that understanding.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 08:19:57 +0100

> My recollection is the same as Will’s with regard to the discussion and

I agree that we should have invested more energy for this discussion in 
London. That being said, the IETF meetings and interim meetings can not 
make any decisions - what will count is the rough consensus over here, 
right now.

> It is correct that we are interested in using Upgrade and not Alt-Svc
> for upgrading HTTP URIs from HTTP 1.1 to HTTP/2.  I am not aware of

My understanding is that Microsoft thinks that Upgrade on port 80 is 
going to work well enough in practice that no other mechanism is needed. 
Apparently, the other implementers do not believe this, or are opposed 
to this for other reasons. It would be awesome if there were actual 
numbers on success rates to inform the rest of us.

I personally would love to see this work, as, after all, this is how it 
was *supposed* to work. But even if it does work, a way to advertise an 
alternative way, potentially using OE, sounds good to me as well.

> anyone who is planning on implementing Alt-Svc for this scenario, but
> maybe there is someone out there who wants to support this/.. In

We heard about experiments in Firefox. That shows that at least one 
developer was sufficiently interested to experiment with it.

> addition, we are not planning on implementing TLS for HTTP URIs at this
> time and we definitely prefer explicit TLS with HTTPS URIs.  We are not
> planning on supporting the asymmetric load balancing or the SNI
> scenarios at this time.
>
> I agree that most people have not changed their position since London.
> In particular, I do not want to see the Alt-Svc work further delaying
> HTTP/2. Again my recollection was that there was strong consensus that
> this work was not going to block HTTP/2.  It follows that this reference
> should not be normative to prevent creating a dependency. *//*

My recollection was that this shouldn't block, and *therefore* it needs 
to become a WG work item as soon as possible. However, what I recall may 
be side discussions.

In any case, the place to make decisions is *here*, not at face-to-face 
meetings.

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 20 Mar 2014 08:38:51 +0100 (CET)

On Thu, 20 Mar 2014, Julian Reschke wrote:

>> It is correct that we are interested in using Upgrade and not Alt-Svc for 
>> upgrading HTTP URIs from HTTP 1.1 to HTTP/2.  I am not aware of
>
> My understanding is that Microsoft thinks that Upgrade on port 80 is going 
> to work well enough in practice that no other mechanism is needed. 
> Apparently, the other implementers do not believe this, or are opposed to 
> this for other reasons. It would be awesome if there were actual numbers on 
> success rates to inform the rest of us.

We support http1+Upgrade: on port 80 for plain-text HTTP2 in curl (powered by 
nghttp2) as well as the other mechanisms and I intend to offer (at least 
partial*) Alt-Svc support as well. It is just not there yet.

Primarily of course because we make a tool widely used for exploring, testing 
and debugging these internet protocols so supporting "everything" is what we 
do, but also because I'm a proponent of being able to switch HTTP:// traffic 
to use TLS in a controlled manner. (I'm avoiding the O* acronyms!)

There aren't that many http2-draft9/10 servers alive out there yet that 
support upgrade (hint hint) so I have no numbers or even a hunch of how good 
it actually works in real-life.

[*] = because the setting up of a secondary route to the same content is 
intended to be somewhat of an asynchronous operation it isn't that easily 
transferable to curl paradogms. It'll have to work on a more direct and 
explicit way for us.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 08:55:22 +0100

Trying to summarize what we heard so far (please correct me if I'm wrong):

a) Rob Trace

alt-svc is not needed (will use upgrade on port 80), work on alt-svc 
shouldn't block progress

b) 陈智昌

alt-svc is useful (needed?), but doesn't want a normative reference to a 
document that includes a definition of the Alt-Svc header field, because 
he's not planning to support it

I believe Rob's concern can be addressed by getting the work done ASAP.

I believe William's concern can be addressed by making it crystal clear 
that although the spec defines an HTTP header field, support for that 
header field is purely optional.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 18:57:37 +1100

I don't think that's the case, Julian. Alt-Svc is used for many things; William has so far only expressed a reservation about one use case. Likewise, Rob's message was just about upgrade, not other uses of Alt-Svc.

Cheers,

On 20 Mar 2014, at 6:55 pm, Julian Reschke <[email-masked]> wrote:

> alt-svc is not needed (will use upgrade on port 80), work on alt-svc shouldn't block progress
> 
> b) 陈智昌
> 
> alt-svc is useful (needed?), but doesn't want a normative reference to a document that includes a definition of the Alt-Svc header field, because he's not planning to support it
> 
> 
> I believe William's concern can be addressed by making it crystal clear that although the spec defines an HTTP header field, support for that header field is purely optional.
> 
> Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 18:58:08 +1100

> Sorry, I'm not trying to be dense here. I'm honestly just confused about what the status is of all the opportunistic encryption stuff. And my primary objective here is to clear up that confusion. M…

No. A normative reference is not "we import that specification and all of its requirements"; it means "you need to understand that document to implement part of this document." That includes an OPTIONAL part of "this document" -- it does not mean that you have to implement the normatively referenced document to be conformant to the referent. 

See:
  https://www.ietf.org/iesg/statement/normative-informative.html

E.g., HTTPbis p1 references RFC1950-1952 for GZIP and Deflate; that does not mean that every implementation must support GZIP and deflate (current efforts in HTTP/2 notwithstanding). It does mean that if you use those formats in HTTP, you need to be conformant to that specification.

Or, consider that we already document how to use HTTP/2 in the clear, despite your repeated statements that you will not implement that. That is part of the document, but not required to implement.

Your concern seems to be more about how people perceive what we publish. We could indeed publish HTTP:// over TLS separately, but that doesn't really have an effect on its weight; it's still a product of the HTTPbis Working Group, and it's still on the standards track. 

> And I'm happy with that. I want to re-emphasize that my primary purpose with this thread is to make sure we get clarity on something that I thought was vague. If everyone else says they believe tha…

So, I went back and listened to the audio archive <http://www.ietf.org/audio/ietf89/ietf89-blenheim-20140305-1300-pm1.mp3>; this discussion starts at 1:28:20, with the most relevant part at 1:55:30.

We had agreement in the room that we wanted to document TLS for HTTP:// URIs without requiring it, but we indeed need to confirm that consensus on the list, as we're doing now*.

Let's decouple the discussion of HTTP for TLS URLs from that for the rest of alt-svc. The text I've been working on is the section starting here:
  https://github.com/http2/http2-spec/compare/altsvc#diff-8894168382f6487e5e38c4306e613a88R455

Let's consider that text an in-play proposal. 

What would you like to see instead? Keep in mind that we already have considerable support for documenting it somehow.

Cheers,

* And I've updated the wording on that blog entry to clarify this point.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 09:04:13 +0100

> I don't think that's the case, Julian. Alt-Svc is used for many things; William has so far only expressed a reservation about one use case. Likewise, Rob's message was just about upgrade, not other…

Rob said: "In particular, I do not want to see the Alt-Svc work further 
delaying HTTP/2." which IMHO implies that he think it's not strictly 
needed (otherwise the statement wouldn't make sense, right?).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Mar 2014 20:45:54 +1100

> Let's consider that text an in-play proposal. 

… moved to:
  https://gist.github.com/mnot/9660370

Cheers,

---

From: Rob Trace <[email-masked]>
Date: Thu, 20 Mar 2014 14:09:02 +0000

Thanks Julian,  that's correct.  My opinion is that Alt-Svc is not strictly needed for HTTP/2 and my concern would be that if the alt-svc conversation goes on for too long, it will impact HTTP/2.

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 1:04 AM
To: Mark Nottingham
Cc: Rob Trace; "William Chan (陈智昌)"; HTTP Working Group
Subject: Re: Finding consensus on alt-svc, was: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

> I don't think that's the case, Julian. Alt-Svc is used for many things; William has so far only expressed a reservation about one use case. Likewise, Rob's message was just about upgrade, not other…

Rob said: "In particular, I do not want to see the Alt-Svc work further delaying HTTP/2." which IMHO implies that he think it's not strictly needed (otherwise the statement wouldn't make sense, right?).

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Mar 2014 15:16:18 +0000

On 03/20/2014 02:39 AM, William Chan (陈智昌) wrote:
>  If everyone else says they believe that the working group

With no hats, I'd like to be on the record as saying that
documenting how to do http:// URIs via TLS as part of HTTP/2.0
would be a really good thing to do. Especially in the light
of recent reports of cleartext HTTP being used to trigger
other attacks. And defining that at the same time as we are
defining HTTP/2.0 seems like the perfect time to me. (Adding
it later would be far less good IMO.)

I don't have a very strong position about which 2119 keywords
are used to talk about whether that MAY, SHOULD or MUST be
implemented or used, but one could argue that both BCP 61 and
the new perpass-attack BCP will be far more clearly satisfied
the more that feature is implemented. The main thing for me
however is that it be well-defined now so that those who want
to use that feature can do so and get interop and be in a
position to mitigate attacks such as those referred to above
without requiring changes to web content.

And yes, I do get that this is not entirely a slam-dunk, but
from the discussion I've heard and the evidence that it can
be done from Patrick and I think Will, it seems to me that
defining how to do it ought not be something that'd add
significant (or any) delay.

S.

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 20 Mar 2014 08:41:39 -0700

> sure what we were agreeing to in the hum.
So I haven't talked to Mark about this (so I'm not even in his un-listed
list above), but my recollection matches his. I distinctly remember walking
out of the room with a sense that we had come to a good place, where
basically every intended use case (plaintext http://, https://, and
http://-over-TLS)
was going to be documented as part of the spec. The question of whether or
not some things would be in a (normatively-referenced) separate document or
not was still a little up in the air, but I was definitely under the
impression that there would be normative references involved if
http://-over-TLS
wasn't placed directly in the main spec. My general feeling on that was
that we had agreed to put the ALTSVC frame, and mechanism for http://-over-TLS
in the main spec, with the new Alt-Svc header for HTTP/1.1 in a separate
document.
-- 
Peace,
  -Nick

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 20 Mar 2014 15:46:54 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> >  If everyone else says they believe that the working group consensus
> > indeed is to document http:// over TLS in the core HTTP/2 spec,
> 
> With no hats, I'd like to be on the record as saying that documenting how to
> do http:// URIs via TLS as part of HTTP/2.0 would be a really good thing to do.
> Especially in the light of recent reports of cleartext HTTP being used to trigger
> other attacks. And defining that at the same time as we are defining
> HTTP/2.0 seems like the perfect time to me. (Adding it later would be far less
> good IMO.)
> 
> I don't have a very strong position about which 2119 keywords are used to
> talk about whether that MAY, SHOULD or MUST be implemented or used,
> but one could argue that both BCP 61 and the new perpass-attack BCP will be
> far more clearly satisfied the more that feature is implemented. The main
> thing for me however is that it be well-defined now so that those who want
> to use that feature can do so and get interop and be in a position to mitigate
> attacks such as those referred to above without requiring changes to web
> content.
> 
> And yes, I do get that this is not entirely a slam-dunk, but from the discussion
> I've heard and the evidence that it can be done from Patrick and I think Will,
> it seems to me that defining how to do it ought not be something that'd add

[Gab] I think there was agreement in London to go ahead and document it. The issue is of a different nature. If the base spec adds a normative reference to the alt-svc spec, it adds a blocker from the point of view of the RFC editing/publication process. We did not discuss informative vs normative reference in London, but we also agreed in London (very clearly, per my recollection) that alt-svc would not be a blocker for HTTP/2. 

Documenting and having an informational reference is non-blocking, and appropriate as well, since one does not need to understand all the alt-svc scenarios in order to implement the ALTSVC frame. This is analogous to how PUSH and flow control also have the low-level mechanisms in the spec, but how to actually use them (PUSH strategies, flow control algorithms) are left out.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 16:58:45 +0100

> [Gab] I think there was agreement in London to go ahead and document it. The issue is of a different nature. If the base spec adds a normative reference to the alt-svc spec, it adds a blocker from…

It's only a blocker if we don't make progress :-)

> Documenting and having an informational reference is non-blocking, and appropriate as well, since one does not need to understand all the alt-svc scenarios in order to implement the ALTSVC frame. T…

Yes, but the definition of the ALTSVC frame relies on the definition of 
the Alt-Svc concept. Either we in-line the definition of the concept, or 
we have a normative dependency on that other spec.

Both will work, and I claim that timing-wise it doesn't make any 
significant difference. It's just the number of documents that varies.

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Thu, 20 Mar 2014 18:03:24 +0000

While I wasn't in London, it sounds like the consensus there was "don't block the spec."  However, there are a couple approaches to "don't block" that are being used by different people.

Some seem to be advocating a normative reference, which makes HTTP/2 dependent on the Alt-Svc draft, and achieves "don't block" by getting the draft done so quickly that it doesn't (further) delay the HTTP/2 RFC.  When we're already unable to finish HTTP/2 on schedule, this makes me worry that the draft would be rushed.

Others are advocating an informative reference, where Alt-Svc would be dependent on the HTTP/2 spec and could finish afterward -- that corresponds better to my understanding of non-blocking.  The problem with that approach is that with no extensibility mechanism in HTTP/2, if Alt-Svc needs *anything* from the base protocol it has to be known before HTTP/2 goes to RFC.  That makes the obvious interpretation of not blocking rather problematic, now that Alt-Svc isn't simply using headers.

What is the most contained set of changes we could make, either to HTTP/2 or Alt-Svc, to decouple them? 

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 1:04 AM
To: Mark Nottingham
Cc: Rob Trace; "William Chan (陈智昌)"; HTTP Working Group
Subject: Re: Finding consensus on alt-svc, was: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 19:15:58 +0100

> Some seem to be advocating a normative reference, which makes HTTP/2 dependent on the Alt-Svc draft, and achieves "don't block" by getting the draft done so quickly that it doesn't (further) delay…

Can we give it a try instead of having this meta discussion? :-)

> Others are advocating an informative reference, where Alt-Svc would be dependent on the HTTP/2 spec and could finish afterward -- that corresponds better to my understanding of non-blocking.  The p…

An informative ref is not going to work if we put the alt-svc framework 
into a separate document.

> What is the most contained set of changes we could make, either to HTTP/2 or Alt-Svc, to decouple them?

There's no way to decouple them. The alt-svc framework needs to live in 
either (a) a separate spec or (b) in HTTP/2.

In case of (a) (which is what IMHO the current authors of these specs 
prefer), HTTP/2 will normatively reference the alt-svc draft. In case of 
(b), all "users" of the alt-cvs framework will need a normative 
reference to the HTTP/2 spec, which looks weird to me.#

At the end of the day, the number of documents really is not relevant 
for the time we need to finish them.

Best regards, Julian

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 20 Mar 2014 19:14:32 +0000

> prefer), HTTP/2 will normatively reference the alt-svc draft. In case of
 
Disagree. Just like HTTP/s does not reference normatively the PUSH strategies document nor the flow control algorithms documents. That's a good thing, since those documents don't exist.

> reference to the HTTP/2 spec, which looks weird to me.#

That seems like backwards layering.

The "users" of the alt-svc framework would need a normative reference to the alt-svc framework, which in turn can point at HTTP/2.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Mar 2014 21:24:24 +0100

> Disagree. Just like HTTP/s does not reference normatively the PUSH strategies document nor the flow control algorithms documents. That's a good thing, since those documents don't exist.

...and because HTTP/2 is self-contained with respect to that.

> The "users" of the alt-svc framework would need a normative reference to the alt-svc framework, which in turn can point at HTTP/2.

Hm, that just adds one indirection, but the problem is the same. To 
leverage alternate services, you'd always have a normative reference 
(indirectly) to HTTP/2. Why would that be a good thing?

Best regards, Julian

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 25 Mar 2014 15:07:07 -0700

Looking at things, it's clear to me that my understanding of things was
somewhat confused (normative references and mixing of the opportunistic
encryption next steps as discussed first by Pat in the middle of the 2nd
httpbis session, then re-raised at the end of the session, and then more
concrete next steps discussed in the design meeting). I'm happy with the
current state of the discussion process - documenting the non-HTTP/2
portions outside of the HTTP/2 spec. As Rob states, I also don't want to
see it block the HTTP/2 work, although I think Julian is right that it will
likely finish first anyway.

On Thu, Mar 20, 2014 at 2:45 AM, Mark Nottingham <[email-masked]> wrote:

> > Let's decouple the discussion of HTTP for TLS URLs from that for the
> rest of alt-svc. The text I've been working on is the section starting here:
> >
> ... moved to: