Re: WGLC p6 4.2.1

["Adrien W. de Croy" <[e-mail]>]

OK, thanks for clarification.

So this means that maybe it was just my mis-reading of RFC2616 that led 
me to presume IMS could only come from LM.

I guess this means it's possible to make any request conditional, by 
setting an IMS header.

Should there be maybe some SHOULD level requirements around choice of 
value for this?

e.g. if there was a LM sent on the previous response, it SHOULD be used.

Adrien


------ Original Message ------
From: "Roy T. Fielding" <[e-mail]>
To: "Adrien W. de Croy" <[e-mail]>
Cc: "IETF HTTP Working Group" <[e-mail]>
Sent: 20/03/2013 7:00:24 a.m.
Subject: Re: WGLC p6 4.2.1
>On Mar 17, 2013, at 3:39 PM, Adrien W. de Croy wrote:
>
>>Hi all
>>
>>I see there were some changes made to the 3rd bullet point in 4.2.1 
>>about selection of representations to update with a 304.
>>
>>The new text hints that dates other than those received in a previous 
>>Last-Modified can be used to generate a conditional request with 
>>If-Modified-Since.
>
>Yes, because that has always been allowed, including within my
>original definition when I invented it in 1993.  IMS is used for
>both cache updates and restricted-window traversals (e.g., MOMspider).
>
>>However, there are a number of side-effects with introducing this 
>>concept.
>
>It is not being introduced.  p6 was originally extracted to only talk
>about the use of IMS in caching, but it still needs to deal with all
>valid uses of IMS that were defined in RFC2616, RFC2068, and RFC1945.
>The recent changes in p6 just restores the prior definitions.
>
>This dual use of IMS has never been a problem in the past, though
>concerns about it was one of the main reasons for introducing etags
>as a replacement for validation.
>
>....Roy