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.


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

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