Re: New Version Notification for draft-nottingham-variants-00.txt

> On 29 Sep 2017, at 11:31 am, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 
> ​On 28 September 2017 at 17:47, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> Just a little comment: The title, "HTTP Variants", let me think that it's about 'variants' such 1.0, 1.1, 2.0, and maybe some finer distinctions.
> 
> I'd change the title to "The HTTP 'Variants' Header" or some such.
> 
> Regards,   Martin.
> ​
> Or perhaps just "HTTP Resource Variants".

I like that.


> On 28 September 2017 at 18:16, Mark Nottingham <mnot@mnot.net> wrote:
> Hi Jan,
> 
> I mentioned TCN in acknowledgements, but could touch on t on the introduction too.
> 
> Sent from my iPhone
> 
> > On 28 Sep 2017, at 6:08 pm, Jan Algermissen <algermissen1971@icloud.com> wrote:
> >
> > [resending with better reference [1]]
> >
> > Hi Mark,
> >
> > cannot give it a thorough read right now, so bear with me if this is obvious, but:
> >
> > What is the difference to the Alternates[1][2] header? It would be nice, I think, mentioning that explicitly in the spec.
> >
> > jan
> >
> > [1] https://tools.ietf.org/html/rfc2295#section-8.3
> > [2] curl http://www.w3.org -HAccept:text/foo -I
> >
> 
> 
> ​I think it would be helpful to have at least a little more about TCN in there somewhere.  Personally I'd appreciate something that explains how Variants and Alternates are different; along the lines of:
> 
> * Alternates requires you to specify each combination of attributes
> * Alternates/TCN assumes each combination has a different, specific URI.
> 
> etc.

SGTM.


> I need to dash out so I'm not reading particularly thoroughly right now, but how does this proposal sit with WhatWG's "Why not connect" thing? https://wiki.whatwg.org/wiki/Why_not_conneg

I agree with a lot of what is said there about proactive content negotiation. What's happening here is that we're a) giving intermediaries defined algorithms for picking a stored response for known negotiation axes (where it's appropriate), and b) giving UAs more information about what's available on the server, so they can make more informed choices if they want to reissue a request. 

It also mitigates a lot of the downsides explained in "Server-side choice is worse for intermediate caches than browser-side choice" in that document. 

I don't think it's a replacement with reactive conneg (to use the 7231) as that document advocates; the motivation here is much the same as client hints -- where you want to do negotiation but don't want to touch the HTML.

Cheers,



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

Received on Friday, 29 September 2017 06:34:29 UTC