Re: OCLC's URN Services Proposal

Some comments in reply to Paul Hoffman's remarks about the OCLC URN Services
Proposal:
 
  > >To support this, one cannot merely say that a URN
  > >resolution request in a document is specified as URN:NA/OS.  Instead,
  > >one should explicitly state the service desired.
  > 
  > I agree as long as the "one" in the second sentence is the user resolving
  > the URN, not the author publishing the URN. Unfortunately, later parts of
  > the proposal only talk about the resolution requests with the desired
  > service as part of the request. If you agree that it is the user (through
  > default settings in her/his client software) who decides what level of
  > response they way, I'd like to see more discussion of this here and in
  > section 5. I'm a bit worried by the examples in section 5.3, because they
  > show requests in angle brackets, making them look like things you might see
  > in free text.

The great majority of the time, the client software will specify the
resolution service(s) to be applied to the URN (see section X).  One
can also imagine situations where it would be useful to let an author
embed a service request in the URN...  to highlight a particular
projection of the metadata for the object, for example.  Do we really
want to make this impossible?

  > 
  > >IV.  This scheme requires a Naming Authority Registry.  Since
  > >information from this Name Authority Registry will be easily cached, we
  > >assume a flat name authority space.
  > 
  > I think that a flat name space is probably sufficient in the short run,
  > particularly because the registered name space is augmented by the DNS.
  > However, I think that the name space should be allowed to become
  > hierarchical if needed in the future. If you agree, a simple fix would be
  > to have the name space be flat initially, reserve a character such as "#"
  > for future use, and if the namespace needs to become hierarchical later,
  > use that character for the hierarchy (for example, "ISSN#OCLC",
  > "CHRIS#OCLC", and so on). You can turn hierarchy on later by extending the
  > proposal then.

Paul's suggestion here is one excellent example of simple means by which
an initially flat name space can be deepened if necessary.

  > >The name authority part of a URN is not necessarily a name authority
  > >ID.  It can also be a resolution host -- a fully qualified domain name
  > >(FQDN) and port to a resolution service.  Any name authority with a
  > >"." in it is assumed to be a resolution host.
  > 
  > I love this, I really do. It gets away from the DNS, which I only
  > reluctantly used in the x-dns-2 scheme Ron and I proposed. I'm very much
  > against mandating a single central registry for URN servers, even with the
  > advantages given in your proposal and in some of the other URN proposals. I
  > think you've hit a real winner here with how to have the best of both
  > worlds: optional central registry and trivial unregistered hierarchy at the
  > same time, and the names are easily distinguishable.

:-)

  > >4.0 Resolution Services
  > 
  > Service names
  > 
  > I'm not comfortable with the request *demanding* a single kind of service
  > because it is very likely that clients can handle more than one. This is
  > why Ron and I used the HTTP Accept header: it lets the server know the
  > variety of services the client can handle and which kind of services the
  > client prefers in one simple mechanism.
  > 
  > With the spec here, if I specify N2C0 but the server can only do N2L, I'll
  > get a negative response back instead of one I could use. You could modify
  > the proposal to make the service field a semicolon-separated list of
  > services, such as "N2L:;N2C0://OCLC/ISBN1234".

Our notion was that any but the simplest of clients will in fact
implement a resolution strategy based on a series of attempted service
resolutions.  This strategy need not even be hardcoded, but rather
could be configured by reading a plug-n-play configuration file that
could be changed.  Implementation aside, we certainly did not envision
a single service.  A semicolon-separated list of  services seems like
it would also work. 
 
  > Also, although you don't specify it in section 4.1, I take it from your
  > examples that "N2Cx" is actually "N2C0" or "N2C1" or "N2CC", but not a
  > combination of them. You should make this more explicit in section 4.1.
  > Then again, I think this is a bad idea too for the same reason: the server
  > should be able to find out what a client can accept and what the client
  > prefers, and go from there.

Some syntax that would let you actually get multiple service requests
fulfilled simultaneously does make sense.  This requires further
thought.  Independence of services is still the safest starting place.
Imagine a service, for example, that resolves to terms and conditions.
Such a service might well be fulfilled by a different resolution server
than the one that resolves location.

  > 
  > RPs
  > 
  > I like this idea very much. Assuming that the RPs are generated by the
  > client software resolving a registered NA and seeing which of the hosts it
  > prefers, this has many big advantages over our DNS-only scheme. More kudos
  > for this.
  > 
  > However, I think you need talk a bit about how RPs are handled when the NA
  > is a FQDN. For example, consider the following valid requests:
  > N2C0:/foo.com/bar.com/abcd
  > N2C0:/foo.com:1234/foo.com/abcd
  > N2C0:/foo.com:1234/foo.com:5678/abcd

Optional Resolution Paths would be tried from left to right until 
successful resolution or all options fail.

  > Also, I think it's too restrictive to insist that an RP be a FQDN: I think
  > that an IP address is also appropriate if the NA is a FQDN. Here, the
  > client could resolve the FQDN through a standard DNS lookup, get back a
  > list of IP addresses, and pick the IP addresses prefered from the list.
  > Thus, I'd like to allow a valid request in your format to be:
  > N2C0:/165.227.249.2;165.227.25.1/proper.com/abcd
  > This is useful if the client knows the network IP prefixes for local
  > networks, or the prefix or full IP address of preferred resolvers.

makes sense to us!

  > 
  > >4.5 URL to URN  (L2N)
  > >4.6 URL to URC  (L2Cx)
  > 
  > I think that these are out of place in this proposal unless you describe it
  > in much more detail. What does this have to do with resolving URNs? How
  > will a user decide which URN resolver to ask for a particular URL? What is
  > the significance of a list of URNs or a list of URCs without
  > metainformation about them, such as who chose them and how?

There is certainly a good deal more to be said about this area, we agree.
Our intent here is to extend the scope of the URI architecture somewhat
(On reflection, perhaps the title of our proposal should be URI Services,
rather than URN services).  Our perspective here is, I believe, not
materially different from what Paul suggests: URNs and URLs are but two
elements in a larger resource description structure... the URC.  The simplest
resolution case requires only a table mapping URNs and URLs, but anything
beyond that will require access to the URC (through one a potentially
large number of  *2Cn services).

  > 
  > >5.1 Resolution Service (Resolver)
  > 
  > This needs much more information. First off, you didn't describe the
  > transmission protocol or default ports. Even more significant, you don't
  > describe the format of the results. These are both very important.
  > 
  > Overall: What URNs resolve to
  > 
  > Throughout the document, you talk about URNs resolving to URLs, and I think
  > that's wrong. Specifically, you say "URNs are meant to be resolved to
  > URLs." I strongly disagree. In my mind, URNs do not resolve just to URLs:
  > they resolve to URCs. A URC could be as single URL, one or more URLs with
  > unstructured metatext for each (that is, a URC0), or a more structured URC.
  > 
  > In linking URNs to just the URLs, you gloss over the desirability of the
  > metatext for users. A good example is a URN such as
  > "URN:ISBN/0-7821-1719-8". I may not care where that book is stored on the
  > Internet, but I might want to know who the author is or when it was
  > published. In this case, the URL is unimportant to me, but the metatext is
  > very important.

Perhaps we have overemphasized the default case: URN --  > URL.  This is
the simple look-it-up service that Web browsers will want, and we think
it is particularly important because it addresses one of the most obvious
problems on the web: location independence.   In actuality, it does not
even solve that problem without the underlying ability to change
URN-->URL mappings (via URCs).   I hope that nothing we have said rules
out the sort of resolution services that Paul alludes to.
  
  > 
  > Summary
  > 
  > I think you've got some ideas that Ron and I may want to include in our
  > proposals. I very much like the method you use for mixing registered and
  > DNS names, and I like how requests can have prioritized RPs. I hope we can
  > come to an understanding on the other issues.
  > 
  > --Paul Hoffman
  > --Proper Publishing
  > 

Thanks for the thoughtful and timely commentary.  We will be editting the
draft to include many of the points made.

for the OCLC URI team,

stu

Received on Thursday, 8 June 1995 09:36:25 UTC