Re: temporal fragments

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?




At 08:29 -0400 4/7/03, Daniel R. Tobias wrote:
>On 7 Apr 2003 at 16:33, Silvia.Pfeiffer@csiro.au wrote:
>
>>  + 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.
>
>I don't really understand how the MIME type can be used in the
>process of determining whether the fragment identifier is to be
>processed by the client or the server; the MIME type is not revealed
>until a request has been made from the client to the server, and at
>that point it's too late to decide whether or not to include the
>fragment identifier in the request.
>
>Traditionally, fragment identifiers are not included in the request
>to the server, and it would probably break servers if clients were to
>begin including them under existing protocols.  If new standards were
>to call for the fragments to be sent to the server for particular
>MIME types, how is the client to know what type is to be received
>before making the request?
>
>Now, you also say that the URI scheme is to be considered in deciding
>the semantics of fragment identitifers as well, and that is more
>practicable since the client does know this ahead of time.
>
>
>--
>== Dan ==
>Dan's Web Tips: http://webtips.dan.info/
>Dan's Domain Site: http://domains.dan.info/


-- 
David Singer
Apple Computer/QuickTime