W3C home > Mailing lists > Public > uri@w3.org > March 2003

Re: URIBOF at IETF meeting S.F.

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 10 Mar 2003 08:57:23 -0500
Message-Id: <>
To: Silvia.Pfeiffer@csiro.au, uri@w3.org
Cc: Conrad.Parker@csiro.au

At 12:22 AM 2003-03-07, Silvia.Pfeiffer@csiro.au wrote:
What we want to standardize is a way of describing time offsets,

[some general comments]

+ FYI re process:

Dan Brickley forwarded this proposal to <public-tt@w3.org> and 
<www-annotation@w3.org> on
account of their [presumable] interest in the topic.

+ 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.

+ W3C prior art:

The prior art in W3C is summarized in the SMIL timing model.


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

For an example of the use of this SMIL timing model in annotations, see the 
capabilities in the ANSI/NISO Z39.86 Digital Talking Book:


see also


+ 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

>(start downloading at 14 seconds and 15 frames into bar.mov)
>(start streaming data recorded on 8th March 2003 at half past 2pm)
>(start downloading from the start)
.. is the default, not indicated by fragment.

>(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.

+ Other coordination points:  timestamp formats for SMTP and 

+ 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?


>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:
>-> 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:
>Here are examples for temporal URI fragment offsets that we envisage:
>(start downloading at 14 seconds and 15 frames into bar.mov)
>(start streaming data recorded on 8th March 2003 at half past 2pm)
>(start downloading from the start)
>(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:
>Best Regards,
>Silvia Pfeiffer & Conrad Parker.
Received on Monday, 10 March 2003 09:07:51 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:42 UTC