From: mitra@path.net (Mitra)
Date: Fri, 12 Nov 1993 10:29:33 PDT
In-Reply-To: Larry Masinter <masinter@parc.xerox.com>
To: masinter@parc.xerox.com
Subject: Re: URN to URC resolution scenario
Message-Id: <9311121029.aa08089@pandora.sf.ca.us>
Larry
As I conceived of it, you WOULD use the same scheme to resolve all URN->URL
addresses, the places searched would be hidden at a lower level. If the
schema were to be more vague, as you suggest, then client writers will
simply not use URN's but continue to use URL's which they can
deterministically resolve.
Lets take your examples
}
} E.g., for an ISBN number, you'll check your shelves, your local
} library, a close bookstore, and finally, if you can't find it anywhere
} else, the library of congress.
The places you checked are rather hard for computers to do without arms,
legs and eyes, but in a real scenario, I'd expect that one or more
referencing services would appear for the ISBN area, they would register
their resolvers under the isbn.urn domain.
} For a news identifier, you might check your local news server, a
} couple of the net CDROM authorities, and some of the netnews archive
} sites.
News is a hard one, its neither a good URN nor a good URL and obeys the
properties of neither, in particular it is not location independant
sicne NNTP servers tend to be only available to local clients. I havent
figured out how to handle this degenerate case yet.
}
} For an RFC document, you'd check the various document repositories.
RFC's are easy, if a URN is of the form urn:iana/rfc:1036. Then I'd
look up rfc.iana.urn in the DNS and find a URN->URL resolver for rfc's.
} You don't want to build the URN -> URL resolution method into the
} design of URN, do you?
I dont want to build THE urn->url resolution method into the design, I
do want to build A method into the design, otherwise URN's are only
usefull for the equality test, and not for resolution.
- Mitra