- From: Dave Singer <singer@apple.com>
- Date: Mon, 28 Apr 2003 15:43:31 -0700
- 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