From stpeter@stpeter.im Fri Dec 16 13:06:02 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 286C81F0C78 for ; Fri, 16 Dec 2011 13:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.561 X-Spam-Level: X-Spam-Status: No, score=-101.561 tagged_above=-999 required=5 tests=[AWL=-1.862, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MANGLED_STOP=2.3, USER_IN_WHITELIST=-100] 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 8gftxaEYoFHS for ; Fri, 16 Dec 2011 13:06:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCF81F0C76 for ; Fri, 16 Dec 2011 13:06:01 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77FA6423AD; Fri, 16 Dec 2011 14:13:44 -0700 (MST) Message-ID: <4EEBB2B6.5090801@stpeter.im> Date: Fri, 16 Dec 2011 14:05:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> In-Reply-To: <4EC25AC6.9060404@helsinki.fi> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 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: Fri, 16 Dec 2011 21:06:02 -0000 My apologies for the delayed reply. I'm still catching up after IETF 82. On 11/15/11 5:27 AM, Juha Hakala wrote: > 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. Really? As far as I can see, this idea is not present in RFC 2141. Has something changed since then that would compel us to say that URNs must be actionable in the way you describe? > 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). Juha, that is all quite interesting. Can you propose text changes that would incorporate those insights? > 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. Could you clarify whether your statement refers to that particular example or to resolution services as such? > 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.) Isn't that a matter for RFC 2483 (or 2483bis), not the core URN spec? There is no necessary connection between URNs and resolution, I think. > 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. Please clarify. Do you mean the syntax of fragment identifiers, or the semantics? I think the semantics differ based on the media type of the resource that might be retrieved, as we've discussed. See Section 3.5 of RFC 3986: The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. > 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. How is this matter *not* addressed by Appendix C of RFC 3986? > 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. Do you mean that all of the examples should include those components, or that some examples should be added? > 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. That sounds like a good idea. Do you have a plan for releasing the next version of the specification? Thanks! Peter > > 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 >> From stpeter@stpeter.im Fri Dec 16 13:36: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 09F451F0C53 for ; Fri, 16 Dec 2011 13:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] 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 26dYAHMCxYso for ; Fri, 16 Dec 2011 13:36:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D3C211F0C38 for ; Fri, 16 Dec 2011 13:36:27 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C4FB423AD; Fri, 16 Dec 2011 14:44:10 -0700 (MST) Message-ID: <4EEBB9D9.3060505@stpeter.im> Date: Fri, 16 Dec 2011 14:36:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> In-Reply-To: <4EC4DF6D.7070209@helsinki.fi> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 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: Fri, 16 Dec 2011 21:36:29 -0000 On 11/17/11 3:18 AM, Juha Hakala wrote: > 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). See the message I just sent about 2141bis. I think this claim is not exactly uncontroversial. > 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. Proposed text is always good, so thanks for sending it. I don't know if we need to explicitly make a distinction here between data records/resources and metadata records/resources. Isn't that a matter for particular namespace definitions? > 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. I think that makes sense. > 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, Why? I would not describe the registration process as overly loose. Quite a bit of attention is paid to registration requests on the urn-nid list. > 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. Do you have evidence that any existing namespaces are being used in such an uncontrolled manner? > 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). The UUID namespace is different from the rest. See the thread we had on this list back in September, starting here: http://www.ietf.org/mail-archive/web/urn/current/msg01612.html You wouldn't use the UUID namespace if you had another namespace to use. If publishers are using that namespace instead of the ISBN namespace, then that is their fault. > 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. Are you proposing that we change "some" to "careful"? That seems fine to me, since careful consideration is already given. > As regards the three bullet points in page 7, I suggest the following > changes: Those changes are hard to track. Please in the future provide such changes via the following convention: OLD lorem ipsum foo bar baz qux NEW some new text here So: OLD > - 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; NEW > - 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); That doesn't seem like an improvement to me. You've removed the notion of organizational stability and added competency. How do you judge competency? What if the organization hasn't issued URNs before? And are we really worried about incompetent namespace administrators? Furthermore, persistence considerations are already contained elsewhere in the document. I realize that your text is in fact closer to RFC 3406 (rather than 3406bis), so perhaps the WG might have consensus to keep what's in the current RFC. But please note that those bullet points are included as the types of things that people might consider. OLD > - 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. NEW > - 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. Why "user organizations"? And again resolution is creeping in here. That isn't a necessary aspect of URNs and shouldn't be a core consideration in the assignment of namespaces. > 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). 2 weeks has proven to be sufficient, in my experience on the urn-nid list. > 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. I agree that registrants are often confused about what needs to go in the community considerations section. > 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). That's a good list of considerations. I might add a few more once I have time to think about my experience with namespace registrations. > Something may also be said about the costs of > maintaining the system. Why? > 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. Do you think those restrictions need to be formalized? IMHO coming up with a complete list of reserved strings is fruitless -- better to leave this up to the judgment of the reviwers / document sponsor (typically an AD). > 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. I think validation applies to a URN, not the NSS. > 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. That seems sensible. > As regards elaboration of services: I am still working on RFC2483bis, > but completing the first draft take at least a few weeks. Have you had a chance to work on that yet? Peter > > 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 >> From stpeter@stpeter.im Fri Dec 16 13:56:24 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 2D67511E80AB for ; Fri, 16 Dec 2011 13:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-3.763, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] 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 ftL1Hw02M4mt for ; Fri, 16 Dec 2011 13:56:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4E11E80A2 for ; Fri, 16 Dec 2011 13:56:20 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1DDCC423AD; Fri, 16 Dec 2011 15:04:04 -0700 (MST) Message-ID: <4EEBBE82.3090004@stpeter.im> Date: Fri, 16 Dec 2011 14:56:18 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juha Hakala References: <4E96C9EA.8070605@helsinki.fi> In-Reply-To: <4E96C9EA.8070605@helsinki.fi> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Fri, 16 Dec 2011 21:56:24 -0000 On 10/13/11 5:22 AM, Juha Hakala wrote: > Hello, > > I have written updated versions of > > * draft-ietf-urnbis-rfc3187bis-isbn-urn > * draft-ietf-urnbis-rfc3188bis-nbn-urn > > Some editorial help will be needed to publish them as Internet drafts; > what I have now is two XML texts that need to be polished/converted to > I-Ds. But I can send them either to the list (if that is OK) or anybody > who is interested to review them. Are those the versions that were published here? http://tools.ietf.org/html/draft-ietf-urnbis-rfc3187bis-isbn-urn-01 http://tools.ietf.org/html/draft-ietf-urnbis-rfc3188bis-nbn-urn-01 > Since these texts rely on unpublished new version of rfc2141bis that > myself and Alfred Hoenes have been working on, I'd rather wait until the > next version of rfc2141bis has been made available before publishing > them as I-Ds. But the WG is, like Peter pointed out in his message a > week ago, behind schedule. And as the fact that we have been working on > new versions of the I-Ds has not been made clear in the messages sent to > the list, it is easy to get an impression that nothing much is happening > in this particular WG. So if need be I am prepared to make some > shortcuts here. > > Some comments concerning these namespace registrations and namespace > registration process in general. > > I have taken into account the discussions on the list, especially as > regards . For ISBN this was trivial, since ISBN standard does > not allow usage. For NBN this was more complicated; there are > three different ways in which fragments can be dealt with within that > namespace. > > And this serves as an introduction to the first generic point, which is > that the difficulty of writing a (decent) namespace registration has an > inverse relation to the level of establishment the namespace has. I think you are basing your conclusions on ISBN and NBN only. I think it's fairly easy to write a decent namespace registration, but most of them are used for the issuance of URNs for things like XML namespaces, not for the kind of resources you care about. Furthermore, none of the NID registrations I have shepherded as Area Director involve resolution, which introduces further complexities. > ISBN > is based on an international standard and it has been in production > almost 40 years. It is easy to write a namespace registration to it, > provided that the standard is not heavily modified and assignment > practices do not change. No such changes are imminent in the case of ISBN. > > It is more difficult to supply an accurate NBN namespace registration. > We have fairly good idea of who uses URN:NBN and for what purposes, but > still the scope is not self evident. Unlike the previous versions, the > I-D I completed today explicitly allows NBN assignment to works (things > that only exist in Plato's world of ideas, such as "Hamlet"). These > URN:NBNs will be resolved to work level metadata, which should include > links to manifestations of the work. ISBNs can not be assigned to works; > there is another identifier (ISTC) for that purpose. > > If you dislike the extension of the URN coverage to works, please > discuss this topic on the list. For me, works may play a central role in > the URN resolution since they are persistent (they are abstract entities > that never change) whereas manifestations of digital resources are > technology dependent and will not live long. But work level metadata is > the bedrock to which we will be able to link all manifestations (and > related works such as translations) related to a single work. I think that makes sense in the context of NBNs and other such URNs. > I can't recall if the scope of the URN system as a whole has ever been > formally specified. This issue is a bit complicated since the scope of > the URN is the sum of all scopes of the identifiers that have a URN > namespace. It only takes one very large namespace such as UUID to cover > almost everything. But it might still be useful to discuss this topic, > in order to see if there is a consensus among the list subscribers. I'd welcome that discussion. > Going back to NBN after this diversion, lots of things that are dictated > by the base standard in the ISBN namespace, had to be written into the > NBN namespace registration in order to make sure the users have an > accurate enough idea of how to utilize URN:NBNs. > > There are also namespaces where there seems to be very little control, > that is, basically anyone can use them to identify anything at any time. > At least for a librarian like myself identifier assignment should not be > organised like this. UUID has been mentioned before as an example of > namespace which may require (local) control mechanisms beyond the > namespace registration to function well. These URNs may fulfill the > basic syntactic requirement of being globally unique, but beyond that > these namespaces cannot guarantee much, although there may be islands of > reliable resolution within them. I think that UUIDs are very much the outlier here. None of the other namespaces are uncontrolled in the way that UUIDs are. > As far as I am concerned, when a namespace registration is based on an > international identifier standard such as ISBN, the RFC can / should be > put on standard track. I am less certain what to do with NBN-like > semi-established namespace registrations. At least IETF should take a > good look at the communities behind them. All of the NID registrations that I have shepherded were informational. > I am not sure (without checking e.g. how URN:UUIDs work in practice) if > UUID-like namespaces are really useful. I doubt if the identified > resources themselves, or anything meaningful their URNs might resolve > to, will be in existence for long (from the national library point of > view, meaning several decades or even centuries). In the worst case > there may eventually be many low-quality namespaces where most URNs will > not live much longer than URLs or cool URIs. Such namespaces might > eventually undermine the value of the URN system as a whole. Please again refer to the discussion we had in September about UUIDs. It's a hasty generalization to talk about UUID-like namespaces, because we have only one. > I suppose that all this boils down to the question of control. Up to now > IETF has operated on the basis of trust; as namespace registrations are > informal RFCs they have not been (I suppose) scrutinized. What evidence do you have for saying that? > Whether the > level of control needs to be heightened is hard to say without making > some kind of empirical check. What exactly are you worried about? Perhaps if you could describe the concerns you have with non-UUID namespaces, that would help us understand what you are trying to accomplish by tightening control over the issuance of NIDs. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Sat Dec 17 02:08:01 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 B4DD321F8B3E for ; Sat, 17 Dec 2011 02:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YD6HqpvOePQG for ; Sat, 17 Dec 2011 02:07:57 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7D21F86C3 for ; Sat, 17 Dec 2011 02:07:57 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBHA7j6v012499 for ; Sat, 17 Dec 2011 02:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1324116471; bh=WZm9fAsCEZzARe3+49Vkk3ZESCrgWbXybgeuTbK0mQ4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Lwo5FAqGCZgGwxgmQT5JJSx+bhVFXGn5NX5Qzk19rD5K+1aFiFo18SfmugsdddFo/ 4egdg7IDCd9pzXp47RNMtRiJnKIw6UsEnU0TrzmeMNK4W0tNC7RIBkXBTsUp3v/F9k UjS7FChh3tLXkADH0e5kE0ldpmX8wGWy/qNbUBts= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1324116471; bh=WZm9fAsCEZzARe3+49Vkk3ZESCrgWbXybgeuTbK0mQ4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0W46CE5PnzTQhLXua3w5f17dosgZVSTIxjvhYDxTJMJdONhaTS4s7HrLw/8UotRYw ivMdQ/J8V3xSvBCfZNRxFvf40VDiGeXufDFP1t6bkT6C1dOFILCyZNL6oRUfSpNOX2 LMMcJI8RdXeLlny9fm8uWQVrxktm0d6u9TL/6N+c= Message-Id: <6.2.5.6.2.20111217013713.09040ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 Dec 2011 02:07:31 -0800 To: urn@ietf.org From: SM In-Reply-To: <4EEBBE82.3090004@stpeter.im> References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Sat, 17 Dec 2011 10:08:01 -0000 At 13:56 16-12-2011, Peter Saint-Andre wrote: >I'd welcome that discussion. Seven messages were posted to this mailing list since November 1. Two of the messages were about a workshop. Three of them were from Peter Saint-Andre as an individual. According to the working group charter, the milestone for rfc3187bis-isbn-urn and rfc3188bis-nbn-urn was February 2011. On October 3, the Responsible AD commented on the working group progress [1]. This working group was formed on November 23, 2011. It has not been able to produce an RFC in over a year. Is it premature to ask for a consensus call on closing this working group? :-) Regards, -sm P.S. I understand the work is important. However, if there isn't any discussion about the drafts, it denotes a lack of interest in getting the drafts published as RFCs. 1. http://www.ietf.org/mail-archive/web/urn/current/msg01626.html From stpeter@stpeter.im Tue Dec 20 09:55:39 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 F2B3E21F8AB9 for ; Tue, 20 Dec 2011 09:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Zl3IqdTvoi5U for ; Tue, 20 Dec 2011 09:55:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5961321F8A7D for ; Tue, 20 Dec 2011 09:55:38 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B6A24234D; Tue, 20 Dec 2011 11:03:33 -0700 (MST) Message-ID: <4EF0CC0F.6010207@stpeter.im> Date: Tue, 20 Dec 2011 10:55:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SM References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> <6.2.5.6.2.20111217013713.09040ae0@resistor.net> In-Reply-To: <6.2.5.6.2.20111217013713.09040ae0@resistor.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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, 20 Dec 2011 17:55:39 -0000 On 12/17/11 3:07 AM, SM wrote: > At 13:56 16-12-2011, Peter Saint-Andre wrote: >> I'd welcome that discussion. > > Seven messages were posted to this mailing list since November 1. Two > of the messages were about a workshop. Three of them were from Peter > Saint-Andre as an individual. SM, although I too am concerned about the lack of involvement, the choice of November 1 as the cutoff date for your measurements is a bit misleading, because there was a flurry of activity (at least from Juha and Alfred) in October. However, the lack of activity since then is not encouraging. Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Wed Dec 21 04:02:53 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 E392521F8A56 for ; Wed, 21 Dec 2011 04:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 9vyQNArSmR6t for ; Wed, 21 Dec 2011 04:02:52 -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 1545121F8A57 for ; Wed, 21 Dec 2011 04:02:46 -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 pBLC2gF0006543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Dec 2011 14:02:43 +0200 Message-ID: <4EF1CAE2.7000900@helsinki.fi> Date: Wed, 21 Dec 2011 14:02:42 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> In-Reply-To: <4EEBBE82.3090004@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Wed, 21 Dec 2011 12:02:54 -0000 Hello Peter; all, Please see some responses to your questions below. (Sorry, this message is quite long.) Peter Saint-Andre wrote: > > > On 10/13/11 5:22 AM, Juha Hakala wrote: >> Hello, >> >> I have written updated versions of >> >> * draft-ietf-urnbis-rfc3187bis-isbn-urn >> * draft-ietf-urnbis-rfc3188bis-nbn-urn >> >> Some editorial help will be needed to publish them as Internet drafts; >> what I have now is two XML texts that need to be polished/converted to >> I-Ds. But I can send them either to the list (if that is OK) or anybody >> who is interested to review them. > > Are those the versions that were published here? > > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3187bis-isbn-urn-01 > > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3188bis-nbn-urn-01 Yes. While preparing these I-Ds (and 2141bis & 3406bis) for publication, Alfred did specify some issues which should be resolved. I have provided my own views, but there hasn't been other comments. It might have been helpful to split that discussion into separate topics. At least there would then have been more traffic on the list ;-). >> And this serves as an introduction to the first generic point, which is >> that the difficulty of writing a (decent) namespace registration has an >> inverse relation to the level of establishment the namespace has. > > I think you are basing your conclusions on ISBN and NBN only. I think > it's fairly easy to write a decent namespace registration, but most of > them are used for the issuance of URNs for things like XML namespaces, > not for the kind of resources you care about. Furthermore, none of the > NID registrations I have shepherded as Area Director involve resolution, > which introduces further complexities. With "decent" (thorough or complete might have been a more accurate term) I mean a registration which specifies the scope and syntax of the identifier (namespace specific string), provides an overview of identifier assignment process, describes the URNs resolution process and explains why these URNs are persistent. In a well established namespace (such as e.g. ISBN) many of these things are settled in the identifier standard & well established identifier assignment process. It is possible to write a complete and concise description, which is easy to evaluate. Any identifier standard which gives the organizations a lot of room for improvisation would require a lot of additional rules in the namespace registration, if the aim were to bring all the namespaces to approximately same level. Most likely this is unrealistic, given that there are already e.g. namespace registrations which do not specify resolution processes. >> I can't recall if the scope of the URN system as a whole has ever been >> formally specified. This issue is a bit complicated since the scope of >> the URN is the sum of all scopes of the identifiers that have a URN >> namespace. It only takes one very large namespace such as UUID to cover >> almost everything. But it might still be useful to discuss this topic, >> in order to see if there is a consensus among the list subscribers. > > I'd welcome that discussion. Fine. I'll write more about this later. My gut feeling is that in order to reduce uncertainties as regards the scope of the URN system as a whole and the nature of individual namespaces, the WG might produce a BCP which tries to provide the big picture. Another thing that should be discussed is the relation of URN to other persistent identifiers, both politically and technically (for instance: is IETF going to endorse other persistent identifiers such as XXX; is it possible to express XXXs as URNs). Choosing a persistent identifier systems is a long term commitment, and I am not sure if the implications are yet fully understood. The implementers do expect that IETF will continue to endorse and develop URN system in the foreseeable future. The first step on this road is the current revision process. I do admit that the list has not been active, but there are at least two reasons for this: first, the work under way (according to the charter) is non-controversial from the point of view of the users, and second, the group of URN implementers is relatively small, and not all of them participate in the process. Most implementers of URN and other persistent identifiers are organisations which preserve digital resources for long term (decades, centuries), and given that the average life time of a web page is about 50-100 days (see http://blogs.loc.gov/digitalpreservation/2011/11/the-average-lifespan-of-a-webpage/) only a fraction of the Internet users are in a position where cool URIs are not cool at all. >> There are also namespaces where there seems to be very little control, >> that is, basically anyone can use them to identify anything at any time. >> At least for a librarian like myself identifier assignment should not be >> organised like this. UUID has been mentioned before as an example of >> namespace which may require (local) control mechanisms beyond the >> namespace registration to function well. These URNs may fulfill the >> basic syntactic requirement of being globally unique, but beyond that >> these namespaces cannot guarantee much, although there may be islands of >> reliable resolution within them. > > I think that UUIDs are very much the outlier here. None of the other > namespaces are uncontrolled in the way that UUIDs are. OK. I have not analyzed all the existing 40+ namespace registrations, but I did read the one for UUID and did have some concerns about it. It is good to know that other namespaces are more restrained. > >> As far as I am concerned, when a namespace registration is based on an >> international identifier standard such as ISBN, the RFC can / should be >> put on standard track. I am less certain what to do with NBN-like >> semi-established namespace registrations. At least IETF should take a >> good look at the communities behind them. > > All of the NID registrations that I have shepherded were informational. Seems to me that the current practice can continue unchanged, except that namespace registrations for proper standards could be elevated to the standard track if the community wants that. Whether IETF should then introduce some additional requirements as regards the quality of the namespace registration is a different matter. >> I suppose that all this boils down to the question of control. Up to now >> IETF has operated on the basis of trust; as namespace registrations are >> informal RFCs they have not been (I suppose) scrutinized. > > What evidence do you have for saying that? If strict quality criteria were applied, then organisations assigning URNs should be able to prove that they are able to preserve the identified resources for long term, and to maintain the resolution services as well. I suppose it is not realistic to require that IETF makes any assessments on the applicants of informal namespaces. At least some kind of checks could be added to when the namespace registration goes on standard track. Since persistence of a resource (and resolution service) is primarily an organizational issue, IETF should not ignore this issue. It should be noted that the main difference between Handles and DOIs (the main competitors URN has in the PID "market") is organizational: every DOI is also a Handle, but there is a level of control with DOIs which is absent from most Handles. > >> Whether the >> level of control needs to be heightened is hard to say without making >> some kind of empirical check. > > What exactly are you worried about? Perhaps if you could describe the > concerns you have with non-UUID namespaces, that would help us > understand what you are trying to accomplish by tightening control over > the issuance of NIDs. I am concerned that if IETF does not pay more attention to organizational issues related to the identifier assignment (and e.g. enable a two-tiered system in some ways similar to DOI / Handle based on ranking of namespaces) then over time URNs will not be as reliable as they should be. More trustworthy than URLs for sure, but URNs will not remain actionable for decades and centuries if anybody out there can get a permission to assign them and establish resolution services. All the best, Juha > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > -- 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 andy@hxr.us Wed Dec 21 06:30:11 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 E757A21F88A0 for ; Wed, 21 Dec 2011 06:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 eDb0Dr8vc9C3 for ; Wed, 21 Dec 2011 06:30:10 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C021F8551 for ; Wed, 21 Dec 2011 06:30:10 -0800 (PST) Received: by qcsf15 with SMTP id f15so5448895qcs.31 for ; Wed, 21 Dec 2011 06:30:10 -0800 (PST) Received: by 10.229.78.165 with SMTP id l37mr2674684qck.126.1324477810073; Wed, 21 Dec 2011 06:30:10 -0800 (PST) Received: from zx80.arin.net (core.arin.net. [192.149.252.11]) by mx.google.com with ESMTPS id q14sm10986982qap.4.2011.12.21.06.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 06:30:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: <4EF1CAE2.7000900@helsinki.fi> Date: Wed, 21 Dec 2011 09:28:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> <4EF1CAE2.7000900@helsinki.fi> To: Juha Hakala X-Mailer: Apple Mail (2.1084) Cc: "urn@ietf.org" Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Wed, 21 Dec 2011 14:30:12 -0000 Juha (and the WG), One of the problems I see with these discussions is that these threads = intertwine noted issues with the documents and larger architectural or = philosophical issues. That can get confusing. I would like to ask you, as a document editor, and the working group if = we should use the issue tracker for dealing with document issues so that = they do not get lost in the larger debates. Comments? As for the larger issues, we can discuss them and after there is = consensus on how to move forward with addressing those issues will be = able to knock them out through documents. What say you? -andy On Dec 21, 2011, at 7:02 AM, Juha Hakala wrote: > Hello Peter; all, >=20 > Please see some responses to your questions below. (Sorry, this = message is quite long.) >=20 > Peter Saint-Andre wrote: >> >> On 10/13/11 5:22 AM, Juha Hakala wrote: >>> Hello, >>>=20 >>> I have written updated versions of >>>=20 >>> * draft-ietf-urnbis-rfc3187bis-isbn-urn >>> * draft-ietf-urnbis-rfc3188bis-nbn-urn >>>=20 >>> Some editorial help will be needed to publish them as Internet = drafts; >>> what I have now is two XML texts that need to be polished/converted = to >>> I-Ds. But I can send them either to the list (if that is OK) or = anybody >>> who is interested to review them. >> Are those the versions that were published here? >> http://tools.ietf.org/html/draft-ietf-urnbis-rfc3187bis-isbn-urn-01 >> http://tools.ietf.org/html/draft-ietf-urnbis-rfc3188bis-nbn-urn-01 >=20 > Yes. >=20 > While preparing these I-Ds (and 2141bis & 3406bis) for publication, = Alfred did specify some issues which should be resolved. I have provided = my own views, but there hasn't been other comments. It might have been = helpful to split that discussion into separate topics. At least there = would then have been more traffic on the list ;-). >=20 >>> And this serves as an introduction to the first generic point, which = is >>> that the difficulty of writing a (decent) namespace registration has = an >>> inverse relation to the level of establishment the namespace has.=20 >> I think you are basing your conclusions on ISBN and NBN only. I think >> it's fairly easy to write a decent namespace registration, but most = of >> them are used for the issuance of URNs for things like XML = namespaces, >> not for the kind of resources you care about. Furthermore, none of = the >> NID registrations I have shepherded as Area Director involve = resolution, >> which introduces further complexities. >=20 > With "decent" (thorough or complete might have been a more accurate = term) I mean a registration which specifies the scope and syntax of the = identifier (namespace specific string), provides an overview of = identifier assignment process, describes the URNs resolution process and = explains why these URNs are persistent. >=20 > In a well established namespace (such as e.g. ISBN) many of these = things are settled in the identifier standard & well established = identifier assignment process. It is possible to write a complete and = concise description, which is easy to evaluate. Any identifier standard = which gives the organizations a lot of room for improvisation would = require a lot of additional rules in the namespace registration, if the = aim were to bring all the namespaces to approximately same level. Most = likely this is unrealistic, given that there are already e.g. namespace = registrations which do not specify resolution processes. >=20 >>> I can't recall if the scope of the URN system as a whole has ever = been >>> formally specified. This issue is a bit complicated since the scope = of >>> the URN is the sum of all scopes of the identifiers that have a URN >>> namespace. It only takes one very large namespace such as UUID to = cover >>> almost everything. But it might still be useful to discuss this = topic, >>> in order to see if there is a consensus among the list subscribers. >> I'd welcome that discussion. >=20 > Fine. I'll write more about this later. >=20 > My gut feeling is that in order to reduce uncertainties as regards the = scope of the URN system as a whole and the nature of individual = namespaces, the WG might produce a BCP which tries to provide the big = picture. Another thing that should be discussed is the relation of URN = to other persistent identifiers, both politically and technically (for = instance: is IETF going to endorse other persistent identifiers such as = XXX; is it possible to express XXXs as URNs). Choosing a persistent = identifier systems is a long term commitment, and I am not sure if the = implications are yet fully understood. >=20 > The implementers do expect that IETF will continue to endorse and = develop URN system in the foreseeable future. The first step on this = road is the current revision process. I do admit that the list has not = been active, but there are at least two reasons for this: first, the = work under way (according to the charter) is non-controversial from the = point of view of the users, and second, the group of URN implementers is = relatively small, and not all of them participate in the process. Most = implementers of URN and other persistent identifiers are organisations = which preserve digital resources for long term (decades, centuries), and = given that the average life time of a web page is about 50-100 days (see = http://blogs.loc.gov/digitalpreservation/2011/11/the-average-lifespan-of-a= -webpage/) only a fraction of the Internet users are in a position where = cool URIs are not cool at all. >=20 >>> There are also namespaces where there seems to be very little = control, >>> that is, basically anyone can use them to identify anything at any = time. >>> At least for a librarian like myself identifier assignment should = not be >>> organised like this. UUID has been mentioned before as an example of >>> namespace which may require (local) control mechanisms beyond the >>> namespace registration to function well. These URNs may fulfill the >>> basic syntactic requirement of being globally unique, but beyond = that >>> these namespaces cannot guarantee much, although there may be = islands of >>> reliable resolution within them. >> I think that UUIDs are very much the outlier here. None of the other >> namespaces are uncontrolled in the way that UUIDs are. >=20 > OK. I have not analyzed all the existing 40+ namespace registrations, = but I did read the one for UUID and did have some concerns about it. It = is good to know that other namespaces are more restrained. >>> As far as I am concerned, when a namespace registration is based on = an >>> international identifier standard such as ISBN, the RFC can / should = be >>> put on standard track. I am less certain what to do with NBN-like >>> semi-established namespace registrations. At least IETF should take = a >>> good look at the communities behind them. >> All of the NID registrations that I have shepherded were = informational. >=20 > Seems to me that the current practice can continue unchanged, except = that namespace registrations for proper standards could be elevated to = the standard track if the community wants that. Whether IETF should then = introduce some additional requirements as regards the quality of the = namespace registration is a different matter. >=20 >>> I suppose that all this boils down to the question of control. Up to = now >>> IETF has operated on the basis of trust; as namespace registrations = are >>> informal RFCs they have not been (I suppose) scrutinized.=20 >> What evidence do you have for saying that? >=20 > If strict quality criteria were applied, then organisations assigning = URNs should be able to prove that they are able to preserve the = identified resources for long term, and to maintain the resolution = services as well. I suppose it is not realistic to require that IETF = makes any assessments on the applicants of informal namespaces. At least = some kind of checks could be added to when the namespace registration = goes on standard track. Since persistence of a resource (and resolution = service) is primarily an organizational issue, IETF should not ignore = this issue. >=20 > It should be noted that the main difference between Handles and DOIs = (the main competitors URN has in the PID "market") is organizational: = every DOI is also a Handle, but there is a level of control with DOIs = which is absent from most Handles. >>> Whether the >>> level of control needs to be heightened is hard to say without = making >>> some kind of empirical check. >> What exactly are you worried about? Perhaps if you could describe the >> concerns you have with non-UUID namespaces, that would help us >> understand what you are trying to accomplish by tightening control = over >> the issuance of NIDs. >=20 > I am concerned that if IETF does not pay more attention to = organizational issues related to the identifier assignment (and e.g. = enable a two-tiered system in some ways similar to DOI / Handle based on = ranking of namespaces) then over time URNs will not be as reliable as = they should be. More trustworthy than URLs for sure, but URNs will not = remain actionable for decades and centuries if anybody out there can get = a permission to assign them and establish resolution services. >=20 > All the best, >=20 > Juha >> Peter >> -- >> Peter Saint-Andre >> https://stpeter.im/ >=20 > --=20 >=20 > Juha Hakala > Senior advisor, standardisation and IT >=20 > 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 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From stpeter@stpeter.im Wed Dec 21 08:53:11 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 E3C941F0C4C for ; Wed, 21 Dec 2011 08:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uO5NSF-nXYQ7 for ; Wed, 21 Dec 2011 08:53:09 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD7D1F0C3B for ; Wed, 21 Dec 2011 08:53:09 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C409A4248C; Wed, 21 Dec 2011 10:01:06 -0700 (MST) Message-ID: <4EF20EF3.8060605@stpeter.im> Date: Wed, 21 Dec 2011 09:53:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andy Newton References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> <4EF1CAE2.7000900@helsinki.fi> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Wed, 21 Dec 2011 16:53:11 -0000 On 12/21/11 7:28 AM, Andy Newton wrote: > Juha (and the WG), > > One of the problems I see with these discussions is that these > threads intertwine noted issues with the documents and larger > architectural or philosophical issues. That can get confusing. > > I would like to ask you, as a document editor, and the working group > if we should use the issue tracker for dealing with document issues > so that they do not get lost in the larger debates. Comments? > > As for the larger issues, we can discuss them and after there is > consensus on how to move forward with addressing those issues will be > able to knock them out through documents. > > What say you? > > -andy Andy, I think that would indeed be helpful. Although the more "philosophical" issues are interesting and important, we also need to focus the discussion down to specific text proposals to be incorporated into the specificuations under consideration. Using the issue tracker might help move us in that direction. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Wed Dec 21 10:08:53 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 181B421F8B06 for ; Wed, 21 Dec 2011 10:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hB0kZeelh6jH for ; Wed, 21 Dec 2011 10:08:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D611521F8B03 for ; Wed, 21 Dec 2011 10:08:50 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id pBLI8gS6005122; Wed, 21 Dec 2011 10:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1324490929; bh=IPyyEmVMQYVUqVtNAlOzlgLYqH2iMBqeKLmNfxcWzdc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=uoxifJXHzElmB7s7FbcJpYfmCz1BJEtmYYvxZUQqKJh0x3zmdAtgV0LjByW1mpvim qkOP8hVetzo4/4Q2+CE7rBwqdnkaGcoDL4oXXt05ZBIssBdSI5v7O2sSQTdEUVREd4 pCnj7mFWpe0FN0n3ULhFWs7f+LWmoffgLQ1/ZSFU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1324490929; bh=IPyyEmVMQYVUqVtNAlOzlgLYqH2iMBqeKLmNfxcWzdc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=i/A5avlQl3PuMoOEgPlGq+J+N3Dl+FZWtaYD+XmDY49wkVdS1FJHhUt1GH+1zTLYW ZWF1yEqolinMBHZ9FAF/P2nYsTXE3p7KAGzAD/IsRGdbNKMOysUif26XYOK0wU3Tj8 YXrNCO1odTFXGSBKm+3s03EY48tS5mqgf6qc4Gk0= Message-Id: <6.2.5.6.2.20111221095836.062bdfe0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Dec 2011 10:08:37 -0800 To: Peter Saint-Andre From: SM In-Reply-To: <4EF0CC0F.6010207@stpeter.im> References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> <6.2.5.6.2.20111217013713.09040ae0@resistor.net> <4EF0CC0F.6010207@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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: Wed, 21 Dec 2011 18:08:53 -0000 Hi Peter, At 09:55 20-12-2011, Peter Saint-Andre wrote: >SM, although I too am concerned about the lack of involvement, the >choice of November 1 as the cutoff date for your measurements is a bit >misleading, because there was a flurry of activity (at least from Juha I agree that the choice of the cutoff date for the measurement is misleading. It helps to have somebody else (e.g. as you did in this case) discuss about the comments and drafts to catch mistakes. Regards, -sm From juha.hakala@helsinki.fi Thu Dec 22 02:36:42 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 CBB4F21F8B58 for ; Thu, 22 Dec 2011 02:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_20=-0.74, 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 07r7sB4R5--s for ; Thu, 22 Dec 2011 02:36:41 -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 055DA21F8B4A for ; Thu, 22 Dec 2011 02:36:39 -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 pBMAHJsU029273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2011 12:17:20 +0200 Message-ID: <4EF303AF.3030807@helsinki.fi> Date: Thu, 22 Dec 2011 12:17:19 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> In-Reply-To: <4EEBB2B6.5090801@stpeter.im> 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: Thu, 22 Dec 2011 10:36:42 -0000 Hello all, Plenty of comments below (sorry). Peter Saint-Andre wrote: >> 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. > > Really? As far as I can see, this idea is not present in RFC 2141. Has > something changed since then that would compel us to say that URNs must > be actionable in the way you describe? I don't think that anything has changed (or it wasn't my intention). From my point of view, if a resource has a network accessible instance (or manifestation, as we librarians call them) and/or metadata related to these instances, then URLs will provide temporary access, and URNs something more: persistent access to the resource or surrogates such as descriptive metadata. I used the term actionable to refer to anything that the URN resolution can deliver. > >> 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). > > Juha, that is all quite interesting. Can you propose text changes that > would incorporate those insights? Yes. We might add something like this into 2141bis or elsewhere: Resources identified with URNs may be abstract (e.g. works such as Shakespeare's Hamlet) or embodied in some physical form (PDF/A version of the Finnish translation of Hamlet). An abstract entity may have 0-n digital manifestations in the Internet (and other kind of manifestations in the physical world). Since any digital manifestation will be rendered unusable in a few decades because file formats get outdated, all digital manifestations of a work should be linked to one another using their URNs. This will help the user to find a usable version, even if the identified manifestation can no longer be interpreted by the software at hand. Resources may be simple (a single file or a fragment thereof) or complex (a set of inter-related files). For large sets surrogates may replace the delivery of the actual resources. Generally, services available shall depend both on the identified resources and the target systems. For works lacking physical representations in the Internet, descriptive metadata and location information can be provided. A long term preservation system can supply technical metadata about the file format of the identified manifestation of the work. A publisher's digital asset management system may be able to supply rights metadata about the identified resource, even if the resource itself is not accessible. (In the future, URN resolution services should enable the users to pinpoint the kind of metadata they need.) > >> 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. > > Could you clarify whether your statement refers to that particular > example or to resolution services as such? I refer to the example in 2141bis. But my comment also makes the point that we should revise the URN services in such a way that the user can specify the type of metadata desired (the point made above in parenthesis). > >> 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.) > > Isn't that a matter for RFC 2483 (or 2483bis), not the core URN spec? > There is no necessary connection between URNs and resolution, I think. There is no need to add the note if revision of RFC 2483 is added to the charter of the URNBIS WG ;-). My intention is to complete the first version of 2483bis in January and send it as a private contribution. URNs and resolution services are parts of the URN system. Without services URN assignment would not make sense. But technically the two are not interconnected since we can keep on adding new services without tweaking the URNs themselves. In the resolution process the service request must never be part of the URN itself (although we can use to piggyback service parameters). >> 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. > > Please clarify. Do you mean the syntax of fragment identifiers, or the > semantics? I think the semantics differ based on the media type of the > resource that might be retrieved, as we've discussed. If a file format (for instance, PDF) has well undertood rules as regards URI fragment usage, then these rules should apply in all namespaces where identifiers can be assigned to PDF fragments. In the namespace registration request all that is needed is to tell that fragment identification is allowed. > > See Section 3.5 of RFC 3986: > > The fragment's format and resolution is therefore > dependent on the media type [RFC2046] of a potentially retrieved > representation, even though such a retrieval is only performed if the > URI is dereferenced. As an aside, I don't know how far we can get with media types (2046) only. Fragment usage is dependent on file formats. Rules for text/plain are not the same as the rules for OOXML text documents. And the identified resources may encompass multiple media types; for instance, an e-book in EPUB 3.0 may contain the text of the book itself, sound recording of an interview of the author, an trailer of a film based on the book, and so on. It remains to be seen how such bundles will be identified (although my gut feeling is that each EPUB 3 book may consume a whole set of identfiers, one for its each constituent part). >> 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. > > How is this matter *not* addressed by Appendix C of RFC 3986? Appendix C is based on the idea that some kind of delimiting characters are used. I do admit that this will often be the case. But this does not need to happen. For instance, somebody may add a home made fragment into URN:ISBN. Such fragment should not be there, but no method described in Appendix C now would enable us to drop it. If there are well understood rules on how NSS should look like in a given namespace (examples of this include urn:issn or urn:isbn), then we can parse namespace specific strings in ways not foreseen in RFC 3986. Not only do we always know where the string ends, we can also check if the string is correct (if the identifier contains a check digit). >> 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. > > Do you mean that all of the examples should include those components, or > that some examples should be added? I mean that examples with query and fragment should be added. >> 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. > > That sounds like a good idea. Do you have a plan for releasing the next > version of the specification? No dates have been fixed yet. I should be able to send revised versions of 3187 and 3188 to Alfred Hönes quite soon (that being the first priority), but we have not discussed when he would be able to publish them and the next version of 2141bis. At this stage it would be highly useful to get feedback from other people on the list. I do recognize that we are just revising existing documents, and the revisions we have made should not be controversial, but actually confirming that the texts are fine would give us a more solid basis to move on - and show to the IETF that the work relevant. And it would be even better to receive criticism to help us in improving the documents. Best regards, Juha > > Thanks! > > Peter > >> 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 Dec 22 04:04:30 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 1AAE421F8B5A for ; Thu, 22 Dec 2011 04:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=2.440, BAYES_00=-2.599, 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 SOJ9s2IjYXPq for ; Thu, 22 Dec 2011 04:04:29 -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 ED2A821F8B59 for ; Thu, 22 Dec 2011 04:04:27 -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 pBMC4MxM014795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2011 14:04:22 +0200 Message-ID: <4EF31CC5.3060704@helsinki.fi> Date: Thu, 22 Dec 2011 14:04:21 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im> <4EF1CAE2.7000900@helsinki.fi> <4EF20EF3.8060605@stpeter.im> In-Reply-To: <4EF20EF3.8060605@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general 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, 22 Dec 2011 12:04:30 -0000 Hello, Issue tracker has been actively (and I think productively) used in the IRI group. So I am in favour of this suggestion, in principle. In practice isolating and formulating the issues can be complicated to those of us (including myself) who have no first hand experience of such working method. Perhaps IETF veterans could extract a few tangible issues from the discussions we've had on the list of late. Moreover, I would rather not formulate the issues myself since IETF folks may have more objective view on problems that still need to be solved. There are cases in which the document level (small) issues and architectural principles we have discussed are intertwined. For instance, if we agree that URNs can be applied to works, then we should also outline a model of how works and their manifestations are connected to one another, and derive some conclusions as regards what kind of impact this model may have to URN services. Of course we could also start the discussion from the top, agree on a model and then start deriving practical conclusions from there. But this approach would require more faith than the bottom - top -one. Juha Peter Saint-Andre wrote: > > > On 12/21/11 7:28 AM, Andy Newton wrote: >> Juha (and the WG), >> >> One of the problems I see with these discussions is that these >> threads intertwine noted issues with the documents and larger >> architectural or philosophical issues. That can get confusing. >> >> I would like to ask you, as a document editor, and the working group >> if we should use the issue tracker for dealing with document issues >> so that they do not get lost in the larger debates. Comments? >> >> As for the larger issues, we can discuss them and after there is >> consensus on how to move forward with addressing those issues will be >> able to knock them out through documents. >> >> What say you? >> >> -andy > > Andy, I think that would indeed be helpful. Although the more > "philosophical" issues are interesting and important, we also need to > focus the discussion down to specific text proposals to be incorporated > into the specificuations under consideration. Using the issue tracker > might help move us in that direction. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > -- 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 Dec 22 05:06:54 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 EF80D21F8B34 for ; Thu, 22 Dec 2011 05:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.973 X-Spam-Level: X-Spam-Status: No, score=-4.973 tagged_above=-999 required=5 tests=[AWL=1.627, BAYES_00=-2.599, 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 FZgGX+seqrgK for ; Thu, 22 Dec 2011 05:06:53 -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 2E74921F8B2F for ; Thu, 22 Dec 2011 05:06:52 -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 pBMD6ma3011238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2011 15:06:49 +0200 Message-ID: <4EF32B68.2070408@helsinki.fi> Date: Thu, 22 Dec 2011 15:06:48 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> In-Reply-To: <4EEBB9D9.3060505@stpeter.im> Content-Type: text/plain; charset=UTF-8; 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, 22 Dec 2011 13:06:55 -0000 Hello Peter, Again a few comments below. Peter Saint-Andre wrote: > >> 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, > > Why? The three most popular persistent identifier systems in existence at the moment are Handle, DOI and URN. Technically speaking, DOIs are Handles. The key difference between the two is the level of control; while Handle usage policy is liberal and nobody knows have many Handles have been assigned, DOI is centrally co-ordinated system where the level of control is high. And there is a good chance that DOIs will live longer than normal Handles. With URN, all namespaces are currently equal, and the reader has no simple means of estimating the relative trustworthiness of the URNs belonging to different namespaces. But there are ways in which we can introduce a simple mechanism with which to indicate that some namespaces may be more reliable. For instance, 3406bis might say that if a namespace does not specify the e.g. organisational background and if there is no description of the resolution mechanism (or if these descriptions are vague), then the registration request may be approved, but the RFC will be only informational. On the other hand, if all the essential data is provided, the registration could be elevated to standards track (perhaps iff the namespace is based on a proper standard). The registration request should then contain a question of whether the registrants want a standard status to the registration or not. URN system would still differ significantly from DOI/Handle, since instead of a sharp dichotomy, we would have all kinds of shades of grey. Some namespaces such as issn (which will use a single resolution service maintained by the ISSN international centre) will be very reliable, whereas some other standard track namespaces will be slightly less so. > I would not describe the registration process as overly loose. Quite a > bit of attention is paid to registration requests on the urn-nid list. I may have been misled by paying too much attention to UUID. I suppose the archive of the urn-nid is accessible so that the URNBIS folks can see what has been going on. >> 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. > > Do you have evidence that any existing namespaces are being used in such > an uncontrolled manner? No, and it would be difficult to obtain it. There can be at least three kinds of problems: dysfunctional URNs which are not capable of providing any services, lack of resolver infrastructure, and lack of URN assignment. It is not and it will not be easy to spot these, manually or otherwise. Having said this, it is not hard to find URNs from UUID namespace using Google. But trying to resolve urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 is impossible since I don't know the address of the resolution service. > The UUID namespace is different from the rest. See the thread we had on > this list back in September, starting here: > > http://www.ietf.org/mail-archive/web/urn/current/msg01612.html OK. > You wouldn't use the UUID namespace if you had another namespace to use. > If publishers are using that namespace instead of the ISBN namespace, > then that is their fault. For libraries, NBN is the fall back mechanism when other systems such as ISBN cannot be used. I can see the point of UUID namespace from this point of view (as the system level fall back namespace). I still have a problem grasping how such an abstract namespace would work in practice, but that may be a solely personal issue :-). > >> 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. > > Are you proposing that we change "some" to "careful"? That seems fine to > me, since careful consideration is already given. Yes. >> As regards the three bullet points in page 7, I suggest the following >> changes: > > Those changes are hard to track. Please in the future provide such > changes via the following convention: > > OLD > lorem ipsum foo bar baz qux > > NEW > some new text here OK. > > So: > > OLD >> - 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; > > NEW >> - 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); > > That doesn't seem like an improvement to me. You've removed the notion > of organizational stability and added competency. How do you judge > competency? What if the organization hasn't issued URNs before? And are > we really worried about incompetent namespace administrators? I withdraw the suggestion, except that the competency in identifier/name assignment should be added to the old text. > > Furthermore, persistence considerations are already contained elsewhere > in the document. > > I realize that your text is in fact closer to RFC 3406 (rather than > 3406bis), so perhaps the WG might have consensus to keep what's in the > current RFC. But please note that those bullet points are included as > the types of things that people might consider. > > OLD >> - 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. > > NEW >> - 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. > > Why "user organizations"? It has a different scope: although there will be just one organisation which assigns the URN, there will be many more in the foreseeable future using the URN to provide services, and they may be tempted to reassign URNs at some point. > And again resolution is creeping in here. That isn't a necessary aspect > of URNs and shouldn't be a core consideration in the assignment of > namespaces. OK. >> 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). > > 2 weeks has proven to be sufficient, in my experience on the urn-nid list. OK; if we allow some registrations to become standards track documents, that may (I guess) mean stricter control for those namespaces. > >> 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. > > I agree that registrants are often confused about what needs to go in > the community considerations section. > >> 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). > > That's a good list of considerations. I might add a few more once I have > time to think about my experience with namespace registrations. OK. >> Something may also be said about the costs of >> maintaining the system. > > Why? Costs of the system and the funding mechanism may have an impact on the longevity of the service. I might trust more on a service which is relatively cheap and funded from the state budget, than on a system which is expensive and dependent on private donations. >> Registration requests with intentionally misleading NIDs (e.g. NID >> UNESCO when the request has nothing to do with UNESCO) should be turned >> down. > > Do you think those restrictions need to be formalized? IMHO coming up > with a complete list of reserved strings is fruitless -- better to leave > this up to the judgment of the reviwers / document sponsor (typically an > AD). There is no way we could produce a complete list, but we should mention the principle of not approving misappropriate NIDs in the RFC so as to diminish the risk that somebody who has nothing to do with UN tries to register e.g. the namespace identifier "UNESCO". > >> 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. > > I think validation applies to a URN, not the NSS. We can and should validate NSS (whenever possible) as a part of the URN validation process. Generally, such validation can be carried out when the identifier contains a check sum. Quite a few of them do, and they tend to be very useful. >> As regards elaboration of services: I am still working on RFC2483bis, >> but completing the first draft take at least a few weeks. > > Have you had a chance to work on that yet? Alas, not yet. But I'll restart the drafting tomorrow, 23rd of December, and will concentrate on it on 27th and 28th. That may not be sufficient to complete the text, and I will face some technical problems in getting the XML coding right. Juha > > Peter > >> 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 From julian.reschke@gmx.de Thu Dec 22 05:21:35 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 CF96021F8B9A for ; Thu, 22 Dec 2011 05:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] 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 qYUb8m4hqtyS for ; Thu, 22 Dec 2011 05:21:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F2A6B21F8B8F for ; Thu, 22 Dec 2011 05:21:34 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2011 13:21:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 22 Dec 2011 14:21:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19HlQYcIJZHcdhTlxqrNmSUy6Jy+axVuMDcs0Sk6U ltoWREvcD1tdl3 Message-ID: <4EF32EDB.6040807@gmx.de> Date: Thu, 22 Dec 2011 14:21:31 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> In-Reply-To: <4EF32B68.2070408@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 22 Dec 2011 13:21:35 -0000 On 2011-12-22 14:06, Juha Hakala wrote: > ... Here's a high level comment: I think that adding requirements on resolution services is a step into the wrong direction. In particular, it's totally OK that urn:uuids are not resolvable, because that's by design. Do you want to force identifiers like these into different URI schemes? Why? Also, once you start to focus too much on resolution then you'll inevitably get people asking why you don't start with a scheme that already is resolvable in the first place. In the end, stability of URIs depends mainly on those who mint them, not on the actual notation. Best regards, Julian From juha.hakala@helsinki.fi Fri Dec 23 00:14:11 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 8183121F84DF for ; Fri, 23 Dec 2011 00:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=0.620, 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 LE-syFlouM8s for ; Fri, 23 Dec 2011 00:14:11 -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 3B6B021F84DB for ; Fri, 23 Dec 2011 00:14:08 -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 pBN8E3mT007339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2011 10:14:03 +0200 Message-ID: <4EF4384B.6090208@helsinki.fi> Date: Fri, 23 Dec 2011 10:14:03 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Reschke References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> In-Reply-To: <4EF32EDB.6040807@gmx.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: Fri, 23 Dec 2011 08:14:11 -0000 Hello, Julian Reschke wrote: > On 2011-12-22 14:06, Juha Hakala wrote: >> ... > > Here's a high level comment: I think that adding requirements on > resolution services is a step into the wrong direction. In particular, > it's totally OK that urn:uuids are not resolvable, because that's by > design. The current working draft of RFC2483bis makes it clear that there is no such thing as an obligatory resolution service. But it does require that at least one service is supported, since I could not see the point of URNs which are a priori unresolvable. After reading RFC 4122 (urn:uuid namespace specification) I realize it is necessary to drop the resolvability requirement, so RFC2483bis will allow namespaces with zero services. This change can be done easily enough. Resolution related requirements can be weeded from other relevant I-Ds as well. Is there a way to estimate how widely the UUID community is using urn:uuids, and for what purposes? > Do you want to force identifiers like these into different URI schemes? > Why? To be honest, I would rather not see another URN namespace like uuid, since most users of persistent identifier systems have service expectations based on resolvability. And URN:UUIDs a priori will not fulfill any of these expectations. But based on what Peter said earlier, I suppose URN:UUID is and will be different from (all/most) other URN namespaces in this respect. > Also, once you start to focus too much on resolution then you'll > inevitably get people asking why you don't start with a scheme that > already is resolvable in the first place. In the end, stability of URIs > depends mainly on those who mint them, not on the actual notation. Yes, there is a broad agreement among the people who deal with long term preservation of digital content that preservation is primarily an organizational issue. The reason why resolution is important is that URN and other persistent identifiers will only become popular if they can provide added value; services which cool URIs etc. cannot support at all, or could only support with difficulty. These services are often based on resolution. There are good reasons for keeping services and identification apart (for instance, services are technology driven and will change over time), which is why the URN community has tried to avoid conflicts here, both in the existing URN RFCs and in the documents currently under development. All the best, Juha > Best regards, Julian > -- 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 julian.reschke@gmx.de Fri Dec 23 00:49:26 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 60E9021F8B3C for ; Fri, 23 Dec 2011 00:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-4.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] 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 csXm7YQHnkIj for ; Fri, 23 Dec 2011 00:49:26 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 76B4121F8B39 for ; Fri, 23 Dec 2011 00:49:25 -0800 (PST) Received: (qmail invoked by alias); 23 Dec 2011 08:49:22 -0000 Received: from p5DCC39E5.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.229] by mail.gmx.net (mp030) with SMTP; 23 Dec 2011 09:49:22 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19rGIVJGQdrYILyFpup80/77ty1ewy4bU4SMDWGlA NBffvLS6MdFTfL Message-ID: <4EF44091.3070608@gmx.de> Date: Fri, 23 Dec 2011 09:49:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> In-Reply-To: <4EF4384B.6090208@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Fri, 23 Dec 2011 08:49:26 -0000 On 2011-12-23 09:14, Juha Hakala wrote: > ... > Is there a way to estimate how widely the UUID community is using > urn:uuids, and for what purposes? > ... I think it's safe to say that it's used a lot if you need a globally unique URI that doesn't need to be resolvable. And no, I don't think there's something like an "UUID community"... >> Do you want to force identifiers like these into different URI >> schemes? Why? > > To be honest, I would rather not see another URN namespace like uuid, > since most users of persistent identifier systems have service > expectations based on resolvability. And URN:UUIDs a priori will not > fulfill any of these expectations. But based on what Peter said earlier, > I suppose URN:UUID is and will be different from (all/most) other URN > namespaces in this respect. We should keep that the important point in UR*N* * *naming*. URNs *can* be (made) resolvable, and URLs *can* be (stable) names. If this WG believes that urn:uuid is something that is kind of wrong then I think we have a problem :-) >> Also, once you start to focus too much on resolution then you'll >> inevitably get people asking why you don't start with a scheme that >> already is resolvable in the first place. In the end, stability of >> URIs depends mainly on those who mint them, not on the actual notation. > > Yes, there is a broad agreement among the people who deal with long term > preservation of digital content that preservation is primarily an > organizational issue. > > The reason why resolution is important is that URN and other persistent > identifiers will only become popular if they can provide added value; > services which cool URIs etc. cannot support at all, or could only > support with difficulty. These services are often based on resolution. I don't follow. Any kind of organization that can make name-based identifiers stable and resolvable *could* do that with HTTP URIs as well. It's not a technical problem but only one of organization. > There are good reasons for keeping services and identification apart > (for instance, services are technology driven and will change over > time), which is why the URN community has tried to avoid conflicts here, > both in the existing URN RFCs and in the documents currently under > development. Is this the "HTTP" may go way argument? Even if it does, you will still be able to write resolvers, just like what you're trying to do right now with URNs. Best regards, Julian From juha.hakala@helsinki.fi Fri Dec 23 03:01:40 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 E5F3121F8B38 for ; Fri, 23 Dec 2011 03:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=0.496, 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 Bcf-pFKzmo2P for ; Fri, 23 Dec 2011 03:01:39 -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 92BBD21F8B2B for ; Fri, 23 Dec 2011 03:01:37 -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 pBNB1Vft025826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2011 13:01:32 +0200 Message-ID: <4EF45F8B.7040509@helsinki.fi> Date: Fri, 23 Dec 2011 13:01:31 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Reschke References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> In-Reply-To: <4EF44091.3070608@gmx.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: Fri, 23 Dec 2011 11:01:40 -0000 Hello again, Julian Reschke wrote: > We should keep that the important point in UR*N* * *naming*. In my community (libraries & publishing) naming has been taken for granted for decades, due to the identifier systems like ISBN and ISSN. URN is relevant for us because we need to make these traditional identifiers actionable (resolvable) in the Internet. So the important point in URN may vary, depending on the implementer community's requirements and background. > URNs *can* be (made) resolvable, and URLs *can* be (stable) names. True, and the shelf location codes the libraries use could be utilized as identifiers too. But approximately 4000 years of practical experience has proven that it is a very good idea to separate location information and identification, since things do move around, and often in ways that haven't been anticipated. Using URLs as names of Internet resources will eventually (after a few decades or centuries) get more complicated than URN-based solution (which becomes truly useful only when supported by some kind of resolution services). > > If this WG believes that urn:uuid is something that is kind of wrong > then I think we have a problem :-) We do not have a problem, since RFC 4122 and approximately 300.000 assigned urn:uuid's have settled this issue forever. It is definitely not wrong to use UUIDs as URNs. Whether it is a good idea to do that is an entirely different question, and one that will be answered by the users, not by us. Since many people are using just prefix uuid: instead of urn:uuid: there is a chance that at least some people are failing to see the point of using URN:UUIDs. >> There are good reasons for keeping services and identification apart >> (for instance, services are technology driven and will change over >> time), which is why the URN community has tried to avoid conflicts here, >> both in the existing URN RFCs and in the documents currently under >> development. > > Is this the "HTTP" may go way argument? Even if it does, you will still > be able to write resolvers, just like what you're trying to do right now > with URNs. No, I was just emphasizing the point that if we piggyback service parameters in they will not be part of the URN itself. Whenever there are fundamental changes in technology, the URN itself remains the same, but the service parameters may be encoded differently. Best regards, Juha > > Best regards, Julian > -- 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 julian.reschke@gmx.de Fri Dec 23 04:34:26 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 A26C921F8B18 for ; Fri, 23 Dec 2011 04:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.066 X-Spam-Level: X-Spam-Status: No, score=-105.066 tagged_above=-999 required=5 tests=[AWL=-2.467, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ODET6mic0EQ2 for ; Fri, 23 Dec 2011 04:34:25 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 582E921F8AF9 for ; Fri, 23 Dec 2011 04:34:24 -0800 (PST) Received: (qmail invoked by alias); 23 Dec 2011 12:34:23 -0000 Received: from p5DCC39E5.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.229] by mail.gmx.net (mp069) with SMTP; 23 Dec 2011 13:34:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Uv+o+uhyUxxGB6tj5/repaY/9XPJHK3QOoNbe/D QjHulD/5EIx5SR Message-ID: <4EF4754D.2080703@gmx.de> Date: Fri, 23 Dec 2011 13:34:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> In-Reply-To: <4EF45F8B.7040509@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Fri, 23 Dec 2011 12:34:26 -0000 On 2011-12-23 12:01, Juha Hakala wrote: > ... >> Is this the "HTTP" may go way argument? Even if it does, you will >> still be able to write resolvers, just like what you're trying to do >> right now with URNs. > > No, I was just emphasizing the point that if we piggyback service > parameters in they will not be part of the URN itself. Whenever (Because the NSS syntax doesn't allow "?"). True, but it *will* be part of the identifier if you view it from a URI point of view. > there are fundamental changes in technology, the URN itself remains the > same, but the service parameters may be encoded differently. Not convinced; you described one way to add resolution information to the urn: URI, creating a different thing that is a different URI. If you're ok with the URN not being resolvable without additional out-of-band information, there are many many other ways to achieve the same result. Best regards, Julian From duerst@it.aoyama.ac.jp Sun Dec 25 23:26:50 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 CB13F21F8ABB for ; Sun, 25 Dec 2011 23:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.19 X-Spam-Level: X-Spam-Status: No, score=-97.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 UiIdEiFAMA+L for ; Sun, 25 Dec 2011 23:26:50 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6521F8AB0 for ; Sun, 25 Dec 2011 23:26:48 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pBQ7QYI9018275 for ; Mon, 26 Dec 2011 16:26:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 549b_59f9_f0c2212c_2f92_11e1_a9fa_001d096c566a; Mon, 26 Dec 2011 16:26:34 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35687) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Dec 2011 16:26:34 +0900 Message-ID: <4EF821A9.3050404@it.aoyama.ac.jp> Date: Mon, 26 Dec 2011 16:26:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> In-Reply-To: <4EF45F8B.7040509@helsinki.fi> Content-Type: text/plain; charset=UTF-8; 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: Mon, 26 Dec 2011 07:26:50 -0000 Hello Juha, On 2011/12/23 20:01, Juha Hakala wrote: > Julian Reschke wrote: >> URNs *can* be (made) resolvable, and URLs *can* be (stable) names. > > True, and the shelf location codes the libraries use could be utilized > as identifiers too. But approximately 4000 years of practical experience > has proven that it is a very good idea to separate location information > and identification, since things do move around, and often in ways that > haven't been anticipated. This experience applies very much to traditional libraries, where the artefacts being stored are physical in nature. The physical nature and constraints of e.g. printed books, namely having a number of identical copies (because it doesn't matter which one you read) which are nevertheless clearly distinct items makes such a two-level distinction quite obvious. However, the "4000 years" is probably too long; before the printing press, it was extremely rare that a library had two copies of the same book, or if they did, they will have been sufficiently different from each other to be worth taking a closer look. For electronic resources, the physical constraints are virtually gone. Copying electronic content is essentially instantaneous and cost-free (it may not be legally free, though). If I read a book electronically, the library still has it, as does my hard disk and maybe a few caches and content delivery networks between the library and me. This means that there is a strong question as to how, and to what degree, the classical library-based name-location distinction is still relevant and useful. With that I don't want to say that it's useless, I just want to say that however many years of "practical experience" you can claim, that experience may or may not transfer to a world with essentially different "physical" rules. Also, at least as far as content is digital text, search engines add another dimension to this picture. If things move, search engines just catch up. Especially for specialized content, we are definitely not yet there yet, but for more general content, the fact that something gets a different URI isn't the end of the world these days. So up to the middle ages, we mostly had the situation that one would hear by chance that a certain library had a certain work, and would travel to that library and read the work inside that library (though indeed not on the shelf) if one had that much leisure time. In the "library age", one would go to the nearest public library, ask e.g. "I want to read Tom Sawyer", got back a question whether one meant Tom Sawyer by Mark Twain, and then got a "name" (or number) to write on the order slip, or got directed to the relevant bookshelf (location). And one would take the book home, and the library would record the location of the copy in question as "with lender Foo". In the digital age, we can type something into a search box, get the content in no time, and never have to "give it back". At the same time, several copies will have been created. Lots of names/locations/identifiers (from metadata down to track numbers on a hard disk) may be involved, but the overall thing may not easily fit an old-style library name/location dichotomy anymore. Regards, Martin.