Re: E-E: Re: URI Requirements

Craig A. Finseth wrote:
> 
>    o  Given a URI, it must be possible for a receiver to determine
>       the time period(s) within which the resource can be retrieved
>       from the (also resolved) location. The accuracy of the time
>       period should correspond with the event's granularity as
>       provided by the service signaling system.
>       [Note: the time period in which the resource is valid/meaningful
>        is controlled by the lifecycle of the application calling the
>        resource. That application also controls the synchronization
>        of the time period in which the resource is presented. The URI
>        indicates the time period within which the resource is available.]
> 
> Do you envision that this requirement could be met by the trivial
> implementation of having the open() call fail when the resource is not
> available?
> 


The requirement is about the information in the URI.

So, it may induce the open() call to fail, where the 
open() method is using that information. 
To make sure: I assume you aren't referring to a 
particular, existing 'open()' method. Correct ?

Vice versa, when that method fails it doesn't mean 
this URI requirement is met.


> (This implementation would correspond to the traditional Internet
> implementation: "http://foo.bar.com/xxx" can only be opened when the
> site and files are available.)

As you show with this example, without the time information, 
open() can also be made to fail. In that case the URI requirement 
is clearly not met (opposite to your question above).

You point to a wording improvement needed: I don't think this
timing information on the URI is mandatory. The URI scheme
must support it, but not every URI is obliged to carry the
information. I will adapt the wording to that.


Warner.

Received on Monday, 23 November 1998 12:11:49 UTC