W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

From: Michael Sweet <msweet@apple.com>
Date: Wed, 20 Nov 2013 07:59:15 -0500
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <B81EF1C8-6EB4-4445-9643-4FAEFECA8AAD@apple.com>
To: Grahame Grieve <grahame@healthintersections.com.au>
Grahame,

On Nov 19, 2013, at 9:20 PM, Grahame Grieve <grahame@healthintersections.com.au> wrote:
> +1.
> 
> Unless you propose to simply ban non-TLS HTTP/2 altogether under any
> circumstance, this becomes a policy issue, and belongs elsewhere (and,
> in fact, what about that is specific to http/2? - probably negotiated
> upgrade, which is not possible in http/1)

HTTP/1.1 supports negotiated upgrade via the Upgrade and Connection headers. RFC 2817 describes how to use it to upgrade the current hop to TLS.


> 
> Grahame
> 
> 
> On Wed, Nov 20, 2013 at 12:53 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
>> On 20 November 2013 11:02, Mark Nottingham <mnot@mnot.net> wrote:
>>> 
>>> <https://github.com/http2/http2-spec/issues/314>
>>> 
>>> 
>>> So far, we don't have any text for this issue, so I'm asking for proposals
>>> to be made now.
>>> 
>>> If we can't get consensus (or if one isn't made), the default is to leave
>>> the specification as-is; that is, we'll continue to define how to use
>>> HTTP/2.0 for both http:// and https://, and implementations will choose
>>> which scheme(s) they support for the new protocol. You're welcome to
>>> explicitly propose the status quo, of course.
>> 
>> 
>> I explicitly propose the status quo: leave any recommendation (normative or
>> otherwise) out of the base HTTP/2.0 spec.  Instead I suggest we/you/someone
>> create a separate (informational?) document describing these issues.
>> 
>> At the least, I would imagine the base spec to be (hopefully) current and
>> useful for decades, whereas what various browsers do or don't support, or
>> even what browsers exist or matter in the market, might be a bit more
>> transient; thus any documentation that depends on them should be equally
>> versatile.  Updating or obsoleting an informational RFC would be a lot
>> easier than keeping a "that's *so* 2013" social reference in the HTTP/2.0
>> spec, and possibly pointing out to people that it, in fact, no longer
>> applies, or whatever.
>> 
>> --
>>  Matthew Kerwin
>>  http://matthew.kerwin.net.au/
> 
> 
> 
> -- 
> -----
> http://www.healthintersections.com.au /
> grahame@healthintersections.com.au / +61 411 867 065
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 20 November 2013 12:59:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC