- From: Leslie Daigle <leslie@thinkingcat.com>
- Date: Wed, 03 May 2000 21:39:38 -0400
- To: W3C URI List <uri@w3.org>
Howdy, Please indulge me as I reply to a bunch of the messages in this thread in one message -- I had mail failure earlier in the week, and am just catching up. Ray Denenberg wrote: > On the issue "what is a URI?", I see two differing views: > > (a) URI schemes fall into two (or more) broad classes, URL and URN. Each > URI > scheme is cast into one or the other class; thus for example "HTTP:" is > a > URL scheme and "hdl:" a URN scheme. (Of course, there are RFCs that > still > hypothesize about an additional class, URC.) > > (b) The distinction between URL and URN is artificial, and therefore > this > "level" in the URI hierarchy un-necessary. Thus "HTTP:" and "hdl:" are > simply URI schemes. By this view, the concept of "URL" and "URN" would > go > away, and be replaced by "URI". (Which does not mean that any of the > proposed URN schemes would go away; they would just become URI schemes, > as > would HTTP.) An interesting characterization of current views on the issue; my personal thought is that, probably as a result of the (in the end) irreconcilable difference of opinion as to whether one wants/can have a distinction between addresses and names, the situation evolved from a) into c), where c) URN is well-defined: there is a URI scheme, URN:, which does aim to fulfill many of the goals laid out in the original URI documentation. It is not the only scheme that does -- persistence, etc, may well be characteristics sought/provided by others. Thus, hdl: is _not_ a URN, although it can be one or both of: 1. a URI scheme that provides many (perhaps all) of the characteristics originally required for hypothetical URNs, and 2. a URN: namespace (i.e., carried in URNs). In my experiences talking with various communities that have differing needs of identifiers, it has become clear that "applicability" documents are an issue. However, I don't think that's in the purview of the IETF (or probably the W3C, although I'm less familiar with its scope) to produce -- the IETF can produce a document that, for example, lays out the types of subdelegation possible for resolution of URNs, but only repository management specialists, hardware/software developers, and other interested communities can determine if the characteristics provided fulfill _their_ definitions of persistence, etc. I'm not entirely sure how to bridge the gap. Larry Masinter wrote: > http://www.w3.org/Addressing/schemes.html looks like some > notes that someone (Dan Connolly?) keeps in his spare time. > Probably if we got together we could put it into shape > in 3-4 hours of joint work. I really believe this should be a pointer to the IANA registry: http://www.isi.edu/in-notes/iana/assignments/url-schemes It is, after all, their job to keep this up to date. There will, presently, be a similar page for URN namespaces. So, Ray Denenberg wrote: > I would be happy (or at least happier) if there were a document that > listed the > relevant RFCs (and permitted the reader to determine by inference that a > given RFC > is irrelevant, out-of-date, still experimental, etc.) and told you which > RFC to > look at to solve a given problem. But it should be an *authoritative* > document > (not just someone's private web page, or some *informal* W3C page). > > And no, it should not be updated for new URI schemes, and yes, it is not > good to > try to say "everything" in a single document. Have a look at the IANA registry, and see what you think is missing. Personally, I think the data is there, but the information isn't getting out to the desired audience, presumably (at least in part) because they aren't familiar with IETF/IANA/W3C documentation & processes. My concern with this is that I'm not sure they should have to have this familiarity -- just haven't found the way around it yet. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com -------------------------------------------------------------------
Received on Wednesday, 3 May 2000 21:45:54 UTC