W3C home > Mailing lists > Public > uri@w3.org > February 2004

RE: Section 3.5. Passing fragment identifiers to other systems.

From: Williams, Stuart <skw@hp.com>
Date: Tue, 24 Feb 2004 17:45:52 -0000
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80801EA0C8F@0-mail-br1.hpl.hp.com>
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

[Which implies the status-quo wrt the RFC2396bis draft - apologies for the

> Larry
> --
> http://larry.masinter.net


Received on Tuesday, 24 February 2004 12:46:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC