RE: temporal fragments

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