From nobody Wed Jul 1 03:19:37 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8AA1B2D00 for ; Wed, 1 Jul 2015 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVp8MQuyd0zr for ; Wed, 1 Jul 2015 03:19:33 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ADE1B2CFB for ; Wed, 1 Jul 2015 03:19:31 -0700 (PDT) Received: from AM2PR07MB0819.eurprd07.prod.outlook.com (10.161.71.142) by AM2PR07MB0596.eurprd07.prod.outlook.com (10.160.33.18) with Microsoft SMTP Server (TLS) id 15.1.207.19; Wed, 1 Jul 2015 10:19:13 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AM2PR07MB0819.eurprd07.prod.outlook.com (10.161.71.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 1 Jul 2015 10:19:12 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0195.005; Wed, 1 Jul 2015 10:19:12 +0000 From: "Hakala, Juha E" To: Melinda Shore , "urn@ietf.org" Thread-Topic: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt Thread-Index: AQHQqv8vPdyydT05JUuwHnufbKXNbZ3GSVDg Date: Wed, 1 Jul 2015 10:19:12 +0000 Message-ID: References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> In-Reply-To: <5584CD07.4050906@gmail.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0819; 5:vsUy9FGuPQRS4SOIIdMawvcPPHBSe6JO9+07PuvtQyjUMBeth3bPCP+pHXLJRJxQQCQYHH9TfM1AAgA/9SJB3JdktBRj9BKdAx0VWspw0pltZ57qCDdH072HA0p0PoExIo4XEPp6o6/4m1kmTAc0tQ==; 24:z11Y3l2PArLYp4EoPm/fRKXLpFMmvIzcHYNIWSfWm33W4XiSS2A3gBqzJ7B4hsKTTT8ZAfZF+M3e49kK6hhU6JyT11f9MvzuXCOylTBcOtw=; 20:VD+RUoEQeGIGlVxlWiFJOKNcrDtBC5411eDEPpSqMO036kQ0Ce63U413sPdfHoQcfO/NgOHRKj8dgI5RJpshTg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0819; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0596; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM2PR07MB0819; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0819; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377424004)(2473001)(164054003)(66654002)(54356999)(76576001)(5002640100001)(87936001)(5001960100002)(5001770100001)(189998001)(106116001)(19580395003)(77156002)(19580405001)(50986999)(76176999)(5003600100002)(102836002)(15975445007)(230783001)(46102003)(74316001)(66066001)(92566002)(15395725005)(2656002)(33656002)(74482002)(2950100001)(2501003)(40100003)(15198665003)(77096005)(122556002)(62966003)(2900100001)(24704002)(10090945008)(19477635001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0819; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 10:19:12.2322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0819 X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0596; 2:bbDZ7x1M6fwlPBody8WrJJICMewvlJw5HMJ3igGkphsNY+GTKxM+r0JONEsNNWQm; 3:mE0LF6nb/vZ1i25DbWxELATb7ttvaqGMonklhVBJVTZffM7kfRmwenAw2/VTuxzQF3bQTrIQbBWGngdumaJeWVZUrC7nwJkCFvF7GtCWcJWi2vBceduNXEj0wBuXZK2B+7daYOI6Irzl4KXDeXAH2Q==; 25:mToqmcoIY7b9yk8JXvCrMgqTGmvADKvTqwjl4Zelhs1pPcu3kIydfeuv4v1iYJvyOLhT4UKPenIy5Q8KvNXb2qTdul4VFwv/A07DdEZLMiKmEUCHoV5EUwyGUePJ4dBOgNCL8HTBNu2yhdHs9A24PeJdbMEsbZ3bHZfqP9VRz01rizQn2ywGZ+qdLVWF+FlVycIqeGhXOGl2yH+iP4h9aMmOMBdB9ZrneTB4CC78s5N7WPw124DFXoHc1Te+3HPMTfbiAlMV3RszGsf5yEtXSA==; 23:KW3QzXoyFIe0DgbAcTIjO5KMSKPu2Csy4WiUAhC+M22V5OZCSNpaEHGdBAyo7YqoDp0XXXYKqJRb6/2LEbPeFAO3bgvteLMKL+tCHg9oT+tPrPwV48j7y7OIhNSZHgeu+OMjmIoaw20txNuiOek4WgSufijznPqY9LYGUdfb/OmhuS9GWYKjTy57YFvvmpSVccdzyOD9m8JP60sUAkMvYr2GpVejkbVCp7OouVZER4iABaXFhzEGLX61mWKX5YPr X-OriginatorOrg: helsinki.fi Archived-At: Cc: Tobias Weigel , "stella@isbn-international.org" , "isabelxiang@hotmail.com" Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 10:19:36 -0000 Hello Melinda; all,=20 I have only a few, mostly minor comments to the latest RFC2141bis draft. As= far as I am concerned, our work is almost done. With this syntax the libra= ry community will be able to do everything we wanted initially to do, and t= hen some more - we did not anticipate the possibility to send resolution re= quests not only to the URN resolvers, but also to the identified resources = themselves or to the applications managing them. Since resources are gettin= g more complex - research data sets are an example of this -, this kind of = enriched functionality may become very useful in the long run. =20 Best regards,=20 Juha ----- =20 In the second paragraph of chapter 3.3 we say that unless defined for a par= ticular namespace, use of q-, r- and f-components is disallowed.=20 This is OK for q- and r-components, but I am not sure if such limitation is= required for F-component, since it has no impact on URN resolution. Moreov= er, F-component is not namespace specific but depends on file format. It ca= n be added to the URN:ISBN if the identified book is e.g. a PDF document, b= ut not to every URN:ISBN (even if the ISBN identifies an e-book; printed bo= oks certainly do not have URI fragments). So it is likely that f-component = can never be applied to all URNs in a certain namespace, but it may be poss= ible to apply it to some URNs in most (actionable) namespaces. =20 The example in the last paragraph of chapter 3.3.1 uses a real ISBN but in = wrong (urn:example) namespace. It is better to replace the ISBN with a rand= om NSS such as "bar", because the URN is not actionable and even if it were= , the fragment would not be applicable. =20 Although libraries' primary intention was to use q-component for passing re= solution related information to URN resolvers, I see no problem in using r-= component instead to this purpose. IMO it is good design to make a differen= ce between requests to resolvers (r-component) and requests to resources th= emselves or applications managing them (q-component). Identified resources = will become increasingly large and complex (scientific data sets are a good= example of this) and it may be necessary to perform various operations be= fore the resource is ready to be sent to the user. =20 In 3.3.3 we say that f-component need not be semantically equivalent to the= URI fragment (component). IMO URN f-component is never semantically equiva= lent with URI fragment since f-component does not have a role in identifica= tion. We avoid making this difference explicit by saying that f-component i= s intended to "distinguish integral parts of resources", which is OK to me = in spite of being somewhat vague. If we want to be more specific we could s= ay that what is being distinguished are physical (encoded) parts of resourc= es. F-component cannot be applied to logical parts of resources unless they= coincide with physical ones. It might be a good idea to be more specific a= bout what f-component does because there is an increasing need within my co= mmunity (libraries, archives and museums) to identify component parts of re= sources. If and when we start developing a new standard identifier for logi= cal components of resources (or if we extend existing systems such as NBN i= n such a way that they do the job) it is important to know precisely what t= he role of f-component is. The present wording does not make that very clea= r.=20 The example in the last paragraph of chapter 3.3.3 uses a real ISBN but in = wrong (urn:example) namespace. It is better to replace the ISBN with a rand= om NSS such as "bar". URN:ISBN is actionable (as http://urn.fi/URN:ISBN:978= -952-10-7060-0) but urn:example is not. In both cases fragment is not appli= cable. =20 =20 In chapter 6 (top of page 14) the draft states that "uniqueness constraint = means that an identifier within the namespace is never assigned to more tha= n one resource and never reassigned to a different resource". We might cons= ider saying "one resource (as defined in the namespace)". Every journal ar= ticle published in e.g. Scientific American has the same ISSN, since in the= URN:ISSN namespace "resources" are serials. In SICI (Serial Item and Contr= ibution Identifier) namespace resources are journal issues and articles. UR= N:NBN could be used for identification of still images within these article= s. In chapter 6.1, the last paragraph of page 16 the draft requires that parti= cular attention should be paid to strings that might imply association with= well-known trademarks. More exhaustive formulation would be "... well-know= n identifier systems and trademarks". In this context we need to be even mo= re concerned about NID strings like "handle" and "doi" than "pepsi".=20 In 7.3.1 (Purpose of the URN registration) it is IMO necessary to provide i= nformation whether resolution services are or will be available, and if so,= what the existing / anticipated services. Registrants might even be able t= o provide examples for q- and r-component semantics and syntax, even if the= y are registered elsewhere later. This question could be the second one ask= ed. =20 It might be a good idea to ask the registrants to clarify formal status of = the identifier (de jure standard / de facto standard / other) and current /= anticipated extent of its use (international / national / local usage). Id= entifiers with statuses "other" and "local usage" should usually have infor= mal than formal namespaces registered for them. The current scope question = (number 4 on the list) is a little bit of a mixed bag as it covers both geo= graphical and organizational issues; it might be better to target scope on = various organizational issues only (public / private sector, book trade / l= ibraries, military / civilian use etc.). =20 As regards the current second (later perhaps third) question on the list, I= would drop the request for telling why it is preferable to use URN rather = than some other technology. IETF does not need to know this. Also asking th= e registrant to explain why existing URN namespaces are not a good fit soun= ds a bit negative. I would ask the registrant to describe how the namespace= to be registered relates to existing URN namespaces and how the new namesp= ace complements them.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: 20. kes=E4kuuta 2015 5:17 > To: urn@ietf.org > Subject: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.= txt >=20 > This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-12 > with an eye towards what, if anything, needs to be resolved before going = to > working group last call. >=20 > Many thanks, and have an excellent weekend. >=20 > Melinda >=20 >=20 > -------- Forwarded Message -------- > Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > Date: Tue, 16 Jun 2015 07:28:05 -0800 > From: Melinda Shore > To: urn@ietf.org >=20 > As you've probably seen, the -12 version of the 2141bis draft was uploade= d > yesterday. We're planning on taking the -13 version to working group las= t > call, and we really need some careful review to make sure that problems w= ith > the document have been identified and addressed. >=20 > This morning John sent out a list of issues that he's identified and that= need > sign-off from the working group. > Some of his questions are somewhat open-ended and we need to avoid rat- > holing, so please be very specific and provide concrete examples where > possible. >=20 > The immediate questions are: >=20 > . Are the current versions of the registration templates > and descriptions complete and clear? > . Are the r-component and q-component examples correct? > . Can someone provide clarifying text about where r-component > and q-component queries go? >=20 > He also raised some broader questions which need discussion but which > perhaps can wait until we've got some level of agreement on what needs to > be done for wglc. >=20 > (John's email is here: > https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) >=20 > Thanks, >=20 > Melinda >=20 > -------- Forwarded Message -------- > Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > Date: Mon, 15 Jun 2015 16:25:26 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: urn@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Uniform Resource Names, Revised Working > Group of the IETF. >=20 > Title : Uniform Resource Names (URNs) > Authors : Peter Saint-Andre > John C Klensin > Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt > Pages : 30 > Date : 2015-06-15 >=20 > Abstract: > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is assigned under the "urn" scheme and a particular URN > namespace, with the intent that the URN will be either a persistent, > location-independent resource identifier or in some cases an abstract > designator that is persistent but that does not identify a resource. > With regard to URN syntax, this document defines the canonical syntax > for URNs (in a way that is consistent with URI syntax), specifies > methods for determining URN equivalence, and discusses URI > conformance. With regard to URN namespaces, this document specifies > a method for defining a URN namespace and associating it with a > namespace identifier, and describes procedures for registering > namespace identifiers with the Internet Assigned Numbers Authority > (IANA). This document obsoletes both RFC 2141 and RFC 3406. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jul 1 05:59:25 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14B1A879F for ; Wed, 1 Jul 2015 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqUlX59zxDP8 for ; Wed, 1 Jul 2015 05:59:22 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020B21A8734 for ; Wed, 1 Jul 2015 05:59:22 -0700 (PDT) Received: by ieqy10 with SMTP id y10so33996440ieq.0 for ; Wed, 01 Jul 2015 05:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G3AoQop7fQImnTfNEoVFKlmhtFlbGPLLt5lEdljv1xQ=; b=Vplf0nei6pFV6mzHpqVfFgx3u6/Z6EfI2L79Wd6Zll9Yfo61wXFa6yUr2ENX+54Eob I8CllbIvvnYmZf7G4nMDKGAXiFNa/TQ1vUm01ENfRcN77KrcRk3jSGtMWY26AuOg0e1L IFTWXaCuQDNCXSLtsGTa5UNzehKO5d4J2ezhSni9PG0oevau+b8TWp/eAJ3HOhkUlJQq 3ia2vE29xEKMBLHK3EEj1/+aM1flq+IqYl253rJ1sDv9dxO/KB/BGSgZzCWS3TMhOhlq l5XPn34tTVzs09UPCO8mpxk02TSDlUj/YPu9lgS829TpywBXx0kjlYGgSjCl/h8NROt1 DwBQ== X-Gm-Message-State: ALoCoQnwZTGZO3XwUT17XIE3gx7F7jwL6y9uPtYS6L18lvW7b/Ix89ek4xghvTZ/nNRiLaF7F3GA X-Received: by 10.107.136.153 with SMTP id s25mr20829966ioi.65.1435755561408; Wed, 01 Jul 2015 05:59:21 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:1827:d172:67de:9f00]) by mx.google.com with ESMTPSA id pg7sm1236253igb.6.2015.07.01.05.59.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 05:59:19 -0700 (PDT) Message-ID: <5593E426.305@andyet.net> Date: Wed, 01 Jul 2015 06:59:18 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Hakala, Juha E" , Melinda Shore , "urn@ietf.org" References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Tobias Weigel , "stella@isbn-international.org" , "isabelxiang@hotmail.com" Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:59:24 -0000 Hi Juha, thank you very much for the careful review. I will try to reply in detail within a few days. Peter On 7/1/15 4:19 AM, Hakala, Juha E wrote: > Hello Melinda; all, > > I have only a few, mostly minor comments to the latest RFC2141bis draft. As far as I am concerned, our work is almost done. With this syntax the library community will be able to do everything we wanted initially to do, and then some more - we did not anticipate the possibility to send resolution requests not only to the URN resolvers, but also to the identified resources themselves or to the applications managing them. Since resources are getting more complex - research data sets are an example of this -, this kind of enriched functionality may become very useful in the long run. > > Best regards, > > Juha > > ----- > > In the second paragraph of chapter 3.3 we say that unless defined for a particular namespace, use of q-, r- and f-components is disallowed. > > This is OK for q- and r-components, but I am not sure if such limitation is required for F-component, since it has no impact on URN resolution. Moreover, F-component is not namespace specific but depends on file format. It can be added to the URN:ISBN if the identified book is e.g. a PDF document, but not to every URN:ISBN (even if the ISBN identifies an e-book; printed books certainly do not have URI fragments). So it is likely that f-component can never be applied to all URNs in a certain namespace, but it may be possible to apply it to some URNs in most (actionable) namespaces. > > The example in the last paragraph of chapter 3.3.1 uses a real ISBN but in wrong (urn:example) namespace. It is better to replace the ISBN with a random NSS such as "bar", because the URN is not actionable and even if it were, the fragment would not be applicable. > > Although libraries' primary intention was to use q-component for passing resolution related information to URN resolvers, I see no problem in using r-component instead to this purpose. IMO it is good design to make a difference between requests to resolvers (r-component) and requests to resources themselves or applications managing them (q-component). Identified resources will become increasingly large and complex (scientific data sets are a good example of this) and it may be necessary to perform various operations before the resource is ready to be sent to the user. > > In 3.3.3 we say that f-component need not be semantically equivalent to the URI fragment (component). IMO URN f-component is never semantically equivalent with URI fragment since f-component does not have a role in identification. We avoid making this difference explicit by saying that f-component is intended to "distinguish integral parts of resources", which is OK to me in spite of being somewhat vague. If we want to be more specific we could say that what is being distinguished are physical (encoded) parts of resources. F-component cannot be applied to logical parts of resources unless they coincide with physical ones. It might be a good idea to be more specific about what f-component does because there is an increasing need within my community (libraries, archives and museums) to identify component parts of resources. If and when we start developing a new standard identifier for logical components of resources (or if we extend existing systems such as NBN in such a way that the y do the job) it is important to know precisely what the role of f-component is. The present wording does not make that very clear. > > The example in the last paragraph of chapter 3.3.3 uses a real ISBN but in wrong (urn:example) namespace. It is better to replace the ISBN with a random NSS such as "bar". URN:ISBN is actionable (as http://urn.fi/URN:ISBN:978-952-10-7060-0) but urn:example is not. In both cases fragment is not applicable. > > In chapter 6 (top of page 14) the draft states that "uniqueness constraint means that an identifier within the namespace is never assigned to more than one resource and never reassigned to a different resource". We might consider saying "one resource (as defined in the namespace)". Every journal article published in e.g. Scientific American has the same ISSN, since in the URN:ISSN namespace "resources" are serials. In SICI (Serial Item and Contribution Identifier) namespace resources are journal issues and articles. URN:NBN could be used for identification of still images within these articles. > > In chapter 6.1, the last paragraph of page 16 the draft requires that particular attention should be paid to strings that might imply association with well-known trademarks. More exhaustive formulation would be "... well-known identifier systems and trademarks". In this context we need to be even more concerned about NID strings like "handle" and "doi" than "pepsi". > > In 7.3.1 (Purpose of the URN registration) it is IMO necessary to provide information whether resolution services are or will be available, and if so, what the existing / anticipated services. Registrants might even be able to provide examples for q- and r-component semantics and syntax, even if they are registered elsewhere later. This question could be the second one asked. > > It might be a good idea to ask the registrants to clarify formal status of the identifier (de jure standard / de facto standard / other) and current / anticipated extent of its use (international / national / local usage). Identifiers with statuses "other" and "local usage" should usually have informal than formal namespaces registered for them. The current scope question (number 4 on the list) is a little bit of a mixed bag as it covers both geographical and organizational issues; it might be better to target scope on various organizational issues only (public / private sector, book trade / libraries, military / civilian use etc.). > > As regards the current second (later perhaps third) question on the list, I would drop the request for telling why it is preferable to use URN rather than some other technology. IETF does not need to know this. Also asking the registrant to explain why existing URN namespaces are not a good fit sounds a bit negative. I would ask the registrant to describe how the namespace to be registered relates to existing URN namespaces and how the new namespace complements them. > > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Melinda Shore >> Sent: 20. kesäkuuta 2015 5:17 >> To: urn@ietf.org >> Subject: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt >> >> This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-12 >> with an eye towards what, if anything, needs to be resolved before going to >> working group last call. >> >> Many thanks, and have an excellent weekend. >> >> Melinda >> >> >> -------- Forwarded Message -------- >> Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt >> Date: Tue, 16 Jun 2015 07:28:05 -0800 >> From: Melinda Shore >> To: urn@ietf.org >> >> As you've probably seen, the -12 version of the 2141bis draft was uploaded >> yesterday. We're planning on taking the -13 version to working group last >> call, and we really need some careful review to make sure that problems with >> the document have been identified and addressed. >> >> This morning John sent out a list of issues that he's identified and that need >> sign-off from the working group. >> Some of his questions are somewhat open-ended and we need to avoid rat- >> holing, so please be very specific and provide concrete examples where >> possible. >> >> The immediate questions are: >> >> . Are the current versions of the registration templates >> and descriptions complete and clear? >> . Are the r-component and q-component examples correct? >> . Can someone provide clarifying text about where r-component >> and q-component queries go? >> >> He also raised some broader questions which need discussion but which >> perhaps can wait until we've got some level of agreement on what needs to >> be done for wglc. >> >> (John's email is here: >> https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) >> >> Thanks, >> >> Melinda >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt >> Date: Mon, 15 Jun 2015 16:25:26 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> CC: urn@ietf.org >> >> >> 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 Names (URNs) >> Authors : Peter Saint-Andre >> John C Klensin >> Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt >> Pages : 30 >> Date : 2015-06-15 >> >> Abstract: >> A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) >> that is assigned under the "urn" scheme and a particular URN >> namespace, with the intent that the URN will be either a persistent, >> location-independent resource identifier or in some cases an abstract >> designator that is persistent but that does not identify a resource. >> With regard to URN syntax, this document defines the canonical syntax >> for URNs (in a way that is consistent with URI syntax), specifies >> methods for determining URN equivalence, and discusses URI >> conformance. With regard to URN namespaces, this document specifies >> a method for defining a URN namespace and associating it with a >> namespace identifier, and describes procedures for registering >> namespace identifiers with the Internet Assigned Numbers Authority >> (IANA). This document obsoletes both RFC 2141 and RFC 3406. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> From nobody Wed Jul 1 15:04:28 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C741AD272 for ; Wed, 1 Jul 2015 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6tRkzXu3jZs for ; Wed, 1 Jul 2015 15:04:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328881ACD53 for ; Wed, 1 Jul 2015 15:04:15 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 178DD20AB5 for ; Wed, 1 Jul 2015 18:04:14 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 01 Jul 2015 18:04:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=hE XGitXQw05IqRb5AvG49vu0IUM=; b=rlwMzugtIVUa9lOiKUAkG7FYb40Kvhm8U7 Kr96KuvQGmeZ0IN8mYgCJZPX2J+I1SvcKG4QJTT/BGDF8uPix1A+sunw2x80E3cm n1bzM3bCjbXoGJFaCLSL8ixd0Mn/GXtVhRE1eU3RepE+OuMoL+ZEfnmvR9BlS82Q Iu5E3KD4w= X-Sasl-enc: bsIIjqK7csPD5WnLiy7EEM8nxZ3VmNlKG/GJdGO/96N7 1435788253 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5075568014F; Wed, 1 Jul 2015 18:04:13 -0400 (EDT) Message-ID: <559463C3.3030905@network-heretics.com> Date: Wed, 01 Jul 2015 18:03:47 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: multipart/alternative; boundary="------------020403000101070309050707" Archived-At: Subject: [urn] review of rfc2141bis-12 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:04:26 -0000 This is a multi-part message in MIME format. --------------020403000101070309050707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In an effort to make my input very concrete, I have suggested text to fix most of the issues I've identified. I'm sorry that this makes this review longer and more difficult to read. Summary of significant problems (no particular significance to the order): 1. The URN syntax grammar is ambiguous, and is inconsistent with the text. 2. The current grammar either requires encoding of queries represented as q-components (without specifying any such encoding) or disallows queries containing '??'. 3. For the sake of interoperability between clients, interpretation of q-component, r-component, and f-component by client software needs to be consistent across all URNs that can resolve to URLs. The current text explicitly permits variant uses of these components, without setting any restrictions on such usage. There are several minor problems also, and a few nits. Comments and suggestion for changes in document order: *1.* Section 3, first paragraph: The rationale for the syntax changes made in this document needs some work. IMO, "Semantic flexibility in the use of URNs within particular applications" is not a desirable goal for URNs, or maybe I just interpret those words differently than intended. We need for URNs to be interpreted uniformly from one (client) application to the next. Perhaps this is just an ambiguity that needs to be cleared up, but the need to have client implementations interpret URN components uniformly from one client to the next (i.e. interoperability) should inherently constrain the semantics of URN components to some degree. (I'll have separate comments for urnbis-semantics.) CURRENT: 3. URN Syntax The syntax of URNs as provided in [RFC2141] was defined before the updated specification of URIs in [RFC3986]. In order to ensure consistency with the URI syntax as well as semantic flexibility in the use of URNs within particular applications (see [I-D.ietf-urnbis-semantics-clarif] for further discussion), this specification does the following: RECOMMENDED: 3. URN Syntax The syntax of URNs as provided in [RFC2141] was defined before the updated specification of URIs in [RFC3986].*In order to facilitate** ** the use of URNs with parameters similar to URI queries and fragments,** ** permit parameters influencing URN resolution to be included with** ** URNs, and ease use of URNs with identifier spaces that**include** ** the '/' character,* this specification does the following: (see also my note below about including "~" and "&" in NSSs) *2.* Problems with grammar in section 3 a) The grammar is both ambiguous (in that it permits the same string to be parsed in multiple/conflicting ways) and inconsistent with the text. In particular, if "??" separates a q-string from r-string, then q-string should not permit "?" to appear twice in succession, and the currently specified grammar does. b) The grammar refers to "q-string" etc. but the text refers to "q-component" etc. I could find no reason for the discrepancy. c) Also, the encoding problem for q-component still remains. See below. CURRENT: namestring = assigned-name [ "?" q-string ] [ "??" r-string ] [ "#" f-string ] assigned-name = "urn" ":" NID ":" NSS NID = (alphanum) 0*30(ldh) (alphanum) ldh = alphanum / "-" NSS = pchar *(pchar / "/") q-string = pchar *( pchar / "/" / "?" ) r-string = pchar *( pchar / "/" / "?" ) f-string = fragment Note: The character "?" can be used without percent-encoding inside q-components, r-components, and f-components. ALTERNATIVE 1 (keep order and separators the same but fix ambiguity): namestring = assigned-name [ "?" q-*component* ] [ "??" r-*component* ] [ "#" f-*component* ] assigned-name = "urn" ":" NID ":" NSS NID = (alphanum) 0*30(ldh) (alphanum) ldh = alphanum / "-" NSS = pchar *(pchar / "/") q-*component* =*pchar *( pchar / "/" / ( "?" ( pchar / "/")))* r-*component* = pchar *( pchar / "/" / "?" ) f-*component* = fragment Note: The character "?" can be used without percent-encoding inside q-components, r-components, and f-components, but two adjacent "?" characters MUST NOT appear inside a q-component. Basically, the change specifies that any "?" in a q-component must be followed by either a pchar or a "/". However, this suggested grammar still has the encoding problem that I mentioned earlier: If q-component is interpreted as a query to be attached to a URL (which is what I thought we had agreed to, at least for URNs that resolve to URLs), there need to be clear rules for copying or converting that q-component text to the URL query text. The above grammar does not permit multiple "?"s to appear adjacent in a q-component. This implies that if there's ever some need to bundle a URN with a query that contains "??", the "??" must somehow be encoded so that (a) it doesn't violate the URN syntax grammar, and (b) the original query string is recovered when bundled with the URL. Simply assuming percent-encoding doesn't fully specify a solution, because while a query that contains "??" could be encoded as %3F%3F, a resource might reasonably interpret %3F%3F differently from "??" This is one reason that I believe it's much simpler, and more likely to be implemented correctly, to not constrain the syntax of q-components beyond the syntax of RFC 3986 queries. And that implies either (a) putting r-component somewhere else than following q-component [e.g. ALTERNATIVE 2 below], or (b) using a different character sequence to separate r-component from q-component [e.g. ALTERNATIVE 3]. Then we can specify that if a URN with a q-component resolves to a URL, the q-component is simply copied to the URL query. RECOMMENDED ALTERNATIVE 2 (switch order of r-component and q-component): namestring = assigned-name *[ "??" r-component ] * *[ "?" q-component ] * [ "#" f-*component* ] assigned-name = "urn" ":" NID ":" NSS NID = (alphanum) 0*30(ldh) (alphanum) ldh = alphanum / "-" NSS = pchar *(pchar / "/") q-*component* *= *( pchar / "/" / "?" )* r-*component* *= pchar *( pchar / "/" )* f-*component* = fragment Note: The character "?" can be used without percent-encoding inside q-components, r-components, and f-components. ALTERNATIVE 3 (use "##" as the introducer for r-component) OOPS: I noticed after I had most of this review complete that this grammar isn't compatible with RFC 3986, since 3986 doesn't permit a fragment to contain "#". I'm leaving this example here anyway to illustrate that there might be more than one way to tweak the grammar to make q-component have identical syntax to query and thus fix the encoding problem. For instance, if we don't really need to permit '&' in an NSS, maybe '&' could be used to introduce r-component. namestring = assigned-name [ "?" q-*component* ] [*"##"* r-*component* ] [ "#" f-*component* ] assigned-name = "urn" ":" NID ":" NSS NID = (alphanum) 0*30(ldh) (alphanum) ldh = alphanum / "-" NSS = pchar *(pchar / "/") q-*component* *= *( pchar / "/" / "?" )* r-*component* = pchar *( pchar / "/" / "?" ) f-*component* = fragment Note: The character "?" can be used without percent-encoding inside q-components, r-components, and f-components. Either alternative 2 or alternative 3 fixes the encoding problem. The order of components in alternative 2 seems more logical to me. Also, both alternative 2 and alternative 3 permit the first character of a q-component to be "?". Note: My suggestions for changes to the remainder of the document assume that alternative 2 replaces the current grammar. Some of the language would need tweaking if a different grammar were chosen. *3.* Section 3.2, 2nd paragraph: This document modifies the syntax of the NSS to allow the following characters: "/", "~", and "&". Are there reasons to permit "~" and "&", and have we sufficiently investigated the implications of doing so? I am wondering whether this will break parsers for no good reason. I have seen URLs which "~" was encoded to "%7E" (even though this shouldn't be necessary) and "&" to "%26" (which also shouldn't be necessary except in a query that uses HTML FORM encoding for HTTP GET). *4. * This document needs to clarify (somewhere) that the change to the URN grammar DOES NOT change encoding rules for existing URN namespaces, if there are existing namespaces that are used outside of the URN context, and in which use any of "/", "~", or "&" are allowed to appear in those names in native form. *5.* Also, something that I think could possibly use a bit more explicit attention in the registration section and perhaps elsewhere: In some sense there are two kinds of URN namespaces: those that exist solely as URNs, and identifier spaces that exist independently of URNs. The latter kind of identifier has a "native" form and a URN form, and its URN namespace registration should specify an algorithm for converting from native form to URN form. Ideally this algorithm produces a distinguished form of its input when converting it to URN format - this makes it easier to build generic services that answer queries for arbitrary URNs. If the algorithm is just to use percent-encoding, that's fine, but IMO this should be explicitly specified in the namespace registration. I don't think we should unilaterally impose this algorithm for all identifier spaces. Client software that just handles URNs doesn't need to worry about this. Such software should always see the URN form of such identifiers and should be able to handle all URNs in a uniform manner. However, software that allows such identifiers to be input directly (e.g. without the urn:xxx: prefix) and converts those identifiers to URNs, needs to be aware of the conversion rules for each URN namespace that it accepts. Anyway, I think it would help to have some background text early in the document that explains this, and one or two specific items in the registration template (I can try to come up with text if desired, but I didn't want to delay this review any longer.) (Also, much of this item is also reflected in the next item. Sorry for not merging them; I wanted to get this out the door.) *6.* Section 3.2, 3rd paragraph: I'm concerned that telling implementors to use %-encoding of disallowed characters that appear in NSS might conflict with an existing URN namespace's encoding rule. Also, %-encoding is a mess, because it's used by so many different layers of software without any clear guidance about which layers undo which portions of the encoding. So I doubt that it's a good idea to specify a uniform rule for how every namespace should encode its native names to URN format; instead, I think that encoding considerations should be part of namespace-specific "canonicalization" rules. As for interoperability: if a URN appears with its urn:nid prefix, software should be able to assume that it's already in appropriate format, with all necessary encoding applied, and apply uniform parsing rules, uniform resolution code, etc. to that URN. But if an identifier appears without a urn:nid prefix, software shouldn't be trying to generate a URN from it, or otherwise treat it as a URN, unless that software knows the namespace-specific rules for encoding those identifiers as URNs. And somewhere, probably in this document, there should be a discussion about the difference between URN format and namespace-specific "native" formats of identifiers. CURRENT: Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "?", and "#"). While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of the generic URI specification [RFC3986]. Note that the "%" character is allowed in the NSS only for the purpose of percent-encoding. RECOMMENDED: Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "?", and "#"). While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS.*Translation** ** of an identifier from its "native" format to URN format is accomplished** by using the canonicalization and encoding methods defined for that**URN namespace in that namespace's registration. Software that is not aware of those URN canonicalization** and encoding rules for the namespace used MUST NOT construct URNs from such identifiers.* *7.* Last paragraph of section 3.2: CURRENT: If a namespace designates one or more characters conforming to the "pchar" rule as having special meaning for that namespace (e.g., "@") and the namespace also uses that character in a literal sense, when used in a literal sense the character MUST be percent-encoded (e.g., "%40"). For related considerations with regard to NID registration, see Section 7.3.2. RECOMMENDED: If a namespace designates one or more characters conforming to the "pchar" rule as having special meaning for that namespace (e.g., "@") and the namespace also uses that character in a literal sense,*that** * *namespace registration MUST specify a means of representing * *its native format* *identifiers as URNs in a way that conforms * *with the URN NSS grammar*.*See Section 7.3.2.* *8.* Section 3.3: I have several problems with this section overall: Defining new URN components without saying anything about semantics (a) invites inconsistent interpretation of those components from one URN namespace to the next (which thwarts the ability to write client software that handles URNs in a uniform way), and (b) also threatens to harm the ability to specify queries and/or fragments with URNs that resolve to URLs. Even though the semantics of q-components and f-components might vary from one URN to the next, it's important for this document to make clear that client software can handle these in a uniform manner. For URNs that resolve to URLs, q-component /always/ maps to the URL query (if that URL scheme supports query), and f-component /always/ maps to the URL fragment. At least for those resources, the semantics of the q-components are defined by those resources, not by the namespace. The semantics of f-components are defined by the media type of the resource, not by its URN namespace. (The namespace can choose to not assign names to resources that don't fit its criteria for interpretation of queries or fragments, but it's important that 2141bis not promote the idea that the interpretation of these components is arbitrary, or namespace-specific.) It's also important to recognize that a resource can quite reasonably have multiple URNs, in the same and/or different namespaces. This must not create a conflict or ambiguity over the interpretation of f-components or q-components with respect to that resource, either when such components appear within URNs or when those components appear in relative references within those resources. If this document is going to focus "almost exclusively" on URN syntax, then we need to have an accompanying document that discusses semantics of the new components. I think that's probably a Bad Idea. Every time a reader has to switch from one document to another, there's a good chance that he'll lose some context, or worse, not bother to read the next document. I'm fine with -semantics-clarif being in a separate document if it just explains why certain decisions were made, but it's probably not a good idea to entirely separate syntax and semantics. So I'm proceeding on the assumption that at least minimum interpretation/semantics of these new components needs to be specified in 2141bis. CURRENT: Because this specification focuses almost exclusively on URN syntax, it does not define the semantics of the q-component, r-component, and f-component for URNs in general. Instead, additional specifications might establish these matters for URN-related services (such as URN resolution) or for individual URN namespaces (e.g., to handle extended information about the resource identified by a URN). Defining the details of such usage is the responsibility of specifications for URN resolution services, namespace registration requests or specifications for individual namespaces, and other appropriate documentation (such as policy documents governing the management of a given URN namespace). Unless specifically defined for a particular namespace after publication of this document, use of these components is disallowed, thereby maintaining strict backward compatibility with namespaces defined in accordance with [RFC2141] and registered in accordance with [RFC3406]. SUGGESTED: *As compared to [RFC2141], this document extends the URN syntax to** * *permit inclusion of three new types of components: q-component,** * *r-component, and f-component.**Because this specification focuses** * *almost exclusively on URN syntax, it does not define detailed** * *semantics for these components for URNs in general. However, each of** * *these components has a distinct role from the others, which is** * *independent of the URN and its namespace, and it is intended that** * *clients be able to handle these components uniformly for all URNs.** * *In general:** ** ** o q-component is intended for parameters to be transmitted to** ** the named resource and interpreted by that resource;** ** ** o r-component is intended for parameters to be transmitted to** ** resolution services and interpreted by those services; and** ** ** o f-component is intended to be interpreted by the client as** ** a specification for a location within or region of, the** ** named resource.** * *The above is true regardless of the URN's namespace.** ** ** Whenever a URN resolves to a URL which may be used to access the** ** resource, there is a more specific interpretation of q-component and** ** f-component: the q-component is copied verbatim to the query portion** ** of the URL (if that URL scheme supports query), and the f-component** ** is copied verbatim to the fragment portion of the URL. This is** ** necessary, among other reasons, so that interpretation of q-component** ** and f-component when associated with URNs, will be consistent with** ** the interpretation of relative references containing query and/or** ** fragment, respectively, within documents which are accessible via URNs.** ** Thus, for resources which may be accessed via a URL, the semantics of** ** q-component are identical to those for queries to that resource, and** ** the semantics of f-components are identical to those of fragments for** ** that resource. Semantics of q-component and f-component for resources** ** that inherently cannot be accessed via a URL are undefined by this** ** document; however, they SHOULD be consistent with the above roles.** ** It is expected that additional specifications will define the semantics** ** of r-components.** ** ** Note: In general, neither syntax nor semantics of q-component or f-component are** defined by, or dependent on, the namespace of the URN. **A particular** namespace might, however, define use of r-components that are specific**to its namespace and supported by the resolution services which that** namespace operates and/or recommends.** ** Any of these components MAY be used with URNs from existing namespaces whether or not the namespace explicitly supports them. As described above, the interpretation of q-component and f-component is namespace- independent. Interpretation of an r-component may be namespace-dependent to some degree if it relies on behavior of a namespace-specific resolution service. If a URN contains r-components that are not defined by the namespace, the meaning of the URN and result of resolution are out of scope for this specification. * Note about the last paragraph of the suggested text as compared to the original: I think it's pointless to forbid use of a *-component with existing URNs, especially when the client's interpretation of such a component should be consistent from one URN to the next anyway. It's unreasonable to expect clients to implement namespace-specific behavior for interpretation of *-components. * **9.* Section 3.3.1 Again, it is important that this document be clear about the appropriate roles for each of these components, and for this document to not encourage inconsistent use of these components from one client application or namespace to another. Also, it's important to be clear that q-components are not passed to URN resolvers, so that they are not taken into account in URN resolution. Also, the example chosen in the -12 text to illustrate use of q-components in this section, while valid, seems likely to cause confusion. While it is certainly possible and reasonable to have a resource that returns metadata about other resources, and for a URN to be assigned to a metadata-returning resource, the example URN doesn't actually specify the URI of a resource for which metadata is to be returned. The reader is likely to presume that the resource named is returning metadata about itself. And while a resource could certainly do that (and it might be a useful convention), that's assuming a lot more than anything that's been specified to date. Normally one does not obtain metadata by querying a resource, one obtains metadata by contacting a resolution service - and the r-component, not the q-component, must be used to pass paramters to the resolution service. CURRENT: 3.3.1. q-component Although the URN q-component has close to the same syntax as the URI query component, the URN q-component need not be semantically equivalent to the URI query component and therefore is called by a different name in this specification to emphasize that the relationship is about syntax only (see also [I-D.ietf-urnbis-semantics-clarif]). The q-component is indicated by the first question mark ("?") character and terminated by a double question mark ("??"), by a number sign ("#") character, or by the end of the URI. The q-string MUST NOT begin with a question mark ("?") since a double question mark is reserved for use by an r-component (Section 3.3.2). The characters slash ("/") and question mark ("?") may represent data within the q-string. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the q-component SHALL NOT be taken into account when determining URN equivalence. The q-component is primarily intended to be used for passing information in requests to the resources identified by a URN or to applications that manage such resources. Consider the hypothetical example of passing parameters to an application that returns metadata about a resource (say, Dublin Core [RFC5013] data about a published book). This could perhaps be accomplished by specifying the desired metadata field (e.g., "description") in the q-component, resulting in URNs such as "urn:example:0-395-36341-1?operation=search&field=description". However, this primary purpose is not intended to forestall other potential uses for q-components. SUGGESTED: (note: the following text assumes the grammar alternative 2 and will need to be changed if a different fix for the grammar is chosen) 3.3.1. q-component * The URN q-component has the same syntax as the URI query component.** ** If a URN resolves to a URL with a scheme that supports a query** ** component, the q-component from the URN is copied verbatim to the** ** query component of the URL.** If the URN does not resolve to a URL,** ** the interpretation of the q-component is undefined by this** ** specification; however, it SHOULD be used to communicate parameters** ** that are interpreted by a resource. The q-component MUST NOT be used** to communicate parameters to a resolution service.** ** ** **The q-component follows the r-component if one exists. The start of the** q-component is indicated by** a** question mark ("?") character and** ** terminated by a number sign ("#") character, or by the end of the URI. * The characters slash ("/") and question mark ("?") may represent data within the q-component. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the q-component SHALL NOT be taken into account when determining URN equivalence.* Similarly, the q-component SHALL NOT be taken into account when resolving a URN and MUST** NOT be passed to a resolution service when querying the service for metadata.* The q-component is*entirely* intended to be used for passing information in requests to the resources identified by a URN or to applications that manage such resources.* Consider the hypothetical example of passing parameters to an application that returns weather** ** maps from different regions and/or for different time periods. This** ** could perhaps be accomplished by specifying lat/long coordinates and** ** dates/times in the URN's q-component.* * **10. * Section 3.3.2 CURRENT: 3.3.2. r-component The URN r-component has no syntactic equivalent in URIs. The r-component is indicated by a double question mark ("??") and terminated by a number sign ("#") character or by the end of the URI. The characters slash ("/") and question mark ("?") may represent data within the r-string. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the r-component SHALL NOT be taken into account when determining URN equivalence. The r-component is primarily intended to be used for passing information in requests to URN resolution services (not, as with the q-component, to the resources identified by a URN or to applications that manage such resources). Consider the hypothetical example of passing parameters to resolution service (say, an ISO alpha-2 country code [ISO3166-1] in order to scope down the preferred country in which to search for a physical copy of a book). This could perhaps be accomplished by specifying the country code in the r-component, resulting in URNs such as "urn:example:0-395-36341-1??cc=uk". However, this primary purpose is not intended to forestall other potential uses for r-components. This document defines only the syntax of the r-component and reserves it for future use. The exact semantics of the r-component and its use in URN resolution protocols are a matter for potential standardization in separate specifications. SUGGESTED: (note: the following assumes the grammar alternative 2 and will need changes for different fixes to the grammar) 3.3.2. r-component The URN r-component has no syntactic equivalent in URIs. * **The r-component precedes any q-component. It is indicated by a double question mark ("??") and terminated by a number sign ("#") character, a question mark ("?"), or by the end of the URI. The slash ("/") may represent data within the r-component, but the question mark ("?") MUST NOT appear in an r-component. If there is a need to represent a question mark in data passed to a resolver, it MUST be percent-encoded in the URN.** ** * Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the r-component SHALL NOT be taken into account when determining URN equivalence.*The r-component SHALL be** ** supplied along with the URN when presenting requests to URN resolution** **services.* The r-component is*entirely* intended to be used for passing information in requests to URN resolution services (not, as with the q-component, to the resources identified by a URN or to applications that manage such resources). Consider the hypothetical example of passing parameters to resolution service (say, an ISO alpha-2 country code [ISO3166-1] in order to scope down the preferred country in which to search for a physical copy of a book). This could perhaps be accomplished by specifying the country code in the r-component, resulting in URNs such as "urn:example:0-395-36341-1??cc=uk". This document defines only the syntax of the r-component and reserves it for future use. The exact semantics of the r-component and its use in URN resolution protocols are a matter for potential standardization in separate specifications. *11.* Section 3.3.3 CURRENT 3.3.3. f-component Although the URN f-component has the same syntax as the URI fragment component, the URN f-component need not be semantically equivalent to the URI fragment component and therefore is called by a different name in this specification to emphasize that the relationship is about syntax only (see also [I-D.ietf-urnbis-semantics-clarif]). The f-component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the f-component SHALL NOT be taken into account when determining URN equivalence. The f-component is primarily intended to distinguish the integral parts of resources named by URNs in particular namespaces. Consider the hypothetical example of obtaining resources that are part of a larger entity (say, the chapters of a book). Each part could be specified in the f-component, resulting in URNs such as "urn:example:978-952-10-7060-0#chapter1". However, this primary purpose is not intended to forestall other potential uses for f-components. ALTERNATIVE 3.3.3. f-component * The URN f-component has the same syntax as the URI fragment component. When a URN containing an f-component resolves to a URL,** ** the f-component from the URN is copied verbatim into the fragment** ** of that URL. Interpretation of the f-component for URNs that do** ** not resolve to URLs is not defined by this specification.** * The f-component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the f-component SHALL NOT be taken into account when determining URN equivalence.* Similarly, the f-component** ** MUST NOT be passed to resolution servers when querying them for resource** locations or metadata.* The f-component is primarily intended to distinguish the integral parts of resources named by URNs in particular namespaces. Consider the hypothetical example of obtaining resources that are part of a larger entity (say, the chapters of a book). Each part could be specified in the f-component, resulting in URNs such as "urn:example:978-952-10-7060-0#chapter1". However, this primary purpose is not intended to forestall other potential uses for f-components* for URNs that do not resolve to network-accessible** ** resources.* *12.* Section 5.3 (NIT) I think it's a bit of a stretch to say what the result of use of a relative reference will be if there's no base URI. CURRENT: If no such base URI exists, use of a relative reference with respect to a URN is an error and will yield results that might be unexpected or not useful. RECOMMENDED: If no such base URI exists, use of a relative reference with respect to a URN is an error.* Client behavior in this case is undefined. * *13.* Section 6, about halfway through Clarify that a resource MAY have more than one URN assigned to it, either in the same namespace or in different namespaces. CURRENT: With regard to global uniqueness, using different NIDs for different collections of identifiers ensures that no two URNs will be the same for different resources, since each collection is required to uniquely assign each identifier. However, a single resource can have more than one URN assigned to it for different purposes (for example, if a book were published in a monograph series, it could have both an ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two URNs referring to the same book). Subject to other constraints, such as those imposed by the URI syntax [RFC3986], the rules of the URN scheme are intended to allow preserving the normal and natural form of identifiers specified elsewhere when they are treated as URN namespaces. RECOMMENDED: With regard to global uniqueness, using different NIDs for different collections of identifiers ensures that no two URNs will be the same for different resources, since each collection is required to uniquely assign each identifier.*However, a single resource MAY have more than one URN assigned to it, either in the same namespace (if the namespace permits it) or** in different namespaces, and either for similar purposes or different**purposes.* (for example, if a book were published in a monograph series, it could have both an ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two URNs referring to the same book). Subject to other constraints, such as those imposed by the URI syntax [RFC3986], the rules of the URN scheme are intended to allow preserving the normal and natural form of identifiers specified elsewhere when they are treated as URN namespaces. *14.* section 6, last paragraph If we're deprecating X- namespaces, fine, but we should reserve namespaces beginning with X- to prevent conflicts with identifiers that might already exist in the wild. CURRENT: Note: [RFC3406] defined a third type of "experimental namespaces", denoted by prefixing the namespace identifier with the string "X-". Consistent with general IETF conclusions about similar approaches [RFC6648], this specification removes the experimental category and syntax. Because experimental namespaces were never registered, removing the experimental category has no impact on the existing registries or future registration procedures. Because they are not registered, strings that refer to existing experimental namespaces are not valid URNs. Truly experimental usages can, of course, employ the 'example' namespace [RFC6963]. RECOMMENDED: Note: [RFC3406] defined a third type of "experimental namespaces", denoted by prefixing the namespace identifier with the string "X-". Consistent with general IETF conclusions about similar approaches [RFC6648], this specification removes the experimental category and syntax. Because experimental namespaces were never registered, removing the experimental category has no impact on the existing registries.*However, to avoid the potential for conflict between** ** previously-allowed unregistered experimental namespaces and** ** namespaces registered in the future, no registrations will be** ** accepted for new namespaces beginning with "X-".*Because they are not registered, strings that refer to experimental namespaces are not valid URNs. Truly experimental usages*MAY*, of course, employ the 'example' namespace [RFC6963]. *15.* Section 6.1 CURRENT: 5. It MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens. Those strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890]. RECOMMENDED: 5. It MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens. Those strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890]. * 6. It MUST NOT start with the string "X-" so that it will not be confused with an experimental namespace previously permitted by [RFC3406], nor conflict** with such a namespace.* --------------020403000101070309050707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit In an effort to make my input very concrete, I have suggested text to fix most of the issues I've identified.  I'm sorry that this makes this review longer and more difficult to read.

Summary of significant problems (no particular significance to the order):

1. The URN syntax grammar is ambiguous, and is inconsistent with the text.
2. The current grammar either requires encoding of queries represented as q-components (without specifying any such encoding) or disallows queries containing '??'.
3. For the sake of interoperability between clients, interpretation of q-component, r-component, and f-component by client software needs to be consistent across all URNs that can resolve to URLs.   The current text explicitly permits variant uses of these components, without setting any restrictions on such usage.  


There are several minor problems also, and a few nits.

Comments and suggestion for changes in document order:

1.  Section 3, first paragraph:

The rationale for the syntax changes made in this document needs some work.

IMO, "Semantic flexibility in the use of URNs within particular applications" is not a desirable goal for URNs, or maybe I just interpret those words differently than intended.  We need for URNs to be interpreted uniformly from one (client) application to the next.   Perhaps this is just an ambiguity that needs to be cleared up, but the need to have client implementations interpret URN components uniformly from one client to the next (i.e. interoperability) should inherently constrain the semantics of URN components to some degree.  

(I'll have separate comments for urnbis-semantics.)

CURRENT:
3.  URN Syntax

   The syntax of URNs as provided in [RFC2141] was defined before the
   updated specification of URIs in [RFC3986].  In order to ensure
   consistency with the URI syntax as well as semantic flexibility in
   the use of URNs within particular applications (see
   [I-D.ietf-urnbis-semantics-clarif] for further discussion), this
   specification does the following:
RECOMMENDED:
3.  URN Syntax

   The syntax of URNs as provided in [RFC2141] was defined before the
   updated specification of URIs in [RFC3986].  In order to facilitate
   the use of URNs with parameters similar to URI queries and fragments,
   permit parameters influencing URN resolution to be included with
   URNs, and ease use of URNs with identifier spaces that include
   the '/' character, this specification does the following:
(see also my note below about including "~" and "&" in NSSs)

2.  Problems with grammar in section 3

a) The grammar is both ambiguous (in that it permits the same string to be parsed in multiple/conflicting ways) and inconsistent with the text.   In particular, if "??" separates a q-string from r-string, then q-string should not permit "?" to appear twice in succession, and the currently specified grammar does.

b) The grammar refers to "q-string" etc. but the text refers to "q-component" etc.  I could find no reason for the discrepancy.

c) Also, the encoding problem for q-component still remains.    See below.

CURRENT:

      namestring    = assigned-name
                      [ "?" q-string ]
                      [ "??" r-string ]
                      [ "#" f-string ]
      assigned-name = "urn" ":" NID ":" NSS
      NID           = (alphanum) 0*30(ldh) (alphanum)
      ldh           = alphanum / "-"
      NSS           = pchar *(pchar / "/")
      q-string      = pchar *( pchar / "/" / "?" )
      r-string      = pchar *( pchar / "/" / "?" )
      f-string      = fragment

   Note: The character "?" can be used without percent-encoding inside
   q-components, r-components, and f-components.

ALTERNATIVE 1 (keep order and separators the same but fix ambiguity):

      namestring    = assigned-name
                      [ "?" q-component ]
                      [ "??" r-component ]
                      [ "#" f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NID           = (alphanum) 0*30(ldh) (alphanum)
      ldh           = alphanum / "-"
      NSS           = pchar *(pchar / "/")
      q-component   = pchar *( pchar / "/" / ( "?" ( pchar / "/")))
      r-component   = pchar *( pchar / "/" / "?" )
      f-component   = fragment

   Note: The character "?" can be used without percent-encoding inside
   q-components, r-components, and f-components, but two adjacent "?" 
   characters MUST NOT appear inside a q-component.

Basically, the change specifies that any "?" in a q-component must be followed by either a pchar or a "/".

However, this suggested grammar still has the encoding problem that I mentioned earlier:   If q-component is interpreted as a query to be attached to a URL (which is what I thought we had agreed to, at least for URNs that resolve to URLs), there need to be clear rules for copying or converting that q-component text to the URL query text.   The above grammar does not permit multiple "?"s to appear adjacent in a q-component.   This implies that if there's ever some need to bundle a URN with a query that contains "??", the "??" must somehow be encoded so that (a) it doesn't violate the URN syntax grammar, and (b) the original query string is recovered when bundled with the URL.

Simply assuming percent-encoding doesn't fully specify a solution, because while a query that contains "??" could be encoded as %3F%3F, a resource might reasonably interpret %3F%3F differently from "??"

This is one reason that I believe it's much simpler, and more likely to be implemented correctly, to not constrain the syntax of q-components beyond the syntax of RFC 3986 queries.   And that implies either (a) putting r-component somewhere else than following q-component [e.g. ALTERNATIVE 2 below], or (b) using a different character sequence to separate r-component from q-component [e.g. ALTERNATIVE 3].   Then we can specify that if a URN with a q-component resolves to a URL, the q-component is simply copied to the URL query.

RECOMMENDED ALTERNATIVE 2 (switch order of r-component and q-component):

      namestring    = assigned-name
                      [ "??" r-component ]
                      [ "?" q-component ]
                      [ "#" f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NID           = (alphanum) 0*30(ldh) (alphanum)
      ldh           = alphanum / "-"
      NSS           = pchar *(pchar / "/")
      q-component   =  *( pchar / "/" / "?" )
      r-component   = pchar *( pchar / "/" )
      f-component   = fragment

   Note: The character "?" can be used without percent-encoding inside
   q-components, r-components, and f-components.

ALTERNATIVE 3 (use "##" as the introducer for r-component)

OOPS:  I noticed after I had most of this review complete that this grammar isn't compatible with RFC 3986, since 3986 doesn't permit a fragment to contain "#".   I'm leaving this example here anyway to illustrate that there might be more than one way to tweak the grammar to make q-component have identical syntax to query and thus fix the encoding problem.  For instance, if we don't really need to permit '&' in an NSS, maybe '&' could be used to introduce r-component.
 


      namestring    = assigned-name
                      [ "?" q-component ]
                      [ "##" r-component ]
                      [ "#" f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NID           = (alphanum) 0*30(ldh) (alphanum)
      ldh           = alphanum / "-"
      NSS           = pchar *(pchar / "/")
      q-component   = *( pchar / "/" / "?" )
      r-component   = pchar *( pchar / "/" / "?" )
      f-component   = fragment

   Note: The character "?" can be used without percent-encoding inside
   q-components, r-components, and f-components.
Either alternative 2 or alternative 3 fixes the encoding problem. The order of components in alternative 2 seems more logical to me.   Also, both alternative 2 and alternative 3 permit the first character of a q-component to be "?".

Note: My suggestions for changes to the remainder of the document assume that alternative 2 replaces the current grammar.   Some of the language would need tweaking if a different grammar were chosen.

3.  Section 3.2, 2nd paragraph:
   This document modifies the syntax of the NSS to allow the following
   characters: "/", "~", and "&".

Are there reasons to permit "~" and "&", and have we sufficiently investigated the implications of doing so?   I am wondering whether this will break parsers for no good reason.  I have seen URLs which "~" was encoded to "%7E" (even though this shouldn't be necessary) and "&" to "%26" (which also shouldn't be necessary except in a query that uses HTML FORM encoding for HTTP GET).

4.  This document needs to clarify (somewhere) that the change to the URN grammar DOES NOT change encoding rules for existing URN namespaces, if there are existing namespaces that are used outside of the URN context, and in which use any of "/", "~", or "&" are allowed to appear in those names in native form.

5.  Also, something that I think could possibly use a bit more explicit attention in the registration section and perhaps elsewhere: In some sense there are two kinds of URN namespaces: those that exist solely as URNs, and identifier spaces that exist independently of URNs.   The latter kind of identifier has a "native" form and a URN form, and its URN namespace registration should specify an algorithm for converting from native form to URN form.   Ideally this algorithm produces a distinguished form of its input when converting it to URN format - this makes it easier to build generic services that answer queries for arbitrary URNs.   If the algorithm is just to use percent-encoding, that's fine, but IMO this should be explicitly specified in the namespace registration. I don't think we should unilaterally impose this algorithm for all identifier spaces.  

Client software that just handles URNs doesn't need to worry about this.   Such software should always see the URN form of such identifiers and should be able to handle all URNs in a uniform manner.   However, software that allows such identifiers to be input directly (e.g. without the urn:xxx: prefix) and converts those identifiers to URNs, needs to be aware of the conversion rules for each URN namespace that it accepts.

Anyway, I think it would help to have some background text early in the document that explains this, and one or two specific items in the registration template

(I can try to come up with text if desired, but I didn't want to delay this review any longer.)

(Also, much of this item is also reflected in the next item.  Sorry for not merging them; I wanted to get this out the door.)

6.  Section 3.2, 3rd paragraph:

I'm concerned that telling implementors to use %-encoding of disallowed characters that appear in NSS might conflict with an existing URN namespace's encoding rule.  Also, %-encoding is a mess, because it's used by so many different layers of software without any clear guidance about which layers undo which portions of the encoding.  So I doubt that it's a good idea to specify a uniform rule for how every namespace should encode its native names to URN format; instead, I think that encoding considerations should be part of namespace-specific "canonicalization" rules.

As for interoperability: if a URN appears with its urn:nid prefix, software should be able to assume that it's already in appropriate format, with all necessary encoding applied, and apply uniform parsing rules, uniform resolution code, etc. to that URN.   But if an identifier appears without a urn:nid prefix, software shouldn't be trying to generate a URN from it, or otherwise treat it as a URN, unless that software knows the namespace-specific rules for encoding those identifiers as URNs.   And somewhere, probably in this document, there should be a discussion about the difference between URN format and namespace-specific "native" formats of identifiers.

CURRENT:
   Depending on the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not allowed by the
   "pchar" production referenced above (e.g., characters outside the
   ASCII range or characters that are reserved in URIs, such as "?", and
   "#").  While such a string might be a valid name, it is not a valid
   URN until it has been translated into a conformant NSS.  Translation
   is done by percent-encoding each disallowed character using the
   method defined in Section 2.1 of the generic URI specification
   [RFC3986].  Note that the "%" character is allowed in the NSS only
   for the purpose of percent-encoding.
RECOMMENDED:

   Depending on the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not allowed by the
   "pchar" production referenced above (e.g., characters outside the
   ASCII range or characters that are reserved in URIs, such as "?", and
   "#").  While such a string might be a valid name, it is not a valid
   URN until it has been translated into a conformant NSS.  Translation
   of an identifier from its "native" format to URN format is 
   accomplished by using the canonicalization and encoding methods
   defined for that URN namespace in that namespace's registration.
   Software that is not aware of those URN canonicalization and 
   encoding rules for the namespace used MUST NOT construct URNs
   from such identifiers.

7. Last paragraph of section 3.2:

CURRENT:
   If a namespace designates one or more characters conforming to the
   "pchar" rule as having special meaning for that namespace (e.g., "@")
   and the namespace also uses that character in a literal sense, when
   used in a literal sense the character MUST be percent-encoded (e.g.,
   "%40").  For related considerations with regard to NID registration,
   see Section 7.3.2.

RECOMMENDED:

   If a namespace designates one or more characters conforming to the
   "pchar" rule as having special meaning for that namespace (e.g., "@")
   and the namespace also uses that character in a literal sense, that 
   namespace registration MUST specify a means of representing
   its native format identifiers as URNs in a way that conforms
   with the URN NSS grammar.   See Section 7.3.2.

8. Section 3.3:

I have several problems with this section overall:

Defining new URN components without saying anything about semantics (a) invites inconsistent interpretation of those components from one URN namespace to the next (which thwarts the ability to write client software that handles URNs in a uniform way), and (b) also threatens to harm the ability to specify queries and/or fragments with URNs that resolve to URLs.

Even though the semantics of q-components and f-components might vary from one URN to the next, it's important for this document to make clear that client software can handle these in a uniform manner.  For URNs that resolve to URLs, q-component always maps to the URL query (if that URL scheme supports query), and f-component always maps to the URL fragment.  At least for those resources, the semantics of the q-components are defined by those resources, not by the namespace.  The semantics of f-components are defined by the media type of the resource, not by its URN namespace.   (The namespace can choose to not assign names to resources that don't fit its criteria for interpretation of queries or fragments, but it's important that 2141bis not promote the idea that the interpretation of these components is arbitrary, or namespace-specific.) 

It's also important to recognize that a resource can quite reasonably have multiple URNs, in the same and/or different namespaces.  This must not create a conflict or ambiguity over the interpretation of f-components or q-components with respect to that resource, either when such components appear within URNs or when those components appear in relative references within those resources. 

If this document is going to focus "almost exclusively" on URN syntax, then we need to have an accompanying document that discusses semantics of the new components.  I think that's probably a Bad Idea.   Every time a reader has to switch from one document to another, there's a good chance that he'll lose some context, or worse, not bother to read the next document.   I'm fine with -semantics-clarif being in a separate document if it just explains why certain decisions were made, but it's probably not a good idea to entirely separate syntax and semantics.   So I'm proceeding on the assumption that at least minimum interpretation/semantics of these new components needs to be specified in 2141bis.


CURRENT:

   Because this specification focuses almost exclusively on URN syntax,
   it does not define the semantics of the q-component, r-component, and
   f-component for URNs in general.  Instead, additional specifications
   might establish these matters for URN-related services (such as URN
   resolution) or for individual URN namespaces (e.g., to handle
   extended information about the resource identified by a URN).
   Defining the details of such usage is the responsibility of
   specifications for URN resolution services, namespace registration
   requests or specifications for individual namespaces, and other
   appropriate documentation (such as policy documents governing the
   management of a given URN namespace).

   Unless specifically defined for a particular namespace after
   publication of this document, use of these components is disallowed,
   thereby maintaining strict backward compatibility with namespaces
   defined in accordance with [RFC2141] and registered in accordance
   with [RFC3406].

SUGGESTED:

   As compared to [RFC2141], this document extends the URN syntax to
   permit inclusion of three new types of components: q-component,
   r-component, and f-component.  Because this specification focuses 
   almost exclusively on URN syntax, it does not define detailed 
   semantics for these components for URNs in general.  However, each of 
   these components has a distinct role from the others, which is
   independent of the URN and its namespace, and it is intended that 
   clients be able to handle these components uniformly for all URNs.   
   In general: 

       o  q-component is intended for parameters to be transmitted to 
          the named resource and interpreted by that resource; 

       o  r-component is intended for parameters to be transmitted to 
          resolution services and interpreted by those services; and 

       o  f-component is intended to be interpreted by the client as 
          a specification for a location within or region of, the
          named resource.

   The above is true regardless of the URN's namespace.

   Whenever a URN resolves to a URL which may be used to access the
   resource, there is a more specific interpretation of q-component and 
   f-component: the q-component is copied verbatim to the query portion
   of the URL (if that URL scheme supports query), and the f-component
   is copied verbatim to the fragment portion of the URL.   This is
   necessary, among other reasons, so that interpretation of q-component
   and f-component when associated with URNs, will be consistent with
   the interpretation of relative references containing query and/or 
   fragment, respectively, within documents which are accessible via URNs.
   Thus, for resources which may be accessed via a URL, the semantics of 
   q-component are identical to those for queries to that resource, and 
   the semantics of f-components are identical to those of fragments for
   that resource.   Semantics of q-component and f-component for resources
   that inherently cannot be accessed via a URL are undefined by this 
   document; however, they SHOULD be consistent with the above roles.  
   It is expected that additional specifications will define the semantics
   of r-components.

   Note:  In general, neither syntax nor semantics of q-component or 
   f-component are defined by, or dependent on, the namespace of the URN.  
   A particular namespace might, however, define use of r-components that 
   are specific to its namespace and supported by the resolution services
   which that namespace operates and/or recommends.

   Any of these components MAY be used with URNs from existing namespaces
   whether or not the namespace explicitly supports them.  As described 
   above, the interpretation of q-component and f-component is namespace-
   independent.  Interpretation of an r-component may be namespace-dependent
   to some degree if it relies on behavior of a namespace-specific 
   resolution service.   If a URN contains r-components that are not 
   defined by the namespace, the meaning of the URN and result of resolution
   are out of scope for this specification.

Note about the last paragraph of the suggested text as compared to the original: I think it's pointless to forbid use of a *-component with existing URNs, especially when the client's interpretation of such a component should be consistent from one URN to the next anyway.   It's unreasonable to expect clients to implement namespace-specific behavior for interpretation of *-components.

9. Section 3.3.1

Again, it is important that this document be clear about the appropriate roles for each of these components, and for this document to not encourage inconsistent use of these components from one client application or namespace to another.   Also, it's important to be clear that q-components are not passed to URN resolvers, so that they are not taken into account in URN resolution.

Also, the example chosen in the -12 text to illustrate use of q-components in this section, while valid, seems likely to cause confusion.  While it is certainly possible and reasonable to have a resource that returns metadata about other resources, and for a URN to be assigned to a metadata-returning resource, the example URN doesn't actually specify the URI of a resource for which metadata is to be returned.   The reader is likely to presume that the resource named is returning metadata about itself.  And while a resource could certainly do that (and it might be a useful convention), that's assuming a lot more than anything that's been specified to date.  Normally one does not obtain metadata by querying a resource, one obtains metadata by contacting a resolution service - and the r-component, not the q-component, must be used to pass paramters to the resolution service.

CURRENT:
3.3.1.  q-component

   Although the URN q-component has close to the same syntax as the URI
   query component, the URN q-component need not be semantically
   equivalent to the URI query component and therefore is called by a
   different name in this specification to emphasize that the
   relationship is about syntax only (see also
   [I-D.ietf-urnbis-semantics-clarif]).

   The q-component is indicated by the first question mark ("?")
   character and terminated by a double question mark ("??"), by a
   number sign ("#") character, or by the end of the URI.  The q-string
   MUST NOT begin with a question mark ("?") since a double question
   mark is reserved for use by an r-component (Section 3.3.2).  The
   characters slash ("/") and question mark ("?") may represent data
   within the q-string.  Note that characters outside the ASCII range
   [RFC20] MUST be percent-encoded using the method defined in
   Section 2.1 of the generic URI specification [RFC3986].

   As described under Section 4, the q-component SHALL NOT be taken into
   account when determining URN equivalence.

   The q-component is primarily intended to be used for passing
   information in requests to the resources identified by a URN or to
   applications that manage such resources.  Consider the hypothetical
   example of passing parameters to an application that returns metadata
   about a resource (say, Dublin Core [RFC5013] data about a published
   book).  This could perhaps be accomplished by specifying the desired
   metadata field (e.g., "description") in the q-component, resulting in
   URNs such as
   "urn:example:0-395-36341-1?operation=search&field=description".
   However, this primary purpose is not intended to forestall other
   potential uses for q-components.

SUGGESTED:

(note: the following text assumes the grammar alternative 2 and will need
to be changed if a different fix for the grammar is chosen)  
3.3.1.  q-component

   The URN q-component has the same syntax as the URI query component. 
   If a URN resolves to a URL with a scheme that supports a query 
   component, the q-component from the URN is copied verbatim to the
   query component of the URL.  If the URN does not resolve to a URL,
   the interpretation of the q-component is undefined by this 
   specification; however, it SHOULD be used to communicate parameters
   that are interpreted by a resource.  The q-component MUST NOT be
   used to communicate parameters to a resolution service.

   The q-component follows the r-component if one exists.  The start of
   the q-component is indicated by a question mark ("?") character and 
   terminated by a number sign ("#") character, or by the end of the URI.
   The characters slash ("/") and question mark ("?") may represent data
   within the q-component.  Note that characters outside the ASCII range
   [RFC20] MUST be percent-encoded using the method defined in
   Section 2.1 of the generic URI specification [RFC3986].

   As described under Section 4, the q-component SHALL NOT be taken into
   account when determining URN equivalence.   Similarly, the q-component SHALL
   NOT be taken into account when resolving a URN and MUST NOT be passed
   to a resolution service when querying the service for metadata.

   The q-component is entirely intended to be used for passing
   information in requests to the resources identified by a URN or to
   applications that manage such resources.  Consider the hypothetical
   example of passing parameters to an application that returns weather
   maps from different regions and/or for different time periods.  This
   could perhaps be accomplished by specifying lat/long coordinates and
   dates/times in the URN's q-component.
   

10.  Section 3.3.2

CURRENT:

3.3.2.  r-component

   The URN r-component has no syntactic equivalent in URIs.

   The r-component is indicated by a double question mark ("??") and
   terminated by a number sign ("#") character or by the end of the URI.
   The characters slash ("/") and question mark ("?") may represent data
   within the r-string.  Note that characters outside the ASCII range
   [RFC20] MUST be percent-encoded using the method defined in
   Section 2.1 of the generic URI specification [RFC3986].

   As described under Section 4, the r-component SHALL NOT be taken into
   account when determining URN equivalence.

   The r-component is primarily intended to be used for passing
   information in requests to URN resolution services (not, as with the
   q-component, to the resources identified by a URN or to applications
   that manage such resources).  Consider the hypothetical example of
   passing parameters to resolution service (say, an ISO alpha-2 country
   code [ISO3166-1] in order to scope down the preferred country in
   which to search for a physical copy of a book).  This could perhaps
   be accomplished by specifying the country code in the r-component,
   resulting in URNs such as "urn:example:0-395-36341-1??cc=uk".
   However, this primary purpose is not intended to forestall other
   potential uses for r-components.

   This document defines only the syntax of the r-component and reserves
   it for future use.  The exact semantics of the r-component and its
   use in URN resolution protocols are a matter for potential
   standardization in separate specifications.

SUGGESTED:

(note: the following assumes the grammar alternative 2 and will need
changes for different fixes to the grammar)  
3.3.2.  r-component

   The URN r-component has no syntactic equivalent in URIs.

   The r-component precedes any q-component.   It is indicated by a double 
   question mark ("??") and terminated by a number sign ("#") character, a
   question mark ("?"), or by the end of the URI.   The slash ("/") may 
   represent data within the r-component, but the question mark ("?") MUST
   NOT appear in an r-component.   If there is a need to represent a question
   mark in data passed to a resolver, it MUST be percent-encoded in the URN.  
   Note that characters outside the ASCII range
   [RFC20] MUST be percent-encoded using the method defined in
   Section 2.1 of the generic URI specification [RFC3986].

   As described under Section 4, the r-component SHALL NOT be taken into
   account when determining URN equivalence. The r-component SHALL be 
   supplied along with the URN when presenting requests to URN 
   resolution services.

   The r-component is entirely intended to be used for passing
   information in requests to URN resolution services (not, as with the
   q-component, to the resources identified by a URN or to applications
   that manage such resources).  Consider the hypothetical example of
   passing parameters to resolution service (say, an ISO alpha-2 country
   code [ISO3166-1] in order to scope down the preferred country in
   which to search for a physical copy of a book).  This could perhaps
   be accomplished by specifying the country code in the r-component,
   resulting in URNs such as "urn:example:0-395-36341-1??cc=uk".
   
   This document defines only the syntax of the r-component and reserves
   it for future use.  The exact semantics of the r-component and its
   use in URN resolution protocols are a matter for potential
   standardization in separate specifications.

11.  Section 3.3.3

CURRENT
3.3.3.  f-component

   Although the URN f-component has the same syntax as the URI fragment
   component, the URN f-component need not be semantically equivalent to
   the URI fragment component and therefore is called by a different
   name in this specification to emphasize that the relationship is
   about syntax only (see also [I-D.ietf-urnbis-semantics-clarif]).

   The f-component is indicated by the presence of a number sign ("#")
   character and terminated by the end of the URI.  Note that characters
   outside the ASCII range [RFC20] MUST be percent-encoded using the
   method defined in Section 2.1 of the generic URI specification
   [RFC3986].

   As described under Section 4, the f-component SHALL NOT be taken into
   account when determining URN equivalence.

   The f-component is primarily intended to distinguish the integral
   parts of resources named by URNs in particular namespaces.  Consider
   the hypothetical example of obtaining resources that are part of a
   larger entity (say, the chapters of a book).  Each part could be
   specified in the f-component, resulting in URNs such as
   "urn:example:978-952-10-7060-0#chapter1".  However, this primary
   purpose is not intended to forestall other potential uses for
   f-components.

ALTERNATIVE

3.3.3.  f-component

   The URN f-component has the same syntax as the URI fragment
   component.   When a URN containing an f-component resolves to a URL,
   the f-component from the URN is copied verbatim into the fragment
   of that URL.  Interpretation of the f-component for URNs that do
   not resolve to URLs is not defined by this specification.

   The f-component is indicated by the presence of a number sign ("#")
   character and terminated by the end of the URI.  Note that characters
   outside the ASCII range [RFC20] MUST be percent-encoded using the
   method defined in Section 2.1 of the generic URI specification
   [RFC3986].

   As described under Section 4, the f-component SHALL NOT be taken into
   account when determining URN equivalence.   Similarly, the f-component
   MUST NOT be passed to resolution servers when querying them for 
   resource locations or metadata.

   The f-component is primarily intended to distinguish the integral
   parts of resources named by URNs in particular namespaces.  Consider
   the hypothetical example of obtaining resources that are part of a
   larger entity (say, the chapters of a book).  Each part could be
   specified in the f-component, resulting in URNs such as
   "urn:example:978-952-10-7060-0#chapter1".  However, this primary
   purpose is not intended to forestall other potential uses for
   f-components for URNs that do not resolve to network-accessible
   resources.
12.  Section 5.3

(NIT) I think it's a bit of a stretch to say what the result of use of a relative
reference will be if there's no base URI.

CURRENT:
   If no such base URI exists, use of a relative reference with respect
   to a URN is an error and will yield results that might be unexpected
   or not useful.
RECOMMENDED:
   If no such base URI exists, use of a relative reference with respect
   to a URN is an error.   Client behavior in this case is undefined.

13.  Section 6, about halfway through

Clarify that a resource MAY have more than one URN assigned to
it, either in the same namespace or in different namespaces.

CURRENT:
   With regard to global uniqueness, using different NIDs for different
   collections of identifiers ensures that no two URNs will be the same
   for different resources, since each collection is required to
   uniquely assign each identifier.  However, a single resource can have
   more than one URN assigned to it for different purposes (for example,
   if a book were published in a monograph series, it could have both an
   ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two
   URNs referring to the same book).  Subject to other constraints, such
   as those imposed by the URI syntax [RFC3986], the rules of the URN
   scheme are intended to allow preserving the normal and natural form
   of identifiers specified elsewhere when they are treated as URN
   namespaces.

RECOMMENDED:
   With regard to global uniqueness, using different NIDs for different
   collections of identifiers ensures that no two URNs will be the same
   for different resources, since each collection is required to
   uniquely assign each identifier.  However, a single resource MAY have
   more than one URN assigned to it, either in the same namespace 
   (if the namespace permits it) or in different namespaces, and 
   either for similar purposes or different purposes. (for example,
   if a book were published in a monograph series, it could have both an 
   ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two 
   URNs referring to the same book).  Subject to other constraints, such 
   as those imposed by the URI syntax [RFC3986], the rules of the URN scheme
   are intended to allow preserving the normal and natural form of
   identifiers specified  elsewhere when they are treated as URN
   namespaces.


14. section 6, last paragraph

If we're deprecating X- namespaces, fine, but we should reserve
namespaces beginning with X- to prevent conflicts with identifiers
that might already exist in the wild.

CURRENT:
   Note: [RFC3406] defined a third type of "experimental namespaces",
   denoted by prefixing the namespace identifier with the string "X-".
   Consistent with general IETF conclusions about similar approaches
   [RFC6648], this specification removes the experimental category and
   syntax.  Because experimental namespaces were never registered,
   removing the experimental category has no impact on the existing
   registries or future registration procedures.  Because they are not
   registered, strings that refer to existing experimental namespaces
   are not valid URNs.  Truly experimental usages can, of course, employ
   the 'example' namespace [RFC6963].

RECOMMENDED:
   Note: [RFC3406] defined a third type of "experimental namespaces",
   denoted by prefixing the namespace identifier with the string "X-".
   Consistent with general IETF conclusions about similar approaches
   [RFC6648], this specification removes the experimental category and
   syntax.  Because experimental namespaces were never registered,
   removing the experimental category has no impact on the existing
   registries.  However, to avoid the potential for conflict between
   previously-allowed unregistered experimental namespaces and 
   namespaces registered in the future, no registrations will be
   accepted for new namespaces beginning with "X-".  Because they are not
   registered, strings that refer to experimental namespaces
   are not valid URNs.  Truly experimental usages MAY, of course, employ
   the 'example' namespace [RFC6963].

15. Section 6.1

CURRENT:
   5.  It MUST NOT start with the string "xn--" or any other string
       consisting of two letters followed by two hyphens.  Those strings
       are reserved for potential representation of DNS A-labels and
       similar strings in the future [RFC5890].
RECOMMENDED:
   5.  It MUST NOT start with the string "xn--" or any other string
       consisting of two letters followed by two hyphens.  Those strings
       are reserved for potential representation of DNS A-labels and
       similar strings in the future [RFC5890].

   6.  It MUST NOT start with the string "X-" so that it will not 
       be confused with an experimental namespace previously
       permitted by [RFC3406], nor conflict with such a namespace.


--------------020403000101070309050707-- From nobody Sun Jul 5 12:37:24 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585631ACE77 for ; Sun, 5 Jul 2015 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwyL27WfSNC4 for ; Sun, 5 Jul 2015 12:37:17 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 229A11ACE76 for ; Sun, 5 Jul 2015 12:37:16 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id B3C1F8AFB1 for ; Sun, 5 Jul 2015 21:37:15 +0200 (CEST) X-AuditID: 0a453fe7-f79136d0000011d7-5a-5599876b2202 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id EF.09.04567.B6789955; Sun, 5 Jul 2015 21:37:15 +0200 (CEST) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Sun, 5 Jul 2015 21:37:15 +0200 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt Thread-Index: AQHQqv8vTJj6SgSkO0Go8O0j62UfY53GSVDggAcSGuA= Date: Sun, 5 Jul 2015 19:37:14 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D0A868F@dnbf-ex1.AD.DDB.DE> References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.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.195] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0hTYRzGe7e5Hdfeep1zvq3rRn3RWpkWkdI9sAtW6iLqgx3bcVtuOnY2 0SDwkkV2sSFJrpvi6Eq5VtSslTUKMkrLTMTAiNKwQQbR7UOX8+5sduzb//ye//O8zzkvhxIr +2QaylLiZBwltFUnlUvka5d/nVd8oMmw4NjozCXHaz6LVoBsr/enaDPYLs8yMlZLGeOYv2yn 3BxonWMfsJSfdvulleBGfh2IpzDKwA1tXik/q/HzwTZullNK9BDgkdb3Ev7hJsAN97s5RUZJ UQoeNZN9FdLie8PVsjpAUYkoF/eeX8njPNw+cB3w81J88W1IQmYJmo0/9X8RkRmiDfhxoF3E pzcCXH/wWRwR4tEO3PG6MrIE0HTs83WLySxGydg//D2O74mwN8hzjJLwyLvfUa7F17s6pPz+ AjzadTbqTcXnWsJi/uAE3Nn0XnIMJHkEsR6BxSOweASWZiC5BCaxNlOanjbqjcZCvZHxA/4C PgTA0Z41IYAooFPAjOomgzKOLmMrbCGwiRLpkqDt0AmDclJhqbHCTLPmAofLyrA6FWyr4Tbh GC50WYt1M2B4kFtOHqOsi7VbdllKXWyBy2ENAUyJOeuTcmI10hV7GEcpHxgCUymJLhm671Tl K5GJdjLFDGNnHDF1G0XpMET7OWOCgzEx5UUWqzMmc77MWk5BQiVSSAv3vuEKaYTC/51EVHwI bKQUXLEskg9ZO21jLaZodiLsJt9EEaOR3OlwNclVx+D4zCcgT5MMw5FKZMPsKhnrqlHD1Lmc dbJAIJGaWbB/UaNBOUXAx6d+BOu4K0qEF0hJBfcb/euohIvJYROjMFJxGjSQiklR9n/WRu5u VVBFjoSsk3YKXziHUEWMRl84m0B1DI6P01SCi0PNdbdDG7SN4kXp5/2uCQerlA+eolcV1c21 fWvvHu7p7TwTlG+ucS8dvPVmfcCXuiOzNiiSr8rYmv3q2YpVZV9yi9JDsvL6I6facttntVgu Xz3p1O8ecp9ruPYHDu151LHlU47px8sX3+C+lPpvvmBawrRSpAj/grLTA+lXsloX6iSsmU5L ETtY+i+MDGyKaQQAAA== Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 19:37:21 -0000 Melinda et al.; My comments are even more minor than Juha's: 1) Introduction The first paragraph discusses the difference between resource identifiers a= nd abstract designators. In order to avoid confusion we should make it clea= r that "resource" is meant as "internet resource", since also abstract desi= gnators do identify resources (but not internet resources). This comment al= so applies to the document's abstract. 2) Terminology The first paragraph mentions that important terms are taken from RFC 3986. = I think it would help the interpretation if we could list exactly what term= s are to be interpreted in the RFC 3986 fashion (e. g. "resource"). 3) URN syntax The third paragraph discusses "rules not defined here" and mentions "path-a= bsolute" and "query", but I cannot find that those two rules are used in th= e ABNF. 4) Appendix A, =A7A.6 This section says that the use of p-components is not allowed unless the re= gistration explicitly says how. There are no p-components any more. I'm not deep enough into the gory details to be able to answer any of Keith= 's comments, but I look forward to the discussion. Best, Lars *** Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek ***=20 --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek Informationsinfrastruktur und Bestanderhaltung Adickesallee 1 D-60322 Frankfurt am Main Telefon: +49-69-1525-1752 Telefax: +49-69-1525-1799 mailto:l.svensson@dnb.de=20 http://www.dnb.de > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Hakala, Juha E > Sent: Wednesday, July 01, 2015 12:19 PM > To: Melinda Shore; urn@ietf.org > Cc: Tobias Weigel; stella@isbn-international.org; isabelxiang@hotmail.com > Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn= -12.txt >=20 > Hello Melinda; all, >=20 > I have only a few, mostly minor comments to the latest RFC2141bis draft. = As far > as I am concerned, our work is almost done. With this syntax the library > community will be able to do everything we wanted initially to do, and th= en > some more - we did not anticipate the possibility to send resolution requ= ests > not only to the URN resolvers, but also to the identified resources thems= elves or > to the applications managing them. Since resources are getting more compl= ex - > research data sets are an example of this -, this kind of enriched functi= onality > may become very useful in the long run. >=20 > Best regards, >=20 > Juha >=20 > ----- >=20 > In the second paragraph of chapter 3.3 we say that unless defined for a > particular namespace, use of q-, r- and f-components is disallowed. >=20 > This is OK for q- and r-components, but I am not sure if such limitation = is > required for F-component, since it has no impact on URN resolution. Moreo= ver, > F-component is not namespace specific but depends on file format. It can = be > added to the URN:ISBN if the identified book is e.g. a PDF document, but = not to > every URN:ISBN (even if the ISBN identifies an e-book; printed books cert= ainly > do not have URI fragments). So it is likely that f-component can never be > applied to all URNs in a certain namespace, but it may be possible to app= ly it to > some URNs in most (actionable) namespaces. >=20 > The example in the last paragraph of chapter 3.3.1 uses a real ISBN but i= n > wrong (urn:example) namespace. It is better to replace the ISBN with a ra= ndom > NSS such as "bar", because the URN is not actionable and even if it were,= the > fragment would not be applicable. >=20 > Although libraries' primary intention was to use q-component for passing > resolution related information to URN resolvers, I see no problem in usin= g r- > component instead to this purpose. IMO it is good design to make a differ= ence > between requests to resolvers (r-component) and requests to resources > themselves or applications managing them (q-component). Identified resour= ces > will become increasingly large and complex (scientific data sets are a go= od > example of this) and it may be necessary to perform various operations b= efore > the resource is ready to be sent to the user. >=20 > In 3.3.3 we say that f-component need not be semantically equivalent to t= he > URI fragment (component). IMO URN f-component is never semantically > equivalent with URI fragment since f-component does not have a role in > identification. We avoid making this difference explicit by saying that f= - > component is intended to "distinguish integral parts of resources", which= is OK > to me in spite of being somewhat vague. If we want to be more specific we > could say that what is being distinguished are physical (encoded) parts o= f > resources. F-component cannot be applied to logical parts of resources un= less > they coincide with physical ones. It might be a good idea to be more spec= ific > about what f-component does because there is an increasing need within my > community (libraries, archives and museums) to identify component parts o= f > resources. If and when we start developing a new standard identifier for = logical > components of resources (or if we extend existing systems such as NBN in = such > a way that they do the job) it is important to know precisely what the ro= le of f- > component is. The present wording does not make that very clear. >=20 > The example in the last paragraph of chapter 3.3.3 uses a real ISBN but i= n > wrong (urn:example) namespace. It is better to replace the ISBN with a ra= ndom > NSS such as "bar". URN:ISBN is actionable (as http://urn.fi/URN:ISBN:978-= 952- > 10-7060-0) but urn:example is not. In both cases fragment is not applicab= le. >=20 > In chapter 6 (top of page 14) the draft states that "uniqueness constrain= t means > that an identifier within the namespace is never assigned to more than on= e > resource and never reassigned to a different resource". We might consider > saying "one resource (as defined in the namespace)". Every journal artic= le > published in e.g. Scientific American has the same ISSN, since in the URN= :ISSN > namespace "resources" are serials. In SICI (Serial Item and Contribution > Identifier) namespace resources are journal issues and articles. URN:NBN = could > be used for identification of still images within these articles. >=20 > In chapter 6.1, the last paragraph of page 16 the draft requires that par= ticular > attention should be paid to strings that might imply association with wel= l-known > trademarks. More exhaustive formulation would be "... well-known identifi= er > systems and trademarks". In this context we need to be even more concerne= d > about NID strings like "handle" and "doi" than "pepsi". >=20 > In 7.3.1 (Purpose of the URN registration) it is IMO necessary to provide > information whether resolution services are or will be available, and if = so, what > the existing / anticipated services. Registrants might even be able to pr= ovide > examples for q- and r-component semantics and syntax, even if they are > registered elsewhere later. This question could be the second one asked. >=20 > It might be a good idea to ask the registrants to clarify formal status o= f the > identifier (de jure standard / de facto standard / other) and current / > anticipated extent of its use (international / national / local usage). I= dentifiers > with statuses "other" and "local usage" should usually have informal than > formal namespaces registered for them. The current scope question (number= 4 > on the list) is a little bit of a mixed bag as it covers both geographica= l and > organizational issues; it might be better to target scope on various > organizational issues only (public / private sector, book trade / librari= es, > military / civilian use etc.). >=20 > As regards the current second (later perhaps third) question on the list,= I would > drop the request for telling why it is preferable to use URN rather than = some > other technology. IETF does not need to know this. Also asking the regist= rant to > explain why existing URN namespaces are not a good fit sounds a bit negat= ive. I > would ask the registrant to describe how the namespace to be registered > relates to existing URN namespaces and how the new namespace complements > them. >=20 >=20 > > -----Original Message----- > > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Melinda Shore > > Sent: 20. kes=E4kuuta 2015 5:17 > > To: urn@ietf.org > > Subject: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-1= 2.txt > > > > This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-1= 2 > > with an eye towards what, if anything, needs to be resolved before goin= g to > > working group last call. > > > > Many thanks, and have an excellent weekend. > > > > Melinda > > > > > > -------- Forwarded Message -------- > > Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > > Date: Tue, 16 Jun 2015 07:28:05 -0800 > > From: Melinda Shore > > To: urn@ietf.org > > > > As you've probably seen, the -12 version of the 2141bis draft was uploa= ded > > yesterday. We're planning on taking the -13 version to working group l= ast > > call, and we really need some careful review to make sure that problems > with > > the document have been identified and addressed. > > > > This morning John sent out a list of issues that he's identified and th= at need > > sign-off from the working group. > > Some of his questions are somewhat open-ended and we need to avoid rat- > > holing, so please be very specific and provide concrete examples where > > possible. > > > > The immediate questions are: > > > > . Are the current versions of the registration templates > > and descriptions complete and clear? > > . Are the r-component and q-component examples correct? > > . Can someone provide clarifying text about where r-component > > and q-component queries go? > > > > He also raised some broader questions which need discussion but which > > perhaps can wait until we've got some level of agreement on what needs = to > > be done for wglc. > > > > (John's email is here: > > https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) > > > > Thanks, > > > > Melinda > > > > -------- Forwarded Message -------- > > Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > > Date: Mon, 15 Jun 2015 16:25:26 -0700 > > From: internet-drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: urn@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Uniform Resource Names, Revised Worki= ng > > Group of the IETF. > > > > Title : Uniform Resource Names (URNs) > > Authors : Peter Saint-Andre > > John C Klensin > > Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt > > Pages : 30 > > Date : 2015-06-15 > > > > Abstract: > > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > > that is assigned under the "urn" scheme and a particular URN > > namespace, with the intent that the URN will be either a persistent, > > location-independent resource identifier or in some cases an abstrac= t > > designator that is persistent but that does not identify a resource. > > With regard to URN syntax, this document defines the canonical synta= x > > for URNs (in a way that is consistent with URI syntax), specifies > > methods for determining URN equivalence, and discusses URI > > conformance. With regard to URN namespaces, this document specifies > > a method for defining a URN namespace and associating it with a > > namespace identifier, and describes procedures for registering > > namespace identifiers with the Internet Assigned Numbers Authority > > (IANA). This document obsoletes both RFC 2141 and RFC 3406. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-12 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > _______________________________________________ > > urn mailing list > > urn@ietf.org > > https://www.ietf.org/mailman/listinfo/urn >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Jul 23 23:11:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5775D1A1E0E for ; Thu, 23 Jul 2015 23:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYwbnvhgRyw9 for ; Thu, 23 Jul 2015 23:11:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62221A6EDE for ; Thu, 23 Jul 2015 23:11:18 -0700 (PDT) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 06:11:01 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0219.018; Fri, 24 Jul 2015 06:11:01 +0000 From: "Hakala, Juha E" To: "urn@ietf.org" , Keith Moore Thread-Topic: NSS encoding Thread-Index: AdDF10NkZPpUus3rQ1+1ufTH5gDqSQ== Date: Fri, 24 Jul 2015 06:11:01 +0000 Message-ID: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:JDN8N+u/Joj6J2lxoFx5Yz9UmF/LeOrtABXFUReWkmcTbqCJieyHA9G72Y6//2fZeprVn4k30DXzirqacFe1hwePU9KsaxcW0YPzgUTWikLgKjTh11Ak1hQbMaKgcka3qPYLg0buD7tgOHJ6CPXjMA==; 24:l19aiWFaRSetCDFVpYrCUOPHZ8uqDqeEos+RlDyw6O9NRlNhntUxxR3kNd2WJXH2BFLcNhR97UxKlrcd72QL6bTVfKFH8TaEPhr3zD3Bq5o=; 20:T/nZzFN/yv3TEfVgBnsOoRANzYNZpaWMz6obgVcYg8unB8aWsxZ/liGBa2kmgkdxdRl8MlxcOdqDEl50174+5w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; amspr07mb453: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51444003)(252514010)(122556002)(5002640100001)(2501003)(102836002)(40100003)(5001770100001)(2656002)(92566002)(50986999)(76576001)(33656002)(77096005)(87936001)(107886002)(74316001)(5003600100002)(46102003)(77156002)(66066001)(86362001)(229853001)(19580395003)(74482002)(54356999)(189998001)(62966003)(2900100001)(19580405001)(5001960100002)(221733001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 06:11:01.4221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Subject: [urn] NSS encoding X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:11:22 -0000 Hello,=20 Keith said:=20 "I'm concerned that telling implementors to use %-encoding of disallowed ch= aracters that appear in NSS might conflict with an existing URN namespace's= encoding rule. Also, %-encoding is a mess, because it's used by so many d= ifferent layers of software without any clear guidance about which layers u= ndo which portions of the encoding. So I doubt that it's a good idea to sp= ecify a uniform rule for how every namespace should encode its native names= to URN format; instead, I think that encoding considerations should be par= t of namespace-specific "canonicalization" rules." My take on this is between the original text and Keith's point of view. Mos= t standard identifiers I am familiar with consist of ASCII characters only = and do not need encoding rules for disallowed characters at all. But in the= other extreme there are cases when name space specific encoding rules are = needed. For instance, if ARK (another persistent identifier system) registe= rs a URN namespace, it is necessary to develop namespace specific guideline= s for dealing with ARK specific r-components which are "?" for requesting f= rom the resolver metadata about the resource and "??" for asking for preser= vation commitment of the institution which is holding the document. ? is a = reserved character, and since URNs have specific uses for "?" and "??" norm= al URN resolver would not have any idea of what to do with unaccompanied "?= " or "??" ARK has chosen to use. But %-encoding them would not make sense f= rom ARK resolution point of view, so URN:ARK (if and when it is registered)= must specify how to treat these ARK specific features. For instance, since= "?" and "??" are not part of the ARK identifier, they can be deleted in or= der to just retrieve the identified resource. Or, they can be migrated into= corresponding URN r-components. =20 If we allow both %-encoding and namespace specific encoding of identifiers,= the resulting text in RFC2142bis could be something like this:=20 "Depending on the rules governing a namespace, names that are valid in a na= mespace might contain characters that are not allowed by the "pchar" produc= tion referenced above (e.g., characters outside the ASCII range or characte= rs that are reserved in URIs, such as "?", and "#"). While such a string m= ight be a valid name, it is not a valid URN until it has been translated in= to a conformant NSS. If there are no namespace specific encoding requireme= nts, translation may not be necessary at all, or it may be done by percent-= encoding each disallowed character using the method defined in Section 2.1 = of the generic URI specification [RFC3986]. If there are specific encoding = requirements, translation of an identifier from its "native" format to URN = format is accomplished by using the canonicalization and encoding methods d= efined for that URN namespace in that namespace's registration. Software th= at is not aware of those URN canonicalization and encoding rules for the na= mespace used MUST NOT construct URNs from such identifiers. Note also that = the "%" character is allowed in the NSS only for the purpose of percent-enc= oding. " =20 IMO we have already taken namespace specific character encoding into accoun= t, since the syntax section of the namespace registration template enables= the registrant to describe "Any special character encoding rules for assig= ned URNs (e.g., which character ought to always be used for quotes)." There is also another aspect of URN encoding which we may need to mention i= n passing. It may happen that when an identifier is turned into NSS, change= s go beyond simple %-encoding of characters, especially if the identifier a= s such does not support resolution requirements of the community. An exampl= e of this in ISBN in DOI. ISBN prefix element, registration group element a= nd registrant element form DOI prefix and publication element and check dig= it become DOI suffix. So ISBN 978-952-222-272-5 becomes DOI 10.978952222/27= 25, which can be resolved by the publisher. There are various ways in which= URN:ISBN resolution could be tweaked in the same way, and some of them wou= ld have an impact on how ISBNs are expressed as URNs. =20 =20 Best regards,=20 Juha -- Juha Hakala Senior advisor =A0The National Library of Finland Library Network Services=20 =A0P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Gsm: +358 50 3827678 email: juha.hakala@helsinki.fi=20 From nobody Sat Jul 25 12:41:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784631AD2AF for ; Sat, 25 Jul 2015 12:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.801 X-Spam-Level: *** X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dieMkmOGXvFw for ; Sat, 25 Jul 2015 12:41:48 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4191A8908 for ; Sat, 25 Jul 2015 12:41:48 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZJ5KM-000Bdw-T5; Sat, 25 Jul 2015 15:41:46 -0400 Date: Sat, 25 Jul 2015 15:41:37 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <4732B81F609179B87526E501@JcK-HP5.jck.com> In-Reply-To: <559463C3.3030905@network-heretics.com> References: <559463C3.3030905@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 Archived-At: Subject: [urn] encoding, component order, and related issues (was: Re: review of rfc2141bis-12) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 19:41:50 -0000 Keith, I'm going to try to respond to a few elements of this (I think my comments are complementary to Juha's) but leave most of this for Peter to finish remarks that I know are coming... --On Wednesday, July 01, 2015 6:03 PM -0400 Keith Moore wrote: >... > 1. The URN syntax grammar is ambiguous, and is inconsistent > with the text. I hate ABNF but will go back and check this. > 2. The current grammar either requires encoding of queries > represented as q-components (without specifying any such > encoding) or disallows queries containing '??'. When I wrote that, I assumed that "encoding" would reflect the 3986 definition and force us into "%"-type arrangements. We are, after all, following that syntax. If you think that needs to be made more explicit, I don't see that as a problem. That does get us to the more substantive and troublesome comment below. > 3. For the sake of interoperability between clients, > interpretation of q-component, r-component, and f-component by > client software needs to be consistent across all URNs that > can resolve to URLs. The current text explicitly permits > variant uses of these components, without setting any > restrictions on such usage. I think we have a real conundrum here and I don't know how to resolve it. I also think you are contradicting yourself. That perception (correct or not) is a symptom of the problem. On the one hand, we want and need to allow significant flexibility to namespace-definers, especially those who are trying to overlay URNs on existing, standardized, and extensively-deployed namespaces. Another, related, reason for that flexibility is that it is fairly clear that, if we engage in a discussion with the managers of a namestpace that starts like: IETF: Don't do Namespace manager: But is required to embed our namespace in URNs. IETF: Don't do Namespace manager: is horrible to look at and will cause integrity, transcription, and comparison problems with our identifiers. IETF: Don't do Jokes about the protocol police notwithstanding, that type of conversation can, in the real world and remembering that, ultimately, the namespace manager makes the decisions, we don't, there are only three plausible outcomes and one less likely one: (i) Do anyway and believe that any resulting messes are Someone Else's Problem. (ii) Write off URNs and ask for a URI. (iii) Write off namespace-specific URIs and either give up on Internet resolution or use http://foo-manager.org/, presumably playing DNS games if needed. (iv) (the unlikely one) Give in and follow our rules, irritating those who define and use their identifiers and pay their salaries. I think the way to avoid those choices is to spread as wide an umbrella as possible, even if it means giving up on purity. Nothing prevents us from saying "if you do (or fail to do with it) that is likely to cause problems that you need to understand and expect" but that is as far as I think we should go. My reasoning above informed some of the other text to which you object so, at least until we hear from Peter, consider them context. >... > a) The grammar is both ambiguous (in that it permits the same > string to be parsed in multiple/conflicting ways) and > inconsistent with the text. In particular, if "??" separates > a q-string from r-string, then q-string should not permit "?" > to appear twice in succession, and the currently specified > grammar does. If you have an improved grammar suggestion, I'm sure we will welcome it. Otherwise, you get a textual discussion/ restriction (as I think you suggested). > b) The grammar refers to "q-string" etc. but the text refers > to "q-component" etc. I could find no reason for the > discrepancy. I think I was intending that "q-component" include the leading "?" and that q-string was without it. But, if that confuses things rather than clarifying them... >... > Basically, the change specifies that any "?" in a q-component > must be followed by either a pchar or a "/". Of, of course, a # because urn:blather:frizzlepop?foobar?# is presumably valid, if ugly. > However, this suggested grammar still has the encoding problem > that I mentioned earlier: If q-component is interpreted as a > query to be attached to a URL (which is what I thought we had > agreed to, at least for URNs that resolve to URLs), there need > to be clear rules for copying or converting that q-component > text to the URL query text. The above grammar does not > permit multiple "?"s to appear adjacent in a q-component. > This implies that if there's ever some need to bundle a URN > with a query that contains "??", the "??" must somehow be > encoded so that (a) it doesn't violate the URN syntax grammar, > and (b) the original query string is recovered when bundled > with the URL. > > Simply assuming percent-encoding doesn't fully specify a > solution, because while a query that contains "??" could be > encoded as %3F%3F, a resource might reasonably interpret > %3F%3F differently from "??" > > This is one reason that I believe it's much simpler, and more > likely to be implemented correctly, to not constrain the > syntax of q-components beyond the syntax of RFC 3986 queries. > And that implies either (a) putting r-component somewhere else > than following q-component [e.g. ALTERNATIVE 2 below], or (b) > using a different character sequence to separate r-component > from q-component [e.g. ALTERNATIVE 3]. Then we can specify > that if a URN with a q-component resolves to a URL, the > q-component is simply copied to the URL query. > RECOMMENDED ALTERNATIVE 2 (switch order of r-component and > q-component): > > namestring = assigned-name > *[ "??" r-component ] > * *[ "?" q-component ] > * [ "#" f-*component* ] > assigned-name = "urn" ":" NID ":" NSS > NID = (alphanum) 0*30(ldh) (alphanum) > ldh = alphanum / "-" > NSS = pchar *(pchar / "/") > q-*component* *= *( pchar / "/" / "?" )* > r-*component* *= pchar *( pchar / "/" )* > f-*component* = fragment > > Note: The character "?" can be used without > percent-encoding inside > q-components, r-components, and f-components. > > > ALTERNATIVE 3 (use "##" as the introducer for r-component) Keith, I think this has been settled. This is clearly up to Andy and Melinda, but I think the WG has concluded that q-component and then r-component was, on balance, the right way to do things and that you are not introducing anything new above. The claim that %-encoding in complex situations introduces confusion and/or ambiguity has been made many times before, including by me, and consistently shot down by presumed URI experts. If there is a problem in that area, either construct an erratum for RFC 3986 or convince the WG (and others concerned) that the original "URNs are not URIs" model was correct... a model that you argue against when you suggest that URI processors ought to be able to handle URNs in an unambiguous way. > OOPS: I noticed after I had most of this review complete that > this grammar isn't compatible with RFC 3986, since 3986 > doesn't permit a fragment to contain "#". I'm leaving this > example here anyway to illustrate that there might be more > than one way to tweak the grammar to make q-component have > identical syntax to query and thus fix the encoding problem. > For instance, if we don't really need to permit '&' in an NSS, > maybe '&' could be used to introduce r-component. At the price of making URN syntax even more complex. I thought we had considered introducing yet more special characters and then conclude it wasn't a good idea. I'd be willing to revisit that if you are not the only one in the WG who thinks it is a good idea. >... best, john From nobody Mon Jul 27 00:58:07 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532D51AD074 for ; Mon, 27 Jul 2015 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f0UvCiGvU1r for ; Mon, 27 Jul 2015 00:58:03 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1761ACD8F for ; Mon, 27 Jul 2015 00:58:02 -0700 (PDT) Received: from DB4PR07MB460.eurprd07.prod.outlook.com (10.141.238.146) by DB4PR07MB457.eurprd07.prod.outlook.com (10.141.238.141) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 27 Jul 2015 07:57:41 +0000 Received: from DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) by DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) with mapi id 15.01.0225.018; Mon, 27 Jul 2015 07:57:41 +0000 From: "Hakala, Juha E" To: "urn@ietf.org" Thread-Topic: Usage of f-, q- and r-components Thread-Index: AdDIQbL0NAceB7DfRNuZTediDm8aUw== Date: Mon, 27 Jul 2015 07:57:41 +0000 Message-ID: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; DB4PR07MB457; 5:p2t8ktR84OqGFES6XSedZcoiq8/wG0hMHHijoJDtOMkzFt5ZRaEez7s6/NkYUx2oepEfOLvROtu8Tf6golKegpHCts7buh+kpNpSA1/1Omac0W3eTae+8DfZ+V1N1+E5F1HPDhTgyN/e1aR0Z5Tb2g==; 24:tqUq1F0a5zFGQ4j8Du3W0dS2xDh0xqrc4jqd78berzYXCLb2zDzV3lpItn6XyuOiN9lOnaTuzURq4MIGIZAwwM6xdgpSo3rEsRmvh052gas=; 20:oY+yINOgAzmzwZQtIJQJ6CQ7A0LBM1qL2a3n5xXGZYUz9rbokxURlC/LAh8oyBX6s/XYEF+l6Q6Jks7Je3muYA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB457; db4pr07mb457: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR07MB457; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB457; x-forefront-prvs: 0650714AAA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(252514010)(19580395003)(40100003)(62966003)(5003600100002)(86362001)(110136002)(87936001)(74316001)(450100001)(74482002)(2656002)(2900100001)(102836002)(15975445007)(77096005)(46102003)(92566002)(107886002)(5001960100002)(54356999)(2501003)(2351001)(77156002)(66066001)(189998001)(76576001)(5002640100001)(19580405001)(33656002)(50986999)(229853001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB457; H:DB4PR07MB460.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2015 07:57:41.5621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB457 Archived-At: Subject: [urn] Usage of f-, q- and r-components X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 07:58:06 -0000 Hello,=20 Keith said:=20 > 3. For the sake of interoperability between clients, interpretation of=20 > q-component, r-component, and f-component by client software needs to=20 > be consistent across all URNs that can resolve to URLs. The current=20 > text explicitly permits variant uses of these components, without=20 > setting any restrictions on such usage. John responded:=20 I think we have a real conundrum here and I don't know how to resolve it. = I also think you are contradicting yourself. That perception (correct or n= ot) is a symptom of the problem. On the one hand, we want and need to allo= w significant flexibility to namespace-definers, especially those who are t= rying to overlay URNs on existing, standardized, and extensively-deployed n= amespaces. =20 --- As a namespace-definer who is trying to overlay URNs on a few existing, sta= ndardized and widely used namespaces my take on this is that the problem ma= y not be as severe as John seems to think. It helps - I think - to discuss = this issue in more practical terms, instead of trying to solve it theoretic= ally.=20 F-components look exactly like URI fragments and will be treated like them.= Web browsers should never send them to URN resolvers, and if they do, reso= lvers should ignore the f-component. It will only be applied to the identif= ied and retrieved document.=20 Things get more challenging with q-component. Let's have a practical exampl= e: a user wants bibliographic metadata in Dublin Core format of the book wh= ich has ISBN 978-3-598-24287-8. =20 If the request is to be sent directly to the target database, then the synt= ax and semantics of the q-component will be dictated by the search protocol= supported by the database. In this case the request can be sent to e.g. Li= brary of Congress Online Catalog (http://catalog.loc.gov/). For machine to = machine interaction, it supports Z39.50 and SRU search protocols. In this c= ase SRU is appropriate, so the URN with q-component will look like this: urn:isbn:978-3-598-24287-8?version=3D1.1&operation=3DsearchRetrieve&query= =3D9783598242878&maximumRecords=3D1&recordSchema=3Ddc =20 The q-component looks complicated to those who do not know SRU. There is a = lot that needs to be told to the bibliographic database which acts as the t= arget system: the service we are asking for, search term, number of records= to be retrieved and metadata format to be used. Luckily SRU search request= s are machine generated; users should not see them at all.=20 A URN resolver receiving this should know one or more SRU servers to which = the send the request. When the LoC server location is added as SRU base URL= to the q component, the URI becomes:=20 http://z3950.loc.gov:7090/voyager?version=3D1.1&operation=3DsearchRetrieve&= query=3D9783598242878&maximumRecords=3D1&recordSchema=3Ddc The URN resolver may be aware of 1-n SRU servers, which can be fulfil the u= ser's demand. But the resolver does not need to know how to construct SRU s= earch request; that has already been done on the fly by the OPAC or other b= ibliographic system the customer is using. Standard based queries / resulti= ng q-components may look complicated but it is not hard for applications to= create and understand them. It is far more difficult to deal with cases wh= en there is no standard search API and "screen scraping" has to be used to = create a search URI. Generally, q-component needs to be whatever the target system requires it t= o be. So if URNBIS says don't do in the q-component, then - if = is something required by e.g. the SRU protocol which will be widely used to= deliver one of the most important resolution services, the implementers wi= ll do in any case at least if there is no viable workaround such as u= sing the r-component.=20 Due to the existence of various standard APIs it should be easy to use r-co= mponent to deliver I2C service. All it takes is that the URN resolver can m= igrate the r-component into appropriate URI such as SRU search, using defau= lt values for service related parameters if the user has not supplied them.= For instance, using "I2C" from RFC 2483 as mnemonic for service "URI to U= RC" and SRU syntax to require Dublin Core metadata, we get URN urn:isbn:978-3-598-24287-8??s=3DI2C&recordSchema=3Ddc The resolver would need to know how to migrate this into a search URI suppo= rted by an appropriate target system. It may be SRU server, OpenSearch serv= er, or something else. For the r-component above, Library of Congress Onlin= e Catalog would be fine. But if the user wants preservation metadata about = the resource with r-component like this urn:isbn:978-3-598-24287-8??s=3DI2C&recordSchema=3Dpremis digital preservation system should be chosen instead of a bibliographic dat= abase. As a rule the latter do not contain preservation metadata in any for= mat, and do not support Premis which is the de facto format used for this p= urpose (see http://www.loc.gov/standards/premis/). A user might also reques= t that the identified resource is deleted from digital archive. Then SRU wo= uld not be the right protocol; instead, for instance French standard MEDONA= (Mod=E9lisation des =E9changes de donn=E9es pour l'archivage) should be us= ed. =20 In order to make r-component truly useful we need a service registry which = can be easily maintained. New services and service parameters are emerging = as a result of implementation of digital preservation systems and other new= tools needed for management of digital resources. It would be impractical = to revise RFC 2483 and its successors each time something new (revised meta= data format, novel functionality, etc.) is introduced. =20 IMO the usefulness of r-component depends on the availability of standard-b= ased APIs for relevant services. Resolving a URN should not be complex or e= rror prone, and therefore it is important to be able to map the service req= uest and parameters in the r-component accurately into a URI. In a standard= based environment such mappings should be relatively simple and stable; in= a non-standardized environment it is likely to be neither. Even finding ou= t what services are supported in the target system can be complicated, depe= nding on the quality of the documentation provided. With q-component it will be easier to use non-standardized functionality su= pported by digital asset management systems than with r-component. All that= is needed is to cut and paste the relevant parts of URIs from the target s= ystem to the client application. The downside is that URIs used for e.g. se= arching non-standard bibliographic databases tend to change. So although th= e identifier (NSS part of the URN) of a resource is stable, the q-component= of the URI may change when the target system is updated. =20 Best regards,=20 Juha=20 -- Juha Hakala Senior advisor =A0The National Library of Finland Library Network Services=20 =A0P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Gsm: +358 50 3827678 email: juha.hakala@helsinki.fi=20 From nobody Mon Jul 27 21:04:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674EB1A874B for ; Mon, 27 Jul 2015 21:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts3uwrpHwpaL for ; Mon, 27 Jul 2015 21:04:09 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEE91A874A for ; Mon, 27 Jul 2015 21:04:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EC59920801 for ; Tue, 28 Jul 2015 00:04:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 28 Jul 2015 00:04:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=O6AuiHfL2qhFm7x oeEGI7DcmrqA=; b=M3bzWWP0yXqa9dr3qO2RC0OeWpdp8WoF7gpZD/iiVY80upU JtuOMEkViItZ3ldhTRfYtoQhCNpDpDEQlKXkZkyz9Y3d4DA97Nif0HlweK/2MIXp /iYgNClWibr8DNP/+tiQsQKdeLVKjIGmHFMaFoq77NQY1TVU5Fj+O+Zl2YJc= X-Sasl-enc: MGMU/FJwPXBZHufUY8JNBUTX85QxBnFVPpm9as9NQxBO 1438056247 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C7E0680206; Tue, 28 Jul 2015 00:04:07 -0400 (EDT) Message-ID: <55B6FF2A.3060001@network-heretics.com> Date: Tue, 28 Jul 2015 00:03:54 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Usage of f-, q- and r-components X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 04:04:11 -0000 On 07/27/2015 03:57 AM, Hakala, Juha E wrote: > Hello, > > Keith said: > >> 3. For the sake of interoperability between clients, interpretation of >> q-component, r-component, and f-component by client software needs to >> be consistent across all URNs that can resolve to URLs. The current >> text explicitly permits variant uses of these components, without >> setting any restrictions on such usage. > John responded: > > I think we have a real conundrum here and I don't know how to resolve it. I also think you are contradicting yourself. That perception (correct or not) is a symptom of the problem. On the one hand, we want and need to allow significant flexibility to namespace-definers, especially those who are trying to overlay URNs on existing, standardized, and extensively-deployed namespaces. > > --- > > As a namespace-definer who is trying to overlay URNs on a few existing, standardized and widely used namespaces my take on this is that the problem may not be as severe as John seems to think. It helps - I think - to discuss this issue in more practical terms, instead of trying to solve it theoretically. > > F-components look exactly like URI fragments and will be treated like them. Web browsers should never send them to URN resolvers, and if they do, resolvers should ignore the f-component. It will only be applied to the identified and retrieved document. > > Things get more challenging with q-component. Let's have a practical example: a user wants bibliographic metadata in Dublin Core format of the book which has ISBN 978-3-598-24287-8. > > If the request is to be sent directly to the target database, then the syntax and semantics of the q-component will be dictated by the search protocol supported by the database. In this case the request can be sent to e.g. Library of Congress Online Catalog (http://catalog.loc.gov/). For machine to machine interaction, it supports Z39.50 and SRU search protocols. In this case SRU is appropriate, so the URN with q-component will look like this: > > urn:isbn:978-3-598-24287-8?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc This looks odd to me. I understand the q-component to be reserved for information to be transmitted to the resource and interpreted by that resource. So a q-component wouldn't normally be applicable to a paper book. It looks to me like the parameters listed above would be more appropriate for r-component. > > The q-component looks complicated to those who do not know SRU. There is a lot that needs to be told to the bibliographic database which acts as the target system: the service we are asking for, search term, number of records to be retrieved and metadata format to be used. Luckily SRU search requests are machine generated; users should not see them at all. > > A URN resolver receiving this should know one or more SRU servers to which the send the request. When the LoC server location is added as SRU base URL to the q component, the URI becomes: > > http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc In contrast with the above example, this does not look odd to me, as this is a URL for a request to a resolution service. There's nothing wrong with a resolution server accepting parameters via HTTP query string. But a client using such a service for URN resolution needs to know how to map the r-component of the URN for which it is seeking information, onto that resolution service's protocol. If the resolution service defined its protocol in a way to make this work, the client might simply copy the r-component from the URN directly to the query component of the HTTP URL used to query the resolution service, perhaps adding the assigned portion of the URN as an additional query parameter. To make this more concrete, the original URN might be: urn:isbn:978-3-598-24287-8??request=I2C&protocol=SRU&maximumRecords=1&recordSchema=dc and the client might need to translate this to a URL like the following one to request the needed information: http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc Note that this requires some registry or other means by which r-component parameters that are widely used across different URN namespaces, need to be interpreted by the client (like "request" and "protocol" in the example above) and translated into whatever the resolution service needs, are distinguished from those parameters that are simply passed through to the resolution protocol. (Ideally, the URN would not need to specify any protocol-specific parameters, as this makes the URN dependent on a specific resolution protocol that is likely to change over time. But I think it will take awhile to standardize r-component parameters and there will always be some need to specify parameters that are specific to a particular namespace or resolution service.) > > The URN resolver may be aware of 1-n SRU servers, which can be fulfil the user's demand. But the resolver does not need to know how to construct SRU search request; that has already been done on the fly by the OPAC or other bibliographic system the customer is using. Standard based queries / resulting q-components may look complicated but it is not hard for applications to create and understand them. It is far more difficult to deal with cases when there is no standard search API and "screen scraping" has to be used to create a search URI. > > Generally, q-component needs to be whatever the target system requires it to be. So if URNBIS says don't do in the q-component, then - if is something required by e.g. the SRU protocol which will be widely used to deliver one of the most important resolution services, the implementers will do in any case at least if there is no viable workaround such as using the r-component. > > Due to the existence of various standard APIs it should be easy to use r-component to deliver I2C service. All it takes is that the URN resolver can migrate the r-component into appropriate URI such as SRU search, using default values for service related parameters if the user has not supplied them. For instance, using "I2C" from RFC 2483 as mnemonic for service "URI to URC" and SRU syntax to require Dublin Core metadata, we get URN > > urn:isbn:978-3-598-24287-8??s=I2C&recordSchema=dc > > The resolver would need to know how to migrate this into a search URI supported by an appropriate target system. It may be SRU server, OpenSearch server, or something else. For the r-component above, Library of Congress Online Catalog would be fine. But if the user wants preservation metadata about the resource with r-component like this > > urn:isbn:978-3-598-24287-8??s=I2C&recordSchema=premis > > digital preservation system should be chosen instead of a bibliographic database. As a rule the latter do not contain preservation metadata in any format, and do not support Premis which is the de facto format used for this purpose (see http://www.loc.gov/standards/premis/). A user might also request that the identified resource is deleted from digital archive. Then SRU would not be the right protocol; instead, for instance French standard MEDONA (Modélisation des échanges de données pour l'archivage) should be used. > > In order to make r-component truly useful we need a service registry which can be easily maintained. New services and service parameters are emerging as a result of implementation of digital preservation systems and other new tools needed for management of digital resources. It would be impractical to revise RFC 2483 and its successors each time something new (revised metadata format, novel functionality, etc.) is introduced. > > IMO the usefulness of r-component depends on the availability of standard-based APIs for relevant services. Resolving a URN should not be complex or error prone, and therefore it is important to be able to map the service request and parameters in the r-component accurately into a URI. In a standard based environment such mappings should be relatively simple and stable; in a non-standardized environment it is likely to be neither. Even finding out what services are supported in the target system can be complicated, depending on the quality of the documentation provided. > > With q-component it will be easier to use non-standardized functionality supported by digital asset management systems than with r-component. All that is needed is to cut and paste the relevant parts of URIs from the target system to the client application. The downside is that URIs used for e.g. searching non-standard bibliographic databases tend to change. So although the identifier (NSS part of the URN) of a resource is stable, the q-component of the URI may change when the target system is updated. Your latter two URN examples are also using the r-component in a way that is consistent with my expectations. I get the impression that you envision using q-component for parameters that are specific to a particular resolution service, and r-component for resolution parameters that are standardized. I also understand the need to distinguish between the two kinds of parameters, but I've assumed that both kinds of parameter would appear in r-component, with a registry or some sort of parameter naming convention used to distinguish between "generic" parameters that might need to be mapped into protocol-specific requests, and "protocol-specific" r-component parameters that would be passed directly to the resolution protocol. And I certainly agree with the need for a registry for r-component parameter names, and for standard resolution protocols. However, I want to reserve q-component to be strictly for parameters to be passed to a resource (for example, as "queries") and interpreted by that resource. I believe it's important to retain the capability to use URNs to identify network-accessible resources that accept input parameters, and to associate those input parameters with the URN. To use a concrete example, suppose the URN urn:example:g were created to name the Google search engine. That URN urn:example:g might resolve to the URL https://www.google.com/search . Then an attempt to access urn:example:g?Who%27s%20Afraid%20of%20Virginia%20Woolf%3F in a URN-aware web browser should eventually result in an HTTP GET request for https://www.google.com/search?Who%27s%20Afraid%20of%20Virginia%20Woolf%3F I think it's important to reserve q-component for this purpose not only so that network-accessible resources that accept "queries" can have those queries included in a URN, but also, more generally, that "?" will behave in a way that is more-or-less consistent with familiar usage. Keith From nobody Mon Jul 27 23:01:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27731A1BA7 for ; Mon, 27 Jul 2015 23:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLBd5hupMXWX for ; Mon, 27 Jul 2015 23:01:50 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFD31A1BA9 for ; Mon, 27 Jul 2015 23:01:50 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9CE8720AD0 for ; Tue, 28 Jul 2015 02:01:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 28 Jul 2015 02:01:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=TQAkjTS8a4FPeQl 720oUPbQITZg=; b=nAyNphC6xdTz1ZL4inEKnRYZxmMXB/VLMfzwZxsc98CS/tB VM9PN1gOTnxrzYtCR4j7QKWUeoxA6nwpm/qeC3wbzZ7ZaT9iHBYgBsxkpu3cQfj1 qttPwb9Eu4vwJGL09E27WEE9N1uzkxVvhAp9kEeqFH2pBWOeB+NZ12bpm88M= X-Sasl-enc: 6SN2YeU3jVXQyaNZcRuX8q5V0E7x2PlkiBTMyar9SPqp 1438063309 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D0B2EC00017; Tue, 28 Jul 2015 02:01:48 -0400 (EDT) Message-ID: <55B71ABF.7090508@network-heretics.com> Date: Tue, 28 Jul 2015 02:01:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: urn@ietf.org References: <559463C3.3030905@network-heretics.com> <4732B81F609179B87526E501@JcK-HP5.jck.com> In-Reply-To: <4732B81F609179B87526E501@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] encoding, component order, and related issues X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 06:01:53 -0000 On 07/25/2015 03:41 PM, John C Klensin wrote: > Keith, > > I'm going to try to respond to a few elements of this (I think > my comments are complementary to Juha's) but leave most of this > for Peter to finish remarks that I know are coming... > > --On Wednesday, July 01, 2015 6:03 PM -0400 Keith Moore > wrote: > >> ... >> 1. The URN syntax grammar is ambiguous, and is inconsistent >> with the text. > I hate ABNF but will go back and check this. thanks. > >> 2. The current grammar either requires encoding of queries >> represented as q-components (without specifying any such >> encoding) or disallows queries containing '??'. > When I wrote that, I assumed that "encoding" would reflect the > 3986 definition and force us into "%"-type arrangements. We > are, after all, following that syntax. If you think that needs > to be made more explicit, I don't see that as a problem. I have the impression that I've still failed to adequately explain what I think the problem is. But maybe I've been overestimating the severity of the problem. Mostly I'm just worried about edge cases that might result when a URN with a q-component is resolved to a URL with a query, given that the syntax for a q-component (in particular the characters that are allowed without percent-encoding) is different than that of a query. So for instance if a resource accepting a query were accessed via URL, the URL with the bundled query might look like http://example.com/foo?q=who? whereas if the same resource were accessed via URN, the URN would need to look like urn:example:bar?q=who%3F which would then resolve to http://example.com/foo?q=who%3F and the resource would (might) actually see a different GET command between the two cases, and perhaps produce different results. But what I'm seeing is that some web browsers percent-encode "?" in a search string even though RFC 3986 doesn't require this. So it might be that in practice, the resource isn't likely to see a difference between the two, and is unlikely to treat them differently even if it does see a difference. A similar potential glitch would be if http://example.com/foo contained a link to . But if the resource were accessed instead via URN urn:example:bar, that relative reference (if combined with the base URI via RFC 3986 rules) would produce urn:example:bar?q=bar??zot which would have zot interpreted as an r-component even though it was intended to be part of a query. I realize that we've declared that when evaluating a relative reference with respect to a resource named by a URN, that reference is supposed to actually be evaluated relative to a base URL that was either obtained via the resolution process or specified in the resource itself. But for various reasons I suspect that we'll still have client software trying to make sense of URN + relative reference without an associated URL. Since I believe that protocol designs and system should try to avoid obscure edge cases, I would prefer that the syntax permit a direct copying of URN q-component to URL query (and vice versa if this is ever applicable). And that's why I was looking for ways to change the ABNF to permit this, including changing the order of q- and r-components. I think that will produce fewer implementation bugs, less obscure and odd behavior, and less user frustration. But I also realize that this is at least the third time I've tried to fix this, and that the glitches that this causes will probably be infrequent. I also strongly suspect that this will come up again in IETF-wide Last Call because I expect the web types will want to go over this with a fine-toothed comb. So while I still don't understand why you so strongly insist that r-component has to follow q-component, I feel like other issues are more substantive and I've done due diligence trying to point it out. So maybe the thing to do is see if it gets raised again in IETF-wide Last Call, where I expect the whole interaction between URN components and URL components will get a lot of attention. > > That does get us to the more substantive and troublesome comment > below. > >> 3. For the sake of interoperability between clients, >> interpretation of q-component, r-component, and f-component by >> client software needs to be consistent across all URNs that >> can resolve to URLs. The current text explicitly permits >> variant uses of these components, without setting any >> restrictions on such usage. > I think we have a real conundrum here and I don't know how to > resolve it. I also think you are contradicting yourself. That > perception (correct or not) is a symptom of the problem. Ok, I have no idea what is meant by the above, and I'm not aware of my contradicting myself. If you think it's important to explain, please explain. If not, I won't worry about it. > On the > one hand, we want and need to allow significant flexibility to > namespace-definers, especially those who are trying to overlay > URNs on existing, standardized, and extensively-deployed > namespaces. Another, related, reason for that flexibility is > that it is fairly clear that, if we engage in a discussion with > the managers of a namestpace that starts like: > > IETF: Don't do > Namespace manager: But is required to embed our > namespace in URNs. > IETF: Don't do > Namespace manager: is horrible to look at and will > cause integrity, transcription, and comparison problems > with our identifiers. > IETF: Don't do > > Jokes about the protocol police notwithstanding, that type of > conversation can, in the real world and remembering that, > ultimately, the namespace manager makes the decisions, we don't, > there are only three plausible outcomes and one less likely one: > > (i) Do anyway and believe that any resulting > messes are Someone Else's Problem. > (ii) Write off URNs and ask for a URI. > (iii) Write off namespace-specific URIs and either give > up on Internet resolution or use > http://foo-manager.org/, presumably playing > DNS games if needed. > (iv) (the unlikely one) Give in and follow our rules, > irritating those who define and use their identifiers > and pay their salaries. > > I think the way to avoid those choices is to spread as wide an > umbrella as possible, even if it means giving up on purity. > Nothing prevents us from saying "if you do (or fail to do > with it) that is likely to cause problems that you need to > understand and expect" but that is as far as I think we should > go. To me it looks like there's a conflict between: (a) the goal of being able to accommodate some new namespaces into the URN umbrella with minimal rewriting, and (b) the goal of having URNs of arbitrary namespaces be resolvable and usable by clients. If you make interpretation of q-component, r-component, or f-component dependent on the namespace (or worse, on the individual URN), this presents some awkward choices to client developers. Either (i) clients will only resolve URNs of namespaces for which they know the interpretation of those components, or (ii) clients interpret these components uniformly for all namespaces, this producing strange behavior for URNs that don't conform, or (iii) some combination of the first two, with a generic default interpretation of these components and special-case behavior for some namespaces, or (iv) clients have to ask resolution services how to interpret these components for a particular namespace or URN, or (v) few if any clients implement URN resolution support at all, because it's just too flaky. All of these choices seem to me to be highly undesirable. I also think it's highly undesirable (and highly unlikely to get through IETF-wide Last Call) for q- or f-components of URNs to be interpreted in a substantially different way than queries and fragments are interpreted for URLs. Choice (i) favors some kinds of URNs over others. Essentially it makes it likely that clients will only support a small number of URN namespaces that happen to be in favor at the moment. (much as clients tend not to support as many URL schemes as they used to) Choice (ii) produces strange behavior when resolving URNs that don't fit the convention, and I have a hard time believing we would recommend it. Choice (iii) is perhaps the most palatable and pragmatic, and I've said in the past that I could accept a small and limited number of namespaces that required variant handling. But it would still be confusing to users who would have to learn that these components mean different things in different namespaces. Choice (iv) is also confusing to users, adds a lot of complexity to the system, actually seems to encourage a lack of uniformity in use of these components, and creates new security vulnerabilities. With uniform interpretation of URN components, I would say (for example) that a f-component should never be presented to a resolution service, and a q-component should only be presented to a resolution service if the service being requested were the actual resource. For all other requests, only the assigned portion of the URN and the r-component should be presented. That basically enforces uniformity of interpretation of components, which makes the system both simpler and more reliable and also more predictable to both implementors and users. But if choice (iv) were adopted, nothing would prevent a resolution service from returning a completely different resource based on the q-component or f-component. This strikes me as not only poor layering, but an architectural and security disaster - basically it's letting the resolution service assert control over interpretation of the resource at any time. The last thing we need is an information system that facilitates either centralized control over resource interpretation or centralized monitoring of queries sent to resources. Finally, I would regard choice (v) as a complete failure, since URNs were always intended to be resolvable. So while I acknowledge the difficulties you've listed above - that some namespaces might not fit well into URN syntax with uniform interpretation of components, and that this presents some awkward choices for users of those namespaces - that risk needs to be balanced against the risk that accommodating variant interpretations of URN components impairs URN resolution. And while I do want to be able to accommodate new URN namespaces, it's long been understood that URNs would, to the extent practicable, fit within both the syntax and semantic conventions that were established for URLs circa 1994. RFC 2141 reserved both "?" and "#" precisely because it was expected that if these were used with URNs at all, they should be used to denote query and fragment (assuming we could figure out how to define it in a way that made sense with URNs), or at least something similar. The notion that names from other namespaces might require encoding to be represented in URN form has also been established since at least 1999 (RFC 2611). It was always understood that for some namespaces this would be awkward - either requiring percent-encoding which is ugly, or some mapping from one delimiter to another that might not be obvious. So basically, I think the decisions regarding how much namespace-specific variation to permit in a URN (either syntax or interpretation) have been in place for around 20 years, and it seems late to be changing them much. But even if that weren't a concern, the problems I've listed above would still need to be dealt with. > > a) The grammar is both ambiguous (in that it permits the same > string to be parsed in multiple/conflicting ways) and > inconsistent with the text. In particular, if "??" separates > a q-string from r-string, then q-string should not permit "?" > to appear twice in succession, and the currently specified > grammar does. > If you have an improved grammar suggestion, I'm sure we will > welcome it. The various "alternative" ABNF fragments I suggested in my previous message each attempted to fix this issue. Keith