temporal URI fragments (was: URIBOF at IETF meeting S.F.)

Dear Al, all,

many thanks for your general comments and suggestions for change. Thanks 
also for forwarding to other mailing lists - I am happy for any feedback 
and discussions that are starting. We've also had some very interesting 
discussions within the IETF on the mailing list that discusses streaming 
standards.

Let me address some of your issues. Especially the suggestion to use the 
query "?" component of URIs instead of the fragment "#" component to 
specify temporal fragment offsets needs a thorough reply because we have 
important reasons not to do that change. Instead, we propose to slightly 
change the URI RFC to accommodate the needs of large-volume data.

Al Gilman wrote:
> + IMHO re standing of the question for a URI-spec solution:
> 
> Usually we say that the interpretation of #fragment is strictly up to 
> the rules of the type
> of the recovered representation.  In this case it makes sense to think 
> again, because there
> is a broad class of temporal-data datatypes where the representation of 
> the data is peculiar
> to each but the common concept of a proper timebase for each such 
> temporal media object is
> generally interoperable.

Our proposed solution is simple and applicable to any kind of 
time-continuous resource. We are also only proposing a standard way of 
specifying temporal fragment offsets - whether the "recovered 
representation" (i.e. the specific MIME-type under a specific scheme) 
will actually support it, is probably up to the MIME-type proponent. 
This is completely conformant to the existing URI specification as given 
in RFC 2396.


> + W3C prior art:
> 
> The prior art in W3C is summarized in the SMIL timing model.
> 
>  http://www.w3.org/TR/smil20/smil-timing.html#Timing-Overview
> 
> This demonstrates the capability to deal in terms of 
> local-time-base-valued parameters with a
> welter of media types and achieve a unified presentation responsive to 
> one common master
> timebase.
> 
> For an example of the use of this SMIL timing model in annotations, see 
> the annotations
> capabilities in the ANSI/NISO Z39.86 Digital Talking Book:
> 
>   http://www.niso.org/standards/resources/Z39-86-2002.html#Bkmk
> 
> see also
> 
>  http://www.loc.gov/nls/niso/

I have studied the SMIL timing model. It provides a way to synchronise 
media when *authoring* a multimedia presentation. This does not solve 
our specific problem of addressing temporal offsets into time-continuous 
resources (e.g. SMIL playback). So, this is NOT prior art, but only 
another work on time-continuous Web resources.


> + Notation options within the URI framework
> 
> The semantics of this reference fits a natural English expansion of
>   ".. where [some named parameter] is [some given value]"  In other 
> words, it fits
> the generic semantics of the searchPart syntax.  So an alternative 
> syntax for
> this functionality would yield the examples
> 
> 
>> http://foo/bar.mov?smpte=00:00:14:15
>> (start downloading at 14 seconds and 15 frames into bar.mov)
>>
>> rtsp://foo/bar.avi?utc=20030308T143000.00Z
>> (start streaming data recorded on 8th March 2003 at half past 2pm)
>>
>> http://foo/bar.mpg
>> (start downloading from the start)
> 
> .. is the default, not indicated by fragment.
> 
>> rtsp://foo/bar.rm?utc=now
>> (start streaming now)
> 
> 
> needs a parameter name that implies wall-clock time, maybe not utc, but not
> an anonymous reserved token, must be qualified that this token is a 
> metavalue
> in the timeStamp dimension.  That is a limitation that comes with using the
> generic searchPart syntax, but it's worth it.
> 
> This may also be the default.


We have discussed the proposal of using the query "?" component of URIs 
instead of the fragment "#" component for addressing offsets in 
time-continuous resources very intensely in different fora. The main 
reason people come up with this suggestion is our proposal that Web 
resources which are addressed with a temporal fragment offset should be 
served out from that offset only and not from the resource start. There 
are two reasons why we would like to stick with the fragment component:

1) With the temporal offsets we are not querying any databases nor are 
we composing a previously non-existent Web resource. All we are doing is 
addressing a subpart of a Web resource. It is my understanding that that 
was the original intention of creating the fragment component and 
therefore we should make use of it.

2) Query results cannot be cached in network proxies, though Web 
resources can. The use of fragments, which specify subparts of Web 
resources, can enable the network to cache and reuse these subparts, 
which provides scalability to the use of time-continuous data on the 
Internet.


The question then boils down to: what is it that we have to change in 
the "URI generic syntax" standard to enable our suggested use of 
temporal fragments? As it turns out: not much!

The problem comes in where the URI standard says
"When a URI reference is used to perform a retrieval action on the 
identified resource, the optional fragment identifier, separated from 
the URI by a crosshatch ("#") character, consists of additional 
reference information to be interpreted by the user agent after the 
retrieval action has been successfully completed."

While this usage prescriptions may be appropriate for html pages, it is 
not good for Web resources that consist of large volume data, of which 
the user is only interested in receiving a small subpart. Instead, our 
suggestion for the use of fragments is to send them to the server and 
let the server figure out if it can handle the fragment offset. If it 
cannot, it may reject the interpretation of the URI, tell this to the 
client and the client may act accordingly (i.e. either inform the user 
about the problem or ask for the complete resource and perform the 
offset locally). If the server is capable of interpreting the fragment 
offset on the interpreted resource specification, it can serve out the 
resource from the determined offset.

Please note that this still retains all existing ways of using the 
fragment offset because user agents (or Web clients) that have used 
fragment offsets in a standard conformant way, have always stripped off 
the fragment offset from the URI that is being sent to the server. 
Therefore, the server was never even shown a fragment offset. This 
existing usage pattern is still supported for time-continuous data where 
the user agent decides to perform the temporal offset action locally 
only and asks the server for the complete resource. (It may even become 
an additional option for users to set up in their user preferences).


> + Other coordination points:  timestamp formats for SMTP and 
> calendaring-and-scheduling.
> 
> + Other process:  Sounds like an example of what one would want to register
> broadly-applicable property-names for use in ?name-value-pair-list
> searchParts in URIs.  Of course any properties one would be likely to want
> to commonly use are also likely to have standard definitions somewhere
> already.  A registry of short names for standard properties?  Or
> URI-references as property names as in RDF?  All it takes is encoding 
> the '#'.
> But 'who wants to write those things' when 'smpte' works?

Re SMPTE time formats, I have received an update of the standardised 
SMPTE time specifications and we will update the proposal accordingly.
I don't understand what you mean by "calending-and-scheduling".


Look forward to your comments!

Best Regards,

Silvia.

Received on Thursday, 20 March 2003 22:52:13 UTC