Re: temporal fragments

Dear Larry, all,

many thanks for your review of our idea and consideration of the 
implications for the URI specification.

Indeed, when looking at rtsp and media streamed over it, a fragment 
specification in a URI pointing to some media will certainly flag to the 
user that the streaming will start at that offset. An offset in rtsp 
makes sense to be specified in two ways:

- the traditional "named" way. This is analogous to the specification of
   <a name="offset"...> in html which gets identified in a URI as
   http://...#offset. Such markers also exist on media files; e.g.
   QuickTime files allow for chapter markers. Specifying them through
   rtsp://...video.mov#offset expresses the expectation to stream from
   that offset. As rtsp streams can be volatile (and thus there is no
   "retrieved" representation of them), the offset interpretation must be
   performed on the server side and not the client side.

- the "timed" way that we proposed as in rtsp://...video.mov#@npt=241.6.
   There is no analogy with html here as the specification of a character
   offset into a html file does not make sense to most people. However,
   with time-continuous data, this makes sense as the timing is an
   inherent property of a time-continuous resource. Therefore our
   suggestion to handle time offsets in the same way as named offsets.

We understand that fragments are well defined for use with text files 
(html in particular), but we don't think they are well suited to media 
files. Therefore we propose the following changes to chapters 4. and 
4.1. in RFC 2396 [Dave, I hope it is ok to use QuickTime as an example 
for demonstrating the use of fragments on time-continuous data]:

===========================================================================
4. URI References

    The term "URI-reference" is used here to denote the common usage of
    a resource identifier.  A URI reference may be absolute or relative,
    and may have additional information attached in the form of a
    fragment identifier.  However, "the URI" that results from such a
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    reference includes only the absolute URI after the fragment
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    identifier (if any) is removed and after any relative URI is resolved
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    to its absolute form.  Although it is possible to limit the
    ^^^^^^^^^^^^^^^^^^^^^
+[I am not sure if this sentence needs to be changed to accommodate the
+ usage we foresee. For the moment I'd say it is ok. If this however
+ implies that fragments are not forwarded to the server, then this
+ should get deleted.]

    discussion of URI syntax and semantics to that of the absolute
    result, most usage of URI is within general URI references, and it is
    impossible to obtain the URI from such a reference without also
    parsing the fragment and resolving the relative form.

       URI-reference = [ absolute-URI / relative-URI ] [ "#" fragment ]

    Many protocol elements allow only the absolute form of a URI with an
    optional fragment identifier.

       absolute-URI-reference = absolute-URI [ "#" fragment ]

    The syntax for a relative URI is a shortened form of that for an
    absolute URI, where some prefix of the URI is missing and certain
    path components ("." and "..") have a special meaning when, and only
    when, interpreting a relative path.  The relative URI syntax is
    defined in Section 5.

4.1 Fragment Identifier

    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.  As such, it is not
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[This part of the sentence should be deleted or replaced by:]
+ to be interpreted either by the user agent after the retrieval action
+ has been successfully completed or by the resource servicing entity.

    part of a URI, but is often used in conjunction with a URI.

       fragment      = *( pchar / "/" / "?" )

    The semantics of a fragment identifier is a property of the data
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    resulting from a retrieval action, regardless of the type of URI used
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    in the reference.  Therefore, the format and interpretation of
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    fragment identifiers is dependent on the media type [RFC2046] of the
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    retrieval result.  The character restrictions described in Section 2
    ^^^^^^^^^^^^^^^^
[I'd like to replace this sentence with the following:]
+ The semantics of a fragment identifier is a property of the scheme
+ and the resource addressed through the fragment-free URI. Therefore,
+ the format and interpretation of fragment identifiers is dependent on
+ the media type [RFC2046] and the protocol used to retrieve the media
+ type. MIME type applications therefore should specify the
+ interpretation of the fragment under different schemes.
+ Example 1:
+ The interpretation of fragments in HTML documents as retrieved with
+ http is that they have to be interpreted by the user agent after the
+ retrieval action has been successfully completed, and that the user
+ agent will forward the reading position to the named anchor given in
+ the fragment identifier if that named anchor exists.
+ Example 2:
+ The interpretation of fragments in QuickTime MOV documents as
+ addressed with RTSP may be that they should be forwarded to the
+ RTSP server who is then expected to serve out the media data from
+ the specified fragment position onwards. The fragment position may
+ either be a reference to a chapter name asprovided in QuickTime's
* chapter track, or a time specification starting with the reserved
+ character "@".
+ Please note that while Example 1 is already commonly accepted,
+ Example 2 is currently just a proposal.

    for a URI also apply to the fragment in a URI-reference.  Individual
    media types may define additional restrictions or structure within
    the fragment for specifying different types of "partial views" that
    can be identified within that media type.

    A fragment identifier is only meaningful when a URI reference is
    intended for retrieval and the result of that retrieval is a document
    for which the identified fragment is consistently defined.
===========================================================================

Looking forward to your comments.

Best Regards,

Silvia.


Larry Masinter wrote:
> 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 Monday, 7 April 2003 02:33:24 UTC