- From: Jonathan Ballard <dzonatas@gmail.com>
- Date: Mon, 30 Jul 2012 15:06:48 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Larry Masinter <masinter@adobe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAAPAK-7D3xyTAdk6iqNxrSXzrBprQQTS4ThZN_NGuXn0gFNrhg@mail.gmail.com>
Any valid MIME or SMIME under application/<registered-type> also works as text/<format>+<registered-type>. That possibility does not imply those are all practical at the transport layer. It does, however explicitly, suggest an upgrade or downgrade logical in this context with HTTP/x.y streams. On Monday, July 30, 2012, James M Snell wrote: > In all honesty, the existing MIME Media Type system could stand for a bit > of an update [1]... Such changes, however, are certainly well beyond the > scope of the missing to produce an updated HTTP with identical semantics to > 1.1. Would definitely be interested in exploring the possibilities of what > could be done here tho. > > - James > > [1] > http://chmod777self.blogspot.com/2012/04/even-more-on-future-of-mime-media-types.html > > On Fri, Jul 27, 2012 at 11:39 PM, Larry Masinter <masinter@adobe.com<javascript:_e({}, 'cvml', 'masinter@adobe.com');> > > wrote: > >> re changes to semantics: consider the possibility of eliminating >> "sniffing" in HTTP/2.0. If sniffing is justified for compatibility with >> deployed servers, could we eliminate sniffing for 2.0 sites? >> >> It would improve reliability, security, and even performance. Yes, >> popular browsers would have to agree not to sniff sites running 2.0, so >> that sites wanting 2:0 benefits will fix their configuration. >> >> Likely there are many other warts that can be removed if there is a >> version upgrade. >> >> >> -----Original message----- >> >> *From: *Mark Nottingham <mnot@mnot.net <javascript:_e({}, 'cvml', >> 'mnot@mnot.net');>>* >> To: *Amos Jeffries <squid3@treenet.co.nz <javascript:_e({}, 'cvml', >> 'squid3@treenet.co.nz');>>* >> Cc: *"ietf-http-wg@w3.org <javascript:_e({}, 'cvml', >> 'ietf-http-wg@w3.org');>" <ietf-http-wg@w3.org <javascript:_e({}, >> 'cvml', 'ietf-http-wg@w3.org');>>* >> Sent: *Fri, Jul 27, 2012 06:16:31 GMT+00:00 >> * >> Subject: *Re: Straw-man for our next charter >> >> >> On 27/07/2012, at 4:10 PM, Amos Jeffries <squid3@treenet.co.nz<javascript:_e({}, 'cvml', 'squid3@treenet.co.nz');>> >> wrote: >> >> > On 27/07/2012 5:27 p.m., Mark Nottingham wrote: >> >> Hi Amos, >> >> >> >> On 25/07/2012, at 10:02 PM, Amos Jeffries <squid3@treenet.co.nz<javascript:_e({}, 'cvml', 'squid3@treenet.co.nz');>> >> wrote: >> >>>> Work will begin using XXX as a starting point; all proposals are to >> be expressed >> >>>> in terms of changes to the that document. >> >>> I just think I'll throw a spanner in the general direction of the >> works here.... >> >>> >> >>> How realistic is it to expect the HTTPbis 1.1 draft documents fill >> that role? At least we can guarantee that modifications to adjust them for >> 2.0 specifics will not loose or add any features unintentionally that could >> affect HTTP/1.1 compatibility. >> >> I'm not sure what your concern is here... >> > >> > concern 1) is the feature parity between the HTTP/1 drafts and any >> other document that gets picked. ie workload to get the new doc completed. >> > >> > concern 2) is the politcal battle to get document X to meet the WG >> goals. >> > >> > Much like what I said in my expression of interest summary. The HTTP/2 >> drafts on the tables (own one included) do not come up to scratch for >> HTTP/2 starting points. >> > >> > I know a lot of people have interest in SPDY, but to make that the >> HTTP/2 base doc there are a fair chunk of things which will need pruning >> out - if only because they are new semantics. It is probably not a good >> idea for the WG to start off facing that political battle to ensure its >> semantically seamless to HTTP/1.1. The other documents are bare-bones with >> specific focus on framing improvement over WG drafts part1-2. >> >> Aha. I was assuming that would come up; please discuss (details would >> help). >> >> >> > However taking the HTTPbis draft documents and replacing sections of >> them with SPDY mechanisms, frame design, etc as we agree on particulars - >> that has a clear chance of faster success. >> >> That's an interesting approach. >> >> Cheers, >> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> >
Received on Monday, 30 July 2012 22:07:18 UTC