Re: Simple solution? Pub. Idents. vs URN.
At 1:40 PM 11/28/96, Tim Bray wrote:
>I take the body of the above discussion (enjoyable though it is)
>as strong evidence that for now, XML should stay with the two modes
>of addressing that it has built in: URL and ID/IDREF. Every discussion
>of FPI's and UR[^L]'s that I have heard has quickly passed out of my
>comprehension and into a desolate area full of ringing assertions about
>document metaphysics and the eschatology of network addressing. Which is
>all very entertaining but not, I submit, our job. URL's and ID/IDREF,
>particularly when extended with some basic HyTime mechanisms, have an
>important virtue; they demonstrably work, and there is the software to
All I was asking, and will continue to ask, is that we add language to the
XML standard so that when URNs are deployed, XML will be compatible with
them. The URN group has finally finished with the "ringing assertions"
(took at least 3 years, by my rough estimate). This is an easy way to throw
a crumb to people who believe (rightly or wrongly) that FPIs do them some
good. We have had several testimonials to their use, and no real argument
against their use than that "they don't work." It seems to me that a claim
that something works, made by someone who uses it is stronger evidence than
a claim by someone else that "No it doesn't really work, you are deluded".
I think that we _ought_ to add FPIs in the same as we have them in SGML,
but instead I am proposing a compromise which will let the IETF URN group
deploy a resolution framework, that we simply agree (in advance) to use.
>XML is not here to be a partisan of hypotheses about the way advanced
>document processing ought to be done in the future; its goal is to specify
>a simple set of practices that (a) are comprehensible (b) are
>compliant with international standards and (c) work.
I have not seen any arguments or evidence that FPIs are not any of these
things. There is a good argument that SGML Open Catalogs are to heavyweight
to be a requirement of XML, but I have not seen one for the proposition
that we should _exclude_ the use of persistent identifiers when they are
available over the internet!
Let's just change "URL" in the XML spec to "URL or URN" everywhere. This
may help the URN effort as well, by getting some users lined up at the
PS I promised some information on URN status, here are the 3 recent,
important docs in that effort. (There are 2 other requirements documents,
also worth reading, but perhaps more "philosophical".)
Here are the current drafts for URNs:
Internet-Draft Ryan Moats
Expires in six months November 1996
Uniform Resource Names (URNs) are intended to serve as persistent
resource identifiers. This document sets forward the canonical syntax
for URNs. Support for both existing legacy and new namespaces is
discussed. Requirements for URN presentation and transmission are
presented. Finally, there is a discussion of URN equivalence and how
to determine it.
Title : Conventions for the Use of HTTP for URN Resolution
Author(s) : R. Daniel
Filename : draft-ietf-urn-http-conv-00.txt
Pages : 6
Date : 11/21/1996
The URN-WG was formed to specify persistent, location-independent names for
network accessible resources, and resolution mechanisms to retrive the
resources given such a name. At this time the URN-WG is considering one
particular resolution mechanism, the NAPTR proposal . That proposal does
not get the client software all the way from the URN to the resource.
Instead, it gets the client from a URN to a "resolver", which is a system
that can then tell the client where the resource is. The NAPTR draft
defines a "resolution protocol" to be the protocol used to speak to a
resolver in order to obtain the resource, its location(s), or other
information about the resource. The NAPTR proposal allows different
resolution protocols to be used for commuicating with resolvers.
This draft establishes conventions for encoding URN resolution requests and
responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of
this draft is to define a convention that is simple to implement and will
allow existing HTTP servers to easily add support for URNresolution. We
expect that the resolution databases that arise will be useful when more
sophisticated resolution protocols are developed later.
Title : Resolution of Uniform Resource Identifiers using the
Domain Name System
Author(s) : R. Daniel, M. Mealling
Filename : draft-ietf-urn-naptr-01.txt
Pages : 13
Date : 11/21/1996
Uniform Resource Locators (URLs) are the foundation of the World Wide Web,
and are a vital Internet technology. However, they have proven to be
brittle in practice. The basic problem is that URLs typically identify a
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there
a graceful way of replicating the resource located by the URL to achieve
better network utilization and/or fault tolerance. Uniform Resource Names
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of
identifiers known as Uniform Resource Identifiers (URIs).
This document describes a new DNS Resource Record, NAPTR (Naming Authority
PoinTeR), that provides rules for mapping parts of URIs to domain names.
By changing the mapping rules, we can change the host that is contacted to
resolve a URI. This will allow a more graceful handling of URLs over
long time periods, and forms the foundation for a new proposal for
Uniform Resource Names.
In addition to locating resolvers, the NAPTR provides for other naming
systems to be grandfathered into the URN world, provides independence
between the name assignment system and the resolution protocol system,
and allows multiple services (Name to Location, Name to Description,
Name to Resource, ...) to be offered. In conjunction with the SRV RR
proposal , the NAPTR record allows those services to be replicated
for the purposes of fault tolerance and load balancing.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: email@example.com. In the body type:
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
I am not a number. I am an undefined character.
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________