- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 20 Nov 2013 07:59:15 -0500
- To: Grahame Grieve <grahame@healthintersections.com.au>
- Cc: Matthew Kerwin <matthew@kerwin.net.au>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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