obsoleted by reliability thru replication and Catalogs: resource description and discovery.Dan Connolly, 8 Apr 1997
The Uniform Resource Locator is beoming a widespread way to address resources on the internet. It's used in WWW, and folks are putting them in email messages, USENET news articles, BibTeX databases, and even business cards, newspaper articles, and magazines.
OK... in all of these cases save the WWW/HTML case, the URL is consumed by a human reader, who has the capability to decide how much of the data is a URL and how much is wrappers, containers, or just other "stuff."
But before long, we'll see URL style hyperlinks in TeX, Adobe's PDF, probably MIME external body references, and all sorts of other data formats where the URL is consoumed wholly by machine with no manual intervention.
Another context where URLs are used more and more is the "desktop message bus" -- cut/copy/paste, drag-n-drop and clipboard types on X, Mac, Windows, and NeXTStep patforms. Apple Events, OLE 2, and even local-area and wide-area RPC systems based on CORBA, and DCE.
So it becomes pretty important to know what the "type" or "bandwidth" of a URL or a URL-based link is -- what's its expressive capability.
For most applications, it appears that a single "token" or "string with no spaces" is enough. The fact that entire HTML forms queries are encoded in URLs regularly shows that this can be pretty expressive.
But for other applications, folks are putting linking information outside the single URL token. In the S-HTTP proposal for example, to make a secure link or a secure form submission, you need a DN or distinguished name attribute (and possibly some others) in addition to the URL. In the BRIO system, additional anchor attributes are necessary to support a rich annotation system.
So what if I want to cut-and-paste a secure link? A link to a replicated object? Do I loose all the info except the URL? Bad news. Perhaps the "type" of a link is not just the HREF part of the anchor tag, but the whole tag: HREF, DN, URN, etc.
I think that replication and other URN issues will surface at the level of the HTML anchor tag. Ultimately, I think that a reliable link will not fit comfortably in one "token." It will look more like a BibTeX entry, a MARC record, a postal address, a business card, or other conventional reference. This is not to say that handier, more fragile links like pathnames, phone numbers, and the like
7.2.2. AncHor Attributes
We define the following new anchor (and form submission) attributes:
- DN -- The distinguished name of the principal who will sign the reply to the dereferenced URL. This need not be speci- fied, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. (See section 7.3.1 for another way for clients to get DNs/certificates). This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
- NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced (see section 4.5).
- CRYPTOPTS -- The cryptographic option information from sec- tion 4. If multiline, this must be quoted to protect the line break information.
HTML anchors can be augmented with meta information about the link: <A HREF="url" META_LANGUAGE="PRDM" META_VERSION="1.0" META_CONTENT="opaque string understood only by browsers with appropriate extension">link</A> HTML anchors are used to represent some of the meta items (inlined annotations, highlight markers, etc.). Specifically, in the absence of a separate tag for annotations in the HTML standard, we use the anchor tag with the following additional attributes: <A HREF="url by which the full annotation can be retrieved separately" NAME="identifier of an annotation (set name plus unique number)" TYPE="annotation (or link)" INFO="whatever is to be displayed by the light-weight viewer" REFTO="which text to highlight"