temporal fragments

I think I finally understood 'the issue' (or at least 'an issue').
Currently, the interpretation of fragment identifiers is defined
by the media type "retrieved" (at least with HTTP and FTP). Fragment
identifiers are not defined for use with URI schemes that don't
"retrieve" a representation in a particular media type.

I think your proposal is that, at least for 'rtsp', that it
might make sense to define a general mechanism for fragment
identifiers that are associated with the _scheme_ instead of
the media type. I think the idea (as I understand it) is that
the rtsp fragments might be somewhat independent of the
'media type', and instead be uniformly applied to any resource
accessed via rtsp.

Is that a fair characterization of the issue?

I'm trying to focus on "how the URI spec might change" issues
rather than the specific details of the temporal fragments
themselves.


> -----Original Message-----
> From: Silvia.Pfeiffer@csiro.au [mailto:Silvia.Pfeiffer@csiro.au] 
> Sent: Thursday, March 06, 2003 9:22 PM
> To: LMM@acm.org; uri-review@ietf.org; uri@w3.org
> Cc: Conrad.Parker@csiro.au
> Subject: 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 Friday, 21 March 2003 12:37:48 UTC