From julian.reschke@gmx.de Sun Jun 24 05:41:45 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1A21F84B4 for ; Sun, 24 Jun 2012 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.722 X-Spam-Level: X-Spam-Status: No, score=-104.722 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8csSdsfOgOm for ; Sun, 24 Jun 2012 05:41:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 042A221F8653 for ; Sun, 24 Jun 2012 05:41:44 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2012 12:41:43 -0000 Received: from p54BB31EF.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.49.239] by mail.gmx.net (mp027) with SMTP; 24 Jun 2012 14:41:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/jv2oS0hfjs1uOE1sLAxyIUbdUOtIlui2zClI/pY McdDz1+jvMbQsc Message-ID: <4FE70B05.9010602@gmx.de> Date: Sun, 24 Jun 2012 14:41:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [urn] example URN NIS X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 12:41:45 -0000 Hi there, is there a recommended NIS for URN examples? RFC 3406 doesn't seem to cover this... Best regards, Julian From A.Hoenes@TR-Sys.de Sun Jun 24 07:47:29 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6FD21F85A3 for ; Sun, 24 Jun 2012 07:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.449 X-Spam-Level: X-Spam-Status: No, score=-98.449 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc60u0z-2H83 for ; Sun, 24 Jun 2012 07:47:14 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id D766E21F855F for ; Sun, 24 Jun 2012 07:47:12 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA227329135; Sun, 24 Jun 2012 16:45:35 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA28201; Sun, 24 Jun 2012 16:45:33 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201206241445.QAA28201@TR-Sys.de> To: julian.reschke@gmx.de Date: Sun, 24 Jun 2012 16:45:32 +0200 (MESZ) In-Reply-To: <4FE70B05.9010602@gmx.de> from Julian Reschke at Jun "24, " 2012 "02:41:41" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] example URN NIS X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 14:47:29 -0000 Julian Reschke wrote: > Hi there, > > is there a recommended NIS for URN examples? RFC 3406 doesn't seem to > cover this... > > Best regards, Julian Julian, I assume you are looking for a dedicated URN Namespace for examples (i.e. a formally assigned "NID"). There isn't one, and due to the dichotomy between the properties of URNs (see RFC 1737 -- in particular the first 3 bullets in Section 2 there: global scope, global uniqueness, persistency, etc.) and the nature of 'hypothetical' examples (for educational purposes only), the last time this has been considered informally, it has been agreed that such 'example' URN Namespace would be a poor idea and it should not be assigned by rfc3406bis. (The discussion around the URNbis BOF and in March 2011 has focussed on a namespace for "experimental" URNs, but most of the arguments raised there against these are similarly valid against "example" URNs.) On the other hand, given the plethora of publicly assigned URNs that can be used persistently without negative side effects, AFAICS the RFCs so far in need of using concrete examples of URNs in general (and not in the context of the discussion of some particular URN Namespace) have used examples of existing bibliographic URNs, and doing so seems to have well served the educational purpose, because everybody likely has an idea of what kind of resource a urn:isbn might refer to. Other well known URN the use of which should not incur any harm might be considered in the IETF context; in particular URNs like urn:ietf:rfc:3406 or urn:ietf:mtg:82 immediately come to my mind. But maybe we need to reconsider this topic, if you see an urgent demand. If (and only if) the use of something that looks like a URN (but isn't permanently assigned and stable) for educational purposes is deemed worth defining a form of URNs that can be easily identified as such, a possible alternative to an entire URN Namespace dedicated to example usage would be the creation of a branch in the 'IETF' URN namespace. Beyond the urn:ietf branches defined in RFC 2648 (rfc, std, bcp, fyi, id, mtg), so far only the 'params' and 'xml' branches have been defined (in RFCs 3553 and 3688, respectively), and one might consider defining an "exceptional" 'example' branch as well. Kind regards, Alfred. From stpeter@stpeter.im Mon Jun 25 08:52:08 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124A11E8079 for ; Mon, 25 Jun 2012 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.744 X-Spam-Level: X-Spam-Status: No, score=-101.744 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKXYFybfNrur for ; Mon, 25 Jun 2012 08:52:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB60C11E8073 for ; Mon, 25 Jun 2012 08:52:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 75BE240081; Mon, 25 Jun 2012 10:09:57 -0600 (MDT) Message-ID: <4FE88926.6080808@stpeter.im> Date: Mon, 25 Jun 2012 09:52:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Julian Reschke References: <4FE70B05.9010602@gmx.de> In-Reply-To: <4FE70B05.9010602@gmx.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] example URN NIS X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:52:08 -0000 On 6/24/12 6:41 AM, Julian Reschke wrote: > Hi there, > > is there a recommended NIS for URN examples? RFC 3406 doesn't seem to > cover this... It would be easy enough to write a short spec about it and register such a NID. Peter -- Peter Saint-Andre https://stpeter.im/ From andy@hxr.us Tue Jun 26 09:10:32 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9854121F8483 for ; Tue, 26 Jun 2012 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJcvJVyzoTbI for ; Tue, 26 Jun 2012 09:10:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC91F21F847F for ; Tue, 26 Jun 2012 09:10:31 -0700 (PDT) Received: by yenq13 with SMTP id q13so79365yen.31 for ; Tue, 26 Jun 2012 09:10:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=8n5onxwaxE+wWkdZlBaBjsGl9yFCJSX1oEFC4jbrwuk=; b=Kknb9c5EAtaP4DrZsdoVb9FJWqO9yQ819RBVekuSzMiuB2TLgnuQ5iH/cNfJitZ98f z83BOdaf6iubL4A9oS0PKlegGcGWZsCdGAq00EVdGZH6CojxOA5LfxoQOTyyKyqIvp4i EGE5fa67Ubn04Ja04yS7R26meKotTsvKRRnq5tMlC0y2tZOe4jSyvBqUXqBKxjGll2t5 QWDkRHpaRtpH08SilmKs9GdALsG6q1ISmOHkjjrepPNgX87U/LtsP2ZKDxGcF6Gp2Zyp HEZWlqrK8ukUjk/eRfs1q3wk56Tc6iFil1yCVLDQb7eXBMli8naHY5PDjDizgiWofA9w 4/kA== Received: by 10.101.136.17 with SMTP id o17mr5664286ann.87.1340727031113; Tue, 26 Jun 2012 09:10:31 -0700 (PDT) Received: from ?IPv6:2001:500:4:15:754f:a154:1fd0:4c5d? ([2001:500:4:15:754f:a154:1fd0:4c5d]) by mx.google.com with ESMTPS id c28sm104674788yhk.2.2012.06.26.09.10.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 09:10:30 -0700 (PDT) From: Andy Newton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2012 12:10:28 -0400 Message-Id: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> To: urn@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmuol57WsWi4LtM3lAzUeiOV9Dp25uD5/4gPwfWGTT9NsNXirUo0dIgIcVfhgL48j61xX8z Subject: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 16:10:32 -0000 All, There are two items that surfaced during the URNBIS working group = meeting in Paris (IETF 83) which I should have explicitly noted on this = mailing list but neglected to do so. That is my fault. The first item was brought forward in the presentations on 2141bis and = 3406bis. The editors of these drafts have noted, in these documents, = issues they feel are closed. At IETF 83 I asked for a review of these = issues by working group participants and for any notes of dissent or = inquiries to be sent to this mailing list by April 16. Given this = request was never explicitly stated here, I would like to re-invite = working group participants to review the 2141bis and 3406bis issues. If = possible, I would ask that concerns raised from these reviews be given = on this mailing list before July 13. Second, at IETF 83 Leslie Daigle proposed removing the fragment language = from 2141bis and placing it in a separate draft to be moved forward as = an Experimental RFC. If you have objections to this approach, please let = us know (again, before July 13). -andy (obviously over-paid co-chair).= From sm@resistor.net Wed Jun 27 16:25:32 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5411E8123 for ; Wed, 27 Jun 2012 16:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqMxTye5eTdX for ; Wed, 27 Jun 2012 16:25:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61011E8124 for ; Wed, 27 Jun 2012 16:25:28 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5RNPJxc005247 for ; Wed, 27 Jun 2012 16:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340839527; bh=P0OPvqWzW64jRFy/YqCzYz/WoAqdtW78LW03Uo8y9TY=; h=Date:To:From:Subject:Cc; b=srPYX3RJ5PjP867arCjYoRhtvdMMOoSBxAmxsV9B4FN5TNSMF9yZN8Ek+nWQ8Dwhh tL48DPMiOTqHFkWDl0MjRQ8oat+7x1HL1xL6N+NTCAkOuYh78DFOYx11092o6BGcqE BFiHwglEo7sra76OGW2JIeTT6iS4yybx0kagW69Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340839527; i=@resistor.net; bh=P0OPvqWzW64jRFy/YqCzYz/WoAqdtW78LW03Uo8y9TY=; h=Date:To:From:Subject:Cc; b=3UvE9nZOgb205+3cBYc/ajKFvcV7Zl/D9ul5spuXSV5Yzua2AmfD5eY5N6B7oDjuX k4c6O9AHiUrkS4jErIQULIDn/MLCxRoTWh+zi5lhmw6wDRSizsI7ofz5hPNPeZ7+u9 xJgLr6KzaRU4C4FG97YNIW/zjxVM5PxIuAjv5r2o= Message-Id: <6.2.5.6.2.20120627161749.08c30070@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 16:17:56 -0700 To: urn@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [urn] Comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 23:25:32 -0000 Hi, This comments are on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02. The Abstract Section is too long. The draft is about procedures to register a URN namespace. In the Introduction Section: "URNs are part of the larger Uniform Resource Identifier (URI) family (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986 [RFC3986]) with the specific goal of providing persistent naming of resources." The first line is useful; the rest is unnecessary information. "To actually leverage the potential synergetic advantage of this unification" This is not a document about pharmaceuticals. :-) 'The purpose of this document is to outline a mechanism and provide a template for explicit URN Namespace definition, as well as provide the mechanism for associating an identifier (called a "Namespace ID", or NID), which is registered with the Internet Assigned Numbers Authority (IANA) [IANA] in the URN Namespaces registry maintained at [IANA-URN].' Could this text be made shorter? "The URN Namespace definition and registration mechanisms originally have been specified in RFC 2611 [RFC2611], which has been obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing IANA procedures have been revised as well over the years, and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative document. This document is a revision of RFC 3406 based on the revised URN Syntax specification RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226." There is ample historical information. Is it necessary in the introduction? The discussion about URN namespace (Section 2) should be moved to draft-ietf-urnbis-rfc2141bis-urn-02. In Section 3.1: "No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. However, as described below in Section 4.1, these are designated by a specific form of the NID to allow differentiation (without preexisting knowledge of details) from the other URN Namespace types." This could be formulated as guidance about when NIDs should be registered. Given the discussion about X- for other protocols, it's better to also drop it here. In Section 4: "The IANA Considerations Guidelines document (BCP 26 [RFC5226]) suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes." Why is this text needed in this draft? "The official list of registered URN Namespaces is currently maintained by IANA at [IANA-URN]." The "who" is not important. What is important is to point the reader to the location of the list of URN Namespaces. In Section 4.3: "The designated expert(s) for URN Namespace registrations are nominated by the IESG, and their role adheres to the regulations in BCP 26, unless specified otherwise below." BCPs are not about regulations. I suggest using the term "guidelines". 'Applicants, in concert with the IANA experts, should ensure that the sought NID strings are "proper" for the designated purpose, according to common sense (and applicable legal rules).' Who are the IANA experts? '"IETF Review" (per [RFC5226]) means that the Formal NID application is made via submission to the IETF of an Internet-Draft that contains the Namespace definition and targets publication as an RFC of Informational or Standards-Track category, which needs to be approved by the IESG after performing an IETF Last Call on the document and evaluating review comments. The applicant can be an individual or an IETF working group, in alignment with the designation of the Internet-Draft. The actual choice should be properly considered by applicants, but it is RECOMMENDED that the registration documents for NIDs belonging to an established standard namespace aim at Standards- Track, whereas other applications aim at Informational RFC.' There is a reference to RFC 5226 in this draft. The reader interested in the details of "IETF Review" can find the information in that RFC. I don't think that it is a good idea to explain about IETF process in this draft. In Section 4.4.3: 'According to the general procurements for RFCs, URN Namespace definition documents must include a "Security Considerations" section (cf. BCP 72 [RFC3552]). That section has to identify the security considerations specific to the subject URN Namespace.' The above should be trimmed. Provide the reader with actionable information so that the person knows what security issues to look out for. Why is Section 4.4.4 needed? This should be more about how to devise an appropriate registration request. This section seems like registration guidelines. In Section 6: "Until recently, that registry has been available in HTML, XML, and plain text from the generic web page at [IANA-URN]" Why is it important to tell IANA that the registry is available in three formats? Appendix A is informative for the registrant. I suggest separating the template and the "how to fill" information. AppendiX B reminds me of another RFC where the WG replicated information about procedures to help future authors. The draft should be about the registration steps in practice instead of a "formal" section and the actual steps. The draft is well-written. It should be ready with a little more work. Regards, -sm P.S. I did not cross-check all the details due to time constraints. From sm@resistor.net Wed Jun 27 16:25:32 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1911E8124 for ; Wed, 27 Jun 2012 16:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wssd0mGPNT0W for ; Wed, 27 Jun 2012 16:25:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEE311E8122 for ; Wed, 27 Jun 2012 16:25:25 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5RNPJxa005247 for ; Wed, 27 Jun 2012 16:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340839524; bh=qiqvHQM765t2YrCXl0X7B/rB+M3v0HeoMXwRip8Wcho=; h=Date:To:From:Subject:Cc; b=BRRzf9xjsR9IjD3XJpYnYBi+uuZA3gnkWtXNUg4S8uCE3jGEHGorDx4VzWn8xZoyQ oTPbQW9OC2yHH+LCybsPIcrPufHNrTlcFAtOpi0iDwNloCiPGh39c3hGfD5fT8JiNm HHtJzGzbGFGnEz5sXJk6bvBy03sc8Z51WZOJeEOs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340839524; i=@resistor.net; bh=qiqvHQM765t2YrCXl0X7B/rB+M3v0HeoMXwRip8Wcho=; h=Date:To:From:Subject:Cc; b=ii8BmGf5d+e3q7zZZvOSXLJGlde5ppQ8gxOVBG66K02ZRwujllaxwKLsu9P/XNpot TQcNECWHENTZqJkTcTFUmfDeHP0TiTf4oY4n6TcIYlqiP6G7ZiI4Hl22ea4xQAfO7X KXmMs9WiVlPZ2Dxzysk7R6PuDOZKAtxIyzXhAi2E= Message-Id: <6.2.5.6.2.20120627161737.08c30300@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 16:17:43 -0700 To: urn@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 23:25:33 -0000 Hi, These comments are on draft-ietf-urnbis-rfc2141bis-urn-02. The comments may sound abrupt. It is not intentional. In the Abstract Section: "The requirements and procedures for URN Namespace registration documents are set forth in BCP 66, for which RFC 3406bis is the companion revised specification document replacing RFC 3406." The above paragraph isn't relevant to the document contents. In the Introduction Section: "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (that share the properties of URNs) into URI-space." RFC 3986 mentions that 'the term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name'. The above text does not mention global uniqueness and persistence even when the resource ceases to be unavailable. Are those characteristics important? In Section 1.1: "Since this RFC will be of particular interest for groups and individuals that are interested in persistent identifiers in general and not in continuous contact with the IETF and the RFC series, this section gives a brief outline of the evolution of the matter over time. Appendix E gives hints on how to obtain RFCs and related information." This is unnecessary. if a person cannot find RFC XXXX, it's unlikely that the person would find this document. "Registration procedures for URI Schemes originally had been laid down in RFC 2717 [RFC2717] and guidelines for the related specification documents were given in RFC 2718 [RFC2718]. These documents have been obsoleted and consolidated into BCP 35, RFC 4395 [RFC4395], which is based on, and aligned with, RFC 3986." The history of the registration procedures is not as important. I suggest moving it into an appendix if the author wants to keep that information. I found the text informative but most readers won't share that view. In Section 1.2: "This section aims at quoting requirements as identified in the past; it does not attempt to revise or redefine these requirements, but it gives some hints where more than a decade of experience with URNs has shed a different light on past views. The citations below are given here to make this document self-contained and avoid normative down- references to old work." Such information might only be informative for a small subset of IETF participants. People reading a document about URN syntax might find it confusing. This this is a stylistic nit. I suggest targeting the average reader. Describe the properties of URNs and move the historical information to an appendix if the author would like to keep that. In Section 1.3: "RFC 2141 does not seamlessly match current Internet Standards. The primary objective of this document is the alignment with the URI standard [RFC3986] and URI Scheme guidelines [RFC4395], the ABNF standard [RFC5234] and the current IANA Guidelines [RFC5226] in general. The objective should be in the Introduction Section. Move the Historical information to the section about history. "For advancing the URN specification on the Internet Standards-Track, it needs to be based on documents of comparable maturity. Therefore, to further advancements of the formal maturity level of this RFC, it deliberately makes normative references only to documents at Full Standard or Best Current Practice level." This above is not that useful in the context of this document. In Section 2: "The syntax definitions below do, and syntax definitions in dependent documents MUST, conform to the URI syntax specified in RFC 3986, in the sense that additional syntax rules must only constrain the general rules from RFC 3986." This requirement is incorrect as it isn't that good to have one based on "dependent documents". Keep the text simple by telling the reader what are the syntax requirements. "RFC 2141 was published before the URI Generic Syntax was finalized and therefore had to defer the decision on whether and components are applicable to URNs. RFC 2141 therefore has reserved the use of bare (unencoded) question mark ("?") and hash ("#") characters in URNs for future usage in conformance with the generic URI syntax." What's the impact of keeping this; i.e. would it break a generic URI parser? "The part is not generally allowed in URNs. It is only applicable to URN Namespaces that specifically opt to support its usage." I suggest removing this sentence or rewording the following sentence to cover the optional (MAY) case. Section 2 comes out as being too lengthy. In Section 2.1: "To avoid confusion with the URI Scheme name "urn", the NID "urn" is permanently reserved by this RFC and MUST NOT be used or registered." If this memo reserves the NID, it cannot be registered. In Section 3: "Any identifier to be used as a URN MUST be expressed in conformance with the URI and URN syntax specifications ([RFC3986], this document)." Why is this requirement necessary? In Section 6: "Namespace registrations must include guidance on how to determine functional equivalence for that URN Namespace, i.e., when two URNs are identical within a namespace." Why is the above in this document? In Section 7: "At the time of publication of RFC 2141, no formal registration procedure for URI Schemes had been established yet, and so IANA only informally has registered the 'urn' URI Scheme with a reference to [RFC2141]." The above paragraph is not important within the context of this document. Although the draft is well-written, it was tedious for me to find actionable information. This turned into a disincentive to suggest text changes. RFC 2141 contained eight pages. The draft contains 32 pages. I suggest trimming the text. Using RFC 3906 as an example. the draft is clear when it discusses about syntax components. Regards, -sm From juha.hakala@helsinki.fi Wed Jun 27 23:17:50 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEA911E8135 for ; Wed, 27 Jun 2012 23:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qse3EmzVxM+g for ; Wed, 27 Jun 2012 23:17:49 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC511E8085 for ; Wed, 27 Jun 2012 23:17:47 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q5S6HiC7029269 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 28 Jun 2012 09:17:45 +0300 Message-ID: <4FEBF708.9030604@helsinki.fi> Date: Thu, 28 Jun 2012 09:17:44 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: urn@ietf.org References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> In-Reply-To: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 06:17:50 -0000 Hello, Concerning this: On 26.6.2012 19:10, Andy Newton wrote: > All, > Second, at IETF 83 Leslie Daigle proposed removing the fragment language from 2141bis and placing it in a separate draft to be moved forward as an Experimental RFC. If you have objections to this approach, please let us know (again, before July 13). I have an objection, but the fragment related sections of RFC2141bis must be made more clear. The terms and conditions governing the fragment use are on the one hand technical, and on the other hand identifier system dependent. From technical point of view, fragments are part of the URI but they are not part of the NSS. From identifier system point of view, fragments are only applicable when a) the identifier system covers only manifestations and b) single manifestation of a resource only gets one identifier, which is never re-assigned. In practice, this means that fragments are not applicable if the identifier covers immaterial works (like International Standard Text Code). Also, fragments cannot be used if the identifier covers multiple manifestations (for instance International Standard Serial Number applies to the entire journal). But fragments can be used with e.g. ISBNs since each ISBN is assigned to single manifestation of a book, such as PDF or XML version. Since fragment is not part of the namespace specific string, a user who for instance wants to cite a certain paragraph of an e-book may add a fragment to the existing URN:ISBN of the book in order to provide a persistent link to the paragraph (assuming that the e-book is structured in such a way that this is possible). When an e-book is migrated to another file format in order to preserve it, then according to the ISBN user guide the new version of the book must get another ISBN. Any identifier system which allows identification of multiple manifestations with a single identifier is not applicable for fragment use. Depending on what the list attendees agree on, we may place a text to the above effect into rfc2141bis or into an experimental document. But I hope that RFC2141bis will say at least that fragments are not part of the NSS but they can be used in those namespaces which specifically allow that. Best regards, Juha > > -andy > (obviously over-paid co-chair). > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From L.Svensson@dnb.de Thu Jun 28 02:42:37 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E93E21F89DE for ; Thu, 28 Jun 2012 02:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-VD83xh8fW0 for ; Thu, 28 Jun 2012 02:42:36 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3721F89AA for ; Thu, 28 Jun 2012 02:42:35 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 56234D5D81; Thu, 28 Jun 2012 11:42:34 +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.01.0355.002; Thu, 28 Jun 2012 11:42:33 +0200 From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" Thread-Topic: [urn] Finalizing items from IETF 83 Thread-Index: AQHNU7Y4WUUzenOcXE6c5NsjX0h0pJcPIoEAgABAjlA= Date: Thu, 28 Jun 2012 09:42:33 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> In-Reply-To: <4FEBF708.9030604@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.121] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 09:42:37 -0000 Juha wrote: > But > I hope that RFC2141bis will say at least that fragments are not part of > the NSS but they can be used in those namespaces which specifically > allow that. I'll second that RFC 2141bis says that fragment identifiers are allowed in = URNs but that they are not part of the NSS. Further, RFCs for new namespace= s must specify if they allow the use of fragment identifiers or not but I g= uess that is something for RFC 3406bis. All the best, Lars ***Lesen. H=F6ren. Wissen. 100 Jahre Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. A century of the German National Libr= ary*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de http://www.dnb.de/100jahre > -----Urspr=FCngliche Nachricht----- > Von: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] Im Auftrag von > Juha Hakala > Gesendet: Donnerstag, 28. Juni 2012 08:18 > An: urn@ietf.org > Betreff: Re: [urn] Finalizing items from IETF 83 >=20 > Hello, >=20 > Concerning this: >=20 > On 26.6.2012 19:10, Andy Newton wrote: > > All, >=20 > > Second, at IETF 83 Leslie Daigle proposed removing the fragment > language from 2141bis and placing it in a separate draft to be moved > forward as an Experimental RFC. If you have objections to this > approach, please let us know (again, before July 13). >=20 > I have an objection, but the fragment related sections of RFC2141bis > must be made more clear. >=20 > The terms and conditions governing the fragment use are on the one hand > technical, and on the other hand identifier system dependent. From > technical point of view, fragments are part of the URI but they are not > part of the NSS. From identifier system point of view, fragments are > only applicable when a) the identifier system covers only > manifestations and b) single manifestation of a resource only gets one > identifier, which is never re-assigned. >=20 > In practice, this means that fragments are not applicable if the > identifier covers immaterial works (like International Standard Text > Code). Also, fragments cannot be used if the identifier covers multiple > manifestations (for instance International Standard Serial Number > applies to the entire journal). But fragments can be used with e.g. > ISBNs since each ISBN is assigned to single manifestation of a book, > such as PDF or XML version. >=20 > Since fragment is not part of the namespace specific string, a user who > for instance wants to cite a certain paragraph of an e-book may add a > fragment to the existing URN:ISBN of the book in order to provide a > persistent link to the paragraph (assuming that the e-book is > structured in such a way that this is possible). >=20 > When an e-book is migrated to another file format in order to preserve > it, then according to the ISBN user guide the new version of the book > must get another ISBN. Any identifier system which allows > identification of multiple manifestations with a single identifier is > not applicable for fragment use. >=20 > Depending on what the list attendees agree on, we may place a text to > the above effect into rfc2141bis or into an experimental document. But > I hope that RFC2141bis will say at least that fragments are not part of > the NSS but they can be used in those namespaces which specifically > allow that. >=20 > Best regards, >=20 > Juha >=20 > > > > -andy > > (obviously over-paid co-chair). > > _______________________________________________ > > urn mailing list > > urn@ietf.org > > https://www.ietf.org/mailman/listinfo/urn >=20 > -- >=20 > Juha Hakala > Senior advisor, standardisation and IT >=20 > The National Library of Finland > P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University > Email juha.hakala@helsinki.fi, tel +358 50 382 7678 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From julian.reschke@gmx.de Thu Jun 28 03:09:54 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C71821F87DD for ; Thu, 28 Jun 2012 03:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMt5eHhVxpgs for ; Thu, 28 Jun 2012 03:09:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7F8D621F8A25 for ; Thu, 28 Jun 2012 03:01:53 -0700 (PDT) Received: (qmail invoked by alias); 28 Jun 2012 10:01:52 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp034) with SMTP; 28 Jun 2012 12:01:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19MOkxjr7RM3tS/HauxVV4Vx1NoOAAVjW48IlsiF4 2RbrS8rq4zw07Y Message-ID: <4FEC2B8C.4070604@gmx.de> Date: Thu, 28 Jun 2012 12:01:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Svensson, Lars" References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:09:54 -0000 On 2012-06-28 11:42, Svensson, Lars wrote: > Juha wrote: > >> But >> I hope that RFC2141bis will say at least that fragments are not part of >> the NSS but they can be used in those namespaces which specifically >> allow that. > > I'll second that RFC 2141bis says that fragment identifiers are allowed in URNs but that they are not part of the NSS. Further, RFCs for new namespaces must specify if they allow the use of fragment identifiers or not but I guess that is something for RFC 3406bis. No. Namespace specifications define the namespace-specific part; nothing else. Fragment syntax and semantics are defined by RFC 3986. A spec *can* point out that the URN does not identify something from which a payload + media type can be retrieved, in which fragment identifiers are not applicable. But that's different from disallowing them. Best regards, Julian From juha.hakala@helsinki.fi Thu Jun 28 04:53:00 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8309521F85A8 for ; Thu, 28 Jun 2012 04:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFCwG-sTxMuJ for ; Thu, 28 Jun 2012 04:53:00 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id AC76521F85A5 for ; Thu, 28 Jun 2012 04:52:58 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q5SBqrbV007339 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 28 Jun 2012 14:52:54 +0300 Message-ID: <4FEC4595.1020609@helsinki.fi> Date: Thu, 28 Jun 2012 14:52:53 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: Julian Reschke References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> In-Reply-To: <4FEC2B8C.4070604@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:53:00 -0000 Hello, On 28.6.2012 13:01, Julian Reschke wrote: > On 2012-06-28 11:42, Svensson, Lars wrote: >> I'll second that RFC 2141bis says that fragment identifiers are >> allowed in URNs but that they are not part of the NSS. Further, RFCs >> for new namespaces must specify if they allow the use of fragment >> identifiers or not but I guess that is something for RFC 3406bis. > > No. > > Namespace specifications define the namespace-specific part; nothing > else. Fragment syntax and semantics are defined by RFC 3986. > > A spec *can* point out that the URN does not identify something from > which a payload + media type can be retrieved, in which fragment > identifiers are not applicable. But that's different from disallowing them. OK. It should be possible to adjust the text in rfc2141bis to say that there are namespaces in which fragment usage is not applicable since the resources which can be identified within than namespace - say, textual works as abstract entities in URN:ISTC - will not have fragments in the RFC 3986 sense of the word. As far as I am concerned, it does no harm if the namespace registration request confirms that it is possible to use fragment to augment the functionality of the URNs from that particular namespace. For instance, I asked a permission from the ISBN Registration Authority to use fragments in the URN:ISBN namespace. Since this point will be made in the namespace registration request the national ISBN agencies and other ISBN users do not need to ask if fragments are allowed. And while some examples could be given in the namespace registration request it is definitely up to the URI Generic Syntax and other relevant technical documents to provide the necessary details for each document format. All the best, Juh > > Best regards, Julian -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From duerst@it.aoyama.ac.jp Fri Jun 29 03:18:13 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A421F8734 for ; Fri, 29 Jun 2012 03:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.239 X-Spam-Level: X-Spam-Status: No, score=-99.239 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oak04YfQGZ+V for ; Fri, 29 Jun 2012 03:18:12 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 874BD21F8735 for ; Fri, 29 Jun 2012 03:18:12 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5TAHxsH025789 for ; Fri, 29 Jun 2012 19:18:03 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1370_1e49_b390990e_c1d3_11e1_af2c_001d096c5782; Fri, 29 Jun 2012 19:17:58 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60501) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 29 Jun 2012 19:18:02 +0900 Message-ID: <4FED80D0.5000205@it.aoyama.ac.jp> Date: Fri, 29 Jun 2012 19:17:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Juha Hakala References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FEC4595.1020609@helsinki.fi> In-Reply-To: <4FEC4595.1020609@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 10:18:13 -0000 On 2012/06/28 20:52, Juha Hakala wrote: > On 28.6.2012 13:01, Julian Reschke wrote: >> Namespace specifications define the namespace-specific part; nothing >> else. Fragment syntax and semantics are defined by RFC 3986. >> >> A spec *can* point out that the URN does not identify something from >> which a payload + media type can be retrieved, in which fragment >> identifiers are not applicable. But that's different from disallowing >> them. > > OK. It should be possible to adjust the text in rfc2141bis to say that > there are namespaces in which fragment usage is not applicable since the > resources which can be identified within than namespace - say, textual > works as abstract entities in URN:ISTC - will not have fragments in the > RFC 3986 sense of the word. Strictly speaking, that's not true. It's perfectly possible to imagine (and even to set up, although that will require quite a bit of coordination) to have an identifier for "Much Ado about Nothing" and have fragment identifiers e.g. for Act I, II, III, IV, and V. These may not work with all resolution systems, or all representations, but that's not a problem. If a fragment identifier cannot be resolved, we just get the whole work. The only problem is when a fragment identifier leads to obviously different pieces in different representations (e.g. Act I in an XML representation and Act V in a mobi representation,...). All this isn't new for URNs, it's exactly the same as for content-negotiated HTTP resources (different languages, HTML vs. XML vs. SVG vs. JSON vs. RDF, just to name a few). > As far as I am concerned, it does no harm if the namespace registration > request confirms that it is possible to use fragment to augment the > functionality of the URNs from that particular namespace. For instance, > I asked a permission from the ISBN Registration Authority to use > fragments in the URN:ISBN namespace. Since this point will be made in > the namespace registration request the national ISBN agencies and other > ISBN users do not need to ask if fragments are allowed. Nobody should have to ask. If it works, you can use it. If you can't make it work, it's a bad idea. > And while some > examples could be given in the namespace registration request it is > definitely up to the URI Generic Syntax and other relevant technical > documents to provide the necessary details for each document format. Yes indeed. Regards, Martin. From jonathan.rees@gmail.com Fri Jun 29 07:00:47 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431EF21F86B1 for ; Fri, 29 Jun 2012 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk2bWY6g2yN3 for ; Fri, 29 Jun 2012 07:00:46 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB821F86C2 for ; Fri, 29 Jun 2012 07:00:46 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4750881pbc.31 for ; Fri, 29 Jun 2012 07:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5L4lYXoz4YhYmTzY6tC29xTL/XEvcwCEbmJaGPnLh5U=; b=N0PR3zT93fK1YI+q/soH0hZF6lyYSfG2IaVqUzb6jhgUc+I/ZL+ccV69pn4RraLU5m t/WUOuC1Fk3S2Yg5DYAD9Zk3KVki+i6Dxq2umLYZpGBep/+zRQPy68U+HcdR6QKmA0DA BhUuCyYfx1sjABb60MKg0djv+/HMLfabOLG0S+OO9Foloi0EqytEmZbjxyGCF3cJoVvN nYm2R228DS0VjS8p+SqD1o/5cjlewWZZf4z+rPekjIAllumeBURPwAowPDjLWk6TJRcj dd4jvbuBUK7k7CK7luK1rrIR0xC0xWJPRhiQe8MJsZRWle52MRJErEjLishWEH0Ttt/Y Bz9g== MIME-Version: 1.0 Received: by 10.68.229.2 with SMTP id sm2mr7469409pbc.57.1340978445963; Fri, 29 Jun 2012 07:00:45 -0700 (PDT) Sender: jonathan.rees@gmail.com Received: by 10.142.134.8 with HTTP; Fri, 29 Jun 2012 07:00:45 -0700 (PDT) In-Reply-To: <4FED80D0.5000205@it.aoyama.ac.jp> References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FEC4595.1020609@helsinki.fi> <4FED80D0.5000205@it.aoyama.ac.jp> Date: Fri, 29 Jun 2012 10:00:45 -0400 X-Google-Sender-Auth: E1LuMsZHLuyjN-V1pO3pFCbvn_4 Message-ID: From: Jonathan A Rees To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:00:47 -0000 I think the goal is for URIs of the form urn:x#fragid to also have URN-like properties, just as urn:x does., i.e. name-like and persistent. RIght? And this appears to be in conflict with the fact that the semantics of such URIs is determined by 3986, not by the URI scheme registration. I offer (again) the following compromise for your consideration; I have no dog in this race: If those registering namespaces want to constrain the semantics of urn: URIs with fragment identifiers, it would be possible to do so indirectly, by constraining the possible representations yielded by URN resolver infrastructure. E.g. if urn:x#part1 was supposed to name part 1 of , then the registration could say (or imply) that a resolver MUST only yield representations in which #part1 names part 1. Or perhaps it would be OK to yield some representations in which #part1 did not name anything at all. Then you would say: A resolver MUST NOT yield a representation in which the semantics of #part1 is inconsistent with urn:x#part1 being a name for (whatever). Whether this would work in one of the many unclear aspects of fragment identifier semantics (see http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html ). That is, per 3986, fragment id semantics depends on media types, so if a spec wants to constrain fragment id semantics, its only option is to do so indirectly, by constraining the representations to which the URN resolves. A weakness of this approach would be differentiating between persistent fragment identifiers and ephemeral ones. If someone gets a representation, and discovers a fragment identifier definition inside it, they will have no way of knowing the persistence commitment of that fragment identifier. Best Jonathan On Fri, Jun 29, 2012 at 6:17 AM, "Martin J. D=FCrst" wrote: > On 2012/06/28 20:52, Juha Hakala wrote: > >> On 28.6.2012 13:01, Julian Reschke wrote: > > >>> Namespace specifications define the namespace-specific part; nothing >>> else. Fragment syntax and semantics are defined by RFC 3986. >>> >>> A spec *can* point out that the URN does not identify something from >>> which a payload + media type can be retrieved, in which fragment >>> identifiers are not applicable. But that's different from disallowing >>> them. >> >> >> OK. It should be possible to adjust the text in rfc2141bis to say that >> there are namespaces in which fragment usage is not applicable since the >> resources which can be identified within than namespace - say, textual >> works as abstract entities in URN:ISTC - will not have fragments in the >> RFC 3986 sense of the word. > > > Strictly speaking, that's not true. It's perfectly possible to imagine (a= nd > even to set up, although that will require quite a bit of coordination) t= o > have an identifier for "Much Ado about Nothing" and have fragment > identifiers e.g. for Act I, II, III, IV, and V. These may not work with a= ll > resolution systems, or all representations, but that's not a problem. If = a > fragment identifier cannot be resolved, we just get the whole work. The o= nly > problem is when a fragment identifier leads to obviously different pieces= in > different representations (e.g. Act I in an XML representation and Act V = in > a mobi representation,...). > > All this isn't new for URNs, it's exactly the same as for content-negotia= ted > HTTP resources (different languages, HTML vs. XML vs. SVG vs. JSON vs. RD= F, > just to name a few). > > > >> As far as I am concerned, it does no harm if the namespace registration >> request confirms that it is possible to use fragment to augment the >> functionality of the URNs from that particular namespace. For instance, >> I asked a permission from the ISBN Registration Authority to use >> fragments in the URN:ISBN namespace. Since this point will be made in >> the namespace registration request the national ISBN agencies and other >> ISBN users do not need to ask if fragments are allowed. > > > Nobody should have to ask. If it works, you can use it. If you can't make= it > work, it's a bad idea. > > >> And while some >> examples could be given in the namespace registration request it is >> definitely up to the URI Generic Syntax and other relevant technical >> documents to provide the necessary details for each document format. > > > Yes indeed. > > Regards, =A0 =A0Martin. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn