- From: Williams, Stuart <skw@hp.com>
- Date: Tue, 24 Feb 2004 17:45:52 -0000
- To: Larry Masinter <LMM@acm.org>, "'Roy T. Fielding'" <fielding@gbiv.com>
- Cc: uri@w3.org, "'Graham Klyne'" <GK@NineByNine.org>
> Well, after thinking about this a bit, I've changed my mind. > > > I'm trying to understand why it is so important to state such a > > constraint wrt to retrieval and whether or not, maybe on the basis of > > minimal constraint, it was intentionally stated only for retrieval or > > whether it should be more universally applied. > > I think fragment identifiers are only defined for use with > retrieval, because the semantics of the fragment are > (supposed to be, at least) :-) > defined by the media type of the > retrieved result. With other operations, there is no clear media type. That makes sense. However, at least with HTTP other operations, PUT and POST, do have potential to return response messages that carry representations with a media type - (in which case I guess one could argue that they are also a form of retrieval and hence covered - hmmm). > Using fragment identifiers for other purposes, with PUT, > POST, or any other operation, shouldn't be defined in the > IETF 'Standard'. Maybe someone wants to propose some other > semantics for fragment identifiers with operations other than > retrieval, but I don't think this document is the right place > to include those extensions. Yes... I think staying silent about non-retrival frag id semantics is likely best. [Which implies the status-quo wrt the RFC2396bis draft - apologies for the disturbance]. > Larry > -- > http://larry.masinter.net Thanks, Stuart
Received on Tuesday, 24 February 2004 12:46:52 UTC