RE: introducing URIs [was: 13 Aug Arch Doc...]

In the good old days when we only used URIs for HREFs
and other kinds of hyperlinking, it was safe to
think of a URI as identifying some kind of communication
endpoint (whether mailto:, telnet:, http:, ftp:, or
the like), and to use the interpretation of a fragment
identifier depended on the data type of the object
retrieved. After all, RFC 2396 is pretty clear

   When a URI reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URI, but is often used in conjunction with a URI.

      fragment      = *uric

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.  ...

That's why fragment identifiers can work with
http: and ftp: but not with mailto: and telnet:,
since the latter two don't support 'retrieval'.

Now, URIs and URI references have been pressed into service
to perform the function of identification, not only
of the communication endpoint or a fragment of the
result of a retrieval action, but also (through namespace
names and RDF) as identifiers for abstractions. I think
this is OK merely through reference: the resource vs.
the abstraction for which it stands.

But I don't like throwing out the definition in section 4.1
of RFC 2396 of fragment identifiers, and trying to make fragments
identify resources instead of what that section says.


Received on Sunday, 18 August 2002 22:27:24 UTC