From nobody Mon Apr 4 08:34:13 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6548012D5FE; Mon, 4 Apr 2016 08:34:09 -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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 SzAbrYprfoOJ; Mon, 4 Apr 2016 08:34:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD6712D53F; Mon, 4 Apr 2016 08:34:07 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u34FNWZP043363; Mon, 4 Apr 2016 11:34:05 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 223tb0suv2-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Apr 2016 11:34:04 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u34FY3PA002109; Mon, 4 Apr 2016 11:34:03 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u34FXw0L002020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Apr 2016 11:33:59 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 4 Apr 2016 15:33:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.171]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 11:33:41 -0400 From: "STARK, BARBARA H" To: "urn@ietf.org" , "urn-nid@ietf.org" Thread-Topic: Review requested of draft-bbf-bbf-urn-01 Thread-Index: AdGOhitbQ4UWbC5zT3CFh+5H+csBzQ== Date: Mon, 4 Apr 2016 15:33:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114263C196@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.197.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604040227 Archived-At: Cc: "Benoit Claise \(bclaise@cisco.com\)" Subject: [urn] Review requested of draft-bbf-bbf-urn-01 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:34:09 -0000 Hi URN experts, A review of https://tools.ietf.org/html/draft-bbf-bbf-urn-01 would be much = appreciated. Benoit has said he will AD sponsor this draft. Just to tackle an obvious question that will come to the minds of many: Why= is BBF asking for 3 namespaces? 2 of the namespaces requested are historical namespaces that BBF has squatt= ed on for many years. Both are in wide use in many service provider environ= ments. Because of this, BBF thinks it would be best to get these 2 legitimi= zed and out of the squatter shadows.=20 For new efforts, BBF would like to use the "bbf" namespace. Thanks, Barbara From nobody Tue Apr 12 03:35:54 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75B412EAA0 for ; Tue, 12 Apr 2016 03:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 nVSRdha5-i7R for ; Tue, 12 Apr 2016 03:35: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 B7B5212EAAC for ; Tue, 12 Apr 2016 03:35:50 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1apvfg-000IrH-GS for urn@ietf.org; Tue, 12 Apr 2016 06:35:48 -0400 Date: Tue, 12 Apr 2016 06:35:43 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <09BBE9A392D75DB003F7FD42@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] r-components and resolverID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 10:35:53 -0000 Hi. I have been waiting and hoping from feedback about the r-component issues from more of the WG but, since it has not arrived and some of what arrived earlier seemed contradictory, it is time for an editorial decision. I've gone all the way through the document and thought more about the 3406 language about the relationship between resolvers and the registration process. That has led me to the conclusion that we've gotten distracted to the point that any discussion of r-components in 2141bis is premature. So, absent new arguments or instructions to the contrary from the WG or Co-chairs, the -16 version of 2141bis will: (1) Retain the distinction between r-component and q-component, including the "?+" and "?=" syntax distinctions. (2) Remove the resolverID material entirely. As a side effect, this means we don't need to debate whether resolverIDs should have the same syntax as NIDs or something else. (3) Add an explicit statement prohibiting the use of r-components until and unless they are developed, specified, and standardized. For those who want to understand the reasoning (other than lack of strong WG support for including that bit of syntax and explanation), see below. Others can safely stop reading. RFCs 2141 and 3406 very clearly make resolution mechanisms part of the namespace and expect that those mechanisms will be specified as part of the registration. That can be done by discussion, identification of a Resolution Discovery System in which the NID is registered, or presumably something else (such as a statement that URNs associated with the namespace are never resolved, i.e., are "abstract designators" in the language of 2141bis). Our earliest discussions of r-components assumed they would contain instructions _to_ the resolver, just as q-components (and f-components) contain (slightly different types of) instructions to the resource. Somehow, we drifted into the notion that the r-component might specify the resolver itself. That may or may not be a good idea, but it leads to a series of other questions, such as whether the resolver material in the registration template (see the material under "Process for identifier resolution" in Appendix A of 3406) is optional, whether a particular namespace registration can leave out resolver information and make r-components mandatory, and so on. It is, at best, unlikely that we can resolve (sic) such questions without a complete r-component design and specification. We have concluded that we aren't going to allow such a specification to get into the WG's critical path, so the baby step toward a separate resolverID comes back out. There is a separate argument that specifying a resolver as part of a URN effectively crosses the conceptual boundary to separate schemes or locators with more complex syntax, e.g., that URN:foo:example-NSS?+bar: baz should really not be a URN at all but something more like bar:foo:example-NSS/baz or barfoo:example-NSS/baz but we don't need to have that discussion at this point (either). Again, if anyone objects and has new arguments, please speak up. best, john From nobody Tue Apr 12 06:18:24 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60D012EE1C for ; Tue, 12 Apr 2016 06:18:22 -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 autolearn_force=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 NWjIVdHsg3oL for ; Tue, 12 Apr 2016 06:18:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1210112EDE9 for ; Tue, 12 Apr 2016 06:18:21 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DCCF450A85 for ; Tue, 12 Apr 2016 09:18:19 -0400 (EDT) To: urn@ietf.org References: <09BBE9A392D75DB003F7FD42@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <570CF5B6.7020705@seantek.com> Date: Tue, 12 Apr 2016 06:18:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <09BBE9A392D75DB003F7FD42@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] r-components and resolverID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:18:23 -0000 Hi John, I have feedback and comments. However, due to IETF 95 happening, I am sure that I, and other participants, have been very busy with other things. Given the speed at which this working group has progressed, another week or two would not be unreasonable. Thank you for writing out some of the possible paths forward. (Also I would like to point out, that just because I have been one of the few persistent voices in this discussion, should not discount my contributions. Quite the opposite, in fact. Especially since I am an implementer. Others are always welcome to express their own opinions. I did ask that we meet at IETF 95 so that these issues could be discussed in person with others in the room or in the virtual meeting, but that did not happen.) Regards, Sean On 4/12/2016 3:35 AM, John C Klensin wrote: > Hi. > > I have been waiting and hoping from feedback about the > r-component issues from more of the WG but, since it has not > arrived and some of what arrived earlier seemed contradictory, > it is time for an editorial decision. > > I've gone all the way through the document and thought more > about the 3406 language about the relationship between resolvers > and the registration process. That has led me to the conclusion > that we've gotten distracted to the point that any discussion of > r-components in 2141bis is premature. So, absent new arguments > or instructions to the contrary from the WG or Co-chairs, the > -16 version of 2141bis will: > > (1) Retain the distinction between r-component and q-component, > including the "?+" and "?=" syntax distinctions. > > (2) Remove the resolverID material entirely. As a side effect, > this means we don't need to debate whether resolverIDs should > have the same syntax as NIDs or something else. > > (3) Add an explicit statement prohibiting the use of > r-components until and unless they are developed, specified, and > standardized. > > For those who want to understand the reasoning (other than lack > of strong WG support for including that bit of syntax and > explanation), see below. Others can safely stop reading. > > RFCs 2141 and 3406 very clearly make resolution mechanisms part > of the namespace and expect that those mechanisms will be > specified as part of the registration. That can be done by > discussion, identification of a Resolution Discovery System in > which the NID is registered, or presumably something else (such > as a statement that URNs associated with the namespace are never > resolved, i.e., are "abstract designators" in the language of > 2141bis). > > Our earliest discussions of r-components assumed they would > contain instructions _to_ the resolver, just as q-components > (and f-components) contain (slightly different types of) > instructions to the resource. Somehow, we drifted into the > notion that the r-component might specify the resolver itself. > That may or may not be a good idea, but it leads to a series of > other questions, such as whether the resolver material in the > registration template (see the material under "Process for > identifier resolution" in Appendix A of 3406) is optional, > whether a particular namespace registration can leave out > resolver information and make r-components mandatory, and so on. > It is, at best, unlikely that we can resolve (sic) such > questions without a complete r-component design and > specification. We have concluded that we aren't going to allow > such a specification to get into the WG's critical path, so the > baby step toward a separate resolverID comes back out. > > There is a separate argument that specifying a resolver as part > of a URN effectively crosses the conceptual boundary to separate > schemes or locators with more complex syntax, e.g., that > URN:foo:example-NSS?+bar: baz > should really not be a URN at all but something more like > bar:foo:example-NSS/baz or > barfoo:example-NSS/baz > but we don't need to have that discussion at this point (either). > > Again, if anyone objects and has new arguments, please speak up. > > best, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Tue Apr 12 09:02:30 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7CA12D1BD for ; Tue, 12 Apr 2016 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 m6auOmheg6YQ for ; Tue, 12 Apr 2016 09:02:28 -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 40D1E12D79D for ; Tue, 12 Apr 2016 09:02:27 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aq0ll-000JKd-T4; Tue, 12 Apr 2016 12:02:25 -0400 Date: Tue, 12 Apr 2016 12:02:20 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <52B5491FB43E75035D096494@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] r-components and resolverID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:02:30 -0000 Sean, Your quick response is much appreciated. Several comments inline below but I want to assure you that your comments prior to today have been _very_ carefully considered. --On Tuesday, April 12, 2016 06:18 -0700 Sean Leonard wrote: > Hi John, > > I have feedback and comments. However, due to IETF 95 > happening, I am sure that I, and other participants, have been > very busy with other things. Given the speed at which this > working group has progressed, another week or two would not be > unreasonable. Normally yes (and IETF 95 is precisely the reason my note did not show up a week or two ago) but we do have another problem. ISO TC 46 ("Information and documentation") will hold their annual plenary meeting the second week in May. As the IETF Liaison to them, I owe them a report by a week from today. In each of the last several years, we've told them that we were nearly finished with a new URN standard, updated to accommodate various of the needs of their communities, to be completed well before their next meeting. To put it mildly, that tale is getting a little old. Absent other instructions from the WG or IAB, I need to go tell it again, try to keep a straight face, and probably end up having to explain why they should take us seriously this time. I have no idea how to do the latter convincingly, especially if we are back to discussing fundamentals of what URNs are for and about (see below). TC 46 is important because their national member participants tend to be the representatives of institutions that know a great deal about persistent identifiers, including a great many archival/ repository libraries and museums. TC 46 is directly responsible for a lot of the identifiers we are very concerned about and have been using as examples from almost the time we started talking about URNs, including ISBNs and ISSNs (as well as ISO 3166 country codes and having joint responsibility for the other codes that are the underpinnings of our language identifiers, etc.). During the time that we've been dithering about URNs (or, if you prefer, carefully considering the options and working toward the best standard possible), they created and adopted an International Standard for DOIs. I don't personally believe we could have stopped that, or that we should have tried to do so even if we could, but the door is closing rapidly on any possibility of what we would call an applicability statement with clear advice as to when to use DOIs and when to use URNs. If we lose the TC 46 community to the point that they start seriously considering the development of URNs, or a URN-type identifier, on their own, I think URNs are basically over. A year ago, I would have said "except for IETF documents" but the application of DOIs to RFCs can be used to make a case that URNs are a lot less important to IETF documents than we might have claimed a couple of years ago. I'm not suggesting that TC 46 is that important by itself (although, in a lot of contexts, it probably is) but remember that DOIs are being aggressively promoted for many applications, much of the Web community thinks that URNs are useless at best and, at worst, distracting syntactic sugar sprinkled on top of distinct URI schemes for many cases. The Semantic Web portion of that community thinks they are a useless distraction (or worse), and so on. There are a _lot_ of persistent, location-independent, identifiers for digital (and equivalent) objects out there. URNs could have been the unifying framework, but that window is closing (perhaps has already closed) and the sphere of applicability narrows with each major group that wanders off in some other direction or decides to adopt a standard of their own. If we can't get this done, and done soon, we should probably just stop -- I can't speak for others in the WG, although the apparently dropping level of engagement may be a clue, but I don't want to be putting energy into making epicycles work a little bit better in a post-Kepler era. > Thank you for writing out some of the possible paths forward. I think we are a little past that. See below. > (Also I would like to point out, that just because I have been > one of the few persistent voices in this discussion, should > not discount my contributions. Quite the opposite, in fact. > Especially since I am an implementer. Others are always > welcome to express their own opinions. I did ask that we meet > at IETF 95 so that these issues could be discussed in person > with others in the room or in the virtual meeting, but that > did not happen.) Take that up with the Co-chairs. I personally would not object to a virtual meeting if there were evidence that the right mix of people would attend and that it would have a useful agenda. I would have objected to a f2f meeting in Buenos Aires because the right mix of people definitely would _not_ have been there -- no Peter, no me, no one from the library or museum communities, etc. However, after a great deal of thought about how to accommodate your ideas, I think we are facing a more fundamental problem that goes directly to the importance of your views as an implementer. There is a conceptual model of what URNs are about, a model whose first versions were outlined in RFCs 1737, 2141, and 2276. It is no secret that I'm not a fan of a lot of the details of 1737 and that I believe that some of the efforts to follow up 2276 represent failed experiments. At the same time, there is a conceptual model in those documents, particular 2141 and the definition/registration mechanisms of 3406, and there are a lot of namespaces (registered and otherwise) and many millions of URNs that are consistent with that model. With the understanding that this is just my personal opinion, when we start decoupling resolution arrangements from the NID/Namespace (including indirection through a resolver-finding service as something anticipated since the beginning) and move toward selection of resolvers in the URN, perhaps using those selections as a means of determining what information is wanted, we move sufficiently outside the historical URN scheme model to really be talking about something else. I actually find that idea quite interesting. It may be a sort of midway point between "locator" and "name", countering the historical claim that the two represent a dichotomy with nothing in between. But it isn't, again IMO, a historical URN scheme type of arrangement, While I've very clearly heard "I'm an implementer and I think this is a useful approach" (it is why I tried to incorporate an anchor for your syntax into 2141bis), I haven't heard those who represent users of URNs say "we see a need for URNs to go in that direction". My request for additional voices and arguments was, and is, a desire to see if the user demand is out there. At least in its absence, I am increasingly convinced that you should be looking at a separate, name-like, URI scheme that accommodates those ideas rather than trying to pull the URN scheme in that direction. The fear that we will lose URNs entirely if we try to pin down the details of your model and then figure out if the result is still compatible with historical URNs is only part of that concern; most of the concern is about where the conceptual boundaries lie and what the current and potential user communities think they need. Again, just my opinion -- I'm still waiting for input from the WG and/or additional instructions from the co-chairs. Since -16 is a step away from your ideas (while -15 was a step toward them although not as big a step as you wanted), I'm reluctant to post it until I see that input. john From nobody Tue Apr 12 23:11:09 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3B12E28A for ; Tue, 12 Apr 2016 23:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 OcvnxTkhawJM for ; Tue, 12 Apr 2016 23:11:03 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0096.outbound.protection.outlook.com [104.47.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7622612D938 for ; Tue, 12 Apr 2016 23:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s0N9GhQIyKcG4xqlGlMgjWEXiZc1u39RmNXIh9isqmM=; b=pDq55FyLLAdDJ5sEASgx0UCOPwpRwLHh5ThH320TRC9JV+UwR/k5+IqERb+lN0vvpS0m6gEn5kjMY3Rz2XGwCDwbZADRU1U0p1uMxXSOTQOb5of59T1FKE0TThTJKODqp8Je0DyVcxQDyVIz9MSP/EBbWknaxzSaDaregnVHD4M= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1726.eurprd07.prod.outlook.com (10.166.143.22) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 06:10:58 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0466.018; Wed, 13 Apr 2016 06:10:58 +0000 From: "Hakala, Juha E" To: John C Klensin , Sean Leonard , "urn@ietf.org" Thread-Topic: [urn] r-components and resolverID Thread-Index: AQHRlNSxY7PhEnXSDEqmzm4yT8sIOJ+HVxAA Date: Wed, 13 Apr 2016 06:10:58 +0000 Message-ID: References: <52B5491FB43E75035D096494@JcK-HP8200.jck.com> In-Reply-To: <52B5491FB43E75035D096494@JcK-HP8200.jck.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: b945d429-edd4-445a-f8d5-08d3636261bf x-microsoft-exchange-diagnostics: 1; VI1PR07MB1726; 5:nMSm4FjSVeFHyoiPPoFGXuWmG7o7LU3wnagoQIqrqVwHvjCymMDWusJRCE6EgpzsJzqPVTTlmWn3y2i6gFMR875aDbPfr+r6GLFc0xyK8YV2/amnQe8jLW/vOQTFT5caeHNQIORk05TY7rXwYvdgukctz6xPBrG8vi1svlbZTM5wRnRM51PSXt6sPuxn5FVl; 24:mvslPE+YupCliilV7oEGGjFMqM+UOU+1mrlhDKPo/XRB65jLWEumZUB10P4lFZ5xBNbd56fhxSXhQ7+0Wq8eNnBnJCA97ULgNBdicCdQvVo=; 7:aE7AFPojJcvisqqwund5XbhJD7OVAj2tYg1V62OGh2ANv/guQi6l+IBWx8CRVIZMxxMaraPUwjAGprO/L1bAvFWeBTPIu0dfmQi1qI7B825JKdD4ZDrTwG9+IIK6J0Bo9au9UbFSXULct399IIgAVXd3b4BZSqiETsEzTnH0xa/87qCtQ1m9QtEVzUJTi1ZNtQX/MZkDotyI72HrQlCpdaXXAmVVX0e+9ZzpzImfY30= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1726; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1726; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(77096005)(54356999)(76176999)(74316001)(50986999)(74482002)(9686002)(102836003)(3846002)(92566002)(6116002)(19580405001)(3660700001)(586003)(345774005)(5002640100001)(189998001)(3280700002)(5004730100002)(15975445007)(2900100001)(5001770100001)(19580395003)(2950100001)(107886002)(86362001)(122556002)(5003600100002)(11100500001)(76576001)(10400500002)(1096002)(5008740100001)(106116001)(2906002)(1220700001)(31430400001)(81166005)(66066001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1726; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 06:10:58.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1726 Archived-At: Subject: Re: [urn] r-components and resolverID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 06:11:08 -0000 John; all,=20 some additional comments inline.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin > Sent: 12. huhtikuuta 2016 19:02 > To: Sean Leonard ; urn@ietf.org > Subject: Re: [urn] r-components and resolverID >=20 > Sean, >=20 > Your quick response is much appreciated. Several comments inline below > but I want to assure you that your comments prior to today have been _ver= y_ > carefully considered. >=20 > --On Tuesday, April 12, 2016 06:18 -0700 Sean Leonard > wrote: >=20 > > Hi John, > > > > I have feedback and comments. However, due to IETF 95 happening, I am > > sure that I, and other participants, have been very busy with other > > things. Given the speed at which this working group has progressed, > > another week or two would not be unreasonable. >=20 > Normally yes (and IETF 95 is precisely the reason my note did not show up= a > week or two ago) but we do have another problem. > ISO TC 46 ("Information and documentation") will hold their annual plenar= y > meeting the second week in May. As the IETF > Liaison to them, I owe them a report by a week from today. In > each of the last several years, we've told them that we were nearly finis= hed > with a new URN standard, updated to accommodate various of the needs of > their communities, to be completed well > before their next meeting. To put it mildly, that tale is > getting a little old. =20 TC 46 attendees do understand that sometimes it is difficult to complete st= andards. However, ISO directives do specify strict time limits, so things c= annot go on forever. Also there is a limit on how many drafts can be writte= n. URNBIS is by now well past anything that would be acceptable or even pos= sible in ISO standardization process. =20 Absent other instructions from the WG or IAB, I need to > go tell it again, try to keep a straight face, and probably end up having= to > explain why they should take us seriously this time. I have no idea how = to do > the latter convincingly, especially if we are back to discussing fundamen= tals > of what URNs are for and about (see below). Since many of the attendees will represent organizations or interest groups= which use persistent identifiers (national libraries, national archives, s= cientific publishers) possible failure to revise URN standards is a concern= especially to those who are using URNs, but also to the PID community as a= whole. There is a shared interest to make PIDs smarter, and URN could prov= ide an example of how that can be done. =20 >=20 > TC 46 is important because their national member participants tend to be > the representatives of institutions that know a great deal about persiste= nt > identifiers, including a great many archival/ repository libraries and > museums. TC 46 is directly responsible for a lot of the identifiers we a= re > very concerned about and have been using as examples from almost the > time we started talking about URNs, including ISBNs and ISSNs (as well as > ISO 3166 country codes and having joint responsibility for the other code= s > that are the underpinnings of our language identifiers, etc.). During th= e time > that we've been dithering about URNs (or, if you prefer, carefully > considering the options and working toward the best standard possible), > they created and adopted an International Standard for DOIs. I don't > personally believe we could have stopped that, or that we should have tri= ed > to do so even if we could, but the door is closing rapidly on any possibi= lity of > what we would call an applicability statement with clear advice as to whe= n > to use DOIs and when to use URNs. DOI standardization in ISO predated the URNBIS work. DOI is based on Handle= system (see RFC 3650), so most of the technical aspects in the standardiza= tion process were fixed. We did spend a lot of time discussing potential ov= erlap between DOIs and other ISO standard identifiers. Since DOI can in the= ory be used to identify any object, it may replace for instance ISBN in the= identification of books. The standard contains some prose to prevent this = kind of misuse of DOIs. In practice, using DOIs for identification of "wron= g" objects has not been an issue. =20 > If we lose the TC 46 community to the point that they start seriously > considering the development of URNs, or a URN-type identifier, on their > own, I think URNs are basically over. A year ago, I would have said "exc= ept > for IETF documents" but the application of DOIs to RFCs can be used to > make a case that URNs are a lot less important to IETF documents than we > might have claimed a couple of years ago. I'm not suggesting that TC 46 = is > that important by itself (although, in a lot of contexts, it probably is)= but > remember that DOIs are being aggressively promoted for many applications, > much of the Web community thinks that URNs are useless at best and, at > worst, distracting syntactic sugar sprinkled on top of distinct URI schem= es > for many cases. The Semantic Web portion of that community thinks > they are a useless distraction (or worse), and so on. There > are a _lot_ of persistent, location-independent, identifiers for digital = (and > equivalent) objects out there. URNs could have been the unifying > framework, but that window is closing (perhaps has already closed) and th= e > sphere of applicability narrows with each major group that wanders off in > some other direction or decides to adopt a standard of their own. IETF has already "lost" Handles to ITU. ARK has not made it beyond Internet= draft, and right now it does not seem likely that it will be published eve= n as an informational RFC. And revising URN has definitely been far more di= fficult than I ever thought it would be.=20 Persistent identifiers are used a lot. For instance, there were about five = billion DOI resolutions in 2015. In the same time we know - based on e.g. r= esearch by Herbert Van de Sompel and others, see http://dx.doi.org/10.1371/= journal.pone.0115253 - that URLs are not nearly as cool as some people thi= nk they are. There is definitely a need for persistent identifiers which ar= e better managed and offer richer functionality than plain vanilla URLs. Wh= ether IETF wants to have any role in this in the future must be considered = carefully. It seems to me that at least some members in URNBIS tend to forg= et the strategic importance for IETF of being involved with PID standardiza= tion. URNBIS has spent a lot of time discussing technical details which cou= ld have been ignored - and certainly similar things have been ignored in st= andardization of other PIDs.=20 >=20 > If we can't get this done, and done soon, we should probably just stop --= I > can't speak for others in the WG, although the apparently dropping level = of > engagement may be a clue, but I don't want to be putting energy into > making epicycles work a little bit better in a post-Kepler era. If IETF drops URNs, that should be done gracefully. TC 46/SC 9, which deals= with identifiers, can complete the URN syntax revision, but this should be= agreed between IETF and ISO. Having said this, I still hope that URNBIS fi= nishes the documents. Then they could be standardized via fast track proces= s in ISO.=20 Technical issues URNBIS has been battling with are unlikely to become a pro= blem in a more practically oriented TC 46. DOI standard and its underlying = Handle specification are - from URI syntax point of view - in some ways pro= blematic documents, but this has not prevented Handle and DOI from becoming= very popular and useful PID systems.=20 > > Thank you for writing out some of the possible paths forward. >=20 > I think we are a little past that. See below. >=20 > > (Also I would like to point out, that just because I have been one of > > the few persistent voices in this discussion, should not discount my > > contributions. Quite the opposite, in fact. > > Especially since I am an implementer. Others are always welcome to > > express their own opinions. I did ask that we meet at IETF 95 so that > > these issues could be discussed in person with others in the room or > > in the virtual meeting, but that did not happen.) >=20 > Take that up with the Co-chairs. I personally would not object to a virt= ual > meeting if there were evidence that the right mix of people would attend > and that it would have a useful agenda. > I would have objected to a f2f meeting in Buenos Aires because the right > mix of people definitely would _not_ have been there > -- no Peter, no me, no one from the library or museum communities, etc. It is a pity that most URN users have been just lurking on this list. Some = of my colleagues who work with URN assignment in practice got frustrated lo= ng time ago due to the theoretical nature of much of the discussion. Few co= ntributions seemed to relate directly or even indirectly to what they were = doing with URNs and what they wanted to do with them in the future. =20 > However, after a great deal of thought about how to accommodate your > ideas, I think we are facing a more fundamental problem that goes direct= ly > to the importance of your views as an > implementer. There is a conceptual model of what URNs are > about, a model whose first versions were outlined in RFCs 1737, 2141, and > 2276. It is no secret that I'm not a fan of a lot of the details of 1737= and > that I believe that some of the efforts to follow up 2276 represent faile= d > experiments. At the same time, there is a conceptual model in those > documents, particular > 2141 and the definition/registration mechanisms of 3406, and there are a > lot of namespaces (registered and otherwise) and many millions of URNs > that are consistent with that model. >=20 > With the understanding that this is just my personal opinion, when we sta= rt > decoupling resolution arrangements from the NID/Namespace (including > indirection through a resolver-finding service as something anticipated s= ince > the beginning) and move toward selection of resolvers in the URN, perhaps > using those selections as a means of determining what information is > wanted, we move sufficiently outside the historical URN scheme model to > really be talking about something else. I actually find that idea quite > interesting. =20 Me too. The model RFC 2276 is too narrow, and does not take into account th= at the same object may be available from different services on different te= rms.=20 So this section from RFC 2276:=20 "we assume that the publisher of a resource can choose resolver services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolver service for that delegated namespace." should be expanded in such a way that at least in some (large, standard bas= ed) namespaces it has to be possible to choose resolution service in the it= em level. For instance, there can be three items (copies) of an electronic = PhD dissertation available in the Web: one in the national library's legal = deposit system, another in the digital asset management system of the unive= rsity (available for free) and one in publisher's web site (available for f= ee). All these copies of the book have the same ISBN, so the first part of = the resolution process for the user is to decide which copy / target system= is the preferred one. There are various ways to implement this; for instan= ce, if the identified resource is available on multiple target systems, the= resolver may be able to check from an external service which copy / copies= the user is entitled to access and use. Libraries have already implemented= this kind of services. So whether we must change the URN syntax to enable = this kind of enrichment of the resolution process depends on the technical = infrastructure available. =20 It may be a sort of midway point between "locator" and > "name", countering the historical claim that the two represent a dichotom= y > with nothing in between. But it isn't, again IMO, a historical URN schem= e > type of arrangement, While I've very clearly heard "I'm an implementer a= nd > I think this is a useful approach" (it is why I tried to incorporate an a= nchor for > your syntax into 2141bis), I haven't heard those who represent users of > URNs say "we see a need for > URNs to go in that direction". My request for additional > voices and arguments was, and is, a desire to see if the user > demand is out there. At least in its absence, I am > increasingly convinced that you should be looking at a separate, name-lik= e, > URI scheme that accommodates those ideas rather than trying to pull the > URN scheme in that direction. The fear that we will lose URNs entirely i= f > we try to pin down the details of your model and then figure out if the r= esult > is still compatible with historical URNs is only part of that concern; mo= st of > the concern is about where the conceptual boundaries lie and what the > current and potential user communities think they need. Putting my TC 46 hat on, my recommendation is to complete the URN syntax st= andardization as fast as possible, and not to try to add any major features= into it anymore. PIDs and PID resolvers need to become smarter in synch wi= th the development of the underlying technical infrastructure such as appli= cations used by libraries, archives and museums. There is no way to create = now the final version of URN syntax which will be sufficient for a very lon= g time. Instead, IETF (or whichever organization is responsible of the syst= em) needs to be prepared to revise URN specifications often enough, and hop= efully next time around the process will not last for years and years. All the best,=20 Juha =20 > Again, just my opinion -- I'm still waiting for input from the > WG and/or additional instructions from the co-chairs. Since > -16 is a step away from your ideas (while -15 was a step toward them > although not as big a step as you wanted), I'm reluctant to post it until= I see > that input. >=20 > john >=20 >=20 >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Apr 13 08:49:29 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52012B04A for ; Wed, 13 Apr 2016 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EJbWj8jpRS3G for ; Wed, 13 Apr 2016 08:49:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 273CB12B008 for ; Wed, 13 Apr 2016 08:49:22 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 73554E8206; Wed, 13 Apr 2016 09:57:31 -0600 (MDT) To: "Hakala, Juha E" , John C Klensin , Sean Leonard , "urn@ietf.org" References: <52B5491FB43E75035D096494@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: <570E6A7F.5040306@stpeter.im> Date: Wed, 13 Apr 2016 09:49:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] r-components and resolverID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:49:26 -0000 On 4/13/16 12:10 AM, Hakala, Juha E wrote: > John; all, > > some additional comments inline. Juha, thanks for your input. I agree on all points. Let's finish this work soon (which implies not expanding the scope at this time). Peter > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin >> Sent: 12. huhtikuuta 2016 19:02 >> To: Sean Leonard ; urn@ietf.org >> Subject: Re: [urn] r-components and resolverID >> >> Sean, >> >> Your quick response is much appreciated. Several comments inline below >> but I want to assure you that your comments prior to today have been _very_ >> carefully considered. >> >> --On Tuesday, April 12, 2016 06:18 -0700 Sean Leonard >> wrote: >> >>> Hi John, >>> >>> I have feedback and comments. However, due to IETF 95 happening, I am >>> sure that I, and other participants, have been very busy with other >>> things. Given the speed at which this working group has progressed, >>> another week or two would not be unreasonable. >> >> Normally yes (and IETF 95 is precisely the reason my note did not show up a >> week or two ago) but we do have another problem. >> ISO TC 46 ("Information and documentation") will hold their annual plenary >> meeting the second week in May. As the IETF >> Liaison to them, I owe them a report by a week from today. In >> each of the last several years, we've told them that we were nearly finished >> with a new URN standard, updated to accommodate various of the needs of >> their communities, to be completed well >> before their next meeting. To put it mildly, that tale is >> getting a little old. > > TC 46 attendees do understand that sometimes it is difficult to complete standards. However, ISO directives do specify strict time limits, so things cannot go on forever. Also there is a limit on how many drafts can be written. URNBIS is by now well past anything that would be acceptable or even possible in ISO standardization process. > > Absent other instructions from the WG or IAB, I need to >> go tell it again, try to keep a straight face, and probably end up having to >> explain why they should take us seriously this time. I have no idea how to do >> the latter convincingly, especially if we are back to discussing fundamentals >> of what URNs are for and about (see below). > > Since many of the attendees will represent organizations or interest groups which use persistent identifiers (national libraries, national archives, scientific publishers) possible failure to revise URN standards is a concern especially to those who are using URNs, but also to the PID community as a whole. There is a shared interest to make PIDs smarter, and URN could provide an example of how that can be done. > >> >> TC 46 is important because their national member participants tend to be >> the representatives of institutions that know a great deal about persistent >> identifiers, including a great many archival/ repository libraries and >> museums. TC 46 is directly responsible for a lot of the identifiers we are >> very concerned about and have been using as examples from almost the >> time we started talking about URNs, including ISBNs and ISSNs (as well as >> ISO 3166 country codes and having joint responsibility for the other codes >> that are the underpinnings of our language identifiers, etc.). During the time >> that we've been dithering about URNs (or, if you prefer, carefully >> considering the options and working toward the best standard possible), >> they created and adopted an International Standard for DOIs. I don't >> personally believe we could have stopped that, or that we should have tried >> to do so even if we could, but the door is closing rapidly on any possibility of >> what we would call an applicability statement with clear advice as to when >> to use DOIs and when to use URNs. > > DOI standardization in ISO predated the URNBIS work. DOI is based on Handle system (see RFC 3650), so most of the technical aspects in the standardization process were fixed. We did spend a lot of time discussing potential overlap between DOIs and other ISO standard identifiers. Since DOI can in theory be used to identify any object, it may replace for instance ISBN in the identification of books. The standard contains some prose to prevent this kind of misuse of DOIs. In practice, using DOIs for identification of "wrong" objects has not been an issue. > >> If we lose the TC 46 community to the point that they start seriously >> considering the development of URNs, or a URN-type identifier, on their >> own, I think URNs are basically over. A year ago, I would have said "except >> for IETF documents" but the application of DOIs to RFCs can be used to >> make a case that URNs are a lot less important to IETF documents than we >> might have claimed a couple of years ago. I'm not suggesting that TC 46 is >> that important by itself (although, in a lot of contexts, it probably is) but >> remember that DOIs are being aggressively promoted for many applications, >> much of the Web community thinks that URNs are useless at best and, at >> worst, distracting syntactic sugar sprinkled on top of distinct URI schemes >> for many cases. The Semantic Web portion of that community thinks >> they are a useless distraction (or worse), and so on. There >> are a _lot_ of persistent, location-independent, identifiers for digital (and >> equivalent) objects out there. URNs could have been the unifying >> framework, but that window is closing (perhaps has already closed) and the >> sphere of applicability narrows with each major group that wanders off in >> some other direction or decides to adopt a standard of their own. > > IETF has already "lost" Handles to ITU. ARK has not made it beyond Internet draft, and right now it does not seem likely that it will be published even as an informational RFC. And revising URN has definitely been far more difficult than I ever thought it would be. > > Persistent identifiers are used a lot. For instance, there were about five billion DOI resolutions in 2015. In the same time we know - based on e.g. research by Herbert Van de Sompel and others, see http://dx.doi.org/10.1371/journal.pone.0115253 - that URLs are not nearly as cool as some people think they are. There is definitely a need for persistent identifiers which are better managed and offer richer functionality than plain vanilla URLs. Whether IETF wants to have any role in this in the future must be considered carefully. It seems to me that at least some members in URNBIS tend to forget the strategic importance for IETF of being involved with PID standardization. URNBIS has spent a lot of time discussing technical details which could have been ignored - and certainly similar things have been ignored in standardization of other PIDs. >> >> If we can't get this done, and done soon, we should probably just stop -- I >> can't speak for others in the WG, although the apparently dropping level of >> engagement may be a clue, but I don't want to be putting energy into >> making epicycles work a little bit better in a post-Kepler era. > > If IETF drops URNs, that should be done gracefully. TC 46/SC 9, which deals with identifiers, can complete the URN syntax revision, but this should be agreed between IETF and ISO. Having said this, I still hope that URNBIS finishes the documents. Then they could be standardized via fast track process in ISO. > > Technical issues URNBIS has been battling with are unlikely to become a problem in a more practically oriented TC 46. DOI standard and its underlying Handle specification are - from URI syntax point of view - in some ways problematic documents, but this has not prevented Handle and DOI from becoming very popular and useful PID systems. > >>> Thank you for writing out some of the possible paths forward. >> >> I think we are a little past that. See below. >> >>> (Also I would like to point out, that just because I have been one of >>> the few persistent voices in this discussion, should not discount my >>> contributions. Quite the opposite, in fact. >>> Especially since I am an implementer. Others are always welcome to >>> express their own opinions. I did ask that we meet at IETF 95 so that >>> these issues could be discussed in person with others in the room or >>> in the virtual meeting, but that did not happen.) >> >> Take that up with the Co-chairs. I personally would not object to a virtual >> meeting if there were evidence that the right mix of people would attend >> and that it would have a useful agenda. >> I would have objected to a f2f meeting in Buenos Aires because the right >> mix of people definitely would _not_ have been there >> -- no Peter, no me, no one from the library or museum communities, etc. > > It is a pity that most URN users have been just lurking on this list. Some of my colleagues who work with URN assignment in practice got frustrated long time ago due to the theoretical nature of much of the discussion. Few contributions seemed to relate directly or even indirectly to what they were doing with URNs and what they wanted to do with them in the future. > >> However, after a great deal of thought about how to accommodate your >> ideas, I think we are facing a more fundamental problem that goes directly >> to the importance of your views as an >> implementer. There is a conceptual model of what URNs are >> about, a model whose first versions were outlined in RFCs 1737, 2141, and >> 2276. It is no secret that I'm not a fan of a lot of the details of 1737 and >> that I believe that some of the efforts to follow up 2276 represent failed >> experiments. At the same time, there is a conceptual model in those >> documents, particular >> 2141 and the definition/registration mechanisms of 3406, and there are a >> lot of namespaces (registered and otherwise) and many millions of URNs >> that are consistent with that model. >> >> With the understanding that this is just my personal opinion, when we start >> decoupling resolution arrangements from the NID/Namespace (including >> indirection through a resolver-finding service as something anticipated since >> the beginning) and move toward selection of resolvers in the URN, perhaps >> using those selections as a means of determining what information is >> wanted, we move sufficiently outside the historical URN scheme model to >> really be talking about something else. I actually find that idea quite >> interesting. > > Me too. The model RFC 2276 is too narrow, and does not take into account that the same object may be available from different services on different terms. > > So this section from RFC 2276: > > "we assume that the publisher of a resource can choose resolver services, > independently of choices made by others. At any given time, the > owner of a namespace may choose a particular URN resolver service for > that delegated namespace." > > should be expanded in such a way that at least in some (large, standard based) namespaces it has to be possible to choose resolution service in the item level. For instance, there can be three items (copies) of an electronic PhD dissertation available in the Web: one in the national library's legal deposit system, another in the digital asset management system of the university (available for free) and one in publisher's web site (available for fee). All these copies of the book have the same ISBN, so the first part of the resolution process for the user is to decide which copy / target system is the preferred one. There are various ways to implement this; for instance, if the identified resource is available on multiple target systems, the resolver may be able to check from an external service which copy / copies the user is entitled to access and use. Libraries have already implemented this kind of services. So whether we must change the URN syntax to enable this kind of enrichmen t > of the resolution process depends on the technical infrastructure available. > > It may be a sort of midway point between "locator" and >> "name", countering the historical claim that the two represent a dichotomy >> with nothing in between. But it isn't, again IMO, a historical URN scheme >> type of arrangement, While I've very clearly heard "I'm an implementer and >> I think this is a useful approach" (it is why I tried to incorporate an anchor for >> your syntax into 2141bis), I haven't heard those who represent users of >> URNs say "we see a need for >> URNs to go in that direction". My request for additional >> voices and arguments was, and is, a desire to see if the user >> demand is out there. At least in its absence, I am >> increasingly convinced that you should be looking at a separate, name-like, >> URI scheme that accommodates those ideas rather than trying to pull the >> URN scheme in that direction. The fear that we will lose URNs entirely if >> we try to pin down the details of your model and then figure out if the result >> is still compatible with historical URNs is only part of that concern; most of >> the concern is about where the conceptual boundaries lie and what the >> current and potential user communities think they need. > > Putting my TC 46 hat on, my recommendation is to complete the URN syntax standardization as fast as possible, and not to try to add any major features into it anymore. PIDs and PID resolvers need to become smarter in synch with the development of the underlying technical infrastructure such as applications used by libraries, archives and museums. There is no way to create now the final version of URN syntax which will be sufficient for a very long time. Instead, IETF (or whichever organization is responsible of the system) needs to be prepared to revise URN specifications often enough, and hopefully next time around the process will not last for years and years. > > All the best, > > Juha > >> Again, just my opinion -- I'm still waiting for input from the >> WG and/or additional instructions from the co-chairs. Since >> -16 is a step away from your ideas (while -15 was a step toward them >> although not as big a step as you wanted), I'm reluctant to post it until I see >> that input. >> >> john >> From nobody Fri Apr 15 08:09:57 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A81412D6E7 for ; Fri, 15 Apr 2016 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h5zOGnxgfulQ for ; Fri, 15 Apr 2016 08:09:55 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA89612D1B6 for ; Fri, 15 Apr 2016 08:09:54 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so139418063ywa.0 for ; Fri, 15 Apr 2016 08:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=kTsFPj3WtsnAqHU0NEfdfPAYxSzviXEw1Lg6+V8j280=; b=nyxecHIpLhdBP1MBrJCwvjHayqRCHNAfaiu2ekSj8Igug34sCuVbwMwjFqchkpzJ4/ NzzelAu7g5uY7Ew28uGhPj3Wi1hOHYToTpPfs0DtIUZEEQ6hg9ppZU2w9zc9TBkV/+yV NlTfxgTABXUGjOfnki642ljaFUNaWLGpkBO1j0se06O6yDOeGuP09uk5RapA/tJR35S+ 49AswlfWdKnIMtiO+IFMeV0TwiDEFv6Fzh5uvLpH0Yyx5NSQ81cYoRk91mpsxLIDQMex L0Uhy0GtvM6QNzUgZsn1PI+vqxGRn8zNN8I+wGYQVZSKVsNVGFYoeApkkaJZbE89NQ8P wcxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=kTsFPj3WtsnAqHU0NEfdfPAYxSzviXEw1Lg6+V8j280=; b=O+7W7Hq7eQeXIihVpfFykNJi227F388mcN2PyksbHL8K7G075LFnKx/U6E+OARwv7N VgjrfZJ+9PPDQcxehlL6wbXog3IIWpByOY1sIFZBGyMikMaOSfc86Y3y6E7CO77I8OzP CcgkztBK/29JOxFPTg+PVHliWACVFJDZ82kFRrc3AcvECiYRE6Mrxi194iVGX9tVUoax XCWDghAqR1GrvdsiNAkR9qxEewnzFEYqbpvdn0mSwgOgGHWWu1jgOLfArZbSZePQbsW3 80uoJlXkkmczhd1yaAmNvLrjIsrsMk5LpbKqFvcAe5zs0WYp8v7W8p1T0SaDk1+xoZeR SANw== X-Gm-Message-State: AOPr4FVdU4U5ghD+aTQSkiDJ2Ug4XPEIeUavB3qsKlF9+UVt+K1SnTuTw5SMn+WSOiq9wNH4CuAu9TA4oiYeFQ== MIME-Version: 1.0 X-Received: by 10.37.215.84 with SMTP id o81mr1782934ybg.134.1460732994128; Fri, 15 Apr 2016 08:09:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.13.67 with HTTP; Fri, 15 Apr 2016 08:09:53 -0700 (PDT) Date: Fri, 15 Apr 2016 11:09:53 -0400 X-Google-Sender-Auth: ZPwSE22uUmdZXlJsepNKAiZ7s6c Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] urnbis progress X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 15:09:56 -0000 I had hoped that with the updated drafts we'd have reviews and discussion, and we could get to final resolution on the documents. There's been some of that (thanks to those who did), but not enough. We need more. The authors will be posting another revision soon, and I'd like to see some strong review of them with an eye toward convergence on updated specs that we need, and with issues resolved in a way we can live with, even if it wouldn't be the first choice for any particular one of us. Specific text suggestions, please, whenever you can. As I said before, we need to leave behind some long-debated issues -- a big one of those is resolution of URNs. That may be important to some, but it really is a separate effort, with one or more separate documents, and needs to stay out of scope for this current work. Without putting specific dates on specific things, I'll say that I'd really like to see all this resolved and the documents sent to the IESG within the next couple of months. Can we all do our best to make that happen before, say, the Berlin meeting? Barry From nobody Sun Apr 17 14:51:22 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA312D8AB; Sun, 17 Apr 2016 14:51:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160417215118.28744.21053.idtracker@ietfa.amsl.com> Date: Sun, 17 Apr 2016 14:51:18 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-16.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 21:51:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-16.txt Pages : 38 Date : 2016-04-17 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 17 20:00:48 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65EC12D6D4 for ; Sun, 17 Apr 2016 20:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 J0I7wX0nLDHN for ; Sun, 17 Apr 2016 20:00:46 -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 5C70212D69A for ; Sun, 17 Apr 2016 20:00:46 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1arzQa-000HDR-Fv for urn@ietf.org; Sun, 17 Apr 2016 23:00:44 -0400 Date: Sun, 17 Apr 2016 23:00:39 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <8E2E925C5A90E22F4B1BF36D@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 03:00:48 -0000 Hi. I've posted -ietf-urnbis-rfc2141bis-urn-16. The major changes are summarized in the Change Log (Appendix F.8) but the following (in no particular order) may be worth special note by the WG. (1) Versions up to and including -15 contained a good deal of text that was incremental from RFC 2141 and explained on that basis. This version removes that text, making the document much more of the standalone definition of URNs that the WG is expected to produce. The explanations of differences and increments have been moved to the "changes from..." appendices (Appendix B and C) and some additional explanation has been added to an expanded Introduction. (2) Section 2 ("URN Syntax") has been edited to remove material that was redundant with other parts of that section or the document. (3) Following up the comments on the list, the "resolverID" material has been removed, the explanation of r-component reduced to a discussion of the general principle, and a statement added to indicate that r-components are reserved for future standardization. (4) There were a few places where the text assumed knowledge that, given the 3986 model of URIs, a URN processor might well not have, with whether or not a particular target resource would accept a query as one example. Those statements have been revised. The intent of the current language is that, if the URN resolves to a URL, the q-component and f-component are to be copied to the URL. If the URN is an abstract designator or resolves to something other than a URL, the behavior or those two components is not defined by the spec -- there just isn't a lot we can say. If the language does not make that approach adequately clear, or if you think another approach would be more appropriate, please explain why and, if possible, suggest alternate text. (5) As I mentioned in an earlier note, RFC 3506 contains a subsection titled "process for identifier resolution". I believe that Section 6.4.6 and the registration template of 2141bis-16 adequately captures what was there, while removing the specific reference to DDDS. The model in the current draft is intended to be that, if the URN and namespace are not for an abstract designator (i.e., the URN is expected to "resolve" somehow, independent of what "resolve" means (see the discussion in Sections 1.1 and 1.2 for that topid) then the registration template and process are expected to either: (i) Specify the resolution tools and/or procedure and any additional information needed to utilize it or them. (ii) Specify a resolution discovery system (RDS) that will provide the needed information and any information needed to call on and use that system. As above, if that is not clear from the text in -16 or if you disagree with the approach and have something new to say on the subject (please see ; cent note as well as my prior one), please speak up soon and, if you simply have a problem with the explanation, supply recommended text if possible. As mentioned in an earlier note, I think there is a role for a model in which a persistent object or resource identifier is passed to an explicitly-specified resolution service, but that is not a URN as we have so far known it, (6) Finally, there is a question about component syntax. Our current hypothesis is that we need only q-components, f-components, and r-components, even though we don't have a clear understanding of the latter. The q-components and r-components are introduced by "?=" and "?+" only. Each one (along with "#") terminates the other, but all other sequences consisting on "?" followed by something else are normal -- they can appear inside q-component or r-component strings, or elsewhere, without any special interpretation (or requiring quoting). If we are sure that we won't need anything else, that is fine. However, if we were somehow concerned that we might need additional component types and corresponding delimiters, this is probably our last chance to make provision for that without having to make major incompatible changes. Anyone want to make a strong case for making such reservations? Of course, I may have missed other issues, but those are the ones I'm aware of at present. I think that, if the WG can check them and either agree they are ok or focus on what else might be done, we should be just about finished. There are still some typographical and editorial issues with this draft which we will get to next time... if you find any, please say so. thanks, john (with a lot of help from Peter this time, but the errors are certainly mine) , \ From nobody Wed Apr 20 06:32:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5366212DAFC; Wed, 20 Apr 2016 06:32:55 -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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 CSX1nqXzxd7K; Wed, 20 Apr 2016 06:32:47 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5435612DBCD; Wed, 20 Apr 2016 06:32:47 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3KD4OVV024991; Wed, 20 Apr 2016 09:08:14 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 22e5p064x8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Apr 2016 09:08:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3KD8BGt025434; Wed, 20 Apr 2016 09:08:12 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3KD80GW025241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Apr 2016 09:08:05 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 20 Apr 2016 13:07:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.50]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 09:07:41 -0400 From: "STARK, BARBARA H" To: "urn@ietf.org" , "urn-nid@ietf.org" Thread-Topic: Review requested of draft-bbf-bbf-urn-01 Thread-Index: AdGOhitbQ4UWbC5zT3CFh+5H+csBzQMfzSUQ Date: Wed, 20 Apr 2016 13:07:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114265B31B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114263C196@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114263C196@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.196.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-20_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604200211 Archived-At: Cc: "Benoit Claise \(bclaise@cisco.com\)" Subject: Re: [urn] Review requested of draft-bbf-bbf-urn-01 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:32:55 -0000 Hi URN experts, It would be really helpful if someone could take a look at https://tools.ie= tf.org/html/draft-bbf-bbf-urn-01 and say if there's anything wrong with it.= Thanks, Barbara > Hi URN experts, > A review of https://tools.ietf.org/html/draft-bbf-bbf-urn-01 would be muc= h > appreciated. Benoit has said he will AD sponsor this draft. >=20 > Just to tackle an obvious question that will come to the minds of many: W= hy > is BBF asking for 3 namespaces? > 2 of the namespaces requested are historical namespaces that BBF has > squatted on for many years. Both are in wide use in many service provider > environments. Because of this, BBF thinks it would be best to get these 2 > legitimized and out of the squatter shadows. > For new efforts, BBF would like to use the "bbf" namespace. >=20 > Thanks, > Barbara >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Apr 20 23:57:17 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C6112E9BE for ; Wed, 20 Apr 2016 23:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 8zxdd3CK7O5C for ; Wed, 20 Apr 2016 23:57:11 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0132.outbound.protection.outlook.com [104.47.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B0912E9BD for ; Wed, 20 Apr 2016 23:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IyKg3JpR72GYOxbFTWRQz92GFciC6PY4ufvtomtnV0o=; b=EAt1Peps5NKI5RMCHKdjr9ZtICUk0eIVoES3+vdoCLKrWn7xzXisbi2Xurjm2QvpatvCCo7gVB6TOabphWpWxVkIc724FI/5YuXxt4fN2Bhpw0f1jjPrt+pDfM15vzCxQ+MIELSy+PhfEffZK/l5n/fsx3OUMw8I1iwepMeL/y0= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) with Microsoft SMTP Server (TLS) id 15.1.477.5; Thu, 21 Apr 2016 06:57:07 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0477.007; Thu, 21 Apr 2016 06:57:08 +0000 From: "Hakala, Juha E" To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 Thread-Index: AQHRmR6Q2fk1u9GVBEu61tt2o2725J+T7aPw Date: Thu, 21 Apr 2016 06:57:07 +0000 Message-ID: References: <8E2E925C5A90E22F4B1BF36D@JcK-HP8200.jck.com> In-Reply-To: <8E2E925C5A90E22F4B1BF36D@JcK-HP8200.jck.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 53fd4707-c02c-4edd-5afe-08d369b227bd x-microsoft-exchange-diagnostics: 1; VI1PR07MB1725; 5:6uHRLDZ8I7c59ariyleXmB6cOUp7tZRwrNqBYhWYS+UDtSMXtwCVg4GQenCbX0MWJGdkVH0fzTzGSl7HLVWpEDL9edh9EOEph5WEl9bs/LBmiTQDkRPcmxxMnCruI5H0F7qhzP8gl+YIaf4A4d4glQ==; 24:tCLbZA6b2bhzCe0FtEdojDHngASoMEylWPYN9fMM01V5j6ssMfqpUkSMiDLXsN8XcXsTKTTE/25kQYsbToWoZp652oGHGvkKtuSTExakcWs=; 7:D/7fgHhgNhEKvFgEBVVdwPovSxfi9tqRmBbcb8MSo6pFQd0E8uPvC7lzT2ROuvhdPm1DPzMibMw8L/1Zfn25Gd1KcAU9OR+75rGyehLW5WtW1C01v2u+jcIP3ljNQUkdDdxXq5M8idMWTFgRCzP5In53Q8U0iks4nE2Bfxu6ldUd1KSdLqvSF4jGFzsqCuha x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1725; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1725; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1725; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51444003)(3280700002)(15975445007)(5008740100001)(122556002)(77096005)(76176999)(74316001)(3660700001)(87936001)(86362001)(2906002)(66066001)(19580405001)(586003)(5004730100002)(50986999)(54356999)(33656002)(2950100001)(19580395003)(102836003)(92566002)(76576001)(1096002)(6116002)(230783001)(5002640100001)(1220700001)(106116001)(107886002)(5003600100002)(81166005)(2900100001)(5001770100001)(10400500002)(9686002)(3846002)(2501003)(31430400001)(189998001)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1725; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 06:57:07.9313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1725 Archived-At: Subject: Re: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:57:15 -0000 Hello John; all,=20 this new version of rfc2141bis is an improvement, and I believe we are gett= ing closer to the goal of this process.=20 I am fine with the decision to postpone work on r-component, although that = means further delay of some development projects the library community has = been talking about.=20 There are some minor issues in the text that should be corrected.=20 In 2.3.1 the draft says:=20 "If a URN resolves to a URL, the q-component from the URN is copied verbati= m to the query component of the URL." However, we are no longer using URI query component syntax and our added "= =3D" may cause problems. It is probably better to say something like: "If a URN resolves to a URL, the q-component from the URN is copied to the = query component of the URL without "=3D", so that the query syntax matches = URI query component." =20 =20 In 2.3.3 there is a paragraph "Clients SHOULD NOT pass f-components to resolution services unless those s= ervices also perform object retrieval and interpretation functions." The purpose of this is to allow the resolution service to act as a "client"= which retrieves the entire identified object, applies the fragment to it a= nd sends the result to the original client. IMO this would often give no ad= ded value. If the only purpose of the fragment is to take the user to a cer= tain point within the document, there is no way the resolver can do this on= behalf of the client the customer is using. So even if the fragment were i= ncluded in the URN, the resolver should just ignore it, and pass the entire= document to the client which then applies the fragment to it.=20 On the other hand, clients usually do not send fragments to servers / resol= vers, so it might be non-trivial to change this behavior even if the resolv= er could do something meaningful with fragments.=20 The easiest solution is to just write=20 Clients SHOULD NOT pass f-components to resolution services functions even = if those services also perform object retrieval and interpretation function= s." since then there is no pressure to change the normal behavior of clients, o= r to add entirely new kind of functionality to resolvers, which in the end = of the day might not be that useful. In 4.2 there is a somewhat challenging (at least for a non-English speaker)= sentence "In part because of the separation of URN semantics from more general URI syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors need to pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized." It might be better to say something like "... must treat the URN as opaque = unless the identifier scheme is recognized and its requirements are known a= nd met." Chapter 5 specifies three constraints: uniqueness, consistent assignment an= d assignment according to a common definition. I would like to add fourth c= onstraint, persistence. It is already there between the lines (URN is never= reassigned to a different resource) but we could also make the point that = sometimes URNs may even outlive identified resources. There is a typo in 6.4.6: handilng should be handling.=20 Finally, I am OK with the idea of having two kinds of URNs: resource identi= fiers and abstract designators which do not and will not support resolution= services. But I find it difficult to accept (as stated in Introduction) th= at these abstract designators, although persistent, do not identify a resou= rce. What is the purpose of a URN that does not identify anything? It is de= finitely possible to identify something without being resolvable. =20 All the best,=20 Juha > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin > Sent: 18. huhtikuuta 2016 6:01 > To: urn@ietf.org > Subject: [urn] Request for review and comments draft-ietf-urnbis- > rfc2141bis-urn-16 >=20 > Hi. >=20 > I've posted -ietf-urnbis-rfc2141bis-urn-16. The major changes are > summarized in the Change Log (Appendix F.8) but the following (in no > particular order) may be worth special note by the WG. >=20 > (1) Versions up to and including -15 contained a good deal of text that w= as > incremental from RFC 2141 and explained on that basis. This version > removes that text, making the document much more of the standalone > definition of URNs that the WG is expected to produce. The explanations = of > differences and increments have been moved to the "changes from..." > appendices (Appendix B and C) and some additional explanation has been > added to an expanded Introduction. >=20 > (2) Section 2 ("URN Syntax") has been edited to remove material that was > redundant with other parts of that section or the document. >=20 > (3) Following up the comments on the list, the "resolverID" > material has been removed, the explanation of r-component reduced to a > discussion of the general principle, and a statement added to indicate th= at r- > components are reserved for future standardization. >=20 > (4) There were a few places where the text assumed knowledge that, given > the 3986 model of URIs, a URN processor might well not have, with whether > or not a particular target resource would accept a query as one example. > Those statements have been revised. The intent of the current language i= s > that, if the URN resolves to a URL, the q-component and f-component are t= o > be copied to the URL. If the URN is an abstract designator or resolves t= o > something other than a URL, the behavior or those two components is not > defined by the spec -- there just isn't a lot we can say. If the languag= e does > not make that approach adequately clear, or if you think another approach > would be more appropriate, please explain why and, if possible, suggest > alternate text. >=20 > (5) As I mentioned in an earlier note, RFC 3506 contains a > subsection titled "process for identifier resolution". I > believe that Section 6.4.6 and the registration template of > 2141bis-16 adequately captures what was there, while removing the specifi= c > reference to DDDS. The model in the current draft is intended to be that= , if > the URN and namespace are not for an abstract designator (i.e., the URN i= s > expected to "resolve" > somehow, independent of what "resolve" means (see the discussion in > Sections 1.1 and 1.2 for that topid) then the registration template and > process are expected to either: >=20 > (i) Specify the resolution tools and/or procedure and > any additional information needed to utilize it or them. >=20 > (ii) Specify a resolution discovery system (RDS) that > will provide the needed information and any information > needed to call on and use that system. >=20 > As above, if that is not clear from the text in -16 or if you disagree wi= th the > approach and have something new to say on the subject (please see ; cent > note as well as my prior one), please speak up soon and, if you simply ha= ve a > problem with the explanation, supply recommended text if possible. As > mentioned in an earlier note, I think there is a role for a model in whic= h a > persistent object or resource identifier is passed to an explicitly-speci= fied > resolution service, but that is not a URN as we have so far > known it, >=20 > (6) Finally, there is a question about component syntax. Our current > hypothesis is that we need only q-components, f-components, and r- > components, even though we don't have a clear understanding of the latter= . > The q-components and r-components are introduced by "?=3D" and "?+" only. > Each one (along with "#") terminates the other, but all other sequences > consisting on "?" followed by something else are normal -- they can appea= r > inside q-component or r-component strings, or elsewhere, without any > special interpretation (or requiring quoting). If we are sure that we wo= n't > need anything else, that is fine. However, if we were somehow concerned > that we might need additional component types and corresponding > delimiters, this is probably our last chance to make provision for that > without having to make major incompatible changes. Anyone want to make > a strong case for making such reservations? >=20 > Of course, I may have missed other issues, but those are the ones I'm awa= re > of at present. I think that, if the WG can check them and either agree t= hey > are ok or focus on what else might be > done, we should be just about finished. There are still some > typographical and editorial issues with this draft which we will get to n= ext > time... if you find any, please say so. >=20 > thanks, > john (with a lot of help from Peter this time, but the errors are cert= ainly > mine) , >=20 > \ >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Apr 21 10:30:04 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FACD12DBBD for ; Thu, 21 Apr 2016 10:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 wGsI0k6m6lfH for ; Thu, 21 Apr 2016 10:30:00 -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 4C1EE12D4FE for ; Thu, 21 Apr 2016 10:30:00 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1atIQQ-0000Sc-2s; Thu, 21 Apr 2016 13:29:58 -0400 Date: Thu, 21 Apr 2016 13:29:53 -0400 From: John C Klensin To: "Hakala, Juha E" , urn@ietf.org Message-ID: In-Reply-To: References: <8E2E925C5A90E22F4B1BF36D@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:30:03 -0000 Juha, Thanks for the careful reading. A few comments inline below. --On Thursday, April 21, 2016 06:57 +0000 "Hakala, Juha E" wrote: > Hello John; all, > > this new version of rfc2141bis is an improvement, and I > believe we are getting closer to the goal of this process. > > I am fine with the decision to postpone work on r-component, > although that means further delay of some development projects > the library community has been talking about. Speaking personally (not as editor), I'd like to understand those projects, particularly the needs they are trying to address, in more detail. That should, however, probably be off-list or delayed until we've gotten 2141bis and its relatives finished. > There are some minor issues in the text that should be > corrected. > > In 2.3.1 the draft says: > > "If a URN resolves to a URL, the q-component from the URN is > copied verbatim to the query component of the URL." > > However, we are no longer using URI query component syntax and > our added "=" may cause problems. It is probably better to say > something like: > > "If a URN resolves to a URL, the q-component from the URN is > copied to the query component of the URL without "=", so that > the query syntax matches URI query component." I actually checked that sentence when I rewrote things for the "?=" convention and I believe it is correct. The reason is that, in the ABNF (and I hope consistently in the text), the q-component is consistently the string without the introducer. For example, Section 2 of 2141bis-16 includes rq-components = ( "?=" q-component [ "?+" r-component ] ) / ( "?+" r-component [ "?=" q-component ] ) q-component = pchar *( pchar / "/" / "?" ) That is consistent with the way is defined in 3968, i.e., from Section 3 of that document: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] So copying the q-component (which does not include the "?=") into the query (which does not contain the "?") actually is correct. I have doubts about whether "verbatim" is actually helpful, but that is another issue. If you and others think it would be helpful, it would be fairly easy to incorporate a sentence into the paragraph after the 2141bis syntax partially quoted above and/or after the "copied" sentence warning that "q-component", etc., refer to the string and do not contain the introducing delimiter. An even better solution might be to incorporate an example if someone wants to suggest one. > In 2.3.3 there is a paragraph > > "Clients SHOULD NOT pass f-components to resolution services > unless those services also perform object retrieval and > interpretation functions." > > The purpose of this is to allow the resolution service to act > as a "client" which retrieves the entire identified object, > applies the fragment to it and sends the result to the > original client. IMO this would often give no added value. If > the only purpose of the fragment is to take the user to a > certain point within the document, there is no way the > resolver can do this on behalf of the client the customer is > using. So even if the fragment were included in the URN, the > resolver should just ignore it, and pass the entire document > to the client which then applies the fragment to it. Actually, the reason for it was a little different and that is to not constrain implementation models. In one resolution model (using the URN-> URL case as the obvious example), the one I think you have in mind, the approach is client parses URN into pieces and client sends NID and NSS -> URN-resolution-service <- (resulting URL) -or- sends NSS -> NID-specific resolution-service <- (resulting URL) client adds whatever needs to be added to URL client -> URL-resolution-service <- (resulting resource/ object) client evaluates fragment, if any, against object client returns object, or object subset, to user The other model, which I think is worth preserving, is client does not parse URN but passes the whole thing -> URN processor <- (resulting resource / object and fragment ID client evaluates fragment, if any, against object clients returns object, object subset, or other result to user. There are several variations on those themes, but the basic difference in that, in the first model, the client has to break the URI into pieces and then manage the processing/ evaluation of the pieces. In the second, most of that is handed off to what looks to the client like a black box that emits a resource or, in extreme cases, conformation that the desired action has been completed. In addition to suggesting two different processing models, either of which might be implemented in libraries or the like for a broad range of URNs, the relationship between the two also suggests a distinction that 2141bis does not make. That specification now describes two types of URNs, those that resolve in some way (for some very broad definition of "resolve") and those that do not resolve at all, with the latter called "abstract designators". It is also possible to distinguish between namespaces of "objects" that are similar to documents and "objects" that are really actions to be performed. The latter would strongly favor the second implementation model (as well as concepts closer to some views of what r-components should be about). The distinction has not been made in 2141bis for a number of reasons, including its non-discussion in the WG and some concern, reflected in a different form in my recent note to Sean, as to whether such creatures should be considered as URNs or perhaps as URAs ("... resource actions"?) or individual URI schemes. > On the other hand, clients usually do not send fragments to > servers / resolvers, so it might be non-trivial to change this > behavior even if the resolver could do something meaningful > with fragments. Yes. Indeed, 3986 can be read as prohibiting anything but the client from doing anything at all with fragments. On the other hand, interpreting 3986 that way may violate the principle that Internet standards specify what happens (and is visible "on the wire") rather than where and how it is done. > The easiest solution is to just write > > Clients SHOULD NOT pass f-components to resolution services > functions even if those services also perform object retrieval > and interpretation functions." > since then there is no pressure to change the normal behavior > of clients, or to add entirely new kind of functionality to > resolvers, which in the end of the day might not be that > useful. I can live with that although I believe the restriction is unnecessary and might, in some edge cases, might be harmful. Need to hear from others about this. > In 4.2 there is a somewhat challenging (at least for a > non-English speaker) sentence > > "In part because of the separation of URN semantics from more > general URI syntax [I-D.ietf-urnbis-semantics-clarif], > generic URI processors need to pay special attention to the > parsing and analysis rules of RFC 3986 and, in particular, > must treat the URI as opaque unless the scheme and its > requirements are recognized." > > It might be better to say something like "... must treat the > URN as opaque unless the identifier scheme is recognized and > its requirements are known and met." I wonder. Noting that 3986 uses a definition of "identifier" that you and others have questioned and that it doesn't use the term "identifier scheme" at all, might this just add confusion? In 3986-speak, the scheme associated with (or part of) the identifier is well defined and, for the purposes of 2141bis, is always "urn" unless we are specifically talking about URIs, I'm not even sure how to read your modified sentence. What that admittedly-difficult sentence is trying to say is closer to: 'If one has a generic processor for URI, the rules of 3986 apply and must be followed. Only if the processor recognizes the "urn" scheme and understands the applicability of this specification as a result it is appropriate to try to apply its extended rules.' Put that way, the statement is very nearly tautologically trivial and should simply be dropped. But I think we added it to help define the "syntax only but, like other schemes, we get to further restrict and interpret the syntax" boundary between 2141bis and 3986. Suggestions welcome. > Chapter 5 specifies three constraints: uniqueness, consistent > assignment and assignment according to a common definition. I > would like to add fourth constraint, persistence. It is > already there between the lines (URN is never reassigned to a > different resource) but we could also make the point that > sometimes URNs may even outlive identified resources. Send text. I can't remember whether it was an explicit decision or not, but persistence may have been omitted from Section 5 after it became necessary to add what is now Section 1.1 to reflect the fact that we couldn't really agree on a universally-applicable definition for persistence. Of course, we could simply insert a persistence constraint to Section 5 and point back to 1.1 for a [non-]definition. > There is a typo in 6.4.6: handilng should be handling. Fixed in working draft for -17. Thanks. > Finally, I am OK with the idea of having two kinds of URNs: > resource identifiers and abstract designators which do not and > will not support resolution services. But I find it difficult > to accept (as stated in Introduction) that these abstract > designators, although persistent, do not identify a resource. > What is the purpose of a URN that does not identify anything? > It is definitely possible to identify something without being > resolvable. First of all, I agree that things are still a little bit confused (see discussion above). I am hoping that complete clarification is not in the critical path. But the specific answer to your question is that we've got several situations (the XMPP one is the most-cited case) in which the presence or absence of a URN, or the presence of a URN with a particular set of values in the NSS, simply tells whatever (e.g., client) is interpreting it to take or not take some action or to behave in one way or not another. For some months, I referred to such URNs as "indicators" (sometimes prefixed by "pure" or "abstract") to distinguish them from "identifiers" in the sense that your comments above implied. There are some disadvantages to the "indicator" terminology. While I don't remember an explicit discussion of that terminology, Peter preferred "abstract designator", no one else seemed to object, and I didn't think it was worth arguing about. If you see a useful way to clarify that situation, please suggest it. thanks again, john From nobody Mon Apr 25 03:18:50 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA63812D15E for ; Mon, 25 Apr 2016 03:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 JigJO-pu9LhN for ; Mon, 25 Apr 2016 03:18:45 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922EA12D093 for ; Mon, 25 Apr 2016 03:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dnXx8qrRYX4bV7QWagp8tu3/7wY+q4LRTqZG15v1GTE=; b=JSmKkV+nXlFt1cBzDBPsiGJDJF/hI6mRa8KPj0otPeE/xh87/eK55JQrJkldBUFWvgG0jfXVOaztDR/732cILdMFFAmcjyA/qREkUZhdp9dAacAAlokXwyD+TpnFXk/SC8ry4lAscU+vmtC+BE7GqG9E/mJcCIfieUelB9DGkBs= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) with Microsoft SMTP Server (TLS) id 15.1.477.5; Mon, 25 Apr 2016 10:18:21 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0477.012; Mon, 25 Apr 2016 10:18:22 +0000 From: "Hakala, Juha E" To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 Thread-Index: AQHRmR6Q2fk1u9GVBEu61tt2o2725J+T7aPwgADG9ICABawhEA== Date: Mon, 25 Apr 2016 10:18:21 +0000 Message-ID: References: <8E2E925C5A90E22F4B1BF36D@JcK-HP8200.jck.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 9f498305-3363-4c08-ff47-08d36cf2ee00 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1725; 5:9zqaedjfEZJ2jhIQDI7rNGDCtZnjT0zfEZbVu2AQClz9RZsWsbT+hJzuokJjfHasc7COvaaTRuXln7k+ON4bpRVXvCpWX+d/1AhiU5T8cidF6IVRju3FY2Lv9qu32lk+XMSaUeCqMIhiwlgP39Zv+Q==; 24:ASYzNAqtx3pcwL3/HuF6YJF4Niy4yUTXP1dm8XivV1js6zH+M64GEwSktxMGA5qzPYAm3GFipdxj7btN/WKK5rAh/qqiU9cXIMwLwnO2+g4=; 7:E478kCaA2gfX+w0fryVshSaUPrL0/sy1pqjUJdBQo76MWgMdl0jMRL4WPG21f9PhnBcUbvnENidOzfdJAQ+A8fTxaVAft6n3VNxb2aKlpt0OXjYMqh0c+2UUxyNmx8zJGlqOqQk8CNvjMGtGuj3C+Wcxw6kAEMwBWLgyXr414SwRY+dUQ2ASMTi7vr6PkVLq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1725; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1725; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1725; x-forefront-prvs: 0923977CCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(24454002)(13464003)(43784003)(5001770100001)(33656002)(586003)(31430400001)(74316001)(3280700002)(1096002)(1220700001)(5002640100001)(5004730100002)(76576001)(86362001)(9686002)(2950100001)(122556002)(2900100001)(87936001)(77096005)(15975445007)(2501003)(19580405001)(19580395003)(92566002)(5008740100001)(10400500002)(66066001)(81166005)(6116002)(102836003)(74482002)(3846002)(4326007)(3660700001)(5003600100002)(106116001)(230783001)(76176999)(50986999)(54356999)(2906002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1725; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2016 10:18:21.9050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1725 Archived-At: Cc: "jonathanmtclark@gmail.com" Subject: Re: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 10:18:49 -0000 Hello John; all,=20 Further comments below.=20 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: 21. huhtikuuta 2016 20:30 > To: Hakala, Juha E ; urn@ietf.org > Subject: RE: [urn] Request for review and comments draft-ietf-urnbis- > rfc2141bis-urn-16 >=20 > Juha, >=20 > Thanks for the careful reading. A few comments inline below. >=20 > --On Thursday, April 21, 2016 06:57 +0000 "Hakala, Juha E" > wrote: >=20 > > Hello John; all, > > > > this new version of rfc2141bis is an improvement, and I believe we are > > getting closer to the goal of this process. > > > > I am fine with the decision to postpone work on r-component, although > > that means further delay of some development projects the library > > community has been talking about. >=20 > Speaking personally (not as editor), I'd like to understand those project= s, > particularly the needs they are trying to address, in more detail. That > should, however, probably be off-list or delayed until we've gotten 2141b= is > and its relatives finished. In short, resolvers must be made a lot smarter. All PIDs are facing the sam= e problem. Future resolvers must offer more options to the users instead of= just supporting persistent linking to the identified resource. Improvement= s in systems with which libraries, publishers etc. are managing digital res= ources both enable and require such improvements in resolvers. Currently ou= r (and for instance publishers') applications are not too smart, but things= will change in few years' time, and URN syntax should be ready to accommod= ate these new requirements when they materialize. =20 For instance, when a future user locates a relevant document, she should be= able to easily retrieve rights metadata (copyright owner, license terms et= c.) related to the document. It would be easy to list many other requiremen= ts and functionalities which have to do with metadata (descriptive / admini= strative / structural) about digital objects. =20 >=20 > > There are some minor issues in the text that should be corrected. > > > > In 2.3.1 the draft says: > > > > "If a URN resolves to a URL, the q-component from the URN is copied > > verbatim to the query component of the URL." > > > > However, we are no longer using URI query component syntax and our > > added "=3D" may cause problems. It is probably better to say something > > like: > > > > "If a URN resolves to a URL, the q-component from the URN is copied to > > the query component of the URL without "=3D", so that > > the query syntax matches URI query component." >=20 > I actually checked that sentence when I rewrote things for the > "?=3D" convention and I believe it is correct. The reason is > that, in the ABNF (and I hope consistently in the text), the q-component = is > consistently the string without the introducer. OK. I missed that. But it might be a good idea to minimize the chance that = others make the same mistake. > For example, Section 2 of 2141bis-16 includes >=20 > rq-components =3D ( "?=3D" q-component > [ "?+" r-component ] ) / > ( "?+" r-component > [ "?=3D" q-component ] ) > q-component =3D pchar *( pchar / "/" / "?" ) >=20 > That is consistent with the way is defined in 3968, i.e., from Se= ction > 3 of that document: >=20 > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] >=20 > So copying the q-component (which does not include the "?=3D") into the q= uery > (which does not contain the "?") actually is correct. I have doubts abou= t > whether "verbatim" is actually helpful, but that is another issue. >=20 > If you and others think it would be helpful, it would be fairly easy to > incorporate a sentence into the paragraph after the 2141bis syntax partia= lly > quoted above and/or after the "copied" > sentence warning that "q-component", etc., refer to the string and do not > contain the introducing delimiter. An even better solution might be to > incorporate an example if someone wants to suggest one. Such sentence + an example would be useful.=20 An example can be built by pre-using the example further down in the text:= =20 urn:example:weather?=3Dop=3Dmap&lat=3D39.56 &lon=3D-104.85 could be resolved to something like https://weatherapp.org?op=3Dmap&lat=3D39.56 &lon=3D-104.85 =20 >=20 > > In 2.3.3 there is a paragraph > > > > "Clients SHOULD NOT pass f-components to resolution services unless > > those services also perform object retrieval and interpretation > > functions." > > > > The purpose of this is to allow the resolution service to act as a > > "client" which retrieves the entire identified object, applies the > > fragment to it and sends the result to the original client. IMO this > > would often give no added value. If the only purpose of the fragment > > is to take the user to a certain point within the document, there is > > no way the resolver can do this on behalf of the client the customer > > is using. So even if the fragment were included in the URN, the > > resolver should just ignore it, and pass the entire document to the > > client which then applies the fragment to it. >=20 > Actually, the reason for it was a little different and that is to not con= strain > implementation models. In one resolution model (using the URN-> URL > case as the obvious example), the one I think you have in mind, the appro= ach > is >=20 > client parses URN into pieces and > client sends NID and NSS > -> URN-resolution-service > <- (resulting URL) > -or- sends NSS > -> NID-specific resolution-service > <- (resulting URL) >=20 > client adds whatever needs to be added to URL > client -> URL-resolution-service > <- (resulting resource/ object) > client evaluates fragment, if any, against object > client returns object, or object subset, to user >=20 > The other model, which I think is worth preserving, is >=20 > client does not parse URN but > passes the whole thing > -> URN processor > <- (resulting resource / object and > fragment ID > client evaluates fragment, if any, against object > clients returns object, object subset, or other > result to user. >=20 > There are several variations on those themes, but the basic difference in > that, in the first model, the client has to break the URI into pieces and= then > manage the processing/ evaluation of the pieces. In the second, most of > that is handed off to what looks to the client like a black box that emit= s a > resource or, in extreme cases, conformation that the desired action has b= een > completed. >=20 > In addition to suggesting two different processing models, either of whic= h > might be implemented in libraries or the like for a broad range of URNs, = the > relationship between the two also suggests a distinction that 2141bis doe= s > not make. That specification now describes two types of URNs, those that > resolve in some way (for some very broad definition of > "resolve") and those that do not resolve at all, with the latter > called "abstract designators". It is also possible to > distinguish between namespaces of "objects" that are similar to documents > and "objects" that are really actions to be performed. I cannot see any immediate use for utilizing identifiers for actions like t= his, at least in library domain, but eventually such approach may become re= levant.=20 > The latter would strongly favor the second implementation model (as well > as concepts closer to some views of what r-components > should be about). The distinction has not been made in 2141bis > for a number of reasons, including its non-discussion in the WG and some > concern, reflected in a different form in my recent note to Sean, as to > whether such creatures should be considered as URNs or perhaps as URAs > ("... resource actions"?) or individual URI schemes. >=20 > > On the other hand, clients usually do not send fragments to servers / > > resolvers, so it might be non-trivial to change this behavior even if > > the resolver could do something meaningful with fragments. >=20 > Yes. Indeed, 3986 can be read as prohibiting anything but the > client from doing anything at all with fragments. On the other > hand, interpreting 3986 that way may violate the principle that Internet > standards specify what happens (and is visible "on the > wire") rather than where and how it is done. >=20 > > The easiest solution is to just write > > > > Clients SHOULD NOT pass f-components to resolution services functions > > even if those services also perform object retrieval and > > interpretation functions." >=20 > > since then there is no pressure to change the normal behavior of > > clients, or to add entirely new kind of functionality to resolvers, > > which in the end of the day might not be that useful. >=20 > I can live with that although I believe the restriction is unnecessary an= d > might, in some edge cases, might be harmful. > Need to hear from others about this. Now that I understand the purpose of the text, I take back my suggestion. L= et's keep the current formulation.=20 >=20 > > In 4.2 there is a somewhat challenging (at least for a non-English > > speaker) sentence > > > > "In part because of the separation of URN semantics from more > > general URI syntax [I-D.ietf-urnbis-semantics-clarif], > > generic URI processors need to pay special attention to the > > parsing and analysis rules of RFC 3986 and, in particular, > > must treat the URI as opaque unless the scheme and its > > requirements are recognized." > > > > It might be better to say something like "... must treat the URN as > > opaque unless the identifier scheme is recognized and its requirements > > are known and met." >=20 > I wonder. Noting that 3986 uses a definition of "identifier" > that you and others have questioned and that it doesn't use the term > "identifier scheme" at all, might this just add confusion? > In 3986-speak, the scheme associated with (or part of) the identifier is = well > defined and, for the purposes of 2141bis, is always "urn" unless we are > specifically talking about URIs, I'm not even sure how to read your modif= ied > sentence. >=20 > What that admittedly-difficult sentence is trying to say is closer to: >=20 > 'If one has a generic processor for URI, the rules of > 3986 apply and must be followed. Only if the processor > recognizes the "urn" scheme and understands the > applicability of this specification as a result it is > appropriate to try to apply its extended rules.' >=20 > Put that way, the statement is very nearly tautologically trivial and sho= uld > simply be dropped. But I think we added it to help define the "syntax on= ly > but, like other schemes, we get to further restrict and interpret the syn= tax" > boundary between 2141bis and 3986. Suggestions welcome. I should not have used the term "identifier scheme". What I was aiming at w= as that parsing a URN is a double challenge for a generic URI processor. Fi= rst, the processor must recognize the "urn" scheme. And next, the processor= must know how to deal with identifier system (URN namespace). A parser cap= able of resolving urn:isbn's may not know itself how to deal with urn:issn'= s. In an ideal world equipped with resolver discovery service, urn:isbn res= olver would know how to find the urn:issn resolver or any other urn namespa= ce specific resolver out there. For the time being, finding the right resol= ver (there may be several for a single namespace) can be a challenge unless= the resolver location is embedded in the URI with the URN. Parsing URNs is to some extent namespace specific . Some namespaces may not= provide any services, some may have a whole set of them. "Scheme-appropria= te processing" seems to relate to URNs in general. Recognizing that a strin= g is a URN is the necessary first step, but from practical point of view it= is more important to provide appropriate namespace specific parsing of URN= s. =20 >=20 > > Chapter 5 specifies three constraints: uniqueness, consistent > > assignment and assignment according to a common definition. I would > > like to add fourth constraint, persistence. It is already there > > between the lines (URN is never reassigned to a different resource) > > but we could also make the point that sometimes URNs may even outlive > > identified resources. >=20 > Send text. I can't remember whether it was an explicit decision or not, = but > persistence may have been omitted from Section 5 after it became > necessary to add what is now Section 1.1 to reflect the fact that we coul= dn't > really agree on a > universally-applicable definition for persistence. Of course, > we could simply insert a persistence constraint to Section 5 and point ba= ck > to 1.1 for a [non-]definition. What about this formulation to replace the current requirement 1 in chapter= 5:=20 The "uniqueness" and "persistence" constraints mean that once assigned, an = identifier within the namespace is never altered and never reassigned to a different resou= rce (for the kind of "resource" identified by URNs assigned within the namespace) even If the URN is= found to have been issued in error. This holds true even if the identifier itself is deprecated or becomes obsolete= . Note that I am not comfortable with "identifier within the namespace is nev= er assigned to more than one resource ". In ISBN namespace, for instance, t= here are separate ISBNs for all three parts of The Lord of the Rings, but t= here is also 4th ISBN which covers all three parts. So ISBN namespace does = not meet the requirement "never assigned to more than one resource", since = in the ISBN namespace the concept of book is complex and covers both multiv= olume works as single entity in addition to each volume. =20 > > There is a typo in 6.4.6: handilng should be handling. >=20 > Fixed in working draft for -17. Thanks. >=20 > > Finally, I am OK with the idea of having two kinds of URNs: > > resource identifiers and abstract designators which do not and will > > not support resolution services. But I find it difficult to accept (as > > stated in Introduction) that these abstract designators, although > > persistent, do not identify a resource. > > What is the purpose of a URN that does not identify anything? > > It is definitely possible to identify something without being > > resolvable. >=20 > First of all, I agree that things are still a little bit confused (see di= scussion > above). I am hoping that complete > clarification is not in the critical path.=20 I don't think so.=20 But the specific > answer to your question is that we've got several situations (the XMPP on= e > is the most-cited case) in which the presence or absence of a URN, or the > presence of a URN with a particular set of values in the NSS, simply tell= s > whatever (e.g., client) is interpreting it to take or not take some actio= n or to > behave in > one way or not another. For some months, I referred to such > URNs as "indicators" (sometimes prefixed by "pure" or > "abstract") to distinguish them from "identifiers" in the sense that your > comments above implied. There are some disadvantages to the "indicator" > terminology. While I don't remember an explicit discussion of that > terminology, Peter preferred "abstract designator", no one else seemed to > object, and I didn't think it was worth arguing about. If you see a usef= ul way > to clarify that situation, please suggest it. I cannot... but I can live with this situation. This part of the spec may b= ecome a headache if and when it becomes necessary to translate and explain = "abstract designator" in Finnish ;-).=20 Best regards,=20 Juha >=20 > thanks again, > john From nobody Mon Apr 25 14:34:55 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F289912B009; Mon, 25 Apr 2016 14:34:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425213453.30150.20540.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 14:34:53 -0700 Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm Subject: [urn] urnbis - Not having a session at IETF 96 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 21:34:54 -0000 Barry Leiba, a chair of the urnbis working group, indicated that the urnbis working group does not plan to hold a session at IETF 96. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Apr 27 08:02:35 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D15612D82D for ; Wed, 27 Apr 2016 08:02:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WXx4tLPc7tuK for ; Wed, 27 Apr 2016 08:02:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 02BA912D857 for ; Wed, 27 Apr 2016 08:02:29 -0700 (PDT) Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LmeGF-1bVK1z2Jsp-00aB2V; Wed, 27 Apr 2016 17:02:24 +0200 To: "urn@ietf.org" From: Julian Reschke Message-ID: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> Date: Wed, 27 Apr 2016 17:02:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FwMDXenvrjEZBjxK2s9adNAzVeDyECqVuCLZfdcRN5GreDbC9yv vRyW0KdmL9/eDHkHK/YYaNXi7f1f0cQpKY6nQzW/0sDj88WqJsJ9wYbxtwmJcxyiI9zLv1l 8kG6DQk7Fy+Di/DOFgiayuqElQtoWdVJWbzcnFChK2k/QnVdIJdMSGVbfTUXLxwN9YApx8u PWIEEyTYKvmbU9PTdScFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rn5aAFMv8lA=:MgxO3xbSWWMEAAG/LfwLei +avV2AURUhpEPK+2TJ8H/BSp3oFVelSf/D8zr32CGm1sfKiI01CYrKfkRujBLAiSxRPCZnd2m nMYe99FqTEthw80mWOvWKPfman3IbZWCVvpJHoflDV6gUcUHn/qleP+LuQoUj30daGOnSsiPk DGnumJGBwsR25BoKYMUW6c6le6PLlWJGxCtRWo8YaAGMuEV/AAsiVzMlUlsiDlfgvQuEGWQ/g f4MP19oNhhynTm+cDUlhKVZR1fEArraXVvjZ8LWu+FO2WC6s/eaPTMkpNyBL4F7/iKgFoSAvF qdVBGqhrxyty7fQqdJTIXDRJfaUvQejv1Fxx2jrwOEfYtyFrcddmZSZYUdkMujDeKGrXhyRRC ZzRn8806jDPZB1XrNLWU2qmRpgt83UhQtOA90uit5yMgrZVsggaRaZ094Ka5QCHjDgYAVpaGY ZUENrdJ1GJzKZ77ZCR17+XcAW0LRl0dot4Wd9jdy/DbhTNr1a0d7MEDAIvCUYRGH4S+yujcME +Iy3uBdlHIp+drWTSkISymgI/JQ7PpgKJUZErNSsG2Bvmmfh01uMcrY5Fk0M2LcFZZFxPq1ho PzOckGTHv2+G2t77iQBpyennlmELBtfyYaTb+f99JECS091memapYcvL4dTxD9VTO52K19SiP UjZu0hMiBEm2sPOHP2yeXBtUazkXNW3J7QSG+NZvFYesiXJbj4+UihiyFZgxvfetKWqgW/wg+ 3+j+IOAh2rdcXv/E49XeUA9Mtaj4V1/ojmHV+nyTgKL2XHf7WS/kqm0V3mHJEonYmtc+Zqts1 nY3NGQf Archived-At: Subject: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 15:02:34 -0000 Hi there, I was asked off-list to review the current drafts, given my interest in RFC 3986 in the past. I was first confused about 2141bis seemingly making changes to 3986, but then realized that there's draft-ietf-urnbis-semantics-clarif-03 as well. I believe 2141bis needs to *normatively* reference this one. That said, I appreciate that these two are separated, because it's easier to understand what's going on with relation to 3986. However, the separation may need more work; this document IMHO contains stuff that should be in 2141bis, while there's stuff in 2141bis which would need to be here. Other than that see below comments inline (sorry for the format). Best regards, Julian -- snip -- Uniform Resource Names (urnbis) J. Klensin Internet-Draft February 5, 2016 Updates: 3986 (if approved) Intended status: Standards Track Expires: August 8, 2016 URN Semantics Clarification draft-ietf-urnbis-semantics-clarif-03.txt Abstract 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 Information Science 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) in RFC 3986, updating that Lack of clarity: this is intended to be standards track document updating a full internet standard. I don't think that what people believe about that spec is relevant; we should be able to agree upon what it says and what it doesn't say. document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. ...that depends on whether resolution of a relative reference against a base URI is part of what a URI parser does (do we have a definiton of what a "URI parser" does?) 1. Introduction The Generic URI Syntax specification [RFC3986] covers both locators and names and mixtures of the two (See its Section 1.1.3) and describes Uniform Resource Locators (URLs) -- first documented in the 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] and its successors [RFC2141bis] (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 understand that historical context is useful, but do we really need half a paragraph to say: "this is about URIs using the 'urn' scheme"? Experience with URNs since the publication of RFC 3986 has identified several ways in which their inclusion under the 3986 scope has hampered understanding, adoption, and especially extension (specifically extensions of types that were anticipated, but not defined, in RFC 2141). The need for extensions to the URN concept is now being felt in some communities, especially those that include libraries, museums, publishers, and other information scientists. 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 and the various syntax forms and interpretations it allows for . This Agreed for "fragment", not sure about "query". Could you elaborate a bit? specification excludes URNs from those definitions of meaning and interpretation so that RFC 3986 applies to their syntax only. The meaning --and any more specific syntax rules-- for those fields for URNs are now defined in a URN-specific document [RFC2141bis]. URNs remain members of the URI family and parsers for generic URI syntax are not affected by this specification although parsers that make assumptions based on other URI schemes obviously might be. I don't get the last sentence. If a parser makes assumptions on *other* schemes, how would it affect processing of "urn" URIs? Neither this specification nor the successor to RFC 2141 [RFC2141bis] discusses DDDS [RFC3401] resolution or conversion to (and interpretation of) URCs [RFC2483] or, with the exception of providing some syntax to cover some specific cases, URN "resolution" more generally. Any of those topics that do need to be addressed should be covered in other documents. The document also does not discuss alternatives to URNs, either those that might use a different scheme name within the RFC 3986 URI framework or those that might use a different framework entirely. In particular, some externally-defined content or object identification systems could be represented either by a URN namespace or through separate URI schemes. This specification does not offer advice on that choice other than to suggest that the two options not be confused (or both used in a way that would be confusing). (matter of taste: I think that long text about what spec does *not* do really distracts from what it is about; maybe it would be good to things like this (and the text about URN's history) to an appendix?) This document updates RFC 3986 to make the distinction between syntax and semantics clear for URNs and to isolate URNs from presumed URI semantic requiremnts. It is important to note that some readers of s/requiremnts/requirements/ RFC 3986 are convinced that the separation is clear in that specification and therefore that no changes to that document are needed. For them, this specification is only a confirming clarification. I understand that this is well-intended, but it is certainly very very confusing. In the long term, as the expanded syntax and uses of URNs become commonplace and RFC 3986 is updated, this specification is likely to become of historical interest only, providing an extended rationale for decisions made and adjustment of the boundary between URN specifications and generic URI ones. ... 3. The role of queries and fragments in URNs Part of the concern that led to this document was a desire to accommodate URN components that would be analogous to the query and fragment components of generalized URNs but that might have different properties. For many cases, the analogy cannot be exact. For example, RFC 3986 ties the interpretation of fragments to media types. Since media type is a function of specific content, URNs that are never resolved cannot have an associated media type, nor can URNs that resolve to, for example, other URIs that may then not be FTR, RFC 3986 says: "If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." resolved further. Similarly, while the RFC 3986 syntax for queries (and fragments) may be entirely appropriate for URN use, terminology like "Service Request" (see Appendix B of the predecessor "URNs are not..." draft [ServiceRequests] for additional discussion) may be more suitable to the URN context than "query" (if, indeed, the portion of the URN that is syntactically equivalent to a URI query is where those requests belong). RFC 3986: "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)." -- so what *exactly* does this specification try to change? Just the name of the component?? 4. Changes to RFC 3986 This specification removes URN semantics from the scope of RFC 3896. s/3896/3986/ It makes no changes to the generic URI syntax. That syntax still applies to URNs as well as to other URI types. Even as regard to semantics, it has no practical effect for URNs defined in strict conformance to the prior URN specification [RFC2141] or the associated registration specification [RFC3406]. So what other effect *does* it have? In particular (but without altering RFC 3986 in any way), the generic URI syntax for "queries" (strings starting with "?" and continuing to the end of the URI or to a "#"), and for "fragments" (strings starting with "#" and continuing to the end of the URI) is unchanged. For URNs, additional syntax is introduced to divide the URI "query" into two parts, referred to as "q-components" and "r-components". ...I'd argue that this URN-specific syntax shouldn't be discussed in *this* specification. The syntax and general semantics of "fragments" (specified in RFC 3986 as scheme-independent) are unchanged, but a somewhat liberal interpretation may be needed in the context of URNs, so a fragment is referred to as an "f-component" as a term of convenience to highlight that distinction. [RFC2141bis]. From this paragraph it's entirely unclear what the actual change is. 5. Actions Occurring in Parallel with this Specification The basic URN syntax specification [RFC2141] was published well before RFC 3986 and therefore does not depend on it. The successor to that specification [RFC2141bis], fully spells out, or references documents that spell out, the semantics and any required within-field syntax of URNs. It uses great care about generic or implicit reference to any URI specification and delegates further details to specific namespaces. [[CREF1: Note in Draft: Perhaps this section can be dropped entirely.]] Actually, no. essentially updates . This specification needs to be clear about that, because that is actually the biggest change to RFC 3986, and it's not even mentioned here. So if there *was* agreement on that change (which is a separate, complex, discussion), it really really would need to be mentioned here. .... 8. IANA Considerations [[CREF2: RFC Editor: Please remove the first paragraph below before publication.]] This memo is not believed to require any action on IANA's part. There is an existing (i.e. prior to the publication of this document) registry for "Uniform Resource Identifier (URI) Schemes" that already includes the "urn" scheme itself and a separate existing URN Namespace registry. None of those registrations have any specific dependencies on generic URI specifications. Actually, the second paragraph could go as well... 9. Security Considerations This specification changes the semantics of URNs to make them self- contained (as specified in other documents), relying on the generic URI syntax specification for syntax only. It should have no effect on Internet security unless the use of a definition, syntax, and semantics that are more clear reduces the potential for confusion and consequent vulnerabilities. It seems that it's RFC 2142bis which defines these changes, no? 10.2. Informative References [DeterministicURI] Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic URI Encoding", February 2014, . This is an expired document, cited for historical context only. This reference doesn't seem to be used. ... [URN-transition] Klensin, J. and J. Hakala, "Uniform Resource Name (URN) Namespace Registration Transition", Feburary 2016, . This reference doesn't seem to be used. Appendix A. Background on the URN - URI relationship The Internet community now has many years of experience with both name-type identifiers and location-based identifiers (or "references" for those who are sensitive to the term "identifier" such as many members of the library and information science communities.. The s/.././ primary examples of these two categories are Uniform Resource Names (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) [RFC1738]). That experience leads to the conclusion that it is impractical to constrain URNs to the high-level semantics of URLs. The generic syntax for URIs [RFC3986] is adequately flexible to accommodate the perceived needs of URNs, but the specific semantics associated with the URI syntax definition -- what particular constructions "mean" and how and where they are interpreted -- appear to not be. Generalization from URLs to generic Uniform Resource Identifiers (URIs) [RFC3986], especially to name-based, high- stability, long-persistence, identifiers such as many URNs, has failed because the assumed similarities do not adequately extend to all forms of URNs. Ultimately, locators, which typically depend on particular accessing protocols and a specification relative to some physical space or network topology, are simply different creatures from long-persistence, location-independent, object identifiers. The syntax and semantic constraints that are appropriate for locators are either irrelevant to or interfere with the needs of resource names as a class. That was tolerable as long as the URN system didn't need additional capabilities (over those specified in RFC 2141) but experience since RFC 2141 was published has shown that they are, in fact, needed. I don't believe this appendix is way too vague to be helpful. From nobody Wed Apr 27 11:12:01 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E917A12DB8A for ; Wed, 27 Apr 2016 11:11: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NAOpt1d2wLvs for ; Wed, 27 Apr 2016 11:11:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A2B9712DB8F for ; Wed, 27 Apr 2016 11:11:48 -0700 (PDT) Received: from [192.168.178.20] ([84.187.39.170]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LcSAg-1bNhwK02uE-00jqmi for ; Wed, 27 Apr 2016 20:11:46 +0200 To: "urn@ietf.org" From: Julian Reschke Message-ID: Date: Wed, 27 Apr 2016 20:11:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9O04sBbE2lzC8Ql+6821liqq97Kk5ZZHRFzIl5fbMfz3hBfkRwD dVoFnh1VEG5/gWRH6aHioFiNk+evKPJbRLzxJRyLnyndgcSobOmdVJbqtZpBlIAssGO22QJ pPsxHy67rDLd/d9sU46zyoBtgTVMXcH8k539rL6j7qJ0aC/4Ko4GLxOQuQRxBPQvq1rw/jf fqv68p5uKPPGXmmsMLeMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:higUJ5UXD8A=:OoG3eZvak1Rt41uGEBPls+ ufufojRbiZ4bc+gvgJYwX1/yoy6327nOdP6ZwF6Y99OhSrsssKA+T8GLefZ3jE3L8vmePuefd xo6fNYRIVdiWKu2ZCTTPzhKok+k9r3YOXbQi3NGeYBQ41BtOD4BRehE1Y56f9zgko/KelwqvE HoTKfK3Plg4sKzs02Y/qtivxSeUXh0w8dz3Tfr3+Hov/nMrCV9Dk+4GvjCy4wcypb5Jaanqhd zo8zqKjDOyUCbTf8FGvu/48gU3NOG4YMCywpeEjuUmrwEA6OuQlr0aLB8YhR+23yV+tzOl8OX poT9N3PDL18Bs9gSwkZX5YONpVh1nhoPuubq20gSlA0lsQP9Sw/GDrq+MUWRUgqR6XBVO9HOM issfRGGLocY3DbFmJ8Iao4bijZywP+xLOIKJe2h1DvtBknNakGJvbyJXItBuT3TYV+z5i5LdR SNslbEXgJRfq8sZTJ7O8U5HQhqhNke7Y63+y4F3eoSfVGyfeDgJGz0cgbsB+XoAZUH/Kos8nh xA1kpkD3c2B9v8H5zx+LimoGLSycbMzPUz3PiUY4kbcFIu4kNNfUDxBqi6Uol0KUc3KgO1Sg4 DzLiobk3T/zpKbfezgH5vtkRFAUlTCV95EE93ymyzRFdlDq9wnO+BxWOrgGYdEfjsCBth4vWs nFuh88llBV0l9rsFjjTwKCrFArqUZwXol4x63CNtnn5tcu6gHS2xBZFWmSDzMgJpc7Q7j5WtO sSDf1nBOeW7g80mm4FwEgSugwZ9oPw7mtB8f3DSocdCacEtZQfO1G3xxPYfKsGp+WhFqh06l6 PEzGss1 Archived-At: Subject: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:11:59 -0000 Hi there, below some notes on draft-ietf-urnbis-rfc2141bis-urn-16 (I didn't read all of the spec once I realized that it's the other spec that concerns me more :-) (again, sorry for the format) Best regards, Julian -- snip -- The basic syntax for a URN is defined using the Augmented Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined here (specifically: alphanum, fragment, and pchar) are defined as part of the URI syntax [RFC3986] and used here to point out the syntactic relationship with the terms used there. The definitions of some of the terms used below are not complete; additional restrictions are imposed sections of the document that are specific to those terms. Maybe "imposed in the sections"? rq-components = ( "?=" q-component [ "?+" r-component ] ) / ( "?+" r-component [ "?=" q-component ] ) q-component = pchar *( pchar / "/" / "?" ) r-component = pchar *( pchar / "/" / "?" ) f-component = fragment These come as a surprise to anybody not already familiar to what led to the spec. Either introduce them later, or insert some prose explaining where they come from. Also, it would be good if there was a discussion about compatibility with existing use of queries, as these essentially reserve certain variants of queries for generic use. The NSS specified in this document allows characters not permitted by earlier specifications (see Appendix B. In particular, the "/" character, which is now allowed, effectively makes it possible to encapsulate hierarchical identifiers from other naming systems. For s/(see Appendix B/(see Appendix B)/ For the sake of consistency with RFC 3986, neither the general syntax nor the semantics of q-components are defined by, or dependent on, the namespace of the URN. In parallel with RFC 3896, specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular namespace or even a particular resource. I agree that this is the right thing to do, but I'm not sure what this has to do with 3986. 3986 allows a scheme to mandate a specific syntax, no? urn:example:foo-bar-baz-qux?+CCResolve: cc=uk Whitespace? Huh? For the sake of consistency with RFC 3986, neither the general syntax nor the semantics of f-components are defined by, or dependent on, the namespace of the URN. In parallel with RFC 3896, specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular namespace or even a particular resource. s/3896/3986/ Section 5.2 of [RFC3986] describes an algorithm for converting a URI reference that might be relative to a given base URI into "parsed components" of the target of that reference, which can then be recomposed per RFC 3986 Section 5.3 into a target URI. This s/RFC3986// algorithm cannot be applied directly to URNs because their syntax Well, it can be applied (and will be by software developed according to RFC 3986). It's just that the result won't be helpful. does not support the necessary path components. Whenever a URN resolves to a URL which may be used to access the resource, there is a more specific interpretation of q-component and f-component: the q-component is copied verbatim to the query portion of the URL (if that URL scheme supports query), and the f-component is copied verbatim to the fragment portion of the URL. Even though the notion of a URN as a "persistent", "permanent" identifier does not reconcile easily with relative referencing, resources named with URNs may contain relative references that do not apply to the URN itself. I find this very problematic. The URN spec of course can specify a URN-specific algorithm for resolution against a base URI. What it can't do easily is override what RFC 3986 without clearly saying so (updates: 3986) and getting consensus for that. Maybe it would make sense to step back and to consider what software is supposed to implement this algorithm. Browsers? If so, what are the plans of this WG to actually get them to do this? I'm sure there are other use cases that are specific to URNs; do those really require overriding RFC 3986, or could they be addressed differently?