Re: [xri] comments on Expires

["Nika Jones" <njones@ouno.com>]

> Joe Gregorio and Martin Atkins are asking on the xri-comments list for
> more clarification on the Expires element.  Particularly, two concerns
> were brought up:
>
>  - what should an XRD consumer do when a document is expired?  obviously
> it should try and fetch a new copy of the document, but how strong of
> language do we want to use here?  "Consumers MUST NOT process an expired
> XRD" ?
>

From XRI Resolution 2.0:

...  A resolver MUST NOT use an XRD after the time stated here ... If the
HTTP transport caching semantics specify an expiry time earlier than the
time expressed in this [element], then a resolver MUST NOT use this XRD
after the expiry time declared in the HTTP headers per section 13.2 of
[RFC2616] ...

I think that says it all.

>  - what happens when the <Expires> date has passed, but the HTTP expires
> date has not yet passed?  Depending on your HTTP stack, when you attempt
> to fetch a fresh copy of the document, you may very likely end up with
> the same document.  Perhaps a recommendation for XRD providers to prevent
> this from happening?
>

I suggest that anytime after the <Expires /> date has past, that the XRD
MUST NOT be used, regardless of HTTP caching. Because as you mentioned the
same document should be served up (hence cache.)

Now the consumer could re-fetch if the two dates were within a certain
time frame or something, but I don't think the spec should decide that.

>
> It's certainly worth noting that XRI Resolution 2.0 explicitly addressed
> both of these cases.  While I do prefer our general approach trying not to
> over specify the relationship between <Expires> and any transport caching
> semantics, I do think this is worth addressing.
>
> Thoughts?
>
> -will
>
>
> On Jan 11, 2010, at 10:47 PM, Drummond Reed wrote:
>
>> On Mon, Jan 11, 2010 at 11:17 AM, Joe Gregorio <joe@bitworking.org>
>> wrote:
>>
>>> On Mon, Jan 11, 2010 at 2:02 PM, Will Norris <will@willnorris.com>
>>> wrote:
>>>>
>>>> On Jan 11, 2010, at 10:44 AM, Joe Gregorio wrote:
>>>>
>>>>> I've reviewed the XRD 1.0 spec and have the following issues:
>>>>>
>>>>> 1. Expires
>>> http://www.oasis-open.org/committees/download.php/35678/xrd-1.0-wd11.html.#element.expires
>>>>>
>>>>> "This dateTime value indicates the time instant after which the
>>>>> document is no longer valid."
>>>>>
>>>>> There is no explanation of what 'valid' means. I presume it is not
>>>>> used in the context of XML, so
>>>>> it is not referring to XML validity. Should none of the information
>>>>> in the XRD document be
>>>>> used after the expiration time? Or only the signed information?
>>>>>
>>>>> What is the relationship between XML validity and this expires
>>>>> validity? That is, if I receive an
>>>>> XRD document that does not conform to the schema, obviously that
>>>>> means it is XML invalid,
>>>>> but does that XML invalidity mean that the document is also invalid
>>>>> in the 'expires' sense?
>>>>
>>>> I'm actually working on this now.  I noticed we had a slight
>>> inconsistency in the spec, as to whether the document was still valid
>>> (in
>>> the expiration sense) at the exact time instant specified by <Expires>.
>>>  In
>>> clarifying that, I've also changed the wording:
>>>>
>>>>   The <Expires> element contains a dateTime value which indicates the
>>> time instant at which the document has expired.
>>>
>>> Avoiding the word 'valid' does avoid the ambiguity with XML validity.
>>> On the other
>>> hand, it does not answer the question of what, in this case, 'expired'
>>> means. Should
>>> none of the information in the XRD file be used? Should a client try
>>> to retrieve a
>>> fresher copy?
>>>
>>
>> I agree with Joe that the spec should state what the client (XRD
>> consumer)
>> either SHOULD or MUST do when the XRD has expired. I believe the simple
>> answer is that the client MUST retrieve a new copy.
>>
>> =Drummond
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>