atom feed21 messages in org.w3.uritemporal fragments
FromSent OnAttachments
Silv...@csiro.auMar 6, 2003 9:22 pm 
Al GilmanMar 10, 2003 5:57 am 
Silv...@csiro.auMar 20, 2003 7:52 pm 
Paul PrescodMar 20, 2003 10:37 pm 
S. Mike DierkenMar 20, 2003 11:29 pm 
Larry MasinterMar 21, 2003 9:37 am 
Silv...@csiro.auApr 6, 2003 11:33 pm 
John CowanApr 7, 2003 5:34 am 
Silv...@csiro.auApr 7, 2003 5:39 pm 
Silv...@csiro.auApr 7, 2003 9:18 pm 
Paul PrescodApr 7, 2003 10:43 pm 
S. Mike DierkenApr 7, 2003 11:09 pm 
Etan WexlerApr 8, 2003 1:31 am 
Etan WexlerApr 8, 2003 1:31 am 
Larry MasinterApr 17, 2003 12:17 am 
Mark BakerApr 17, 2003 6:26 am 
Roy T. FieldingApr 17, 2003 5:40 pm 
Dave SingerApr 24, 2003 2:36 pm 
Mike DierkenApr 24, 2003 10:19 pm 
Larry MasinterApr 26, 2003 6:42 pm 
Dave SingerApr 28, 2003 3:43 pm 
Subject:temporal fragments
From:Larry Masinter (
Date:Mar 21, 2003 9:37:42 am

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: [] Sent: Thursday, March 06, 2003 9:22 PM To:;; Cc: 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:


-> 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: .txt

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

http://foo/ (start downloading at 14 seconds and 15 frames into

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: .txt

Best Regards,

Silvia Pfeiffer & Conrad Parker.