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

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 17:17:55 +1000

FYI, I've been working on a thought experiment; it's a possible supplement to Key (or even replacement for, at least for headers with defined semantics, like Client Hints). Feedback appreciated.

Pretty version at:
  https://mnot.github.io/I-D/variants/ <https://mnot.github.io/I-D/variants/>

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-variants-00.txt
> Date: 28 September 2017 at 5:15:05 pm AEST
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-variants-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-variants
> Revision:	00
> Title:		HTTP Variants
> Document date:	2017-09-28
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-variants-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-variants/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-variants-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-variants-00
> 
> 
> Abstract:
>   This specification introduces the HTTP "Variants" response header
>   field to communicate what representations are available for a given
>   resource.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 28 Sep 2017 16:47:21 +0900

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.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 28 Sep 2017 10:08:11 +0200

[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

On 28 Sep 2017, at 9:17, Mark Nottingham wrote:

> FYI, I've been working on a thought experiment; it's a possible 
> supplement to Key (or even replacement for, at least for headers with 
> defined semantics, like Client Hints). Feedback appreciated.
>
> Pretty version at:
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-nottingham-variants-00.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-nottingham-variants/
>> Htmlized:       
>> https://tools.ietf.org/html/draft-nottingham-variants-00
>> Htmlized:       
>> https://datatracker.ietf.org/doc/html/draft-nottingham-variants-00
>>
>>
>> Abstract:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 18:16:27 +1000

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 <[email-masked]> wrote:
> 
> 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
>

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 29 Sep 2017 11:31:49 +1000

​
On 28 September 2017 at 17:47, Martin J. Dürst <[email-masked]>
 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.
>
​
Or perhaps just "HTTP Resource Variants".

> > [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.

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

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Sep 2017 16:34:00 +1000

> On 29 Sep 2017, at 11:31 am, Matthew Kerwin <[email-masked]> wrote:
> 
> ​On 28 September 2017 at 17:47, Martin J. Dürst <[email-masked]> 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 like that.

> ​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:
> 

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,