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
>prove it.

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.
Easy, no?

>
>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
door.

   -- David

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
draft-ietf-urn-syntax-01.txt                                        AT&T
Expires in six months                                      November 1996


                               URN Syntax
                 Filename: draft-ietf-urn-syntax-01.txt

   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 [1]. 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 [3], 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
     "get draft-ietf-urn-naptr-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt

Internet-Drafts directories are located at:	
	
     o  Africa:  ftp.is.co.za
	
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it
	
     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:  mailserv@ds.internic.net. In the body type:
     "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt".
							
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              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Thursday, 28 November 1996 17:19:01 UTC