W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Getting to consensus on HTTP:// over TLS

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Mar 2014 18:58:08 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <686340D9-BD9E-47FA-8875-AE603DB4A77C@mnot.net>
To: "William Chan (陈智昌)" <willchan@chromium.org>
On 20 Mar 2014, at 1:39 pm, William Chan (陈智昌) <willchan@chromium.org> wrote:

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

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. 


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

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.


--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 20 March 2014 07:58:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC