Re: Straw-man for our next charter

[Larry Masinter <[e-mail]>]

defining the meaning and expected behavior of recipients of headers is a protocol issue of interest to intermediaries as well as receivers.


-----Original message-----
From: Mark Nottingham <[e-mail]>
To: Larry Masinter <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: Sun, Jul 29, 2012 18:52:19 GMT+00:00
Subject: Re: Straw-man for our next charter

Sniffing -- for better or worse -- isn't really a HTTP behaviour. I.e., it may use a HTTP header (User-Agent), but it's more a use *of* HTTP -- just as Web browsing is generally.

Also -- and everyone really needs to understand this -- HTTP is NOT an end-to-end protocol, and therefore browsers can't tell whether or not it's a "2.0 site" because there may be intermediary transitions in the middle.

As far as shaving warts off -- doing so in the protocol is really, really hard, because the deployed footprint is so large. My preferred approach is to allow sites to opt out -- e.g., <http://tools.ietf.org/html/draft-nottingham-http-browser-hints-00>.

Cheers,


On 27/07/2012, at 11:39 PM, Larry Masinter <[e-mail]> 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 <[e-mail]>
> To: Amos Jeffries <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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 <[e-mail]> wrote:
>
> > On 27/07/2012 5:27 p.m., Mark Nottingham wrote:
> >> Hi Amos,
> >>
> >> On 25/07/2012, at 10:02 PM, Amos Jeffries <[e-mail]> 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/
>
>
>
>

--
Mark Nottingham
http://www.mnot.net/