From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 4 11:31:56 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09382 for ; Thu, 4 Jan 2001 11:31:56 -0500 (EST) 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 LAA06997; Thu, 4 Jan 2001 11:19:02 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8704577 for URN-IETF@LISTS.NETSOL.COM; Thu, 4 Jan 2001 11:18:00 -0500 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 LAA06982 for ; Thu, 4 Jan 2001 11:17:58 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id LAA01434 for urn-ietf@lists.netsol.com; Thu, 4 Jan 2001 11:01:58 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20010104110158.U27819@bailey.dscga.com> Date: Thu, 4 Jan 2001 11:01:58 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: OID URN NID issues..... To: URN-IETF@LISTS.NETSOL.COM Hi all, After dealing with the holidays and the flu I've finally been able to review the discussion on the OID NID registration. The major point of discussion was whether or not the namespace should include the text tags for each node of the OID tree as seen here: urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) or, as proposed, only include the digits themselves as seen here: urn:oid:0.4.0.1733.1.4.1 It became apparent in the discussion that the text tags were meant only to aid in reading by a human and in no way added to the uniqueness or persistence of the name (the point was made that the text tag actually harmed persistence due to semantic drift of semantically loaded tag names). The point was also made that the tagname was not required to be the same and in many cases wasn't (translations). This created the case where two OID URNs would contain the same OID but according to URI matching rules would be two different URIs. Based on the concensus of this list and the issues brought up I am sugggesting that the OID namespace be registered in its current form as specified in RFC 3001. -MM P.S. administrivia: due to a snafu with document versions RFC 3001 will be updated to include a corrected registrant section. Nothing will change except the RFC number.... -- -------------------------------------------------------------------------------- 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 Jan 25 04:02:46 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22278 for ; Thu, 25 Jan 2001 04:02:45 -0500 (EST) 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 DAA21466; Thu, 25 Jan 2001 03:51:06 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8678698 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 03:48:50 -0500 Received: from post.it.helsinki.fi (post.it.helsinki.fi [128.214.205.24]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id DAA21456 for ; Thu, 25 Jan 2001 03:48:47 -0500 (EST) Received: from helsinki.fi (kvp13.lib.helsinki.fi [128.214.71.205]) by post.it.helsinki.fi (8.11.1/8.11.0-SPAMmers-sod-off) with ESMTP id f0P8ghx27920; Thu, 25 Jan 2001 10:42:44 +0200 (EET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------45573F37B423F8B875A8902B" Approved-By: Juha Hakala Message-ID: <3A6FE6E4.85061E34@helsinki.fi> Date: Thu, 25 Jan 2001 10:42:12 +0200 Reply-To: Juha Hakala From: Juha Hakala Organization: HYK Subject: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------45573F37B423F8B875A8902B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, I have finished the second version of the URN namespace ID registration for ISBN. The text (which is attached here) has been delivered to the IETF Internet drafts editor today. The discussion about the first version did not reveal any fundamental problems, but there was nevertheless some criticism related to actual ISBN usage. A few people pointed out that ISBNs are occasionally wrongly assigned by publishers. The draft now acknowledges this more clearly and discusses the practical implications from the URN resolution point of view. An another issue was that sometimes ISBN group identifiers are not reliable; this problem is also taken into account and settled in the current draft. I am currently finishing the third version of the NID registration for national bibliography numbers, and will start writing the registration request for SICI (Serial Item and Contribution Identifier, ID system for articles) in the near future. I hope to be able to deliver the first version of this text in February. Best regards, Juha Hakala -- Juha Hakala Helsinki University Library juha.hakala@helsinki.fi --------------45573F37B423F8B875A8902B Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-hakala-isbn-01.txt" Content-Disposition: inline; filename="draft-ietf-hakala-isbn-01.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id DAA21466 Content-Transfer-Encoding: quoted-printable Network Working Group Juha Hakala Internet-Draft Helsinki University Library Category: Informational Hartmut Walravens draft-ietf-hakala-isbn-01.txt The International ISBN Agency Expires: 25 July 2001 25 January 2001 Using International Standard Book Numbers as Uniform Resource Names Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on 25 January, 2001. Abstract This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats. Much of the discussion below is based on the ideas expressed in RFC 2288 [Lynch]. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. 1. Introduction As part of the validation process for the development of URNs the IETF URN working group agreed that it is important to demonstrate that the current URN syntax proposal can accommodate existing identifiers from well established namespaces. One such infrastructure for assigning and managing names comes from the bibliographic community. Bibliographic identifiers function as names for objects that exist both in print and, increasingly, in electronic formats. RFC 2288 [Lynch et. al.] investigated the feasibility of using three identifiers (ISBN, ISSN and SICI) as URNs. This document will analyse the usage of ISBNs as URNs in more detail than RFC 2288. A registration request for acquiring Namespace Identifier (NID) "ISBN" for ISBNs is included in chapter 5. The document at hand is part of a global joint venture of the national libraries to foster identification of electronic documents in general and utilisation of URNs in particular. The document was written as a co- operative project between the Helsinki University Library and The International ISBN Agency. We have used the URN Namespace Identifier "ISBN" for ISBNs in examples below. 2. Identification vs. Resolution As a rule the ISBNs identify finite, manageably-sized objects, but these objects may still be large enough that resolution into a hierarchical system is appropriate. The materials identified by an ISBN may exist only in printed or other physical form, not electronically. The best that a resolver will be able to offer in this case is bibliographic data from a national bibliography database, including information about where the physical resource is stored in the national library's holdings. 3. International Standard Book Numbers 3.1 Overview RFC 2288 [Lynch] describes the ISBN system in the following way: An International Standard Book Number (ISBN) identifies an edition of a monographic work. The ISBN is defined by the standard NISO/ANSI/ISO 2108:1992 [ISO1] Basically, an ISBN is a ten-digit number (actually, the last digit can be the letter "X" as well, as described below) which is divided into four variable length parts usually separated by hyphens when printed. The parts are as follows (in this order): * a group identifier which specifies a group of publishers, based on national, geographic or some other criteria, * the publisher identifier, * the title identifier, * and a modulus 11 check digit, using X instead of 10. The group and publisher number assignments are managed in such a way that the hyphens are not needed to parse the ISBN unambiguously into its constituent parts. However, the ISBN is normally transmitted and displayed with hyphens to make it easy for human beings to recognize these parts without having to make reference to or have knowledge of the number assignments for group and publisher identifiers. Groups usually cover only one country, but occasionally a single group is= used in several countries. For instance, group "3" is utilised in Germany, Aus= tria and German-speaking parts of Switzerland. "976" is used in Caribbean comm= unity (Antigua, Bahamas, Barbados, Belize, Cayman Islands, Dominica, Grenada, G= uyana, Jamaica, Montserrat, St. Kitts-Nevis, St. Lucia, St. Vincent and the Gren= adines, Trinidad and Tobago, Virgin Islands (Br))and "982" in South Pacific (Cook Islands, Fiji, Kiribati, Marshall Islands, Nauru, Niue, Solomon Islands, Tokelau, Tonga, Tuvalu; Vanuatu, Western Samoa). For each international g= roup, the International ISBN Agency has assigned ranges of publisher identifier= s to individual countries. These ranges are listed on the ISBN web site (http://www.isbn.spk-berlin.de/html/prefix.htm). The group identifiers ar= e listed at http://www.isbn.spk-berlin.de/html/prefix/allpref.htm. There are plans to extend the ISBN into 13 digits in order to make the system more suitable for identification of electronic monographs. So called Bookland ISBN will consist of a traditional ISBN preceded by the 978 or 979 EAN flag. 3.2 Encoding Considerations and Lexical Equivalence RFC 2288 [Lynch] says that: Embedding ISBNs within the URN framework presents no particular encoding problems, since all of the characters that can appear in an ISBN are valid in the identifier segment of the URN. %-encoding, as described in [MOATS] is never needed. Example: URN:ISBN:0-395-36341-1 For the ISBN namespace, some additional equivalence rules are appropriate. Prior to comparing two ISBN URNs for equivalence, it is appropriate to remove all hyphens, and to convert any occurrences of the letter X to upper case. 3.3 Resolution of ISBN-based URNs The existing ISBN structure is suitable for URN resolution purposes. The group identifier can assist in the resolver discovery process. For instance, the group identifier "951" means Finland. In this case, the Finnish national bibliographic database will be able to resolve the URN either into bibliographic data or - if the resource is available in the Internet - to the document itself. If a group identifier does not identify a single country but a language area, there are two means for locating the correct national bibliography. First, it is possible to define a cascade of URN resolution services - for instance, German national bibliography, Austrian national bibliography and Swiss national bibliography, in this order - into the DNS records describing the resolution service for ISBNs starting with "3". Second, the publisher identifier ranges assigned by the International ISBN Agency could be defined into the DNS records. This method is better than cascading, since the correct resolution service can be found immediately. In some exceptional cases - notably in the US and in UK, where international companies do a significant portion of publishing - the information provided by the group identifier may not always be fully reliable. For instance, some monographs published in New York by international publishing companies may get an ISBN with the group identifier "3". This is technically appropriate when the headquarters or one of the offices of the publisher is located in Germany. Information about such a book will not be available in the German national bibliography, but via the Library of Congress systems. Unfortunately the appropriate national bibliography cannot be known to the resolver discovery service. As a fall back mechanism a large union catalogue, such as WorldCat maintained by OCLC (http://www.oclc.org ) could be used to complement the default services provided by national bibliographies. The problem described above may well be less severe than it looks. Some international publishers (Springer, for example) give the whole production to the national library of their home country as legal deposit, no matter which country the book was published. Thus everything published by Springer in New York with group identifier "3" will be found from the German national bibliography. On the other hand, when these companies give their home base also as a place of publication, the "home" national library requires the legal deposit. Due to the intelligent structure of ISBN, group identifier or even the publisher identifier can be used as a =91hint=92. Technically it is possi= ble to incorporate into the common structure also URN resolution services maintained by publishers. For instance, "951-0" is the unique ISBN publisher identifier of the largest publisher in Finland, Sanoma-WSOY. If they launch their own URN resolution services, resolution requests for ISBNs starting with "951-0" will be directed to the publisher's server, and all other requests to the national bibliography. 3.4 Additional considerations The basic guidelines for assigning ISBNs to electronic resources are the following: * Format/means of delivery is irrelevant to the decision whether a product needs an ISBN or not. If the content meets the requirement, it gets an ISBN, no matter what the format of the delivery system. * Each format of a digital publication should have a separate ISBN. The definition of a new edition is normally based on one of the two criteria: * A change in the kind of packaging involved: the hard cover edition, the paperback edition and the library-binding edition would each get a separate ISBN. The same applies to different formats of digital files. * A change in the text, excluding packaging or minor changes such as correcting a spelling error. Again, this criterion applies regardless of whether the publication is in printed or in digital form. Although these rules seem very clear, their interpretation may vary. As [Lynch] points out, The choice of whether to assign a new ISBN or to reuse an existing one when publishing a revised printing of an existing edition of a work or even a revised edition of a work is somewhat subjective. Practice varies from publisher to publisher (indeed, the distinction between a revised printing and a new edition is itself somewhat subjective). The use of ISBNs within the URN framework simply reflects these existing practices. Note that it is likely that an ISBN URN will often resolve to many instances of the work (many URLs). Publishers have also in some occasions re-used the same ISBN for another book. This reasonably rare kind of human error does not threaten or undermine the value of the ISBN system as a whole. Neither do they pose a serious threat to the URN resolution service based on ISBNs. An error will only lead into the retrieval of two or more bibliographic records from a national bibliographic database. Based on the information in the records, a user can choose the correct record from the result set. Most national bibliographies and especially the Books in Print correct ISBN mistakes. The systems then provide cross references ("incorrect ISBN -> correct ISBN"). Further details on the process of assigning ISBNs can be found in section 5 (Namespace registration) below. 4. Security Considerations This document proposes means of encoding ISBNs within the URN framework. ISBN-based URN resolution service is depicted here only in a fairly generic level; thus questions of secure or authenticated resolution mechanisms are excluded. It does not deal with means of validating the integrity or authenticating the source or provenance of URNs that contain ISBNs. Issues regarding intellectual property rights associated with objects identified by the ISBNs are also beyond the scope of this document, as are questions about rights to the databases that might be used to construct resolvers. 5. Namespace registration URN Namespace ID Registration for the International Standard Book Number (ISBN) This registration describes how International Standard Book Numbers (ISBN) can be supported within the URN framework. Namespace ID: ISBN This Namespace ID is the same as the internationally known acronym for the International Standard Book Number. Giving NID "ISBN" to any other identifier system would cause a lot of confusion. Registration Information: Version: 1 Date: 2001-01-25 Declared registrant of the namespace: Name: Hartmut Walravens E-mail: hartmut.walravens@sbb.spk-berlin.de Affiliation: Director, The International ISBN Agency Address: Staatsbibliothek zu Berlin - Preu=DFischer Kulturbesitz - D-1077= 2 Berlin, Germany Declaration of syntactic structure: An ISBN is a ten-digit number (actually, the last digit can be the letter "X" as well, as described below) which is divided into four variable length parts usually separated by hyphens when printed. The parts are as follows (in this order): * a group identifier which specifies a group of publishers, based on national, geographic or some other criteria, * the publisher identifier, * the title identifier, * and a modulus 11 check digit, using X instead of 10. Example: URN:ISBN:0-395-36341-1 Relevant ancillary documentation: The ISBN (International Standard Book Number) is a unique machine- readable identification number, which marks any edition of a book unambiguously. This number is defined in ISO Standard 2108. The number has been in use now for 30 years and has revolutionised the international book-trade. 154 countries are officially ISBN members, and more countries are joining the system. The administration of the ISBN system is carried out on three levels: International agency Group agencies Publisher levels The International ISBN agency is located within the State Library Berlin. The main functions of the International ISBN Agency are: * To promote, co-ordinate and supervise the world-wide use of the ISBN system. * To approve the definition and structure of group agencies. * To allocate group identifiers to group agencies. * To advise on the establishment and functioning of group agencies. * To advise group agencies on the allocation of international publisher identifiers. * To publish the assigned group numbers and publishers prefixes in up- to-date form. More information about ISBN usage can be found from the ISBN Users' Manual. 4th edition of this document is available at http://www.isbn.spk- berlin.de/html/userman.htm. Identifier uniqueness considerations: ISBN that has been assigned once should never be re-used. Nevertheless, publishers do occasionally re-use the same number. From the point of the URN resolution system proposed here, this will typically cause retrieval of two bibliographic records. A user can choose the correct publication using the data in the record, such as the author or title. Incorrect ISBNs are routinely corrected in national bibliographies and Books in Print catalogue. Identifier persistence considerations: The ISBN accompanies a publication from its production onwards. It is persistent; ISBN once given - if correct - will never leave the publication. Identifier assignment process: Assignment of ISBNs is always controlled by ISBN group agencies, which are often national and quite frequently located in the national libraries. Publishers are usually given blocks of ISBNs, from which they pick identifiers for their newly published items. As pointed out earlier, in spite of the common rules of how to use ISBNs, there is some variation between different publishers in ISBN assignment. In practice these differences are so small that they do not pose a threat to the usability of the ISBN system. Identifier resolution process: URNs based on ISBNs will be primarily resolved via the national bibliography databases. Since ISBN group agencies are as a rule located in national libraries, the national bibliography databases cover almost every publication which does have an ISBN. If group identifier does not define a country but a language area there may be many countries using the same group identifier. In such cases, the International ISBN Agency has divided publisher identifiers into ranges assigned to each country within the group. The appropriate resolution service can be found by using the group identifier and publisher identifier information. Alternatively a cascade of national bibliographies can be defined. Resolution carried out in national bibliography databases may be complemented by so called union catalogues, which contain huge amount of bibliographic data (up to 42 million records). This complementary service is only needed if the ISBN group identifier information is misleading. This is not common. The International ISBN Agency maintains a list of publishers who have been assigned a publisher identifier within the ISBN system. The publisher identifier may be used to allow participation of resolution services maintained by publishers into the URN resolution system for ISBN. Rules for Lexical Equivalence: For the ISBN namespace, some additional equivalence rules are appropriate. Prior to comparing two ISBN URNs for equivalence, it is appropriate to remove all hyphens, and to convert any occurrences of the letter X to upper case. Conformance with URN Syntax: Embedding ISBNs within the URN framework presents no particular encoding problems, since all of the characters that can appear in an ISBN are valid in the identifier segment of the URN %-encoding, as described in [MOATS] is never needed. Example: URN:ISBN:0-395-36341-1 Validation mechanism: Validity of an ISBN string can be checked by modulus 11 check digit, included in the ISBN. X is used instead of 10. Validity of ISBN assignments can be checked from the group agencies or directly from the publisher. Scope: Global. 6. References [Daigle et al.]: Daigle, L., van Gulik, D., Iannella, R. & Faltstrom, P.: URN Namespace Definition Mechanisms, RFC2611, June 1999. [Lynch] Lynch, C., Using Existing Bibliographic Identifiers as Uniform Resource Names, RFC 2288, February 1998 [Moats] Moats, R., "URN Syntax", RFC 2141, May 1997. 7. Authors' Addresses Juha Hakala Helsinki University Library - The National Library of Finland P.O. Box 26 FIN-00014 Helsinki University FINLAND E-mail: juha.hakala@helsinki.fi ...Hartmut Walravens The International ISBN agency Staatsbibliothek zu Berlin - Preu=DFischer Kulturbesitz - D-10772 Berlin, GERMANY E-mail: hartmut.walravens@sbb.spk-berlin.de 8. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. --------------45573F37B423F8B875A8902B-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 09:44:21 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27361 for ; Thu, 25 Jan 2001 09:44:20 -0500 (EST) 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 JAA23866; Thu, 25 Jan 2001 09:33:04 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8678956 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 09:32:49 -0500 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 JAA23856 for ; Thu, 25 Jan 2001 09:32:47 -0500 (EST) 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 GAA04152; Thu, 25 Jan 2001 06:26:42 -0800 (PST) Received: (from cameron@localhost) by orpheus.cs.sfu.ca (8.9.1/8.9.1) id GAA26538; Thu, 25 Jan 2001 06:26:40 -0800 (PST) Approved-By: Rob Cameron Message-ID: <200101251426.GAA26538@orpheus.cs.sfu.ca> Date: Thu, 25 Jan 2001 06:26:40 -0800 Reply-To: Rob Cameron From: Rob Cameron Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM Juha, If I understand it correctly, the resolution model described in your document is based on a centralized model. A centrally controlled resolver service will dispatch to resolvers at national bibliographic services based on ISBN country/group prefix. For example, ISBNs beginning 85-, 961- and 99917- dispatch to the national bibliographic services of Brazil, Slovenia and Brunei, respectively. If the national bibliographic service is unable to resolve the identifier, a global service such as WorldCat. Although the international network of national bibliographic services has an important role to play, this model ignores an existing well-resourced network whose longstanding role has been the provision of primary bibliographic service: the network of academic and research libraries. If the first step of the resolution model could somehow use a local bibliographic service, which would then be backed up by national and global services, I believe there would be a number of benefits. (1) The local service could highlight local availability, e.g., books on the shelf, books at a campus bookstore, interlibrary loan options and so on. In short, the "appropriate copy" problem or "contextualization" would be solved. (2) International resolution "traffic" would be reduced. (3) Redundancy and reliability would be increased. We have implemented this model in our work with an alternative URN framework that we have put forward to the IETF as "bibliographic protocol". In deference to the URN WG, we have used the scheme name "bibp:" instead of "urn:", but the identification concept is basically the same. We are excited about this work because the resolution technology underlying bibp is deployed world-wide and stable at this time. In brief, a bibp link of the form bibp:ISBN/0-13-877846-9 resolves to http://bibhost/bibp1.0/resolve?usin=ISBN/0-13-877846-9 if a local server exists at http://bibhost/ and is providing bibp service. It is a standard part of DNS technology that a relative domain name bibhost is interpreted according to the local domain of the client (or a client-specified search domain). For example, users at sfu.ca would have service from bibhost.sfu.ca and users at yale.edu would have service from bibhost.yale.edu. If local bibhost service does not exist, the model backs up to a document-specified citehost (if it exists) or to a known global server. For immediate deployment of bibp links, an author need only include a short bit of JavaScript in the web page; see our BibP Linking 1-2-3 document at http://usin.org/linking-1-2-3.html . This enables bibp service for popular web clients (see http://usin.org/software/clients/ ). JavaScript is a short-term solution until bibp-aware clients become deployed. As a consequence of this model, it is very easy for a library to install a bibp service that immediately becomes effective for the local domain. For example, bibhost.cs.sfu.ca currently provides a crude prototype based on a bibp-Z39.50 gateway. Try http://bibhost.cs.sfu.ca/bibp1.0/resolve?usin=ISBN/0-13-021119-2 (or any other ISBN) to see it in operation. You can also see what our prototype global service does at http://usin.org/bibp1.0/resolve?usin=ISBN/0-13-021119-2 Currently it does validation and parsing of the ISBN structure and attempts error correction for any single digit insertions deletions, replacements or transpositions. The above URLs represent different resolved forms of the bibp link bibp:ISBN/0-13-021119-2. We have a rudimentary demo available at http://usin.org/ that allows you to experiment with different server combinations for BibP:ISBN linking. Although our servers are crude prototypes at this stage, what is really important is the resolution model. It works. Robert D. Cameron Professor of Computing Science Simon Fraser University From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 10:12:13 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28932 for ; Thu, 25 Jan 2001 10:12:12 -0500 (EST) 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 JAA24212; Thu, 25 Jan 2001 09:54:35 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679018 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 09:54:31 -0500 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 JAA24200 for ; Thu, 25 Jan 2001 09:54:27 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id JAA00806; Thu, 25 Jan 2001 09:38:27 -0500 (EST) References: <200101251426.GAA26538@orpheus.cs.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20010125093827.D418@bailey.dscga.com> Date: Thu, 25 Jan 2001 09:38:27 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200101251426.GAA26538@orpheus.cs.sfu.ca>; from cameron@CS.SFU.CA on Thu, Jan 25, 2001 at 06:26:40AM -0800 On Thu, Jan 25, 2001 at 06:26:40AM -0800, Rob Cameron wrote: > If I understand it correctly, the resolution model described > in your document is based on a centralized model. A centrally > controlled resolver service will dispatch to resolvers at > national bibliographic services based on ISBN country/group > prefix. For example, ISBNs beginning 85-, 961- and 99917- > dispatch to the national bibliographic services of Brazil, > Slovenia and Brunei, respectively. If the national bibliographic > service is unable to resolve the identifier, a global service > such as WorldCat. > > Although the international network of national bibliographic > services has an important role to play, this model ignores > an existing well-resourced network whose longstanding role > has been the provision of primary bibliographic service: the > network of academic and research libraries. The URN framework has always assumed that there would be many namespaces where 'non-authoritative' (from the assignment standpoint) services would also provide resolution services. The different being that the DDDS based resolution mechanism was specifically for finding the _authoritative_ service. The algorithm always stated that the first step of URN resolution was to ask some locally preferred entity first. > If the first step of the resolution model could somehow use > a local bibliographic service, which would then be backed up > by national and global services, I believe there would be a > number of benefits. > (1) The local service could highlight local availability, > e.g., books on the shelf, books at a campus bookstore, > interlibrary loan options and so on. In short, the > "appropriate copy" problem or "contextualization" would > be solved. > (2) International resolution "traffic" would be reduced. > (3) Redundancy and reliability would be increased. IMHO, this would be valuable but as an adjunct service (probably based on some of the contextualization/"appropriate copy" discussions that have been had recently). Both of these models should work together. But I think its valuable and proper that the _authoritative_ resolution system follow the ISBN assignment delegation rules. It may come to pass that everyone uses some contextualized resolution mechanism that actually asks the local bibliographic services but IMHO, its not _authoritative_. > We have implemented this model in our work with an alternative > URN framework that we have put forward to the IETF as "bibliographic > protocol". In deference to the URN WG, we have used the > scheme name "bibp:" instead of "urn:", but the identification > concept is basically the same. But the difference is that the bibp delegation model isn't authoritative. There are times when I want to know what my local library or bookstore thinks about a particular ISBN number (like when I'm buying it). But other times when I want to know what the ISBN organization actually thinks (like when I'm referencing it in a bibliography) and for that answer it _must_ be authoritative.... > We are excited about this work because the resolution technology > underlying bibp is deployed world-wide and stable at this time. > > In brief, a bibp link of the form bibp:ISBN/0-13-877846-9 resolves to > http://bibhost/bibp1.0/resolve?usin=ISBN/0-13-877846-9 > if a local server exists at http://bibhost/ and is providing bibp > service. It is a standard part of DNS technology that a > relative domain name bibhost is interpreted according to > the local domain of the client (or a client-specified search > domain). For example, users at sfu.ca would have service > from bibhost.sfu.ca and users at yale.edu would have service > from bibhost.yale.edu. Assuming one has his/her DNS search path configured correctly but that's an operational issue. IMHO, the better approach would be to generalize this and make it a local service discovery problem... I.e. the discussions we had at the c15n BOF showed that indeed this area is very interesting and a general, standard solution is needed but it also found that it needed to be explicit both on the users part and on the link authors part.... So I think we're in agreement except that I don't think this service belongs as part of the 'official' ISBN URN namespace resolution process and thus shouldn't be part of Juha's registration document.... -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 Jan 25 11:10:20 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02594 for ; Thu, 25 Jan 2001 11:10:19 -0500 (EST) 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 KAA24930; Thu, 25 Jan 2001 10:51:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679137 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 10:51:24 -0500 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 KAA24923 for ; Thu, 25 Jan 2001 10:51:23 -0500 (EST) Received: from thinkingcat.com ([64.229.192.124]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010125154451.ZJRA27935.tomts5-srv.bellnexxia.net@thinkingcat.com>; Thu, 25 Jan 2001 10:44:51 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200101251426.GAA26538@orpheus.cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A7049A7.935AB1B4@thinkingcat.com> Date: Thu, 25 Jan 2001 10:43:35 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, Juha's document describes how ISBN uses the standards discussed in this working group. Whatever else they may do with ISBN URNs is up to them. This working group set out to define a specific set of globally- resolvable identifiers & infrastructure, and that is the scope of its work. This does not preclude the value of other approaches to resolution, but arguments of "that's a flawed idea, you should do X instead" are out of scope. Finally, I appreciate that you have made this group aware of the work you've done, and various of us have offered you technical input. However, at this point I view your actions as "advertizing" your system, that's out of scope for this mailing list as well. As Michael mentioned, there has been interest in contextualized resolution as a separate work effort. That will provide the relevant forum for discussing much of what you're getting at. Leslie. Rob Cameron wrote: > > Juha, > > If I understand it correctly, the resolution model described > in your document is based on a centralized model. A centrally > controlled resolver service will dispatch to resolvers at > national bibliographic services based on ISBN country/group > prefix. For example, ISBNs beginning 85-, 961- and 99917- > dispatch to the national bibliographic services of Brazil, > Slovenia and Brunei, respectively. If the national bibliographic > service is unable to resolve the identifier, a global service > such as WorldCat. > > Although the international network of national bibliographic > services has an important role to play, this model ignores > an existing well-resourced network whose longstanding role > has been the provision of primary bibliographic service: the > network of academic and research libraries. > > If the first step of the resolution model could somehow use > a local bibliographic service, which would then be backed up > by national and global services, I believe there would be a > number of benefits. > (1) The local service could highlight local availability, > e.g., books on the shelf, books at a campus bookstore, > interlibrary loan options and so on. In short, the > "appropriate copy" problem or "contextualization" would > be solved. > (2) International resolution "traffic" would be reduced. > (3) Redundancy and reliability would be increased. > > We have implemented this model in our work with an alternative > URN framework that we have put forward to the IETF as "bibliographic > protocol". In deference to the URN WG, we have used the > scheme name "bibp:" instead of "urn:", but the identification > concept is basically the same. > > We are excited about this work because the resolution technology > underlying bibp is deployed world-wide and stable at this time. > > In brief, a bibp link of the form bibp:ISBN/0-13-877846-9 resolves to > http://bibhost/bibp1.0/resolve?usin=ISBN/0-13-877846-9 > if a local server exists at http://bibhost/ and is providing bibp > service. It is a standard part of DNS technology that a > relative domain name bibhost is interpreted according to > the local domain of the client (or a client-specified search > domain). For example, users at sfu.ca would have service > from bibhost.sfu.ca and users at yale.edu would have service > from bibhost.yale.edu. > > If local bibhost service does not exist, the model backs up to > a document-specified citehost (if it exists) or to a known global > server. > > For immediate deployment of bibp links, an author need only > include a short bit of JavaScript in the web page; see > our BibP Linking 1-2-3 document at http://usin.org/linking-1-2-3.html . > This enables bibp service for popular web clients (see > http://usin.org/software/clients/ ). JavaScript is a short-term > solution until bibp-aware clients become deployed. > > As a consequence of this model, it is very easy for a library > to install a bibp service that immediately becomes effective > for the local domain. For example, bibhost.cs.sfu.ca currently > provides a crude prototype based on a bibp-Z39.50 gateway. > Try http://bibhost.cs.sfu.ca/bibp1.0/resolve?usin=ISBN/0-13-021119-2 > (or any other ISBN) to see it in operation. > > You can also see what our prototype global service does at > http://usin.org/bibp1.0/resolve?usin=ISBN/0-13-021119-2 > Currently it does validation and parsing of the ISBN structure > and attempts error correction for any single digit insertions > deletions, replacements or transpositions. > > The above URLs represent different resolved forms of the bibp > link bibp:ISBN/0-13-021119-2. We have a rudimentary demo > available at http://usin.org/ that allows you to experiment > with different server combinations for BibP:ISBN linking. > > Although our servers are crude prototypes at this stage, what is > really important is the resolution model. It works. > > Robert D. Cameron > Professor of Computing Science > Simon Fraser University -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 11:49:40 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03816 for ; Thu, 25 Jan 2001 11:49:39 -0500 (EST) 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 LAA25436; Thu, 25 Jan 2001 11:32:12 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679221 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 11:32:08 -0500 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 LAA25429 for ; Thu, 25 Jan 2001 11:32:07 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id LAA01222; Thu, 25 Jan 2001 11:16:09 -0500 (EST) References: <200101251426.GAA26538@orpheus.cs.sfu.ca> <3A7049A7.935AB1B4@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: <20010125111609.F418@bailey.dscga.com> Date: Thu, 25 Jan 2001 11:16:09 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A7049A7.935AB1B4@thinkingcat.com>; from leslie@THINKINGCAT.COM on Thu, Jan 25, 2001 at 10:43:35AM -0500 On Thu, Jan 25, 2001 at 10:43:35AM -0500, Leslie Daigle wrote: > As Michael mentioned, there has been interest in contextualized > resolution as a separate work effort. That will provide the relevant > forum for discussing much of what you're getting at. And that forum can be found at: http://lists.research.netsol.com/pipermail/c15n/ And the subscription info is at: http://lists.research.netsol.com/mailman/listinfo/c15n -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 Jan 25 13:06:16 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05303 for ; Thu, 25 Jan 2001 13:06:15 -0500 (EST) 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 MAA26252; Thu, 25 Jan 2001 12:46:27 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679346 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 12:46:17 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA26044 for ; Thu, 25 Jan 2001 12:22:02 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA15830; Thu, 25 Jan 2001 09:15:39 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f0PHFRH01895; Thu, 25 Jan 2001 09:15:27 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA20158; Thu, 25 Jan 2001 09:15:09 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Message-ID: Date: Thu, 25 Jan 2001 18:13:02 +0100 Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: draft-ietf-urn-net-procedures-06.txt To: URN-IETF@LISTS.NETSOL.COM X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id MAA26252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05303 IESG have two issues with this document: (a) We need a security consideration section. Please provide one. (b) The IANA consideration section will be changed by the IESG and IAB to match the current view on wording regarding cooperation between IANA and the IETF. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 13:49:01 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05801 for ; Thu, 25 Jan 2001 13:49:00 -0500 (EST) 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 NAA26826; Thu, 25 Jan 2001 13:29:44 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679438 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 13:29:37 -0500 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA26817 for ; Thu, 25 Jan 2001 13:29:36 -0500 (EST) Received: from hplns3.hpl.hp.com (hplns3.hpl.hp.com [15.0.48.4]) by deimos.hpl.hp.com (8.9.3 (PHNE_18546)/HPL-PA Relay) with ESMTP id KAA20541; Thu, 25 Jan 2001 10:23:29 -0800 (PST) Received: from timpc.hpl.hp.com (timpc.hpl.hp.com [15.4.92.160]) by hplns3.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id f0PINTH09072; Thu, 25 Jan 2001 10:23:29 -0800 (PST) X-Sender: timothy@hplex1.hpl.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 References: <3A7049A7.935AB1B4@thinkingcat.com> <200101251426.GAA26538@orpheus.cs.sfu.ca> <3A7049A7.935AB1B4@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Tim Kindberg Message-ID: <5.0.2.1.1.20010125084954.0308ae38@hplex1.hpl.hp.com> Date: Thu, 25 Jan 2001 10:23:04 -0800 Reply-To: Tim Kindberg From: Tim Kindberg Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <20010125111609.F418@bailey.dscga.com> At 11:16 AM 1/25/2001 -0500, Michael Mealling wrote: >On Thu, Jan 25, 2001 at 10:43:35AM -0500, Leslie Daigle wrote: > > As Michael mentioned, there has been interest in contextualized > > resolution as a separate work effort. That will provide the relevant > > forum for discussing much of what you're getting at. > >And that forum can be found at: >http://lists.research.netsol.com/pipermail/c15n/ > >And the subscription info is at: >http://lists.research.netsol.com/mailman/listinfo/c15n Thanks for that links. We've been working on contextual resolution as part of our 'CoolTown' system (http://cooltown.hp.com/): we map identifiers found on physical entities to contextually relevant URLs. This is a good opportunity for me to try to spell out what has been bemusing me about the URN/URI community, looked at from the point of view of our work. When I started to work on resolution I naturally looked at what the URN community has been doing, but I tripped over the first assumption I came across: that URNs are 'location independent identifiers'. That is, the goal seems to be a system that would give the same 'authoritative' (the URN community's word) answer to everyone, every time, wherever they are. That's the opposite of what seems to us to be the makings of a useful system, given our assumptions. Here's an example to illustrate our thinking: Suppose I, you (another shopper) and a supermarket employee all pick up identical cans of beans in the supermarket, and suppose we all scan the barcode on the can with a wirelessly connected device to look at web pages about the beans (this is something we routinely do in CoolTown). We think that the chances are that those three users would want to see different results. I want to avoid genetically modified (GM) foods so I want to see appropriate links to check the beans' status. You suffer from diabetes, so you want to see diabetic links about the beans. The employee wants to do a Safeway price or stock check. Actually, we may all want to see a link to the Safeway page, in addition to the other specialised pages I've mentioned. And if we were back in our homes instead of the supermarket, then we may want to see yet another set of pages when we scan the beans' barcode: say, a page enabling us to put that item on our web shopping list. In CoolTown we have ways to pick up the local context (Safeway, the home); but users also configure their devices to use more generally applicable contexts (e.g. GM foods and diabetes). One name -- let's call it upca:78996800002 -- has bindings in multiple naming contexts: in each case, to a record containing a URL (we're considering Xlink). Which of the bindings is 'authoritative'? Our answer is: they are all equally authoritative. Bindings derive from organisations that assert them (Safeway stores, The Campaign against GM foods, the Finnish Diabetes society, Tim Kindberg's household). Those organisations can digitally sign them to make them literally authoritative. What about the fact that the name contains 'upca' -- doesn't that signify some 'extra' authority for the manufacturer? Our answer is: No, not _binding_ authority. There's a basic distinction between the authority to mint names and the authority to bind them to resources, which rarely seems to be made. The UPC people have devised a way of ensuring that manufacturers can mint names for their products without fear of collision. Those manufacturers then bind those names (a) literally, physically as part of the fabric products (which probably would count as 'authoritative' in court) and (b) virtually, to virtual resources about the products. Should that mean that The Campaign Against GM foods _cannot_ also bind the UPC code to their own virtual resources, or that, if they do so, their binding has a lesser status? I can understand why Heinz might wish that virtual binding didn't exist or was deprecated, for commercial reasons. But there's no logical objection that they can raise. At least, not as long as we satisfy the requirement that no-one will get confused about whose binding is whose. And that problem can be solved by making bindings first-class, standard, digitally signed objects. I sometimes wonder whether having UPC codes physically bound to objects or whether DNS has got a lot of people hooked on the idea that authority to mint names and authority to bind them always go together. Those two things coexist for understandable reasons at Heinz and in DNS. But the next generation of Internet naming and binding systems should separate the two. Tim. Tim Kindberg internet & mobile systems lab hewlett-packard laboratories 1501 page mill road, ms 1u-17 palo alto ca 94304-1126 usa timothy@hpl.hp.com voice +1 650 857 5609 fax +1 650 857 2358 From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 14:21:06 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06424 for ; Thu, 25 Jan 2001 14:21:05 -0500 (EST) 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 OAA27406; Thu, 25 Jan 2001 14:01:30 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679522 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 14:01:21 -0500 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 OAA27399 for ; Thu, 25 Jan 2001 14:01:19 -0500 (EST) Received: from thinkingcat.com ([64.229.192.124]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010125185446.VVLX11735.tomts6-srv.bellnexxia.net@thinkingcat.com>; Thu, 25 Jan 2001 13:54:46 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A7049A7.935AB1B4@thinkingcat.com> <200101251426.GAA26538@orpheus.cs.sfu.ca> <3A7049A7.935AB1B4@thinkingcat.com> <5.0.2.1.1.20010125084954.0308ae38@hplex1.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A707629.32DCBB8B@thinkingcat.com> Date: Thu, 25 Jan 2001 13:53:29 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Tim, Top-down authority is one piece in the puzzle -- there are at least times when you want it. There isn't (that I have seen) dispute that there are times when you do want instead contextualized resolution (and what that means in terms of "authoritative" has to be explored). But, that's a work item outside the scope of this WG (NB: I'm not saying it's irrelevant to URNs). So, the WG chair reiterates her request to take the discussion to the forum that is evolving to tackle it, and encourages all interested parties to follow the pointers provided by Michael. I'm copying the c15n mailing list on this to help "move" it. Thanks, Leslie. Tim Kindberg wrote: > > At 11:16 AM 1/25/2001 -0500, Michael Mealling wrote: > >On Thu, Jan 25, 2001 at 10:43:35AM -0500, Leslie Daigle wrote: > > > As Michael mentioned, there has been interest in contextualized > > > resolution as a separate work effort. That will provide the relevant > > > forum for discussing much of what you're getting at. > > > >And that forum can be found at: > >http://lists.research.netsol.com/pipermail/c15n/ > > > >And the subscription info is at: > >http://lists.research.netsol.com/mailman/listinfo/c15n > > Thanks for that links. We've been working on contextual resolution as part > of our 'CoolTown' system (http://cooltown.hp.com/): we map identifiers > found on physical entities to contextually relevant URLs. > > This is a good opportunity for me to try to spell out what has been > bemusing me about the URN/URI community, looked at from the point of view > of our work. When I started to work on resolution I naturally looked at > what the URN community has been doing, but I tripped over the first > assumption I came across: that URNs are 'location independent identifiers'. > That is, the goal seems to be a system that would give the same > 'authoritative' (the URN community's word) answer to everyone, every time, > wherever they are. > > That's the opposite of what seems to us to be the makings of a useful > system, given our assumptions. Here's an example to illustrate our thinking: > > Suppose I, you (another shopper) and a supermarket employee all pick up > identical cans of beans in the supermarket, and suppose we all scan the > barcode on the can with a wirelessly connected device to look at web pages > about the beans (this is something we routinely do in CoolTown). > > We think that the chances are that those three users would want to see > different results. I want to avoid genetically modified (GM) foods so I > want to see appropriate links to check the beans' status. You suffer from > diabetes, so you want to see diabetic links about the beans. The employee > wants to do a Safeway price or stock check. Actually, we may all want to > see a link to the Safeway page, in addition to the other specialised pages > I've mentioned. > > And if we were back in our homes instead of the supermarket, then we may > want to see yet another set of pages when we scan the beans' barcode: say, > a page enabling us to put that item on our web shopping list. > > In CoolTown we have ways to pick up the local context (Safeway, the home); > but users also configure their devices to use more generally applicable > contexts (e.g. GM foods and diabetes). > > One name -- let's call it upca:78996800002 -- has bindings in multiple > naming contexts: in each case, to a record containing a URL (we're > considering Xlink). > > Which of the bindings is 'authoritative'? Our answer is: they are all > equally authoritative. Bindings derive from organisations that assert them > (Safeway stores, The Campaign against GM foods, the Finnish Diabetes > society, Tim Kindberg's household). Those organisations can digitally sign > them to make them literally authoritative. > > What about the fact that the name contains 'upca' -- doesn't that signify > some 'extra' authority for the manufacturer? Our answer is: No, not > _binding_ authority. There's a basic distinction between the authority to > mint names and the authority to bind them to resources, which rarely seems > to be made. The UPC people have devised a way of ensuring that > manufacturers can mint names for their products without fear of collision. > Those manufacturers then bind those names (a) literally, physically as part > of the fabric products (which probably would count as 'authoritative' in > court) and (b) virtually, to virtual resources about the products. > > Should that mean that The Campaign Against GM foods _cannot_ also bind the > UPC code to their own virtual resources, or that, if they do so, their > binding has a lesser status? > > I can understand why Heinz might wish that virtual binding didn't exist or > was deprecated, for commercial reasons. But there's no logical objection > that they can raise. > > At least, not as long as we satisfy the requirement that no-one will get > confused about whose binding is whose. And that problem can be solved by > making bindings first-class, standard, digitally signed objects. > > I sometimes wonder whether having UPC codes physically bound to objects or > whether DNS has got a lot of people hooked on the idea that authority to > mint names and authority to bind them always go together. Those two things > coexist for understandable reasons at Heinz and in DNS. But the next > generation of Internet naming and binding systems should separate the two. > > Tim. > > Tim Kindberg > > internet & mobile systems lab hewlett-packard laboratories > 1501 page mill road, ms 1u-17 > palo alto > ca 94304-1126 > usa > > timothy@hpl.hp.com > voice +1 650 857 5609 > fax +1 650 857 2358 -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Thu Jan 25 15:53:40 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08548 for ; Thu, 25 Jan 2001 15:53:39 -0500 (EST) 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 PAA28428; Thu, 25 Jan 2001 15:31:48 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679674 for URN-IETF@LISTS.NETSOL.COM; Thu, 25 Jan 2001 15:31:38 -0500 Received: from case.vlc.com.au (case.vlc.com.au [203.27.111.4]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA28421 for ; Thu, 25 Jan 2001 15:31:34 -0500 (EST) Received: from vlc.com.au (host212-140-119-148.host.btclick.com [212.140.119.148]) by case.vlc.com.au (8.9.3/8.9.3) with ESMTP id EAA20816; Fri, 26 Jan 2001 04:17:19 +0800 X-Mailer: Mozilla 4.76 [en]C-{C-UDP; OWL-18191} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A7049A7.935AB1B4@thinkingcat.com> <200101251426.GAA26538@orpheus.cs.sfu.ca> <3A7049A7.935AB1B4@thinkingcat.com> <5.0.2.1.1.20010125084954.0308ae38@hplex1.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Justin Couch Message-ID: <3A708B91.D57B06FF@vlc.com.au> Date: Thu, 25 Jan 2001 20:24:49 +0000 Reply-To: Justin Couch From: Justin Couch Organization: The Virtual Light Company Subject: Re: NID registration for ISBN To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Tim Kindberg wrote: > This is a good opportunity for me to try to spell out what has been > bemusing me about the URN/URI community, looked at from the point of view [snip] > That is, the goal seems to be a system that would give the same > 'authoritative' (the URN community's word) answer to everyone, every time, > wherever they are. [snip] > One name -- let's call it upca:78996800002 -- has bindings in multiple > naming contexts: in each case, to a record containing a URL (we're > considering Xlink). > > Which of the bindings is 'authoritative'? Our answer is: they are all > equally authoritative. URN's deal nicely with this too. You can use any one of the resolvers to either resolve a URN (or URI for that matter) to either a single answer, or all possible answers. What you choose depends on your network bandwidth and responsiveness of the servers. In fact, if you want, you can put multiple different resolver schemes together (something that has been a special focus of my use of URNs). That is, when I ask for the URN to resolve, I can ask for it to return all answers and then decide which of those I want to read. A simple GUI might present a list on your PDA (that has just scanned the item) and you select the appropriate information. Then you can make use of the URCs to deliver whatever other information about the appropriateness of the person supplying the answer or anything else (URCs are still *very* nebulous concepts at the moment). -- 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 processes 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 Sat Jan 27 13:34:02 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17350 for ; Sat, 27 Jan 2001 13:34:01 -0500 (EST) 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 NAA13599; Sat, 27 Jan 2001 13:22:07 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8680588 for URN-IETF@LISTS.NETSOL.COM; Sat, 27 Jan 2001 13:19:54 -0500 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 NAA13587 for ; Sat, 27 Jan 2001 13:19:50 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA06698; Sat, 27 Jan 2001 13:03:50 -0500 (EST) References: <200101271739.f0RHdU628865@chmls20.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20010127130350.C299@bailey.dscga.com> Date: Sat, 27 Jan 2001 13:03:50 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/ To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200101271739.f0RHdU628865@chmls20.mediaone.net>; from creitzel@mediaone.net on Sat, Jan 27, 2001 at 12:39:30PM -0500 There is a process for registering URN namespace (RFC 2611) which this namespace should follow. I've done others so I might as well do this one. There are a couple of issues here though: 1) slashes ('/') are not allowed to be used un-percent-encoded in a URN thus that leading slash violates the URN syntax rules 2) draft-leach-uuids-guids-01.txt (August '98) describes the UUID/GUID algorithm and provides a way of creating one if you don't have a MAC address handy. You can find a copy here: http://www.opennc.org/dce/info/draft-leach-uuids-guids-01.txt My proposed URN GUID namespace will follow the DCE rules but won't allow the slash (as required). It will reference the DCE spec but will provide text for sufficiently unique system identifiiers without a MAC address. -MM On Sat, Jan 27, 2001 at 12:39:30PM -0500, Charles Reitzel wrote: > That would be XML Data, which is one of the early schema proposals and was > submitted by Microsoft. It has only NOTE status. > > See http://www.w3.org/TR/1998/NOTE-XML-data-0105/ > > Charles Reitzel > > >Date: Fri, 26 Jan 2001 16:19:01 -0800 > >From: "Cox, Roger" > > > >The xml data type namespace > >urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/ > >seems to be in common use, but I cannot find the > >definition. Where is it? > >Thank you. -- -------------------------------------------------------------------------------- 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 Jan 30 07:43:11 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04340 for ; Tue, 30 Jan 2001 07:43:11 -0500 (EST) 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 HAA07203; Tue, 30 Jan 2001 07:31:24 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8682683 for URN-IETF@LISTS.NETSOL.COM; Tue, 30 Jan 2001 07:30:47 -0500 Received: from post.it.helsinki.fi (post.it.helsinki.fi [128.214.205.24]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA07195 for ; Tue, 30 Jan 2001 07:30:44 -0500 (EST) Received: from helsinki.fi (kvp13.lib.helsinki.fi [128.214.71.205]) by post.it.helsinki.fi (8.11.1/8.11.0-SPAMmers-sod-off) with ESMTP id f0UCOfx28653; Tue, 30 Jan 2001 14:24:41 +0200 (EET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------5E556AB3B4F7489B99581A0F" Approved-By: Juha Hakala Message-ID: <3A76B264.E1B8D3@helsinki.fi> Date: Tue, 30 Jan 2001 14:24:04 +0200 Reply-To: Juha Hakala From: Juha Hakala Organization: HYK Subject: NID registration for NBN To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------5E556AB3B4F7489B99581A0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, Please find attached the third and hopefully last version of the URN NID registration request for national bibliography numbers (NBNs). The text has already been sent to the Internet drafts editor. The previous version did not attract criticism from URN community, but some colleagues from national libraries (especially Ray Denenberg from the Library of Congress) have provided useful feedback. I have done my best to accommodate these comments into the present text. No fundamental changes have been necessary, but the present document should be more clear, and its English is definitely better (a bunch of missing articles has been added, for instance). Some national libraries are already actively assigning URNs based on NBNs to their electronic resources. Thus we are quite eager to finalise the NID registration process. Of course, comments are still welcome. As regards the comments to the ISBN NID registration document sent last week to the URN list: feedback sent by Michael and Leslie did not leave much for me to say. The national bibliography databases' prominent status in resolution process is justified because these databases are a) authoritative and b) exhaustive. The NB databases are based on deposit collection, which contain a very large part of the published cultural heritage in each country. Local or publisher driven resolution services are much more limited in this respect. Nevertheless, the ISBN registration document does make room for resolution services provided by publishers (based on the ISBN publisher ID) since such services may complement the one provided by the national bibliography and the deposit collection. Best regards, Juha -- Juha Hakala Helsinki University Library juha.hakala@helsinki.fi --------------5E556AB3B4F7489B99581A0F Content-Type: text/plain; charset=us-ascii; name="draft-ietf-hakala-nbn-02.txt" Content-Disposition: inline; filename="draft-ietf-hakala-nbn-02.txt" Content-Transfer-Encoding: 7bit Network Working Group Juha Hakala Internet-Draft Helsinki University Library Category: Informational 30 January 2001 draft-ietf-hakala-nbn-02.txt Expires: 30 July 2001 Using National Bibliography Numbers as Uniform Resource Names Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on 30 July, 2001. Abstract This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats].Much of the discussion below is based on the ideas expressed in RFC 2288 [Lynch]. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. 1. Introduction As part of the validation process for the development of URNs the IETF working group agreed that it is important to demonstrate that the current URN syntax proposal can accommodate existing identifiers from well established namespaces. One such infrastructure for assigning and managing names comes from the bibliographic community. Bibliographic identifiers function as names for objects that exist both in print and, increasingly, in electronic formats. RFC 2288 [Lynch et. al.] investigated the feasibility of using three identifiers (ISBN, ISSN and SICI) as URNs. This document will analyse the usage of national bibliography numbers (NBNs) as URNs. The need to extend analysis to new identifier systems was briefly discussed in RFC 2288 as well, with the following summary: "The issues involved in supporting those additional identifiers are anticipated to be broadly similar to those involved in supporting ISBNs, ISSNs, and SICIs". A registration request for acquiring a Namespace Identifier (NID) "NBN" for national bibliography numbers has been written by the National Library of Finland on the request of the Conference of Directors of National Libraries (CDNL) and the Conference of the European National Librarians (CENL). The request is included in chapter 5 of this text. The document at hand is part of a global co-operation of the national libraries to foster identification of electronic documents in general and utilisation of URNs in particular. Some national libraries, including the national libraries of Finland, Norway and Sweden, are already assigning NBN-based URNs for electronic resources. We have used the URN Namespace Identifier "NBN" for the national bibliographic numbers in examples below. 2. Identification vs. Resolution As a rule the national bibliography numbers identify finite, manageably- sized objects, but these objects may still be large enough that resolution to a hierarchical system is appropriate. The materials identified by a national bibliography number may exist only in printed or other physical form, not electronically. The best that a resolver will be able to offer in this case is bibliographic data from a national bibliography database, including information about where the physical resource is stored in a national library's holdings. The URN Framework provides resolution services that may be used to describe any differences between the resource identified by a URN and the resource that would be returned as a result of resolving that URN. However, NBNs will be used for instance to identify resources in digital Web archives created by harvester robot applications. In this case, NBN will identify exactly the resource the user expects to see. 3. National bibliography numbers 3.1 Overview National Bibliography Number (NBN) is a generic name referring to a group of identifier systems utilised by the national libraries and only by them for identification of deposited publications which lack an identifier, or to descriptive metadata (cataloguing) that describes the resources. In many countries legal (or voluntary) deposit is being extended to electronic publications. Each national library uses its own NBN strings independently of other national libraries; there is no global authority which controls them. For this reason NBNs are unique only on national level. When used as URNs, NBN strings must be augmented with a controlled prefix such as country code. These prefixes guarantee uniqueness of the NBN-based URNs on the global scale. NBNs have traditionally been given to documents that do not have a publisher-assigned identifier, but are catalogued to the national bibliography. NBNs can be seen as a fall-back mechanism: if no other, better established identifier such as ISBN can be given, an NBN is assigned. In principle, NBN usage enables identification of any Internet document. Local policies may limit the NBN usage to a much smaller subset of documents. Some national libraries (e.g. Finland, Norway, Sweden) have established Web-based URN generators, which enable authors and publishers to fetch NBN-based URNs for their network documents. At least national libraries of Sweden and Finland are harvesting and archiving domestic Web documents (and a number of other libraries plan to start this activity), and long-time preservation of these materials requires persistent and unique identification. NBNs can be and are in fact already used as internal identifiers in these Web archives. Both syntax and scope of NBNs can be decided by each national library independently. Typically, an NBN consist of one or more letters and/or digits. This simple syntax makes NBNs infinitely extensible and very suitable for e.g. naming of the Web documents. For instance the application used by the national library of Finland for Web harvesting creates NBNs which are based on the MD5 checksum of the archived resource. 3.2 F-code F-code is the NBN used by the National Library of Finland. F-codes have been used since early 20th century to identify catalogue cards and later MARC records in the national bibliography. In 1998 the national library decided to enable the Finnish authors and publishers to assign F-codes to their Internet documents, if these documents do not qualify for other identifiers such as ISBN. F-codes, embedded into URNs, can be fetched from the URN generator (http://www.lib.helsinki.fi/cgi- bin/urn.pl) developed in co-operation between the national library of Finland and the Lund University library, NETLAB unit. Attached to the generator there is a user guide (http://www.lib.helsinki.fi/meta/URN- opas.html; only in Finnish), which tells the users how to use URNs. F-codes are also used within the Web harvesting and archiving software (http://www.csc.fi/sovellus/nedlib/), which has been built for the Networked European Deposit Library (NEDLIB) project (see http://www.kb.nl/nedlib). NEDLIB harvester calculates MD5 checksum for each archived resource, and then builds an NBN-based URN from the checksum. The URN serves then as a unique identifier to the archived resource. Traditional identifiers can not be used for this purpose, since there may for instance be several variants of a book which (quite rightly so) all have the same ISBN. Moreover, identifiers embedded into a document do not necessarily belong to the document itself; thus the Web archiving application can not trust the identifiers embedded into the body of the document. The F-code built by the URN generator consist of: Prefix (for example fe) Year (YYYY; for example 1999) Number (for example 1055) The generator also adds namespace identifier "NBN" and ISO 3166 country code. Thus a URN based on F-code would in this case be for instance urn:nbn:fi-fe19991055. URNs created by the Web archiving application have similar overall structure, except that prefix (which may be defined by the operator) is fea and year is not used. An example: urn:nbn:fi-fea- 5c5875e6e49ae649cad63e5ee4f6c346. F-codes never need any special encoding when used as URNs, since they consist of alphanumeric codes only (0-9, a-z). This is often the case for other national libraries' NBN systems as well. 3.3 Encoding Considerations and Lexical Equivalence Embedding NBNs within the URN framework usually presents no particular encoding problems, since all of the characters that can appear in commonly used NBN systems can be expressed in special encoding, as described in RFC 2141 [MOATS]. When an NBN is used as a URN, the namespace specific string will consist of three parts: prefix, consisting of either a two-letter ISO 3166 country code or other registered string, delimiting character which is either hyphen (-) or colon (:), and NBN string assigned by the national library. Delimiting characters are not lexically equivalent. Hyphen is always used for separating the prefix and the NBN string. Colon is used as the delimiting character if and only if a country code -based NBN namespace is split further in smaller sub-namespaces. If there are several national libraries in one country, these libraries can split their national namespace into smaller parts using this method. A national library may also assign a trusted organisation(s) its own sub-namespace. For instance, the national library of Finland has given Statistics Finland (http://www.stat.fi/index_en.html) a sub-namespace "st" (e.g. urn:nbn:fi:st:). The Finnish Council of State (http://www.vn.fi/vn/english/index.htm) will use sub-namespace "vn" (e.g. urn:nbn:fi:vn). Non-ISO 3166 -prefixes, if used, must be registered on the global level. The Library of Congress will maintain the central register of reserved codes. This register will be available to the national libraries and other users in the Web. Sub-namespace codes beneath a country-code -based namespace need to be registered on the national level by the national library which assigned the code. The national register must be available in the Web and should also be linked to the global register maintained by the Library of Congress. Two-letter codes may not be used as non-ISO prefixes, since all such codes are reserved for existing and possible future ISO country codes. If there are several national libraries in one country who use the same prefix - for instance, a country code -, they need to agree on how to split the namespace between them. Models: URN:NBN:- URN:NBN::- URN:NBN:- Examples: URN:NBN:fi-fe19981001 (A "real" URN assigned by the National Library of Finland). 3.4 Resolution of NBN-based URNs The (usually) country code -based prefix part of the URN namespace specific string will provide a guide to where to find a resolution service, and the NBN register will identify the assigning agency. Once the NBN-based URN resolution is in global usage, the number of prefixes will slowly approach and may eventually exceed the number of national libraries. If NBN assignment for a given country is limited to the national bibliography database, then all NBN-based URNs for that country will be resolved there. In one model these databases contain detailed resource descriptions including URLs, which will point both to the copy of the document in the Internet and to the copy in the national library's (legal) deposit collection. Due to the limitations in the usage of legal deposit documents it is possible that the deposited electronic materials can not be delivered in electronic form outside the premises of the national library. If it is possible for the authors and publishers to retrieve NBNs to Web documents and there is no obligation to deposit thus identified documents to the national library, URN resolution service is not possible without a national Web index and archive, maintained by the national library or other organisation(s). A Web index/archive will also resolve machine-generated URNs to the archived Web documents. 3.5 Additional considerations Guidelines adopted by each national library define when different versions of a work should be assigned the same or differing NBNs. These rules apply only if identifier assignment is done manually. If identifiers are allocated programmatically, the only criteria that can be used is that two documents which are identical on the bit level (have the same MD5 checksum) are deemed identical and should receive the same NBN. The likelihood of this happening to dissimilar documents is about 2^64, according to the RFC1321. The rules governing the usage of NBNs are less strict than those specifying the usage of ISBN or other, better established identifiers. Since the NBNs have up to now been given only by the personnel (cataloguers) working in the national libraries, the identifier assignment has in practice been well co-ordinated. A NBN-based URN will resolve to single instance of the work if identifier assignment has been automatic. Given the nature of NBNs it is also likely that different versions of the same work will receive different NBNs even if the identifier is given manually. 4. Security Considerations This document proposes means of encoding several existing bibliographic identifiers within the URN framework. This document does not discuss resolution except at a very generic level; thus questions of secure or authenticated resolution mechanisms are out of scope. It does not address means of validating the integrity or authenticating the source or provenance of URNs that contain bibliographic identifiers. Issues regarding intellectual property rights associated with objects identified by the various bibliographic identifiers are also beyond the scope of this document, as are questions about rights to the databases that might be used to construct resolvers. 5. Namespace registration URN Namespace ID Registration for the National Bibliography Number (NBN) Namespace ID: NBN This Namespace ID has been in production use in demonstrator systems since summer 1998; thousands of URNs from this namespace have already been delivered in Finland, Sweden and Norway. Registration Information: Version: 3 Date: 2001-01-30 The first registration of the NID "NBN" was done via the URN WG in 1998. The second, slightly edited registration request was done in 1999. Declared registrant of the namespace: Name: Juha Hakala E-mail: juha.hakala@helsinki.fi Affiliation: Helsinki University Library - The National Library of Finland, Conference of European National Librarians (CENL) and Conference of Directors of National Libraries (CDNL) Address: P.O.Box 26, 00014 Helsinki University, Finland Both CENL and CDNL made decisions to foster the usage of URNs during 1998. The latter organisation has set up a working group for this purpose. One item in the common work plan is utilisation of national bibliography numbers as URNs for identification of grey literature published in the Internet. The NBN namespace will be available for free for all national libraries in the world. Declaration of syntactic structure: The namespace specific string will consist of three parts: prefix, consisting of either a two-letter ISO 3166 country code or other registered string and sub-namespace codes, delimiting characters (colon (:), or hyphen (-), and NBN string assigned by the national library. Colon is used as a delimiting character only within the prefix, between ISO 3166 country code and sub-namespace code, which splits the national namespace into smaller parts. This technique can be used when there are several national libraries, which all need their own namespaces, or when the national library allows trusted partners to set up their own sub- namespaces within the national NBN namespace. Dividing non-ISO 3166 -based namespaces further with sub-namespace codes is not allowed. Hyphen is used as a delimiting character between the prefix and the NBN string. Within the NBN string, hyphen can be used for separating different sections of the code from one another. Non-ISO prefixes used instead of the ISO country code must be registered. A global registry, maintained by the Library of Congress, will be created and made available via the Web. Contact information: nbn.register@loc.gov.us. All two-letter codes are reserved for existing and possible future ISO country codes and may not be used as non-ISO prefixes. Sub-namespace codes must be registered on the national level by the national library which assigned the code. The register must be available via the Web, and it should be accessible via the global registry set up by the Library of Congress. Models: URN:NBN:- URN:NBN:- URN:NBN:- Example: A country code -based URN: URN:NBN:fi-fe19981001 (A URN assigned by the National Library of Finland). Relevant ancillary documentation: National Bibliography Number (NBN) is a generic name referring to a group of identifier systems used by the national libraries for identification of deposited publications which lack an identifier, or to descriptive metadata (cataloguing) that describes the resources. Each national library uses its own NBN system independently of other national libraries; there is no global authority which controls syntax of these identifier systems. Each national library can decide freely which resources will receive NBNs. These identifiers have traditionally been assigned to documents that do not have a publisher-assigned identifier, but are nevertheless catalogued to the national bibliography. Typically identification of grey publications have largely been dependent on NBNs. Some national libraries (Finland, Norway, Sweden) have established Web- based URN generators, which enable authors and publishers to fetch NBN- based URNs for their network documents. Both syntax and scope of NBNs is decided by each national library independently. Typically, a NBN consist of one or more letters and a number. Identifier uniqueness considerations: NBN strings assigned by two national libraries may be identical. For this reason usage of a controlled prefix in the namespace specific string is obligatory in order to guarantee global uniqueness of NBN- based URNs. In the national level, libraries utilise different policies for guaranteeing uniqueness. A national library may automate the delivery of NBN-based URNs. In this case, the NBNs are assigned sequentially by a program (URN generator). Identifier persistence considerations: Persistence of the NBNs as identifiers is guaranteed by the persistence of national libraries and information systems, such as national bibliographies, maintained by them. NBNs have been used for several centuries for printed materials. NBN-based identification of electronic documents is a recent practice, but it is likely to continue for a very long time. Process of identifier assignment: Assignment of NBN-based URNs is always controlled on national level by the national library / national libraries. The Conference of Directors of National Librarians (CDNL) has established in 1999 a task force, which will co-ordinate the URN usage in all national libraries. National libraries may choose different strategies in assigning NBN- based URNs. One option is assignment by the library personnel only. This is done when the document is catalogued into the national bibliography. Thus in this case the national bibliography database will serve as the URN resolution service. A national library may also set up a URN generator (generators), and allow publishers and authors to retrieve NBN-based URNs from there. In this case there is no guarantee that the identified resource will ever be catalogued into the national bibliography, and URN resolution is dependent on Web index/archive. Process for identifier resolution: URNs based on NBNs will be primarily resolved via the national bibliography databases. In one model these databases contain detailed resource descriptions including URLs, which will point both to the copy of the document in the Internet and to the copy in the national library's (legal) deposit collection. Due to the limitations in the usage of legal deposit documents it is possible that the deposited materials can not be delivered outside the premises of the national library. For those documents not catalogued into the national bibliography database URN resolution may take place via national or international Web indexes and/or archives. Nordic national libraries have established in autumn 2000 a joint initiative called Nordic Web Archive (NWA), which aims at creating a national Web archive into all Nordic countries. Indexes to these archive systems will be able to act as URN resolution services of any document which a) is or has been available via the Web, and b) had an URN embedded into it. Country code and additional sub-namespace information will provide a guide to where to find appropriate resolution services. For instance, if the country code is "fi", the primary resolution service is the national bibliography database. Secondary resolution service is the Web archive. Generally, there will be one or more resolution services specified for each country, depending on the assignment policy and services of the national library. If NBN assignment is limited to the national bibliography database, then all NBN-based URNs for that country will be resolved there. If the authors and publishers have been allowed to retrieve NBNs to their Web resources, URN resolution services require a national Web archive. If other organisations have been allowed to assign NBNs, they may also set up their own URN resolution services. Rules for Lexical Equivalence: None in the global level. Any national library may provide its own rules, on the basis of its NBN syntax. Conformance with URN Syntax: All NBNs we know of are ASCII strings consisting of letters (a-z) and numbers (0-9). If NBN contains characters that are reserved in the URN syntax, this data must be presented in hex encoded form as defined in RFC2141. A national library may limit the full scope of its NBN strings in URN usage in such a way that there are no reserved characters in the URN namespace specific strings. Validation mechanism: None specified on the global level. A national library may use NBNs, which contain a checksum and can therefore be validated, but this is for the time being not a common practice. Scope: Global. 6. References [Daigle et al.]: Daigle, L., van Gulik, D., Iannella, R. & Faltstrom, P.: URN Namespace Definition Mechanisms, RFC2611, June 1999. [Lynch] Lynch, C., Using Existing Bibliographic Identifiers as Uniform Resource Names, RFC 2288, February 1998 [Moats] Moats, R., "URN Syntax", RFC 2141, May 1997. 7. Authors' Address Juha Hakala Helsinki University Library - The National Library of Finland P.O. Box 26 FIN-00014 Helsinki University FINLAND E-mail: juha.hakala@helsinki.fi 8. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. --------------5E556AB3B4F7489B99581A0F-- From owner-urn-ietf@LISTS.NETSOL.COM Wed Jan 31 10:35:32 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17725 for ; Wed, 31 Jan 2001 10:35:31 -0500 (EST) 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 KAA16746; Wed, 31 Jan 2001 10:24:13 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8683536 for URN-IETF@LISTS.NETSOL.COM; Wed, 31 Jan 2001 10:23:33 -0500 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 KAA16737 for ; Wed, 31 Jan 2001 10:23:31 -0500 (EST) 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 HAA04957; Wed, 31 Jan 2001 07:17:22 -0800 (PST) Received: (from cameron@localhost) by orpheus.cs.sfu.ca (8.9.1/8.9.1) id HAA11009; Wed, 31 Jan 2001 07:17:21 -0800 (PST) Approved-By: Rob Cameron Message-ID: <200101311517.HAA11009@orpheus.cs.sfu.ca> Date: Wed, 31 Jan 2001 07:17:21 -0800 Reply-To: Rob Cameron From: Rob Cameron Subject: Re: NID registration for NBN To: URN-IETF@LISTS.NETSOL.COM Juha, With respect to the NBN document, I have one immediate concern that you may wish to address in regard to the Rules for Lexical Equivalence. Just as you state that x and X are equivalent in the ISBN document (with the implication that X is canonical) I believe that you should make a similar statement with respect to the country code component of an NBN. Are "FI", "fi", "Fi" and "fI" all legal and equivalent? Personally, I think it's best to stick with ISO 3166 precisely and require "FI". This problem is an immediate concern to us in our implementation of the NBN domain under the bibp: scheme as well. Even if you do not wish to change the document, I would like to know your thoughts on this. We want to make our bibp:NBN services interoperate with any urn:NBN services that are developed. Are there any urn:NBN servers that are available at this time? We would appreciate the opportunity to direct NBN requests to them; we would also provide feedback on any interoperability concerns that arise. On a general note, thanks for considering and responding on my point with respect to resolution models. Our work with the bibp: scheme will continue to pursue the decentralized model, but I agree that there is no need to refer to this in the urn:ISBN document. Please forgive me if my enthusiasm for our current work overflows sometimes into the realm of what some might call 'advertizing.' Whereas the pessism of many with respect to URN work is based partly on doubts about whether DDDS resolution services will ever be deployed, we are excited by the fact that the resolution technology we require is already widely deployed world-wide. We also think our model is the Right Thing for future bibliographic services: a decentralized model that gives local libraries precedence over publishers and global services and gives users ultimate control to set their own bibliographic service providers.