From andy@hxr.us Thu Nov 3 05:34:44 2011 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A811E8088 for ; Thu, 3 Nov 2011 05:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BlWLCmYWxeh for ; Thu, 3 Nov 2011 05:34:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6511E80D3 for ; Thu, 3 Nov 2011 05:34:43 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1218840vcb.31 for ; Thu, 03 Nov 2011 05:34:43 -0700 (PDT) Received: by 10.52.36.112 with SMTP id p16mr9462545vdj.102.1320323682951; Thu, 03 Nov 2011 05:34:42 -0700 (PDT) Received: from zx80.arin.net (core.arin.net. [192.149.252.11]) by mx.google.com with ESMTPS id ib2sm7742956vdb.1.2011.11.03.05.34.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 05:34:37 -0700 (PDT) From: Andy Newton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Nov 2011 08:33:21 -0400 References: <4EB21B3B.7080708@stpeter.im> To: urn@ietf.org Message-Id: <3BC654B8-C7D5-4842-8A33-0E5CFE6941EB@hxr.us> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [urn] Fwd: [weirds] FYI: workshop on domain names and persistence X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:34:44 -0000 This seems very URNish if you ask me. -andy Begin forwarded message: > From: Peter Saint-Andre > Date: November 3, 2011 12:40:27 AM EDT > To: weirds@ietf.org > Subject: [weirds] FYI: workshop on domain names and persistence > > I learned today of a call for participation in a workshop on domain > names and persistence to be held in Bristol, UK on December 8: > > http://www.w3.org/2001/tag/doc/idcc_workshop.html > > It's possible that some folks on this list might be interested. Feel > free to forward as appropriate. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From jar@creativecommons.org Thu Nov 3 10:29:43 2011 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F3911E8132 for ; Thu, 3 Nov 2011 10:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYO7lycnLvPx for ; Thu, 3 Nov 2011 10:29:43 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84411E80DA for ; Thu, 3 Nov 2011 10:29:42 -0700 (PDT) Received: by qadc10 with SMTP id c10so1717354qad.31 for ; Thu, 03 Nov 2011 10:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.219 with SMTP id o27mr877285qci.117.1320341380394; Thu, 03 Nov 2011 10:29:40 -0700 (PDT) Received: by 10.229.84.200 with HTTP; Thu, 3 Nov 2011 10:29:40 -0700 (PDT) In-Reply-To: <3BC654B8-C7D5-4842-8A33-0E5CFE6941EB@hxr.us> References: <4EB21B3B.7080708@stpeter.im> <3BC654B8-C7D5-4842-8A33-0E5CFE6941EB@hxr.us> Date: Thu, 3 Nov 2011 13:29:40 -0400 Message-ID: From: Jonathan Rees To: Andy Newton Content-Type: text/plain; charset=UTF-8 Cc: urn@ietf.org Subject: Re: [urn] Fwd: [weirds] FYI: workshop on domain names and persistence X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:29:43 -0000 In fact it is very URNish. (I'm one of the organizers, and on this list.) You're all most welcome to come. Think of it as an examination of the prospects for URNs in http: space. Positive and negative results both welcome here. Best Jonathan On Thu, Nov 3, 2011 at 8:33 AM, Andy Newton wrote: > This seems very URNish if you ask me. > > -andy > > Begin forwarded message: > >> From: Peter Saint-Andre >> Date: November 3, 2011 12:40:27 AM EDT >> To: weirds@ietf.org >> Subject: [weirds] FYI: workshop on domain names and persistence >> >> I learned today of a call for participation in a workshop on domain >> names and persistence to be held in Bristol, UK on December 8: >> >> http://www.w3.org/2001/tag/doc/idcc_workshop.html >> >> It's possible that some folks on this list might be interested. Feel >> free to forward as appropriate. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From juha.hakala@helsinki.fi Tue Nov 15 04:28:05 2011 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5821F8BB3 for ; Tue, 15 Nov 2011 04:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoj8Y-p7H-Rr for ; Tue, 15 Nov 2011 04:28:01 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8299A21F8DD0 for ; Tue, 15 Nov 2011 04:27:56 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id pAFCRo3T022641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Nov 2011 14:27:51 +0200 Message-ID: <4EC25AC6.9060404@helsinki.fi> Date: Tue, 15 Nov 2011 14:27:50 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alfred Hoenes References: <201110312002.VAA11600@TR-Sys.de> In-Reply-To: <201110312002.VAA11600@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:28:05 -0000 Hello Alfred; all, Thank you for submitting a new, improved version of RFC2141bis. I have a few comments to the draft. Most concern the text itself; some are more generic issues which are just implied in the document. In chapter 1.2 (Background) we quote RFC1738: o Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in the assignment of its name. Instances of digital resources do have a short life time. After a few decades we may no longer have software capable of interpreting the bits. Metadata about the resource (including technical metadata which may help digital archaeologists) may however still be available. And if migration has been used as a preservation strategy, there will be other instances of the resource which are still accessible. Therefore should may adjust the purpose / function of a URN (the first bullet point in 1.2) as expressed in RFC 2141 slightly, to say that URNs are used for recognition, or for access to diverse metadata (formerly characteristics) about the resource, or access to the resource itself or other resources related to it, such as preceding or later versions of the original resource. This is still a simple use scenario, where I have (in library slang) different manifestations of a single expression of a work (for instance, a Finnish translation of Joyce's Ulysses in Word 97 and PDF/A. I may also have multiple expressions of a work, and 1-n versions of each one of these. URN resolution must support resource interlinking, since a user looking for e.g. the first Finnish translation of Ulysses may also be able to use a more modern Finnish translation or the original text. We have not restarted the discussion of what URNs can be applied to. In 7.1 (bottom of the page 16) we say that URNs serve as identifiers for concrete and abstract objects that have network accessible instances and/or metadata. In short, URNs must be actionable one way or another; resolution should provide some kind of result. This specification is OK, especially if we keep in mind that the abstract object itself can be a metadata record. For instance, some national libraries routinely describe two variants of a printed book (paperback & hardcover, for instance) in the same metadata record. If record has an NBN, one may argue that it identifies the record, not the books. From the URN resolution process point of view this makes sense, because the URN will resolve to the metadata record. As the RFC2141bis already says, URNs may also be assigned to works, which are abstract objects having 0-n manifestations (there are plenty of works that have been lost, and many have reached us in truncated form). In chapter 2 is discussed in the bottom of page 9 & top of the page 10. We should refer here to RFC2483 (which specifies the resolution services) and use an example which is based on an existing service. The current example is a bit puzzling; for the time being it is not possible to specify the type of metadata wanted because no such service exists. A note should be added, saying that the services nailed down in RFC2483 are not sufficient. For instance, it is not possible to specify what type of metadata is needed (descriptive / administrative / structural) and in which format (there are plenty of formats for descriptive metadata, such as MARC21 or Dublin Core). RFC2483 refers to URC (Uniform Resource Characteristics) which was never implemented in practice. (As an aside, there are plenty of other reasons for updating that RFC.) On page 10, two options for supporting fragment identifiers are specified. I am not sure this dichotomy works. Method a) (fragment identifiers are assigned individually) is of course OK. But if fragment identifiers are generally applicable (method b), then there is no need to repeat the specification at the namespace level. Assuming that fragments can be used with PDF documents, then the same principles should apply across all namespaces which do approve fragment usage. In chapter 2.3.3 (in the middle of the page 14) we say: "In a textual context for a URN, the NSS part ends when an octet/ character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the NSS." This does not take into account the discussion we've had on the list. First, whatever is said here applies to plain text only. In structured text parsing URNs should be easy. Second, most standard identifiers have well known syntax. ISSN has 8 characters, ISBN either 10 or 13, and ISTC 16. Parsing urn:issn is easy; after 8 characters you are done, even if the next character is not from the excluded set. Any namespace specific rules for parsing and lexical equivalence must be expressed in the namespace registration. In chapter 5. (top of the page 15), examples should include and . As the former is not part of the URN, must be ignored in the analysis, while must not. Terminological comment We speak (almost) interchangeably about objects which have instances, or resources which have versions. We may also refer either to resource characteristics or object metadata, or use library related concepts of work, expression and manifestation. Consolidation of the terminology used would make the documents easier to understand. I suggest that we carry out such a task between the authors before the next versions of these I-Ds are published. All the best, Juha Alfred � wrote: > The IETF I-D Submission Tool wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the >> Uniform Resource Names, Revised Working Group of the IETF. >> >> Title : Uniform Resource Name (URN) Syntax >> Author(s) : Alfred Hoenes >> Filename : draft-ietf-urnbis-rfc2141bis-urn-01.txt >> Pages : 28 >> Date : 2011-10-31 >> >> Uniform Resource Names (URNs) are intended to serve as persistent, >> location-independent, resource identifiers. This document serves as >> the foundation of the 'urn' URI Scheme according to RFC 3986 and sets >> forward the canonical syntax for URNs, which subdivides URNs into >> "namespaces". A discussion of both existing legacy and new >> namespaces and requirements for URN presentation and transmission are >> presented. Finally, there is a discussion of URN equivalence and how >> to determine it. This document supersedes RFC 2141. >> >> The requirements and procedures for URN Namespace registration >> documents are currently set forth in RFC 3406, which is also being >> updated by a companion, revised specification dubbed RFC 3406bis. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-01.txt >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > > [[ speaking as the document editor ]] > > This draft version contains many updates, > as outlined in the new Appendix D.5 of the draft. > > Most importantly, based on the list discussion, the open issue > regarding the NSS character repertoire is now regarded closed; > there have been no concerns raised against now allowing "&" and "~" > in the NSS syntax, and hence bringing it in alignment with RFC 3986. > Hence, much of the material from s2.2 has been moved to a new > Appendix (C), and Appendix B (previously: C) has been filled in now. > Please note also that the previous Appendix A has been moved to the > end of the memo and now has become Appendix E, which has caused > some renumbering of the more persistent Appendices of the draft. > > Due to time constraints and technical issues I had in the past with > Internet/email access, the elaborations on the fragment identifier > issues have not yet been fully aligned with the vast amount of list > discussion we had in the past regarding this topic. I regard this > topic as not yet finally closed, and will bring my considerations > to the list a.s.a.p. > > So, in order to bring forward the discussion on the draft, please > currently focus on the other open issues tagged in (editorial) Notes > inside the draft, which have not received much comments so far. > In particular, we should hopefully be able to close the NID syntax > issues discussed in section 2.1 soon, with your help! > > I plan to submit another revision of this draft during the IETF 82 > week, once draft submission is open again. > > Kind regards, > Alfred. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From juha.hakala@helsinki.fi Thu Nov 17 02:18:29 2011 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A12D21F9BB0 for ; Thu, 17 Nov 2011 02:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=1.427, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkrjCyGUYsP7 for ; Thu, 17 Nov 2011 02:18:27 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79521F9B9F for ; Thu, 17 Nov 2011 02:18:26 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id pAHAILB1009254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 12:18:22 +0200 Message-ID: <4EC4DF6D.7070209@helsinki.fi> Date: Thu, 17 Nov 2011 12:18:21 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alfred Hoenes References: <201110312251.XAA11909@TR-Sys.de> In-Reply-To: <201110312251.XAA11909@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:18:29 -0000 Hello Alfred; all, Below is my take on the open issues listed by Alfred, plus some additional comments. Abstract URN is a resource identifier; therefore the end of the last sentence of the first para could be changed into ... make available generic and persistent network-based resolution services for the identified resources (documents, artifacts and other objects, and metadata related to them). Chapter 2 Statement "identifiers are never assigned to more than one resource" needs some tuning. Resources themselves may be static or dynamic (as pointed out in page 19). The identified resource may be a metadata record which describes a collection which contains a number of objects. The important thing is that the resolution process itself is clear; there must always be one and only one entity to resolve. Suggested new formulation: For the purposes of URNs, a "namespace" is a collection of uniquely assigned identifiers. That is, the identifiers are never assigned to more than one resource. These resources may be stable (e.g. a doctoral dissertation) or dynamic (e.g. a continuously evolving web site of a periodical). When the identified resource is a metadata record, such record may describe several objects (such as two versions of a book) or a collection of objects. Once assigned, URNs are never re-assigned to a different resource. A single resource, however, may have more than one URN assigned to it since the namespaces are not mutually exclusive. Chapter 3.1 Experimental namespaces After considering the issue, I am in favour of removing experimental namespaces. In 12 years, not a single experimental namespace has been registered. Nor do I foresee a need for them, as identifier systems which deserve a URN namespace should be relatively stable. As an aside, we may need informal and experimental services. But these services (or mechanism for registering them) should not be described in rfc3406bis, but in rfc2483bis. Chapter 3.3 Formal namespaces It has been easy to register formal URN namespaces. In order to guarantee the reliability and persistence of the URN system, control should be tightened in the future, and rfc3406bis should provide tools for this. Given the experiences from the last 12 years, the key factors here are scope (type of resources to be identified) and user community (who is entitled to assign identifiers in this namespace). Control is the key factor; the more clearly the scope and the user community are specified, the better. On the other hand, an identifier which covers everything and can be used by anybody should be treated with caution, due to overlap with all the other URN namespaces and total lack of control in the identifier assignment. To illustrate the problem, we may compare urn:isbn and urn:uuid. ISBNs are assigned by large publishers and ISBN agencies for books. The system has been in operation for almost 40 years, and is deeply embedded into the book trade (which does not mean that everyone uses it correctly, or according to the same principles). UUIDs can be assigned to everything (including books) by anyone. There is no control over this namespace; nobody knows how it is used and by whom. Some users may have utilized in a highly useful manner and this is to be hoped; once a namespace has been approved it can never be discontinued, unless it can be proven that zero URNs have been assigned (or remain resolvable). It is not sufficient to give "some consideration as to the longevity and maintainability of the namespace" (see page 6). Careful consideration is called for. As regards the three bullet points in page 7, I suggest the following changes: - the organization maintaining the URN Namespace should demonstrate stability and the ability to maintain the URN namespace for a long time, and/or it should be clear how the namespace can continue to be usable/useful if the organization ceases to be able to foster it; - the organizations assigning URNs should demonstrate ability and competency in name assignment; this should improve the likelihood of persistence (e.g., to minimize the likelihood of conflicts); - the organizations assigning URNs MUST follow the rules and regulations outlined in namespace registration reguests. They SHOULD always use the identifier which is the best match for the resource at hand (e.g. ISSN for serials). However, identifiers which do not have a registered URN namespace MUST NOT be expressed as URNs. - the user organizations need to commit to not re-assign existing names. Old names MUST continue to be valid, even if the owners or assignees of those names are no longer members or customers of these organizations; this does not mean that there must be resolution of such names, but that they must not resolve the name to false or stale information, and that they must not be reassigned. If the review process is made more strict, then more time than the current two weeks is needed. I suggest a review period of 8 weeks; this is still a very short time compared to the life time of namespaces (which should equal or exceed that of the URNs in that namespace). 4.4. Registration documents After having written a few namespace registrations, I prefer keeping the namespace and community considerations separate. But it is necessary to clarify the differences between the two. My take on this is that we could rephrase thse aspects into technical and organisational considerations. Technical (namespace) considerations are primarily technical and should outline the scope (types of resources to be identified), identifier assignment process, services needed (some of which may be non-existent by the time of registration), and the resolution process. Organizational (community) considerations should clarify the background of the identifier used (formal standard or something else), its relation ot other identifier systems with or without URN namespace, and different aspects of the user community (who is allowed to assign these identifiers; who can use them for resolution; who maintains the resolution services). Something may also be said about the costs of maintaining the system. IANA review should pay particular attention to the scope and user community (from the assignment point of view) issues. Standard identifier namespace registrations should always involve the maintenance agency of the standard in question. 4.4.4 IANA considerations There are a lot of strings (in addition to "urn-" that must be reserved from IETF point of view, such as uri, urc, url, iana, ietf, iesg, and so on. All known identifier acronyms should be reserved for those identifier systems. Registration requests with intentionally misleading NIDs (e.g. NID UNESCO when the request has nothing to do with UNESCO) should be turned down. Validation mechanism (page 20) This section may still need some work. First, it is possible to validate NSS if the identifier has a mechanism for it. For instance, when ISSN or ISBN is used as URN, it is possible to check that the namespace specific string is a valid ISBN or ISSN. In order to do this, the validator must be aware of the identifier syntax. Second (and this is point 1 in the current version of the document), it is necessary to check the NID. There are a number of opportunities here. For instance, URN parsing may have revealed that the NSS is ISTC. Even if the ISTC string were OK the URN would not be correct, since ISTC does not have a URN namespace (which may not prevent some people from using NID ISTC). We may also have valid NID (such as ISSN), but NSS that does not belong to this namespace; it can be either some other identifier (such as ISBN) or something unrecognizable. Such NID - NSS mismatch are fatal because they will prevent successfull resolution. Third (point 2 in the current document) step is to check if the (valid) URN can be used for resolution. Many syntactically URNs will fail at this point; for instance, most URN:ISBNs are not functional yet. But this has nothing to do with the validity of those URNs; the problem is in the infrastructure. Thus this step is not part of the URN validation, but it can still be included as validation of the resolution process. As regards elaboration of services: I am still working on RFC2483bis, but completing the first draft take at least a few weeks. Alfred Hoenes wrote: > internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Uniform Resource >> Names, Revised Working Group of the IETF. >> >> Title : Uniform Resource Name (URN) Namespace Definition Mechanisms >> Author(s) : Alfred Hoenes >> Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt >> Pages : 29 >> Date : 2011-10-31 >> >> Uniform Resource Names (URNs) are intended to serve as persistent, >> location-independent, resource identifiers. To structure and >> organize their usage, the URN syntax specifies a hierarchy that >> divides the set of possible URNs into "URN Namespaces" that can be >> individually defined and managed. URN Namespaces in particular serve >> to map existing identifier systems into the URN system and thereby >> make available generic, network-based resolution services for the >> identified documents, artifacts, and other objects (and their >> metadata). >> >> To actually leverage such synergetic advantage, URN Namespaces need >> to be specified in a comparable manner, and their Namespace >> Identifiers (NIDs) need to be registered with IANA, so that naming >> conflicts are avoided and implementers of services can follow a >> structured approach in support of various namespaces, guided by the >> registry to the related documents and the particularities of specific >> namespaces, as described in these namespace registration documents. >> >> This document serves as a guideline for authors of URN Namespace >> definition and registration documents. It describes the essential >> content of such documents and how they shall be structured to allow >> readers familar with the scheme to quickly assess the properties of a >> specific URN Namespace. Further, this RFC describes the process to >> be followed to get a URN Namespace registered with IANA. >> >> This document is a companion document to the revised URN Syntax >> specification, RFC 2141bis; it supersedes and replaces RFC 3406. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt > > > [[ speaking as the draft author/editor ]] > > This is mainly an editorial update, based on received review > comments and a bit of on-list discussion. > > Please see the newly amended Appendix D in the draft for the > open issues that need on-list discussion, state your opinions, > and provide replacement text snippets where deemed appropriate. > > The delta information summary for this version inadvertently has > been dropped during XML debugging; it will be restituted in the > next draft version. > > Best regards, > Alfred. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678