From internet-drafts@ietf.org Fri Aug 2 03:22:54 2013 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 0FFBF21E809C; Fri, 2 Aug 2013 03:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a61SSBlyl93A; Fri, 2 Aug 2013 03:22:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A837221E8137; Fri, 2 Aug 2013 03:22:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802102253.12340.51985.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 03:22:53 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:22:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Syntax Author(s) : Peter Saint-Andre Filename : draft-ietf-urnbis-rfc2141bis-urn-06.txt Pages : 9 Date : 2013-08-02 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. 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: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-06 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 stpeter@stpeter.im Fri Aug 2 03:30:29 2013 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 5C59021E835F; Fri, 2 Aug 2013 03:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSs8oU1kJO-j; Fri, 2 Aug 2013 03:30:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A37BD21E8390; Fri, 2 Aug 2013 03:28:42 -0700 (PDT) Received: from che-vpn-cluster-1-331.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 74B38E831C; Fri, 2 Aug 2013 04:31:02 -0600 (MDT) Message-ID: <51FB89D6.5060209@stpeter.im> Date: Fri, 02 Aug 2013 12:28:38 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20130802102253.12340.51985.idtracker@ietfa.amsl.com> In-Reply-To: <20130802102253.12340.51985.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org, i-d-announce@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:30:29 -0000 Modifications about "equivalence" as previously discussed on the list. Per discussion with the responsible AD directly after the meeting today (which is probably captured in the audio recording), I also removed Ryan Moats as an author and added a new section for Contributors so that he receives proper credit. Peter On 8/2/13 12:22 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Syntax > Author(s) : Peter Saint-Andre > Filename : draft-ietf-urnbis-rfc2141bis-urn-06.txt > Pages : 9 > Date : 2013-08-02 > > Abstract: > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is intended to serve as a persistent, location-independent > resource identifier. This document defines the canonical syntax for > URIs under the "urn" scheme, guidelines for URN namespaces, > requirements for URN presentation and transmission, and methods for > determining URN equivalence. This document obsoletes RFC 2141. > > > 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: > http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-06 > > > 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/ > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From john-ietf@jck.com Fri Aug 2 04:31:57 2013 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 F35D211E8303 for ; Fri, 2 Aug 2013 04:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeG9+sj1Bref for ; Fri, 2 Aug 2013 04:31:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6332E11E82BE for ; Fri, 2 Aug 2013 04:31:08 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1V5DZY-000OUQ-QH; Fri, 02 Aug 2013 07:31:04 -0400 Date: Fri, 02 Aug 2013 07:30:59 -0400 From: John C Klensin To: Andrew Newton , Alfred Hoenes Message-ID: 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 Cc: urn@ietf.org Subject: [urn] (resend) Suggestion about 3044bis (ISSN), 3187bis (ISBN), and 3188bis (NBN) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:31:57 -0000 (sorry... sent with the wrong address... for those who get this, the content is identical) Hi. Given the direction the registration model in 3406bis seems to be taking [1] and some informal discussions during June's meeting of ISO TC 46, I'd like to propose the following: (1) We convert the 3044bis (ISSN), 3187bis (ISBN), and 3188bis (NBN) I-Ds to draft templates. If the present authors don't have the time or energy to do this soon, I'm willing to take a shot at first drafts in the interest of moving this along but checking and help from the proposed "expert committee" would be appreciated. (2) Assuming the IAB doesn't raise procedural objections [2], we send notes to the three relevant registration bodies asking them to take formal responsibility for the URN namespaces that build on their numbering schemes, starting with reviewing, revising if necessary, and submitting the templates. Given previous discussions that things might conceivably move in this direction, they won't be surprised. And, given a registration model based on expert review and my previous comments on this mailing list about recognized SDOs, this is just The Right Thing to do. (3) The steps above leave us with a few loose ends which I think are actually a convenience: (3.1) We need to obsolete 2288, 3044, 3187, and 3188. (3.2) We need to capture any important text from the three I-Ds that won't be in the derived templates and/or ensure that it ends up in stable, referenced, documents [3]. (3.3) As a matter of equity and professional courtesy (and IETF IPR rules if significant text is used), the work of the key authors of the current I-Ds should be appropriately acknowledged. (3.4) We are going to need a document to instruct IANA about replacing the old (and "IETF Reviewed") registrations with ones based on the new templates. Those instructions may well designate the new authorities for the specs. Recommendation: we spin up a new WG draft to deal with the issues above. If Alfred and Juha can find the time to review and make suggestions (and commit to the AUTH48 process), I suggest we make them co-authors. While this isn't the way we expected things to come out when URNbis was started, it is a better outcome and we wouldn't be here without their efforts. In the interest of preserving the recent momentum, if participants in the WG and its leadership think the above is sensible, I'll try to cons up [4] a preliminary version of an I-D within the next few days. best, john [1] For those who missed the WG session, we seem to be shifting toward a well-documented extension of expert review, rather than requiring IETF review. I'll post a separate note on that, but you may want to listen to the rather brief audio (should be at http://www.ietf.org/audio/ietf87/ietf87-charlottenburg1-20130802-1120-am2.mp3 soon) and/or review the slides (http://www.ietf.org/proceedings/87/slides/slides-87-urnbis-0.pdf) if this note doesn't provide enough context. [2] We have a formal liaison relationship with ISO TC 46, which is the parent body for the relevant standards. We don't have formal relationships with the various registration and assignment bodies. I'm not aware of our sending notes equivalent to liaison letters to groups with whom we don't have formal liaison relationships, but it would be, at least IMO, silly to use procedures and that history to prevent getting things done. However, we could, if needed, send notes to the TC 46 Secretariat and ask them to forward, then, since liaison letters are public, quietly slip links to the other bodies. [3] Good news here: The meaning of words like "stable", "archival", and "persistent" around ISO TC 46 and its subgroups is far more stringent than anything the IETF or IANA have been able to think about in specific terms, so no problem there. [4] This term is left as an exercise for those who are not native speakers of the right branches of computer science, It is _not_ English and failure to recognize it does not represent an English deficiency or an offense against diversity :-(. From john-ietf@jck.com Fri Aug 2 05:53:07 2013 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 687A311E8317 for ; Fri, 2 Aug 2013 05:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6mwa9VXNHOV for ; Fri, 2 Aug 2013 05:52:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66821E8092 for ; Fri, 2 Aug 2013 05:52:05 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1V5Epr-000Oa8-1N for urn@ietf.org; Fri, 02 Aug 2013 08:51:59 -0400 Date: Fri, 02 Aug 2013 08:51:53 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <7639E40F70A558B99C1D2367@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 Subject: [urn] The 3406bis template X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 12:53:08 -0000 Hi. I just looked back through the template in draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 in the light of the WG discussion this morning. The template description is now over four pages long and some of the suggestions made this morning will probably make it longer. That is pretty scary; it asks for enough information be copied into the template and handed to IANA to probably be seen as a barrier to registration in some quarters. Recommendations: (1) When the "instructions to Expert Reviewer" material is added, be clear about what is required and what is merely expected. Then reflect that in the sections of the template itself. (2) Number or otherwise identify the sections of the template to make references and cross-references convenient. That will, fwiw, keep this document from running afoul of some possibly-pending RFC Editor style rules. (3) Create an internal table of contents for the template itself. (4) Explicitly permit most sections of the template to be incorporated by reference to a stable external specification (stable by at least the "Specification Required" definition, not just the RFC Editor one) or by a mixture of text and such a reference. By explicit about which ones cannot (I think the first three sections need to be present in the template itself). Let's not make this any harder than it absolutely needs to be. See next note about "Enhanced Expert Review". best, john From juha.hakala@helsinki.fi Tue Aug 6 05:53:21 2013 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 0CB9A21F9344 for ; Tue, 6 Aug 2013 05:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKj+sotu9e0q for ; Tue, 6 Aug 2013 05:53:16 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 388D521F9263 for ; Tue, 6 Aug 2013 05:52:49 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r76Cqa04018494 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 15:52:37 +0300 Message-ID: <5200F194.6050804@helsinki.fi> Date: Tue, 06 Aug 2013 15:52:36 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] (resend) Suggestion about 3044bis (ISSN), 3187bis (ISBN), and 3188bis (NBN) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:53:21 -0000 Hello John; all, See the comments below. On 2.8.2013 14:30, John C Klensin wrote: > Given the direction the registration model in 3406bis seems to > be taking [1] and some informal discussions during June's > meeting of ISO TC 46, I'd like to propose the following: > > (1) We convert the 3044bis (ISSN), 3187bis (ISBN), and 3188bis > (NBN) I-Ds to draft templates. If the present authors don't > have the time or energy to do this soon, I'm willing to take a > shot at first drafts in the interest of moving this along but > checking and help from the proposed "expert committee" would be > appreciated. I am willing (and hopefully also able) to prepare draft templates from existing 3187bis and 3188bis, and cooperate with Pierre Godefroy in writing the ISSN template. Some technical support will probably be needed to create the actual documents. It is a good idea to replace the current practice (IETF Review) with less stringent expert review. Writing an RFC - even an informational one - and having it reviewed by IETF may look like a difficult process. Of course we know from the past experience that the acceptance criteria have not been strict and therefore there are all kinds of namespaces - which is fine with me. But the main difference between them is that some namespaces are well managed and some are not, and this difference cannot be seen clearly from the current registration requests. > > (2) Assuming the IAB doesn't raise procedural objections [2], we > send notes to the three relevant registration bodies asking them > to take formal responsibility for the URN namespaces that build > on their numbering schemes, starting with reviewing, revising if > necessary, and submitting the templates. Given previous > discussions that things might conceivably move in this > direction, they won't be surprised. And, given a registration > model based on expert review and my previous comments on this > mailing list about recognized SDOs, this is just The Right Thing > to do. + 1. > > (3) The steps above leave us with a few loose ends which I think > are actually a convenience: > > (3.1) We need to obsolete 2288, 3044, 3187, and 3188. OK. > > (3.2) We need to capture any important text from the > three I-Ds that won't be in the derived templates and/or > ensure that it ends up in stable, referenced, documents > [3]. We might use this opportunity to take a look on what 3406 requires now, and make some revisions if necessary / possible. Based on my work with 3187bis and 3188bis, there are some things we may want to consider: 1. Should the data elements be defined as mandatory / voluntary? 2. Should the description of both registering organization and contact person include the role (in addition to the name and address)? 3. Many template items could be merged into Description of the identifier system, containing e.g. these components (in this order): - formal status of the identifier (e.g. ISBN is an ISO standard XXX) - scope (e.g. printed and e-books for ISBN) - users (e.g. publishing industry and libraries for ISBN) - identifier semantics (if any) and syntax (including equivalence rules, if any) - identifier persistence and uniqueness considerations (mandatory, for evaluation purposes) - examples of resolution services that can be supported in the namespace, if any Fullness of the information provided will vary a lot from one namespace to the next. 4. The current template does not require the registrants to specify how the namespace is managed. Describing the role of the registering organisation will help a bit, but we should consider allowing the registrants to say more about this, for instance by just simply estimating the management level in a scale from 1 to 10. I could then indicate that ISBN namespace differs from NBN a lot in this respect. We should of course provide some hints as to how to choose the appropriate management level. For instance, no namespace based on in-house identifier should ever receive more than "X". Even a rough estimate of the management level would be useful to the users of the URN system, since well managed URNs (and resources identified by them) may be more persistent than URNs from less privileged namespaces. And organisations considering usage of any given namespace should be very interested in its management level. > > (3.3) As a matter of equity and professional courtesy > (and IETF IPR rules if significant text is used), the > work of the key authors of the current I-Ds should be > appropriately acknowledged. OK. > > (3.4) We are going to need a document to instruct IANA > about replacing the old (and "IETF Reviewed") > registrations with ones based on the new templates. > Those instructions may well designate the new > authorities for the specs. OK. > > Recommendation: we spin up a new WG draft to deal with the > issues above. If Alfred and Juha can find the time to review > and make suggestions (and commit to the AUTH48 process), I > suggest we make them co-authors. While this isn't the way we > expected things to come out when URNbis was started, it is a > better outcome and we wouldn't be here without their efforts. This is fine with me, but I do not know if Alfred will be able to contribute. If not, I'll need help in the publishing process. > > In the interest of preserving the recent momentum, if > participants in the WG and its leadership think the above is > sensible, I'll try to cons up [4] a preliminary version of an > I-D within the next few days. Thank you for making this easier for me, Alfred and Pierre, Juha > > best, > john > > > > [1] For those who missed the WG session, we seem to be shifting > toward a well-documented extension of expert review, rather than > requiring IETF review. I'll post a separate note on that, but > you may want to listen to the rather brief audio (should be at > http://www.ietf.org/audio/ietf87/ietf87-charlottenburg1-20130802-1120-am2.mp3 > soon) and/or review the slides > (http://www.ietf.org/proceedings/87/slides/slides-87-urnbis-0.pdf) > if this note doesn't provide enough context. > > [2] We have a formal liaison relationship with ISO TC 46, which > is the parent body for the relevant standards. We don't have > formal relationships with the various registration and > assignment bodies. I'm not aware of our sending notes > equivalent to liaison letters to groups with whom we don't have > formal liaison relationships, but it would be, at least IMO, > silly to use procedures and that history to prevent getting > things done. However, we could, if needed, send notes to the TC > 46 Secretariat and ask them to forward, then, since liaison > letters are public, quietly slip links to the other bodies. > > [3] Good news here: The meaning of words like "stable", > "archival", and "persistent" around ISO TC 46 and its subgroups > is far more stringent than anything the IETF or IANA have been > able to think about in specific terms, so no problem there. > > [4] This term is left as an exercise for those who are not > native speakers of the right branches of computer science, It > is _not_ English and failure to recognize it does not represent > an English deficiency or an offense against diversity :-(. > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From andy@hxr.us Tue Aug 6 10:37:59 2013 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 DE58C21F9B86 for ; Tue, 6 Aug 2013 10:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCITR1N8w4JP for ; Tue, 6 Aug 2013 10:37:55 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7921F9D45 for ; Tue, 6 Aug 2013 10:37:55 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so511232pdj.7 for ; Tue, 06 Aug 2013 10:37:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ccTd6pX28qPN80nvA0CtRwXZnG8L/Nc8Pz7/EEd8CRo=; b=mEYVelQntr9h8J1yeVdHcRjJak01OpIF2015G15LkxuoQ+dUoDLabi0YOSRa1O082w 6uf8pwcGqsexce7jHr0VBRIbAdqH9ErtUSnTf4gdfgUMZ/nOvN07RZ16xDA1tbkfdVmd HUX/PGzmErhrFMyde3CvnpE0Jkrvgzl43sHJ4plh2EwhWvKFeCLDsNlLm0pT4nVKijMr VLKUcPeLkmRnt2LJyhEUpwOMOZSxEqEYaMJCZIilFfR3IMXwEW54R9+Z9qCtQf2bULdZ 4tQbz6iSl/yXPxzUdO90vy+xs6RtKhhbZ71qxeLXjWtDWr7xogWhKPWZbrc1LDTNFaCE of5g== X-Gm-Message-State: ALoCoQnOqk6W+9MynI4Ya+6uev5EcDXAFtS359wsPKTj58SjXX7g6/arX0WC6zE/dSF50+kBX6uZ MIME-Version: 1.0 X-Received: by 10.67.1.228 with SMTP id bj4mr4345926pad.157.1375810674753; Tue, 06 Aug 2013 10:37:54 -0700 (PDT) Received: by 10.68.203.69 with HTTP; Tue, 6 Aug 2013 10:37:54 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Tue, 6 Aug 2013 13:37:54 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [urn] IETF 87 minutes X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:38:00 -0000 Minutes from our session at IETF 87 are posted. Please confirm that the minutes capture the discussion that occurred during this session. http://www.ietf.org/proceedings/87/minutes/minutes-87-urnbis -andy From barryleiba.mailing.lists@gmail.com Wed Aug 7 01:16:38 2013 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 680A221E80FF for ; Wed, 7 Aug 2013 01:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 619tM4U6nZ1Y for ; Wed, 7 Aug 2013 01:16:36 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D32E021E80FE for ; Wed, 7 Aug 2013 01:16:35 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id b10so1449376vea.7 for ; Wed, 07 Aug 2013 01:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fYUJddsxWJd2LejiS4lWkpUZm++ETi3yQGmxCuC3TOE=; b=KcfqQFJbZ5QhLSN5XrX/I/erzwL544Pvi8H2gq4qYSiV3+w13MfUo6zqRgSYS2Ory7 FjDh5M39V2mb0TYCYXUGeEKnIOi2TuMVtuFly8nkc0PsbSBBUPcPdFXZgVoxCgXakf4q sZw3IlsuT1YMXQO43uXE2wtq4kzEXgU54NwmG0WREGo2YIso/iUhOP2mrxGM8VnXx33l Tdm+U+IPEZr2HzSQCiomfo/zwPa8SzdeJJ/VwrYJuHe6QEZUWm/WNEfH7Sp+LxItkNZd 2LZ1jymCAguUPZ65kuig9KI08pSSSHpUBbzBkv7efHyvymuQhbUgGFtBscgNI9kzXB6M QQMQ== MIME-Version: 1.0 X-Received: by 10.52.164.227 with SMTP id yt3mr513791vdb.107.1375863395284; Wed, 07 Aug 2013 01:16:35 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Wed, 7 Aug 2013 01:16:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Aug 2013 10:16:34 +0200 X-Google-Sender-Auth: ltfFZB0dxrqS4a8qXsgYj3ZNUzM Message-ID: From: Barry Leiba To: Andrew Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] IETF 87 minutes X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 08:16:38 -0000 > Minutes from our session at IETF 87 are posted. Please confirm that > the minutes capture the discussion that occurred during this session. > > http://www.ietf.org/proceedings/87/minutes/minutes-87-urnbis Thanks, Andy; the substance looks good and correct. A few editorial things: "requirements for registering a new URN namespace and lowering the it from RFC Required to Expert Review" -- make "it" be "registration policy". Correct spelling of "Larry Masinter" (one "s"). "SM, via Jabber, suggested that expert reviewers talk directly with the applicants and not let the applicants rely on RFC text for guidance." -- I would say "not require that applicants rely only on". "Without any other business presented, the working group sessions concluded early." -- "session", singular. -- Barry From john-ietf@jck.com Sat Aug 10 02:51:37 2013 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 1083E11E8178 for ; Sat, 10 Aug 2013 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.491 X-Spam-Level: X-Spam-Status: No, score=-101.491 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, MANGLED_WORKNG=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJukY3YljRs2 for ; Sat, 10 Aug 2013 02:51:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3311E8180 for ; Sat, 10 Aug 2013 02:46:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1V85l1-000Hz2-BM; Sat, 10 Aug 2013 05:46:47 -0400 Date: Sat, 10 Aug 2013 05:46:41 -0400 From: John C Klensin To: Thomas Narten , Harald Alvestrand , Peter Saint-Andre Message-ID: 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 Cc: urn@ietf.org, Pete Resnick , Barry Leiba Subject: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 09:51:37 -0000 Hi. Recent discussions and tentative decisions in the URN WG point to a sort of enhancement or fork in the way I (and I think others) have traditionally understood the "expert review" section of RFC 5226. To oversimplify, "expert review" seems to be designed for a situation in which the expert is basically performing an extended sanity check -- are all of the bits of the template complete and do they satisfy the rules, does the applicant understand what they are asking for, and so on. What the URN discussions seem to highlight is that a few enhanced requirements would be desirable in some cases, e.g., (i) The "expert" has a significant tutorial role, not just a passive registration-checking one. Of course, for some registries, that role is served by requirements for submission to a mailing list. (ii) There is enough going on in some registries and the applications used to get entries into them, that it is better to have an expert team who can examine an application from different points of view and discuss it among themselves as well as with the applicant. That would be rather more like a design team than like a shared expert job where two or more people alternate reviews. This idea of an "expert team" could be considered a variation on the "consultation with a set of technology experts" or "multiple designated experts... work[ing] together in evaluating a request",described in Section 3.2 of 5526, but would make all of the members of that team accountable to IANA and the community. (iii) Especially for URNs and probably for some other things, requirements for persistence and stability put a real premium on high-quality and stable documentation. There are good reasons to not move to "Specification Required", but equally good reasons to strongly encourage such specifications, possibly including "provide document or explain why not" provisions in templates. That obviously puts some additional burden on the expert process to try to cajole the document(s) into existence or to approve the exception. (iv) RFC 5226 provides that an expert review is conducted in accordance with "review criteria as documented with the protocol" (Section 3.2), but does not contain an explicit statement that such advice to the expert(s) as to what to review and consider, what the conditions are for rejection, etc., SHOULD be part of any document that specifies "expert review". Relying one the generic criteria in Section 3.2 is really not desirable nor is the statement about "required documentation and review criteria" in Section 4.1. To be clear, that is "SHOULD" in the "do it it or explain why now" sense. In several cases, the right text for expert review appears in Sections 3.1 and 3.2, but the "Expert Review" definition in Section 4.1 doesn't explicitly incorporate the relevant parts of those sections or treat them as options that may be specified. My reading of 5226 is that it just provides convenient templates and that all of the above are allowed by putting the right words into an IANA Considerations section. There have been problems before when some IESG member has trying to treat the categories as normative with only a choice among them (it is easy to read support for that view into statements like "...guidelines for authors on the specific text that must be included..." in the 5226 abstract), but I hope those days are over. So, a question: Does Peter simply incorporate the URN version of the above into 3406bis with a little textual help from me (if he wants or needs it)? Or do I spin up a short I-D that provides an update to 5226 that explicitly adds an enhanced version of expert review with the above as additional options? A third possibility is to do this as an exceptional case for URNs, then treat the URN case as a sort of process experiment (one that does not require 3933) to justify a 5226 update somewhat later. best, john p.s. If an update to 5226 is prepared, there are a few other glitches that ought to be fixed or patched. For example, 5226 explicitly contemplates creation of a registry by an independent submission RFC. But it says that all designated experts are appointed by the IESG. It is not hard to imagine that, as we continue to open things up, a registry would be created via an ISE process (or via the IAB or IRTF stream) for which the IESG should not be the appointment body because there is no "relevant Area Director" and the IESG lacks any expertise to figure out who is and is not expert. So, IMO, 5226upd should, first, suggest that registry-creating documents specify selection criteria for experts and, second, make IESG appointments simply an option for registries created by other than IETF processes. Perhaps some IESG advice and consent model would be appropriate for the latter, but that is probably as far as it is reasonable to go. Note that the above may also require small adjustments to statements about removing experts and who settles deadlocks and deals with non-responsive experts. Because an RFC is required to create a registry, "stream manager" language may be appropriate. From john-ietf@jck.com Sat Aug 10 03:24:58 2013 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 A4CFE11E815E for ; Sat, 10 Aug 2013 03:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62CXrocDPgqE for ; Sat, 10 Aug 2013 03:24:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE221F9CAE for ; Sat, 10 Aug 2013 03:19:09 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1V86GJ-000I0r-OQ; Sat, 10 Aug 2013 06:19:07 -0400 Date: Sat, 10 Aug 2013 06:19:02 -0400 From: John C Klensin To: Andrew Newton , urn@ietf.org Message-ID: <89498995AE1DD4F4C854E1E7@JcK-HP8200.jck.com> In-Reply-To: References: 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 Subject: Re: [urn] IETF 87 minutes X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 10:24:58 -0000 --On Tuesday, August 06, 2013 13:37 -0400 Andrew Newton wrote: > Minutes from our session at IETF 87 are posted. Please confirm > that the minutes capture the discussion that occurred during > this session. > > http://www.ietf.org/proceedings/87/minutes/minutes-87-urnbis Andy, We can (and presumably will) sort details out as revised documents appear, but, in the hope of saving an iteration when Peter gets back to 3406bis, I think that the meeting discussion ran somewhat more in the direction of "specification strongly preferred; if one is not supplied, the template needs to explain why it isn't necessary" than I would infer from the draft minutes. The suggestion that the template contain a report from the expert panel (which the draft captures) was really supplemental to the "provide or explain" requirement, s.t., the report could basically be a comment on the explanation. There was also some significant discussion about the "expert panel" idea, as contrasted with the usual "individual expert" or "rotating experts" ones. It probably deserves a brief mention. Finally, Subramanian should check/comment on this, but I think his intent was closer to "talk directly with the applicants and not require that the applicants rely entirely on RFC text" than the "not let the applicants rely on RFC text" that appears in the minutes. The present text can easily be read as implying that the applicant should listen to the expert and ignore the RFC. thanks, john From stpeter@stpeter.im Mon Aug 12 12:13:50 2013 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 C799821F9BC9 for ; Mon, 12 Aug 2013 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WORKNG=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3QMingmeJdc for ; Mon, 12 Aug 2013 12:13:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BC02721F84D9 for ; Mon, 12 Aug 2013 12:13:44 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B015405AD; Mon, 12 Aug 2013 13:16:35 -0600 (MDT) Message-ID: <520933E4.7030303@stpeter.im> Date: Mon, 12 Aug 2013 13:13:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Harald Alvestrand , Pete Resnick , Barry Leiba , urn@ietf.org Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:13:51 -0000 Hi John, thank you for pursuing this topic. I agree with most everything you've written here. A few comments inline. On 8/10/13 3:46 AM, John C Klensin wrote: > Hi. > > Recent discussions and tentative decisions in the URN WG point > to a sort of enhancement or fork in the way I (and I think > others) have traditionally understood the "expert review" > section of RFC 5226. > > To oversimplify, "expert review" seems to be designed for a > situation in which the expert is basically performing an > extended sanity check -- are all of the bits of the template > complete and do they satisfy the rules, does the applicant > understand what they are asking for, and so on. > > What the URN discussions seem to highlight is that a few > enhanced requirements would be desirable in some cases, e.g., > > (i) The "expert" has a significant tutorial role, not just a > passive registration-checking one. Of course, for some > registries, that role is served by requirements for submission > to a mailing list. As you are well aware, some tutoring does happen on some of the existing lists (say, URI scheme registrations), but it is less intensive than what we foresee for URN namespace registrations. > (ii) There is enough going on in some registries and the > applications used to get entries into them, that it is better to > have an expert team who can examine an application from > different points of view and discuss it among themselves as well > as with the applicant. That would be rather more like a design > team than like a shared expert job where two or more people > alternate reviews. This idea of an "expert team" could be > considered a variation on the "consultation with a set of > technology experts" or "multiple designated experts... work[ing] > together in evaluating a request",described in Section 3.2 of > 5526, but would make all of the members of that team accountable > to IANA and the community. > > (iii) Especially for URNs and probably for some other things, > requirements for persistence and stability put a real premium on > high-quality and stable documentation. There are good reasons > to not move to "Specification Required", but equally good > reasons to strongly encourage such specifications, possibly > including "provide document or explain why not" provisions in > templates. That obviously puts some additional burden on the > expert process to try to cajole the document(s) into existence > or to approve the exception. > > (iv) RFC 5226 provides that an expert review is conducted in > accordance with "review criteria as documented with the > protocol" (Section 3.2), but does not contain an explicit > statement that such advice to the expert(s) as to what to review > and consider, what the conditions are for rejection, etc., > SHOULD be part of any document that specifies "expert review". > Relying one the generic criteria in Section 3.2 is really not > desirable nor is the statement about "required documentation and > review criteria" in Section 4.1. To be clear, that is "SHOULD" > in the "do it it or explain why now" sense. In Berlin, Michelle Cotton pointed me to an I-D that provides more detailed instructions for reviewers related to a particular registry: https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ So there is precedent for doing something beyond just pointing to the buckets in RFC 5226. > In several cases, the right text for expert review appears in > Sections 3.1 and 3.2, but the "Expert Review" definition in > Section 4.1 doesn't explicitly incorporate the relevant parts of > those sections or treat them as options that may be specified. > > My reading of 5226 is that it just provides convenient templates > and that all of the above are allowed by putting the right words > into an IANA Considerations section. There have been problems > before when some IESG member has trying to treat the categories > as normative with only a choice among them (it is easy to read > support for that view into statements like "...guidelines for > authors on the specific text that must be included..." in the > 5226 abstract), but I hope those days are over. > > So, a question: > > Does Peter simply incorporate the URN version of the above into > 3406bis with a little textual help from me (if he wants or needs > it)? Or do I spin up a short I-D that provides an update to > 5226 that explicitly adds an enhanced version of expert review > with the above as additional options? A third possibility is to > do this as an exceptional case for URNs, then treat the URN case > as a sort of process experiment (one that does not require 3933) > to justify a 5226 update somewhat later. Given the IPFIX example cited above, I think we can make the guidelines in 3406bis more detailed than what's provided in RFC 5226 (i.e., your first option). > p.s. If an update to 5226 is prepared, there are a few other > glitches that ought to be fixed or patched. For example, 5226 > explicitly contemplates creation of a registry by an independent > submission RFC. But it says that all designated experts are > appointed by the IESG. It is not hard to imagine that, as we > continue to open things up, a registry would be created via an > ISE process (or via the IAB or IRTF stream) for which the IESG > should not be the appointment body because there is no "relevant > Area Director" and the IESG lacks any expertise to figure out > who is and is not expert. So, IMO, 5226upd should, first, > suggest that registry-creating documents specify selection > criteria for experts and, second, make IESG appointments simply > an option for registries created by other than IETF processes. > Perhaps some IESG advice and consent model would be appropriate > for the latter, but that is probably as far as it is reasonable > to go. > > Note that the above may also require small adjustments to > statements about removing experts and who settles deadlocks and > deals with non-responsive experts. Because an RFC is required > to create a registry, "stream manager" language may be > appropriate. IMHO that's excellent input for draft-leiba-cotton-iana-5226bis, which was last updated very recently. Peter -- Peter Saint-Andre https://stpeter.im/ From andy@hxr.us Tue Aug 13 12:33:33 2013 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 88E2921E80C3 for ; Tue, 13 Aug 2013 12:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZaX5UBgtrqz for ; Tue, 13 Aug 2013 12:33:28 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0211E81B2 for ; Tue, 13 Aug 2013 12:33:25 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so9228613pab.25 for ; Tue, 13 Aug 2013 12:33:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=52aqTpsmQYn1EQy37Bq8ULfeHuIUzshNZIOGn2p0nOo=; b=NXKrBOR3oF3OISryOY3Opl33cJtIMijDDYmFc7Q/VCPBQbgtaiii3qHMhgLx1d0QXR awssrA3l9oOrJA8QuvKTMo1eKPCrEWlw2zUKcoHuQ8a2MdKerQzd+74Ay/kxjirVkB59 BJvsozaQVWs1VwRJQNP8C3EUkbbCS4N9vf08ranlyCcjWxm4SBMOWTMCwPUIQZqL7xsY FBA8X7iLAhm+athwDdKUcP79dkwQA1YZxAIfs0QvAetYlBEFvR5M1S99LIOfCRP+Nqin ve2d53GuaTGTsJlhHvHwGFrDM8KMPOS41TKP1KJaDUNaRB00PsffJZxnBVTy5EhlhjCb gcFg== X-Gm-Message-State: ALoCoQmy3v+UGGo9839f7ZpQo+DUv6wwuFPGE7W8vA/sPakdOnpKDnmof2aSfA9OruO1q6e15VuD MIME-Version: 1.0 X-Received: by 10.66.136.131 with SMTP id qa3mr6053340pab.77.1376422405589; Tue, 13 Aug 2013 12:33:25 -0700 (PDT) Received: by 10.68.203.69 with HTTP; Tue, 13 Aug 2013 12:33:25 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Tue, 13 Aug 2013 15:33:25 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:33:33 -0000 All, Today begins a two-week working group last call of draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end Tuesday, 27 August 2013. The document can be found here: http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ Please review and comment on the draft, even if it is only to say on the record "I have reviewed this document thoroughly and it looks good." We would like to have no fewer than five people report that they have taken a look at the whole document and reported their findings. -andy newton, co-chair From stpeter@stpeter.im Tue Aug 13 12:39:18 2013 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 53C8621F8CB4 for ; Tue, 13 Aug 2013 12:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZjvKmmDVnnK for ; Tue, 13 Aug 2013 12:39:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5911E81BB for ; Tue, 13 Aug 2013 12:39:05 -0700 (PDT) Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 400FB4010C; Tue, 13 Aug 2013 13:42:00 -0600 (MDT) Message-ID: <520A8B56.1070604@stpeter.im> Date: Tue, 13 Aug 2013 13:39:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John C Klensin References: <7639E40F70A558B99C1D2367@JcK-HP8200.jck.com> In-Reply-To: <7639E40F70A558B99C1D2367@JcK-HP8200.jck.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] The 3406bis template X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:39:18 -0000 On 8/2/13 6:51 AM, John C Klensin wrote: > Hi. > > I just looked back through the template in > draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 in the light of the > WG discussion this morning. > > The template description is now over four pages long and some of > the suggestions made this morning will probably make it longer. > That is pretty scary; it asks for enough information be copied > into the template and handed to IANA to probably be seen as a > barrier to registration in some quarters. Agreed: let's make the template as simple as possible, but no simpler. (Marc Blanchet said he would provide some feedback regarding simplification, too.) The template is too long in part because it contains instructions and examples; those could be moved to the body of 3406bis. > Recommendations: > > (1) When the "instructions to Expert Reviewer" material is > added, be clear about what is required and what is merely > expected. Then reflect that in the sections of the template > itself. Yes. > (2) Number or otherwise identify the sections of the template to > make references and cross-references convenient. That will, > fwiw, keep this document from running afoul of some > possibly-pending RFC Editor style rules. > > (3) Create an internal table of contents for the template itself. Right now it is structured in xml2rfc as a huge example. That's easily fixed and will result in a better table of contents for 3406bis itself (and enable cross-references as you mention above). Are you also suggesting that the template contain a mini-ToC? > (4) Explicitly permit most sections of the template to be > incorporated by reference to a stable external specification > (stable by at least the "Specification Required" definition, not > just the RFC Editor one) or by a mixture of text and such a > reference. By explicit about which ones cannot (I think the > first three sections need to be present in the template itself). Agreed. > Let's not make this any harder than it absolutely needs to be. +1 Do you have suggestions on which sections might productively be removed? Peter -- Peter Saint-Andre https://stpeter.im/ From michael@refactored-networks.com Tue Aug 13 14:03:47 2013 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 67FCA21E80C3 for ; Tue, 13 Aug 2013 14:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWEn6Vdjo6wY for ; Tue, 13 Aug 2013 14:03:41 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5062221E8187 for ; Tue, 13 Aug 2013 14:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D02B3294140; Tue, 13 Aug 2013 16:03:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTZHvDmCXPor; Tue, 13 Aug 2013 16:03:26 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B3D4D294143; Tue, 13 Aug 2013 16:03:26 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A71F3294138; Tue, 13 Aug 2013 16:03:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o6hnZ4uGnybu; Tue, 13 Aug 2013 16:03:26 -0500 (CDT) Received: from [192.168.0.103] (50-199-114-66-static.hfc.comcastbusiness.net [50.199.114.66]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 6857E294140; Tue, 13 Aug 2013 16:03:25 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Mealling In-Reply-To: Date: Tue, 13 Aug 2013 17:03:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29CA8F16-6536-4B77-88CB-12686DFBB184@refactored-networks.com> References: To: Andrew Newton X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:03:48 -0000 I have reviewed this document and it looks OK to me. While I'm not = suggesting it be added to the document or should stop anything from = moving forward, I would personally prefer this paragraph in Section 6: "If a query component, fragment identifier component, or both have been appended to the assigned URI, they MUST be ignored for purposes of determining equivalence." be in bright red 72 point type on every page . -MM Michael Mealling Co-Founder Pipefish.com +1-678-640-6884 @mmealling Schedule a meeting: http://meetme.so/michaelmealling On Aug 13, 2013, at 3:33 PM, Andrew Newton wrote: > All, >=20 > Today begins a two-week working group last call of > draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end > Tuesday, 27 August 2013. >=20 > The document can be found here: > http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >=20 > Please review and comment on the draft, even if it is only to say on > the record "I have reviewed this document thoroughly and it looks > good." We would like to have no fewer than five people report that > they have taken a look at the whole document and reported their > findings. >=20 > -andy newton, co-chair > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From sm@resistor.net Tue Aug 13 21:16:38 2013 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 0D32711E8120 for ; Tue, 13 Aug 2013 21:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc5Ky29P1Ghm for ; Tue, 13 Aug 2013 21:16:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D011E8116 for ; Tue, 13 Aug 2013 21:16:37 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7E4GPjn004860; Tue, 13 Aug 2013 21:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376453791; bh=N3e9E4hm5TQXpxKgHxoWWGelkb1xQASLva3DTo9hcA4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XVsy3qHTkKQob4GuIL+zAmjYaxmFAthwBigjpKi19Th0fcjmMutsltg5Trax+5w8e 7J0i1gUfvyNJNegdkKlKoiYWZA98MpvcS1YVuU6UCsYJXAcLycB+r75kMEFloJ1tpT FEeBcxXy1EaErBOPEPb9H5Xcj8amMN4G+brI8eEY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376453791; i=@resistor.net; bh=N3e9E4hm5TQXpxKgHxoWWGelkb1xQASLva3DTo9hcA4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=O9IzK5oS7UbcpLNEa0Lree3j3zc786vb065sYtLaTXZR+y8uHiBAXy7at2G17BL3F /UVW8VSrgeHHbPpxHqF1VdEFnXxwGBmmBWe5yVJUMh/LijnoA22o1vLAk1WuYAE1WQ bawFHstni+6NI4laWt9tL/YfbavecFUW8KsARLTA= Message-Id: <6.2.5.6.2.20130813203953.0d90dae8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 20:59:13 -0700 To: John C Klensin , Andrew Newton From: SM In-Reply-To: <89498995AE1DD4F4C854E1E7@JcK-HP8200.jck.com> References: <89498995AE1DD4F4C854E1E7@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] IETF 87 minutes X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 04:16:38 -0000 At 03:19 10-08-2013, John C Klensin wrote: >Finally, Subramanian should check/comment on this, but I think >his intent was closer to "talk directly with the applicants and >not require that the applicants rely entirely on RFC text" than >the "not let the applicants rely on RFC text" that appears in >the minutes. The present text can easily be read as implying >that the applicant should listen to the expert and ignore the >RFC. I suggested gently explaining how things work instead of requiring that the applicant relies on the text in the RFC for guidance. I am not suggesting that the applicant should listen to the expert or that the applicant should ignore the RFC. The idea here is to make the registration process easier for the applicant. Regards, -sm From sm@resistor.net Tue Aug 13 21:37:18 2013 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 6366411E8126 for ; Tue, 13 Aug 2013 21:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.055 X-Spam-Level: X-Spam-Status: No, score=-101.055 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, MANGLED_WORKNG=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mM53hqZoYvD for ; Tue, 13 Aug 2013 21:37:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3D11E8123 for ; Tue, 13 Aug 2013 21:37:15 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7E4aqnZ014713; Tue, 13 Aug 2013 21:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376455023; bh=PCZUejSmbImL9fOw4K8d/uxNo29idYpBiibgP7hKOJE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IH6Z/FOkURpl/7M0HoygAPWCh74wIKsr22icNPGvWGjlFLso8ISCxefGBm6rxLnZ+ miTyxfPttxOSQDdgGgFdFwXwzfa+JCh9kpAnUrEgCd6y9c9+UaNUf9q2gVzlQ/2KCq czQZIKobEWp2KOOw24IxZOZ4SNOqig3ekPgkowOQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376455023; i=@resistor.net; bh=PCZUejSmbImL9fOw4K8d/uxNo29idYpBiibgP7hKOJE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OFC5WRtXILKZSHeNhhyPIIr1d2w7OBEIC4riKzz9b467JjkkkkODaxLcIpEvug5m4 6kZsJ4dc+AKcqr2zhUdWxwviJE7X1zXRn76b7jiV/VZtrr/U3WJ9UFCK74SBnrEneG HjBsPrkqObWc+prQxhVkgGyvzTe8HRXjR7RMAVMw= Message-Id: <6.2.5.6.2.20130813210235.06c1f810@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 21:16:40 -0700 To: John C Klensin , Thomas Narten , Harald Alvestrand , Peter Saint-Andre From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick , urn@ietf.org, Barry Leiba Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 04:37:18 -0000 At 02:46 10-08-2013, John C Klensin wrote: >Recent discussions and tentative decisions in the URN WG point >to a sort of enhancement or fork in the way I (and I think >others) have traditionally understood the "expert review" >section of RFC 5226. > >To oversimplify, "expert review" seems to be designed for a >situation in which the expert is basically performing an >extended sanity check -- are all of the bits of the template >complete and do they satisfy the rules, does the applicant >understand what they are asking for, and so on. > >What the URN discussions seem to highlight is that a few >enhanced requirements would be desirable in some cases, e.g., > >(i) The "expert" has a significant tutorial role, not just a >passive registration-checking one. Of course, for some >registries, that role is served by requirements for submission >to a mailing list. > >(ii) There is enough going on in some registries and the >applications used to get entries into them, that it is better to >have an expert team who can examine an application from >different points of view and discuss it among themselves as well >as with the applicant. That would be rather more like a design >team than like a shared expert job where two or more people >alternate reviews. This idea of an "expert team" could be >considered a variation on the "consultation with a set of >technology experts" or "multiple designated experts... work[ing] >together in evaluating a request",described in Section 3.2 of >5526, but would make all of the members of that team accountable >to IANA and the community. I like the idea of multiple designated experts working together. I saw a case where that did not work well in practice. Someone had to step in as the person who was assigned the task didn't do it. making the members accountable is not that easy. >(iii) Especially for URNs and probably for some other things, >requirements for persistence and stability put a real premium on >high-quality and stable documentation. There are good reasons >to not move to "Specification Required", but equally good >reasons to strongly encourage such specifications, possibly >including "provide document or explain why not" provisions in >templates. That obviously puts some additional burden on the >expert process to try to cajole the document(s) into existence >or to approve the exception. It would be better if the specification is made available in a timely manner after the expert review instead of a few years down the line. >(iv) RFC 5226 provides that an expert review is conducted in >accordance with "review criteria as documented with the >protocol" (Section 3.2), but does not contain an explicit >statement that such advice to the expert(s) as to what to review >and consider, what the conditions are for rejection, etc., >SHOULD be part of any document that specifies "expert review". >Relying one the generic criteria in Section 3.2 is really not >desirable nor is the statement about "required documentation and >review criteria" in Section 4.1. To be clear, that is "SHOULD" >in the "do it it or explain why now" sense. If I recall correctly the IESG has been asking for better guidance for expert reviewers. The problem might not be the rejection of an application. It looks more like the lack of a "yes" has to be taken as a "no". Regards, -sm From juha.hakala@helsinki.fi Tue Aug 13 23:41:08 2013 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 9E64C11E8126 for ; Tue, 13 Aug 2013 23:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHOF5vGUArcy for ; Tue, 13 Aug 2013 23:40:52 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 48B1711E80E1 for ; Tue, 13 Aug 2013 23:40:50 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r7E6elMX000679 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 14 Aug 2013 09:40:48 +0300 Message-ID: <520B266F.7010404@helsinki.fi> Date: Wed, 14 Aug 2013 09:40:47 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 06:41:08 -0000 Hello, I have reviewed the text once more and it looks fine. Juha On 13.8.2013 22:33, Andrew Newton wrote: > All, > > Today begins a two-week working group last call of > draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end > Tuesday, 27 August 2013. > > The document can be found here: > http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > Please review and comment on the draft, even if it is only to say on > the record "I have reviewed this document thoroughly and it looks > good." We would like to have no fewer than five people report that > they have taken a look at the whole document and reported their > findings. > > -andy newton, co-chair > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From harald@alvestrand.no Wed Aug 14 03:08:49 2013 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 A1A6211E8142 for ; Wed, 14 Aug 2013 03:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WORKNG=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad5C33Mk6kFY for ; Wed, 14 Aug 2013 03:08:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 20D7811E8144 for ; Wed, 14 Aug 2013 03:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 416D439EA1B; Wed, 14 Aug 2013 12:08:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qNY63NNuM9Y; Wed, 14 Aug 2013 12:08:40 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7995839E4EA; Wed, 14 Aug 2013 12:08:40 +0200 (CEST) Message-ID: <520B5727.20900@alvestrand.no> Date: Wed, 14 Aug 2013 12:08:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Aug 2013 06:00:26 -0700 Cc: Thomas Narten , urn@ietf.org, Pete Resnick , Barry Leiba Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:08:49 -0000 On 08/10/2013 11:46 AM, John C Klensin wrote: > Hi. > > Recent discussions and tentative decisions in the URN WG point > to a sort of enhancement or fork in the way I (and I think > others) have traditionally understood the "expert review" > section of RFC 5226. > > To oversimplify, "expert review" seems to be designed for a > situation in which the expert is basically performing an > extended sanity check -- are all of the bits of the template > complete and do they satisfy the rules, does the applicant > understand what they are asking for, and so on. That's almost right - it's been something like 15 years since Thomas and I wrote RFC 2434, and memory may be failing.... as I remember it, the "expert review" variant was intended to cover 2 cases: 1) We weren't sure whether the rules prevented all the cases in which registrations could be considered "actively harmful" (if we felt sure, it would be "FCFS" or "Specification required"). That's the "guardian" aspect. 2) We felt that the rules weren't codified well enough for people to figure out on their own what they needed to write in a registration template - or for IANA to be able to figure out all the ways in which people could get the template wrong. That's the "guidance" aspect. > > What the URN discussions seem to highlight is that a few > enhanced requirements would be desirable in some cases, e.g., > > (i) The "expert" has a significant tutorial role, not just a > passive registration-checking one. Of course, for some > registries, that role is served by requirements for submission > to a mailing list. And not always well served by that function (but I digress). > > (ii) There is enough going on in some registries and the > applications used to get entries into them, that it is better to > have an expert team who can examine an application from > different points of view and discuss it among themselves as well > as with the applicant. That would be rather more like a design > team than like a shared expert job where two or more people > alternate reviews. This idea of an "expert team" could be > considered a variation on the "consultation with a set of > technology experts" or "multiple designated experts... work[ing] > together in evaluating a request",described in Section 3.2 of > 5526, but would make all of the members of that team accountable > to IANA and the community. Thomas and I considered that when writing 2434 - the reason we ended up using "Designated Expert" was that we felt that someone would have to be responsible for making the call; calling for a group to come to consensus seemed like the wrong approach for this. This skepticism towards "delegate to group" was also the reason why section 4 of 2434 said that in the case of mailing list review, use of a Designated Expert MUST be specified. Of course the expert could take advice from anyone, or even delegate his/her responsibility - that's a lot of the extra text in 5226 section 3.1 is about. > > (iii) Especially for URNs and probably for some other things, > requirements for persistence and stability put a real premium on > high-quality and stable documentation. There are good reasons > to not move to "Specification Required", but equally good > reasons to strongly encourage such specifications, possibly > including "provide document or explain why not" provisions in > templates. That obviously puts some additional burden on the > expert process to try to cajole the document(s) into existence > or to approve the exception. Indeed. > > (iv) RFC 5226 provides that an expert review is conducted in > accordance with "review criteria as documented with the > protocol" (Section 3.2), but does not contain an explicit > statement that such advice to the expert(s) as to what to review > and consider, what the conditions are for rejection, etc., > SHOULD be part of any document that specifies "expert review". > Relying one the generic criteria in Section 3.2 is really not > desirable nor is the statement about "required documentation and > review criteria" in Section 4.1. To be clear, that is "SHOULD" > in the "do it it or explain why now" sense. Yup. One of the reasons why this isn't in the documents (especially 2434) was because we saw that designated experts would be put in as a back-patch for existing registries where there wasn't really energy for writing down what the rules should be - the expert was a person of sound judgment and a safeguard against insanity, as much as anything else. > > In several cases, the right text for expert review appears in > Sections 3.1 and 3.2, but the "Expert Review" definition in > Section 4.1 doesn't explicitly incorporate the relevant parts of > those sections or treat them as options that may be specified. > > My reading of 5226 is that it just provides convenient templates > and that all of the above are allowed by putting the right words > into an IANA Considerations section. There have been problems > before when some IESG member has trying to treat the categories > as normative with only a choice among them (it is easy to read > support for that view into statements like "...guidelines for > authors on the specific text that must be included..." in the > 5226 abstract), but I hope those days are over. > > So, a question: > > Does Peter simply incorporate the URN version of the above into > 3406bis with a little textual help from me (if he wants or needs > it)? Or do I spin up a short I-D that provides an update to > 5226 that explicitly adds an enhanced version of expert review > with the above as additional options? A third possibility is to > do this as an exceptional case for URNs, then treat the URN case > as a sort of process experiment (one that does not require 3933) > to justify a 5226 update somewhat later. I think having the URN version of the above as part of the URN registry expert instructions is a very reasonable choice, and as far as I can tell clearly within what 5226 allows. Some generic version of "designated experts need to have instructions" should be part of 5226bis, if it isn't already clear enough from the text. I think the circumstances vary enough that it's good not to put too much normative language into 5226bis about what those instructions should be. > > best, > john > > p.s. If an update to 5226 is prepared, there are a few other > glitches that ought to be fixed or patched. For example, 5226 > explicitly contemplates creation of a registry by an independent > submission RFC. But it says that all designated experts are > appointed by the IESG. It is not hard to imagine that, as we > continue to open things up, a registry would be created via an > ISE process (or via the IAB or IRTF stream) for which the IESG > should not be the appointment body because there is no "relevant > Area Director" and the IESG lacks any expertise to figure out > who is and is not expert. So, IMO, 5226upd should, first, > suggest that registry-creating documents specify selection > criteria for experts and, second, make IESG appointments simply > an option for registries created by other than IETF processes. > Perhaps some IESG advice and consent model would be appropriate > for the latter, but that is probably as far as it is reasonable > to go. > > Note that the above may also require small adjustments to > statements about removing experts and who settles deadlocks and > deals with non-responsive experts. Because an RFC is required > to create a registry, "stream manager" language may be > appropriate. > Hm. I was also told recently that W3C could ask for a registry at IANA without having IESG approval. W3C doesn't do RFCs most of the time. So not only streams might need to be named here. Another "out" is to say that 5226bis (which is an IESG-approved document) only applies to registries created through the IETF stream, and publish an 1-page (hah) RFC that says "for stream X, 5226bis is followed, except that all references to IESG are replaced with ". My thoughts only, and probably more appropriate for wherever 5226bis is being discussed. From john-ietf@jck.com Thu Aug 15 11:02:36 2013 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 5E0F811E811F for ; Thu, 15 Aug 2013 11:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AabQQNQ0YKZV for ; Thu, 15 Aug 2013 11:02:31 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5163311E80AD for ; Thu, 15 Aug 2013 11:02:31 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VA1sE-0006oH-92; Thu, 15 Aug 2013 14:02:14 -0400 Date: Thu, 15 Aug 2013 14:02:09 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <04271FE45BACAD7EAB5F71A5@JcK-HP8200.jck.com> In-Reply-To: <520933E4.7030303@stpeter.im> References: <520933E4.7030303@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========E605E6B3E1216D65D6F2==========" Cc: Thomas Narten , Harald Alvestrand , Pete Resnick , Barry Leiba , urn@ietf.org Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 18:02:36 -0000 --==========E605E6B3E1216D65D6F2========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Monday, August 12, 2013 13:13 -0600 Peter Saint-Andre wrote: > Hi John, thank you for pursuing this topic. I agree with most > everything you've written here. A few comments inline. Sorry it has taken me so long to get back to you. Proposed specific text for a new Section 7 (with appropriate renumbering) is attached. It requires some small editorial cleanups as well -- I'm sending you XML for everything I caught in the hope that, if you and the WG like the text, this can just be merged modulo whatever editorial work you decide to do on my first-draft writing style. Those reading the attached should note that I've made several decisions in the direction of keeping this as process-light as possible, deferring several types of decisions to the IESG, IANA, the expert team, or otherwise. My hope in doing so is that we can end up with as much process as needed and no more and that, where possible, small process adjustments can be made as needed without having to either open or ignore this document. A few comments and an additional suggestion or two below (with lots of earlier text elided). > On 8/10/13 3:46 AM, John C Klensin wrote: >> Hi. >> >> Recent discussions and tentative decisions in the URN WG point >> to a sort of enhancement or fork in the way I (and I think >> others) have traditionally understood the "expert review" >> section of RFC 5226. >... > As you are well aware, some tutoring does happen on some of > the existing lists (say, URI scheme registrations), but it is > less intensive than what we foresee for URN namespace > registrations. I've used "mutual education" in the proposed text for two reasons: unlike "tutoring", it cannot be interpreted as pejorative and I actually expect that the subject matter and namespace experts will educate the IETF-designated ones as much as vice versa. I hope the desired level of intensiveness comes across. >... >> (iv) RFC 5226 provides that an expert review is conducted in >> accordance with "review criteria as documented with the >> protocol" (Section 3.2), but does not contain an explicit >> statement that such advice to the expert(s) as to what to >> review and consider, what the conditions are for rejection, >> etc., SHOULD be part of any document that specifies "expert >> review". Relying one the generic criteria in Section 3.2 is >> really not desirable nor is the statement about "required >> documentation and review criteria" in Section 4.1. To be >> clear, that is "SHOULD" in the "do it it or explain why now" >> sense. > > In Berlin, Michelle Cotton pointed me to an I-D that provides > more detailed instructions for reviewers related to a > particular registry: > > https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ > > So there is precedent for doing something beyond just pointing > to the buckets in RFC 5226. There is _lots_ of precedent. The only issue is whether a stink arises on either IETF LC or in the IESG. I guess we will have to deal with those problems if they arise. >... >> So, a question: >> >> Does Peter simply incorporate the URN version of the above >> into 3406bis with a little textual help from me (if he wants >> or needs it)? Or do I spin up a short I-D that provides an >> update to 5226 that explicitly adds an enhanced version of >> expert review with the above as additional options? A third >> possibility is to do this as an exceptional case for URNs, >> then treat the URN case as a sort of process experiment (one >> that does not require 3933) to justify a 5226 update somewhat >> later. > > Given the IPFIX example cited above, I think we can make the > guidelines in 3406bis more detailed than what's provided in > RFC 5226 (i.e., your first option). Proposed text attached, as noted above. Putting it in required tuning elsewhere and I've taken a shot at that. But it is editorial, rather than substantive, so it is probably best that the WG look at it in context with whatever changes Peter is making. Added high-level suggestion: I have not tried to fix (or otherwise modify) the template other than to tentatively adjust an introductory sentence and add "this item is required" sentences to the first three items. I do suggest that you remove as much discussion as to how specific subsections should be filled in to Section 6 (or elsewhere). That would have two advantages. First, if the template itself runs three or four pages, it will be perceived as long, complex, and hard to complete no matter what is actually there. If we want to bias things toward getting more namespaces that are in use registered, we should minimize that perception. Second, there is enough information in the non-template parts of this document that, if someone who wants to submit a registration has to read it, that would be A Good Thing. >> p.s. If an update to 5226 is prepared, there are a few other >> glitches that ought to be fixed or patched. For example, 5226 >> explicitly contemplates creation of a registry by an >> independent submission RFC. But it says that all designated >> experts are appointed by the IESG. It is not hard to imagine >> that, as we continue to open things up, a registry would be >> created via an ISE process (or via the IAB or IRTF stream) >> for which the IESG should not be the appointment body because >> there is no "relevant Area Director" and the IESG lacks any >> expertise to figure out who is and is not expert. So, IMO, >> 5226upd should, first, suggest that registry-creating >> documents specify selection criteria for experts and, second, >> make IESG appointments simply an option for registries >> created by other than IETF processes. Perhaps some IESG >> advice and consent model would be appropriate for the latter, >> but that is probably as far as it is reasonable to go. >> >> Note that the above may also require small adjustments to >> statements about removing experts and who settles deadlocks >> and deals with non-responsive experts. Because an RFC is >> required to create a registry, "stream manager" language may >> be appropriate. > > IMHO that's excellent input for > draft-leiba-cotton-iana-5226bis, which was last updated very > recently. Ack. Barry, consider yourself provided with input and pass along as appropriate. best, john --==========E605E6B3E1216D65D6F2========== Content-Type: text/plain; charset=utf-8; name="rfc3406bis-new-text.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfc3406bis-new-text.txt"; size=5805 ---- Proposed new Section 7 (with appropriate) renumbering = ------- 7. URN Namespace Review Process The registration model for URN namespaces is intended to = balance several considerations: o Because of the requirement that URNs be persistent, a = namespace that is not adequately supported by rules for use and documentation is one that is likely to be useless in the = long term. o For some namespaces, especially those that are a URN = overlap on internationally-established identifier systems, the best = expertise for evaluating the adequacy of rules and documentation may = lie well outside the usual IETF community. o Even in areas where the IETF is not expert, a careful = review of a namespace specification within the IETF community can = result in useful suggestions that would improve documentation and = sometimes the details of the namespace specification itself. o Whether it would be a good idea or not, the IETF has no = plausible way to prevent people from creating namespaces that use = the same syntax as formal or informal URN ones and using them = without registration or even conformance to URN rules. The desire = for interoperability across the Internet makes such = unregistered or non-conforming namespaces extremely undesirable, but the = IETF (and the broader community) can only encourage registration and conformance, not require either. o Complex and time-consuming registration procedures tend to discourage registrations. Indeed, they sometimes = encourage "why should we bother?" attitudes. There is significant value = in even minimal registrations because they reduce the chances of = the same namespace identifiers accidentally being chosen by = different communities and used for different purposes. The review and approval procedure for URN namespaces is an = enhanced version of the "Designated Expert" IANA Registration model = [RFC5226] with the following properties to supplement or replace those = given in RFC 5266: 1. The purpose of the review process is to improve the = quality and usability of the namespace and its specification. While = the review might result in advice that the particular problem = would be better solved by something other than a URN namespace, = it is not a goal to reject registrations of namespaces that the reviewers find unattractive. To that end, the experts = are encouraged to engage in conversations with applicants = whose goal is mutual education rather than somehow "passing = judgment". 2. The IESG should appoint a small team of experts with = different perspectives to work together in the evaluation and = education process. That team should, if possible, include people = with information science expertise, specifically with = identifiers and classification systems, in addition to those with more traditional IETF expertise. If the team, the IESG, or = IANA consider it necessary, the team will appoint one of its = members to act as a Chair or Coordinator who will be primarily responsible for contacts with IANA and when a single = point of contact is otherwise necessary. 3. Using the template specified in Section 8 and noting that = very little information is actually required but that all of = the requested information is highly desirable, templates for = new namespaces should be submitted to the IANA-maintained = mailing list specified in Section 10. 4. The intent is to have documentation of the same quality = and level of permanence expected of "Specification Required" as = described in RFC 5226. Applicants who cannot supply documentation = of that quality and availability should explain why registration = without it is appropriate. 5. The expert team should reach out to others as needed and, = as suggested above, should engage in conversations with the submitter about any issues that are identified where = improvements are desirable. 6. Unless mutually agreed by the submitters and expert team = in order to better respond to questions or improve the = specification, the length of time between template submission and = registration in the IANA database is not expected to exceed 30 days. ------ Proposed New IANA Considerations ----------- Note that draft-ietf-urnbis-ns-reg-transition has not yet = been=20 posted. It will become the I-D that obsoletes the ISBN, = ISSN,=20 and NBN RFCs as soon as the new templates are ready and = handed=20 off to IANA.=20 10. IANA Considerations This document outlines the processes for registering URN = namespaces, updating and replacing those of RFC 3406. The registration = process has implications for the IANA in terms of registries to be = maintained and the format of, and information contained in, those = registries. In all cases, the IANA ought to assign the appropriate NID = (formal or informal) once the procedures outlined in this document have = been completed. IANA should anticipate some existing registrations and the = associated templates being updated by the appropriate registering = organizations to reflect the information requested in this document. A = separate document specifies the treatment for some existing registries [I-D.ietf-urnbis-ns-reg-transition]. In consultation with = the expert team and relevant Area Directors, IANA should devise a = strategy for preserving registration information that is not updated to = reflect the new template. --==========E605E6B3E1216D65D6F2==========-- From sm@resistor.net Fri Aug 16 21:17:15 2013 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 638A011E80D2 for ; Fri, 16 Aug 2013 21:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH5bBMfgjxfX for ; Fri, 16 Aug 2013 21:17:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE511E8225 for ; Fri, 16 Aug 2013 21:17:11 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H4GX5K017473; Fri, 16 Aug 2013 21:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376713011; bh=wmq7IQRcPFUWeiYUVyQokmO12KH6RJHpBjneWDCM4po=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FPeyUqGRhvwxpdnnFkghqcbnHajgmDmEisWKj2BtJzj5k6FnIz1T1FOtdYlPZaCFl cIb97BxzhvTjy1JJbZzVEU/9/Jpi8UnkEj1e/EPuSpzzAl1iuTPDprH9ARNRfk9EgK tTtGqdltMwWBxpuQ4yzrEqpgKMxUiJ1ti3wu3pyo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376713011; i=@resistor.net; bh=wmq7IQRcPFUWeiYUVyQokmO12KH6RJHpBjneWDCM4po=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4LPpREMB+6nwKcLbS3jKt88t/xViduu6HR4snRBaJhJ2lI7VMVsGK3eh9VX4hFrqK bcxklNyvIeTIsW6QT6AWfcwCKW3iYYnzFKFANh3Pf9QdPxdJEZBEJ85KYl3EZWkTMW 3KjFGX9NYP/IlzPyknunLaWPwo/SEB7HnlGiJGK0= Message-Id: <6.2.5.6.2.20130816210015.0a55cad8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 21:15:45 -0700 To: John C Klensin From: SM In-Reply-To: <04271FE45BACAD7EAB5F71A5@JcK-HP8200.jck.com> References: <520933E4.7030303@stpeter.im> <04271FE45BACAD7EAB5F71A5@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Thomas Narten , urn@ietf.org, Pete Resnick , Harald Alvestrand , Barry Leiba Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 04:17:15 -0000 Hi John, I'll comment on part of the suggested text. "6. Unless mutually agreed by the submitters and expert team in order to better respond to questions or improve the specification, the length of time between template submission and registration in the IANA database is not expected to exceed 30 days." In another context a submitter mentioned that the evaluation period elapsed without the registration request being approved or denied. "Not expected to exceed 30 days" can be overridden by other considerations. There isn't much the submitter can do as the person may be unfamiliar with the process or he/she might be considered as being difficult if he/she invokes process. I suggest: 6. Unless mutually agreed by the submitters and expert team in order to better respond to questions or improve the specification, the length of time to deny the registration should not exceed 30 days. Regards, -sm From john-ietf@jck.com Sat Aug 17 13:20:53 2013 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 2E4B821F9A6A for ; Sat, 17 Aug 2013 13:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkqXHyM0M8Vk for ; Sat, 17 Aug 2013 13:20:45 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 354D121F8F24 for ; Sat, 17 Aug 2013 13:20:44 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VAmz0-000B1J-7x; Sat, 17 Aug 2013 16:20:22 -0400 X-Vipre-Scanned: 03DA8939002C3103DA8A86-TDI Date: Sat, 17 Aug 2013 16:20:20 -0400 From: John C Klensin To: SM Message-ID: In-Reply-To: <6.2.5.6.2.20130816210015.0a55cad8@resistor.net> References: <520933E4.7030303@stpeter.im> <04271FE45BACAD7EAB5F71A5@JcK-HP8200.jck.com> <6.2.5.6.2.20130816210015.0a55cad8@resistor.net> 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 Cc: Thomas Narten , urn@ietf.org, Pete Resnick , Harald Alvestrand , Barry Leiba Subject: Re: [urn] RFC 5226 and enhanced versions of "expert review" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 20:20:53 -0000 --On Friday, 16 August, 2013 21:15 -0700 SM wrote: > Hi John, > > I'll comment on part of the suggested text. > > "6. Unless mutually agreed by the submitters and expert > team in order > to better respond to questions or improve the > specification, the > length of time between template submission and > registration in > the IANA database is not expected to exceed 30 days." > > In another context a submitter mentioned that the evaluation > period elapsed without the registration request being approved > or denied. "Not expected to exceed 30 days" can be overridden > by other considerations. There isn't much the submitter can > do as the person may be unfamiliar with the process or he/she > might be considered as being difficult if he/she invokes > process. I suggest: > > 6. Unless mutually agreed by the submitters and expert > team in order > to better respond to questions or improve the > specification, the > length of time to deny the registration should not > exceed 30 days. In principle, I agree with you. In practice, every time we have tried to write a rule that precise and tie it to a deadline, we've found that it gets us into trouble. Maybe "better respond to questions or improve the specification" is broad enough or "should not" is still value enough, but I think we should be quite careful in going very far down that path. best, john From moore@network-heretics.com Sat Aug 17 14:27:07 2013 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 0467A11E80F5 for ; Sat, 17 Aug 2013 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2KiNA3eadHT for ; Sat, 17 Aug 2013 14:27:01 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B169E11E8218 for ; Sat, 17 Aug 2013 14:27:01 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D86DC2113E for ; Sat, 17 Aug 2013 17:27:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 17 Aug 2013 17:27:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=I39rLKO+UsRjPuELLbE8aw 0+iwo=; b=DtC4wRm4egWCUip0QXadjLEx6why2C1ARxueeutvHUNxnpq97LD01L /FBqesZUJt9fWDjLagmq8vwcSA6W88muvhAeDEYrFIytXBexJd4YqCWEswpnG1sa 2AKckI9duuPhFqJANlD5Gyidm/1xEfGtawqNc7siKIhps7JZVGjAo= X-Sasl-enc: l+NI++qtq+XHdoNRMN2BOHbHnLKtatzuYg0WW/l0mZKq 1376774820 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B305680090; Sat, 17 Aug 2013 17:26:59 -0400 (EDT) Message-ID: <520FEA9B.8080509@network-heretics.com> Date: Sat, 17 Aug 2013 17:26:51 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 21:27:07 -0000 Section 4.3 needs work. The text in -06 is worse than the text in 2141. It is a Very Bad Idea to allow queries and fragments in URNs and not define what they mean. This will lead to conflicts in interpretation of queries and/or fragments between different resolution services and/or different namespaces (and perhaps also different user interfaces) which will then result in inconsistent handling of URNs containing queries and/or fragments. The only interpretation of queries and fragments that is at all consistent with RFC 3986, and still makes sense for URNs, is for queries and fragments to be evaluated entirely in the context of the referenced resource. They must not be interpreted by URN resolution services, and the query and fragment parts of a URN need to be stripped before feeding a URN to a resolution service. Furthermore, more text is needed to explain that even though a URN without a query or fragment is a persistent name (has a persistent binding to whatever it was originally associated with), there is no assurance of persistence for a URN that has a query or fragment portion. Keith > 4.3. Query Component and Fragment Identifier Component > > The URI specification [RFC3986] allows a query component, a fragment > identifier component, or both after the path component of a URI, > where the character '?' is used as a separator to denote the > beginning of the query component and the character '#' is used as a > separator to denote the beginning of the fragment identifier > component. The original URN syntax specification [RFC2141] reserved > the '?' and '#' characters for future developments. This > specification aligns URN syntax with URI syntax by allowing the query > component and fragment identifier component after (not within) the > Namespace Specific String (NSS). > > This specification does not define the applicability and semantics of > the query component or the fragment identifier component in URNs. > Additional specifications might establish these matters for URN- > related services (such as resolution) or for individual URN > namespaces. For example, it is possible that the query component > might be used in requests to URN resolution services, or that the > fragment identifier component might be used to distinguish the > integral parts of resources named by URNs. However, defining such > usage is left to specifications for URN resolution services, > namespace registration requests and specifications for individual > namespaces (which might use some namespace-specific syntax instead of > the URI fragment identifier component), and other appropriate > documentation (such as policy documents governing the management of a > given URN namespace). > > Although URN assignment is often a managed process (see > [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]), the query component or > fragment identifier component can be appended after the NSS once a > URN has been assigned in accordance with the rules for a given > namespace. > From john-ietf@jck.com Sat Aug 17 18:56:10 2013 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 38D1521F9AF8 for ; Sat, 17 Aug 2013 18:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2FIQq9Rzw7X for ; Sat, 17 Aug 2013 18:56:05 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C721F9AEF for ; Sat, 17 Aug 2013 18:56:04 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VAsDo-000BY3-GU; Sat, 17 Aug 2013 21:56:00 -0400 X-Vipre-Scanned: 050DD281002C31050DD3CE-TDI Date: Sat, 17 Aug 2013 21:55:59 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <520FEA9B.8080509@network-heretics.com> References: <520FEA9B.8080509@network-heretics.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 Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 01:56:10 -0000 --On Saturday, 17 August, 2013 17:26 -0400 Keith Moore wrote: > Section 4.3 needs work. The text in -06 is worse than the > text in 2141. > > It is a Very Bad Idea to allow queries and fragments in URNs > and not define what they mean. This will lead to conflicts in > interpretation of queries and/or fragments between different > resolution services and/or different namespaces (and perhaps > also different user interfaces) which will then result in > inconsistent handling of URNs containing queries and/or > fragments. To a certain extent, that is inherent in URIs and, more important, in the notion that different namespaces may actually be different. > The only interpretation of queries and fragments that is at > all consistent with RFC 3986, and still makes sense for URNs, > is for queries and fragments to be evaluated entirely in the > context of the referenced resource. They must not be > interpreted by URN resolution services, and the query and > fragment parts of a URN need to be stripped before feeding a > URN to a resolution service. Ok to the first. I think you will find that a requirement for "stripped before feeding to a resolution service" would simply be ignored in some cases. As with other things, I'll rather explain why some behavior is dangerous and/or provide alternatives than say "don't do this because we said so". The latter merely encourages non-conformance if some namespace defining both or users decide that they have a requirement. > Furthermore, more text is needed to explain that even though a > URN without a query or fragment is a persistent name (has a > persistent binding to whatever it was originally associated > with), there is no assurance of persistence for a URN that has > a query or fragment portion. I have no problem in principle with more text of that type. best, john From moore@network-heretics.com Sat Aug 17 19:14:51 2013 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 62A1B11E81B5 for ; Sat, 17 Aug 2013 19:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7-sZv0UAGOJ for ; Sat, 17 Aug 2013 19:14:46 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3304F11E80E7 for ; Sat, 17 Aug 2013 19:14:46 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D768220E5B; Sat, 17 Aug 2013 22:14:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 17 Aug 2013 22:14:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=yeVYFoLNQw/wKhJFJoPjJM sCqWU=; b=nBO5W7H0s8E4puO11em813jQkmfUcsvip1Tpnkz/spQB5igdW+f72q QzFcumPXQcro1VyDRkLMsKNIdMCEraUyKae3piscrOhpC5KRgV2Oay1qq2qsf3Nv 2uHr8r/UQ7Jhrc/MfXI6D89EIanseurTsfAkZ/q4vCsnk7XhKnHGc= X-Sasl-enc: paGZot+ym3NIN0qK3ypkUDE9v/Io0yQGZIUaBAG3qanK 1376792084 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 06E4EC00E7F; Sat, 17 Aug 2013 22:14:43 -0400 (EDT) Message-ID: <52102E0B.10701@network-heretics.com> Date: Sat, 17 Aug 2013 22:14:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <520FEA9B.8080509@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 02:14:51 -0000 On 08/17/2013 09:55 PM, John C Klensin wrote: > > --On Saturday, 17 August, 2013 17:26 -0400 Keith Moore > wrote: > >> Section 4.3 needs work. The text in -06 is worse than the >> text in 2141. >> >> It is a Very Bad Idea to allow queries and fragments in URNs >> and not define what they mean. This will lead to conflicts in >> interpretation of queries and/or fragments between different >> resolution services and/or different namespaces (and perhaps >> also different user interfaces) which will then result in >> inconsistent handling of URNs containing queries and/or >> fragments. > To a certain extent, that is inherent in URIs and, more > important, in the notion that different namespaces may actually > be different. I disagree that this is inherent, though there are certainly other URIs that have misused query syntax. And I certainly don't think it's desirable for client code to have to know the particulars of how each URN namespace treats fragments and queries. >> The only interpretation of queries and fragments that is at >> all consistent with RFC 3986, and still makes sense for URNs, >> is for queries and fragments to be evaluated entirely in the >> context of the referenced resource. They must not be >> interpreted by URN resolution services, and the query and >> fragment parts of a URN need to be stripped before feeding a >> URN to a resolution service. > Ok to the first. I think you will find that a requirement for > "stripped before feeding to a resolution service" would simply > be ignored in some cases. As long as the resolution service ignores the fragment and/or query, it won't break anything. But we really do want a consistent meaning for URNs across different clients, which means that client handling of URNs containing fragments and/or queries needs to be uniform from one client to the next. Of course, any client implementation is free to violate the specifications, we don't have a police force, etc. But if we don't even write our specifications in such a way as to promote interoperability, that's a failure on our part. > As with other things, I'll rather > explain why some behavior is dangerous and/or provide > alternatives than say "don't do this because we said so". The > latter merely encourages non-conformance if some namespace > defining both or users decide that they have a requirement. How about "Don't do this because if you do you'll be violating the design principle that URNs mean the same thing everywhere"? Keith From L.Svensson@dnb.de Sat Aug 17 19:21:34 2013 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 6CCA411E80E7 for ; Sat, 17 Aug 2013 19:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly5rFBoRps46 for ; Sat, 17 Aug 2013 19:21:27 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 745C111E80D1 for ; Sat, 17 Aug 2013 19:21:27 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 2E0C07EDEA; Sun, 18 Aug 2013 04:17:52 +0200 (CEST) From: "Svensson, Lars" To: John C Klensin , Keith Moore , "urn@ietf.org" Thread-Topic: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: AQHOmFwJTVzGF29mrkyAEAusD7oKJ5mZzrqAgABLMoCAACfWAA== Date: Sun, 18 Aug 2013 02:21:23 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> References: <520FEA9B.8080509@network-heretics.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.219] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 02:21:34 -0000 > > The only interpretation of queries and fragments that is at all > > consistent with RFC 3986, and still makes sense for URNs, is for > > queries and fragments to be evaluated entirely in the > > context of the referenced resource. They must not be > > interpreted by URN resolution services, and the query and fragment > > parts of a URN need to be stripped before feeding a URN to a > > resolution service. >=20 > Ok to the first. I think you will find that a requirement for "stripped = before > feeding to a resolution service" would simply be ignored in some cases.=20 I think that if RFC 2616 can mandate that the fragment portion of an http U= RI is stripped of before sending it to an http server (and implementers see= m to accept that) it should be possible to mandate that fragment and query = are stripped before sending the URI to a resolution service. /Lars From L.Svensson@dnb.de Sat Aug 17 19:27:42 2013 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 8C89911E815C for ; Sat, 17 Aug 2013 19:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny6--qTjYqyS for ; Sat, 17 Aug 2013 19:27:23 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67C11E80D1 for ; Sat, 17 Aug 2013 19:27:23 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 8E5EA7EDEA; Sun, 18 Aug 2013 04:23:48 +0200 (CEST) From: "Svensson, Lars" To: Andrew Newton , "urn@ietf.org" Thread-Topic: Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) Thread-Index: Ac6bunPBcvziABqVQoSfDD0r6PcKVA== Date: Sun, 18 Aug 2013 02:27:20 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.219] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 02:27:42 -0000 > Today begins a two-week working group last call of draft-ietf-urnbis- > rfc2141bis-urn-06.txt. This last call will end Tuesday, 27 August 2013. >=20 > The document can be found here: > http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >=20 > Please review and comment on the draft, even if it is only to say on the > record "I have reviewed this document thoroughly and it looks good." We > would like to have no fewer than five people report that they have taken = a > look at the whole document and reported their findings. This is a late question the range of reserved/forbidden characters to which= I haven't found any discussion on the list (if it has been discussed, coul= d someone please point me to the relevant discussion?). One of the changes between 2141 and 2141bis is that in 2141bis the characte= rs "~" and "&" characters are allowed in an NSS. Has there been any discuss= ion on allowing "/" in the NSS as well. There are use cases where this can = make sense (e. g. embedding DOIs in URNs). Is there a strong reason not to = allow that? Thanks, Lars=20 From moore@network-heretics.com Sat Aug 17 19:28:23 2013 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 A762911E81BB for ; Sat, 17 Aug 2013 19:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW6KX9km+Y7J for ; Sat, 17 Aug 2013 19:28:18 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9560211E81AF for ; Sat, 17 Aug 2013 19:28:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B745520EDF; Sat, 17 Aug 2013 22:28:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 17 Aug 2013 22:28:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=kawwxsWc/XrHpadTSh4Wfm ILCb0=; b=roQI/8n7JKOR6iczMMNnSVsXAMA8jLtw6BVXyiMOJPcm2LaxnQZ/2M 2uRiCOWaR0Em7B95c2XjomgeLfwPyB4JkKbMehQ7cZriV3775AaNYwhbiEDAv097 lXu/c1RLMhPzh2wMOc/GK2ZfxYe4VjxmXSqIirJB56dJ9agX//nZs= X-Sasl-enc: ahcIyAbUyAH8STkUJhJ07MBk2nSxjMF5M9Gz0vtQrAKx 1376792896 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9600D680093; Sat, 17 Aug 2013 22:28:15 -0400 (EDT) Message-ID: <52103136.2040505@network-heretics.com> Date: Sat, 17 Aug 2013 22:28:06 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 02:28:23 -0000 On 08/17/2013 10:21 PM, Svensson, Lars wrote: >>> The only interpretation of queries and fragments that is at all >>> consistent with RFC 3986, and still makes sense for URNs, is for >>> queries and fragments to be evaluated entirely in the >>> context of the referenced resource. They must not be >>> interpreted by URN resolution services, and the query and fragment >>> parts of a URN need to be stripped before feeding a URN to a >>> resolution service. >> Ok to the first. I think you will find that a requirement for "stripped before >> feeding to a resolution service" would simply be ignored in some cases. > I think that if RFC 2616 can mandate that the fragment portion of an http URI is stripped of before sending it to an http server (and implementers seem to accept that) it should be possible to mandate that fragment and query are stripped before sending the URI to a resolution service. There are actually three issues here that I can identify: 1. Consistent interpretation of URNs. Even though there's no assurance of persistence, a URN with a fragment or a query should still mean the same thing no matter where it's being used. 2. Potential conflict between clients, resolution services, and resources about what any particular query string or fragment means. If a resource implements a query engine that accepts arbitrary strings, and the resolution service also interprets certain kinds of queries as indicators that the resolution service should produce a different result, there's a conflict that's not easily resolved. 3. Consistent handling of URNs by clients from one namespace to the next. We accept that different namespaces will probably have different resolution services. But we'd like for clients to be able to handle those differences by looking up resolution services in DNS or some other distributed database, rather than forcing clients to know about the particulars of every specific URN namespace and (in this particular example) how that namespace interprets fragments. Keith From moore@network-heretics.com Sat Aug 17 19:31:26 2013 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 ACB1711E815C for ; Sat, 17 Aug 2013 19:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUDyG630kV1x for ; Sat, 17 Aug 2013 19:31:21 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72921F9C34 for ; Sat, 17 Aug 2013 19:31:21 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1725F2104D for ; Sat, 17 Aug 2013 22:31:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 17 Aug 2013 22:31:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=RiRmKyeqIFCoqlUAdya01O 51N0U=; b=ntMEjM77aibdo+2jn6cyOtJT5vHTsKS2/OkepU288nbPTgeAYPWxao nUElK/nntUG1cHyEAgeLUAMmh2ykSk9uf7hvfBZ8/0UsXFAQfVvzRj0V76fJEv3O g4nL+/Pev2ReQUhuV2zkD8p7p49ymt2BoB8t0z+zWyP9Jlgip3ExE= X-Sasl-enc: JOKN1wBO+F2E5HYUGKnyi59ZCN1iDMWf5Y1ikXY2GEl/ 1376793080 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7AFD96800C4; Sat, 17 Aug 2013 22:31:20 -0400 (EDT) Message-ID: <521031EF.8010504@network-heretics.com> Date: Sat, 17 Aug 2013 22:31:11 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 02:31:26 -0000 On 08/17/2013 10:27 PM, Svensson, Lars wrote: > One of the changes between 2141 and 2141bis is that in 2141bis the characters "~" and "&" characters are allowed in an NSS. Has there been any discussion on allowing "/" in the NSS as well. There are use cases where this can make sense (e. g. embedding DOIs in URNs). Is there a strong reason not to allow that? The best reason I know of is that it's about the only reserved character left which could be used to extend URN syntax, say, to communicate requests to resolution services. Offhand I think this is more important than the ability to embed DOIs in URNs without %-encoding, though I admit to some bias here. DOIs are, after all, an attempt to end-run around IETF standardization. Keith From john-ietf@jck.com Sun Aug 18 08:27:44 2013 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 874B421F9F74 for ; Sun, 18 Aug 2013 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e+MDI6IAP5H for ; Sun, 18 Aug 2013 08:27:39 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 64FAC21F9D4A for ; Sun, 18 Aug 2013 08:27:39 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VB4tD-000Cpo-W2; Sun, 18 Aug 2013 11:27:36 -0400 X-Vipre-Scanned: 0080F406002C310080F553-TDI Date: Sun, 18 Aug 2013 11:27:35 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <521031EF.8010504@network-heretics.com> References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.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 Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 15:27:44 -0000 --On Saturday, 17 August, 2013 22:31 -0400 Keith Moore wrote: >... > DOIs are, after all, an attempt to end-run around IETF > standardization. Only if you believe that every identifier type that might be used on the Internet is either owned by the IETF or an end run around it. Absent firm beliefs that the IETF is in charge of the Internet _and_ that there are no relevant non-Internet uses for digital objects or identifiers, it is at least as sensible to argue that URNs are an attempted end-run around DOIs and their predecessors. And, yes, I know the history. But not only are there multiple versions of it, but it just isn't relevant at this point. john p.s. That doesn't stop me from agreeing that keeping "/" out of NSSs is a good idea (and, indeed, from wondering whether we are really sure that allowing "~" and "&" is necessary. From moore@network-heretics.com Sun Aug 18 08:31:48 2013 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 AA8EF21F9CAE for ; Sun, 18 Aug 2013 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWMlcInXeK1I for ; Sun, 18 Aug 2013 08:31:43 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA8021F9D17 for ; Sun, 18 Aug 2013 08:31:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C10F520E70; Sun, 18 Aug 2013 11:31:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 18 Aug 2013 11:31:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=KcHcWpBwJBj110de+/mq1+ Xp+xk=; b=iCXG7RTo9y64OwHVbtxOLC/hs2YSmXnN2d9NvvQr+9+k7h+kIv26zO OTKEs3hYwpLfs35PHdzlDju8ksMp0507YGzb+f0te0e2/wTQbXGlz3tBEs+10cMc +FfCWSNoi7PK4Xyc078ZVVv74xzqDvuG5BYl52k6n4GxoEBe9IViU= X-Sasl-enc: yRn1wQUx2PZERvjWuExmz3U8HV6vglo28HR+1uxPPONC 1376839902 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E9A8BC00E81; Sun, 18 Aug 2013 11:31:41 -0400 (EDT) Message-ID: <5210E8D2.3000200@network-heretics.com> Date: Sun, 18 Aug 2013 11:31:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 15:31:48 -0000 On 08/18/2013 11:27 AM, John C Klensin wrote: > And, yes, I know the history. But not only are there multiple > versions of it, but it just isn't relevant at this point. I certainly don't pretend that the history can be summarized in one sentence; I'm just trying to be honest about the nature of my bias. > p.s. That doesn't stop me from agreeing that keeping "/" out of > NSSs is a good idea (and, indeed, from wondering whether we are > really sure that allowing "~" and "&" is necessary. I also wonder whether allowing tilde and ampersand are good ideas. To me that looks like an incompatible change that could potentially harm interoperability for existing URNs. Keith From john-ietf@jck.com Sun Aug 18 10:34:21 2013 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 1C14211E8146 for ; Sun, 18 Aug 2013 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deSuxdULTlva for ; Sun, 18 Aug 2013 10:34:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EF5A411E8145 for ; Sun, 18 Aug 2013 10:34:15 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VB6ri-000D1Q-Ou; Sun, 18 Aug 2013 13:34:10 -0400 X-Vipre-Scanned: 00F4D733002C3100F4D880-TDI Date: Sun, 18 Aug 2013 13:34:09 -0400 From: John C Klensin To: Keith Moore Message-ID: In-Reply-To: <5210E8D2.3000200@network-heretics.com> References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> <5210E8D2.3000200@network-heretics.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 Cc: urn@ietf.org Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 17:34:21 -0000 --On Sunday, 18 August, 2013 11:31 -0400 Keith Moore wrote: >... >> p.s. That doesn't stop me from agreeing that keeping "/" out >> of NSSs is a good idea (and, indeed, from wondering whether >> we are really sure that allowing "~" and "&" is necessary. > I also wonder whether allowing tilde and ampersand are good > ideas. To me that looks like an incompatible change that could > potentially harm interoperability for existing URNs. In general, relaxing a previous restriction has no serious ill effects, at least if those restrictions were followed. But I'd like to see, at least, a little more motivation for relaxing it included in the document. However, to expose one of my biases, the whole "some characters are reserved, others are reserved for special purposes except when they are not, and still others aren't reserved unless someone says so, all on a URI scheme type basis" model of character use in URIs has struck me as a bad idea since the beginning and I see this particular set of choices as just a symptom. john From moore@network-heretics.com Sun Aug 18 11:03:16 2013 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 7538111E8171 for ; Sun, 18 Aug 2013 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab0Y1nVd534x for ; Sun, 18 Aug 2013 11:03:11 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0521411E814B for ; Sun, 18 Aug 2013 11:03:11 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DE3AE211CB; Sun, 18 Aug 2013 14:03:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 18 Aug 2013 14:03:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tEF/Wn6CCMeGFGTCJm9691 LxpLE=; b=FzvJfEFbguwN7wgfMSzARwIl3bB0bhBRowB7YMkhOq30zad61XKCTP EU4xdXtdMUEZPPpd4RgXsv7OE9BL6L5CqmmJmjiqpqlrXtqOuPm9899WeDIbi774 jN3XZrPMmTS1dcvG27W7kz+x2u7ObjNfpE2Y4UmO/+Hfuczlajk58= X-Sasl-enc: JUjWm2mbvOL6fPWHy3hZr6T8OO2eCL53209MzlLbt88f 1376848989 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 20B27680193; Sun, 18 Aug 2013 14:03:09 -0400 (EDT) Message-ID: <52110C52.8080507@network-heretics.com> Date: Sun, 18 Aug 2013 14:02:58 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> <5210E8D2.3000200@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:03:16 -0000 On 08/18/2013 01:34 PM, John C Klensin wrote: > > --On Sunday, 18 August, 2013 11:31 -0400 Keith Moore > wrote: > >> ... >>> p.s. That doesn't stop me from agreeing that keeping "/" out >>> of NSSs is a good idea (and, indeed, from wondering whether >>> we are really sure that allowing "~" and "&" is necessary. >> I also wonder whether allowing tilde and ampersand are good >> ideas. To me that looks like an incompatible change that could >> potentially harm interoperability for existing URNs. > In general, relaxing a previous restriction has no serious ill > effects, at least if those restrictions were followed. The principle danger that I see is if there are existing systems that convert some other kind of identifiers to URNs, and they currently percent-encode tildes and ampersands, either for the purpose of coining new URNs or resolving existing identifiers as URNs. If those converters change their behavior to stop encoding tildes and ampersands, lookups of old URNs that were converted with an old converter will fail. If some of those converters change their behavior and others don't, behavior will be inconsistent between different implementations. So I think we need strong justification to remove existing restrictions on characters permitted in URN syntax. And in light of the scenarios described above, a desire to be able to convert existing identifiers to URNs without percent-encoding some of the characters in those identifiers might actually be a good reason to not change those restrictions. Keith From pj@csc.fi Sun Aug 18 23:47:07 2013 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 F14EC11E81FD for ; Sun, 18 Aug 2013 23:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uKTPzFFhzKx for ; Sun, 18 Aug 2013 23:47:07 -0700 (PDT) Received: from smtp1.csc.fi (smtp1.csc.fi [IPv6:2001:708:10:6004::14]) by ietfa.amsl.com (Postfix) with ESMTP id 4109E11E81FE for ; Sun, 18 Aug 2013 23:47:06 -0700 (PDT) Received: from [IPv6:2001:708:10:10:222:68ff:fe1e:5ed1] ([IPv6:2001:708:10:10:222:68ff:fe1e:5ed1]) by smtp1.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id r7J6l21h002961; Mon, 19 Aug 2013 09:47:02 +0300 From: Pekka =?ISO-8859-1?Q?J=E4rvel=E4inen?= To: urn@ietf.org In-Reply-To: <520DC0FF.40207@helsinki.fi> References: <520DC0FF.40207@helsinki.fi> Content-Type: text/plain; charset="UTF-8" Organization: CSC Date: Mon, 19 Aug 2013 09:47:02 +0300 Message-ID: <1376894822.5037.6.camel@sepelrastas.x.csc.fi> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-30.el6) Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=2001:708:10:10:222:68ff:fe1e:5ed1; country=FI X-CanItPRO-Stream: 00_Opt_Out (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Mailman-Approved-At: Mon, 19 Aug 2013 05:48:28 -0700 Cc: panu.kalliokoski@csc.fi, Mika.Wahlroos@csc.fi, "pid@postit.csc.fi" Subject: Re: [urn] Fwd: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 06:48:20 -0000 I have reviewed this document thoroughly and it looks good. Pekka > -------- Original Message -------- > Subject: > [urn] Working Group Last Call of > draft-ietf-urnbis-rfc2141bis-urn-06.txt > Date: > Tue, 13 Aug 2013 15:33:25 -0400 > From: > Andrew Newton > To: > urn@ietf.org > > > All, > > Today begins a two-week working group last call of > draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end > Tuesday, 27 August 2013. > > The document can be found here: > http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > Please review and comment on the draft, even if it is only to say on > the record "I have reviewed this document thoroughly and it looks > good." We would like to have no fewer than five people report that > they have taken a look at the whole document and reported their > findings. > > -andy newton, co-chair > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Pekka Järveläinen CSC - IT Center for Science Ltd. +358 9 457 2467 P.O. BOX 405, FI-02101 Espoo, Finland pj@csc.fi From stpeter@stpeter.im Mon Aug 19 14:42:22 2013 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 4C0E811E8302 for ; Mon, 19 Aug 2013 14:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEBpc76aynpx for ; Mon, 19 Aug 2013 14:42:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD9A11E8300 for ; Mon, 19 Aug 2013 14:42:04 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.46]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70941E8352; Mon, 19 Aug 2013 15:45:19 -0600 (MDT) Message-ID: <52129129.5010803@stpeter.im> Date: Mon, 19 Aug 2013 15:42:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> <5210E8D2.3000200@network-heretics.com> <52110C52.8080507@network-heretics.com> In-Reply-To: <52110C52.8080507@network-heretics.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:42:22 -0000 On 8/18/13 12:02 PM, Keith Moore wrote: > On 08/18/2013 01:34 PM, John C Klensin wrote: >> >> --On Sunday, 18 August, 2013 11:31 -0400 Keith Moore >> wrote: >> >>> ... >>>> p.s. That doesn't stop me from agreeing that keeping "/" out >>>> of NSSs is a good idea (and, indeed, from wondering whether >>>> we are really sure that allowing "~" and "&" is necessary. >>> I also wonder whether allowing tilde and ampersand are good >>> ideas. To me that looks like an incompatible change that could >>> potentially harm interoperability for existing URNs. >> In general, relaxing a previous restriction has no serious ill >> effects, at least if those restrictions were followed. > > The principle danger that I see is if there are existing systems that > convert some other kind of identifiers to URNs, and they currently > percent-encode tildes and ampersands, either for the purpose of coining > new URNs or resolving existing identifiers as URNs. If those > converters change their behavior to stop encoding tildes and ampersands, > lookups of old URNs that were converted with an old converter will > fail. If some of those converters change their behavior and others > don't, behavior will be inconsistent between different implementations. > > So I think we need strong justification to remove existing restrictions > on characters permitted in URN syntax. And in light of the scenarios > described above, a desire to be able to convert existing identifiers to > URNs without percent-encoding some of the characters in those > identifiers might actually be a good reason to not change those > restrictions. With my editor hat on, I see no particular rationale for allowing tilde and ampersand in the updated syntax. As I recall, doing so was a consequence of simplifying the syntax (i.e., borrowing the pchar rule from the URI specification), and that might have been done without full consideration for the consequences. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Aug 19 14:49:00 2013 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 D994811E8302 for ; Mon, 19 Aug 2013 14:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52EiD-OOP2V6 for ; Mon, 19 Aug 2013 14:48:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1A11E82F8 for ; Mon, 19 Aug 2013 14:48:54 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.46]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9ECF7E8352; Mon, 19 Aug 2013 15:52:08 -0600 (MDT) Message-ID: <521292C2.4030305@stpeter.im> Date: Mon, 19 Aug 2013 15:48:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:49:01 -0000 On 8/17/13 8:21 PM, Svensson, Lars wrote: >>> The only interpretation of queries and fragments that is at all >>> consistent with RFC 3986, and still makes sense for URNs, is for >>> queries and fragments to be evaluated entirely in the context of >>> the referenced resource. They must not be interpreted by URN >>> resolution services, and the query and fragment parts of a URN >>> need to be stripped before feeding a URN to a resolution >>> service. >> >> Ok to the first. I think you will find that a requirement for >> "stripped before feeding to a resolution service" would simply be >> ignored in some cases. > > I think that if RFC 2616 can mandate that the fragment portion of an > http URI is stripped of before sending it to an http server (and > implementers seem to accept that) it should be possible to mandate > that fragment and query are stripped before sending the URI to a > resolution service. As I understand it, so far the only use case envisioned for query components (and perhaps also fragment identifier components) is exactly that of passing additional information to a URN resolution service. So I agree with John that people who really want this feature will ignore whatever the spec might say. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Aug 19 14:55:11 2013 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 01BC611E830B for ; Mon, 19 Aug 2013 14:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRxtGThd1WGf for ; Mon, 19 Aug 2013 14:55:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1E11E8167 for ; Mon, 19 Aug 2013 14:54:50 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.46]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3C844E8352; Mon, 19 Aug 2013 15:58:01 -0600 (MDT) Message-ID: <52129423.7090900@stpeter.im> Date: Mon, 19 Aug 2013 15:54:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> In-Reply-To: <521292C2.4030305@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:55:11 -0000 On 8/19/13 3:48 PM, Peter Saint-Andre wrote: > On 8/17/13 8:21 PM, Svensson, Lars wrote: >>>> The only interpretation of queries and fragments that is at all >>>> consistent with RFC 3986, and still makes sense for URNs, is for >>>> queries and fragments to be evaluated entirely in the context of >>>> the referenced resource. They must not be interpreted by URN >>>> resolution services, and the query and fragment parts of a URN >>>> need to be stripped before feeding a URN to a resolution >>>> service. >>> >>> Ok to the first. I think you will find that a requirement for >>> "stripped before feeding to a resolution service" would simply be >>> ignored in some cases. >> >> I think that if RFC 2616 can mandate that the fragment portion of an >> http URI is stripped of before sending it to an http server (and >> implementers seem to accept that) it should be possible to mandate >> that fragment and query are stripped before sending the URI to a >> resolution service. > > As I understand it, so far the only use case envisioned for query > components (and perhaps also fragment identifier components) is exactly > that of passing additional information to a URN resolution service. So I > agree with John that people who really want this feature will ignore > whatever the spec might say. Correction: they will ignore any hard prohibition on using query components and fragment identifier components in that way. Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Mon Aug 19 15:51:35 2013 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 E241121F967F for ; Mon, 19 Aug 2013 15:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-8bHrXyk86W for ; Mon, 19 Aug 2013 15:51:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3A21F8540 for ; Mon, 19 Aug 2013 15:51:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A1E6423BC9; Mon, 19 Aug 2013 18:51:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 19 Aug 2013 18:51:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=dQxwKOATGN+mQmIIrrdDNj AqKrw=; b=UN0RrjO0cYLkyaQmG8PguRQY0iOH4WdA470SBsAbqju2T0M7XZHJiu r7SR4zs7Bd2lGoSdjxJFoVWMhOCTEK5yDILb+vlc4inw2Frxx7eUp0KzprIWADbC Z914nLvzgQom2/ohBWT+v7EyycjoKMT9dBZZ48yH+OXkpsh8ZhkUY= X-Sasl-enc: AdRnqOfHPehAJSvKbwpejCUG5c2VviVcfdSUXqBn9R// 1376952682 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A77CB6800D8; Mon, 19 Aug 2013 18:51:21 -0400 (EDT) Message-ID: <5212A15B.1090302@network-heretics.com> Date: Mon, 19 Aug 2013 18:51:07 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> In-Reply-To: <521292C2.4030305@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 22:51:35 -0000 On 08/19/2013 05:48 PM, Peter Saint-Andre wrote: > As I understand it, so far the only use case envisioned for query > components (and perhaps also fragment identifier components) is exactly > that of passing additional information to a URN resolution service. Why aren't a) Being able to submit a query to the referenced resource (if that resource accepts queries), or b) Being able to reference a fragment of a named resource valid use cases? > So I > agree with John that people who really want this feature will ignore > whatever the spec might say. I don't see how that follows at all. It makes no sense to me whatsoever. Keith From moore@network-heretics.com Mon Aug 19 15:52:38 2013 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 8426B11E8193 for ; Mon, 19 Aug 2013 15:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHl+HUPVjklx for ; Mon, 19 Aug 2013 15:52:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1730611E80F5 for ; Mon, 19 Aug 2013 15:52:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C1D2123BD6; Mon, 19 Aug 2013 18:52:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 19 Aug 2013 18:52:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=+crGz0+MKr7EFcWFfJSajP RwrVU=; b=c/29VTm/lkvM049J5PnYRheyectNougmdWIAcTxtrL+QYRXP75wWcU LyyAO0ISPhNiNFWuiLD1L+JprqeeapsxpuFFT5htfFgzoMdRkV7D+1D0qsi40s7F 0ORsihX8OS2JaaRWIrpGiFJiw6tWoQphRtQYpUZCGP6d0QQnKUg8w= X-Sasl-enc: UZaAPye4D9ygHzmHFHZvEzGdKpAWzzFfd9fT5AfVz/zi 1376952742 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E28096801CF; Mon, 19 Aug 2013 18:52:21 -0400 (EDT) Message-ID: <5212A197.3080502@network-heretics.com> Date: Mon, 19 Aug 2013 18:52:07 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> In-Reply-To: <52129423.7090900@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 22:52:38 -0000 On 08/19/2013 05:54 PM, Peter Saint-Andre wrote: >> > As I understand it, so far the only use case envisioned for query >> > components (and perhaps also fragment identifier components) is exactly >> > that of passing additional information to a URN resolution service. So I >> > agree with John that people who really want this feature will ignore >> > whatever the spec might say. > Correction: they will ignore any hard prohibition on using query > components and fragment identifier components in that way. The most that the standard can do is explain to people why this is a bad idea. But that's easy to do. If people want to build resolution servers that break URNs, I don't pretend that we can stop them. Keith From john-ietf@jck.com Mon Aug 26 12:41:42 2013 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 69B9911E8219 for ; Mon, 26 Aug 2013 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl0vI8PUrkgP for ; Mon, 26 Aug 2013 12:41:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2751111E8214 for ; Mon, 26 Aug 2013 12:41:35 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VE2fN-000CH7-NX for urn@ietf.org; Mon, 26 Aug 2013 15:41:33 -0400 Date: Mon, 26 Aug 2013 15:41:28 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <16145BDFA659E5A78045BF55@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 Subject: [urn] New draft to deal with ISSNs and ISBNs (and, slightly, with NBNs) (draft-ietf-urnbis-ns-reg-transition-00) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:41:42 -0000 Hi. As a follow up to the Berlin discussions, input to 3406bis, and some off-list discussions and thinking, Juha and I have put together a new draft, draft-ietf-urnbis-ns-reg-transition-00. It is short (6 pages total, about 3 or 4 of actual substance) and pretty much self-explanatory. As it notes, it makes some assumptions about what will be in the next version of 3406bis. A new version will be posted if adjustments are needed to conform to that 3406bis-07 and WG discussions. The draft is now in the posting queue, probably awaiting Andy's signoff for posting with a WG draft name. The tentative plan, as the draft indicates, is that this, in combination with new templates, will replace the WG's now-expired ISSN and ISBN URN specifications and IANA registration and obsolete the RFCs on which they are based. The specification for NBNs will be updated and posted soon. Awaiting your comments... john (and Juha) From juha.hakala@helsinki.fi Wed Aug 28 03:54:31 2013 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 E0D3621F8E7C for ; Wed, 28 Aug 2013 03:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KAT1Scz5Ivn for ; Wed, 28 Aug 2013 03:54:20 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4877B21F8BFD for ; Wed, 28 Aug 2013 03:54:18 -0700 (PDT) Received: from [192.168.1.8] ([195.156.89.3]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r7SAsE2H023812 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 28 Aug 2013 13:54:15 +0300 Message-ID: <521DD6D5.3070504@helsinki.fi> Date: Wed, 28 Aug 2013 13:54:13 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> <5210E8D2.3000200@network-heretics.com> <52110C52.8080507@network-heretics.com> In-Reply-To: <52110C52.8080507@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 10:54:31 -0000 Hello, There are two persistent identifiers (Handle and DOI) which always require "/" in the identifier string. Many identifier systems do in theory allow the use of slash, tilde or ampersand. In practice, they seem to be seldom used. For instance, I have never seen an NBN which would have contained anything else but just ASCII characters. Nobody has required that it should be possible to use "~" and "&" without percent encoding. The change to the RFC 2141 NSS charset was done mainly to simplify the specification and because we saw no problem in doing that. Now that a good argument against allowing their use un-encoded has emerged, we can return to the original policy, and require percent encoding of these characters. This should not be a problem, since there does not seem to be a strong use case for allowing them. If there were plans to register a URN namespace to Handle and DOI, we should analyze the pros and cons of allowing "/". Since the Handle / DOI community is not planning to rely on URN resolution we can, for the time being, stick to the current policy as regards "/". All the best, Juha On 18.8.2013 21:02, Keith Moore wrote: > On 08/18/2013 01:34 PM, John C Klensin wrote: >> >> --On Sunday, 18 August, 2013 11:31 -0400 Keith Moore >> wrote: >> >>> ... >>>> p.s. That doesn't stop me from agreeing that keeping "/" out >>>> of NSSs is a good idea (and, indeed, from wondering whether >>>> we are really sure that allowing "~" and "&" is necessary. >>> I also wonder whether allowing tilde and ampersand are good >>> ideas. To me that looks like an incompatible change that could >>> potentially harm interoperability for existing URNs. >> In general, relaxing a previous restriction has no serious ill >> effects, at least if those restrictions were followed. > > The principle danger that I see is if there are existing systems that > convert some other kind of identifiers to URNs, and they currently > percent-encode tildes and ampersands, either for the purpose of > coining new URNs or resolving existing identifiers as URNs. If those > converters change their behavior to stop encoding tildes and > ampersands, lookups of old URNs that were converted with an old > converter will fail. If some of those converters change their > behavior and others don't, behavior will be inconsistent between > different implementations. > > So I think we need strong justification to remove existing > restrictions on characters permitted in URN syntax. And in light of > the scenarios described above, a desire to be able to convert existing > identifiers to URNs without percent-encoding some of the characters in > those identifiers might actually be a good reason to not change those > restrictions. > > Keith > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From juha.hakala@helsinki.fi Wed Aug 28 04:37:28 2013 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 4436D11E8181 for ; Wed, 28 Aug 2013 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v6XEIk16gcu for ; Wed, 28 Aug 2013 04:37:18 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 27A1211E8177 for ; Wed, 28 Aug 2013 04:37:16 -0700 (PDT) Received: from [192.168.1.8] ([195.156.89.3]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r7SBbEFu026284 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 28 Aug 2013 14:37:15 +0300 Message-ID: <521DE0E9.6070001@helsinki.fi> Date: Wed, 28 Aug 2013 14:37:13 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: urn@ietf.org References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> In-Reply-To: <5212A197.3080502@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:37:28 -0000 Hello, On 20.8.2013 1:52, Keith Moore wrote: > On 08/19/2013 05:54 PM, Peter Saint-Andre wrote: >>>> As I understand it, so far the only use case envisioned for query >>>> components (and perhaps also fragment identifier components) is exactly >>>> that of passing additional information to a URN resolution service. So I >>>> agree with John that people who really want this feature will ignore >>>> whatever the spec might say. Yes, it is my intention to specify in rfc2483bis a query syntax for sending resolution service related requests to URN resolvers. If we do not provide such a syntax, there will be a lot of mutually incompatible local solutions for how to use query in this manner, even if rfc2141bis tries to forbid or disencourage the use of query. Alfred Hoenes and myself have started the query specification in rfc2141bis-urn-03. Our idea was to use the service names from RFC 2483, and to complement them with service related parameters; for instance, having just I2C (URI to URC) is not sufficient in the situation where there are multiple metadata formats. >> Correction: they will ignore any hard prohibition on using query >> components and fragment identifier components in that way. Yes, it would be very difficult to convince the URN users why they should not use query, especially when other persistent identifiers are using them already. > The most that the standard can do is explain to people why this is a bad > idea. But that's easy to do. If people want to build resolution > servers that break URNs, I don't pretend that we can stop them. The most that the standard can do is to help people in using query in a useful manner. I don't think that it is our task to tell people why they should not do something that is allowed elsewhere. And we should not write standards in such a way that the users cannot utilize features such as query which are likely to be useful for them. As an aside, this is not the first time there is a need to use query to pass service requests. Information retrieval systems use SRU protocol (http://www.loc.gov/standards/sru/) for sending queries to remote systems like this: http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc In comparison, the planned use of query in the URN context should be relatively simple. But the URN resolvers may need to get smarter. For instance, if I want a resource description instead of the resource itself, the URN resolver may need to extract the required data elements from the URN query into an SRU searchRetrieve URL (if the target system prefers SRU to URN queries). Juha > > Keith > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From L.Svensson@dnb.de Wed Aug 28 07:12:53 2013 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 4251721F9FED for ; Wed, 28 Aug 2013 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsciMVtuRsJS for ; Wed, 28 Aug 2013 07:12:48 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 922CF21F9FF2 for ; Wed, 28 Aug 2013 07:12:44 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id D1B577EA2B; Wed, 28 Aug 2013 16:09:00 +0200 (CEST) From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" Thread-Topic: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: AQHOo+MDVOnPQJ1D10yTQtKcbtrQ+ZmqpXAw Date: Wed, 28 Aug 2013 14:12:42 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> In-Reply-To: <521DE0E9.6070001@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.242] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:12:53 -0000 Juha, All, On Mittwoch, 28. August 2013 13:37, Juha wrote: > On 20.8.2013 1:52, Keith Moore wrote: > > On 08/19/2013 05:54 PM, Peter Saint-Andre wrote: > >>>> As I understand it, so far the only use case envisioned for query > >>>> components (and perhaps also fragment identifier components) is > >>>> exactly that of passing additional information to a URN resolution > >>>> service. So I agree with John that people who really want this > >>>> feature will ignore whatever the spec might say. > Yes, it is my intention to specify in rfc2483bis a query syntax for sendi= ng > resolution service related requests to URN resolvers. If we do not provid= e > such a syntax, there will be a lot of mutually incompatible local solutio= ns for > how to use query in this manner, even if rfc2141bis tries to forbid or > disencourage the use of query. I probably misunderstand how the resolution service and the urn work togeth= er, but this is my understanding: 1) I have a resolution service at http://resolver.example.com/. 2) To that service I pass the URN urn:example:something?here=3Dis&a=3Dquery= #withFragment. 3) In order to tell the service that I want the default URL for the URN I t= ell the service s=3DI2L (service =3D URI to URL). I encode that in a query. The urn already has a query that has no meaning for the resolver. In order = to make the resolver ignore that query (and the fragment), I need to percen= t-encode the characters '?', '&', '=3D' and '#' when passing them on to th= e resolver. Then I can add the query targeted at the resolver, which gives = me http://resolver.example.com/urn:example:something%3Fhere%3Dis%26a%3Dquery%2= 3withFragment?s=3DI2L Then I get a resource back and can apply the query on that resource and the= fragment to the answer to that query. Do I understand that correctly? > Alfred Hoenes and myself have started the query specification in rfc2141b= is- > urn-03. Our idea was to use the service names from RFC 2483, and to > complement them with service related parameters; for instance, having jus= t > I2C (URI to URC) is not sufficient in the situation where there are multi= ple > metadata formats. A side note: is URC formally defined anywhere? > >> Correction: they will ignore any hard prohibition on using query > >> components and fragment identifier components in that way. > Yes, it would be very difficult to convince the URN users why they should= not > use query, especially when other persistent identifiers are using them > already. >=20 > > The most that the standard can do is explain to people why this is a > > bad idea. But that's easy to do. If people want to build resolution > > servers that break URNs, I don't pretend that we can stop them. > The most that the standard can do is to help people in using query in a u= seful > manner. I don't think that it is our task to tell people why they should = not do > something that is allowed elsewhere. And we should not write standards in > such a way that the users cannot utilize features such as query which are > likely to be useful for them. >=20 > As an aside, this is not the first time there is a need to use query to p= ass > service requests. Information retrieval systems use SRU protocol > (http://www.loc.gov/standards/sru/) for sending queries to remote systems > like this: >=20 > http://z3950.loc.gov:7090/voyager?version=3D1.1&operation=3DsearchRetriev= e& > query=3Ddinosaur&maximumRecords=3D1&recordSchema=3Ddc Yes, and the question (to me) still is if the query attached to the urn is = to be applied to the resource identified by that urn or if it is supposed t= o pass information on to a (http-based) resolution service. >=20 > In comparison, the planned use of query in the URN context should be > relatively simple. But the URN resolvers may need to get smarter. For > instance, if I want a resource description instead of the resource itself= , the > URN resolver may need to extract the required data elements from the URN > query into an SRU searchRetrieve URL (if the target system prefers SRU to > URN queries). >=20 > Juha >=20 Lars=20 From juha.hakala@helsinki.fi Wed Aug 28 23:07:32 2013 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 8792A21F9F1B for ; Wed, 28 Aug 2013 23:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etD8EfxzPXve for ; Wed, 28 Aug 2013 23:07:27 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id B68ED21F9F12 for ; Wed, 28 Aug 2013 23:07:22 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r7T67H0R011568 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 29 Aug 2013 09:07:18 +0300 Message-ID: <521EE515.70809@helsinki.fi> Date: Thu, 29 Aug 2013 09:07:17 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 06:07:32 -0000 Hello Lars; all, On 28.8.2013 17:12, Svensson, Lars wrote: > I probably misunderstand how the resolution service and the urn work together, but this is my understanding: The problem we are facing is that currently the URN resolution services are too simple. Just mapping URNs to single or multiple URLs is not enough, because the user requirements are more complex, and we have an increasingly rich technical infrastructure which can supply various things for users. I doubt if anybody understands all the specifics, but at least we have some examples of how things might work out. > > 1) I have a resolution service at http://resolver.example.com/. > 2) To that service I pass the URN urn:example:something?here=is&a=query#withFragment. > 3) In order to tell the service that I want the default URL for the URN I tell the service s=I2L (service = URI to URL). I encode that in a query. > > The urn already has a query that has no meaning for the resolver. In order to make the resolver ignore that query (and the fragment), I need to percent-encode the characters '?', '&', '=' and '#' when passing them on to the resolver. Then I can add the query targeted at the resolver, which gives me > > http://resolver.example.com/urn:example:something%3Fhere%3Dis%26a%3Dquery%23withFragment?s=I2L > > Then I get a resource back and can apply the query on that resource and the fragment to the answer to that query. Do I understand that correctly? It seems to me that you make things a lot more complicated than they need to be. Let us assume that a user wants bibliographic information about a resource in Dublin Core format. The user does not know where to get it, but the user interface she is using gives an opportunity to request metadata about the resource, instead of the thing itself. If the identifier of the resource (which happens to be an e-book) is ISBN 978-952-60-5254-0, we get HTTP URI http://urn.fi/URN:ISBN:978-952-60-5254-0 which, since there is no query, the resolution service will map into the default value of URL https://aaltodoc.aalto.fi/handle/123456789/10927 from where the user can access to document. However, if the user wants metadata about the resource, the HTTP URI above would be something like http://urn.fi/URN:ISBN:978-952-60-5254-0?I2C&recordSchema=dc Please note that there is no point to combine query and fragment unless you want the resource itself. At this point, the URN resolver must know a bibliographic database which is capable of fulfilling this request and how to interact with that system. Assuming that the URN resolver decides to pass the request to the Finnish national bibliography which supports SRU protocol, the HTTP URI needs to be migrated into an SRU query which will look something like this: http://fennica.linneanet.fi:7090/voyager?version=1.1&operation=searchRetrieve& query=9789526052540&maximumRecords=1&recordSchema=dc This SRU search should return the metadata record the user wants, in the form her user interface can deal with. In practice, when we specify I2C-related parameters for query, it is necessary to take the existing search protocols such as Z39.50, SRU and Opensearch into account. Migrating the URN + query into a form the interface in the target system will understand is not rocket science if these target systems support standard APIs. Of course, when technology changes the URN resolver must be updated; if for instance the Finnish national bibliography changes location, goes from Voyager to some other library system or starts to support SRU 1.2 it is necessary to tweak the I2C-related parameters in the resolver. Or, when the national library's digital archive goes live, we need to add that as a new target system into the resolver and specify the services that system will be able to supply, such as providing the most original version of the resource. > >> Alfred Hoenes and myself have started the query specification in rfc2141bis- >> urn-03. Our idea was to use the service names from RFC 2483, and to >> complement them with service related parameters; for instance, having just >> I2C (URI to URC) is not sufficient in the situation where there are multiple >> metadata formats. > A side note: is URC formally defined anywhere? As far as I know, it is neither used nor properly defined. IMO at present Dublin Core has the role that URC was supposed to fulfill. However, from I2C point of view the key thing is that no single metadata format will ever meet everybody's needs. Some people will be happy with simple bibliographic record in DC, some others may want the full record in MARC or ONIX, and still others technical metadata in MIX or preservation metadata in PREMIS. >>>> Yes, and the question (to me) still is if the query attached to the urn is to be applied to the resource identified by that urn or if it is supposed to pass information on to a (http-based) resolution service. My take on this is that the query will pass information to the resolution service, but the resolution service will use that information to facilitate retrieval of something that applies to the identified resource. Unlike query, fragment will be applied to the resource by the web browser or other tool the end user is utilizing. I would rather avoid the complications which may arise if we use the query for passing resolution related information both to the resolver and to the user interface application. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From L.Svensson@dnb.de Thu Aug 29 07:32:51 2013 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 0207A21F9EE5 for ; Thu, 29 Aug 2013 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akmDnDQNIp49 for ; Thu, 29 Aug 2013 07:32:46 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4221F9E83 for ; Thu, 29 Aug 2013 07:32:46 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 064AC7EDDB; Thu, 29 Aug 2013 16:29:02 +0200 (CEST) From: "Svensson, Lars" To: Juha Hakala Thread-Topic: Re: AW: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: Ac6kxJVg/iFH1rgAQ5Ov4s4MnxvP0Q== Date: Thu, 29 Aug 2013 14:32:43 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:32:51 -0000 Juha, all, On Thursday, 29. August 2013 08:07, Juha wrote > On 28.8.2013 17:12, Svensson, Lars wrote: > > I probably misunderstand how the resolution service and the urn work > > together, but this is my understanding: > The problem we are facing is that currently the URN resolution services a= re > too simple. Just mapping URNs to single or multiple URLs is not enough, > because the user requirements are more complex, and we have an > increasingly rich technical infrastructure which can supply various thing= s for > users. >=20 > I doubt if anybody understands all the specifics, but at least we have so= me > examples of how things might work out. OK, I look forward to seeing more examples coming up. > > 1) I have a resolution service at http://resolver.example.com/. > > 2) To that service I pass the URN > urn:example:something?here=3Dis&a=3Dquery#withFragment. > > 3) In order to tell the service that I want the default URL for the URN= I tell > the service s=3DI2L (service =3D URI to URL). I encode that in a query. > > > > The urn already has a query that has no meaning for the resolver. In > > order to make the resolver ignore that query (and the fragment), I > > need to percent-encode the characters '?', '&', '=3D' and '#' when > > passing them on to the resolver. Then I can add the query targeted at > > the resolver, which gives me > > > > > http://resolver.example.com/urn:example:something%3Fhere%3Dis%26a% > 3Dqu > > ery%23withFragment?s=3DI2L > > > > Then I get a resource back and can apply the query on that resource and > > the fragment to the answer to that query. Do I understand that correctl= y? > It seems to me that you make things a lot more complicated than they need > to be. That is entirely possible... > Let us assume that a user wants bibliographic information about a resourc= e in > Dublin Core format. The user does not know where to get it, but the user > interface she is using gives an opportunity to request metadata about the > resource, instead of the thing itself. >=20 > If the identifier of the resource (which happens to be an e-book) is ISBN= 978- > 952-60-5254-0, we get HTTP URI >=20 > http://urn.fi/URN:ISBN:978-952-60-5254-0 >=20 > which, since there is no query, the resolution service will map into the > default value of URL >=20 > https://aaltodoc.aalto.fi/handle/123456789/10927 >=20 > from where the user can access to document. >=20 > However, if the user wants metadata about the resource, the HTTP URI > above would be something like >=20 > http://urn.fi/URN:ISBN:978-952-60-5254-0?I2C&recordSchema=3Ddc >=20 > Please note that there is no point to combine query and fragment unless y= ou > want the resource itself. >=20 > At this point, the URN resolver must know a bibliographic database which = is > capable of fulfilling this request and how to interact with that system. Yes, and IMHO the internals of the resolver should be opaque to the specifi= cation of the service. [...] > This SRU search should return the metadata record the user wants, in the > form her user interface can deal with. When resolving over http we should use that protocol's standard ways of spe= cifying formats, i. e. using a combination of Accept header and profiles to= state that I want DC in XML (or DC in MARC, or RDA in MARCXML). > In practice, when we specify I2C- > related parameters for query, it is necessary to take the existing search > protocols such as Z39.50, SRU and Opensearch into account. Yes, and I guess that the resolver's parameter set will be a subset of the = other protocols' capabilities. =20 > Migrating the URN + query into a form the interface in the target system = will > understand is not rocket science if these target systems support standard > APIs. Of course, when technology changes the URN resolver must be > updated; if for instance the Finnish national bibliography changes locati= on, > goes from Voyager to some other library system or starts to support SRU 1= .2 > it is necessary to tweak the I2C-related parameters in the resolver. Or, = when > the national library's digital archive goes live, we need to add that as = a new > target system into the resolver and specify the services that system will= be > able to supply, such as providing the most original version of the resour= ce. >=20 > > > >> Alfred Hoenes and myself have started the query specification in > >> rfc2141bis- urn-03. Our idea was to use the service names from RFC > >> 2483, and to complement them with service related parameters; for > >> instance, having just I2C (URI to URC) is not sufficient in the > >> situation where there are multiple metadata formats. > > A side note: is URC formally defined anywhere? > As far as I know, it is neither used nor properly defined. IMO at present > Dublin Core has the role that URC was supposed to fulfill. > However, from I2C point of view the key thing is that no single metadata > format will ever meet everybody's needs. Some people will be happy with > simple bibliographic record in DC, some others may want the full record i= n > MARC or ONIX, and still others technical metadata in MIX or preservation > metadata in PREMIS. > >>>> Yes, and the question (to me) still is if the query attached to the = urn is > to be applied to the resource identified by that urn or if it is supposed= to pass > information on to a (http-based) resolution service. > My take on this is that the query will pass information to the resolution > service, but the resolution service will use that information to facilita= te > retrieval of something that applies to the identified resource. >=20 > Unlike query, fragment will be applied to the resource by the web browser > or other tool the end user is utilizing. I would rather avoid the complic= ations > which may arise if we use the query for passing resolution related > information both to the resolver and to the user interface application. If you say that I make things too complicated, this -- to me -- sounds like= a too big simplification. If we allow query (and fragment) in urns, generi= c resolvers need a way to handle that and they need to know how to differ b= etween queries to be handled by the user agent and queries to be handled by= the resolver. Assume that a (future) eBook format allows me access certain information in= the book by executing a query (e. g. searching for a specific word) and th= at a (future) eBook reader can handle that. Then URN:ISBN:978-952-60-5254-0= ?search=3Dsomeword tells my eBook reader to open the identified resource an= d highlight all instances of "someword". Lars=20 From internet-drafts@ietf.org Thu Aug 29 14:49:32 2013 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 4909F21E8089; Thu, 29 Aug 2013 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lFlhG15ydri; Thu, 29 Aug 2013 14:49:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB8711E817D; Thu, 29 Aug 2013 14:49:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829214931.26105.74609.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2013 14:49:31 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 21:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Registration Trans= ition Author(s) : John C Klensin Juha Hakala Filename : draft-ietf-urnbis-ns-reg-transition-00.txt Pages : 6 Date : 2013-08-26 Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 3406bis]] to adopt a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-00 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 juha.hakala@helsinki.fi Fri Aug 30 05:58:45 2013 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 7E45821F9FF9 for ; Fri, 30 Aug 2013 05:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3WJju3Bm19v for ; Fri, 30 Aug 2013 05:58:39 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2821F9B21 for ; Fri, 30 Aug 2013 05:58:37 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r7UCwX8T027605 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 15:58:34 +0300 Message-ID: <522096F9.5000609@helsinki.fi> Date: Fri, 30 Aug 2013 15:58:33 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 12:58:45 -0000 Hello, On 29.8.2013 17:32, Svensson, Lars wrote: >> >> I doubt if anybody understands all the specifics, but at least we have some >> examples of how things might work out. > OK, I look forward to seeing more examples coming up. You have to wait for a while, I plan to provide query examples in rfc2483bis, and that document will only be written once rfc3406bis is (more or less) complete. > >>> At this point, the URN resolver must know a bibliographic database which is >>> capable of fulfilling this request and how to interact with that system. > Yes, and IMHO the internals of the resolver should be opaque to the specification of the service. + 1. For each service, there should be a list of targets (bibliographic databases, digital preservation systems, institutional repositories and so forth) and for each target it is necessary to specify 1-n interfaces. Then, if the interface protocol is for instance SRU, the resolver must know how to create SRU queries for the remote system. > When resolving over http we should use that protocol's standard ways of specifying formats, i. e. using a combination of Accept header and profiles to state that I want DC in XML (or DC in MARC, or RDA in MARCXML). This is to be discussed. In SRU protocol, there is a way to specify the metadata format (recordSchema keyword) and if we use the same mechanism in query, conversion to SRU is very simple and we have a good model for how to specify format in query. We may also invent our own way for query format specification, or rely on some other protocol, or use the approach you recommend. I am not sure which approach would be the best, but using the SRU model might well be the easiest. >> In practice, when we specify I2C- >> related parameters for query, it is necessary to take the existing search >> protocols such as Z39.50, SRU and Opensearch into account. > Yes, and I guess that the resolver's parameter set will be a subset of the other protocols' capabilities. Correct, and the person setting up the resolver must know which features are supported and which ones aren't. >> Unlike query, fragment will be applied to the resource by the web browser >> or other tool the end user is utilizing. I would rather avoid the complications >> which may arise if we use the query for passing resolution related >> information both to the resolver and to the user interface application. > If you say that I make things too complicated, this -- to me -- sounds like a too big simplification. If we allow query (and fragment) in urns, generic resolvers need a way to handle that and they need to know how to differ between queries to be handled by the user agent and queries to be handled by the resolver. > > Assume that a (future) eBook format allows me access certain information in the book by executing a query (e. g. searching for a specific word) and that a (future) eBook reader can handle that. Then URN:ISBN:978-952-60-5254-0?search=someword tells my eBook reader to open the identified resource and highlight all instances of "someword". If we have a valid case for using query to provide guidance to the browser or other user agent, or if we think that such cases may arise in the future, we may add a parameter into the query which indicates that the service request and parameters related to it (if any) should be met by the user agent and that the URN resolver may just ignore the query. For instance, something like URN:ISBN:978-952-60-5254-0?agent=user&search=someword would do, assuming that the user agent knows what to do with it. But my gut feeling is that there is a lot to do to define just the URN resolution services and their parameters. If we start listing also user agent resolution service functionality, we'll have plenty of additional stuff to deal with. An easy way to solve this is to reserve agent=user for user agent related services (default being agent=resolver) and leave the specification of these services to the future implementers. Juha > > Lars > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From john-ietf@jck.com Fri Aug 30 06:46:13 2013 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 D763621F9BFA for ; Fri, 30 Aug 2013 06:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1JRN8rb+E4a for ; Fri, 30 Aug 2013 06:46:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CD21F9FB8 for ; Fri, 30 Aug 2013 06:46:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VFP1J-000Jrr-8w; Fri, 30 Aug 2013 09:45:49 -0400 Date: Fri, 30 Aug 2013 09:45:44 -0400 From: John C Klensin To: Juha Hakala Message-ID: In-Reply-To: <522096F9.5000609@helsinki.fi> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> 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 Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:46:14 -0000 --On Friday, August 30, 2013 15:58 +0300 Juha Hakala wrote: > If we have a valid case for using query to provide guidance to > the browser or other user agent, or if we think that such > cases may arise in the future, we may add a parameter into the > query which indicates that the service request and parameters > related to it (if any) should be met by the user agent and > that the URN resolver may just ignore the query. > > For instance, something like > > URN:ISBN:978-952-60-5254-0?agent=user&search=someword > > would do, assuming that the user agent knows what to do with > it. But my gut feeling is that there is a lot to do to define > just the URN resolution services and their parameters. If we > start listing also user agent resolution service > functionality, we'll have plenty of additional stuff to deal > with. An easy way to solve this is to reserve agent=user for > user agent related services (default being agent=resolver) and > leave the specification of these services to the future > implementers. This seems to me to be a good idea. It preserves the ability to expand things in the future in directions we can only vaguely anticipate today (and that some of us find controversial at best) without committing ourselves to those extensions in the future or requiring that the details be sorted out now. Would it be appropriate to incorporate text into 2141bis and/or 3406bis that explicitly reserves "agent" as a query keyword and specifies "agent=resolver" as the default case? john