Message-Id: <3659974C.DBC2E6E3@natlab.research.philips.com> Date: Mon, 23 Nov 1998 18:11:40 +0100 From: Warner ten Kate <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: 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.