W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Straw-man for our next charter

From: Jonathan Ballard <dzonatas@gmail.com>
Date: Mon, 30 Jul 2012 15:06:48 -0700
Message-ID: <CAAPAK-7D3xyTAdk6iqNxrSXzrBprQQTS4ThZN_NGuXn0gFNrhg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Larry Masinter <masinter@adobe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 July 2012 22:07:25 GMT