From nobody Wed Sep 3 08:26:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B731A0375 for ; Wed, 3 Sep 2014 08:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzJbAyNZxk4s for ; Wed, 3 Sep 2014 08:26:53 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21EA1A036B for ; Wed, 3 Sep 2014 08:25:27 -0700 (PDT) Received: from angora-2.local ([::ffff:173.71.212.143]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 03 Sep 2014 11:25:26 -0400 id 00060006.540732E6.00001121 Message-ID: <540732E3.4090203@thinkingcat.com> Date: Wed, 03 Sep 2014 11:25:23 -0400 From: "Leslie Daigle (TCE)" Organization: ThinkingCat Enterprises User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org, Andrew Newton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LOTv6csjUXjWnQedAVKD-FpTq3c Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:26:54 -0000 [Re-sending from the address that is actually subscribed to the list...] Hi, Thank you for updating the document, and in such short order after the WG meeting! I read through it, and I feel I am being a little dense, or maybe caught between a couple of known edit disconnects. Reading through it, it seems to me that there are 2 problems to solve: + identify, agree and articulate how the URN syntax relates to URI syntax, as captured in RFC3986. This is Section 6 in the document. + ensure that there are persistent identifiers, presumably URIs, that "meet the needs of the Library, Museum, Publisher, and Informational Sciences communities and other users". Some of the requirements for this are captured in the Appendices. The first ought to happen, no matter what, and is in fact the focus of this WG's charter. It could actually happen without addressing the second problem, at least from a strictly logical perspective. I realize that would not be very satisfying -- as the latter was what provided the motivation for the working group in the first place, and I'm not actually suggesting we do that. In fact, I thought where we landed in Toronto was that we should first focus on figuring out how to address those issues -- ensure URI persistent identifiers that meet the requirements and _then_ see whether such persistent URIs were, or could be, URNs as defined by the IETF (i.e., solving the first problem by applying the results of the discussion). In terms of the document, here are a couple of the things that make me wonder about disconnects: 1/ The abstract addresses the second problem, but couches it in terms of the first: "Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Library, Museum, Publisher, and Informational Sciences communities and other users, this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating that document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. For a different document (one addressing the persistent identifier issue), I might write the abstract very slightly differently: Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Identifiers (URIs) to meet the needs of the Library, Museum, Publisher, and Informational Sciences communities and other users, this specification outlines the specification of a persistent identifier scheme which is separate from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) specified in RFC 3986. The syntax of these identifiers is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. 2/ For historic reasons, I have a lot of heartburn with this para: IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept and Uniform Resource Names (URNs), specifically those using the "urn" scheme [RFC2141], as an embodiment of the names that do not directly provide for resource location. This specification is concerned only about URNs of the variety described in RFC 2141 [RFC2141] (i.e., those that use the "urn" scheme). URLs, other types of names, and any URI types that may not fall into one of the above categories are out of its scope and unaffected by it. RFC2141 defines the syntax for URNs, period. Not "the URN: URI scheme". For URNs. I don't take exception to people hating that approach to URNs :-) but insofar as the IETF defines standards, it defined the standard for URNs once. There can be (and already are) any number of other approaches to persistent identifiers that are more or less URN-like, but they are persistent identifiers, Persistent Resource Names, Uniform Persistent Identifiers, whatever. If the IETF starts talking about multiple possible specifications for URNs, we're in trouble, IMO. Leslie. On 8/25/14 8:08 PM, John C Klensin wrote: > Hi. > > I've posted the replacement for > draft-ietf-urnbis-urns-are-not-uris-01 as > draft-ietf-urnbis-semantics-clarif-00. It is now awaiting > Andy's approval which I thought was given shortly after Toronto. > > Some of you know that my intention was to immediately follow it > with a trimmed-down -01 because -00 contains a lot of material > we probably won't want long-term. As a preview, exclusive of > references (some of them cited from the appendices) and > appendices, -00 is only 8 pages long; with them, twice that. > I've deferred trying to get -01 out both because -00 took much > longer than expected and because I continued to review both the > post-Toronto mailing list comments and a number of private > communications and concluded that the current draft may not be > stable enough to start pulling text out of. I'd also like to > have a better idea of what Peter expected to do with 2141bis (or > what the WG wants him to do). > > I'm aware that some text is redundant, especially the repeated > comments about zero effect on generic URI parsing systems. That > is partially intentional (to be sure those statements didn't get > lost when we start removing sections) and partially just > temporarily running out of energy. > > Note too that this draft contains, in Section 6, my cut at the > list Andy requested of alternatives with which the WG will need > to deal. > > In the spirit of the discussions in Toronto, this document is > intended more as the basis for focusing discussions than as a > final piece to be published. To paraphrase what Andy said > there, we need to make decisions about what we want to do and > only then figure out how much of this, if any, is worth having > in an officially-permanent document. > > While some of the discussion in this -00 draft gets fairly far > into "how to do this", I personally concur with something Andy, > Henry, and several others have said in different ways: in the > short run, we are much more likely to end up with the results we > want if we can talk about functionality and not where to put it > or what syntax to use. While the I-D uses "query" and > "fragment" terminology, it may even be useful to thinks of parts > of the URI syntax as "path-stuff", "?-stuff", and "#-stuff", > remembering that the connotations of words like "query" and > "fragment" are themselves semantics. I expect that we will > return to URI terminology before the version of 2141bis that > reflects these issues is posted but, for thinking right now it > again may be useful to break loose from historical concepts. > > Some of the above has almost certainly influenced what I've > written and how I've written it. That doesn't mean the text is > right, but I hope we can be clear about what we are talking > about before we get into trouble. > > Happy reading, > john > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From nobody Wed Sep 3 12:16:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8C1A0AE9 for ; Wed, 3 Sep 2014 12:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJEAv-CUG1U0 for ; Wed, 3 Sep 2014 12:16:27 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA381A0704 for ; Wed, 3 Sep 2014 12:16:26 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPG2a-000F16-0R; Wed, 03 Sep 2014 15:16:24 -0400 Date: Wed, 03 Sep 2014 15:16:18 -0400 From: John C Klensin To: "Leslie Daigle (TCE)" Message-ID: <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> In-Reply-To: <540732E3.4090203@thinkingcat.com> References: <540732E3.4090203@thinkingcat.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xhfE4Dis28a3KGebKfDG_JOAxVs Cc: urn@ietf.org Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:16:30 -0000 --On Wednesday, September 03, 2014 11:25 -0400 "Leslie Daigle (TCE)" wrote: > [Re-sending from the address that is actually subscribed to > the list...] > > Hi, > > Thank you for updating the document, and in such short order > after the WG meeting! > > I read through it, and I feel I am being a little dense, or > maybe caught between a couple of known edit disconnects. Or a strategic question or three. More explanation below but remember that this particular -00 version of this draft was intended to be a placeholder for two classes of things that are probably not part of it long term: (i) Things that really belong in 2141bis or perhaps 3406bis or some other document. (ii) Things, like Section 6 that were included (at Andy's request) purely in the hope of framing the next round of discussions in the WG and moving them forward. In some ways, it would have been better to simply wait for 2141bis (at least), but there was a little bit of a chicken-and-egg problem relative to an expired version of that document and Peter's trying to catch up. Remember too what Andy said in Toronto. To paraphrase, this document is a tool to help the WG advance its work. We don't need to make a decision now as to whether it will ever be published and, if it is, with what content. > Reading through it, it seems to me that there are 2 problems > to solve: > > + identify, agree and articulate how the URN syntax relates to > URI syntax, as captured in RFC3986. This is Section 6 in the > document. Actually, the core of that is Section 4 of this document. The rest is either explanation or, in the case of Section 6, an outline of decisions to be made by the WG and presumably recorded somewhere. That "somewhere" could be a future version of this document, part of 2141bis, or something else. > + ensure that there are persistent identifiers, presumably > URIs, that > "meet the needs of the Library, Museum, Publisher, and > Informational Sciences communities and other users". Some of > the requirements for this are captured in the Appendices. Yes. Partially for legacy reasons to avoid loss of that text should we need it somewhere else. It fairly clearly belonged in the "URNs are not URIs" draft but, since the WG wants to keep URNs as part of the URI family although not necessary following what some people have construed as the generic URI semantics and related restrictions, it is somewhat orphaned now. At the same time, people regularly ask "what are those requirements" and/or "what is that perspective", it seems helpful to keep it around. > The first ought to happen, no matter what, and is in fact the > focus of this WG's charter. It could actually happen without > addressing the second problem, at least from a strictly > logical perspective. Yes. Were the WG to get through some of the issues in Section 6 and then decide that its process and/or convenience would be better served by breaking the material more closely related to the second topic into yet another document, I'd be happy to do that. But, again, I think Peter might reasonably want to incorporate some of it into 2141bis -- if he does, I'll send him the text and drop it out of this document. And, fwiw, I really don't want to spend much time reorganizing material from one document to another without clear direction from the WG. Put differently, let's try to figure out what we want to do, then what we want to say, and then how to say it and where... more or less in that order. > I realize that would not be very satisfying -- as the latter > was what provided the motivation for the working group in the > first place, and I'm not actually suggesting we do that. > > In fact, I thought where we landed in Toronto was that we > should first focus on figuring out how to address those issues > -- ensure URI persistent identifiers that meet the > requirements and _then_ see whether such persistent URIs were, > or could be, URNs as defined by the IETF (i.e., solving the > first problem by applying the results of the discussion). Andy needs to comment on this but my impression coming out of Toronto (and the assumption on which this draft and its predecessor are built) is that: (a) There is a strong conclusion that we want to accommodate the needs of that community and similar ones, i.e., "those issues" within the URN framework at defined (or to be defined) by the IETF if only because, if we can't, it is near-certain that we will see a forked standard. Had the WG taken the position when it started that URNs were inappropriate for those needs and a different URI type (and scheme name) (or something different entirely) should be used, that might have been possible. But, four years later, it is too late. (b) Accommodating those needs requires extending 2141 in the ways that it anticipated, i.e., adding the ability to express what we have recently called "service requests" as part (whatever that means) of the URN. (c) Because of the nature of persistent identifiers, at least some of which may lead to objects stored in multiple and non-persistent locations and others of which may never be resolved to content at all, some of what 3986 has to say is inconsistent with that evolution. Those differences may be as trivial as statements in 3986 about the ultimate way to compare two URIs for equality involving retrieving content and comparing it to seemingly-string definitions and semantics in 3986 about, e.g., the applicability of fragments and their binding to media types. The former example would merely require that URN specification say "don't try to make that kind of comparison where it makes no sense" with no change to 3986 required; the latter is believed by several people to require unbinding the syntax of 3968 from its semantics and binding post-2141 URNs only to the former. Now, if we haven't gotten even that far, I need advice/instructions because, if nothing else, this document is premature even relative to your narrower goal above. In addition, there has been a fourth assumption: (d) Spending a lot of cycles getting the text of this I-D exactly right is not worth the trouble until we decide whether we intend to retain and publish it and will never make sense if we decide to not do that. If I'm called upon to produce another I-D iteration before we make that decision, I'll make it much more explicit. > In terms of the document, here are a couple of the things that > make me wonder about disconnects: > > 1/ The abstract addresses the second problem, but couches it > in terms of the first: >... I am happy to spend time fussing with the abstract once we determine what this document is about and, ideally, whether we ultimately intend to keep or discard it. In the interim, I have recorded your proposed rewrite in my working copy so it doesn't get lost. > 2/ For historic reasons, I have a lot of heartburn with this > para: > > IETF in RFC 1738 [RFC1738] -- as an embodiment of the > locator concept > and Uniform Resource Names (URNs), specifically those > using the "urn" > scheme [RFC2141], as an embodiment of the names that do > not directly > provide for resource location. This specification is > concerned only > about URNs of the variety described in RFC 2141 [RFC2141] > (i.e., > those that use the "urn" scheme). URLs, other types of > names, and > any URI types that may not fall into one of the above > categories are > out of its scope and unaffected by it. > > RFC2141 defines the syntax for URNs, period. Not "the URN: > URI scheme". For URNs. I don't take exception to people > hating that approach to URNs :-) but insofar as the IETF > defines standards, it defined the standard for URNs once. I want to agree with you. But Section 1.1.3 appears to say that the term "URN" refers to both the URN scheme (i.e., what 2141 defines) and lots of other things ("any other URI with the properties of a name"). One of the non-accidental characteristics of the "URNs are not URIs" approach is that it would have nullified that text. If we are going to pursue the "separate only the semantics" approach (semantics that many people believe either should not have been in 3986 in the first place and others believe are illustrative rather than normative), then something has to be done about 1.1.3. The paragraph to which you object was my attempt to remove the current WG and its effort as much as possible from the more general debate about 3986 without modifying 3986 itself. That takes us back to a meta-question. In some best of all possible worlds, we would simply suspend work on URNs, get a replacement/update for 3986 posted that would _at least_ clarify what was normative, what was general guidance and advice, and what was merely examples about how a scheme might do things, be much more precise about the syntax (including strictly following ABNF rather than incorporating RHS matching rules), get rid of problematic statements like the one in 1.1.3, and so on, get that document approved, and then come back to URNs. Unfortunately, most people who have estimated the length of time it would take to get consensus on such a revision have had estimates measured in years (if not decades or eons). If we don't create a revised URN spec in that interval, someone else will. > There can be (and already are) any number of other approaches > to persistent identifiers that are more or less URN-like, but > they are persistent identifiers, Persistent Resource Names, > Uniform Persistent Identifiers, whatever. I would like that to be true. Unfortunately, 3986, which is still an Internet Standard, says otherwise. There are, as far as I can tell, four ways out of that problem: (i) Replace 3986 or create a document that "updates" such statements out of it. (ii) Remove URNs from the scope of generic URIs (and hence 3986) so that statements in 3986 about URNs are nullified. (iii) Try to work around problematic portions of 3986 so that we can get this WG's work done without engaging on those larger issues. (iv) Write an extremely short document deprecating every bit of 3986 except the syntax itself. If that document were to incorporate the syntax (not hugely complex although see above), it could also make 3986 Historic. The difficulties with (i) are discussed above. (iv) would be significantly less work but might show a "no consensus" status a lot more quickly. The WG asked for a draft corresponding to (ii) during and after the London discussions and then decided it didn't like the approach. I think the Toronto conclusion was to pursue (iii). This draft attempts the latter. If it doesn't work either, I hope someone has a proposal other than "give up, close the WG, and let whomever is interested take over URN definition" because it seems to me that is where we are headed. > If the IETF starts talking about multiple possible > specifications for URNs, we're in trouble, IMO. We are, IMO, indeed in trouble. The conditional does not apply: we have been in that trouble at least since RFC 3986 was approved very nearly a decade ago. I'm trying to recognize that trouble and help us dig out. If you don't like the strategy, please propose an alternative that still deals with 3986 as a reality. If the strategy is ok but the text is not, please propose text -- I'm attached to absolutely nothing in this draft other than whatever helps the WG move forward. john From nobody Thu Sep 4 15:40:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508EB1A0076 for ; Thu, 4 Sep 2014 15:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZovyiNfb6k_L for ; Thu, 4 Sep 2014 15:40:55 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D2B1A0084 for ; Thu, 4 Sep 2014 15:40:54 -0700 (PDT) Received: from angora-2.local ([::ffff:173.71.212.143]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Sep 2014 18:40:53 -0400 id 015AC24A.5408EA75.00004C2A Message-ID: <5408EA74.9080803@thinkingcat.com> Date: Thu, 04 Sep 2014 18:40:52 -0400 From: "Leslie Daigle (TCE)" Organization: ThinkingCat Enterprises User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John C Klensin References: <540732E3.4090203@thinkingcat.com> <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> In-Reply-To: <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eZE-2juBPNOUe4pBBN_48MpNaRg Cc: urn@ietf.org Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:40:57 -0000 Okay, I think part of my disconnect is that, while I understand this document is a "support the WG" document that may not persist (and therefore should not steal too many cycles), some of the things I pointed at are ones I think could be misleading for someone joining the discussion late (say, after Toronto). I'm _not_ concluding "and therefore I argue they should be fixed", I'm just framing my perspective :-) Diving in to follow up some pieces: On 9/3/14 3:16 PM, John C Klensin wrote: [massive snip] > > Andy needs to comment on this but my impression coming out of > Toronto (and the assumption on which this draft and its > predecessor are built) is that: > > (a) There is a strong conclusion that we want to > accommodate the needs of that community and similar > ones, i.e., "those issues" within the URN framework at > defined (or to be defined) by the IETF if only because, > if we can't, it is near-certain that we will see a > forked standard. Had the WG taken the position when it > started that URNs were inappropriate for those needs and > a different URI type (and scheme name) (or something > different entirely) should be used, that might have been > possible. But, four years later, it is too late. > > (b) Accommodating those needs requires extending 2141 in > the ways that it anticipated, i.e., adding the ability > to express what we have recently called "service > requests" as part (whatever that means) of the URN. I think we are in agreement. The thought that did not get from my head to the keyboard in my earlier mail was: we may focus first on finding solutions for that community (in ways that are not obviously inimical to existing URNs) and _then_ come back to 2141 updates if we have succeeded in compatibility (and the level at which we have to address 3986 might be more apparent then, too). > > (c) Because of the nature of persistent identifiers, at > least some of which may lead to objects stored in > multiple and non-persistent locations and others of > which may never be resolved to content at all, some of > what 3986 has to say is inconsistent with that > evolution. Those differences may be as trivial as > statements in 3986 about the ultimate way to compare two > URIs for equality involving retrieving content and > comparing it to seemingly-string definitions and > semantics in 3986 about, e.g., the applicability of > fragments and their binding to media types. The former > example would merely require that URN specification say > "don't try to make that kind of comparison where it > makes no sense" with no change to 3986 required; the > latter is believed by several people to require > unbinding the syntax of 3968 from its semantics and > binding post-2141 URNs only to the former. *sigh* I hear you. > > Now, if we haven't gotten even that far, I need > advice/instructions because, if nothing else, this document is > premature even relative to your narrower goal above. In > addition, there has been a fourth assumption: > > (d) Spending a lot of cycles getting the text of this > I-D exactly right is not worth the trouble until we > decide whether we intend to retain and publish it and > will never make sense if we decide to not do that. If > I'm called upon to produce another I-D iteration before > we make that decision, I'll make it much more explicit. > Agreed -- see opening comment. >> In terms of the document, here are a couple of the things that >> make me wonder about disconnects: >> >> 1/ The abstract addresses the second problem, but couches it >> in terms of the first: >> ... > > I am happy to spend time fussing with the abstract once we > determine what this document is about and, ideally, whether we > ultimately intend to keep or discard it. In the interim, I have > recorded your proposed rewrite in my working copy so it doesn't > get lost. > >> 2/ For historic reasons, I have a lot of heartburn with this >> para: >> >> IETF in RFC 1738 [RFC1738] -- as an embodiment of the >> locator concept >> and Uniform Resource Names (URNs), specifically those >> using the "urn" >> scheme [RFC2141], as an embodiment of the names that do >> not directly >> provide for resource location. This specification is >> concerned only >> about URNs of the variety described in RFC 2141 [RFC2141] >> (i.e., >> those that use the "urn" scheme). URLs, other types of >> names, and >> any URI types that may not fall into one of the above >> categories are >> out of its scope and unaffected by it. >> >> RFC2141 defines the syntax for URNs, period. Not "the URN: >> URI scheme". For URNs. I don't take exception to people >> hating that approach to URNs :-) but insofar as the IETF >> defines standards, it defined the standard for URNs once. > > I want to agree with you. But Section 1.1.3 appears to say that > the term "URN" refers to both the URN scheme (i.e., what 2141 > defines) and lots of other things ("any other URI with the > properties of a name"). Okay. IMNSHO, that means RFC3986 is broken and that should have been caught at the time, but I appreciate the political sensitivities (then and now) and am willing to flag it as something to come back and fix if possible. > One of the non-accidental > characteristics of the "URNs are not URIs" approach is that it > would have nullified that text. If we are going to pursue the > "separate only the semantics" approach (semantics that many > people believe either should not have been in 3986 in the first > place and others believe are illustrative rather than > normative), then something has to be done about 1.1.3. The > paragraph to which you object was my attempt to remove the > current WG and its effort as much as possible from the more > general debate about 3986 without modifying 3986 itself. > > That takes us back to a meta-question. In some best of all > possible worlds, we would simply suspend work on URNs, get a > replacement/update for 3986 posted that would _at least_ clarify > what was normative, what was general guidance and advice, and > what was merely examples about how a scheme might do things, be > much more precise about the syntax (including strictly following > ABNF rather than incorporating RHS matching rules), get rid of > problematic statements like the one in 1.1.3, and so on, get > that document approved, and then come back to URNs. > Unfortunately, most people who have estimated the length of time > it would take to get consensus on such a revision have had > estimates measured in years (if not decades or eons). > > If we don't create a revised URN spec in that interval, someone > else will. > >> There can be (and already are) any number of other approaches >> to persistent identifiers that are more or less URN-like, but >> they are persistent identifiers, Persistent Resource Names, >> Uniform Persistent Identifiers, whatever. > > I would like that to be true. Unfortunately, 3986, which is > still an Internet Standard, says otherwise. There are, as far > as I can tell, four ways out of that problem: > > (i) Replace 3986 or create a document that "updates" > such statements out of it. > > (ii) Remove URNs from the scope of generic URIs (and > hence 3986) so that statements in 3986 about URNs are > nullified. I think this is "create a category of identifiers that are syntactically compatible with URIs but not semantically tied", because I argue that URNs are then not the only impacted persistent identifiers. > > (iii) Try to work around problematic portions of 3986 so > that we can get this WG's work done without engaging on > those larger issues. > > (iv) Write an extremely short document deprecating every > bit of 3986 except the syntax itself. If that document > were to incorporate the syntax (not hugely complex > although see above), it could also make 3986 Historic. > > The difficulties with (i) are discussed above. (iv) would be > significantly less work but might show a "no consensus" status a > lot more quickly. The WG asked for a draft corresponding to > (ii) during and after the London discussions and then decided it > didn't like the approach. I think the Toronto conclusion was to > pursue (iii). This draft attempts the latter. If it doesn't > work either, I hope someone has a proposal other than "give up, > close the WG, and let whomever is interested take over URN > definition" because it seems to me that is where we are headed. > >> If the IETF starts talking about multiple possible >> specifications for URNs, we're in trouble, IMO. > > We are, IMO, indeed in trouble. The conditional does not > apply: we have been in that trouble at least since RFC 3986 was > approved very nearly a decade ago. I'm trying to recognize that > trouble and help us dig out. If you don't like the strategy, > please propose an alternative that still deals with 3986 as a > reality. I think we are agreed on strategy but differ in tactics. If the text is confusing no one (else), then perhaps we don't have to worry about that :-) At any rate, I would like discussion to: 1/ focus on the new bits that you added following Toronto, to launch the discussion of "what would we do with the ? and # and / syntax elements to address the overall requirements" - and - 2/ not get stuck 6 months from now with claims from people (confused) that the other text is normative. Leslie. > If the strategy is ok but the text is not, please > propose text -- I'm attached to absolutely nothing in this draft > other than whatever helps the WG move forward. > > john > From nobody Thu Sep 4 18:42:24 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4541A1A02F8 for ; Thu, 4 Sep 2014 18:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyKl6MNgEcKq for ; Thu, 4 Sep 2014 18:42:21 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED4C1A0181 for ; Thu, 4 Sep 2014 18:42:20 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPiXZ-000HrL-TC; Thu, 04 Sep 2014 21:42:17 -0400 Date: Thu, 04 Sep 2014 21:42:12 -0400 From: John C Klensin To: "Leslie Daigle (TCE)" Message-ID: <78A7111695783FBD69408759@JcK-HP8200.jck.com> In-Reply-To: <5408EA74.9080803@thinkingcat.com> References: <540732E3.4090203@thinkingcat.com> <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> <5408EA74.9080803@thinkingcat.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/sEkjYzdpGHs2UNy0BtHGe3ikrzE Cc: urn@ietf.org Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 01:42:23 -0000 --On Thursday, September 04, 2014 18:40 -0400 "Leslie Daigle (TCE)" wrote: > > Okay, I think part of my disconnect is that, while I > understand this document is a "support the WG" document that > may not persist (and therefore should not steal too many > cycles), some of the things I pointed at are ones I think > could be misleading for someone joining the discussion late > (say, after Toronto). I'm _not_ concluding "and therefore I > argue they should be fixed", I'm just framing my perspective > :-) That is fair. Suggested text, or specific pointers to what I should fix, welcome... preferably after Peter has posted 2141bis-08. More generally, I'm unlikely to want to do much more (if anything) with this draft until after 2141bis-08 shows up unless Peter is asking the questions or challenging or confused by text. > Diving in to follow up some pieces: >... >> (b) Accommodating those needs requires extending 2141 in >> the ways that it anticipated, i.e., adding the ability >> to express what we have recently called "service >> requests" as part (whatever that means) of the URN. > > I think we are in agreement. The thought that did not get > from my head to the keyboard in my earlier mail was: we may > focus first on finding solutions for that community (in ways > that are not obviously inimical to existing URNs) and _then_ > come back to 2141 updates if we have succeeded in > compatibility (and the level at which we have to address 3986 > might be more apparent then, too). I think we are in agreement too. Let me, however, suggest a different way of thinking about some of the issues that probably doesn't come through in this semantics draft because I (mostly) considered it out of scope. IMO, there are two ways to proceed from a design standpoint. One is more or less what I understand you to suggest -- we try to focus on accommodating the needs of the community (or communities) that have been most articulate about their requirements, then retrofit those extensions into 2141. The other is that we try to push the "Service Request" model a bit and see if we can do something that is _really_ general, testing its generality against both those expressed requirements and whatever cases we can reasonably hypothesize. In both cases, we more or less need to realize that we are already very far down the path to multiple types and uses of URNs and that they come with different requirements. If there were a collection of requirement spaces or subspaces, the "pure identifier" or "indicator" uses might lie at one extreme and the "URN instantiation of sundry well-established external standards and management systems" (e.g., ISBNs and ISSNs) might lie somewhat else (not necessarily at an extreme. If we take the first approach and get it wrong, we will almost certainly discover that we've run out of extension room and that anything else that comes along and belongs in the requirement space needs, e.g., a URS (Uniform Resource Snafu), more or less along the lines of the "new scheme" model proposed in Toronto. Maybe that would be an ok outcome. But, if we want the URN umbrella to cover as much of the requirements space as possible, generality is probably our friend. >... >> Now, if we haven't gotten even that far, I need >> advice/instructions because, if nothing else, this document is >> premature even relative to your narrower goal above. In >> addition, there has been a fourth assumption: >> >> (d) Spending a lot of cycles getting the text of this >> I-D exactly right is not worth the trouble until we >> decide whether we intend to retain and publish it and >> will never make sense if we decide to not do that. If >> I'm called upon to produce another I-D iteration before >> we make that decision, I'll make it much more explicit. >> > > Agreed -- see opening comment. And, with a strong nod to your opening comment, I see a considerable potential distance between "not add to the confusion" and "getting the text exactly right". If it is confusing, we should, IMO, fix it. >>> In terms of the document, here are a couple of the things >>> that make me wonder about disconnects: >... >>> RFC2141 defines the syntax for URNs, period. Not "the URN: >>> URI scheme". For URNs. I don't take exception to people >>> hating that approach to URNs :-) but insofar as the IETF >>> defines standards, it defined the standard for URNs once. >> >> I want to agree with you. But Section 1.1.3 appears to say >> that the term "URN" refers to both the URN scheme (i.e., what >> 2141 defines) and lots of other things ("any other URI with >> the properties of a name"). > > Okay. IMNSHO, that means RFC3986 is broken and that should > have been caught at the time, but I appreciate the political > sensitivities (then and now) and am willing to flag it as > something to come back and fix if possible. While you conclude from this that 3986 is broken and I, personally, agree with you, it was clear in Toronto (and on the mailing list before and after) that the WG does not have consensus on that point. >... >>> There can be (and already are) any number of other approaches >>> to persistent identifiers that are more or less URN-like, but >>> they are persistent identifiers, Persistent Resource Names, >>> Uniform Persistent Identifiers, whatever. >> >> I would like that to be true. Unfortunately, 3986, which is >> still an Internet Standard, says otherwise. There are, as >> far as I can tell, four ways out of that problem: >> >> (i) Replace 3986 or create a document that "updates" >> such statements out of it. >> >> (ii) Remove URNs from the scope of generic URIs (and >> hence 3986) so that statements in 3986 about URNs are >> nullified. > > I think this is "create a category of identifiers that are > syntactically compatible with URIs but not semantically tied", > because I argue that URNs are then not the only impacted > persistent identifiers. Yes, that is another possibility. Unfortunately, 3986 also contains language that moves it away from general URIs and, instead, indicates that the only thinks out there are locators, non-locator names, and mixtures of the two. One can interpret that as implying URLs, URNs, and something else, or one can interpret it as broad categories in which URLs are part of the first group and URNs are part of the second. The most common interpretation, as I understand it, has been the first. >> (iii) Try to work around problematic portions of 3986 so >> that we can get this WG's work done without engaging on >> those larger issues. >... >>> If the IETF starts talking about multiple possible >>> specifications for URNs, we're in trouble, IMO. >> >> We are, IMO, indeed in trouble. The conditional does not >> apply: we have been in that trouble at least since RFC 3986 >> was approved very nearly a decade ago. I'm trying to >> recognize that trouble and help us dig out. If you don't >> like the strategy, please propose an alternative that still >> deals with 3986 as a reality. > > I think we are agreed on strategy but differ in tactics. If > the text is confusing no one (else), then perhaps we don't > have to worry about that :-) See above about confusion. > At any rate, I would like discussion to: > > 1/ focus on the new bits that you added following Toronto, to > launch the discussion of "what would we do with the ? and # > and / syntax elements to address the overall requirements" > > - and - > > 2/ not get stuck 6 months from now with claims from people > (confused) that the other text is normative. Wfm. By the way, I intend to start pulling text out as soon as the WG and Andy will let me. That should not be before 2141bis-08 appears, but my goal was to get all of the text into one document that people could look at and think about, then remove everything that was not clearly relevant. So, if it is possible to make good progress from this point, I'd expect that most of the text that might be confusing would have disappeared before your six months are up. john From nobody Fri Sep 5 13:52:30 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0AD1A0296 for ; Fri, 5 Sep 2014 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHCO5LziwWUg for ; Fri, 5 Sep 2014 13:52:24 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBB91A00B8 for ; Fri, 5 Sep 2014 13:52:23 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id nV6u1o0071ap0As56YsPht; Fri, 05 Sep 2014 20:52:23 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id nYsN1o00v1KKtkw3iYsPVp; Fri, 05 Sep 2014 20:52:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s85KqMwH010850 for ; Fri, 5 Sep 2014 16:52:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s85KqMcZ010849; Fri, 5 Sep 2014 16:52:22 -0400 Date: Fri, 5 Sep 2014 16:52:22 -0400 Message-Id: <201409052052.s85KqMcZ010849@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org) References: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409950343; bh=II5MzVMTunUHQfmtDPL7oemlXLsFEQjJ/wTG3Z00FX8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Nn9xz1fTCXcafxaKDxIyRHElBWbCgje3QjYsMDzNaQoML3f7LqqRiO5oPNi177qpt QkihGYqywgZ36l5hXj5gfPTeb1t6he7Zd1WpzdFJdcCHxCjbiJbio/UupiqHZdT610 aN1/gyQfY5g4oH/pOxCrK0i2RaP5+B5P+KlCVZZxn2XMTbO/bamKgCFeI/RbKJsvts /sR1VKik0ZjK8aONtkfZ7zYePysZuGEI/qdKRqp7p0b726enPzV23X2TObZhkl2dRf STJGWOcfrihwPXOo/l2LQGOcE86Z4Kagtrom1zuhO2PRp3i0l4fPhLG2oC2xvp9SYf Zxs1Wvm+YH1wQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JfvbWHun-ddc-sw7SrENuD0YXcs Subject: [urn] Wording draft-ietf-urnbis-semantics-clarif-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:52:27 -0000 I've been looking at draft-ietf-urnbis-semantics-clarif-00, and it seems to be a practical place to start. I think its wording could be improved in some places. The Abstract says: ... this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating that document accordingly. Section 1 (Introduction) says: This specification is concerned only about URNs of the variety described in RFC 2141 [RFC2141] (i.e., those that use the "urn" scheme). URLs, other types of names, and any URI types that may not fall into one of the above categories are out of its scope and unaffected by it. I'm sure that the text in section 1 is what we intend, but it doesn't match what is in the Abstract; the Abstract claims to cover all URNs, not just things with the scheme "urn". This goes back to the fact that we've been sloppy about the distinction between "URN" (per RFC 3986, things that have the "name" properties, that is, "identifiers" in Juha's terminology), and things with the scheme "urn". In particular, the Generic URI Syntax specification goes beyond syntax to specify the meaning and interpretation of various fields, especially the "query" and "fragment" ones. It would help the reader who is not already neck-deep in the discussion to consistently use one name for each document. Most references in this draft use the RFC number, but some references use the document title. (Amusingly, both of the above issues involve the use of names: The first is distinguishing the set of all possible URNs from the set URIs with scheme "urn", which contains all existing URNs. The second emphasizes the usefulness of using a unique name for each particular resource.) In section 2 (Pragmatic Goals) is this item: 1. Try to accommodate all of those who think URNs are necessary, i.e., that they can and should be usefully distinguished in certain respects from other URIs, at least those that have been defined prior to this document. In particular, provide a foundation for extensions to the URN syntax allowed by and defined in RFC 2141 to support requirements encountered by some of those communities. The first clause of the item doesn't fit with what follows. One can consider "URNs are necessary" without thinking "they can and should be usefully distinguished in certain respects from other URIs". (One can consider a thing necessary without requiring it to be contained in a distinguished category from certain other things.) I think what is meant "those who think that a specific category for URNs is necessary". But I think the meaning can be more simply conveyed by removing that clause, starting the item with "Try to accommodate all of those who think that URNs can and should be usefully distinguished...". Dale From nobody Fri Sep 5 20:07:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1635C1A0B79 for ; Fri, 5 Sep 2014 20:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwSa8tO3vX07 for ; Fri, 5 Sep 2014 20:07:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6D1A0B03 for ; Fri, 5 Sep 2014 20:07:03 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id nf3k1o0020Fqzac53f72Gw; Sat, 06 Sep 2014 03:07:03 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id nf721o0031KKtkw3Uf72Hi; Sat, 06 Sep 2014 03:07:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s86371s8031697 for ; Fri, 5 Sep 2014 23:07:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s86371n6031692; Fri, 5 Sep 2014 23:07:01 -0400 Date: Fri, 5 Sep 2014 23:07:01 -0400 Message-Id: <201409060307.s86371n6031692@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409972823; bh=xfSonB7W84/7ynLVcavVdmP2zwCeCP+JG2b8GOJvGp8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=FQVoB7mydAoRyZdlHExo1q3sYDqNV72efTjAcx26EeF/qi1KVkAC8T+HeXvwH0IWL w9lySG+AFfNMLbxQBhzTIXMvINwm1M8/G9pThd+MZC2itHCrqYXFQ5lyHPaViqzd9w mc5hxlebbtSItU0dLigeBCyJVzIDfv/CCf+tRmRR2KSHopApMsNgqWbY36uJeSbAnh qL/oY/QmIAXtJ9o4GdX5pk7nST3zUvuX6Lvi+J6xJTKgB34s0FTZHkuMvSVDoO7uMn 5HFcl9C+mR510LqYQPSB/7l4hcqReeFr+PXE2v4yxrLqsaNd93xPkyVimJ6/pZBBit TSC97PFXsj9Wg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/U4tpwXhXx2MJEDEjBT_0ra8OJZc Subject: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 03:07:08 -0000 Here I am attempting to summarize a conceptual distinction that seems to be to be important for this discussion: There are classes of "identifiers" whose meanings are fixed by the meanings of "names" upon which they are based. (I think this aligns with the ideas Juha presented in his message "Rules for identifier systems" (http://www.ietf.org/mail-archive/web/urn/current/msg02449.html).) Terminology: I am going to use the terminology of RFC 3986: name - A persistent, unique identifier whose definition and assignment is managed by an explicit authority. (In Juha's terminology, an "identifier".) (A URN, in RFC 3986 terminology.) identifier - An identifier that indicates some resource(s) by some means. This identification may depend on an assumed "access" or "resolution" process, and may depend on the circumstances within which it is used. (A URI, in RFC 3986 terminology.) Let me go through a number of examples which share certain features: Example 1: Adding a "fragment" part to a URN Let us assume that is the name of an HTML document. (I have administrative authority over that part of the OID tree, so I can make it so!) And let us suppose that one of the tags in the document has a "name" attribute with value "section1". Then (given how "fragment" is used in HTML URLs), it would be reasonable to define that references that location within that (abstract) HTML document. Example 2: Footnoting a page Sitting in front of me is a copy of the book edition with ISBN 978-1-59403-698-9. That book edition has the URN . Suppose we define an extension to the syntax to allow reference to a specific page of a book denoted by an ISBN: . (Here, I deliberately use the character "^" for the extension; "^" is not valid in URIs, and so I cannot be thought to be advocating any particular syntax.) This construction would be useful for scholarly citations. Example 3: Retrieving bibliographic information Suppose there is a standard for providing the metadata (bibliographic data) about a resource. This has been called "URC" (Uniform Resource Characteristics) in RFC 2169. Then we could standardize that is the identifier of the metadata regarding . (Of course, this does not address how we obtain the metadata, it only defines a standard identifier with which to refer to it.) Example 4: Retrieving the instance of a resource from a particular server Suppose we have defined a way to obtain an instance of the resource named by from a server. Then we could standardize the identifier to be the instance (if any) of that can be obtained from foo.example.com. All of these examples have a two-part structure: - a "base URN", which is a name in the strict sense -- its meaning is defined and fixed by an authority - a "modifier" whose meaning/interpretation/effect is fixed by a standard such that the combination of base URN and modifier is fixed by the combination of the meaning of the base URN (set by the authority) and the meaning of the modifier (set by the standard) The degree to which the full URI is a name varies. In regard to Example 2 (footnoting a page), the modified URN is as well-defined, unique, and permanent as the ISBN itself. (Which is why scholarly citations are done that way.) It differs from full "names" by the fact that its meaning is not *individually* set by an authority. Similarly, Example 1 (Adding a fragment) generates a modified URN that is a name in every way except that it is not individually allocated by an authority. Example 3 (metadata) would be a name if the contents of the metadata was fixed by some standard or authority. But it seems that in practice, it is not so, so the modified URN is just a URI, as the result of a particular reference to the resource depends on many unknown factors. (And it is not even a URL, as it does not describe how to resolve itself.) Example 4 (retrieving from a particular server) is a URL, since it specifies how to obtain the described information. But it is not a name, as there is no assurance that particular resolver can produce an instance of that base resource. So although all of these modified URNs are constructed in the same generic way, the nature of the resulting URI (URN, URL, neither, or perhaps both) depends on the specification of the modifier. If we want to allow these sorts of construction, I do not see that as a problem, as long as we remain aware that the modified URN may not have the same properties as the base URN. I doubt anyone will be confused in any particular application, but people must beware of making generalizations without thinking through the various possibilities. Dale From nobody Fri Sep 5 23:37:19 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E391A6F6B for ; Fri, 5 Sep 2014 23:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSEq5coKg9c8 for ; Fri, 5 Sep 2014 23:37:13 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C036F1A6F5D for ; Fri, 5 Sep 2014 23:37:13 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XQ9cW-000KIy-7H; Sat, 06 Sep 2014 02:37:12 -0400 Date: Sat, 06 Sep 2014 02:37:07 -0400 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: <630C2513ADFE8871D5CA6C07@JcK-HP8200.jck.com> In-Reply-To: <201409052052.s85KqMcZ010849@hobgoblin.ariadne.com> References: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> <201409052052.s85KqMcZ010849@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/CQfIfDrxnHA2GQrumonNvsL1CTQ Subject: Re: [urn] Wording draft-ietf-urnbis-semantics-clarif-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 06:37:16 -0000 --On Friday, September 05, 2014 16:52 -0400 "Dale R. Worley" wrote: > I've been looking at draft-ietf-urnbis-semantics-clarif-00, > and it seems to be a practical place to start. I think its > wording could be improved in some places. > > The Abstract says: > > ... this specification separates URNs from the semantic > constraints that many people believe are part of the > specification for Uniform Resource Identifiers (URIs) > specified in RFC 3986, updating that document accordingly. > > Section 1 (Introduction) says: > > This specification is concerned only about URNs of the > variety described in RFC 2141 [RFC2141] (i.e., those that > use the "urn" scheme). URLs, other types of names, and any > URI types that may not fall into one of the above > categories are out of its scope and unaffected by it. > > I'm sure that the text in section 1 is what we intend, but it > doesn't match what is in the Abstract; the Abstract claims to > cover all URNs, not just things with the scheme "urn". Please see my conversation with Leslie from 3 - 5 September (http://www.ietf.org/mail-archive/web/urn/current/maillist.html). In particular, the conclusion in Toronto, Andy's instructions, and that thread all argue that, unless it actually causes confusion in our conversations, it is not a good use of time to fine-tune the text of this document until we decide what we are going to do substantively and then decide whether to keep the document. So, yes, if we are going to keep and publish the document, the abstract needs work. If we are not, please concentrate on substance or explain why the current text is getting in the way of a discussion. > This goes back to the fact that we've been sloppy about the > distinction between "URN" (per RFC 3986, things that have the > "name" properties, that is, "identifiers" in Juha's > terminology), and things with the scheme "urn". This issue was also addressed in that earlier thread, although less directly so. I intentionally did not include it in Section 6 and left out precisely because it relates to what this document says (relevant only if we are going to publish it) rather than the core substance of the WG's work. As illustrated by the thread Leslie started, both she and I (and, I believe from earlier threads and discussions) believe that the language of 3986 that says there are URNs that don't follow the "urn:" scheme is undesirable and has little value unless the goal is to create confusion. At least in retrospect, it probably should have said something more like "there are names and naming system that may be URIs but are not URNs". The WG needs to decide whether it wants to address that topic, whether it wants to address it in a successor to this document and, if so, what it wants to say. The current draft intended to sidestep the issue. Another alternative would be to "update" it out of 3986 but it is hard to do that without formally criticizing 3986. Such criticisms seem to be painful out of proportion to their value in moving the present URN work forward. Then we can make any documents we intend to publish consistent with that decision. > In particular, the Generic URI Syntax specification goes > beyond syntax to specify the meaning and interpretation of > various fields, especially the "query" and "fragment" ones. > > It would help the reader who is not already neck-deep in the > discussion to consistently use one name for each document. > Most references in this draft use the RFC number, but some > references use the document title. Until and unless we decide we intend to publish this document, its audience it precisely those people who are neck-deep in the discussion. Until that time, it is an instrument to aid WG discussion, not an introduction to the WG's work. Bluntly and IMnvHO, a far worse problem than the inconsistencies you cite in the working draft is people expressing opinions in the WG who are not familiar with the issues, mailing list discussions, and relevant documents. > (Amusingly, both of the above issues involve the use of names: > The first is distinguishing the set of all possible URNs from > the set URIs with scheme "urn", which contains all existing > URNs. The second emphasizes the usefulness of using a unique > name for each particular resource.) As others have observed, the difference between a thing, the name of the thing, and the names by which it is called have often been a source of confusion in our conversations. I do not believe that the text of this document adds to that confusion for someone who has been following the work of the WG. If you disagree, send text. > In section 2 (Pragmatic Goals) is this item: > > 1. Try to accommodate all of those who think URNs are > necessary, i.e., that they can and should be usefully > distinguished in certain respects from other URIs, at > least those that have been defined prior to this > document. In particular, provide a foundation for > extensions to the URN syntax allowed by and defined in > RFC 2141 to support requirements encountered by some of > those communities. > > The first clause of the item doesn't fit with what follows. > One can consider "URNs are necessary" without thinking "they > can and should be usefully distinguished in certain respects > from other URIs". (One can consider a thing necessary without > requiring it to be contained in a distinguished category from > certain other things.) That is why the word "and" was used, and used in its Boolean sense. If that is sufficiently unclear to be confusing, please see below and suggest text. > I think what is meant "those who think > that a specific category for URNs is necessary". But I think > the meaning can be more simply conveyed by removing that > clause, starting the item with "Try to accommodate all of > those who think that URNs can and should be usefully > distinguished...". If the current text isn't clear, that isn't the fix because part of the point is that the argument has been made that URNs (at least "urn:" scheme ones, fall somewhere on the scale between completely irrelevant and a bad mistake. For someone who holds that belief, their relationship to [other] URIs is of no importance or, put differently, worthy of discussion among the angels dancing on the head of some particular pin. Sorry. I do appreciate the careful reading. I'm just hoping to do what the document was written to do, which is to focus the WG on critical-path substantive questions rather than editorial and philosophical debates. best, john From nobody Sat Sep 6 00:03:20 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808DC1A6F6D for ; Sat, 6 Sep 2014 00:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze6hTaVhq5_T for ; Sat, 6 Sep 2014 00:03:15 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FD91A0462 for ; Sat, 6 Sep 2014 00:03:15 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XQA1i-000KXN-Er; Sat, 06 Sep 2014 03:03:14 -0400 Date: Sat, 06 Sep 2014 03:03:09 -0400 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> In-Reply-To: <201409060307.s86371n6031692@hobgoblin.ariadne.com> References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tlA_sg8PSEEuapDHjP3y1KnOEdI Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:03:17 -0000 Dale, I think I understand what you are attempting to do and believe it is constructive. However, trying to do it in terms of definitions and other semantics in 3986 that have already been shown to be problematic is not particularly helpful, at least for me. Details inline below. --On Friday, September 05, 2014 23:07 -0400 "Dale R. Worley" wrote: > Here I am attempting to summarize a conceptual distinction > that seems to be to be important for this discussion: There > are classes of "identifiers" whose meanings are fixed by the > meanings of "names" upon which they are based. > > (I think this aligns with the ideas Juha presented in his > message "Rules for identifier systems" > (http://www.ietf.org/mail-archive/web/urn/current/msg02449.htm > l).) > > Terminology: I am going to use the terminology of RFC 3986: Unless you are going to argue against the general approach of draft-ietf-urnbis-semantics-clarif (in which case, please do so explicitly), please don't. The particular vocabulary of 3986 has been, at least IMO, a significant part of the confusion and delay in this WG and, at least through and including the Toronto discussions, viewing 3986 purely as a syntax definition appears useful (and possibly even necessary) to this WG's making progress. In particular, the class of URN that acts as an indicator or flag, such as the XMPP case that Peter has mentioned several times, does not conform to the "identifier" definition you cite below. If we intend to have a discussion about deprecating that use, let's have it explicitly. If we do not, let's move on. > identifier - An identifier that indicates some resource(s) by > some means. This identification may depend on an assumed > "access" or "resolution" process, and may depend on the > circumstances within which it is used. (A URI, in RFC 3986 > terminology.) > Let me go through a number of examples which share certain > features: I'm going to take a couple of these examples as additional examples of why trying to reintroduce fine interpretations of 3986 is not helpful here: > Example 1: Adding a "fragment" part to a URN > > Let us assume that is the > name of an HTML document. (I have administrative authority > over that part of the OID tree, so I can make it so!) And let > us suppose that one of the tags in the document has a > "name" attribute with value "section1". Then (given how > "fragment" is used in HTML URLs), it would be reasonable to > define that > references that location within that (abstract) HTML document. But 3986 explicitly binds fragments to media type, so, unless either every OID or your particular OID has a media type, that discussion leads to a very odd place. In addition, as previously discussed on-list and reflected in Appendix B.3 of the current draft, there is a case to be made that the fragment to which you refer is really a property of the HTML document and not the OID or URN. As such, the syntax you are looking for might be more like I don't believe that, but the distinction is very fine indeed and one that the WG may need to address. > Example 2: Footnoting a page > > Sitting in front of me is a copy of the book edition with ISBN > 978-1-59403-698-9. That book edition has the URN > . > > Suppose we define an extension to the syntax to allow > reference to a specific page of a book denoted by an ISBN: > . (Here, I deliberately use > the character "^" for the extension; "^" is not valid in URIs, > and so I cannot be thought to be advocating any particular > syntax.) This construction would be useful for scholarly > citations. Of course, your doing that as part of the URN requires that you have an agreement with the particular publisher that all instances of objects that they associate with the ISBN have the same pagination properties. I don't believe that is a requirement of the ISBN standard. Whether it is or not, I know (as Juha has also pointed out), publisher assignments of ISBNs are sometimes more flexible. > Example 3: Retrieving bibliographic information > > Suppose there is a standard for providing the metadata > (bibliographic data) about a resource. This has been called > "URC" (Uniform Resource Characteristics) in RFC 2169. Then we > could standardize that > is the identifier > of the metadata regarding . > (Of course, this does not address how we obtain the metadata, > it only defines a standard identifier with which to refer to > it.) I'll let you and Juha (and others who are interested) debate whether that form is an identifier or a service request. I hope that, in the process, you will explain to the rest of us how the distinction moves the work of the WG forward. >... best, john From nobody Mon Sep 8 07:42:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D051A8842 for ; Mon, 8 Sep 2014 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHLsHHBdEiBB for ; Mon, 8 Sep 2014 07:42:32 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22E21A883F for ; Mon, 8 Sep 2014 07:42:32 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id ft15so4891307pdb.32 for ; Mon, 08 Sep 2014 07:42:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d5Gk6zXbJgyIOXWHBsQU2RLudCtdET4gOSeYA9PbWQU=; b=HV1pHMQL/Yq0re7Cvw91Pbr2TdVSSNXK8RdjeOezMQr/m/21KVe6f0/2osFNx96/2z AJ5TfCsgVQyRWVUGt4zDbwOTshnBvpj3c9cC118/Uf5/gwLkQfxhVCuq56bpAba0s6P8 i6nSO/6x6FHh/vJvJlQzwzF6jRwbxGOkBNJLFndHKsSqS9GV8poUzh/nhuIrGP/NWUrR dIORP+xO6EJqqPuYjmp8yVzFOsVccFUapp7LWB5N0fW8g4T0NBQOExdqJ/hhlUCq2eHH hGigwHHcIdcWAsFc1EfBl8b+KP7NAs7w/E0w4GET3+ZT+o8g5fj3wJTwmbWD0AdZ7baq jQlA== X-Gm-Message-State: ALoCoQljATzJQeIOfd1c9OQPlfN9ZNXD/S86XZPpdt2Np/Sj2pgqqrgMfnh4k9uDfhoFRqknY1U2 MIME-Version: 1.0 X-Received: by 10.70.96.233 with SMTP id dv9mr6240662pdb.146.1410187352484; Mon, 08 Sep 2014 07:42:32 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Mon, 8 Sep 2014 07:42:32 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <78A7111695783FBD69408759@JcK-HP8200.jck.com> References: <540732E3.4090203@thinkingcat.com> <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> <5408EA74.9080803@thinkingcat.com> <78A7111695783FBD69408759@JcK-HP8200.jck.com> Date: Mon, 8 Sep 2014 10:42:32 -0400 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/W83mBkco20Z6-v4ldr1D3IQ1ZZ4 Cc: "urn@ietf.org" Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:42:34 -0000 On Thu, Sep 4, 2014 at 9:42 PM, John C Klensin wrote: > > In both cases, we more or less need to realize that we are > already very far down the path to multiple types and uses of > URNs and that they come with different requirements. If there > were a collection of requirement spaces or subspaces, the "pure > identifier" or "indicator" uses might lie at one extreme and the > "URN instantiation of sundry well-established external standards > and management systems" (e.g., ISBNs and ISSNs) might lie > somewhat else (not necessarily at an extreme. If we take the > first approach and get it wrong, we will almost certainly > discover that we've run out of extension room and that anything > else that comes along and belongs in the requirement space > needs, e.g., a URS (Uniform Resource Snafu), more or less along > the lines of the "new scheme" model proposed in Toronto. Maybe > that would be an ok outcome. But, if we want the URN umbrella > to cover as much of the requirements space as possible, > generality is probably our friend. I think generality is a good thing, but I wonder if we have enough people/bandwidth to do it. (fyi, that's just me thinking aloud, not guidance) >>> I want to agree with you. But Section 1.1.3 appears to say >>> that the term "URN" refers to both the URN scheme (i.e., what >>> 2141 defines) and lots of other things ("any other URI with >>> the properties of a name"). >> >> Okay. IMNSHO, that means RFC3986 is broken and that should >> have been caught at the time, but I appreciate the political >> sensitivities (then and now) and am willing to flag it as >> something to come back and fix if possible. > > While you conclude from this that 3986 is broken and I, > personally, agree with you, it was clear in Toronto (and on the > mailing list before and after) that the WG does not have > consensus on that point. Even if we did have consensus on that (and we may), it is also irrelevant. The AA serenity prayer comes to mind here. > Wfm. By the way, I intend to start pulling text out as soon as > the WG and Andy will let me. That should not be before > 2141bis-08 appears, but my goal was to get all of the text into > one document that people could look at and think about, then > remove everything that was not clearly relevant. So, if it is > possible to make good progress from this point, I'd expect that > most of the text that might be confusing would have disappeared > before your six months are up. Rip it out! We always have the historical versions. -andy From nobody Mon Sep 8 10:09:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECD1A0489 for ; Mon, 8 Sep 2014 10:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RGDb1B06a_a for ; Mon, 8 Sep 2014 10:08:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94C91A0659 for ; Mon, 8 Sep 2014 10:08:50 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XR29B-000LHW-Iv; Mon, 08 Sep 2014 12:50:33 -0400 Date: Mon, 08 Sep 2014 12:50:25 -0400 From: John C Klensin To: Andrew Newton Message-ID: <1DE44C0E1F19BFB66DE7801A@JcK-HP8200.jck.com> In-Reply-To: References: <540732E3.4090203@thinkingcat.com> <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> <5408EA74.9080803@thinkingcat.com> <78A7111695783FBD69408759@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KysH_lKlA7FLeU9t4m_gq09M3wQ Cc: urn@ietf.org Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:09:02 -0000 --On Monday, September 08, 2014 10:42 -0400 Andrew Newton wrote: > On Thu, Sep 4, 2014 at 9:42 PM, John C Klensin > wrote: >> >> In both cases, we more or less need to realize that we are >> already very far down the path to multiple types and uses of >> URNs and that they come with different requirements. If there >> were a collection of requirement spaces or subspaces, the >> "pure identifier" or "indicator" uses might lie at one >> extreme and the "URN instantiation of sundry well-established >> external standards and management systems" (e.g., ISBNs and >> ISSNs) might lie somewhat else (not necessarily at an >> extreme. If we take the first approach and get it wrong, we >> will almost certainly discover that we've run out of >> extension room and that anything else that comes along and >> belongs in the requirement space needs, e.g., a URS (Uniform >> Resource Snafu), more or less along the lines of the "new >> scheme" model proposed in Toronto. Maybe that would be an ok >> outcome. But, if we want the URN umbrella to cover as much >> of the requirements space as possible, generality is probably >> our friend. > > I think generality is a good thing, but I wonder if we have > enough people/bandwidth to do it. > (fyi, that's just me thinking aloud, not guidance) Given the relatively small number of people who seem willing and able to engage on the broad issues on an ongoing basis, as distinct from focusing narrowly on some particular set of applications and/or preserving the view of what URNs are able that is reflected in RFC 3986, I think there is reason at this point to believe that we do not. On the other hand, if we don't go for the generality, I think there is a real and serious question about whether the WG should continue to work on developing a solution for which counterexample to the hypothesis of adequacy are likely. Put differently, the IETF can cause, or contribute to, a fork by doing a job that doesn't meet some needs or we can do it by giving up. The latter is obviously unattractive, but might be less painful for those of us who seem to be doing a disproportionate fraction of the work. >>>> I want to agree with you. But Section 1.1.3 appears to say >>>> that the term "URN" refers to both the URN scheme (i.e., >>>> what 2141 defines) and lots of other things ("any other URI >>>> with the properties of a name"). >>> >>> Okay. IMNSHO, that means RFC3986 is broken and that should >>> have been caught at the time, but I appreciate the political >>> sensitivities (then and now) and am willing to flag it as >>> something to come back and fix if possible. >> >> While you conclude from this that 3986 is broken and I, >> personally, agree with you, it was clear in Toronto (and on >> the mailing list before and after) that the WG does not have >> consensus on that point. > > Even if we did have consensus on that (and we may), it is also > irrelevant. The AA serenity prayer comes to mind here. It isn't irrelevant if --as I think some people have suggested (or nearly so)-- the WG decides to suspend work until 3986bis can be completely and agreed to. As I have said in response to those suggestions before, I believe that, in practice, that would be just a different way to give up, but that is just my opinion. >> Wfm. By the way, I intend to start pulling text out as soon >> as the WG and Andy will let me. That should not be before >> 2141bis-08 appears, but my goal was to get all of the text >> into one document that people could look at and think about, >> then remove everything that was not clearly relevant. So, if >> it is possible to make good progress from this point, I'd >> expect that most of the text that might be confusing would >> have disappeared before your six months are up. > > Rip it out! We always have the historical versions. I'm on travel or otherwise out of pocket for almost 3/4 of this month and October is unlikely to= be better. As a result you are going to get at most one more draft in the next two or three weeks and probably no more than one more in October. So I will tentatively start, but really would prefer to see 2141bis before I post. I'll go ahead and generate a stripped-down version without it if Peter tells us that we shouldn't expect that draft any time soon but, so far, I gather we are on schedule for the next day or two. john From nobody Mon Sep 8 13:54:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6B41A0322 for ; Mon, 8 Sep 2014 13:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVbfFGIVHIMo for ; Mon, 8 Sep 2014 13:54:12 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7ACB1A00F5 for ; Mon, 8 Sep 2014 13:54:11 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by resqmta-ch2-11v.sys.comcast.net with comcast id okV61o0090EZKEL01kuBb9; Mon, 08 Sep 2014 20:54:11 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta01.westchester.pa.mail.comcast.net with comcast id oku91o00r1KKtkw3MkuAb2; Mon, 08 Sep 2014 20:54:10 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s88Ks8j0025850; Mon, 8 Sep 2014 16:54:08 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s88Ks6Gx025844; Mon, 8 Sep 2014 16:54:06 -0400 Date: Mon, 8 Sep 2014 16:54:06 -0400 Message-Id: <201409082054.s88Ks6Gx025844@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> (john-ietf@jck.com) References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410209651; bh=XqXB7yfYxfGDHvWPcy3tzx/jWbtLwKOJFAyuQSuesJE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=YaN9ZNfD4Q4KifH0Hl+68qwA5YJFob9Y99YayUxxEIX4IVUZFmggj4EjOQ6vDA0FR sFqkMAAMb2z31fqBORl4KfGhJ6O0DRjbEQX0A9b/Y5d8e78oEDfZuQ0zSsSmuIz9D6 CJ7oWTX35TBixEiIhYOAioSnXsGvqrTSVNO9j2Xpk8vcSDfRZHLte+WTGavhFecco+ WjH5HFnmJQwGtKg9tbKPv/UwrUBqLvuCv+tMLqwXfMqeGw1lOwdGym+gERDy+byzWq Yw2FLjSlr0jqzTOi1xLfqlwioa636ipTcxyyASoI+h6Tz9u1Wu4xLQ35qvRZzuqEuG 3NGQw6oDP9hIQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ftDi0_vjZLv5E_O3Tmt-UhiiV-0 Cc: urn@ietf.org Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:54:14 -0000 > From: John C Klensin > > I think I understand what you are attempting to do and believe > it is constructive. However, trying to do it in terms of > definitions and other semantics in 3986 that have already been > shown to be problematic is not particularly helpful, at least > for me. Details inline below. If you have an alternative set of "definitions and other semantics", I'm probably willing to use it, but I don't recall having seen one that has the categories I'm trying to use. > > Here I am attempting to summarize a conceptual distinction > > that seems to be to be important for this discussion: There > > are classes of "identifiers" whose meanings are fixed by the > > meanings of "names" upon which they are based. > > > > (I think this aligns with the ideas Juha presented in his > > message "Rules for identifier systems" > > (http://www.ietf.org/mail-archive/web/urn/current/msg02449.htm > > l).) > > > > Terminology: I am going to use the terminology of RFC 3986: > > Unless you are going to argue against the general approach of > draft-ietf-urnbis-semantics-clarif (in which case, please do so > explicitly), please don't. The particular vocabulary of 3986 > has been, at least IMO, a significant part of the confusion and > delay in this WG and, at least through and including the Toronto > discussions, viewing 3986 purely as a syntax definition appears > useful (and possibly even necessary) to this WG's making > progress. I've read draft-ietf-urnbis-semantics-clarif (more or less), and I just peeked at it again, and I don't see where "the general approach" of that document provides a revised vocabulary for naming the various semantics for URIs. > In particular, the class of URN that acts as an indicator or > flag, such as the XMPP case that Peter has mentioned several > times, does not conform to the "identifier" definition you cite > below. If we intend to have a discussion about deprecating that > use, let's have it explicitly. If we do not, let's move on. > > > identifier - An identifier that indicates some resource(s) by > > some means. This identification may depend on an assumed > > "access" or "resolution" process, and may depend on the > > circumstances within which it is used. (A URI, in RFC 3986 > > terminology.) OK, I wasn't clear enough. In *that* definition, I take "resource" in the broadest possible meaning, including resources that are concepts. So a URI can be used as an indicator or designator for just about anything. (Of course, there is the treachery that Juha uses the term "identifier" in a very different sense.) > > Let me go through a number of examples which share certain > > features: > > I'm going to take a couple of these examples as additional > examples of why trying to reintroduce fine interpretations of > 3986 is not helpful here: > > > Example 1: Adding a "fragment" part to a URN > > > > Let us assume that is the > > name of an HTML document. (I have administrative authority > > over that part of the OID tree, so I can make it so!) And let > > us suppose that one of the tags in the document has a > > "name" attribute with value "section1". Then (given how > > "fragment" is used in HTML URLs), it would be reasonable to > > define that > > references that location within that (abstract) HTML document. > > But 3986 explicitly binds fragments to media type, so, unless > either every OID or your particular OID has a media type, that > discussion leads to a very odd place. Uh, that's true. But as I said, "Let us assume that is the name of an HTML document." So "[my] particular OID has a media type". > > Example 2: Footnoting a page > > > > Sitting in front of me is a copy of the book edition with ISBN > > 978-1-59403-698-9. That book edition has the URN > > . > > > > Suppose we define an extension to the syntax to allow > > reference to a specific page of a book denoted by an ISBN: > > . (Here, I deliberately use > > the character "^" for the extension; "^" is not valid in URIs, > > and so I cannot be thought to be advocating any particular > > syntax.) This construction would be useful for scholarly > > citations. > > Of course, your doing that as part of the URN requires that you > have an agreement with the particular publisher that all > instances of objects that they associate with the ISBN have the > same pagination properties. I don't believe that is a > requirement of the ISBN standard. Whether it is or not, I know > (as Juha has also pointed out), publisher assignments of ISBNs > are sometimes more flexible. OK; my understanding was that ISBN assignment is very rigid, and so every potential book that is an instance of ISBN 978-1-59403-698-9 will have exactly the same contents on page 7. Hmmm, I think where I got that idea is from the passage It isn't true that ISBN numbers never change. They change rarely, perhaps. A primary use of ISBN was as bookstore stock and pricing unique key. So if a book is printed with multiple color covers, they might use the same ISBN number. New printing, perhaps a minor printing flaw fixed, ditto. which I read in http://www.ietf.org/mail-archive/web/urn/current/msg02342.html. However, while that *message* was from Juha, the passage in question is from Larry Masinter. But... as this is an example of a concept, the question isn't whether it's correct in our world, but to show that there are examles of a pattern. In this case, the pattern is "The assigning of a name may cause the implicit creation of additional derived names. And the derived names may be as "good" as the original name, in terms of their stability and uniqueness." > > Example 3: Retrieving bibliographic information > > > > Suppose there is a standard for providing the metadata > > (bibliographic data) about a resource. This has been called > > "URC" (Uniform Resource Characteristics) in RFC 2169. Then we > > could standardize that > > is the identifier > > of the metadata regarding . > > (Of course, this does not address how we obtain the metadata, > > it only defines a standard identifier with which to refer to > > it.) > > I'll let you and Juha (and others who are interested) debate > whether that form is an identifier or a service request. As I'm using the term "identifier" extremely broadly (broadly enough to include SIP URIs as "identifiers"), there's no particular distinction between "identifier" and "service request". But I see Example 3 as creating an "identifier", not a "service request", as it is *not* clear from the new URI how one goes about retrieving the information that is implied. Example 4 is more of a "service request", and it is actually a "locator", as it gives you enough information to know what network operation to execute to access it: > I hope that, in the process, you will explain to the rest of us how > the distinction moves the work of the WG forward. The point that I'm trying to make is that when a name is assigned, it makes sense in many cases for the assignment to bring into existence additional "identifiers". Depending on the definition of the mechanism that defines the identifiers, their properties can vary: Some of them are "names", in the sense of having a permanant, fixed meaning. Some of them are "locators", in the sense that there is (assumed to be) a disk file or such concrete data object, and the locator defines how one executes a network operation to get a copy of the data object. Some of them are "indicators", whose meaning is broader. In practice, if such a situation exists, it seems that the practicalities aren't confusing. But adjusting the terminology to handle the general case is messier. And I think we need to beware of that, because all the instances I've seen where people suggest attaching "fragments", "queries", "service requests", etc. are of this nature: Taking a managed name and turning in into an identifier which is useful, but may not be expected to be a name at all. It doesn't help to note that adding a "service request" decoration to an item in the URN namespace does not generate a proper name -- we already know that. What we need is a terminology which isn't inconvenienced by that. But it's also a reason why the universe of URNs isn't disjoint from the universe of other URIs -- we may well want systematic ways of generating URIs from URNs. Dale From nobody Mon Sep 8 14:18:22 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609231A0398 for ; Mon, 8 Sep 2014 14:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaCVEaPT7g1s for ; Mon, 8 Sep 2014 14:18:16 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2941A0376 for ; Mon, 8 Sep 2014 14:18:07 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by resqmta-ch2-09v.sys.comcast.net with comcast id okyF1o00116LCl001lJ6ex; Mon, 08 Sep 2014 21:18:06 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta06.westchester.pa.mail.comcast.net with comcast id olJ51o00v1KKtkw3SlJ6mA; Mon, 08 Sep 2014 21:18:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s88LI5Z7027105 for ; Mon, 8 Sep 2014 17:18:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s88LI5E6027104; Mon, 8 Sep 2014 17:18:05 -0400 Date: Mon, 8 Sep 2014 17:18:05 -0400 Message-Id: <201409082118.s88LI5E6027104@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410211086; bh=/6VtMT3Gf5jMgspcJWXgZlGDa2o4P3Ib6PjUWJJ63II=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=LzFX+QcwBxUFc1r/fyGrkRx/kCcIpScO0NodvFH63PyDDx6/Dvgr00WWYw2oX80sW 6eDNzXYqiTus80+jKB/Wx+E8xZrOr5nk2wqI/aFLtOl+YDNubHpAG2iJrnseWDfTZV ujpJokVbYpq8Oz9Hp46g90BA1I6YV9eYRTN76B/tMVKFZKCW0+zyLcNoUxNSUAQKNX RvvF8/TsSWgad6F9DG7bvhP4MblZA8g9lQilF+BHRFgyml6DN+nZG6IPqwBtEQkV8V yBLoENt9XmpETK9eM7fFGGzCVTfhAi6DZdwxyDogv0gb7zTtbU44sFEDkr9PO6nH7k pkIHUUEDO046Q== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YAU1yoVMhD-wBnM8KETEt-MPENo Subject: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 21:18:18 -0000 So I tried to determine whether changing the pagination of a book (without changing the sequence of the words) requires changing the ISBN. The ISBN Users' Manual doesn't make that clear. What I've managed to find is: https://www.isbn-international.org/content/isbn-assignment "ISBN assignment" When to keep the same ISBN A reprint The original ISBN must be retained, provided the publisher remains the same and there are no changes to text or binding. http://www.isbn.org/faqs_isbn_changes "FAQs: How Changes Affect the ISBN" If typos are being corrected, is a new ISBN necessary? No. Dale From nobody Tue Sep 9 11:39:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABEF1A00EC for ; Tue, 9 Sep 2014 11:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKFP_veu4vYN for ; Tue, 9 Sep 2014 11:38:45 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552261A0019 for ; Tue, 9 Sep 2014 11:38:45 -0700 (PDT) Received: (qmail 81996 invoked from network); 9 Sep 2014 18:38:44 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Sep 2014 18:38:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f56.540f4934.k1409; i=johnl@user.iecc.com; bh=B+4x6VdEuoOzOOKhP75NcQjYwkEPp8UneZiONbcscMQ=; b=Pg8SQHwcR/dbqdkIvR8k8VdDuwQNayaGocPRONneogbedym3Mu6OFtME9Q+K2kvsL5gBKB7ijABYDFvC66+LS28GceNzrfrUkXLK6pVR0kWOZfeHpH3jq4L4Gi71hUSIwTtE/mfxMZxxzL9lwKJtlDOpyDqtO0yZRewJGoHJWyYF2DFft9wmzomeVEjguZtnaPwxJKND3g67eZ1tnVsVQdbQVoEDqpYCHTV1hO3scZ9nP462VsziMKo/YhIogcaq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f56.540f4934.k1409; olt=johnl@user.iecc.com; bh=B+4x6VdEuoOzOOKhP75NcQjYwkEPp8UneZiONbcscMQ=; b=OBqqsosUfobLwj/3xXReMZ4uM6VO2mvHyEhpid+ulQ0eXm88sWEb7MhbSJvs7CKyYahA4M4lmQoHOP0HVNlboFLdDN9wbvBAB6HyM3RQ0aP6G79XAsPulYrN8GmZ7f82TiNRKxwnkTZPUWf1suw2TyGN5dWs2HRG9h4S+0jSQByOMz6JYwaQ7NWmmcGt9KdKeKqVajKzyx4n++a6PMBimWnYF3KI+zSG0QLthM3v4hdpuEAkgHdKkRZxP98oMEsU Date: 9 Sep 2014 18:38:22 -0000 Message-ID: <20140909183822.3925.qmail@joyce.lan> From: "John Levine" To: urn@ietf.org In-Reply-To: <201409082118.s88LI5E6027104@hobgoblin.ariadne.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/U1I-AQ7JY7tqLYYDKH1snrXwGmM Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:38:46 -0000 In article <201409082118.s88LI5E6027104@hobgoblin.ariadne.com> you write: >So I tried to determine whether changing the pagination of a book >(without changing the sequence of the words) requires changing the >ISBN. The ISBN Users' Manual doesn't make that clear. I'm not surprised. ISBNs were designed for paper books, and are assigned to e-books sort of by accident. Their original and still primary use is for inventory management at booksellers. A way to think about whether two versions of a book need different ISBNs, is to ask if a reasonable person ordered one and got the other, would she believe that she got what she ordered. A rough analogy here might be trade and mass market paperbacks, which have the same text, but are paginated and typeset differently. They invariably have different ISBNs. At some point it's just a judgment call, e.g., paperbacks that have multiple versions that differ only in cover artwork. R's, John From nobody Tue Sep 9 12:17:17 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF681A0184 for ; Tue, 9 Sep 2014 12:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssjp1bi7crhA for ; Tue, 9 Sep 2014 12:17:13 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBC01A0179 for ; Tue, 9 Sep 2014 12:17:13 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id p7Ew1o0030Fqzac5B7HCKv; Tue, 09 Sep 2014 19:17:12 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id p7HC1o00C1KKtkw3U7HCTx; Tue, 09 Sep 2014 19:17:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s89JHCwc021231; Tue, 9 Sep 2014 15:17:12 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s89JHBHO021230; Tue, 9 Sep 2014 15:17:11 -0400 Date: Tue, 9 Sep 2014 15:17:11 -0400 Message-Id: <201409091917.s89JHBHO021230@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "John Levine" In-reply-to: <20140909183822.3925.qmail@joyce.lan> (johnl@taugh.com) References: <20140909183822.3925.qmail@joyce.lan> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410290232; bh=Tq2sJXs0qxZPU1xiqdW3VGJdt3bu91gQ+n+Le8vgHi4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=vUOGhRcB4xp/DVir6nRcretLia5Y23d6DlymevX+DMnkumj2gULwGfKXobM1od6Rv NSsG4JhZMnENhOXneS/4ZQOXWhhT4825l/x3Wo4+07y36F613vcz96mc1DKOz7KzQW lt8Z8IswxXMKONahzLar40Uyl6ViRg18pHRlxYp4ZLJFEGo7T4zI8AQyE5uybrvD3w uFBk6VVTJ2gNhbEEsXvBlDnm+YOmmTYjyV/j6P4lwmgnsIKNgfqm46D84GIufblNGP nqN/QAtHgRQdEkf5IM1Wd0vR8V7tXdCe6gAdjBb1rldfj+wfP4P9p4A6DSD1a6ksdf a5SIY6sLmmdKA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ynYVIoI2F0cUndhBRFWBq6aW3jU Cc: urn@ietf.org Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:17:15 -0000 > From: "John Levine" > > In article <201409082118.s88LI5E6027104@hobgoblin.ariadne.com> you write: > >So I tried to determine whether changing the pagination of a book > >(without changing the sequence of the words) requires changing the > >ISBN. The ISBN Users' Manual doesn't make that clear. > > I'm not surprised. ISBNs were designed for paper books, and are > assigned to e-books sort of by accident. Their original and still > primary use is for inventory management at booksellers. > > A way to think about whether two versions of a book need different > ISBNs, is to ask if a reasonable person ordered one and got the other, > would she believe that she got what she ordered. A rough analogy here > might be trade and mass market paperbacks, which have the same text, > but are paginated and typeset differently. They invariably have > different ISBNs. An interesting point. For a buyer that is a scholarly user, then two volumes of a modern work, with exactly the same text but different pagination, would be "different editions", because the same passage would have to be cited differently in each edition. (However, classical works usually have a canonical line numbering or some such by which citations are done, and so the pagination of the classical text into a modern edition is not critical for a scholarly user.) Dale From nobody Tue Sep 9 12:37:01 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601A31A01E6 for ; Tue, 9 Sep 2014 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ-zh_RA3PRA for ; Tue, 9 Sep 2014 12:36:51 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC81A1A0201 for ; Tue, 9 Sep 2014 12:36:36 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XRRCJ-000F4Q-B6; Tue, 09 Sep 2014 15:35:27 -0400 Date: Tue, 09 Sep 2014 15:35:22 -0400 From: John C Klensin To: "Dale R. Worley" Message-ID: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zvy4BEIkYiO5727scnSciw0Lk58 Cc: urn@ietf.org, John Levine Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:36:59 -0000 --On Tuesday, September 09, 2014 15:17 -0400 "Dale R. Worley" wrote: >> From: "John Levine" >> >> In article >> <201409082118.s88LI5E6027104@hobgoblin.ariadne.com> you write: >> > So I tried to determine whether changing the pagination of >> > a book (without changing the sequence of the words) >> > requires changing the ISBN. The ISBN Users' Manual doesn't >> > make that clear. >> >> I'm not surprised. ISBNs were designed for paper books, and >> are assigned to e-books sort of by accident. Their original >> and still primary use is for inventory management at >> booksellers. >> >> A way to think about whether two versions of a book need >> different ISBNs, is to ask if a reasonable person ordered one >> and got the other, would she believe that she got what she >> ordered. A rough analogy here might be trade and mass market >> paperbacks, which have the same text, but are paginated and >> typeset differently. They invariably have different ISBNs. > > An interesting point. For a buyer that is a scholarly user, > then two volumes of a modern work, with exactly the same text > but different pagination, would be "different editions", > because the same passage would have to be cited differently in > each edition. > > (However, classical works usually have a canonical line > numbering or some such by which citations are done, and so the > pagination of the classical text into a modern edition is not > critical for a scholarly user.) Two additional comments; Juha or others closer to the actual library and publisher community should check me on both: (1) While it has become popular in some quarters to include an ISBN in a citation, they are rarely considered a normative part of the citation. In order words, enough information about editions, etc., are expected to be in the citation to make any details like page and section numbers that are used accurate. So discussions about the relationship between ISBNs and page numbers may or may not be relevant. That is one of several reasons why a fragment that uses a page number may not be as stable as the ISBN itself. (2) The International ISBN Agency (aka the ISO 2108 [ISBN] Registration Authority) ultimately uses the same branch of the international Protocol Police that the IETF (and IANA) do. In part because, as John L. points out, ISBN are often used by booksellers for inventory and sales management, publishers have a lot of incentive to assign different numbers to versions of a book that are likely to end up with different prices. But, even if the rules were clear that a hardbound edition was to be assigned a different number than a paperback, that decision is ultimately in the hands of the publisher. Not all publishers do things the same way and, if one were to actually violate the standard in how an assignment is made, well, the International or some national ISBN agency could get in line behind us for the attentions of the Protocol Police. Otherwise, their authority basically has the same limits as ours: to try to persuade the offender that whatever they are doing is a bad idea and one that will ultimately hurt them as well as others. Sadly, none of the cases suggested above are entirely theoretical. And the Protocol Police remain somewhat elusive and, at best, ineffective as a remedy. john From nobody Wed Sep 10 12:52:37 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772221A87A8 for ; Wed, 10 Sep 2014 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzrhPORjPk0e for ; Wed, 10 Sep 2014 12:52:33 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id C035B1A876E for ; Wed, 10 Sep 2014 12:52:32 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id pW101o0060bG4ec5DXsYss; Wed, 10 Sep 2014 19:52:32 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta03.westchester.pa.mail.comcast.net with comcast id pXsW1o00z1KKtkw3PXsWkq; Wed, 10 Sep 2014 19:52:32 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8AJqTTT000923; Wed, 10 Sep 2014 15:52:29 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8AJqP9p000915; Wed, 10 Sep 2014 15:52:25 -0400 Date: Wed, 10 Sep 2014 15:52:25 -0400 Message-Id: <201409101952.s8AJqP9p000915@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> (john-ietf@jck.com) References: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410378752; bh=uIvjEzPd39NA9LCrJ4sjoKoLrWnUcv3wQcz8J5YsImU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=F20iYk6gd8o595ycUkbt0znYW2x4cPUv5XBpF2/f46pMMaNL7JhShbOyKNiXFm4kB hU6i1X7eSPXg5BBR8P/uwhu9dPjVuvMHJIaKsCYxNQ0VTyfoueWxma1rX1uAWJ4H5a U+uBWfOQDyGYb5EemW38la2+pLKlvV0U3nhhJGkGRAmILM09fOS7ZyjQLV+alZQM5F 8th1lqCmOtsKggd8G4MiehzmfDLFYRk1lTK3iY603NMHmWwqvd0UfwY/2IWhwLytGe q8tiRPhHgXK173GjGN9m+A1bR3wWtTNbinbzysROOzkJU+TkzE6CM8uNPOe/Ld1HWe j3M9Uw8mGSpBg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1cIc0twkK32-nAyOEoAzEF3WVE0 Cc: urn@ietf.org, johnl@taugh.com Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:52:35 -0000 > From: John C Klensin > But, even if the rules were clear that a hardbound edition was to be > assigned a different number than a paperback, Indeed, the rules are clear on that point: https://www.isbn-international.org/content/isbn-assignment "ISBN assignment" When to keep the same ISBN A reprint The original ISBN must be retained, provided the publisher remains the same and there are no changes to text or binding. > Not all publishers do things the same way and, if one were to > actually violate the standard in how an assignment is made, well, > the International or some national ISBN agency could get in line > behind us for the attentions of the Protocol Police. Otherwise, > their authority basically has the same limits as ours: to try to > persuade the offender that whatever they are doing is a bad idea and > one that will ultimately hurt them as well as others. That's true, but it's another instance of "If you don't follow the rules when using these constructs, you will get poor results." It's parallel to the case where if someone *uses* a URN for different meanings at different times (and for OID-based URNs in one's own OID tree, that's quite easy to do), then every element that touches the URN may misbehave (because the element may assume that the meaning of the URN is fixed over time). Dale From nobody Thu Sep 11 23:27:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331B41A0479 for ; Thu, 11 Sep 2014 23:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr7ixlcFx7lg for ; Thu, 11 Sep 2014 23:27:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF42D1A0005 for ; Thu, 11 Sep 2014 23:27:28 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AACF6509B5 for ; Fri, 12 Sep 2014 02:27:27 -0400 (EDT) Message-ID: <54129263.7080109@seantek.com> Date: Thu, 11 Sep 2014 23:27:47 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: urn@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/c8hupkCGklWGMsd2z1oEVEHgRs8 Subject: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:27:30 -0000 IETF 90 was my first URNBIS meeting. It was an...interesting experience, = so I decided to join this list. Here is what I want: I want (unbroken) cryptographic hashes and large=20 random numbers to be usable as URNs. Specifically, I want things like: urn:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 * urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** and I want identifiers that are valid in their respective namespace,=20 that represent (unbroken) cryptographic hashes or large random numbers,=20 to be valid URNs as well, without any complaints: urn:oid:2.25.324969006592305634633390616021200786553 *** * not an actual URN, yet ** actual URN ** actual URN -- this one is the aforementioned Version 4 Random UUID in = decimal in the OID arc. It's an OID-y way of saying urn:oid:uuid:f47ac10b= =2E.. I reviewed some of the e-mails over the past year. Nobody has really=20 said anything about this. However, some people tend to hem and haw when=20 they see these kinds of things without some kind of "registration=20 authority" that makes some sort of "promise" not to cause collisions. I reviewed draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09: Section 3: 2. The "consistent assignment" constraint means that an identifier within the namespace is assigned by an organization or created in= accordance with a process or algorithm that is always followed. This tells me that an organization is not required; it is sufficient to=20 define a process or algorithm (e.g., cryptographic hashing operation, or = "pick a random large number") that guarantees uniqueness within certain=20 constraints, and call it a day. So are we okay with these kinds of URNs now? If not, what can we do to=20 ensure that urnbis says that these types of things are okay? Thanks, Sean From nobody Thu Sep 11 23:29:21 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC31A017D for ; Thu, 11 Sep 2014 23:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHCNiCjPQfKZ for ; Thu, 11 Sep 2014 23:29:17 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 404451A0140 for ; Thu, 11 Sep 2014 23:29:17 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 12E4532E57F; Fri, 12 Sep 2014 15:28:32 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 47af_b8fa_0d481a1f_1207_4c8f_99ee_5d62816573cf; Fri, 12 Sep 2014 15:28:31 +0900 Received: from [100.66.8.119] (unknown [133.2.59.14]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 49F66BFF77; Fri, 12 Sep 2014 15:28:31 +0900 (JST) Message-ID: <5412928E.2070907@it.aoyama.ac.jp> Date: Fri, 12 Sep 2014 15:28:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Dale R. Worley" , John C Klensin References: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> <201409101952.s8AJqP9p000915@hobgoblin.ariadne.com> In-Reply-To: <201409101952.s8AJqP9p000915@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/g3AbWy_nu2kQ696H7K_GiS-PYp4 Cc: urn@ietf.org, johnl@taugh.com Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:29:20 -0000 On 2014/09/11 04:52, Dale R. Worley wrote: >> From: John C Klensin > >> But, even if the rules were clear that a hardbound edition was to be >> assigned a different number than a paperback, > > Indeed, the rules are clear on that point: > > https://www.isbn-international.org/content/isbn-assignment > "ISBN assignment" > > When to keep the same ISBN > > A reprint > > The original ISBN must be retained, provided the publisher > remains the same and there are no changes to text or binding. Hello Dale, What you cite only says "use the same ISBN if there are no changes to binding". What we would need, to have a rule that requires that a hardbound edition needs a different number than a paperback, is something that says "use a different ISBN if there are changes to binding". Logically, these two are related, but not the same. Regards, Martin. From nobody Thu Sep 11 23:33:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27321A0584 for ; Thu, 11 Sep 2014 23:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8LdCyY3UYE4 for ; Thu, 11 Sep 2014 23:33:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D801A0479 for ; Thu, 11 Sep 2014 23:33:56 -0700 (PDT) Received: from [192.168.2.160] ([93.217.108.65]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LhfN3-1Y64xs3o01-00mrKC; Fri, 12 Sep 2014 08:33:54 +0200 Message-ID: <541293C5.9030205@gmx.de> Date: Fri, 12 Sep 2014 08:33:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54129263.7080109@seantek.com> In-Reply-To: <54129263.7080109@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QMGh+++gO3EQpLg7WdWxIAqGtTHeVNjDWI1OElBPweCdMFc0+Nz +pLwZUv8nNe/yi/bbU4ehEkxcKBNB4I//aMS/swTW/vSXXUku7AvGokxD/kt12kFqcMAnXe vn6eUE0hKieE27Ris/j44pKn3MF3Lw+nqZqc1+VV9m2d6n7ubVaDJZSelDC61ncmRER0WF5 tWeZa4odVhNZaCcw6Hgpw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MyR6d98y1ZP-qJU-RVwiFmJ0fyM Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:33:57 -0000 On 2014-09-12 08:27, Sean Leonard wrote: > IETF 90 was my first URNBIS meeting. It was an...interesting experience, > so I decided to join this list. > > Here is what I want: I want (unbroken) cryptographic hashes and large > random numbers to be usable as URNs. Specifically, I want things like: > ... > urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** > ... RFC 6920? Best regards, Julian From nobody Fri Sep 12 00:23:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872461A049F for ; Fri, 12 Sep 2014 00:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOq8EL06fmx4 for ; Fri, 12 Sep 2014 00:23:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CF81A034F for ; Fri, 12 Sep 2014 00:23:41 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97CB350A88; Fri, 12 Sep 2014 03:23:40 -0400 (EDT) Message-ID: <54129F90.3090201@seantek.com> Date: Fri, 12 Sep 2014 00:24:00 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Julian Reschke , urn@ietf.org References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> In-Reply-To: <541293C5.9030205@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UvChK_1OHU-Yxu1fX-D260q_GiI Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 07:23:43 -0000 On 9/11/2014 11:33 PM, Julian Reschke wrote: > On 2014-09-12 08:27, Sean Leonard wrote: >> IETF 90 was my first URNBIS meeting. It was an...interesting experience, >> so I decided to join this list. >> >> Here is what I want: I want (unbroken) cryptographic hashes and large >> random numbers to be usable as URNs. Specifically, I want things like: >> ... >> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** >> ... > > RFC 6920? That's a URI. I want a URN. Specifically I want the definition of URN to be able to accommodate these kinds of naming schemes. It's not a challenge to the ni: URI. It's just being realistic: people are using mathematically deterministic processes to uniquely and persistently identify (i.e., name) things in real life already. So if URNs uniquely and persistently identify things, don't we have a match? Sean From nobody Fri Sep 12 00:54:29 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368031A065B for ; Fri, 12 Sep 2014 00:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hP8B49P6Amy for ; Fri, 12 Sep 2014 00:54:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1411B1A0659 for ; Fri, 12 Sep 2014 00:54:26 -0700 (PDT) Received: from [192.168.2.160] ([93.217.108.65]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MfjJY-1XgjJB3kiC-00N8lX; Fri, 12 Sep 2014 09:54:22 +0200 Message-ID: <5412A6A2.8090402@gmx.de> Date: Fri, 12 Sep 2014 09:54:10 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> In-Reply-To: <54129F90.3090201@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ib+wUJ0xuKbgcjaXXF6Uj18Ce8StACuF+aCNdAyUkYVvVn4f6xn 35MswgIGo1cgix86JZXKNUZfOlWFpmweq50zEOOxfG3eDoMC5V+HXJCPDSyJgbl7y/y+ueE 0z1kRusHn6VcmHdFtOLMyvyoFHbWkrk5MgCtmlQJOT4e9wijEVBE93sDCbfcGMS167GRqnc j3YP0UPlu6SWAqQsVAizw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FwBgT_0yK8BDHeW1RCXIzIew5y0 Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 07:54:27 -0000 On 2014-09-12 09:24, Sean Leonard wrote: > On 9/11/2014 11:33 PM, Julian Reschke wrote: >> On 2014-09-12 08:27, Sean Leonard wrote: >>> IETF 90 was my first URNBIS meeting. It was an...interesting experience, >>> so I decided to join this list. >>> >>> Here is what I want: I want (unbroken) cryptographic hashes and large >>> random numbers to be usable as URNs. Specifically, I want things like: >>> ... >>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** >>> ... >> >> RFC 6920? > > That's a URI. Yes. > I want a URN. Why? > Specifically I want the definition of URN to be able to accommodate > these kinds of naming schemes. Which I agree with. > It's not a challenge to the ni: URI. It's just being realistic: people > are using mathematically deterministic processes to uniquely and > persistently identify (i.e., name) things in real life already. So if > URNs uniquely and persistently identify things, don't we have a match? +1; I never got why people were upset about urn:uuid. Best regards, Julian From nobody Fri Sep 12 02:18:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2E1A06A7 for ; Fri, 12 Sep 2014 02:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7cYd4A6Dgpc for ; Fri, 12 Sep 2014 02:18:27 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0F01A069B for ; Fri, 12 Sep 2014 02:18:27 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSMzm-000LDs-6Z; Fri, 12 Sep 2014 05:18:22 -0400 Date: Fri, 12 Sep 2014 05:18:17 -0400 From: John C Klensin To: Sean Leonard Message-ID: <725D9113FA12205449854DF4@JcK-HP8200.jck.com> In-Reply-To: <54129F90.3090201@seantek.com> References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1Y-lmyXbPy45YK5RJ256O44M5tA Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:18:30 -0000 Sean, Just to help me understand, two questions... --On Friday, September 12, 2014 00:24 -0700 Sean Leonard wrote: >... >>> Here is what I want: I want (unbroken) cryptographic hashes >>> and large random numbers to be usable as URNs. Specifically, >>> I want things like: ... >>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** >>> ... Ok. I don't know if this is a proper use of the UUID namespace defined in RFC 4122. On skimming, it (and ISO/IEC 9834-8:2004) seems to require more structure than "a large random number" because of the requirement for a distinguishable time stamp (see below). But, if it is not, then I don't see anything that would prevent you from creating a new namespace, say, "uuidr", whose NSS would be a cryptographic hash or large random number. Do you see a restriction that prevents such usage (with or without a separate namespace registration? and, if so, what is it? >> RFC 6920? > > That's a URI. > > I want a URN. Why do you see the distinction as important? For, e.g., the library community, at least part of the answer is that they have been using the URN scheme, they have published specs explaining what they are doing (at least two of them in terms of very widely used ISO standards), and there are enough millions of "urn:"-scheme identifiers out there to make "why don't you just invent a new scheme type with different rules?" more a useful rhetorical exercise than a practical alternative. Now, had you said that URIs don't meet your needs but URNs might, that would reinforce at least the desire to separate syntax. But I'm not sure why you would think that was the case (if you do). > Specifically I want the definition of URN to be able to > accommodate these kinds of naming schemes. > > It's not a challenge to the ni: URI. It's just being > realistic: people are using mathematically deterministic > processes to uniquely and persistently identify (i.e., name) > things in real life already. So if URNs uniquely and > persistently identify things, don't we have a match? Again, what do you believe bars that use? Is it in 2141, 3986, or one of the documents the WG is now working on? Or are you just trying to warn against our making some change that would make such a URN namespace invalid? Going back to your original note in this thread: --On Thursday, September 11, 2014 23:27 -0700 Sean Leonard wrote: > and I want identifiers that are valid in their respective > namespace, that represent (unbroken) cryptographic hashes or > large random numbers, to be valid URNs as well, without any > complaints: > > urn:oid:2.25.324969006592305634633390616021200786553 *** It is one of several substantive points that have gotten lost in the 3986 debate, one that probably should have been on my "decisions to make" list as "do we still believe this?", but one of the reasons 3406bis is moving toward a registration model (rather than the IETF Consensus one called for in 3406) is precisely to allow easy registration and use of NIDs for externally-defined namespaces. Your example illustrates, I think, why some sort of registration procedure is desirable. While your OID usage above appears to conform to the "oid" NID definition of RFC 3061, your UUID one does not appear to conform to the "uuid" definition of RFC 4122 because the latter requires, at least, an identifiable time-stamp rather than a full-length-of-NSS random string (or hash). Reusing an existing NID with a new namespace definition is probably a bad idea, at least unless the namespace definition can be updated in a non-conflicting way. But, again, nothing should prevent creating and registering an NID that creates a URN namespace from some specific established and well-defined namespace. Indeed, IMO, we should make that as easy and painless as possible. > * not an actual URN, yet > ** actual URN > ** actual URN -- this one is the aforementioned Version 4 > Random UUID in decimal in the OID arc. It's an OID-y way of > saying urn:oid:uuid:f47ac10b... ok. See above. > I reviewed some of the e-mails over the past year. Nobody has > really said anything about this. However, some people tend to > hem and haw when they see these kinds of things without some > kind of "registration authority" that makes some sort of > "promise" not to cause collisions. I think the discussions may have been longer ago than that. One of the disadvantages of a WG that moves this slowly is that older discussions and therefore sources of conclusions get lost. > I reviewed draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09: > Section 3: > > 2. The "consistent assignment" constraint means that an > identifier > within the namespace is assigned by an organization or > created in > accordance with a process or algorithm that is always > followed. > This tells me that an organization is not required; it is > sufficient to define a process or algorithm (e.g., > cryptographic hashing operation, or "pick a random large > number") that guarantees uniqueness within certain > constraints, and call it a day. I believe that was the intent. It is also an excellent example, IMO, of why we have to be careful that the needs and perspectives of one particular cluster of URN namespaces, definitions, and user community do not define things in ways that exclude the equally-reasonable requirements of other communities. > So are we okay with these kinds of URNs now? If not, what can > we do to ensure that urnbis says that these types of things > are okay? I await a new version of 3406bis but would be surprised and disappointed if it changed the requirement you quote in a way that would exclude the sorts of generated strings you are asking for. I think they do raise another issue: 3406bis requires (and, IMO, should require) that there be documentation for a namespace. Consistent with moving away from the view that that the IETF is the center of the universe and is expert on everything, that documentation could be just a reference to an external specification, rather than an RFC. Now, suppose there is a spec somewhere that describes the "foobar" namespace and that says "no registration authority needed, no registration or assignment process needed because these NSS strings will always be unique". Should 3406bis be written to simply accept that, i.e., to allow pointing to an en external specification and, if what it specifies is not unique, assume it is Someone Else's Problem. Or should there be a requirement for an explanation of why the string is [sufficiently] unique and under what conditions (e.g., the likelihood of collisions with a cryptographic hash is not zero but is calculable) and some serious attempt to review that explanation? best, john From nobody Fri Sep 12 02:27:38 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19C71A066C for ; Fri, 12 Sep 2014 02:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0qyVWKYOZt3 for ; Fri, 12 Sep 2014 02:27:29 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513091A0643 for ; Fri, 12 Sep 2014 02:27:29 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSN8W-000LEm-FC; Fri, 12 Sep 2014 05:27:24 -0400 Date: Fri, 12 Sep 2014 05:27:19 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , "Dale R. Worley" Message-ID: <27113F7F5F7E0C7D7B6B51FC@JcK-HP8200.jck.com> In-Reply-To: <5412928E.2070907@it.aoyama.ac.jp> References: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> <201409101952.s8AJqP9p000915@hobgoblin.ariadne.com> <5412928E.2070907@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YquxYm-8jK07lryUk9ZO09fpYeQ Cc: urn@ietf.org, johnl@taugh.com Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:27:33 -0000 --On Friday, September 12, 2014 15:28 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >> A reprint >>=20 >> The original ISBN must be retained, provided the publisher >> remains the same and there are no changes to text or >> binding. >=20 > Hello Dale, >=20 > What you cite only says "use the same ISBN if there are no > changes to binding". What we would need, to have a rule that > requires that a hardbound edition needs a different number > than a paperback, is something that says "use a different ISBN > if there are changes to binding". >=20 > Logically, these two are related, but not the same. Indeed. And this is one of several properties of the ISO standard that allow a great deal of publisher discretion. My personal sense is that the distinction is a necessary one. Rather than comparing paperback with hardcover books, assume that, through the print run of a volume, the publisher switched the color of the cloth used in the hardcover binding. If they were concerned about ISBNs for inventory control, they would certainly want to change the ISBN if one of those was a "deluxe" or "special edition" cover that was to be sold at a different price. If it was merely the fact that there was a shortage of blue one week so they shifted to grey, with no other change, they might not. Trying to overspecify that sort of thing and list all of the cases in a standard just leads to rat hole-creation and more edge cases. best, john From nobody Fri Sep 12 08:34:51 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF01E1A00D1 for ; Fri, 12 Sep 2014 08:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlOKQSYGIq6P for ; Fri, 12 Sep 2014 08:34:46 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F561A00A3 for ; Fri, 12 Sep 2014 08:34:45 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5175550A87; Fri, 12 Sep 2014 11:34:42 -0400 (EDT) Message-ID: <541312A6.5090905@seantek.com> Date: Fri, 12 Sep 2014 08:35:02 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: John C Klensin References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> <725D9113FA12205449854DF4@JcK-HP8200.jck.com> In-Reply-To: <725D9113FA12205449854DF4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/hlwqEY-FwAO_7G65-XuWyl0AI88 Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:34:49 -0000 Thanks John. Let me try to respond to a subset of your On 9/12/2014 2:18 AM, John C Klensin wrote: > Sean, > > Just to help me understand, two questions... > > --On Friday, September 12, 2014 00:24 -0700 Sean Leonard > wrote: > >> ... >>>> Here is what I want: I want (unbroken) cryptographic hashes >>>> and large random numbers to be usable as URNs. Specifically, >>>> I want things like: ... >>>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** >>>> ... > Ok. I don't know if this is a proper use of the UUID namespace > defined in RFC 4122. On skimming, it (and ISO/IEC 9834-8:2004) > seems to require more structure than "a large random number" > because of the requirement for a distinguishable time stamp (see > below). But, if it is not, then I don't see anything that would > prevent you from creating a new namespace, say, "uuidr", whose > NSS would be a cryptographic hash or large random number. Do > you see a restriction that prevents such usage (with or without > a separate namespace registration? and, if so, what is it? The full repertoire of UUIDs [RFC 4122] is 128-bits. When I say the=20 "full namespace", I mean the full range of values that a UUID can take=20 on. The versions spelled out in RFC 4122 require that the bits Msb0=3D1=20 and Msb1=3D0 be fixed; however, nothing stops Microsoft Corporation (for = example) from using Msb0=3D1, Msb1=3D1, Msb2=3D0 from creating UUIDs for = its=20 own purposes. UUIDs of the RFC 4122 variant have five versions: 1 =3D time-based [including a MAC address] 2 =3D DCE Security version, with embedded POSIX UIDs the structure is not specified 3 =3D MD5 hashing 4 =3D random 5 =3D SHA-1 hashing The result is that UUIDs can easily contain: - a top-down, hierarchically assigned and registered set of identifiers=20 (based on V1 MAC address) - a set of identifiers that are based on a universal, monotonically=20 increasing counter (V1 and V2 timestamps) http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01= _01 - a set of identifiers that have local uniqueness and are extremely=20 efficient (V2): clock_seq_low and time_low fields in V2 embed the POSIX UID or GID. Chapter 5: By this embedding of local host IDs in (security-version) UUIDs, local=20 host identity information (privilege attributes) can be derived from=20 UUIDs in an especially straightforward and efficient manner (as opposed=20 to, say, going through an auxiliary ID mapping table, maintained either=20 on the local host or elsewhere). (The embedding of local host IDs is=20 specified above in the particular case of POSIX hosts; the embedding in=20 the case of non-POSIX systems is not currently specified in DCE.) Further: Concerning the/uniqueness/of security-version UUIDs, see the discussion=20 inPrivilege (Authorisation) Service=20 (PS)of=20 the double-UUID identification scheme. The point of that discussion is=20 that the security architecture of DCE depends upon the uniqueness of=20 security-version UUIDs/only within the context of a cell/; that is, only = within the context of the local RS's (persistent) datastore, and that=20 degree of uniqueness can be guaranteed by the RS itself (namely, the RS=20 maintains state in its datastore, in the sense that it can always check=20 that every UUID it maintains is different from all other UUIDs it=20 maintains). In other words, while security-version UUIDs are (like all=20 UUIDs) specified to be "globally unique in space and time", security is=20 not compromised if they are merely "locally unique per cell". This=20 statement does not relax the requirements on implementations of=20 security-version UUIDs, it is only a comment about the trust structure=20 of DCE, namely, entities (security subjects and objects) need=20 not/trust/that foreign RSs maintain globally unique UUIDs, only that=20 their own local RS maintains locally unique UUIDs. - a set of identifiers that are based on a deterministic mathematical=20 process (V3 and V5 cryptographic hashing) RFC 4122 leaves this extremely broad. Specifically, "names" are drawn=20 from some "name space"; both terms are "broadly construed". The=20 algorithm is: 1. figure out a way to generate a canonical sequence of octets in some=20 common way for all named items in the name space 2. pick algorithm (MD5 or SHA-1) 3. hash octets 4. extract and fiddle with bits - a set of identifiers that are based on large random numbers (V4) All of these amazing things are possible! All in a UUID! *** Regarding ISO/IEC 9834-8:2008: All UUIDs are valid. They are not limited to Version 1 or any other such = thing. Clause 10: 10 Validation Apart from determining if the variant bits are set correctly, and that=20 the Time value used in a time-based UUID is in the future (and therefore not yet assignable), there is no mechanism for=20 determining if a UUID is valid in any real sense, as all possible values can otherwise occur. Clause 15 specifically states how to generate V4 random UUIDs. it also sa= ys: =96 Set all the other bits of the UUID to randomly (or pseudo-randomly)=20 generated values. NOTE =96 Pseudo-random numbers may produce the same value multiple times.= =20 The use of cryptographic-quality random numbers is strongly recommended in order to reduce the=20 probability of repeated values. ISO/IEC 9834-8:2008 provides for a Registration Authority to register=20 UUIDs. 16.1.5: "The RA for UUIDs is responsible for a collision between=20 registered UUIDs, but it is not responsible for a collision between a=20 registered UUID and an unregistered UUID because it does not manage=20 unregistered UUIDs. If such a collision occurs, the semantics associated = with the registered UUID should have precedence; the semantics=20 associated with the unregistered UUID value should not be used. Thus,=20 the registration of an OID with a UUID does not ensure that the OID has=20 more uniqueness than its UUID's uniqueness. The objective of the=20 registration should be seen mainly as a means of publishing the UUID and = its contents." 16.2.2: The RA's liability is disclaimed. 16.4 and 16.5: The RA operates a registration website. ISO/IEC 9834-8:2012 changes stuff up. In the 2012 edition, "registered=20 UUID" is removed, along with Clause 16 in its entirety. Apparently=20 www.oid-info.com used to be the RA, but no longer. As of 2012, there is=20 no distinction between registered and unregistered UUIDs. They are all=20 the same. Uniqueness is guaranteed by the UUID's definition, not by the=20 act of registration. See . In conclusion: UUIDs already have crypto hash and random number=20 identifiers. (It also has locally-unique identifiers, see V2.) And=20 because it does, so do URNs. And so do OIDs. And so do URIs. There is no = need for a "uuidr" namespace because "uuid" does it already. Perhaps this gets to a broader point: when you delegate authority over=20 part of a namespace to a subsidiary authority, the subsidiary authority=20 *can do whatever it wants*. You are basically trusting the subsidiary=20 authority to follow the rules, both the rules that you made and made=20 them agree to on condition of delegating the namespace, and the rules=20 that the subsidiary authority declares itself to follow for its own=20 purposes. But the subsidiary authority can change its mind. And many times, the=20 reasons why it changes its mind are not malicious, but in response to=20 genuine technical or business needs that can be syntactically=20 accommodated by the naming scheme and will be compatible with the vast=20 majority of implementations that matter. Sean From nobody Fri Sep 12 09:04:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489BA1A06D0 for ; Fri, 12 Sep 2014 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4rFsZ_hLcgc for ; Fri, 12 Sep 2014 09:03:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386A01A02E8 for ; Fri, 12 Sep 2014 09:03:56 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5E5B050A86; Fri, 12 Sep 2014 12:03:54 -0400 (EDT) Message-ID: <5413197E.4040300@seantek.com> Date: Fri, 12 Sep 2014 09:04:14 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: John C Klensin References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> <725D9113FA12205449854DF4@JcK-HP8200.jck.com> In-Reply-To: <725D9113FA12205449854DF4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pXFAyDVZtQSu11qV32SIrjNaWpk Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 16:03:58 -0000 On 9/12/2014 2:18 AM, John C Klensin wrote: > Sean, > > Just to help me understand, two questions... > > --On Friday, September 12, 2014 00:24 -0700 Sean Leonard > wrote: [SNIP] >>> RFC 6920? >> That's a URI. >> >> I want a URN. > Why do you see the distinction as important? For, e.g., the > library community, at least part of the answer is that they have > been using the URN scheme, they have published specs explaining > what they are doing (at least two of them in terms of very > widely used ISO standards), and there are enough millions of > "urn:"-scheme identifiers out there to make "why don't you just > invent a new scheme type with different rules?" more a useful > rhetorical exercise than a practical alternative. > > Now, had you said that URIs don't meet your needs but URNs > might, that would reinforce at least the desire to separate > syntax. But I'm not sure why you would think that was the case > (if you do). Overall, the broader question for the group is not "what do or should=20 the stanadards documents say?" but rather: "why would someone make and use identifiers out of URNs, and why would=20 someone make and use identifiers out of URIs?" We're engineers...let's get right to the purpose, i.e., the utility of=20 the things. I am guided by a vague sense that URNs are for "uniquely naming things,=20 so that computer systems (connected to the Internet) can identify the=20 things, using a text-based string with no line breaks", while URIs are=20 for "naming things in a uniform way, so that computer systems (connected = to the Internet) can retrieve representations of those resources=20 (dereferencing) or perform operations on those resources, using a=20 text-based string with no line breaks". It's a pointless exercise in an SDO that has "Internet Engineering" in=20 its title to ask "what is this [made-up thing]?" as if they have some=20 utility simply because some people thought of them. The whole point is=20 to make computer systems connected to the Internet more useful. Whether we say URNs are URIs, or URNs are not URIs, or whatever, it=20 doesn't really matter. They need to have utility. So overall the point is that, as a user of URI-based implementations,=20 sometimes I want a URI's semantics, and sometimes I don't. Let's say I want to identify a discussion about a Blue Screen after=20 applying update KB2982791 to Windows 7 Home Premium 64 bit. I can say: http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update= /blue-screen-stop-0x50-after-applying-update/6da4d264-02d8-458e-89e2-a78f= e68766fd Or I could also say: {6da4d264-02d8-458e-89e2-a78fe68766fd} Or I could also say: urn:uuid:6da4d264-02d8-458e-89e2-a78fe68766fd So what am I saying (and more specifically, what are computer systems=20 connected to the Internet going to do), when I recite these magical spell= s? A web browser knows how to deal with the http one. That's because it=20 means "the web resource identified by this URI, which you can retrieve=20 using HTTP". A UUID parser...not so much. A UUID parser knows how to deal with the {} one. That is not an Internet = standard; it's just the way that UUIDs are formatted. You know one when=20 you see one. Its meaning is contextual...generally it means "the object=20 associated with this UUID", or, it means "associate this UUID with the=20 following object" (e.g., in COM interface declarations). A web=20 browser...not so much. But both UUID-aware systems and web browsers (URI implementations) know=20 how to deal with the third one. That's because it means "the /thing/=20 that is named in the UUID namespace". The flexibility here is that you=20 can use this form for Microsoft forum posts; you can use it for ABI=20 interfaces; you can use it for DCE authorization identities (aka,=20 security principals); you can use it even to identify XML namespaces.=20 And generally speaking, you can use it anywhere where you can use a URI, = including "unexpected" places like XML namespaces or parts of X.509/PKIX = certificates. It is a significant efficiency advantage that you can=20 reuse URI parsers to validate the syntax of the thing. If you give a web browser urn:uuid:6da4d264-02d8-458e-89e2-a78fe68766fd=20 and say "retrieve this" (implicitly, "retrieve this in such a way that=20 the web browser can present it nicely"), perhaps the web browser knows=20 how to resolve it...or perhaps not. But, the web browser has a *uniform=20 way* to look up the resolution mechanism (perhaps via a web browser=20 extension or via a web service) and pass that resolution mechanism a=20 well-formed thing. Sean From nobody Fri Sep 12 11:18:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74A1A710D for ; Fri, 12 Sep 2014 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh7FtyG3Htmo for ; Fri, 12 Sep 2014 11:18:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFC41A6F85 for ; Fri, 12 Sep 2014 11:18:49 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E4E25509B5; Fri, 12 Sep 2014 14:18:46 -0400 (EDT) Message-ID: <54133919.5010103@seantek.com> Date: Fri, 12 Sep 2014 11:19:05 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: John C Klensin References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> <725D9113FA12205449854DF4@JcK-HP8200.jck.com> In-Reply-To: <725D9113FA12205449854DF4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8HyopFtK8urp7vam5bCeWhuZF1Y Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 18:18:51 -0000 On 9/12/2014 2:18 AM, John C Klensin wrote: > Sean, > > Just to help me understand, two questions... > I think there were more than two questions. :) [SNIP] > >> Specifically I want the definition of URN to be able to >> accommodate these kinds of naming schemes. >> >> It's not a challenge to the ni: URI. It's just being >> realistic: people are using mathematically deterministic >> processes to uniquely and persistently identify (i.e., name) >> things in real life already. So if URNs uniquely and >> persistently identify things, don't we have a match? > Again, what do you believe bars that use? Is it in 2141, 3986, > or one of the documents the WG is now working on? Or are you > just trying to warn against our making some change that would > make such a URN namespace invalid? Over the years I have made a couple of URN proposals. One source of=20 pushback has been that when the URN uses some large random number or=20 cryptographic hash, the assignment process does not "guarantee" enough=20 uniqueness. Some respondents said that you need to have an organization=20 or an IANA registry doling out identifiers. (There were/are other=20 issues, but they are out-of-scope for this discussion.) If you compare RFC 3406 and and=20 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09, it seems clear that=20 non-human processes are permitted, so long as they provide "consistent=20 assignment"--organizations are no longer required. Compare, in=20 particular, Page 5 of RFC 3406 with Page 4 of the urnbis draft. > > Going back to your original note in this thread: > > --On Thursday, September 11, 2014 23:27 -0700 Sean Leonard > wrote: > >> and I want identifiers that are valid in their respective >> namespace, that represent (unbroken) cryptographic hashes or >> large random numbers, to be valid URNs as well, without any >> complaints: >> >> urn:oid:2.25.324969006592305634633390616021200786553 *** > It is one of several substantive points that have gotten lost in > the 3986 debate, one that probably should have been on my > "decisions to make" list as "do we still believe this?", but one > of the reasons 3406bis is moving toward a registration model > (rather than the IETF Consensus one called for in 3406) is > precisely to allow easy registration and use of NIDs for > externally-defined namespaces. [SNIP] (some of the premise of the text was incorrect--hopefully my description = of UUIDs clarifies that issue) All I'll say is that we need some standards. URNs shouldn't be a=20 free-for-all. >> This tells me that an organization is not required; it is >> sufficient to define a process or algorithm (e.g., >> cryptographic hashing operation, or "pick a random large >> number") that guarantees uniqueness within certain >> constraints, and call it a day. > I believe that was the intent. It is also an excellent > example, IMO, of why we have to be careful that the needs and > perspectives of one particular cluster of URN namespaces, > definitions, and user community do not define things in ways > that exclude the equally-reasonable requirements of other > communities. Yup. And this is a reasonable requirement, based on engineering=20 discipline and experience. [SNIP] >> Should 3406bis be written to simply accept that, >> i.e., to allow pointing to an en external specification and, if >> what it specifies is not unique, assume it is Someone Else's >> Problem. Or should there be a requirement for an explanation >> of why the string is [sufficiently] unique and under what >> conditions (e.g., the likelihood of collisions with a >> cryptographic hash is not zero but is calculable) and some >> serious attempt to review that explanation? Per the above, the metric that I advocate for is "engineering=20 reasonableness". Persistence and location-independence (specifically,=20 independent of Internet topology) are clear and desirable goals for=20 URNs, that URLs like http, ldap, gopher, ws, snmp, dns, file, and others = lack. (The commonality with the URLs mentioned is that they use //=20 syntax with an authority part; thus, they are intended to identify=20 resources accessible via the Internet using IP or DNS.) Anyway though, to get that persistence, you have to delegate the=20 allocation of names using a process. All I'm saying is that processes=20 based on natural phenomena, i.e., bounded and describable by physics,=20 mathematics, or other sciences, are just as reliable as commitments by=20 human organizations. Organizations (being made up of humans) fail;=20 organizations make mistakes; organizations change their minds. Natural=20 phenomena don't change like that--they have other problems. Sometimes=20 natural phenomena (i.e., MD5) fail spectacularly. But the commonality=20 between organizations and natural processes is that for engineering=20 purposes, they're good enough. In the case of large random numbers, as long as the address space is=20 large enough, the probability of collision is small enough, that it's=20 good enough for all practical intents and purposes. The same can be said = of cryptographic hash operations (in fact that is the engineered purpose = of a cryptographic hash operation, and what distinguishes a=20 cryptographic hash from a non-cryptographic one). Honestly, engineering reasonableness is achievable by using the=20 Specification Required standard, as long as the people ratifying the=20 standard are reasonable engineers. :-) I don't think that=20 rfc3406bis-urn-ns-reg needs to lower the bar. We just need to accept=20 that there is more than one way to generate identifiers that are unique=20 within the bounds that matter for engineered systems. Sean From nobody Fri Sep 12 11:56:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AB61A7113 for ; Fri, 12 Sep 2014 11:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEWKNesGLcgE for ; Fri, 12 Sep 2014 11:56:02 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9B51A0400 for ; Fri, 12 Sep 2014 11:56:00 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by resqmta-po-05v.sys.comcast.net with comcast id qJmz1o0021u4NiL01JvzdE; Fri, 12 Sep 2014 18:55:59 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.emeryville.ca.mail.comcast.net with comcast id qJvx1o00a1KKtkw8hJvyi3; Fri, 12 Sep 2014 18:55:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8CItuNX008266; Fri, 12 Sep 2014 14:55:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8CItu3U008265; Fri, 12 Sep 2014 14:55:56 -0400 Date: Fri, 12 Sep 2014 14:55:56 -0400 Message-Id: <201409121855.s8CItu3U008265@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Sean Leonard In-reply-to: <54129263.7080109@seantek.com> (dev+ietf@seantek.com) References: <54129263.7080109@seantek.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410548159; bh=vXfguZ1DKBegn6jzJD4cuWamSYval2X3kv6UiIVltGE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=VPYR2LxYKCGjX31yvT/1vSC6BK9LR+LeeIAgIy7tB20mYCG+vjnHwJKPqM+G0Xrz6 kYSCk7sxn3y9B3iUM6l/JtMt6kzBDyIkGndrpGaoDShW8zTVoM3WQopWy+EHivq8jk n5GJvBjQzhAHQXn8RBthNnGEPwkZDKYoViopELj6j9x0lySGzcswqzq5TrYUq3XFsQ 4pZA0WdumTykczJkm5M5c4sR+1m89R1zfBe/mmDisw5ry+mVZI//OsU3ZebVKXulDi otx15nY49675CcZYMr/vZT674nOeIEjRH4A9zG4AD+MnFxrSkOI8/hBQmSp4izx93m 0+2i0QYvi7K3w== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pZYMOj3kCD26RU4o7Y3ZtD3SoWA Cc: urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 18:56:04 -0000 > From: Sean Leonard > > Here is what I want: I want (unbroken) cryptographic hashes and large > random numbers to be usable as URNs. Specifically, I want things like: > urn:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 * > urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 ** > > and I want identifiers that are valid in their respective namespace, > that represent (unbroken) cryptographic hashes or large random numbers, > to be valid URNs as well, without any complaints: > > urn:oid:2.25.324969006592305634633390616021200786553 *** > > * not an actual URN, yet > ** actual URN > ** actual URN -- this one is the aforementioned Version 4 Random UUID in > decimal in the OID arc. It's an OID-y way of saying urn:oid:uuid:f47ac10b... I'm not perfectly clear what you want here. If you want names for cryptographic hash functions, you can use the urn:oid:... identifiers for the hash functions that are given in RFC 4055 section 3.1. For the hashes of things themselves, the ni: scheme seems suitable. Of course, they aren't in the urn: scheme, but that's a technicality, they have the properties of a name. I suppose it's an interesting question whether the ni: identifiers are truly unique, because they're only unique in practice, to a high probability. "Are you willing to bet your life on it?" As for "unbroken", something isn't a "name" if it can be deallocated. And since any algorithm might be broken in the future, you can't require only "unbroken" algorithms be used, as that condition could change. As for large random numbers, what exactly do you want? You can denote them with data: URIs of course, or you could assign them names using any of the existing mechanisms. But I don't think either of those is what you intend. Perhaps if you wrote a draft about this it would make your intention clearer. Dale From nobody Fri Sep 12 12:12:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1CF1A8547 for ; Fri, 12 Sep 2014 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZjKbP_8nkl9 for ; Fri, 12 Sep 2014 12:12:42 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA981A7113 for ; Fri, 12 Sep 2014 12:12:39 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AF896509B6 for ; Fri, 12 Sep 2014 15:12:38 -0400 (EDT) Message-ID: <541345BA.2090602@seantek.com> Date: Fri, 12 Sep 2014 12:12:58 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: urn@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/aSv1KKWsuIfz0-eVH2sWre27EvU Subject: [urn] Help me git an understanding X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 19:12:45 -0000 Sometimes I feel like I want a URL (or URI)...sometimes I feel like I want a URN. What distinguishes the two? Let's take an example that (I think) makes a lot of sense. Suppose I want to get something with git. Git defines a URI scheme : git://host.xz[:port]/path/to/repo.git/ Ok, that's great. We all understand the syntax. And, we understand that 'git:' signals the git (provisional) URI scheme, which is related to a network protocol for git. But instead of getting a repository, I want to identify (and get) a git commit. git commits are identified by SHA-1 hash. It's just the way git works. They talked about SHA-256, but rejected it. There are good reasons. It would seem to me that this makes a lot of sense: urn:git:3eb2a50d8de50c805a5a76f2193fefb8899b9bdb or, if we subdivide the hypothetical git namespace into commits and "other things", we could say: urn:git:commit:3eb2a50d8de50c805a5a76f2193fefb8899b9bdb An application wants to use this syntax because it wants to perform an operation on the commit (for example, do a diff, branch it off, print out the changes, whatever), and it doesn't want or need to specify the repo location on the Internet. But what makes urn:git: better than the git: URI scheme for this purpose? Or, can we use git: for both network resources (git://host...) and location-independent, persistent things (git:commit:....)? And in the case of the latter, what exactly is the point of URN syntax, anyway? Why don't we just say isbn:0-345-80348-5 and drop the urn: part? Sean PS The same could be said of Subversion repositories ("repos"). Every Subversion repo has a UUID. Since it's a UUID, it's persistent and location-independent. So what's the difference between, say: urn:svn:repo:642247e6-a953-0410-9eba-834bae0c6d03 and some additional syntax to the existing svn URI, namely: svn:repo:642247e6-a953-0410-9eba-834bae0c6d03 ? PPS People might say something like, "well, why don't you just use urn:uuid?" For example: urn:uuid:642247e6-a953-0410-9eba-834bae0c6d03 That's an excellent question. And the answer is that it's not the right namespace. It's true that Subversion repositories use UUIDs as identifiers. But merely saying "it's a UUID" is not sufficient; saying "this is a Subversion repository 642247e6-a953-0410-9eba-834bae0c6d03" is the semantic intent that you want to convey. In fact, it's exactly like saying http://example.com vs. ftp://example.com vs. dns://example.com. All three convey the DNS identifier "example.com". When dereferenced, the first two may get something like the same "resource". The third means something else entirely. All three have very different semantics. From nobody Fri Sep 12 12:32:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA661A876E for ; Fri, 12 Sep 2014 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIFGswNVIB3M for ; Fri, 12 Sep 2014 12:32:23 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7101A005A for ; Fri, 12 Sep 2014 12:32:23 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta13.emeryville.ca.mail.comcast.net with comcast id qKYA1o0011zF43QADKYNGk; Fri, 12 Sep 2014 19:32:22 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta24.emeryville.ca.mail.comcast.net with comcast id qKXk1o00P1KKtkw8kKXl5G; Fri, 12 Sep 2014 19:32:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8CJVi1W012079 for ; Fri, 12 Sep 2014 15:31:44 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8CJUmcD011964; Fri, 12 Sep 2014 15:30:48 -0400 Date: Fri, 12 Sep 2014 15:30:48 -0400 Message-Id: <201409121930.s8CJUmcD011964@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: =?utf-8?Q?Martin_J=2E_D=C3=BCrst?= In-reply-to: <5412928E.2070907@it.aoyama.ac.jp> (duerst@it.aoyama.ac.jp) References: <9F8177E09C0A257944B3873D@JcK-HP8200.jck.com> <201409101952.s8AJqP9p000915@hobgoblin.ariadne.com> <5412928E.2070907@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410550343; bh=5wWgF0tTO72CTWUmOfYY1wx9yEBedoo4onOjrw1EXyM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject:MIME-version:Content-type; b=GiAyICIpZKo6iHOS2METxuT6ZxJA7+BJCzZDjT/aNbWf+CTN1STC04QjqoKJLu22i jZp8/rIle4Lephz240/q9T2ojX5RgY49jStmlTubW3n88q2p3wyNauAMkA0WhXcaGo nMFbLXlx0RX0NkXSYPhFHOkpqKY12aTGN5Ql/1uRIB5tRt0+JIbtIoUNy65X91kAXS mRU6RUs4jiMaEY/3+Ph/P9qLYqQKkQnPEShPmLECAbAa5rCkhS8vOCnBiKXYOM6biY 3AP0ewbOemhy+PhXBbGdGuFHeSTjKrKE1ZdPD4ugWnIQm9GUTH2j3LTi3E6eI2qG8l hueMlbYX3PX+Q== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/9-qGVauIzwrJ15BJI1KWTjT6pg4 Cc: urn@ietf.org Subject: Re: [urn] ISBNs and pagination X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 19:32:25 -0000 > From: "Martin J. Dürst" > > A reprint > > > > The original ISBN must be retained, provided the publisher > > remains the same and there are no changes to text or binding. > What you cite only says "use the same ISBN if there are no changes to > binding". What we would need, to have a rule that requires that a > hardbound edition needs a different number than a paperback, is > something that says "use a different ISBN if there are changes to binding". > > Logically, these two are related, but not the same. That's true... What I should have quoted is this other text on the page, which is more or less the converse of what I did quote: > When to assign a new ISBN > > A change of format > > Different formats need different ISBNs in order, for example, that a > customer who wants to buy a book in hardback rather than paperback > can be confident that they will receive the correct format. Dale From nobody Fri Sep 12 12:34:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9D1A876E for ; Fri, 12 Sep 2014 12:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dz7Md-YGCoC for ; Fri, 12 Sep 2014 12:33:55 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4D91A8757 for ; Fri, 12 Sep 2014 12:33:54 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSWbQ-000M0E-3X; Fri, 12 Sep 2014 15:33:52 -0400 Date: Fri, 12 Sep 2014 15:33:47 -0400 From: John C Klensin To: Sean Leonard Message-ID: <07834ADA3935CDB73BC75D99@JcK-HP8200.jck.com> In-Reply-To: <54133919.5010103@seantek.com> References: <54129263.7080109@seantek.com> <541293C5.9030205@gmx.de> <54129F90.3090201@seantek.com> <725D9113FA12205449854DF4@JcK-HP8200.jck.com> <54133919.5010103@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/h2fV2x3GNhsxE6XTjvYJA_B4ecA Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I want URNs for hashes and large random numbers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 19:33:58 -0000 --On Friday, September 12, 2014 11:19 -0700 Sean Leonard wrote: > On 9/12/2014 2:18 AM, John C Klensin wrote: >> Sean, >> >> Just to help me understand, two questions... >> > I think there were more than two questions. :) > > [SNIP] >> >>> Specifically I want the definition of URN to be able to >>> accommodate these kinds of naming schemes. >>> >>> It's not a challenge to the ni: URI. It's just being >>> realistic: people are using mathematically deterministic >>> processes to uniquely and persistently identify (i.e., name) >>> things in real life already. So if URNs uniquely and >>> persistently identify things, don't we have a match? >> Again, what do you believe bars that use? Is it in 2141, >> 3986, or one of the documents the WG is now working on? Or >> are you just trying to warn against our making some change >> that would make such a URN namespace invalid? > > Over the years I have made a couple of URN proposals. One > source of pushback has been that when the URN uses some large > random number or cryptographic hash, the assignment process > does not "guarantee" enough uniqueness. Some respondents said > that you need to have an organization or an IANA registry > doling out identifiers. (There were/are other issues, but they > are out-of-scope for this discussion.) > > If you compare RFC 3406 and and > draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09, it seems clear > that non-human processes are permitted, so long as they > provide "consistent assignment"--organizations are no longer > required. Compare, in particular, Page 5 of RFC 3406 with Page > 4 of the urnbis draft. Speaking personally, this, in combination with -- your earlier observation that, if one delegates a namespace to a particular organization or process, one effectively loses the ability to second-guess particular entries in that namespace and -- the more general realization that registration to prevent the same label (in this case NID) from being accidentally used for two different things is a good thing even if the definitions are not of the quality one might like are the reasons some of us have been pushing for a registration process in which the IETF community could offer advice on documentation and encouragement to do things in other ways but would not have a "approve" a particular namespace, its management, or its definitions or restrictions. >> Going back to your original note in this thread: >> >> --On Thursday, September 11, 2014 23:27 -0700 Sean Leonard >> wrote: >> >>> and I want identifiers that are valid in their respective >>> namespace, that represent (unbroken) cryptographic hashes or >>> large random numbers, to be valid URNs as well, without any >>> complaints: >>> >>> urn:oid:2.25.324969006592305634633390616021200786553 *** >> It is one of several substantive points that have gotten lost >> in the 3986 debate, one that probably should have been on my >> "decisions to make" list as "do we still believe this?", but >> one of the reasons 3406bis is moving toward a registration >> model (rather than the IETF Consensus one called for in 3406) >> is precisely to allow easy registration and use of NIDs for >> externally-defined namespaces. > [SNIP] > (some of the premise of the text was incorrect--hopefully my > description of UUIDs clarifies that issue) > > All I'll say is that we need some standards. URNs shouldn't be > a free-for-all. It does clarify the issue. As to free-for-alls, I agree, but setting up the IETF community as arbiters of taste, especially when the community may have a shortage of knowledge about the particular issues associated wit the namespace but surplus of opinions on the subject, is not a solution either. My own hope, which I think is more or less consistent with 3406bis, is that we will move toward to review committee procedure that can supply advice and some persuasion about better and worse ways to handle things, but that cannot block a registration. Of course, blocking some community from inventing an NID and using it in a URN is close to impossible (and the reason I make cracks about the powerful protocol police). >... > [SNIP] >>> Should 3406bis be written to simply accept that, >>> i.e., to allow pointing to an en external specification and, >>> if what it specifies is not unique, assume it is Someone >>> Else's Problem. Or should there be a requirement for an >>> explanation of why the string is [sufficiently] unique and >>> under what conditions (e.g., the likelihood of collisions >>> with a cryptographic hash is not zero but is calculable) and >>> some serious attempt to review that explanation? > > Per the above, the metric that I advocate for is "engineering > reasonableness". Persistence and location-independence > (specifically, independent of Internet topology) are clear and > desirable goals for URNs, that URLs like http, ldap, gopher, > ws, snmp, dns, file, and others lack. (The commonality with > the URLs mentioned is that they use // syntax with an > authority part; thus, they are intended to identify resources > accessible via the Internet using IP or DNS.) Agreed, modulo my being concerned about setting up a "URN tsar", aka a single appointed expert whose authority goes to his head, rather than an advisory and consultative process. > Anyway though, to get that persistence, you have to delegate > the allocation of names using a process. All I'm saying is > that processes based on natural phenomena, i.e., bounded and > describable by physics, mathematics, or other sciences, are > just as reliable as commitments by human organizations. > Organizations (being made up of humans) fail; organizations > make mistakes; organizations change their minds. Natural > phenomena don't change like that--they have other problems. > Sometimes natural phenomena (i.e., MD5) fail spectacularly. > But the commonality between organizations and natural > processes is that for engineering purposes, they're good > enough. I hope we have learned enough by now that no one disagrees with you. Because people forget, it clearly needs to be made clear in the document. My notion of a consultative process during namespace registration would include some "are you sure you really want to do that?" questions if someone came along today with a plan about a namespace based on MD5, but, until someone discovers perfect foresight, it probably shouldn't go much future than that, e.g. to reject a contemporary hash on the grounds that it might not be good enough to guarantee uniqueness for all eternity. >... > Honestly, engineering reasonableness is achievable by using > the Specification Required standard, as long as the people > ratifying the standard are reasonable engineers. :-) I don't > think that rfc3406bis-urn-ns-reg needs to lower the bar. We > just need to accept that there is more than one way to > generate identifiers that are unique within the bounds that > matter for engineered systems. First of all, we aren't at "Specification Required" today, we are at "IETF Consensus". IMO, _that_ bar needs to be lowered for all sorts of reasons. The difficulty with a "reasonable engineers" standard is that many reasonable engineers (and reasonable other people) tend to get narrowly focused on the particular problems they are trying to solve and lose sight of other issues. That is precisely the reason the IETF tries to insist on cross-area review for standards-track documents. My preference would be that we have two procedures: (1) For something that is merely a URN encapsulation of a standard from some body whose review and approval procedures the IETF considers competent (we use the term "recognized standards developer" or something like it for Media Types), there should be a _really_ fast track. If what they want from a URN is anything beyond "embed our established identifier as the NSS" (i.e., "fragments", "queries", or "path segments"), then they have responsibility for defining those in a stable way, but I don't think we need to care what they pick, whether it is part of their base standard that establishes the name space, part of a technical report or supplemental standard, or something published somewhere else, i.e., in the RFC Series. I'd strongly prefer that such encapsulated namespace URNs conform to the syntax restrictions of 3986 and 4121bis and think we should be willing to offer advice to help that happen, but we need to recognize that we have no power to stop such a body from doing anything it decides is needed. (2) For anything else, we establish an "expert review committee" that consists of volunteer experts from the URN-experience community, ideally representing multiple perspectives. Their role would be to review applications for registration and to work with applicants to improve the quality of those registration applications and, where appropriate, to raise questions and offer advice about how that particular URN namespace might be defined and used. Part of that is close to "Specification Required", but the focus should be on getting the to best specs and best way of defining the URN that is possible under the circumstances rather than on "approval". The committee might try to talk someone out of doing something in a particular way, but should not have (or exercise except under the most unusual and egregious of circumstances) the ability to say "no, registration rejected". I think that model would meet your needs. Plus or minus fine tuning, I think it is consistent with 3406bis. It does go a little further than we have been going because it recognizes that, should some namespace-owner be determined to do something stupid (e.g., in sufficient violation of 3996 syntax to cause generic parsers problems), we can't stop them -- our only choice is ultimately whether to register what they are doing (perhaps prevent inadvertent conflicts in NID strings) or refuse to do that on the theory that our lack of implicit endorsement might accomplish something. john From nobody Mon Sep 22 07:44:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6201A1ACC for ; Mon, 22 Sep 2014 07:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPx14NIQhGir for ; Mon, 22 Sep 2014 07:44:04 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40DC1A1ABE for ; Mon, 22 Sep 2014 07:44:04 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id eu11so2966048pac.10 for ; Mon, 22 Sep 2014 07:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3yNbXWaRgiLJugYakxx9Sbe4VPTh2HOlE1D8BPKVtb4=; b=A6t5OmR7jRbtYgzojUm+M7kMJ+jMKNWy4zUhXfmiJwEOxgvt2DRyqReykxrgYh4kiQ 80M6zEB1d8fw1LSf1vPe/NQvdIt3ej2lGVe27hG1YCqsagS1oryoOm4Xx3w78lrASYtk DVPKYXacUUs5WpDRLoRlNl8zdlp90uzkCdcCXL2SO81+rR3jMasvu0K8C+raWdHYFXbH mrinci9fCPNq5mB7wovfVB6JtN5Em4bDhgTVhfxcqm7p75NbkSIx1wAUhBBTaD3+jWdf aXklRkaxmTcyptHMwIQsL+SGKhdM8v7VmsP5INdyRLDkM3NBRmCS4k0GF8L9Pnw9tZpT gYUg== X-Gm-Message-State: ALoCoQlTRN+QiJH2wt+WTXZmE8lQaic/Gn6Tlw+DE2Qe+yLC5b7eIIA2Eja3SyREcbuGcEAN14RC MIME-Version: 1.0 X-Received: by 10.68.235.105 with SMTP id ul9mr25033099pbc.3.1411397044546; Mon, 22 Sep 2014 07:44:04 -0700 (PDT) Received: by 10.66.168.12 with HTTP; Mon, 22 Sep 2014 07:44:04 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Mon, 22 Sep 2014 10:44:04 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/B-FCderHVv1-eEle8RYzPWlXo6I Subject: [urn] no session at IETF 91 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:44:06 -0000 All, I do not think we need a session at IETF 91. Of course, that does not mean we should not try to continue to make progress on this mailing list. Does anybody believe we need a working group session at the next IETF? And if so, what agenda items would you foresee? -andy