- From: Mike Dierken <mdierken@hotmail.com>
- Date: Thu, 24 Apr 2003 22:19:01 -0700
- To: <uri@w3.org>
----- Original Message ----- From: "Dave Singer" <singer@apple.com> > > 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. When you say 'handle a URL', do you mean you need to understand whether to send a fragment identifier or not? Or do you mean you are doing a retrieval of data identified by the URL and you need to know how to handle the data returned? If it is the first, then the URI specification says that the fragment identifer is never sent to the server. > Indeed, I need to know what I (client) will interpret A piece of client software will always know what is capable of interpreting, I would imagine. > and what I want the server to handle. Well, what you want and what you get are different things. > It seems that the specification of how fragments are handled > should be owned by the protocol (rtsp, http), not the MIME type, no? What do you mean by 'fragment' - do you mean how the fragment identifer portion of a URI is handled by a client? or do you mean a portion of the data returned by a retrieval operation? If by 'how fragments are handled' you mean 'how fragment identifiers in URI are handled', then it is the URI specification that details that. If you mean 'how portions of retrieved data are handled' then it would make sense that the definition of that retrieved data specify how a fragment of data is located and used. For example, if a client wants to get the 5th paragraph of some text, the client would do different things based on whether the returned data was text/plain or text/html (or PDF, or MS-Word, etc.).
Received on Friday, 25 April 2003 01:24:30 UTC