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

RE: temporal fragments

From: Dave Singer <singer@apple.com>
Date: Mon, 28 Apr 2003 15:43:31 -0700
Message-Id: <p0521064cbad35e7417e2@[]>
To: Larry Masinter <LMM@acm.org>, "'Daniel R. Tobias'" <dan@tobias.name>, uri-request@w3.org
Cc: uri@w3.org, Conrad.Parker@csiro.au

At 18:42 -0700 4/26/03, Larry Masinter wrote:
>  > I like Sylvia's idea and concepts, but I agree, I have to be able to
>>  know (client side) how to handle a URL before I even contact the
>>  server.  Indeed, I need to know what I (client) will interpret and
>>  what I want the server to handle.  It seems that the specification of
>>  how fragments are handled should be owned by the protocol (rtsp,
>>  http), not the MIME type, no?
>I don't think so. It's possible (although why one would want
>to do so isn't clear) to serve a SMIL document using rtsp.
>In that case, the fragment identifiers are still SMIL fragments,
>not 'rtsp' fragments.

OK, I am comfortable with passing the untrimmed URL as long as
a) the server can always parse the URI and extract the server-side part and
b) it can't happen that both client and server interpret the fragment.

For example, say I am a client willing to interpret npt time offsets 
in fragments as a 'seek request to the server, but I can't tell if 
this is OK until I get the MIME type back.  I get the MIME type, 
decide it is, seek to there -- but unknown to me, some servers also 
interpret the npt time offset, and so instead of getting, say 2 
minutes in, I start 2 minutes into a clip which starts 2 minutes in, 
and get 4 minutes.

>It may be that if you know the MIME type early in retrieval
>(via FTP, HTTP, RTSP or whatever), you can process the fragment
>identifiers early. However, the _meaning_ depends on the MIME type,
>even though the way you process it might vary depending on
>the protocol.

David Singer
Apple Computer/QuickTime
Received on Monday, 28 April 2003 18:46:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC