RE: Can hash URI description lookups be made to scale?

> The problem is that the first request is at risk of becoming
> GET HTTP/1.0
> because alot of software think (IMO rightly so) that the
> fragment identifier is relevant only within the context
> of interpretation of a representation returned by the
> base URI.

Hi Patrick:

Just wanted to point out that 2396bis has a different take on fragment
identifiers which is somewhat broader than proposed in 2396 which is more or
less restricted to client addressing on a returned representation (see
extract below). Note that the INFO URI scheme is aligned with 2396bis and
makes use of fragment identifiers to identify secondary resources even
though there are /no/ representations returned since INFO URIs are
non-dereferenceable (by specification).

Sorry to belabour this point on fragment identifiers, but we were hoping to
get some (constructive) feedback on the uri list though got no response over
last couple months on our posting of the 2nd revision. Regardless of the
strengths or merits of the INFO URI scheme there are at least some
interesting URI architecture details that could be considered.


	"The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary resource
and additional identifying information. The identified secondary resource
may be some portion or subset of the primary resource, some view on
representations of the primary resource, or some other resource.


	However, if that URI is used in a context that does call for
retrieval and is not a same-document reference (section 4.4), the fragment
identifier is only valid as a reference if a retrieval action on the primary
resource succeeds and results in a representation for which the fragment
identifier is meaningful. "


Received on Friday, 30 January 2004 09:06:25 UTC