URIBOF at IETF meeting S.F.

Dear Larry, URI specialists,

My background is in multimedia, having been involved in the IETF mainly 
in the Audio/Video transport area. We noticed that there will be a 
URIBOF at S.F. and that the URI standard is getting reworked. We'd like 
to put some additional information into this process.

What we really want to be able to do is to reference particular events 
in audio and video files, and we want this to be part of the URI so that 
these references can be used in links from other resources, result lists 
of search engines, or written on the back of a beer coaster.

For some video formats it's possible for the author to include named 
markers, and that's great -- these can already be referenced as a normal
named fragment.

What we want to standardize is a way of describing time offsets, because 
this is a very useful and intuitive concept, and is technically feasible 
in streamable file formats. With a standard notation for time offsets in 
the URI, user agents and servers can behave consistently and users can 
construct URIs in a well-known way when they find an interesting point 
in a media file and wish to reference it.

Our proposal:
-------------
What we want is to address time offsets into videos in a simple, 
intuitive and human readable form. The "#fragment" part of URIs 
naturally lends itself to this task and have therefore come up with the 
following solution, inspired by the timestamp specification in RTSP:

#@npt=14.5

-> the "#" part signifies a fragment specification
-> the "@" tells us to look "at" that time specification
-> the "npt=" part is a time scheme just like in RTSP and we are also 
proposing npt, smpte, smpte-30-drop, smpte-25, and clock
-> the time format itself depends on the time scheme, this one 
signifying a 14.5 seconds offset

More details are specified in an I-D that we have submitted as a 
discussion document to IETF:

http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt

Here are examples for temporal URI fragment offsets that we envisage:

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
(start downloading from the start)

rtsp://foo/bar.rm#@now
(start streaming now)


Fragment handling
-----------------
Currently, the preferred handling of "fragment" offsets is that they are 
only interpreted by the client and not transmitted to the server at all. 
For multimedia data and the "#@..." fragments we're proposing, it makes 
sense, however, to allow the server to interpret the fragment offset in 
order to reduce network load by serving out data only from the offset 
that a user is really interested in receiving.

A more detailed discussion of this is included in the draft:

http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt


Best Regards,

Silvia Pfeiffer & Conrad Parker.

Received on Sunday, 9 March 2003 18:01:25 UTC