From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 4 16:11:56 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06637 for ; Mon, 4 Sep 2000 16:11:56 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA11423; Mon, 4 Sep 2000 16:16:13 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8617178 for URN-IETF@LISTS.NETSOL.COM; Mon, 4 Sep 2000 16:15:09 -0400 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA11416 for ; Mon, 4 Sep 2000 16:15:08 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.9]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000904200856.JBLW29984.tomts8-srv.bellnexxia.net@thinkingcat.com> for ; Mon, 4 Sep 2000 16:08:56 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39B4017A.D16909C@thinkingcat.com> Date: Mon, 4 Sep 2000 16:09:30 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Updated milestones To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, It is, evidently, time for some housecleaning in the IETF APPs area, and WG chairs have been asked to update their milestones. We are all-but-done -- I've added new individual, _short_term_ milestones for wrapping up the resolution system documents (which the wg didn't disagree to taking on, as they are technically the same as the NAPTR/rds documents that preceded them, and which should be just about done, for the same reasons). As I understand it, Michael will have new versions out shortly to reflect commentary that he has received. I expect it will be appropriate to WG last call those versions of the documents -- hence the short timeframe on the milestones :-) Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- Goals and Milestones: Done Submit revision of URN Framework document as Internet-Draft. Done Submit revised version of the NAPTR proposal as an Internet-Draft. Done Submit Syntax document as an Internet-Draft. Done Submit document detailing the N2L/N2R/etc resolution results as an Internet-Draft. Done Submit document describing one (new) namespace as an Internet-Draft. Done Submit revised N2L/N2R/etc document as an Internet-Draft. Done Submit NAPTR proposal to IESG as Experimental RFC. Submit Framework document to IESG for publication as an RFC. Submit syntax paper to IESG for publication as an RFC. Done Submit paper outlining grandfathering one namespace into the framework as an Internet-Draft. Done Submit revised grandfather namespace document as Internet-Draft. Done Submit N2L/N2R/etc document to IESG for publication as RFC. Done Submit revised new Namespace document as Internet-Draft. Done Submit grandfathered namespace paper to IESG for publication as RFC. Submit new namespace proposal to IESG for publication as RFC. Oct 00 Submit "Assignment Procedures for the URI Resolution using DNS" to IESG as Proposed Standard. Oct 00 Submit "Dynamic Delegation Discovery System (DDDS)" to IESG as Proposed Standard. Oct 00 Submit "A DDDS Database Using The Domain Name System" to IESG as Proposed Standard Oct 00 Submit "URI Resolution using the Dynamic Delegation Discovery System" to IESG as Proposed Standard. From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 4 16:29:17 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06722 for ; Mon, 4 Sep 2000 16:29:17 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA11731; Mon, 4 Sep 2000 16:34:00 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8617251 for URN-IETF@LISTS.NETSOL.COM; Mon, 4 Sep 2000 16:33:54 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA11721 for ; Mon, 4 Sep 2000 16:33:52 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id QAA16639; Mon, 4 Sep 2000 16:17:23 -0400 (EDT) References: <39B4017A.D16909C@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000904161722.B16542@bailey.dscga.com> Date: Mon, 4 Sep 2000 16:17:22 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Updated milestones To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <39B4017A.D16909C@thinkingcat.com>; from leslie@thinkingcat.com on Mon, Sep 04, 2000 at 04:09:30PM -0400 On Mon, Sep 04, 2000 at 04:09:30PM -0400, Leslie Daigle wrote: > Oct 00 Submit "Assignment Procedures for the URI Resolution using DNS" > to IESG as Proposed Standard. > > Oct 00 Submit "Dynamic Delegation Discovery System (DDDS)" to IESG as > Proposed Standard. > > Oct 00 Submit "A DDDS Database Using The Domain Name System" to > IESG as Proposed Standard > > Oct 00 Submit "URI Resolution using the Dynamic Delegation Discovery > System" to IESG as Proposed Standard. These all look fine to me. I expect new versions of the docs to be done by the end of this week... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 5 17:00:04 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13684 for ; Tue, 5 Sep 2000 17:00:03 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA18148; Tue, 5 Sep 2000 17:05:34 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618018 for URN-IETF@LISTS.NETSOL.COM; Tue, 5 Sep 2000 17:04:42 -0400 Received: from lisboa.bn.pt (Lisboa.ibl.pt [193.136.149.1]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id RAA18141 for ; Tue, 5 Sep 2000 17:04:39 -0400 (EDT) Received: (qmail 30890 invoked from network); 5 Sep 2000 21:53:50 -0000 Received: from 195-23-121-72.nr.ip.pt (HELO Borbinha) (195.23.121.72) by lisboa.bn.pt with SMTP; 5 Sep 2000 21:53:50 -0000 References: <39ACA516.2124C3C1@helsinki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: José Luis Borbinha Message-ID: <000f01c0177c$7d8007a0$6500030a@bnp.pt> Date: Tue, 5 Sep 2000 22:00:08 +0100 Reply-To: José Luis Borbinha From: José Luis Borbinha Organization: Biblioteca Nacional Subject: Re: Namespaces for national libraries To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit Hi Juha, it is always good "to hear" from you! I appreciated very much your comments, but I think that we are not really talking about the same issue. I'll do my best to try to clarify it: From: "Juha Hakala" >(...) > Last week Jose Borbinha from the National Library of Portugal sent a URN > namespace registration for namespace "pt-bn", to be used by the library > for various purposes. I have a couple of comments to the document. Please be aware that I didn't send a formal request for a namespace registration. It was a draft of that, at this stage only willing to raise a discussion about its ideas (which is what we are doing now...). This doesn't means that I am insecure about it, but that I really would appreciate positive contributions (which, depending of them, might drive the process even for other (better) results, assuming that I can reach my purposes in the end...) For now, lets retain from you the keyword "for various purposes". Try not to forget it, please! > First, the national libraries have an international initiative for > registering a namespace "NBN", which stands for national bibliography > number. Within this namespace, there will be sub-namespaces based on ISO > country code. So, for instance Portugal can use urn:nbn:pt: for > basically all purposes Jose lists in his draft. Moreover, since > assigning national sub-namespaces within the international NBN namespace > is internal affair, you do not need to bother with the registration of > your own namespace in the IETF. On the other hand, if all national > libraries were to follow Portugal's example, IETF would need to tackle > with >150 registration requests. First, I don't see my proposal as an alternative to yours (I assume that Juha is talking about the IETF draft "draft-hakala-nbn-00.txt"). Some reasons are: -- You claim that "national libraries have an international initiative for registering a namespace". I'm sorry, but we simply don't have NBNs in Portugal... The closest concept we have is our legal deposit number, but it applies only to some genres, representing near 10% of our holdings (and we have a dash "/" on it, btw...). For these cases I'm with you! I can use your URNs very well. You can claim here that even if we don't have a unique numbering system, why don't we use all those we have inside our NBN sub-space, in the way we want it? Well, I don't see why should I use a NBN namespace for resources that belong to other genres, where in some case the "Bibliographic" designation simply will not apply... I'll try to explain this better here (you can also re-read the emails that I exchanged in this list with Michael Mealling, in the last 23 and 24 August...). For now, I'd like to say that I noticed that I need to rewrite the Abstract and Introduction in my text to reflect this purpose, since like they are they don't reflect our target (otherwise, most of your comments would make all the sense, in fact). I guess that I was not too carefully about it -- Also, I don't see any problem in registering 150 namespaces, if they are useful (how many DNSs we have?...). However, if I'll go on with this and it becomes an RFC, it'll be an "Informational" document. We'll be only following the requirements for URN registration... Probably if too many libraries get interested in the concept, we can propose a new RFC to update the RFC 2611 for this scope... > You may remember that I sent an Internet draft registering the NBN > namespace to the urn-nid@apps.ietf.org in Spring. The comments were few, > and generally favorable. So, from IETF point of view the draft is OK. > However, the international working group preparing the text (or, to be >... I don't have objections to it neither (BTW, please be aware that the only author of the actual draft is you, and now you refer to a working group...) > One major issue remains: what to do if the identifier used as URN also > has its own namespace? That is, should we stick to urn:isbn: instead of > urn:nbn:pt: or urn:bn-pt:. The answer, as I see it, depends on the > identifier system and location of the resolution services. Here, I don't see any problem too... I don't understand the URN purpose as a 1:1 solution (I mean, each resource should have only one URN). It simply doesn't make any sense in our actual complex world... On the other side, I accept that we are talking about an N:1 model, so I don't see why can't we have URN namespaces overlapping (btw, that exists already with the books and serials that receive a legal deposit number in Portugal and have also ISBN or ISSN -as I guess it happens almost everywhere...). > I sent 30 minutes ago to the IETF an Internet draft, which registers a > namespace for ISBN, International Standard Book Number. ISBN, as > intelligent code, provides good hints as to where to find a resolution > service. Since there is no global ISBN database, ISBNs need to be > resolved in national bibliography databases. Within DNS system there > needs to be a record for each ISBN group identifier (which means that > about 200 DNS records need to be created). For instance, if ISBN begins > with "951", the DNS record will point to the Finnish national > bibliography database. If ISBN starts with 972, the resolution service > will be found from Lisbon. In some cases a cascade of resolution > services is needed; for ISBNs starting with 3 it is necessary to check > Germany, Austria and Switzerland, in this order. Good! That works if what you define as "resource" for this URN is "the metadata associated to a ISBN registration". But what happens if I want to use a URN based in a ISBN (as I describe in my proposal) for a resource that I have in my library and is related with a book with a ISBN starting by 951 (please note that I didn't say "resource=book", but "resource=something related with a book", which I'll try to clarify better in the end of this email)? In this case the resolution by your proposal would be done by your service in Finland, which is not my purpose (unless I agree to send you my information before, but I'm affraid that shuch would not scale for all the world... This doesn't mean that I don't like your namespace, it means only that I need to use "your" ISBN also for MY namespace, for my purposes... > Therefore I do not see any need for having URNs like > urn:bn-pt:isbn:. In order to enable usage of Portuguese national > bibliography database for resolving ISBN-based URNs, you will only need > urn:isbn:. But things are not always as simple as this. > > ISSN (International Standard Serial Number) is a dumb code. Luckily > there is also a global ISSN database, which currently contains about > million bibliographic records. The ISSN International Centre will > register a URN namespace for ISSN. For technical reasons the only > resolution service that can be used is the one built on top of the ISSN > database (as an aside, the ISSN centre has already built a URN > resolution server and WWW browser plug-in; they work fine). No, things are not always simple... But is you who is willing to propose these global URN namespaces, not me... I accept that you have the right of to do it, but I confess that I don't see many practical reasons for its success... What will give me a resolution of a URN like urn:issn:1234-5678. The title and publisher of the serials? Good! But how I know where to get it in Portugal? > Now, if the National Library of Portugal wants to replace the ISSN > database with their own national bibliography as resolution service, the > only way to do this, as far as I can see, is to define a namespace such > as urn:bn-pt:issn: or urn:nbn:pt:issn:. I don't want to replace anything!!! I just want to let people know where in Portugal they can find a book which ISBN is 953-6003-37-6. It was not published in Portugal, but in Zagreb (it the only foreign book I have here in my desk now...). Tis book exists in the collection of my library, and if it exists also is any other library in Portugal member of PORBASE (our national catalogue), I have that information in a database. So, it makes all the sense to me to define a URN in the form "urn:pt-bn:isbn:953-6003-37-6", and announce that it can be solved by a service I have as http://purl.pt/urn:pt-bn:isbn:953-6003-37-6 (according the examples in my proposal it can be solved also as http://purl.ptisbn:953-6003-37-6, but please note that this is a simple PURL spin-off of the process, which has nothing to do with a formal URN namespace). So, what really I intend to give back in this resolution? Simply an HTML page (in fact, an XML page in the future, with a reference to an XSL file if you want to see it in a browser, or anything else that a possible future URN global resolution framework will require, if the IEFT and/or the W3C promote it...)!!! For now, in this page I intend to present the contents of the record in PORBASE, which includes possible contents of the 856 UNIMARC field and also the reference and call numbers of the same work in all the libraries in Portugal that I know have it... But not only that!!!! It is time to explain you what is a resource to me: it is a metadata record, simply that, in an XML schema that I intend to publish in the future (for now, as we intend to give back HTML, I'm not too worried with that...)!!!! These metadata records will give us information about books, journals, reports, etc., printed and/or digital (or digitized), but they can tell us about other "strange" things such as: - news (one singe news text deposited in our library by the national news agency, why not... it is because of this that in my proposal there is a chance for URNs with a time part, which can refer to very tiny instants) - authorities (yes, why not an URN for each author, which once resolved gives us a metadata record with all I know about him/her/it in my databases -books, notes, short bio, etc...?, which probably will come from an LDAP system...) [btw, we'll start very soon a new European project in authorities to feed this genre of resources, involving libraries and archives... it'll be named LEAF -more news will come in a few months] - and more... > For some reason not clear to me, Jose does not rely on SICI standard > (Serial Item and Contribution Identifier, see RFC2288) for > identification of journal issues and articles or sections within It is simple: we don't have analytic records in PORBASE... But why not in the future? > To sum up: Jose's proposal should be aligned with international > developments. It is also necessary to analyse more carefully how > individual identifier systems actually can be resolved within the URN > framework. Some times domestic arrangements should be avoided; some > other times they may be desirable. I'm sorry, but as far as I know it there is no other "URN framework" than the RFCs 2141 and 2611, and the informational RFC for the registration of namespaces... I don't see were I am out of the scope... There is also another important issue related with my proposal, which is the prefix "pt-" in my namespace. I am surprised that it didn't raised yet any discussion... RFC 2611 is very clear about it, when it says that: ===== FROM RFC 2611 ======= Scope: This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN namespace for "this nation's social security numbers". (...) 4.0 URN Namespace Registration, Update, and NID Assignment Process (...) NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventual national registrations of URN namespaces. ===== =========== ======= These statements, with my assumption that we are dealing with a N:1 problem and not with a 1:1, gave me the trigger to raise the issues that I presented, as also the right to think that I am not interfering with any possible proposal for namespaces like URN:NBN, URN:ISSN, URN:ISBN, URN:SICI (btw, shouldn't this be a subspace of URN:ISSN ????). I want to say that with this initiative I also intend to gain experience to propose in a further step my library as a registration authority for the space "URN:PT-". But I don't think it is already the moment for that. We have a lot to learn before, first with our subnamespaces... It'd be interesting if in some time from now we could come back with an international working group and propose to IETF an RFC twin of 2611 for the registration of national URN subspaces... I'm willing of that... So, it is a fact that this is a local initiative, but I think that its pioneering deserves in a first step an IEFT draft, and if it succeeds, and informational RFC. I tried to explain why I think that I'm different from Juha's perspectives, and on the same time thanks to this opportunity I tried to explain a bit more my real purpose. It is clear to me that I need to rewrite the actual draft a lot, to explain all of this, but I really would like to hear a bit more from you all before... I'm listening!!!!! And it is all for now... Sorry for this VERY long email! Many thanks for your attention (for those of you that survived until here...)! best regards, jlb PS: I'd like to ask to the members of this list that in case you want to reply with comments to specific aspects of the discussion, please do it creating a new thread in the Subject field of your message. Otherwise it can be a mess... _______________________________________ José Luis Borbinha Biblioteca Nacional (National Library of Portugal) Direcção de Serviços de Inovação e Desenvolvimento (Direction of Services for Innovation and Development) Campo Grande, 83 - 1749-081 Lisboa - PORTUGAL Tel./Fax: (+351) 217 982 083 / 217 982 123 From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 5 17:24:24 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14115 for ; Tue, 5 Sep 2000 17:24:23 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA18485; Tue, 5 Sep 2000 17:30:26 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618083 for URN-IETF@LISTS.NETSOL.COM; Tue, 5 Sep 2000 17:30:18 -0400 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA18478 for ; Tue, 5 Sep 2000 17:30:16 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.9]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000905212405.QHTZ29984.tomts8-srv.bellnexxia.net@thinkingcat.com>; Tue, 5 Sep 2000 17:24:05 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <39ACA516.2124C3C1@helsinki.fi> <000f01c0177c$7d8007a0$6500030a@bnp.pt> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id RAA18479 Approved-By: Leslie Daigle Message-ID: <39B56494.46A7E060@thinkingcat.com> Date: Tue, 5 Sep 2000 17:24:36 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Namespaces for national libraries To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit Howdy, I don't have a lot to contribute to this discussion -- I'm very happy to see it happening, though. The one thing that I think is important in consideration of all new namespace proposals is: is there another that exists that already does the job. I think you've carried your point that, although there will be structural similarities between this proposal and the NBN identifiers, what they are meant to identify is in fact different; different services will ensue. This doesn't take away from the NBN effort. If it transgresses polite behaviour in national library circles is not for me to say :-) And, José Luis Borbinha wrote: > There is also another important issue related with my proposal, which is the > prefix "pt-" in my namespace. I am surprised that it didn't raised yet any you are of course right -- per RFC2611, this is not a permissible namespace ID (unless and until we have the country-level scoping discussion, and I don't think it's yet the time). Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 5 21:52:45 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18337 for ; Tue, 5 Sep 2000 21:52:45 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA19682; Tue, 5 Sep 2000 21:58:30 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618224 for URN-IETF@LISTS.NETSOL.COM; Tue, 5 Sep 2000 21:58:05 -0400 Received: from gw.imptech.com.au (imptech.iinet.net.au [203.59.131.160]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA19674 for ; Tue, 5 Sep 2000 21:58:01 -0400 (EDT) Received: from vlc.com.au ([192.168.199.82]) by gw.imptech.com.au (8.9.3/8.9.3) with ESMTP id KAA01553 for ; Wed, 6 Sep 2000 10:24:13 +0800 X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Justin Couch Message-ID: <39B5A195.23B04646@vlc.com.au> Date: Wed, 6 Sep 2000 09:44:53 +0800 Reply-To: Justin Couch From: Justin Couch Organization: The Virtual Light Company Subject: Does the ISBN NID exist? To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit G'day Folks, Just starting a new job shortly for an online book company (startup). Naturally, that leads to the interesting subject of IDing them. The national library number debate is interesting, but I'm going to need a more immediate answer. One of the most often used examples of a URN is using ISBNs. Now, I have a real interest in knowing whether that really exists or not. I did a dig through the RFC's and couldn't find it, so my guess is that it does not exist. If it doesn't, I wouldn't mind getting it running, so I'll have to find out who is responsible for maintaining that system and seeing if we can put a proposal together. -- Justin Couch Author, Java Hacker http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer http://www.j3d.org/ J3D.org The Java 3D Community Site ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism process data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Sep 6 04:33:48 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05732 for ; Wed, 6 Sep 2000 04:33:47 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id EAA21822; Wed, 6 Sep 2000 04:39:30 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618544 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Sep 2000 04:37:40 -0400 Received: from lisboa.bn.pt (Lisboa.ibl.pt [193.136.149.1]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id EAA21806 for ; Wed, 6 Sep 2000 04:37:38 -0400 (EDT) Received: (qmail 32007 invoked from network); 6 Sep 2000 09:26:47 -0000 Received: from trinity.bn.pt (HELO Borbinha) (193.136.149.243) by lisboa.bn.pt with SMTP; 6 Sep 2000 09:26:47 -0000 References: <39ACA516.2124C3C1@helsinki.fi> <000f01c0177c$7d8007a0$6500030a@bnp.pt> <39B56494.46A7E060@thinkingcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: José Luis Borbinha Message-ID: <00b901c017dd$4e786c20$6500030a@bnp.pt> Date: Wed, 6 Sep 2000 09:32:42 +0100 Reply-To: José Luis Borbinha From: José Luis Borbinha Organization: Biblioteca Nacional Subject: Re: Namespaces for national libraries To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Leslie Daigle" (...) >José Luis Borbinha wrote: >> There is also another important issue related with my proposal, which is the >> prefix "pt-" in my namespace. I am surprised that it didn't raised yet any > >you are of course right -- per RFC2611, this is not a permissible >namespace ID (unless and until we have the country-level scoping >discussion, and I don't think it's yet the time). If there is a serious obstacle to address the problem of the national prefixes by this way, I can split my proposal in two threads: - one for my short term objective of having a namespace for the services I described (urn:porbase makes all the sense, since we are in a process of expansion of our services to the "Portuguese speaking world" (and not only...) and we are going to have also the DNS "porbase.org") - another thread for the national urn namespaces However, I fear that for practical reasons in this way we'll finish concentrating in the first issue, and forget about the second, which I really would like to address (with "we" I mean my group here...). It is what my experience tells me... Please advise me here... Thanks! jose borbinha From owner-urn-ietf@LISTS.NETSOL.COM Wed Sep 6 09:01:32 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10956 for ; Wed, 6 Sep 2000 09:01:32 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA23064; Wed, 6 Sep 2000 09:07:22 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618696 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Sep 2000 09:07:06 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA22574 for ; Wed, 6 Sep 2000 06:50:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06911; Wed, 6 Sep 2000 06:44:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009061044.GAA06911@ietf.org> Date: Wed, 6 Sep 2000 06:44:46 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rozenfeld-urn-issn-00.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using The ISSN (International Serial Standard Number)as URN (Uniform Resource Names) within an ISSN-URN Namespace Author(s) : S. Rozenfeld Filename : draft-rozenfeld-urn-issn-00.txt Pages : 13 Date : 05-Sep-00 This draft document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the URN framework as a specific URN namespace identifier. An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by the ISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rozenfeld-urn-issn-00.txt Internet-Drafts are also 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-rozenfeld-urn-issn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rozenfeld-urn-issn-00.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905135251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rozenfeld-urn-issn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rozenfeld-urn-issn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135251.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Wed Sep 6 22:48:56 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28154 for ; Wed, 6 Sep 2000 22:48:56 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA00546; Wed, 6 Sep 2000 22:54:29 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8619930 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Sep 2000 22:52:18 -0400 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA00514 for ; Wed, 6 Sep 2000 22:52:17 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.9]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000907024603.YHNS23574.tomts7-srv.bellnexxia.net@thinkingcat.com>; Wed, 6 Sep 2000 22:46:03 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <39ACA516.2124C3C1@helsinki.fi> <000f01c0177c$7d8007a0$6500030a@bnp.pt> <39B56494.46A7E060@thinkingcat.com> <00b901c017dd$4e786c20$6500030a@bnp.pt> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id WAA00515 Approved-By: Leslie Daigle Message-ID: <39B70186.6B4ED596@thinkingcat.com> Date: Wed, 6 Sep 2000 22:46:30 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Namespaces for national libraries To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit José, José Luis Borbinha wrote: > If there is a serious obstacle to address the problem of the national > prefixes by this way, I can split my proposal in two threads: The serious obstacle runs something like this: In reserving the "-" prefix, we're basically saying that until there is a uniform policy IANA can apply for assigning NIDs with that prefix for any country, none can be assigned. That policy would likely be one of: . Nothing -- anyone who asks for it can have it. . Coordinated with a duly recognized authority within a country The problem is -- what's a "duly recognized authority"? We barely can handle that for country code TLDs in DNS; we're unlikely to figure it out any time soon for URNs. And yet, I don't think we're ready to throw in the towel and go with the first option. It's the same kind of thing we've all heard since childhood -- "if we can't solve it for everybody, we can't give it to anybody". > - one for my short term objective of having a namespace for the services I > described (urn:porbase makes all the sense, since we are in a process of > expansion of our services to the "Portuguese speaking world" (and not > only...) and we are going to have also the DNS "porbase.org") > - another thread for the national urn namespaces > > However, I fear that for practical reasons in this way we'll finish > concentrating in the first issue, and forget about the second, which I > really would like to address (with "we" I mean my group here...). It is what > my experience tells me... It sounds like you've already got a compelling reason not to use the "pt-" based URN NID for the first case; it sounds like what you really want for the second is something specific to the national library of Portugal (and the collections/deposits it manages)? Like BNPORTUGAL? Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 8 12:26:34 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25366 for ; Fri, 8 Sep 2000 12:26:34 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA22307; Fri, 8 Sep 2000 12:30:33 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624185 for URN-IETF@LISTS.NETSOL.COM; Fri, 8 Sep 2000 12:29:59 -0400 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA22300 for ; Fri, 8 Sep 2000 12:29:57 -0400 (EDT) Received: from orpheus (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with SMTP id JAA24007; Fri, 8 Sep 2000 09:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /9Uena0gtUN0oboNpGfnbA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Approved-By: Rob Cameron Message-ID: <200009081623.JAA24007@cs.sfu.ca> Date: Fri, 8 Sep 2000 09:23:43 -0700 Reply-To: Rob Cameron From: Rob Cameron Subject: Article-level Document URIs To: URN-IETF@LISTS.NETSOL.COM I have some questions for members of this list. (1) How important, as a potential application of URIs/URNs, is the ability to link to any article published in a journal, conference proceeding or institutional report series? If you think that this an important application, then (2) how important is it that an article-linking solution based on open identifiers be available? By open identifiers, I am referring to identifiers that can easily be worked out by scholars and librarians for the great bulk of the published literature. I contrast this with a closed identifier model such as the DOI, in which documents have identifiers only when rightsholders register those identifiers. I ask these questions because I have been working in this area and I have a strong interest in developing a system of unambiguous, persistent identifiers for published contributions to our collective knowledge archive, together with a library-based network for resolving references. We do have a specific proposal together with an implemented prototype that comprehensively addresses this topic. This has recently put out as an Internet Draft; an HTML version of the draft has working links to demonstrate the technology. Before saying more about our proposal, I would like to ask (3) if are you aware of any other URN-based proposals that address this topic. I acknowledge that RFC 2288 does note the syntactic issues in addressing this problem using SICI document identifiers, but there is no proposed system that builds on it. Otherwise I can't find any semblance of a proposal that would provide a comprehensive URN-based solution based on an open identifier model. Turning to our proposal, we have focussed on the specific problem of bibliographic linking, much narrower than we understand the scope of the general URN work to be. For one, this gives us an extremely simple resolution model that emphasizes local library services with respect to referenced documents. Specifically, a user in some-domain.edu will be first directed to bibhost.some-domain.edu for information and access to the cited item. If the bibhost does not exist, service is directed to a publisher-specified server or to a global server. The resolution hierarchy has been implemented in a short bit of JavaScript that can be easily pasted into HTML documents that use our framework. (No browser modification required.) The emphasis on local library services allows libraries to provide local context on access to items. This includes access to paper-based as well as digitally held items. It includes access to site-licensed materials that are otherwise not freely available. It includes other kinds of local context, such as document delivery options, access to nonlocal items from partner libraries and the ability to present items in the local language. This is consistent with the philosophy expressed in the SFX work, metadata-based approach to article linking. The focus on bibliographic reference also allows a relatively simple solution to the namespace problem, at least to get started. Our namespace has only three top-level domains: ISSN, ISBN and RDNS. However, RDNS is a parameterized domain that creates individual namespaces for institutions that have a well-established DNS name both owned by the institution and associated with it. RDNS(sfu.ca) is the namespace for Simon Fraser University, RDNS(bn.pt) is the namespace for the National Library of Portugal and so on. We think that our approach is philosophically consistent with the URN concept as it applies to bibliographic linking. However, our mechanisms are different. We have thus proposed that it be created with its own URI scheme, "bibp" for bibliographic protocol. Significantly, this allows us to go beyond N2R or N2L style resolution. Although our Level 1 work deals only with resolution, we think there is substantial area for additional protocol development with respect to metadata sharing (server-to-server interactions under BibP level 2). We invite your comments on the Internet Draft entitled Bibliographic Protocol Level 1: Link Resolution and Metapage Retrieval http://search.ietf.org/internet-drafts/draft-cameron-tatu-bibp-00.txt An HTML version with working BibP links (most recent browsers) is available at http://www.cs.sfu.ca/~cameron/draft-cameron-tatu-bibp-00.html We also invite your answers to the three questions identified above as a survey. Robert D. Cameron, Ph. D. Professor of Computing Science Associate Dean of Applied Sciences 8888 University Drive Simon Fraser University Burnaby, B.C., Canada V5A 1S6 http://www.cs.sfu.ca/~cameron/ From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 8 17:09:05 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00541 for ; Fri, 8 Sep 2000 17:09:04 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA26207; Fri, 8 Sep 2000 17:13:46 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624937 for URN-IETF@LISTS.NETSOL.COM; Fri, 8 Sep 2000 17:13:15 -0400 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA26195 for ; Fri, 8 Sep 2000 17:13:14 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.101]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000908210700.KQQY29984.tomts8-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 8 Sep 2000 17:07:00 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39B95505.BE476CE3@thinkingcat.com> Date: Fri, 8 Sep 2000 17:07:17 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Needed refinements To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hello all, In the process of reviewing recent URN formal NID proposals, the IESG has expressed some concerns over whether the URN working group had adequately described constraints that would maximize the likelihood of public use and overall interoperability of these namespaces. Specifically, the current process (RFC2611) does indicate that a formal NID RFC will be published subject to IESG review, but the suggestion is that there should be more concretely stated guidelines so that new formal NIDs are considered when there is adequate justification that: . there is no existing namespace that would serve the functional purposes of the proposer . the proposed namespace is of sufficient community value that it merits the distinction of a formal NID Terry, I think this speaks to your concern about getting _all_ the criteria out on the table. So, there is discussion to be had -- and consensus to be found on what practical criteria can describe the above (to be published in a revised version of RFC2611). I have some specific proposals, but would rather hear what other people have to say, first... Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 8 17:21:37 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00810 for ; Fri, 8 Sep 2000 17:21:36 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA26484; Fri, 8 Sep 2000 17:26:27 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624992 for URN-IETF@LISTS.NETSOL.COM; Fri, 8 Sep 2000 17:25:00 -0400 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id RAA26460 for ; Fri, 8 Sep 2000 17:24:59 -0400 (EDT) Received: (qmail 21106 invoked from network); 8 Sep 2000 21:18:45 -0000 Received: from ultra.sonic.net (208.201.224.22) by marine.sonic.net with SMTP; 8 Sep 2000 21:18:45 -0000 Received: from sonic.net (bolt [208.201.224.36]) by ultra.sonic.net (8.8.8/8.8.5) with ESMTP id OAA26286 for ; Fri, 8 Sep 2000 14:17:15 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id OAA06272 for urn-ietf@LISTS.NETSOL.COM; Fri, 8 Sep 2000 14:21:46 -0700 Approved-By: Terry Allen Message-ID: <200009082121.OAA06272@sonic.net> Date: Fri, 8 Sep 2000 14:21:46 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re needed refinements To: URN-IETF@LISTS.NETSOL.COM [reply-to is being munged ...] Leslie wrote: | In the process of reviewing recent URN formal NID proposals, the | IESG has expressed some concerns over whether the URN | working group had adequately described constraints that would | maximize the likelihood of public use and overall interoperability | of these namespaces. | | Specifically, the current process (RFC2611) does indicate that a | formal NID RFC will be published subject to IESG review, but | the suggestion is that there should be more concretely stated | guidelines so that new formal NIDs are considered when there | is adequate justification that: | | . there is no existing namespace that would serve the | functional purposes of the proposer | | . the proposed namespace is of sufficient community | value that it merits the distinction of a formal NID | | Terry, I think this speaks to your concern about getting _all_ the | criteria out on the table. It does, although the criticisms we've heard recently (except about the NBN proposal) were along different lines. I have to say I don't agree that we should consider the first point (aside from informing an applicant about a name space that he may have overlooked), because functional purpose is only part of the story: reliability and trust in the name space administrator may be far more importnat to the user. And the second point is impossibly vague: what community? what kind of value? what IS the "distinction of a formal NID" such that a name space must merit it? and what is "sufficient"? In the meantime, does anyone have any notion of what to do about formal-looking NIDs that haven't been approved, such as those Microsoft is using? best regards, Terry From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 8 17:44:10 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01214 for ; Fri, 8 Sep 2000 17:44:10 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA26911; Fri, 8 Sep 2000 17:48:55 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8625086 for URN-IETF@LISTS.NETSOL.COM; Fri, 8 Sep 2000 17:47:28 -0400 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA26884 for ; Fri, 8 Sep 2000 17:47:26 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.101]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000908214113.JDVO23574.tomts7-srv.bellnexxia.net@thinkingcat.com>; Fri, 8 Sep 2000 17:41:13 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200009082121.OAA06272@sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39B95D0A.E3EA574A@thinkingcat.com> Date: Fri, 8 Sep 2000 17:41:30 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: re needed refinements To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit A quick clarification: Terry Allen wrote: > because functional purpose is only part of the > story: reliability and trust in the name space administrator > may be far more importnat to the user. I think the larger point was to justify the need for a new namespace; so these issues could potentially equally constitute acceptable reasons. > In the meantime, does anyone have any notion of what to do > about formal-looking NIDs that haven't been approved, such > as those Microsoft is using? Part of a rather general problem with Microsoft, I'm afraid. Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 8 18:59:42 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02022 for ; Fri, 8 Sep 2000 18:59:42 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA28470; Fri, 8 Sep 2000 19:04:24 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8625438 for URN-IETF@LISTS.NETSOL.COM; Fri, 8 Sep 2000 19:04:13 -0400 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA28463 for ; Fri, 8 Sep 2000 19:04:12 -0400 (EDT) Received: from thinkingcat.com ([64.229.192.101]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000908225758.DKOL987.tomts5-srv.bellnexxia.net@thinkingcat.com>; Fri, 8 Sep 2000 18:57:58 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200009081623.JAA24007@cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39B96F07.C0490415@thinkingcat.com> Date: Fri, 8 Sep 2000 18:58:15 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Article-level Document URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, As an aside to the WG -- technically, this doesn't fall into the WG's specific mandate, but I suggested to the IESG that this was a good place to circulate for comments. Rob, I'm not going to answer your questions directly, but a few technical issues I had with your draft: > 3.3 Default Local Server > > The key characteristic of BibP Level 1 is the ability for a locally > available server to act as the default BibP server for a particular > user environment. The following conventions apply. > > - The DNS (Domain Name System) alias bibhost is used to identify the > default BibP server (if one exists) in the the local environment > of the web browser or other user agent. For example, if a web > browser accessing a BibP link is operating in the univ.edu domain, > then the typical configuration of the local DNS resolver would > interpret the relative domain name bibhost as the fully qualified > domain name bibhost.univ.edu (if it exists). In accord with the > recommendations of RFC 2219 [RFC2219], bibhost is the conventional > DNS alias for the BibP protocol. For all RFC2219 does recommend certain conventions for naming hosts, you're essentially making it a requirement that the host be so-named in order for a client to "find" it. Some cases where this will be inappropriate: . if the administrator of the bibhost doesn't have control over the DNS entries for the local domain . if there is more than one server within a subnet . if it so happens that the machine named "bibhost" is actually already assigned (unlikely, but possible) Generally speaking, diddling with DNS to do discovery doesn't seem to live up to the robustness & longevity that you seek to provide in these identifiers. Analoguous qualms with: > - A bibhost server must signal its ability to respond to BibP Level > 1 requests by provision of HTTP access to the BibP Identification > Icon at the URL http://bibhost/bibp1.0/bibpicon.jpg. If this icon > is unavailable, a user agent may direct resolution of a BibP link > to the next level in the server hierarchy. > I didn't read the document with the specific intention of trying to implement it, but my feeling was that there are areas that are vague and open to multiple interpretations. Does anyone else have any comments on the technical side of this paper? Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sat Sep 9 09:12:26 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21415 for ; Sat, 9 Sep 2000 09:12:26 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA03170; Sat, 9 Sep 2000 09:16:35 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8626259 for URN-IETF@LISTS.NETSOL.COM; Sat, 9 Sep 2000 09:16:13 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from friendly.realnames.com (friendly.realnames.com [216.86.230.76]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id BAA01447 for ; Sat, 9 Sep 2000 01:23:42 -0400 (EDT) Received: (qmail 19661 invoked from network); 9 Sep 2000 12:21:30 -0000 Received: from unknown (HELO ?10.1.3.155?) (10.1.3.155) by friendly.realnames.com with SMTP; 9 Sep 2000 12:21:30 -0000 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-ID: Date: Fri, 8 Sep 2000 22:17:12 -0700 Reply-To: Yves Arrouye From: Yves Arrouye Subject: Re: re needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <39B95D0A.E3EA574A@thinkingcat.com> Content-Transfer-Encoding: 7bit >> In the meantime, does anyone have any notion of what to do >> about formal-looking NIDs that haven't been approved, such >> as those Microsoft is using? > > Part of a rather general problem with Microsoft, I'm afraid. Part of a general problem with XML people who thought that one can use urn:whatever:some-id to have some sort of unique identifier for their documents' schemas. YA From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 01:02:15 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14544 for ; Mon, 11 Sep 2000 01:02:15 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA12047; Mon, 11 Sep 2000 01:01:10 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627046 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 00:57:35 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id AAA12025 for ; Mon, 11 Sep 2000 00:57:34 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA13655; Mon, 11 Sep 2000 00:51:18 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200009110451.AAA13655@astro.cs.utk.edu> Date: Mon, 11 Sep 2000 00:51:17 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Fri, 08 Sep 2000 17:07:17 EDT." <39B95505.BE476CE3@thinkingcat.com> . there is no existing namespace that would serve the functional purposes of the proposer The problem with this is that the existing namespaces may come with strings, and IESG is not in a good position to determine whether the existing namespaces (and their strings) serve the functional purposes of the proposer. So I would not include this as a consideration, or at least, I would not want it so strongly worded. We should be able to have URN multiple namespaces that serve a particular purpose, even to the point of allowing namespaces to overlap. . the proposed namespace is of sufficient community value that it merits the distinction of a formal NID I do see this as an important consideration. Basically we don't want to burden either NID space or the NID registration process with NIDs that are of little value to the community. Keith From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 08:16:15 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00405 for ; Mon, 11 Sep 2000 08:16:15 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA13868; Mon, 11 Sep 2000 08:15:16 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627334 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 08:13:40 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA13851 for ; Mon, 11 Sep 2000 08:13:38 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id HAA29957; Mon, 11 Sep 2000 07:57:13 -0400 (EDT) References: <39B95505.BE476CE3@thinkingcat.com> <200009110451.AAA13655@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000911075713.C29048@bailey.dscga.com> Date: Mon, 11 Sep 2000 07:57:13 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200009110451.AAA13655@astro.cs.utk.edu>; from moore@CS.UTK.EDU on Mon, Sep 11, 2000 at 12:51:17AM -0400 On Mon, Sep 11, 2000 at 12:51:17AM -0400, Keith Moore wrote: > > . the proposed namespace is of sufficient community > value that it merits the distinction of a formal NID > > I do see this as an important consideration. Basically we don't want > to burden either NID space or the NID registration process with > NIDs that are of little value to the community. I guess we need to further define what we mean by 'community' here before I'm comfortable with this one. The publishing community for example could be using a few NIDs almost completey within their community. Do we consider their needs or some other community when considering their NIDs? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 09:43:53 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02194 for ; Mon, 11 Sep 2000 09:43:53 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA14444; Mon, 11 Sep 2000 09:43:19 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627430 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 09:42:01 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA14435 for ; Mon, 11 Sep 2000 09:42:00 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA20142; Mon, 11 Sep 2000 09:35:44 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200009111335.JAA20142@astro.cs.utk.edu> Date: Mon, 11 Sep 2000 09:35:44 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Mon, 11 Sep 2000 07:57:13 EDT." <20000911075713.C29048@bailey.dscga.com> > > > > . the proposed namespace is of sufficient community > > value that it merits the distinction of a formal NID > > > > I do see this as an important consideration. Basically we don't want > > to burden either NID space or the NID registration process with > > NIDs that are of little value to the community. > > I guess we need to further define what we mean by 'community' here > before I'm comfortable with this one. The publishing community for > example could be using a few NIDs almost completey within their > community. Do we consider their needs or some other community > when considering their NIDs? I guess I would say that the NID needs to benefit a significantly-sized group of people. Keith From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 09:50:40 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02347 for ; Mon, 11 Sep 2000 09:50:40 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA14590; Mon, 11 Sep 2000 09:50:13 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627464 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 09:50:05 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA14583 for ; Mon, 11 Sep 2000 09:50:03 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id JAA00136; Mon, 11 Sep 2000 09:33:35 -0400 (EDT) References: <20000911075713.C29048@bailey.dscga.com> <200009111335.JAA20142@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000911093335.A123@bailey.dscga.com> Date: Mon, 11 Sep 2000 09:33:35 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200009111335.JAA20142@astro.cs.utk.edu>; from moore@cs.utk.edu on Mon, Sep 11, 2000 at 09:35:44AM -0400 On Mon, Sep 11, 2000 at 09:35:44AM -0400, Keith Moore wrote: > > > . the proposed namespace is of sufficient community > > > value that it merits the distinction of a formal NID > > > > > > I do see this as an important consideration. Basically we don't want > > > to burden either NID space or the NID registration process with > > > NIDs that are of little value to the community. > > > > I guess we need to further define what we mean by 'community' here > > before I'm comfortable with this one. The publishing community for > > example could be using a few NIDs almost completey within their > > community. Do we consider their needs or some other community > > when considering their NIDs? > > I guess I would say that the NID needs to benefit a significantly-sized > group of people. I'm good with that as long as we explicitly say that we use a loose definition of 'benifit'. In my example above some would say that the only people who direclty benifit are a couple of publishers whereas I would claim that the people who benifit are the much larger number of those publisher's customers.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 10:42:11 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03778 for ; Mon, 11 Sep 2000 10:42:10 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15401; Mon, 11 Sep 2000 10:41:20 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627603 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 10:39:51 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from elsoxfs12417.elsevier.co.uk (elsoxfs12417.elsevier.co.uk [193.131.222.39]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15216 for ; Mon, 11 Sep 2000 10:18:53 -0400 (EDT) Received: from elsoxfs12414.elsevier.co.uk (unverified) by elsoxfs12417.elsevier.co.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 11 Sep 2000 15:09:01 +0100 Received: from elsoxfs12303.elsevier.co.uk (elsoxfs12303.elsevier.co.uk [193.131.217.219]) by elsoxfs12414.elsevier.co.uk (2.6 Build 1 (Berkeley 8.8.6)/8.8.4) with ESMTP id PAA00054; Mon, 11 Sep 2000 15:12:06 +0100 Received: by elsoxfs12303.elsevier.co.uk with Internet Mail Service (5.5.2448.0) id ; Mon, 11 Sep 2000 15:12:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <97A4BBFAC1B9D211B2620008C71EF88102EA115C@ELSOXFS12305> Date: Mon, 11 Sep 2000 15:12:02 +0100 Reply-To: "Paskin, Norman (DOI-ELS)" From: "Paskin, Norman (DOI-ELS)" Subject: Re: [Fwd: Article-level Document URIs] To: URN-IETF@LISTS.NETSOL.COM This posting was copied to me as it mentions DOIs. (1) the ability to link is surely the basis of the web, so is needed; (2) creating a system of identifiers which Rob characterises as "open" to do it is possible - but that's not really the point. I am not commenting on the details of Rob's specific proposal here, but making some general points. The terms open and closed unfortunately carry overtones especially on the web which may be misleading; specifically, open = good, closed = proprietary = evil, etc. That's not I believe an accurate characterisation in this case and I suggest using clearer terminology. Open as used by Rob appears to mean that given the item, one can construct the identifier by inspection of the item or a detailed bibliographic record, and algorithm, a property more correctly known as affordance, or derived identifiers. Closed appears to mean that the identifier is assigned by an agreed authority, like country codes, etc (maybe we could call these assigned identifiers). Both have their uses. Consider the most widely used and commercially useful non-Web identifiers: UPC/EAN Bar codes for billions of objects; ISBNs for millions of books. Both systems are what Rob calls closed (and I think more usefully described as assigned in a controlled namespace). It's not useful to assign your own bar code to your pack of milk if you expect your grocery store to understand it, though you could, or your own ISBN to a book if it already has one: basically, the UCC/EAN namespace is more useful than your own namespace for milk, the ISBN more useful for ordering from Amazon, etc. What's important is not how the number is arrived at, but its namespace and thereby wide acceptability, authority etc. Numbering does not require an agency and could clearly be automated and distributed. The namespace could be one which is assembled from derived identifiers, as long as everyone follows the appropriate algorithm. But numbering is the least difficult of the issues: in particular an assigning agency can help in controlling associated metadata (defining what this number is identifying) as an aid to interoperability. It may be argued that we can/will be able to automate metadata control and collection too, and do this in a distributed fashion for web objects. In my view, this is not yet possible in a way which results in interoperability. There are some bibliographic identifiers with affordance ("open") - e.g. SICI. As a generalisation they are harder systems to maintain than dumb numbers and they don't have associated metadata other than in the algorthmic computation. The CrossRef article linking system uses DOIs; some publishers are using SICIs as part of the DOI, others are using other identifiers. DOis therefore can contain either assigned or derived identifiers. On the specific issues of linking between articles, some form of identifier is clearly useful. In the past, we've used open identifiers and algorithms for human consumption; we call them bibliographic citations and they are useful but not always unambiguous. An automated identifier scheme must be capable of dealing with linkage not just to articles but to the many new forms of scholarly invocation- and ultimately to anything you choose to use as a citation . I've written more extensively on this under the heading of E-Citations. The issue of whether linkage can be best done by assigned identifier mechanisms or on-the-fly algorithms (essentially derivable identifiers) has been discussed in three NISO/DLF meetings on identifier linkage (see links at www.niso.org). I do not believe this question can be fully considered as one of a number (identifier) in isolation. The context is vital: the associated namespaces, associated structured metadata, whether or not the identifier carries intelligence, and having multiple identifiers for the same entity. All this has been cogently summarised in the indecs project, a small part of which is reproduced below. <<2.1 The principle of Unique Identification Every entity should be uniquely identified within an identified namespace. It is difficult to overstate the importance of this simple and commonplace principle. At one level it can be said that the basis of interoperable metadata is simply about the relationships of recognisably unique identifiers. In pre-digital bibliographic and commerce systems, much of their effectiveness depends on the robustness of identification systems: the UPC/EAN product numbers, the ISBN book identifier and the CAE composer/author/publisher identifier are among the most successful identification systems in use in the world of content management, and form the backbone of highly effective distribution systems in their respective industries. In contrast, where unique identifiers for major entities do not exist or are poorly implemented within a domain, data management costs are higher and simple and effective systems difficult to develop. The absence of unique "party" identifiers for creators and publishers among the major content industries, the scarcely visible implementation of the ISRC for sound recordings, and the lack of a standard agreement or licence identifier in any copyright community are examples of gaps which are crippling for interoperability within a domain, let alone between traditional domains. Multi-media, multi-lingual, multi-national, multipurpose metadata also requires that unique identification applies at all levels, including the use of "controlled vocabularies" for values of properties such as measures, form and type. In truly well-formed metadata the only "free text" properties of an entity are found in its names or titles; an in some cases (for example, in trademarks and in Actors Equity) even names may be protected to ensure their uniqueness in a given domain. Some issues which were once central to debates on identifiers have become much less important in the electronic domain: in particular the question of intelligence, and of multiple identifiers for the same entity. Intelligent identifiers (that is, identifiers which carry some information in their structure relating to the entity they identify, such as a format, date or producer code) are of some value in particular circumstances, but problems of ambiguity or volatility have rendered much of this intelligence unreliable. It is also less important that an entity may have more than one unique identifier, even in the same domain. On the contrary, as entities like multimedia become more complex, or parties such as publishers operate in multi-media, multinational environments, it becomes inevitable that they will acquire more and more domain identifiers, which may or may not require reconciliation. The question of whether or how different identifiers for the same entity should be reconciled is both practical and political and beyond the scope of this document. The development of domains or namespaces within the Internet has helped in the relaxation of pressure on the need for absolute uniqueness in the structure an identifier. URLs or URIs provide mechanisms for universal disambiguation which allow even common terms to assume unique global status. For wider interoperability the most important properties of an identifier are (1) uniqueness within a domain; (2) stability (identifiers should never be changed or transferred); (3) security, whether through protection by watermarking or encryption, and/or by internal consistency through the use of check digit algorithms; and (4) the availability somewhere of some basic descriptive metadata for the entity identified, without which the identifier has only limited use.>> from: http://www.indecs.org/results/archive.htm the final version (pdf)of the indecs "Metadata Framework: Principles, Model and Data Dictionary." -------- Original Message -------- Subject: Article-level Document URIs Date: Fri, 8 Sep 2000 09:23:43 -0700 From: Rob Cameron Reply-To: Rob Cameron To: URN-IETF@LISTS.NETSOL.COM I have some questions for members of this list. (1) How important, as a potential application of URIs/URNs, is the ability to link to any article published in a journal, conference proceeding or institutional report series? If you think that this an important application, then (2) how important is it that an article-linking solution based on open identifiers be available? By open identifiers, I am referring to identifiers that can easily be worked out by scholars and librarians for the great bulk of the published literature. I contrast this with a closed identifier model such as the DOI, in which documents have identifiers only when rightsholders register those identifiers. I ask these questions because I have been working in this area and I have a strong interest in developing a system of unambiguous, persistent identifiers for published contributions to our collective knowledge archive, together with a library-based network for resolving references. We do have a specific proposal together with an implemented prototype that comprehensively addresses this topic. This has recently put out as an Internet Draft; an HTML version of the draft has working links to demonstrate the technology. Before saying more about our proposal, I would like to ask (3) if are you aware of any other URN-based proposals that address this topic. I acknowledge that RFC 2288 does note the syntactic issues in addressing this problem using SICI document identifiers, but there is no proposed system that builds on it. Otherwise I can't find any semblance of a proposal that would provide a comprehensive URN-based solution based on an open identifier model. Turning to our proposal, we have focussed on the specific problem of bibliographic linking, much narrower than we understand the scope of the general URN work to be. For one, this gives us an extremely simple resolution model that emphasizes local library services with respect to referenced documents. Specifically, a user in some-domain.edu will be first directed to bibhost.some-domain.edu for information and access to the cited item. If the bibhost does not exist, service is directed to a publisher-specified server or to a global server. The resolution hierarchy has been implemented in a short bit of JavaScript that can be easily pasted into HTML documents that use our framework. (No browser modification required.) The emphasis on local library services allows libraries to provide local context on access to items. This includes access to paper-based as well as digitally held items. It includes access to site-licensed materials that are otherwise not freely available. It includes other kinds of local context, such as document delivery options, access to nonlocal items from partner libraries and the ability to present items in the local language. This is consistent with the philosophy expressed in the SFX work, metadata-based approach to article linking. The focus on bibliographic reference also allows a relatively simple solution to the namespace problem, at least to get started. Our namespace has only three top-level domains: ISSN, ISBN and RDNS. However, RDNS is a parameterized domain that creates individual namespaces for institutions that have a well-established DNS name both owned by the institution and associated with it. RDNS(sfu.ca) is the namespace for Simon Fraser University, RDNS(bn.pt) is the namespace for the National Library of Portugal and so on. We think that our approach is philosophically consistent with the URN concept as it applies to bibliographic linking. However, our mechanisms are different. We have thus proposed that it be created with its own URI scheme, "bibp" for bibliographic protocol. Significantly, this allows us to go beyond N2R or N2L style resolution. Although our Level 1 work deals only with resolution, we think there is substantial area for additional protocol development with respect to metadata sharing (server-to-server interactions under BibP level 2). We invite your comments on the Internet Draft entitled Bibliographic Protocol Level 1: Link Resolution and Metapage Retrieval http://search.ietf.org/internet-drafts/draft-cameron-tatu-bibp-00.txt An HTML version with working BibP links (most recent browsers) is available at http://www.cs.sfu.ca/~cameron/draft-cameron-tatu-bibp-00.html We also invite your answers to the three questions identified above as a survey. Robert D. Cameron, Ph. D. Professor of Computing Science Associate Dean of Applied Sciences 8888 University Drive Simon Fraser University Burnaby, B.C., Canada V5A 1S6 http://www.cs.sfu.ca/~cameron/ From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 10:43:47 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03838 for ; Mon, 11 Sep 2000 10:43:47 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15420; Mon, 11 Sep 2000 10:43:08 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627627 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 10:41:45 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15395 for ; Mon, 11 Sep 2000 10:41:09 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA21840; Mon, 11 Sep 2000 10:34:53 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200009111434.KAA21840@astro.cs.utk.edu> Date: Mon, 11 Sep 2000 10:34:52 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Mon, 11 Sep 2000 09:33:35 EDT." <20000911093335.A123@bailey.dscga.com> > > > I guess we need to further define what we mean by 'community' here > > > before I'm comfortable with this one. The publishing community for > > > example could be using a few NIDs almost completey within their > > > community. Do we consider their needs or some other community > > > when considering their NIDs? > > > > I guess I would say that the NID needs to benefit a significantly-sized > > group of people. > > I'm good with that as long as we explicitly say that we use a > loose definition of 'benifit'. In my example above some would say that > the only people who direclty benifit are a couple of publishers whereas > I would claim that the people who benifit are the much larger number of > those publisher's customers.... presumably even in these days of consolidation 'the publishing community' is significantly larger than 'a couple of publishers'. an NID that was shared by a large group of publishers would be okay. OTOH, if each publisher had its own NID, then this would be to the detriment of URNs as stable identifiers (since works should be able to be transferred from one owner to another without changing NIDs). this would result in harm, rather than benefit, to the customers of those publishers. ultimately we should work to benefit the community of internet users, rather than the publishers. Keith From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 10:57:16 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04056 for ; Mon, 11 Sep 2000 10:57:15 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15794; Mon, 11 Sep 2000 10:56:38 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627704 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 10:56:29 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15786 for ; Mon, 11 Sep 2000 10:56:27 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA00318; Mon, 11 Sep 2000 10:39:55 -0400 (EDT) References: <20000911093335.A123@bailey.dscga.com> <200009111434.KAA21840@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000911103955.C123@bailey.dscga.com> Date: Mon, 11 Sep 2000 10:39:55 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200009111434.KAA21840@astro.cs.utk.edu>; from moore@cs.utk.edu on Mon, Sep 11, 2000 at 10:34:52AM -0400 On Mon, Sep 11, 2000 at 10:34:52AM -0400, Keith Moore wrote: > > > > I guess we need to further define what we mean by 'community' here > > > > before I'm comfortable with this one. The publishing community for > > > > example could be using a few NIDs almost completey within their > > > > community. Do we consider their needs or some other community > > > > when considering their NIDs? > > > > > > I guess I would say that the NID needs to benefit a significantly-sized > > > group of people. > > > > I'm good with that as long as we explicitly say that we use a > > loose definition of 'benifit'. In my example above some would say that > > the only people who direclty benifit are a couple of publishers whereas > > I would claim that the people who benifit are the much larger number of > > those publisher's customers.... > > presumably even in these days of consolidation 'the publishing community' > is significantly larger than 'a couple of publishers'. an NID that > was shared by a large group of publishers would be okay. OTOH, if each > publisher had its own NID, then this would be to the detriment of URNs > as stable identifiers (since works should be able to be transferred from > one owner to another without changing NIDs). this would result in harm, > rather than benefit, to the customers of those publishers. > > ultimately we should work to benefit the community of internet users, > rather than the publishers. I can go along with some of this (I don't like it because I still want to allow the 'little guy' into the club but I realize I'm in a minority here). My question is how do you say that in a standards document without getting the IESG into a whole hell of a lot of trouble when someone's NID gets refused on these grounds? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 12:33:07 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06074 for ; Mon, 11 Sep 2000 12:33:07 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA16783; Mon, 11 Sep 2000 12:32:23 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8627890 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 12:32:06 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA16776 for ; Mon, 11 Sep 2000 12:32:04 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA25685; Mon, 11 Sep 2000 12:25:50 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200009111625.MAA25685@astro.cs.utk.edu> Date: Mon, 11 Sep 2000 12:25:50 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Mon, 11 Sep 2000 10:39:55 EDT." <20000911103955.C123@bailey.dscga.com> > I can go along with some of this (I don't like it because I still want to > allow the 'little guy' into the club but I realize I'm in a minority here). I don't see this as a little guy vs. big guy issue. Little guys should be able to get NIDs if what they are doing has the potential to benefit a large group of people. But that's not the same thing as saying that everybody should be able to have his own personal NID. > My question is how do you say that in a standards document without > getting the IESG into a whole hell of a lot of trouble when someone's NID > gets refused on these grounds? it's a good question. I think we need to come up with guidelines about NID suitability that are derived from the intended purpose of URNs as long-term stable resource identifiers, and from other URN requirements such as the ability to grandfather existing URN-like namespaces (presumably with a recognizable NID). also, we're talking about Formal (Type III) NIDs here. Experimental or Informal NIDs are also available. seems like applicants for Formal NIDs should be expected to explain why they need a Formal NID and an Experimental or Informal NID isn't good enough for their purposes. one reason that comes to mind would be the desire to grandfather in an existing well-established namespace; another reason *might* be for namespaces that could reasonably be expected to enjoy very wide use. but IMHO one of the things that DOI did right was to use strings of digits as namespace identifiers. it would be desirable for URNs to discourage use of "human readable" NIDs except when there is a convincing case that the use of such NIDs will actually promote adoption of URNs (this is the grandfather case) or the long-term stability of URNs. Keith From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 14:33:50 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07632 for ; Mon, 11 Sep 2000 14:33:50 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA17922; Mon, 11 Sep 2000 14:32:44 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8628107 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 14:31:08 -0400 Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA17910 for ; Mon, 11 Sep 2000 14:31:07 -0400 (EDT) Received: from thinkingcat.com ([64.229.202.152]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000911182451.SOWR19855.tomts6-srv.bellnexxia.net@thinkingcat.com>; Mon, 11 Sep 2000 14:24:51 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200009110451.AAA13655@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39BD237C.B8D04E9D@thinkingcat.com> Date: Mon, 11 Sep 2000 14:25:00 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, [Slipping on my "participant hat"...] Keith Moore wrote: > > . there is no existing namespace that would serve the > functional purposes of the proposer > > The problem with this is that the existing namespaces may come with > strings, and IESG is not in a good position to determine whether the > existing namespaces (and their strings) serve the functional purposes > of the proposer. So I would not include this as a consideration, or > at least, I would not want it so strongly worded. We should be able > to have URN multiple namespaces that serve a particular purpose, > even to the point of allowing namespaces to overlap. Yes, this is true. My personal feeling is that we can't carve this out in stone, but a) it doesn't seem unreasonable that there should be a burden on the proposer to demonstrate that they've at least looked at existing namespaces b) the demonstration should be at the level of showing that it's not just a "not invented here" syndrome that provokes the desire for ignoring what already exists The challenge is... there are no hard & fast rules (without over- constricting namespace possibilities). > . the proposed namespace is of sufficient community > value that it merits the distinction of a formal NID > > I do see this as an important consideration. Basically we don't want > to burden either NID space or the NID registration process with > NIDs that are of little value to the community. I believe this is true, but this is an area which admits a number of different philosophies. In a later message, Keith Moore wrote: > I think we need to come up with guidelines about > NID suitability that are derived from the intended purpose of URNs as > long-term stable resource identifiers, and from other URN requirements > such as the ability to grandfather existing URN-like namespaces > (presumably with a recognizable NID). The rathole we've never before stopped ourselves from falling into is: what are the objectively observable criteria for predicting that a given namespace proposal will succeed in providing unique identifiers with adequate longevity. So, let's try to stay away from those specific issues, and take a step back to focus on the general area of why should a given thing be formally published. Some things that spring to my mind: 1. Openness (openess?) of some or all aspects of the namespace: . consumers will be able to use this namespace to independently assign and use identifiers within it . software developers will be able to build clients to use it: . published resolution mechanism . open access to the data identified . servicing -- independent services can build resolvers to meet the namespace spec Note that not all (few?) namespaces will meet all these criteria: e.g., the "IETF" namespace does not allow independent assignment of URNs within it, but there is enough published to allow software devlopers to build clients or services for it. 2. Widespread community value There are 2 separate aspects here: . widespread (the "Internet" use, not just "intranet" use) . community -- that there is a (widespread) community that it serves, e.g., the libraries of the world Note that this does not always follow from "openness" -- the "application/MSWord" media type is useful to many individuals across the globe whose mail programs can open up the appropriate proprietary software program to view the attachment (okay, so then we all catch viruses and spend a week debugging our machines, but go with the _point_, not the specific example ;-) The key point is -- there has to be value in publishing the spec openly, not just as a "deposit requirement" for getting a particular NID. We would still have the same problems (although perhaps less frequently) if NIDs were randomly-assigned bit strings. I've tried to phrase the above in a way that will be detectable in a well-written namespace proposal document so that "grandfathered" namespaces will fit, but so will as-yet-unheard-of ones that are brought into being specifically for the Internet (publishing, protocols, etc). Thoughts? Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 14:50:30 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07935 for ; Mon, 11 Sep 2000 14:50:30 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA18298; Mon, 11 Sep 2000 14:49:57 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8628197 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 14:48:34 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA18285 for ; Mon, 11 Sep 2000 14:48:33 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA05530; Mon, 11 Sep 2000 14:42:16 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200009111842.OAA05530@astro.cs.utk.edu> Date: Mon, 11 Sep 2000 14:42:16 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: Needed refinements To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Mon, 11 Sep 2000 14:25:00 EDT." <39BD237C.B8D04E9D@thinkingcat.com> > Keith Moore wrote: > > > > . there is no existing namespace that would serve the > > functional purposes of the proposer > > > > The problem with this is that the existing namespaces may come with > > strings, and IESG is not in a good position to determine whether the > > existing namespaces (and their strings) serve the functional purposes > > of the proposer. So I would not include this as a consideration, or > > at least, I would not want it so strongly worded. We should be able > > to have URN multiple namespaces that serve a particular purpose, > > even to the point of allowing namespaces to overlap. > > Yes, this is true. My personal feeling is that we can't carve > this out in stone, but > > a) it doesn't seem unreasonable that there should be a burden > on the proposer to demonstrate that they've at least looked > at existing namespaces agreed. > b) the demonstration should be at the level of showing that > it's not just a "not invented here" syndrome that provokes > the desire for ignoring what already exists maybe. I'm confortable with "not invented here" provided that the applicant demonstrates some understanding of what has already been invented and can argue that the new proposal is different in some way. (which might be as simple as saying "even though our proposal is similar to XYZ's, XYZ should not have a monopoly on URN assignments of this type") > The challenge is... there are no hard & fast rules (without over- > constricting namespace possibilities). given that we want URNs to last for decades, it will be decades before we really understand how well the policies/procedures/rules work. so at this stage we should have few hard-and-fast rules; in a few years or tens of years we might want more. > > . the proposed namespace is of sufficient community > > value that it merits the distinction of a formal NID > > > > I do see this as an important consideration. Basically we don't want > > to burden either NID space or the NID registration process with > > NIDs that are of little value to the community. > > I believe this is true, but this is an area which admits a number of > different philosophies. agreed. > In a later message, Keith Moore wrote: > > I think we need to come up with guidelines about > > NID suitability that are derived from the intended purpose of URNs as > > long-term stable resource identifiers, and from other URN requirements > > such as the ability to grandfather existing URN-like namespaces > > (presumably with a recognizable NID). > > The rathole we've never before stopped ourselves from falling into > is: what are the objectively observable criteria for predicting > that a given namespace proposal will succeed in providing unique > identifiers with adequate longevity. I don't think (and didn't intend to suggest) that we should insist that a NID proposal demonstrate characteristics that ensure success (as if we could even define such characteristics!) but rather that our criteria for evaluation of new NID proposals should follow from the intended purposes of URNs. > The key point is -- there has to be value in publishing the spec > openly, not just as a "deposit requirement" for getting a particular > NID. We would still have the same problems (although perhaps less > frequently) if NIDs were randomly-assigned bit strings. I agree with this also. There's little point in having a formal NID if publication of the specifications for that NID doesn't result in some community benefit. Though for the case of grandfathering in an existing namespace, a public document of the form "this is how you translate FOO identifiers to/from URNs..." would provide such a benefit even if it did not provide details of assignment, resolution, etc. However I suspect that the granting of a formal NID also constitutes some sort of statement by IETF about the suitability of that namespace as a part of URN space, so I would say that both the suitability of the namespace and the value of publication of the RFC should be considered. Keith From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 15:19:29 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08312 for ; Mon, 11 Sep 2000 15:19:29 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA18879; Mon, 11 Sep 2000 15:18:48 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8628317 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 15:17:11 -0400 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA18853 for ; Mon, 11 Sep 2000 15:17:10 -0400 (EDT) Received: from orpheus (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with SMTP id MAA21083; Mon, 11 Sep 2000 12:10:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0zwEN1GfHEYxu8D9F8gF5g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Approved-By: Rob Cameron Message-ID: <200009111910.MAA21083@cs.sfu.ca> Date: Mon, 11 Sep 2000 12:10:51 -0700 Reply-To: Rob Cameron From: Rob Cameron Subject: The URN WG and Bibliographic Protocol To: URN-IETF@LISTS.NETSOL.COM Leslie Daigle has raised two important issues with respect to BibP (bibliographic protocol) and its approach to article-level document URIs. First she commented that the proposal does not fall under the specific mandate of the URN WG. I agree and suggest that some general discussion is appropriate but detailed discussions of small points be left to another forum. Second, she raised some questions about the robustness of the resolution model. However, we think the robustness, simplicity, fitness for purpose, and the deployment advantage of the resolution model ought to be compelling. The resolution model is based on the relative domain name feature that is a widely-deployed and rock-solid feature of DNS. Use of this feature in protocol development is recommended in RFC 2219 (Best Current Practice 17). Briefly stated, BibP requests are first directed to a host named "bibhost" if that host exists (a global service otherwise). Thus, requests from users in the yale.edu domain would be directed to bibhost.yale.edu, requests from sfu.ca would be directed to bibhost.sfu.ca, and requests from compaq.com would be directed to bibhost.compaq.com. Simple. (Detail: the authentication mechanism deals with an accidental preexisting bibhost.) Although simplicity is good, what is particularly important for us is to match the resolution model to its purpose: providing bibliographic reference services in response to article-identifier "clicks". Here is where the model shines: the bibhost mechanism allows libraries at each institution the first crack at providing bibliographic services tailored to incorporate local context (local holdings, site licensed access, document delivery options and so on). Furthermore, the resolution model supports natural scalability of the network: as the network grows, each additional bibhost pulls load off the global services. Fourthly, the deployment advantage of our model over possible URN-based approaches ought to count for something as well. That is, the DNS-side of our resolution model is fully deployed now. Furthermore, with a very short bit of Javascript, we have a client-side deployment in the great majority of existing web browsers. Of course, we are also working on BibP-aware versions of many web clients to eliminate the dependency on JavaScript. Libraries may immediately begin developing and deploying bibhosts to serve their local patrons. Returning now briefly to the role of this discussion on the URN WG list. We hope that BibP is of interest to some list members and also hope to attract expressions of interest and constructive feedback. Of course, direct e-mail to me rather than responses to the list would be welcome. In addition, we hope at some point to request a formal statement from the URN WG to the IESG with respect to BibP. I hope that the statement will recognize that BibP is addressing an important problem with an approach that is worth exploring, notwithstanding some overlap with the URN work. Robert D. Cameron, Ph. D. Professor of Computing Science Associate Dean of Applied Sciences 8888 University Drive Simon Fraser University Burnaby, B.C., Canada V5A 1S6 http://www.cs.sfu.ca/~cameron/ From owner-urn-ietf@LISTS.NETSOL.COM Mon Sep 11 16:15:20 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08713 for ; Mon, 11 Sep 2000 16:15:20 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA19526; Mon, 11 Sep 2000 16:14:38 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8628456 for URN-IETF@LISTS.NETSOL.COM; Mon, 11 Sep 2000 16:14:20 -0400 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA19519 for ; Mon, 11 Sep 2000 16:14:18 -0400 (EDT) Received: from thinkingcat.com ([64.229.202.152]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000911200800.XFKR23574.tomts7-srv.bellnexxia.net@thinkingcat.com>; Mon, 11 Sep 2000 16:08:00 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200009111910.MAA21083@cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39BD3BAA.30EC8128@thinkingcat.com> Date: Mon, 11 Sep 2000 16:08:10 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: The URN WG and Bibliographic Protocol To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Rob, Two points of clarification: Rob Cameron wrote: > In addition, we hope at some point to request a formal statement > from the URN WG to the IESG with respect to BibP. I hope that > the statement will recognize that BibP is addressing an important > problem with an approach that is worth exploring, notwithstanding > some overlap with the URN work. IETF WG's don't make formal statements, per se. Working groups do publish documents that address specific work items in their charters -- which they send to the IESG when there has been consensus in the working group as regards content and technical strengths. As we've agreed, your document is not a URN WG item, and thus is not being examined with a view to changing it to reflect WG consensus. So, there will not be a formal statement to the IESG from the URN WG as regards BibP. Secondly, my _personal_ view is that there is no real problem with the fact that your proposal has some overlap with what the URN WG is working on; it has long been recognized that many different systems for identification and retrieval will need to exist. My personal comments have been offered in the light of where I believe (still) that your proposal is technically flawed in attempting to achieve its own goals. Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Sep 13 08:52:34 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06676 for ; Wed, 13 Sep 2000 08:52:34 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA29825; Wed, 13 Sep 2000 08:51:26 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8629615 for URN-IETF@LISTS.NETSOL.COM; Wed, 13 Sep 2000 08:49:17 -0400 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA29817 for ; Wed, 13 Sep 2000 08:49:11 -0400 (EDT) Received: from orpheus.cs.sfu.ca (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with ESMTP id FAA22533; Wed, 13 Sep 2000 05:42:52 -0700 (PDT) Received: (from cameron@localhost) by orpheus.cs.sfu.ca (8.9.1/8.9.1) id FAA13266; Wed, 13 Sep 2000 05:42:51 -0700 (PDT) Approved-By: Rob Cameron Message-ID: <200009131242.FAA13266@orpheus.cs.sfu.ca> Date: Wed, 13 Sep 2000 05:42:51 -0700 Reply-To: Rob Cameron From: Rob Cameron Subject: Closed vs. Open Identifier Systems To: URN-IETF@LISTS.NETSOL.COM Norman Paskin questions the fairness of terms "closed" and "open" as used to characterizate document identifiers (and their associated resolution/metadata systems). He would prefer distinctions using the more obscure term "affordance". In outlining the distinctions between the DOI approach and that of Bibliographic Protocol/USINs (see http://usin.org ), there are several dimensions along which the closed/open terminology is appropriate. (1) Creation. Librarians and scholars are free to determine USINs based on publication data. DOIs are closed to this possibility. (2) Coverage. The space of items denoted by DOIs may be fairly described as closed: restricted to those articles registered by rightsholders. This is a substantially smaller space than that for which USINs exist now and will remain so for the forseeable future. (3) Resolution. The BibP/USIN framework is open to (and designed for) independent, interoperable resolution services deployed by libraries, document supply services, publishers and others. The DOI framework has a closed resolution model. (4) Metadata production/association. The BibP/USIN framework is open to the independent development of article metadata from many sources. Abstracting and indexing services as well as subject bibliographers can freely participate. (5) Metaservice identification. The BibP/USIN framework anticipates a free market of document metaservices (document delivery, translation, classification and so on), subject only to operation within the legal frameworks for intellectual property (copyright clearance and so on). This is not a goal of the DOI system. Finally, I recognize Norman's point that "open/closed" distinctions carry "free/proprietary" and "good/bad" connotations. Frankly, I think there are some elements of truth and clarity here and I hope to use the connotations to capture some "mind share" for the BibP/USIN work. The DOI/CrossRef initiative has such a substantial lead in mindshare that it ought to have little to fear from our work - unless of course, there is substance to it. Robert D. Cameron Professor of Computing Science Simon Fraser University BibP/USIN Project http://usin.org/ From owner-urn-ietf@LISTS.NETSOL.COM Wed Sep 13 12:20:34 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11531 for ; Wed, 13 Sep 2000 12:20:33 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA01122; Wed, 13 Sep 2000 12:19:06 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8629803 for URN-IETF@LISTS.NETSOL.COM; Wed, 13 Sep 2000 12:18:39 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA01109 for ; Wed, 13 Sep 2000 12:18:37 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id MAA05126 for urn-ietf@lists.netsol.com; Wed, 13 Sep 2000 12:02:13 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000913120212.G4992@bailey.dscga.com> Date: Wed, 13 Sep 2000 12:02:12 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: a detailed technical issue with the DDDS stuff To: URN-IETF@LISTS.NETSOL.COM Hi all, I'm making some final edits to the DDDS documents based on comments I've recieved (only a few which is good!). The issue is with character sets and which ones we use in the DNS Database. In the past we assumed that we were encoding the various flags, services and regexp as 8bit US-ASCII but this probably shouldn't be the case. Here's my technical question: Is it the concensus of this group that I should specify that all of the fields in a NAPTR record that are of the type MUST be in UTF-8? My recommendation is yes but I want to check with the crowd first.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 14 06:49:25 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08179 for ; Thu, 14 Sep 2000 06:49:25 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA05822; Thu, 14 Sep 2000 06:48:37 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8630282 for URN-IETF@LISTS.NETSOL.COM; Thu, 14 Sep 2000 06:48:02 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id BAA04639 for ; Thu, 14 Sep 2000 01:33:21 -0400 (EDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id OAA11179; Thu, 14 Sep 2000 14:27:02 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20000914111000.03179750@sh.w3.mag.keio.ac.jp> Date: Thu, 14 Sep 2000 11:10:28 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: a detailed technical issue with the DDDS stuff To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20000913120212.G4992@bailey.dscga.com> At 00/09/13 12:02 -0400, Michael Mealling wrote: >Hi all, > I'm making some final edits to the DDDS documents based on comments >I've recieved (only a few which is good!). The issue is with character sets >and which ones we use in the DNS Database. In the past we assumed >that we were encoding the various flags, services and regexp as >8bit US-ASCII but this probably shouldn't be the case. Here's my >technical question: > >Is it the concensus of this group that I should specify that all of the >fields in a NAPTR record that are of the type MUST >be in UTF-8? > >My recommendation is yes but I want to check with the crowd first.... I would definitely be with you on this! Regards, Martin. From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 21 08:02:51 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03523 for ; Thu, 21 Sep 2000 08:02:51 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA25009; Thu, 21 Sep 2000 08:08:19 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8636219 for URN-IETF@LISTS.NETSOL.COM; Thu, 21 Sep 2000 08:07:22 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA24600 for ; Thu, 21 Sep 2000 06:46:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02209; Thu, 21 Sep 2000 06:39:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009211039.GAA02209@ietf.org> Date: Thu, 21 Sep 2000 06:39:46 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-dns-ddds-database-01.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-01.txt Pages : 19 Date : 20-Sep-00 This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-01.txt Internet-Drafts are also 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-dns-ddds-database-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-01.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000920142400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000920142400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 21 08:03:19 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03535 for ; Thu, 21 Sep 2000 08:03:19 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA25037; Thu, 21 Sep 2000 08:09:31 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8636222 for URN-IETF@LISTS.NETSOL.COM; Thu, 21 Sep 2000 08:09:24 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA24607 for ; Thu, 21 Sep 2000 06:46:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02223; Thu, 21 Sep 2000 06:39:51 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009211039.GAA02223@ietf.org> Date: Thu, 21 Sep 2000 06:39:51 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-net-procedures-05.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Assignment Procedures for the URI Resolution using DNS Author(s) : M. Mealling, R. Daniel Filename : draft-ietf-urn-net-procedures-05.txt Pages : 9 Date : 20-Sep-00 RFCXXXX defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving 'http://foo.com/' would be to look up a NAPTR record for the domain 'http.URI.ARPA'. URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-05.txt Internet-Drafts are also 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-net-procedures-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-net-procedures-05.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000920142410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-net-procedures-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-net-procedures-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000920142410.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 21 08:03:29 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03547 for ; Thu, 21 Sep 2000 08:03:27 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA25049; Thu, 21 Sep 2000 08:09:40 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8636225 for URN-IETF@LISTS.NETSOL.COM; Thu, 21 Sep 2000 08:09:37 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA24613 for ; Thu, 21 Sep 2000 06:46:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02237; Thu, 21 Sep 2000 06:39:55 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009211039.GAA02237@ietf.org> Date: Thu, 21 Sep 2000 06:39:55 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-01.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-01.txt Pages : 16 Date : 20-Sep-00 This document describes a the Dynamic Delegation Discovery System or DDDS which, when applied to a unique string will produce a series of rules that describe the various delegations that may exist based on the syntax of that string. Since the DDDS is an abstract algorithm, this specification does not define either an application or a rule database. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-01.txt Internet-Drafts are also 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-ddds-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-01.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000920142418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000920142418.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 21 08:03:41 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03558 for ; Thu, 21 Sep 2000 08:03:41 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA25062; Thu, 21 Sep 2000 08:09:49 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8636228 for URN-IETF@LISTS.NETSOL.COM; Thu, 21 Sep 2000 08:09:46 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA24629 for ; Thu, 21 Sep 2000 06:46:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02251; Thu, 21 Sep 2000 06:40:00 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009211040.GAA02251@ietf.org> Date: Thu, 21 Sep 2000 06:40:00 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-uri-res-ddds-01.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URI Resolution using the Dynamic Delegation Discovery System Author(s) : M. Mealling Filename : draft-ietf-urn-uri-res-ddds-01.txt Pages : 23 Date : 20-Sep-00 A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with [10] and [9], obsoletes RFC 2168[12] and updates RFC 2276[8]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-01.txt Internet-Drafts are also 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-uri-res-ddds-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-01.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000920142427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-uri-res-ddds-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000920142427.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 22 08:50:31 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12860 for ; Fri, 22 Sep 2000 08:50:30 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA03191; Fri, 22 Sep 2000 08:55:21 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8637307 for URN-IETF@LISTS.NETSOL.COM; Fri, 22 Sep 2000 08:54:02 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA02789 for ; Fri, 22 Sep 2000 06:52:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05099; Fri, 22 Sep 2000 06:46:39 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009221046.GAA05099@ietf.org> Date: Fri, 22 Sep 2000 06:46:39 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-02.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-02.txt Pages : 16 Date : 21-Sep-00 This document describes a the Dynamic Delegation Discovery System or DDDS which, when applied to a unique string will produce a series of rules that describe the various delegations that may exist based on the syntax of that string. Since the DDDS is an abstract algorithm, this specification does not define either an application or a rule database. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-02.txt Internet-Drafts are also 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-ddds-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-02.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000921133715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000921133715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 22 16:17:36 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25923 for ; Fri, 22 Sep 2000 16:17:35 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA06035; Fri, 22 Sep 2000 16:23:33 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8637654 for URN-IETF@LISTS.NETSOL.COM; Fri, 22 Sep 2000 16:23:10 -0400 Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA06028 for ; Fri, 22 Sep 2000 16:23:08 -0400 (EDT) Received: from thinkingcat.com ([64.229.197.205]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000922201650.FGIP19855.tomts6-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 22 Sep 2000 16:16:50 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200009211039.GAA02209@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39CBBE19.9F336CC@thinkingcat.com> Date: Fri, 22 Sep 2000 16:16:25 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: WG last call -- DDDS documents To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, The document authors have finished making the suggested edits, and as no one has raised an objection to the restructuring of the documents, I'm putting the following 4 documents up for Working Group last call: Dynamic Delegation Discovery System (DDDS) (draft-ietf-urn-ddds-02.txt) Target: Proposed Standard A DDDS Database Using The Domain Name System (draft-ietf-urn-dns-ddds-database-01.txt) Target: Proposed Standard URI Resolution using the Dynamic Delegation Discovery (draft-ietf-urn-uri-res-ddds-01.txt) Target: Proposed Standard Assignment Procedures for the URI Resolution using DNS (draft-ietf-urn-net-procedures-05.txt) Target: BCP Please read them carefully and provide comments (to the list or to the authors) by OCTOBER 6, 2000. Hopefully all substantive issues have already been addressed, but we are putting most of these up for standards documents, and we'd better make sure we've dotted our i's and crossed our t's... Thanks, Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Sep 22 18:51:41 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27925 for ; Fri, 22 Sep 2000 18:51:41 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA07027; Fri, 22 Sep 2000 18:57:31 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8637769 for URN-IETF@LISTS.NETSOL.COM; Fri, 22 Sep 2000 18:57:07 -0400 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA07020 for ; Fri, 22 Sep 2000 18:57:06 -0400 (EDT) Received: from thinkingcat.com ([64.229.197.205]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000922225044.QYWZ987.tomts5-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 22 Sep 2000 18:50:44 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39CBE22B.6A68CE2B@thinkingcat.com> Date: Fri, 22 Sep 2000 18:50:19 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, Following up on the discussion of a few weeks ago, here is some proposed text to replace the "III. Formal" section in RFC2611. I've tried to incorporate/address the various comments re. the need to allow overlapping namespaces, as well as other issues identified on this list. This inevitably leaves stuff open to interpretation, although I hope it will be able to capture a reasonable expression of our design goals. Comments please... Leslie. ---- Proposed replacement text for RFC2611 ---- III. Formal: A "Formal" namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to an open and broad base of the Internet community. That is, as in any open standards outcome, publication of the NID proposal would allow persons not immediately associated with the proposer to create new software, or services, or otherwise better carry out their own activities than if the NID publication had not been made. Benefits are expected to be in the form of open accessibility, interoperability, etc. The NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards-track, but it will be subject to IESG review and acceptance pursuant to the guidelines written here (as well as standard RFC publication guidelines). The template defined in section 3.0 may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the urn-nid@apps.ietf.org mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG reviews the document. The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements). Considerations might include: - URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported NOTE: It is expected that more than one namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration. The RFC must also include a "Community Considerations" section, which indicates the dimensions upon which the proposer expects the Internet community to be able to benefit by publication of this namespace. Potential considerations include: - open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client) It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of an externally managed (proprietary) registry (as, e.g., ISBN does), for assignment of URNs in the namespace, but it may still provide broad community benefit if the services associated have openly-published APIs. Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discussed at length the issue of finding objective measures for predicting (a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experience of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification. A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must - not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document. Registrations may be revised by updating the RFC through standard IETF RFC update mechanisms. Thus, proposals for updates may be made by the original authors, other IETF participants, or the IESG. In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period. URN namespace registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN- namespaces/". -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sun Sep 24 12:01:03 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09327 for ; Sun, 24 Sep 2000 12:01:02 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA16940; Sun, 24 Sep 2000 12:06:04 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8638750 for URN-IETF@LISTS.NETSOL.COM; Sun, 24 Sep 2000 12:05:03 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id FAA15295 for ; Sun, 24 Sep 2000 05:17:17 -0400 (EDT) Received: from enoshima (ppp3ppp47.sfc.keio.ac.jp [133.27.12.113]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA23053; Sun, 24 Sep 2000 18:10:43 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20000923112834.009d62f0@sh.w3.mag.keio.ac.jp> Date: Sat, 23 Sep 2000 11:38:55 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <39CBE22B.6A68CE2B@thinkingcat.com> Hello Leslie, I haven't thought through everything in detail, but I think your text is extremely well written and addresses a lot of the problems that have come up recentently. At the moment, I have one general concern and one small comment: The text only speaks about an RFC, not about an I-D. Also, it's not clear whether IESG approval or submission to urn-nid@apps.ietf.org should be first, and in what form. From general IETF experience, it seems that the sequence would be: - Submission to urn-nid@apps.ietf.org as an I-D. - Discussion there, maybe resubmission. - Submission to IESG as an I-D for RFC publication. - RFC publication and registration. But maybe I'm getting something wrong. Anyway, I think it would be extremely helpful if these things were spelled out in the text in order to avoid confusion. I haven't seen such confusion yet in the nid case, but I have seen it for similar registrations where they went together with an RFC. At 00/09/22 18:50 -0400, Leslie Daigle wrote: >---- Proposed replacement text for RFC2611 ---- >It is expected that Formal NIDs may be applied to namespaces >where some aspects are not fully open. For example, >a namespace may make use of an externally managed (proprietary) >registry (as, e.g., ISBN does), for assignment of URNs in the namespace, >but it may still provide broad community benefit if the services >associated have openly-published APIs. I'm a little bit confused by the word API here. Does publication as an RFC provide an API? Are RFCs supposed to include an API definition? If yes, what form would such a definition take? Can some entries in DNS and some resolution services, which maybe you want to refer to, be called an API? (I guess in a very wide sense, that's possible, but it's really stretching the term, and there are probably better terms). Regards, Martin. From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 26 14:56:15 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14358 for ; Tue, 26 Sep 2000 14:56:14 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA29164; Tue, 26 Sep 2000 15:01:30 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8639708 for URN-IETF@LISTS.NETSOL.COM; Tue, 26 Sep 2000 15:00:39 -0400 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA29156 for ; Tue, 26 Sep 2000 15:00:38 -0400 (EDT) Received: from thinkingcat.com ([64.229.197.205]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000926185417.WOUL23574.tomts7-srv.bellnexxia.net@thinkingcat.com>; Tue, 26 Sep 2000 14:54:17 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.0.58.J.20000923112834.009d62f0@sh.w3.mag.keio.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39D0F0B1.4D747963@thinkingcat.com> Date: Tue, 26 Sep 2000 14:53:37 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, "Martin J. Duerst" wrote: > But maybe I'm getting something wrong. Anyway, I think it > would be extremely helpful if these things were spelled out > in the text in order to avoid confusion. I haven't seen Yep, good point, I'll add text to clarify that (both for formal and informal NIDs). > >but it may still provide broad community benefit if the services > >associated have openly-published APIs. > > I'm a little bit confused by the word API here. Does publication > as an RFC provide an API? Are RFCs supposed to include an API > definition? If yes, what form would such a definition take? > Can some entries in DNS and some resolution services, which maybe > you want to refer to, be called an API? (I guess in a very wide > sense, that's possible, but it's really stretching the term, > and there are probably better terms). True. How about: "It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of an externally managed (proprietary) source for assignment of URNs in the namespace, while providing open access, and enough technical detail for unrelated parties to build tools to make use of the names and services. For example, the "IETF" namespace has names assigned based on procedures defined for RFC series (closed), but the convention for mapping such URNs to document locations is publicly stated and third parties can make use of these URNs." Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 26 14:57:00 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14378 for ; Tue, 26 Sep 2000 14:57:00 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA29187; Tue, 26 Sep 2000 15:03:16 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8639713 for URN-IETF@LISTS.NETSOL.COM; Tue, 26 Sep 2000 15:03:13 -0400 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA29170 for ; Tue, 26 Sep 2000 15:02:49 -0400 (EDT) Received: from thinkingcat.com ([64.229.197.205]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000926185630.WPDM23574.tomts7-srv.bellnexxia.net@thinkingcat.com> for ; Tue, 26 Sep 2000 14:56:30 -0400 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.0.58.J.20000923112834.009d62f0@sh.w3.mag.keio.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <39D0F135.EA43558F@thinkingcat.com> Date: Tue, 26 Sep 2000 14:55:49 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hi all, I'd like to hear more about people's thinking on the proposed revision to RFC2611, or alternative suggestions. I can make assumptions about what the silence means, but on the whole, I think it's better not to... Thanks, Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 26 16:37:57 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15635 for ; Tue, 26 Sep 2000 16:37:56 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA00532; Tue, 26 Sep 2000 16:44:05 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8639960 for URN-IETF@LISTS.NETSOL.COM; Tue, 26 Sep 2000 16:43:18 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from mpgw.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA00075 for ; Tue, 26 Sep 2000 15:52:45 -0400 (EDT) Received: from exchsj06.ipo.att.com (exchsj06.attlabs.att.com [135.197.72.26]) by mpgw.attlabs.att.com (8.8.5/8.8.8) with ESMTP id MAA07715; Tue, 26 Sep 2000 12:45:37 -0700 (PDT) Received: from larry (mp-dhcp-2-81.attlabs.att.com [135.197.2.81]) by exchsj06.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TJNPHWRW; Tue, 26 Sep 2000 12:39:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Message-ID: Date: Tue, 26 Sep 2000 12:45:47 -0700 Reply-To: Larry Masinter From: Larry Masinter Subject: Re: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <39CBE22B.6A68CE2B@thinkingcat.com> Content-Transfer-Encoding: 7bit I like the direction of the proposed revisions, and I think it's important to revise RFC 2611. There are two components to your proposed revision that are currently intermixed, that might be usefully separated out. One component is the actual qualifications for a formal namespace: what are the considerations and qualifications that formal namespaces must meet. The second component is the process by which the meeting of those qualifications are judged -- which things need to be in the form you fill out, where it gets sent, what mailing list is offered the opportunity to review & comment, and how the final decision to grant or reject the application gets made. I think your current wording tends to get at the first (e.g., that namespaces must meet criteria for longevity and maintainability) by talking about the second (the form must contain a discussion of longevity and maintainability), partly because it is hard to give objective criteria, but I think it would be useful to try to push things even more so that the criteria are explicit, and described separately from the process. From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 26 17:03:40 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15962 for ; Tue, 26 Sep 2000 17:03:40 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA00958; Tue, 26 Sep 2000 17:09:46 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8640042 for URN-IETF@LISTS.NETSOL.COM; Tue, 26 Sep 2000 17:08:19 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from mpgw.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA00710 for ; Tue, 26 Sep 2000 16:51:37 -0400 (EDT) Received: from exchsj06.ipo.att.com (exchsj06.attlabs.att.com [135.197.72.26]) by mpgw.attlabs.att.com (8.8.5/8.8.8) with ESMTP id NAA08592; Tue, 26 Sep 2000 13:44:48 -0700 (PDT) Received: from larry (mp-dhcp-2-81.attlabs.att.com [135.197.2.81]) by exchsj06.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TJNPHW8T; Tue, 26 Sep 2000 13:38:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Message-ID: Date: Tue, 26 Sep 2000 13:44:57 -0700 Reply-To: Larry Masinter From: Larry Masinter Subject: (resend) Idea: URL-based URN space To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit This is an old idea, but I thought it might bear reviving. Some people are using URLs for what they intend to be 'permanent' names, even though there is no guarantee of persistence. Some people are trying to register URN namespaces because there is no existing namespace over which they have control, or they feel that the informal namespaces in RFC 2611 don't give them intuitive names. I propose a URN namespace based on URLs, but made persistent by the addition of a date. I would propose calling this namespace 'dated-url' (possibly 'durl' or 'url'). These URNs would take the form urn:dated-url:: where was a string representing the date with arbitrary precision (following RFC 2550). The largest granularity of a date is a year. One is empowered to assign a dated-url URN with a date of and a URL only if one had administrative control of the resource located by that URL at that given date/time. This simple rule prevents silly dates, recursion, dates in the future, etc., but allows for arbitrary assignment of URNs. For example, I could use urn:dated-url:1999:http://www.parc.xerox.com/masinter or urn:dated-url:200008:http://larry.masinter.net/ Unlike the 'informal' namespace, no registration is required. As long as people follow the rules, conflicts will be impossible. (And if people don't follow the rules, no system can prevent conflicts). This gives another answer to those who want a URN and don't want to guarantee persistent URLs. Larry -- http://larry.masinter.net From owner-urn-ietf@LISTS.NETSOL.COM Tue Sep 26 23:49:47 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22227 for ; Tue, 26 Sep 2000 23:49:47 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA03855; Tue, 26 Sep 2000 23:53:00 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8640474 for URN-IETF@LISTS.NETSOL.COM; Tue, 26 Sep 2000 23:51:22 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA03743 for ; Tue, 26 Sep 2000 23:34:41 -0400 (EDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id MAA06543; Wed, 27 Sep 2000 12:28:05 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20000927120546.031dc2b0@sh.w3.mag.keio.ac.jp> Date: Wed, 27 Sep 2000 12:14:06 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: (resend) Idea: URL-based URN space To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Hello Larry, This looks like an interesting idea. A few comments below: At 00/09/26 13:44 -0700, Larry Masinter wrote: >This is an old idea, but I thought it might bear reviving. > >Some people are using URLs for what they intend to be 'permanent' >names, even though there is no guarantee of persistence. >Some people are trying to register URN namespaces because there is >no existing namespace over which they have control, or they feel >that the informal namespaces in RFC 2611 don't give them intuitive >names. > >I propose a URN namespace based on URLs, but made persistent by the >addition of a date. > >I would propose calling this namespace 'dated-url' (possibly 'durl' >or 'url'). These URNs would take the form > > urn:dated-url:: > >where was a string representing the date with arbitrary >precision (following RFC 2550). The largest granularity of a date >is a year. > >One is empowered to assign a dated-url URN with a date of >and a URL only if one had administrative control of the >resource located by that URL at that given date/time. Shouldn't that say something like 'during that given time'? E.g. for the 1999 example below, it would mean during all of 1999. >This >simple rule prevents silly dates, recursion, dates in the future, etc., >but allows for arbitrary assignment of URNs. > > > For example, I could use > urn:dated-url:1999:http://www.parc.xerox.com/masinter > or > urn:dated-url:200008:http://larry.masinter.net/ > >Unlike the 'informal' namespace, no registration is required. >As long as people follow the rules, conflicts will be impossible. >(And if people don't follow the rules, no system can prevent >conflicts). > >This gives another answer to those who want a URN and don't >want to guarantee persistent URLs. Could you say something about resolution, too? Regards, Martin. From owner-urn-ietf@LISTS.NETSOL.COM Thu Sep 28 10:53:26 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22647 for ; Thu, 28 Sep 2000 10:53:26 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15360; Thu, 28 Sep 2000 10:51:45 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8641962 for URN-IETF@LISTS.NETSOL.COM; Thu, 28 Sep 2000 10:50:49 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15353 for ; Thu, 28 Sep 2000 10:50:42 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA09132 for urn-ietf@lists.netsol.com; Thu, 28 Sep 2000 10:34:02 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000928103402.C9048@bailey.dscga.com> Date: Thu, 28 Sep 2000 10:34:02 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: new version of the PIN URN NID document To: URN-IETF@LISTS.NETSOL.COM Hi all, There is a new version of the PIN URN registration document available as: http://www.ietf.org/internet-drafts/draft-mealling-pin-urn-01.txt This version incorporates the comments I've received so far. Unless I hear some huge issues with it I'm going to request that it be published as an Informational RFC. Since the IESG has asked us to elaborate on 2611 they may kick this one back as well but its worth a try (if anything we may get some more elaboration from the IESG about exactly what they're after). Comments? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com