Re: 9.2.2, Rough Consensus, and Working Code

More to the point, they do implement HTTP, and the chartered goal of
this working group is to produce a protocol that they will be willing
to adopt as a replacement for HTTP/1.  If you want to change the name
of the protocol to TLS+, feel free to do so and ignore the existing
implementations.

I know Apache httpd won't be implementing 9.2.2 because the HTTP-aware
code doesn't even get involved in connection activity until after the
first HTTP message is received.  Furthermore, there is no way of
knowing if an external device is securing the connection.
When we do have an implementation of HTTP/2, it won't be limited to
TLS for the same reason HTTP/1 isn't limited to TCP.

I am sorry that the ADs don't seem to understand the concept.
If they have a problem with the adequacy of TLS, they are
fully capable of publishing TLS 1.3 as a minimum set of changes
and let the session-level protocol negotiate correctly.

Right now, there are zero implementations of server-side 9.2.2 and
no expressions of interest.  So, unless this is rough consensus and
running ADs, the IETF decision should be to delete 9.2.2, or at least
delete the requirements it makes on servers.  This does not, in any way,
prevent user agents from refusing to make requests on what they
consider to be an inadequately secured connection.

....Roy

On Nov 5, 2014, at 3:47 PM, Mike Bishop wrote:

> That's true, but for the most part these are the people who *will* be implementing what we produce once it's finalized.  If they say that they will not be implementing something that's in the spec when they eventually get around to their implementation, I think their feedback is still worth bearing in mind.
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net] 
> Sent: Wednesday, November 5, 2014 3:16 PM
> To: Mike Bishop
> Cc: HTTP Working Group
> Subject: Re: 9.2.2, Rough Consensus, and Working Code
> 
> Mike,
> 
> Digging into this a bit --
> 
> We have 24 reasonably current implementations listed, many of them demonstrating interop.
> 
>> On 5 Nov 2014, at 12:42 pm, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> 
>> By my count, the following implementations have working code or stated plans to implement the restrictions in 9.2.2:
>> ·        Chrome/Google - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0148.html
>> ·        Mozilla Firefox - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0143.html among others
>> ·        Jetty – http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0190.html (best effort, can’t fully match)
>> 
>> The following have stated that they cannot or will not implement 9.2.2:
>> ·        RedHat - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html, http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0014.html
> 
> RedHat does not have an implementation listed.
> 
>> ·        Apple - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html
> 
> Apple is not currently implementing, as far as we know, so this is a statement of Michael's opinion, not implementation support. Additionally, Michael AFAIK does *not* represent Safari or Apple's HTTP stack; he's working on printing protocols (some of which use HTTP). Michael, please correct me if this is incorrect.
> 
>> ·        Apache - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html
> 
> Apache httpd is not currently listed as implementing, so this is a statement of Roy's opinion, not implementation support.
> 
>> ·        Wildfly - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html
> 
> Wildfly does not have an implementation listed. I believe Stuart also works on JBoss, which is also not currently on the implementation list.
> 
>> ·        HAProxy - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html
> 
> HAProxy does not have an implementation listed.
> 
>> ·        Microsoft (IE, IIS, etc.)
> 
> ... Microsoft DOES have an implementation listed.
> 
> So claims of "working code" seem to be premature here. We don't determine everything by running code here, but when we use it to motivate an argument, let's try to get it right. Some of these folks may have implementations planned or in the works, but they haven't yet brought running code to the party. 
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

Received on Thursday, 6 November 2014 00:37:53 UTC