From internet-drafts@ietf.org Mon Mar 5 12:59:43 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 BB10121F8879; Mon, 5 Mar 2012 12:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 2pQLS2-zZVge; Mon, 5 Mar 2012 12:59:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4B21F87DB; Mon, 5 Mar 2012 12:59:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305205943.4639.25901.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 12:59:43 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3044bis-issn-urn-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:59:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Worki= ng Group of the IETF. Title : Using International Standard Serial Numbers as Uniform R= esource Names Author(s) : Pierre Godefroy Filename : draft-ietf-urnbis-rfc3044bis-issn-urn-00.txt Pages : 19 Date : 2012-02-24 The International Standard Serial Number, ISSN, has been the authoritative identifier for continuing resources (which include serials) for more than three decades. Since 2001, the URN (Uniform Resource Name) namespace "ISSN" has been reserved for ISSNs. The namespace registration was performed in RFC 3044. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). Moreover, additional syntax related information required by the RFC 2141[bis] has been included. An updated namespace registration is provided. This document replaces RFC 3044. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3044bis-issn-urn-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3044bis-issn-urn-00= .txt From A.Hoenes@TR-Sys.de Tue Mar 6 01:36:33 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 A096721F881A for ; Tue, 6 Mar 2012 01:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.376 X-Spam-Level: X-Spam-Status: No, score=-98.376 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 8y97dgTXOLBj for ; Tue, 6 Mar 2012 01:36:33 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 63CB821F8817 for ; Tue, 6 Mar 2012 01:36:32 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA126706529; Tue, 6 Mar 2012 10:35:29 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA00789; Tue, 6 Mar 2012 10:35:27 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203060935.KAA00789@TR-Sys.de> To: urn@ietf.org Date: Tue, 6 Mar 2012 10:35:27 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] Status of draft-ietf-urnbis-rfc3044bis-issn-urn-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:36:33 -0000 [ speaking as a WG chair ] URN folks, it looks like software transition artifacts have negatively affected the submission of draft-ietf-urnbis-rfc3044bis-issn-urn-00 (as announced to the list in the message filed at http://www.IETF.ORG/mail-archive/web/urn/current/msg01704.html ) : - Publication of the draft has been inadvertently delayed for more than a week; this has been resolved yesterday by manual intervention of the IETF Secretariat -- thanks! - In some web pages, the draft is still listed as an individual draft, not a WG draft; this will be corrected -- that draft indeed _is_ a chartered work item of URNbis, and it has been accepted as such. Thanks to Pierre Godefroy and his co-workers from the ISSN International Center for taking up this project ! Kind regards, Alfred. From internet-drafts@ietf.org Sun Mar 11 18:05: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 4437E21F858E; Sun, 11 Mar 2012 18:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 VUG942TqXStv; Sun, 11 Mar 2012 18:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98BE21F852A; Sun, 11 Mar 2012 18:05:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 18:05:53 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 01:05:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Worki= ng Group of the IETF. Title : Uniform Resource Name (URN) Syntax Author(s) : Alfred Hoenes Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt Pages : 32 Date : 2012-03-11 Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt From A.Hoenes@TR-Sys.de Sun Mar 11 18:17:40 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 1EB0821F859F for ; Sun, 11 Mar 2012 18:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.581 X-Spam-Level: X-Spam-Status: No, score=-98.581 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 5IFN1giIdp7C for ; Sun, 11 Mar 2012 18:17:39 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 754C821F8596 for ; Sun, 11 Mar 2012 18:17:38 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA163244994; Mon, 12 Mar 2012 02:16:34 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA14649; Mon, 12 Mar 2012 02:16:33 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203120116.CAA14649@TR-Sys.de> To: urn@ietf.org Date: Mon, 12 Mar 2012 02:16:32 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] New Version Notification for draft-ietf-urnbis-rfc2141bis-urn-02.txt (fwd) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 01:17:40 -0000 URNbis folks, I just have submitted a new version of the RFC 2141bis draft that contains quite some changes based on accumulated list discussion and an editorial pass (please note that the updated RFC 3406bis -02 draft already referenced herein will be submitted soon): ----- Forwarded message from internet-drafts@ietf.org ----- > From: internet-drafts@ietf.org > To: ah@TR-Sys.de > Message-Id: <20120312010553.16681.36732.idtracker@ietfa.amsl.com> > Date: Sun, 11 Mar 2012 18:05:53 -0700 > Subject: New Version Notification for draft-ietf-urnbis-rfc2141bis-urn-02 A new version of I-D, draft-ietf-urnbis-rfc2141bis-urn-02.txt has been successfully submitted by Alfred Hoenes and posted to the IETF repository. Filename: draft-ietf-urnbis-rfc2141bis-urn Revision: 02 Title: Uniform Resource Name (URN) Syntax Creation date: 2012-03-12 WG ID: urnbis Number of pages: 32 Abstract: Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. 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 IETF Secretariat ----- End of forwarded message from internet-drafts@ietf.org ----- Here is a summary of the changes, as listed in the Appendix D.6 of the I-D: D.6. Changes from WG Draft -01 to WG Draft -02 Added note at the beginning of Section 1.2 highlighting the purpose of this section. The URNbis charter excludes a revision of RFC 1738, and hence the changes suggested on the list to alter and update this section have been dismissed. Added hint to URN Namespace designers in Section 2 that ":" is customarily used in URN Namespaces to provide further level(s) of hierarchical subdivision of NSSs. Reworked text on fragment identification issues and resulting specification, mostly based on Juha Hakala's evaluation of the consensus evolving from the list discussion. Modified ABNF rule for NIDs to better align it with rules for similar identifiers used in IETF protocols. The new rule now prohibits a trailing hyphen, but defers further restricting rules on NID syntax (based on the kind of NID) to RFC 3406bis. More clearly documented and marked (still open / already closed) ISSUES. The related text will be removed in the next draft version, whence it should have been transferred into the IETF issue tracking system. Text of Section 3 revised, based on Juha's suggestion. In Section 5, added removal of part (but not part) to canonicalization steps for the purpose of determining lexical equivalence of URNs (Juha's comment). Also added examples showing this. Elaborated a bit more on Encoding Consideration in the URI Scheme registration template (Juha's comments). Numerous editorial corrections and improvements. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From internet-drafts@ietf.org Mon Mar 12 13:20:36 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 2E85621F8957; Mon, 12 Mar 2012 13:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 KzQg1Wcgt2Hp; Mon, 12 Mar 2012 13:20:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899E21F88EE; Mon, 12 Mar 2012 13:20:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:20:35 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:20:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Worki= ng Group of the IETF. Title : Uniform Resource Name (URN) Namespace Definition Mechani= sms Author(s) : Alfred Hoenes Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt Pages : 30 Date : 2012-03-12 Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. To structure and organize their usage, the URN syntax (RFC 2141bis) specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified documents, artifacts, and other objects (and metadata related to them). To achive these goals, URN Namespaces need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these Namespace registration documents. This RFC serves as a guideline for authors of URN Namespace definition and registration documents and the process to be followed to register a URN Namespace with IANA. It describes the essential content of such documents and how they shall be structured to allow readers familar with the scheme to quickly assess the properties of a specific URN Namespace. This document is a companion document to the revised URN Syntax specification, RFC 2141bis; it supersedes and replaces RFC 3406. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg= -02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-= 02.txt From A.Hoenes@TR-Sys.de Mon Mar 12 13:53:30 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 1C07C11E811A for ; Mon, 12 Mar 2012 13:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.589 X-Spam-Level: X-Spam-Status: No, score=-98.589 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 H58zZy5FXc4r for ; Mon, 12 Mar 2012 13:53:29 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1011E8104 for ; Mon, 12 Mar 2012 13:53:25 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA168935541; Mon, 12 Mar 2012 21:52:21 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA22918; Mon, 12 Mar 2012 21:52:20 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203122052.VAA22918@TR-Sys.de> To: urn@ietf.org Date: Mon, 12 Mar 2012 21:52:20 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:53:30 -0000 URNbis colleagues, [ speaking again as the document editor ] I have just (in time) completed and uploaded an update to the RFC 3406bis draft, one of our basic work items. As usual, all related information, starting with the HTML-ized version of the draft, and including diffs to the previous version are available at: Please review the draft (and the changes) and focus your comments on the remaining issues. For your convenience, the change and issue summaries contained in the draft are attached inline below, after the forwarded draft announcement. Unfortunately, list discussion has been interesting in the past, but largely not very focussed on the draft text. This has been summed up by Peter Saint-Andre his message sent on "Wed, 11 Jan 2012 15:52:10 -0700" and archived at , which concluded with the question: > In any case, what is the practical output of this discussion > in terms of specification text? I have to admit: not very much. :-( So please help the editor by giving focussed review comments and proposed alternative text or text deltas for where you think it is needed. Kind regards Alfred. ----- Forwarded message from internet-drafts@ietf.org ----- > From: internet-drafts@ietf.org > To: ah@TR-Sys.de > Message-Id: <20120312202035.21803.80702.idtracker@ietfa.amsl.com> > Date: Mon, 12 Mar 2012 13:20:35 -0700 > Subject: New Version Notification for > draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt A new version of I-D, draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt has been successfully submitted by Alfred Hoenes and posted to the IETF repository. Filename: draft-ietf-urnbis-rfc3406bis-urn-ns-reg Revision: 02 Title: Uniform Resource Name (URN) Namespace Definition Mechanisms Creation date: 2012-03-12 WG ID: urnbis Number of pages: 30 Abstract: Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. To structure and organize their usage, the URN syntax (RFC 2141bis) specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified documents, artifacts, and other objects (and metadata related to them). To achive these goals, URN Namespaces need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these Namespace registration documents. This RFC serves as a guideline for authors of URN Namespace definition and registration documents and the process to be followed to register a URN Namespace with IANA. It describes the essential content of such documents and how they shall be structured to allow readers familar with the scheme to quickly assess the properties of a specific URN Namespace. This document is a companion document to the revised URN Syntax specification, RFC 2141bis; it supersedes and replaces RFC 3406. The IETF Secretariat ----- End of forwarded message from internet-drafts@ietf.org ----- -------- begin of excerpt from draft -------- C.4. Changes from URNbis WG I-D -01 to -02 General text edits based on evaluation of meeting and on-list comments. Updated and tightened the organizatorial requirements for Formal Namespace requests. Restored additional IANA Considerations -- due to observed defects. Reserved NID strings "example.*" for documentation (as suggested by Larry Masinter, Peter Saint-Andre, and Julian Reschke). Added text on possible "higher level" methods to establish lexical equivalence of URNs, with the caveats that such things are rather unlikely to get traction in general-purpose client software. Removed historical Appendix B.1 (Example Template). Various editorial enhancements and fixes. Updated and expanded "Issues" Appendix (below) in preparation of usage of the IETF Issue Tracker. Appendix D. Issues in this Draft [ Appendix to be replaced by use of IETF Tools issue tracker. ] For more details on the issues below, please also see the Editorial Notes interspersed in the body of this draft. Discuss consequences of RFC 2141bis (once consensus is achieved); if proposal for fragment part is adopted, details need to be described per Namespace that wants to adopt these possibilities, and maybe the registration template needs a new clause where this will be specified -- or the information has to be assigned to existing clauses. Do registration documents need more guidance and be caused to be more precise in their elaboration on the applicability of Services? Since RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a URNbis work item), we might need a registry for URN Services (initially populated from RFC 2483) that can be referred to in Namespace registration documents, thus avoiding normative dependencies on a future RFC 2483bis. Do we actually need Experimental Namespaces? [Regarded as CLOSED affirmatively at IETF 80.] There are concerns regarding usage of "X-" NIDs, which is reported to having proven impractical in practice. This draft version contains tentative text to address these concerns; "X-" is now demoted to "SHOULD" level. The syntax of the NID strings for the various NID types is given in an informal manner (as has been done in RFC 3406); is it worth the effort to introduce ABNF for this purpose? [The request for ABNF has been voiced only once; the document Editor regards this issue as CLOSED.] Increase review/timeout periods for urn-nid list and IANA experts from 2 to 4 (or more) weeks? This draft version tentatively specifies 4 weeks. Juha Hakala has argued that the assessment of the responsible organizations needed to assure their ability to properly operate the Namespace could never be performed within the present 2 weeks time span; 8 weeks might be an even better choice for the future upper limit for the review period. It has been pointed out that even 8 weeks are miniscule with regard to the expected lifetime of the to- be-registered Namespace and hence should not matter. In practice, the subsequent IESG evaluation of URN Namespace registration documents has typically needed much longer time. Clarification of the desired content of the "Namespace Considerations" and "Community Considerations" sections in registration documents. Shall we admit a combined section for both topics? (so far supported by 2 postings) Cf. the NOTEs in Sections 4.4.1 and 4.4.2 for more details. [No feedback on the list since -01, so the draft text seems to have silent consensus and the issue is regarded as CLOSED.] Shall other strings beyond "urn" also be 'reserved' in the NID registry? (e.g. "uri", "url", "urc", ...) There have been voices in favor of leaving the decision of what is acceptable and reasonable in practice to the common sense of prospective registrants and the designated IANA experts. This draft version reserves NID strings matching the RE "^example.*" for documentation. Appendix A: Once RFC 2483 gets updated and an IANA registry for URN resolution services gets established, the "Process for identifier resolution" clause in the registration template should call out for enumerating the registered services that are applicable for the newly defined URN Namespace. How far can we go in this respect without an update to RFC 2483 at hands? Do we really still need Appendix B.1 ? (There are lots of real-life examples now!) [ Old B.1 removed, old B.2 became Appendix B; ==> CLOSED ] -------- end of excerpt from draft -------- From andy@hxr.us Tue Mar 13 18:43: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 BDA3F21F84F1 for ; Tue, 13 Mar 2012 18:43:54 -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 pFL83n5BTMUZ for ; Tue, 13 Mar 2012 18:43:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5F721F84EB for ; Tue, 13 Mar 2012 18:43:54 -0700 (PDT) Received: by yhpp34 with SMTP id p34so1450077yhp.31 for ; Tue, 13 Mar 2012 18:43:53 -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=SUbFgWWBwUJ295a03qiOkKzEvxPpanfGAKeZmDgYG/s=; b=TJ+kQbMsECjPBrUQ2d+7RhL7cRGJAvp/TdFNNR6XLDNhlR7PFe5tyNOhoECDqX/z7+ 9TZvoGmkzy6A3iajHjPWmsE0SO0HXdXqxJ4h+CaMedfT81tJUEf9yG6Y+MWqGl3eD0OM xYM8DgJZWKK8AhskYWLkercwShPRdL4FEkjj5M/3P7wCKuJQvRIfduXsiKVoHyIWONxJ 9+Vm3lhmVnYUZFWIN+CLkCLGJXi/kZlGnbZ4PisrnSePl5etYY9DUDF9tT5LlCBJiQ9Q cuihs9u7iTHY69fKtb/UA5iGu9BQD/brGh544QxkCvMf7jyzHgA2od9w6+ugHR9kXjJV aRRg== Received: by 10.60.12.103 with SMTP id x7mr794832oeb.51.1331689433708; Tue, 13 Mar 2012 18:43:53 -0700 (PDT) Received: from [10.0.1.10] (ip68-98-152-27.dc.dc.cox.net. [68.98.152.27]) by mx.google.com with ESMTPS id v10sm3465907obb.4.2012.03.13.18.43.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 18:43:52 -0700 (PDT) From: Andy Newton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Mar 2012 21:43:51 -0400 Message-Id: <861C558A-B156-4D0B-A3B0-18A02BD46817@hxr.us> To: urn@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl//UbA2tOMDSlhr4dSgULoVaN/jTjFV20GXaXyPR9MJwVrZ+pmbW06zis3NQjJ17Bs6yR3 Subject: [urn] draft agenda for IETF 83 posted X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 01:43:54 -0000 No shocking endings or high drama, but I tried. :) http://www.ietf.org/proceedings/83/agenda/agenda-83-urnbis.txt -andy From prvs=0420a0dbfd=bengt.neiss@kb.se Wed Mar 14 01:36:18 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 6500521F86EE for ; Wed, 14 Mar 2012 01:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zObdj70PPotW for ; Wed, 14 Mar 2012 01:36:17 -0700 (PDT) Received: from mspkb002.kb.se (mspkb002.kb.se [193.10.72.137]) by ietfa.amsl.com (Postfix) with ESMTP id 86B7521F86DC for ; Wed, 14 Mar 2012 01:36:16 -0700 (PDT) Authentication-Results: mspkb002.kb.se header.from=bengt.neiss@kb.se; domainkeys=neutral (no sig) From: Bengt Neiss To: "urn@ietf.org" Thread-Topic: A comment on draft-ietf-urnbis-rfc2141bis-urn-02 Thread-Index: Ac0BvTMxBBzUezMySK+yL8oiu8BsCA== Date: Wed, 14 Mar 2012 08:36:12 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F52230A186DA59469E8E21CF80FE6D4D0F24911ESRVVM305kblocal_" MIME-Version: 1.0 Received-SPF: none Subject: [urn] A comment 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, 14 Mar 2012 08:36:18 -0000 --_000_F52230A186DA59469E8E21CF80FE6D4D0F24911ESRVVM305kblocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Just a comment on the text of the new text (RFC2141bis-urn-02) I am concerned about the phrase "special meaning" in the text in the sectio= n "2.3.2. The percent character, percent encoding" as follows "Namespaces MAY designate one or more characters from the URN character repertoire as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Further, a character MUST NOT be percent-encoded if the character is not a reserved character." Does "special meaning" mean "reserved character (should be treated as a res= erved character within that namespace)" and thus MUST be percent encoded if= it is used in a literal sense within the NSS? In section "4.4 Additional considerations" in RFC3188bis-nbn-urn-03 the fol= lowing text can be found: "Hyphen MUST be used as the delimiting character between the prefix and the NBN string. Within the NBN string, hyphen MAY be used for separating different sections of the identifier from one another." My interpretation of this text is that URN's can look like "urn:nbn:se:kb-1= 234-5678" Is hyphen in this text a character with a "special meaning"? Depending on how the text about "special meaning" is interpreted the text a= bout the use of hyphen in the NBN namespace might violate the section in RF= C2141bis. I think the phrase "special meaning" needs some clarification. Regards, //Bengt --------------------------------------------------------- Bengt Neiss Kungl. Biblioteket / National Library of Sweden Phone: +46 (0)10 709 35 41 --_000_F52230A186DA59469E8E21CF80FE6D4D0F24911ESRVVM305kblocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Just a comment on the text of t= he new text (RFC2141bis-urn-02)

 

I am concerned about the phrase= “special meaning” in the text in the section “2.3.2. The= percent character, percent encoding” as follows

 

“Namespaces MAY designate one or more chara=
cters from the URN

character repertoir= e as having special meaning for that namespace.

If the namespace al= so uses that character in a literal sense as well,

the character used = in a literal sense MUST be encoded with "%"

followed by the hex= adecimal representation of that octet.  Further, a

character MUST NOT = be percent-encoded if the character is not a

reserved character.”

 

 

Does ”special= meaning” mean ”reserved character (should be treated as a rese= rved character within that namespace)” and thus MUST be percent encod= ed if it is used in a literal sense within the NSS?

 

 

In section “4= .4 Additional considerations” in RFC3188bis-nbn-urn-03 the following = text can be found:

 
“Hyphen MUST be used as the delimiting char=
acter between the prefix
 and the NBN string.  Within the NBN string,=
 hyphen MAY be used for
 separating different sections of the identifier =
from one another.”

 

My interpretation o= f this text is that URN’s can look like “urn:nbn:se:kb-1234-567= 8”

Is hyphen in this t= ext a character with a “special meaning”?

 

Depending on how th= e text about “special meaning” is interpreted the text about th= e use of hyphen in the NBN namespace might violate the section in RFC2141bis.

 

 

I think the phrase = “special meaning” needs some clarification.

 

 

Regards,=

 

//Bengt<= /span>

 

 

 

 

---------------------------------------------------------

Bengt Neiss

Kungl. Biblioteket / National Library of Sweden

Phone: +46 (0)10 709 35 41

 

--_000_F52230A186DA59469E8E21CF80FE6D4D0F24911ESRVVM305kblocal_-- From A.Hoenes@TR-Sys.de Wed Mar 14 07:34:06 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 C19E021F854E for ; Wed, 14 Mar 2012 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.295 X-Spam-Level: X-Spam-Status: No, score=-98.295 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=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 FqcNouPmIZkl for ; Wed, 14 Mar 2012 07:34:06 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id B999721F8512 for ; Wed, 14 Mar 2012 07:34:04 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA181345575; Wed, 14 Mar 2012 15:32:55 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA07222; Wed, 14 Mar 2012 15:32:53 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203141432.PAA07222@TR-Sys.de> To: bengt.neiss@kb.se Date: Wed, 14 Mar 2012 15:32:53 +0100 (MEZ) In-Reply-To: from Bengt Neiss at Mar "14, " 2012 "08:36:12" am 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] A comment 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, 14 Mar 2012 14:34:07 -0000 On 2012-03-14, Bengt Neiss wrote: > Hi all, > > Just a comment on the text of the new text (RFC2141bis-urn-02) Bengt, thanks for taking the time to look into the drafts and commenting. [[ speaking as the author/editor of the quoted I-Ds ]] > I am concerned about the phrase "special meaning" in the text in the > section "2.3.2. The percent character, percent encoding" as follows > > > "Namespaces MAY designate one or more characters from the URN > character repertoire as having special meaning for that namespace. > If the namespace also uses that character in a literal sense as well, > the character used in a literal sense MUST be encoded with "%" > followed by the hexadecimal representation of that octet. Further, a > character MUST NOT be percent-encoded if the character is not a > reserved character." > > > Does "special meaning" mean "reserved character (should be treated as > a reserved character within that namespace)" and thus MUST be percent > encoded if it is used in a literal sense within the NSS? The quoted paragraph is carried over from RFC 2141 *top of page 4) into the current draft almost unchanged -- the only changes are - to avoid messing up with well established character set terminology, "character repertoire" is used in place of "character set"; - "%-encoding" is uniformly spelled out as "percent-encoding" throughout the draft. The important point here, IMO is the conjunction -- the character must both have special (semantical and/or syntactical) meaning within the existing namespace, AND it is desired to make use of it in the assigned strings of that namespace in the literal form, i.e. without that special meaning. > In section "4.4 Additional considerations" in > RFC3188bis-nbn-urn-03 the following text can be found: > > "Hyphen MUST be used as the delimiting character between the prefix > and the NBN string. Within the NBN string, hyphen MAY be used for > separating different sections of the identifier from one another." > > My interpretation of this text is that URN's can look like > "urn:nbn:se:kb-1234-5678" > Is hyphen in this text a character with a "special meaning"? > > Depending on how the text about "special meaning" is interpreted > the text about the use of hyphen in the NBN namespace might > violate the section in RFC2141bis. NBN is not a single pre-existing namespace. For the construction of the URN:NBN namespace, the nationally assigned NBN strings are prefixed -- as in your example -- with the URI scheme (urn), the URN NID (nbn), and the NBN prefix (se:kb). The rfc3188bis draft is intended to make it clear that it does not regard the hyphen character as a character of the type referred to in the above quote from RFC 2141[bis], by giving only the leftmost instance of hyphen in the NSS a special meaning -- and this hyphen is outside the assigned NBN string. To this end, the "Declaration of syntactic structure of NSS part" clause in the filled-out Namespace registration template in Section 5 of draft-ietf-urnbis-rfc3188bis-urn-nbn-03 states, first ... | The namespace-specific string (NSS) will consist of three parts: | | a prefix, consisting of an ISO 3166-1 alpha-2 country code and | optional sub-namespace code(s) separated by colon(s), | | a hyphen (-) as the delimiting character, and | | an NBN string assigned by the national library or sub-delegated | authority. ... and, below the ABNF formalizing that the prefix cannot contain a hyphen, but assigned NBN strings can, the prose states ... | Hyphen MUST be used as the delimiting character between the prefix | and the NBN string. Within the NBN string, hyphen MAY be used for | separating different sections of the identifier from one another. The final sentence reflects existing usage of hyphen in assigned NBN strings. Should a National library want to also use hyphens within one of more of the different sections of such identifiers, it would need to be escaped; but such practice is deemed very confusing, has not been observed in practice, and hence is not being sanctioned by the rfc3188bis draft. This way, in my and Juha's opinion, the second precondition from RFC 21410bis) is not fulfilled here. Therefore, I do not believe that we have a problem here. > I think the phrase "special meaning" needs some clarification. If you have an idea of how to further clarify the above quoted paragraph from the rfc2141bis draft (or any text in the rfc3188bis draft), please suggest suitable replacement text (together with clear enough editing instructions to allow us to correctly place it to reflect your intent). Note that any new text must be compatible with the original one from RFC 2141 to avoid any doubt that rfc2141bis could break URN Namespaces registered based on RFC 2141 (and RFC 3406). > Regards, > > //Bengt > > --------------------------------------------------------- > Bengt Neiss > Kungl. Biblioteket / National Library of Sweden > Phone: +46 (0)10 709 35 41 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Mar 21 08:08:15 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 3617B21F8646 for ; Wed, 21 Mar 2012 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.305 X-Spam-Level: X-Spam-Status: No, score=-98.305 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 ZbsdDeVTUQd6 for ; Wed, 21 Mar 2012 08:08:14 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4B21F863F for ; Wed, 21 Mar 2012 08:08:12 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA230362425; Wed, 21 Mar 2012 16:07:05 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA23963; Wed, 21 Mar 2012 16:07:04 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203211507.QAA23963@TR-Sys.de> To: godefroy@issn.org, urn@ietf.org Date: Wed, 21 Mar 2012 16:07:03 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:08:15 -0000 [ speaking as an individual ] I have reviewed draft-ietf-urnbis-rfc3044bis-issn-urn-00 and would like to offer some comments (see below). A much larger bunch of editorial nits is being reported off-list to the author, to avoid too much on-list "noise", and for efficiency. (Speaking as a co-chair as well: Accordingly, I would appreciate other reviewers to send nits off-list and/or wait until the next draft version had a chance to act upon the current batch.) Overall, the draft seems to be in a very good shape already for an -00 draft version. Given the internal, informal approval by the ISSN International Centre already obtained for the technical content of the draft, I hope that enough qualified reviews will soon support progressing this document. Here are my suggestions for further improvements of the draft: (1) Emphasis on backwards compatibility (1.1) In the Abstract, I suggest to add some emphasis on the goal of backwards compatibility achieved by this document -- in line with the URNbis charter and theintended clarity for readers (and reviewers). For instance: OLD: [...]. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). [...] NEW: [...]. This document | redefines -- in a backwards compatible manner -- how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). [...] (1.2) Similarly, I suggest to add at the very end of Section 1 the following clause: | This version of the URN:ISSN registration is fully backwards | compatible with the original one, in the sense that all ISSN URNs | assigned under RFC 3044 remain valid and semantically unchanged. (2) Discussion of Fragment Usage The 2nd para of Section 3.2 says: OLD: Continuing resources, including serials, most often consist of component parts such as volumes, issues, articles. The ISSN standard does not allow augmentation of the ISSN of the resource with (URI) fragments for identification of component parts. If a fragment identifier is added to an ISSN, the resulting namespace specific string will not be an ISSN. This elaboration seems to be a bit twisted in detail. >From a syntax perspective, a URI is not a part of the Namespace Specific String (NSS) of a URN (cf. the RFC 2141bis draft). Further, embedding an existing namespace into a URN Namespace does not necessarily mean that the NSS needs to be (modulo encoding, perhaps) exactly the pre-existing (externally assigned) identifier from the originating namespace. There can be some additions, as long as these can be syntactically recognized and separated out, if needed (e.g., for resolution systems); one example is the URN Namespace for NBNs, which incorporates a disambiguating prefix into the NSS, in addition to the primary (nationally assigned) NBN string. So most likely the above quoted paragraph can be simplified. For instance: NEW: Continuing resources, including serials, most often consist of component parts such as volumes, issues, articles. The ISSN standard | does not allow the identifiaction of component parts of the serial | designated by the ISSN, and the URN:ISSN Namespace equally does not | support such augmentation -- neither by an added NSS component nor by | use of URI fragment identifiers. (3) Section structure (1) Section 4.1 contains an apparent sub-heading reading "Allocation of blocks of ISSN" I suggest to turn this line into a sub-section headline, and as such turning this and the rest of s4.1 into a new subsection 4.1.1. (4) Section structure (2) Section 4.5.2 does not seem to be logically subordinate to Section 4.5. I suggest to 'elevate' Section 4.5.2 to become Section 4.6. (5) Section 5.1 (Updated Namespace registration) It might be worth aligning the presentation of this section with the style used in the Appendix of the rfc3406bis draft for the formatting of the registration template -- uniformity should further uniform use of URN Namespace definitions. (This tuning update can be deferred until the rfc3406bis draft has finally stabilized with regard to this template.) Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From masinter@adobe.com Fri Mar 23 01:19:07 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 9F77521F84B2 for ; Fri, 23 Mar 2012 01:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.67 X-Spam-Level: X-Spam-Status: No, score=-106.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Z6UvCC716QrK for ; Fri, 23 Mar 2012 01:19:03 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id A4C9A21F84AF for ; Fri, 23 Mar 2012 01:19:00 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT2wx8kMqbCbZTitL3Q5o8fc1BO/l6i8b@postini.com; Fri, 23 Mar 2012 01:19:00 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2N8Iuvq022953; Fri, 23 Mar 2012 01:18:57 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2N8ItMM016478; Fri, 23 Mar 2012 01:18:55 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Fri, 23 Mar 2012 01:18:55 -0700 From: Larry Masinter To: Andy Newton , "urn@ietf.org" Date: Fri, 23 Mar 2012 01:18:53 -0700 Thread-Topic: [urn] draft agenda for IETF 83 posted Thread-Index: Ac0Bg+2Rcglz6GbFRGm6V4z+6EO1ewHSTOfg Message-ID: References: <861C558A-B156-4D0B-A3B0-18A02BD46817@hxr.us> In-Reply-To: <861C558A-B156-4D0B-A3B0-18A02BD46817@hxr.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] draft agenda for IETF 83 posted 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, 23 Mar 2012 08:19:07 -0000 It looks like you have 45 minutes in your agenda but a 1-hour slot. I wonder if I could take 10 minutes (preferably early) to present a model = for URN namespaces registries in the general sense used in, say, http://www= .w3.org/2001/tag/2011/12/evolution/Registries.html (part of http://www.w3.= org/2001/tag/2011/12/evolution/ ). -----Original Message----- From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Andy = Newton Sent: Tuesday, March 13, 2012 6:44 PM To: urn@ietf.org Subject: [urn] draft agenda for IETF 83 posted No shocking endings or high drama, but I tried. :) http://www.ietf.org/proceedings/83/agenda/agenda-83-urnbis.txt -andy _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From andy@hxr.us Fri Mar 23 04:59:59 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 E7B2021F850B for ; Fri, 23 Mar 2012 04:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 sPULpOVXxzFd for ; Fri, 23 Mar 2012 04:59:55 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6AAD21F8505 for ; Fri, 23 Mar 2012 04:59:55 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2216876qcs.31 for ; Fri, 23 Mar 2012 04:59:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5jjGSBI96jMORpDU2vDjWfEs5OwXo7rU8Z5cqObeP7s=; b=oa0sFjPaWR55etBzoa/52XQHBLDq763eGXQDUIJ8j/YXPUnwacSRjzoAAgiUdg26SX heXSfxfGwuM14c7FqOw2JK0aJfM/NSbBPckOAQoi3UM9DfhYjRJDPxg8SQL/mJQeVlzC w4Jg5N0kox1G9xA8HHmC4R8dHBgngniP10WoniM3/7S/wSJpVEWOHW8uHZ0+Q0RvF2Gm RnOEnKcYHgPgz+akGCTsy4QnFgS1jiXFXN1Ywp0RMxDSNozxoiTbLq06wtveGu3LiENO IcWcxG17VEfgnkRoJ8O//q5v36KUPFBvoyIi6tSsoDuyBivKF1uCnuSKAos2R4b0Vr4k 53Zg== Received: by 10.224.106.66 with SMTP id w2mr15783624qao.1.1332503995241; Fri, 23 Mar 2012 04:59:55 -0700 (PDT) Received: from andytop.arin.net (core.arin.net. [192.149.252.11]) by mx.google.com with ESMTPS id dm8sm13578684qab.18.2012.03.23.04.59.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 04:59:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: Date: Fri, 23 Mar 2012 07:59:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <861C558A-B156-4D0B-A3B0-18A02BD46817@hxr.us> To: Larry Masinter X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmrMqgENy848iyOiDUUQPYl0MkVvYlOg67CZGd44VCvV0nchq802a5qSxC/on6QMXRKkJl0 Cc: "urn@ietf.org" Subject: Re: [urn] draft agenda for IETF 83 posted 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, 23 Mar 2012 12:00:00 -0000 I see no problem with tacking that on the end. -andy On Mar 23, 2012, at 4:18 AM, Larry Masinter wrote: > It looks like you have 45 minutes in your agenda but a 1-hour slot. >=20 >=20 > I wonder if I could take 10 minutes (preferably early) to present a = model for URN namespaces registries in the general sense used in, say, = http://www.w3.org/2001/tag/2011/12/evolution/Registries.html (part of = http://www.w3.org/2001/tag/2011/12/evolution/ ). >=20 >=20 > -----Original Message----- > From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of = Andy Newton > Sent: Tuesday, March 13, 2012 6:44 PM > To: urn@ietf.org > Subject: [urn] draft agenda for IETF 83 posted >=20 > No shocking endings or high drama, but I tried. :) >=20 > http://www.ietf.org/proceedings/83/agenda/agenda-83-urnbis.txt >=20 > -andy > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From godefroy@issn.org Fri Mar 23 10:30:25 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 40CDB21F85FF for ; Fri, 23 Mar 2012 10:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBzxL1ggCFtx for ; Fri, 23 Mar 2012 10:30:24 -0700 (PDT) Received: from fra5-4.hostedsecurity.org (fra5-4.hostedsecurity.org [82.98.110.174]) by ietfa.amsl.com (Postfix) with ESMTP id 36AE421F85DB for ; Fri, 23 Mar 2012 10:30:23 -0700 (PDT) Received: FROM [84.37.59.140] ([84.37.59.140]) (envelope-from ) BY fra5-4.hostedsecurity.org ([10.129.2.4]) WITH ESMTP (EmailSecurity KHhYSNibu8ws2) ID 6569849053405773865 FOR ; Fri, 23 Mar 2012 17:30:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Mar 2012 18:27:15 +0100 Message-ID: <43DF796D6D75094D82B6E0D5E3B7F553CE67E4@srvmail.issn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00 Thread-Index: Ac0HdAn2W07HjoxNQ0Gy5aK/ngddSABpGzCg References: <201203211507.QAA23963@TR-Sys.de> From: "Pierre GODEFROY" To: =?Windows-1252?Q?Alfred_H=CEnes?= , Subject: Re: [urn] A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:30:25 -0000 Alfred, Thank you very much for your very careful review of = draft-ietf-urnbis-rfc3044bis-issn-urn-00. Your remarks and proposal seem logical to me, in particular the very = first one concerning "backwards compatibility" with the previous version = of the RFC, so as to avoid any ambiguity on this very important point. I would only like to add, based on the private exchanges we had, that = your suggestion concerning section 4.5.2 : > (4) Section structure (2) > Section 4.5.2 does not seem to be logically subordinate to Section = 4.5. > I suggest to 'elevate' Section 4.5.2 to become Section 4.6. is not necessarily relevant : the issue of the "updating and management = of URLs" is indeed an "additional consideration", in the sense that, = however important it may be, it has no impact on the fundamental = "philosophy" of the mechanism described in the RFC. Kind regards, Pierre Pierre Godefroy Project Manager ISSN International Centre 45 rue de Turbigo 75003 PARIS France Tel : +33 1 44 88 22 18 -----Message d'origine----- De=A0: Alfred H=CEnes [mailto:ah@TR-Sys.de]=20 Envoy=E9=A0: mercredi 21 mars 2012 16:07 =C0=A0: Pierre GODEFROY; urn@ietf.org Objet=A0: A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00 [ speaking as an individual ] I have reviewed draft-ietf-urnbis-rfc3044bis-issn-urn-00 and would like to offer some comments (see below). A much larger bunch of editorial nits is being reported off-list to the author, to avoid too much on-list "noise", and for efficiency. (Speaking as a co-chair as well: Accordingly, I would appreciate other reviewers to send nits off-list and/or wait until the next draft version had a chance to act upon the current batch.) Overall, the draft seems to be in a very good shape already for an -00 draft version. Given the internal, informal approval by the ISSN International Centre already obtained for the technical content of the draft, I hope that enough qualified reviews will soon support progressing this document. Here are my suggestions for further improvements of the draft: (1) Emphasis on backwards compatibility (1.1) In the Abstract, I suggest to add some emphasis on the goal of backwards compatibility achieved by this document -- in line with the URNbis charter and theintended clarity for readers (and reviewers). For instance: OLD: [...]. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). [...] NEW: [...]. This document | redefines -- in a backwards compatible manner -- how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). [...] (1.2) Similarly, I suggest to add at the very end of Section 1 the following clause: | This version of the URN:ISSN registration is fully backwards | compatible with the original one, in the sense that all ISSN URNs | assigned under RFC 3044 remain valid and semantically unchanged. (2) Discussion of Fragment Usage The 2nd para of Section 3.2 says: OLD: Continuing resources, including serials, most often consist of component parts such as volumes, issues, articles. The ISSN standard does not allow augmentation of the ISSN of the resource with (URI) fragments for identification of component parts. If a fragment identifier is added to an ISSN, the resulting namespace specific string will not be an ISSN. This elaboration seems to be a bit twisted in detail. >From a syntax perspective, a URI is not a part of the Namespace Specific String (NSS) of a URN (cf. the RFC 2141bis draft). Further, embedding an existing namespace into a URN Namespace does not necessarily mean that the NSS needs to be (modulo encoding, perhaps) exactly the pre-existing (externally assigned) identifier from the originating namespace. There can be some additions, as long as these can be syntactically recognized and separated out, if needed (e.g., for resolution systems); one example is the URN Namespace for NBNs, which incorporates a disambiguating prefix into the NSS, in addition to the primary (nationally assigned) NBN string. So most likely the above quoted paragraph can be simplified. For instance: NEW: Continuing resources, including serials, most often consist of component parts such as volumes, issues, articles. The ISSN standard | does not allow the identifiaction of component parts of the serial | designated by the ISSN, and the URN:ISSN Namespace equally does not | support such augmentation -- neither by an added NSS component nor by | use of URI fragment identifiers. (3) Section structure (1) Section 4.1 contains an apparent sub-heading reading "Allocation of blocks of ISSN" I suggest to turn this line into a sub-section headline, and as such turning this and the rest of s4.1 into a new subsection 4.1.1. (4) Section structure (2) Section 4.5.2 does not seem to be logically subordinate to Section 4.5. I suggest to 'elevate' Section 4.5.2 to become Section 4.6. (5) Section 5.1 (Updated Namespace registration) It might be worth aligning the presentation of this section with the style used in the Appendix of the rfc3406bis draft for the formatting of the registration template -- uniformity should further uniform use of URN Namespace definitions. (This tuning update can be deferred until the rfc3406bis draft has finally stabilized with regard to this template.) Kind regards, Alfred. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From stpeter@stpeter.im Sat Mar 24 07:16:25 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 28C2621F8705 for ; Sat, 24 Mar 2012 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6n+6cyLFQXl for ; Sat, 24 Mar 2012 07:16:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3FE21F86F7 for ; Sat, 24 Mar 2012 07:16:17 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6727E40058 for ; Sat, 24 Mar 2012 08:29:10 -0600 (MDT) Message-ID: <4F6DD72E.1060301@stpeter.im> Date: Sat, 24 Mar 2012 15:16:14 +0100 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] 2141bis: incorrect citation X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:16:25 -0000 Section 1.2 of draft-ietf-urnbis-rfc2141bis-urn-02 cites RFC 1738 but instead should cite RFC 1737. Peter -- Peter Saint-Andre https://stpeter.im/ From leslie@thinkingcat.com Sun Mar 25 05:58:51 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 06B5221F8489 for ; Sun, 25 Mar 2012 05:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCInXESPGHGa for ; Sun, 25 Mar 2012 05:58:50 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id E570821F848A for ; Sun, 25 Mar 2012 05:58:49 -0700 (PDT) Received: from dhcp-4553.meeting.ietf.org ([::ffff:130.129.69.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 08:58:43 -0400 id 015B4039.4F6F1683.00006854 Message-ID: <4F6F1678.1020001@thinkingcat.com> Date: Sun, 25 Mar 2012 08:58:32 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> In-Reply-To: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [urn] Namespace and Community Considerations Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 12:58:51 -0000 Hi, Following up the editorial notes in the current draft (copied below for ease of reference[*] First, to the question of the bulleted lists: these were merely suggestions of dimensions in which a proposed namespace might differ from existing namespaces of similar syntactic structure. These 2 sections ("namespace" and "community" considerations) were meant to address the basic questions of "why do you need a new namespace anyway?" and "is your audience broad enough that this merits an Internet-wide identifier scheme?". Mostly what I've seen is that registrants don't understand the questions, and first drafts often don't particularly address those questions. That some of the registrations may duplicate text between their answers in each section is, I think, more a function of that than a reason to conflate the 2 into one section. Perhaps a better path would be to more clearly articulate the question/section requirements in ways that will be compelling to people who haven't been privvy to this sort of discussion. (And, I'd send text, but it's my text that is clearly the problem ;-) ). [*] > [[ Editorial Note: > It is acknowledged that, in many cases, the Namespace Considerations > and Community Considerations are closely intertwined. Further, the > bulleted lists above (from RFC 3406) seems to be more related to the > items in the registration template entitled "Identifier uniqueness > considerations", "Identifier persistence considerations", "Process of > identifier assignment", and "Process for identifier resolution" than > to the primary objectives presented in the first paragraph above > (also from RFC 3406). > In fact, Namespace registration documents seen so far duplicate in > the registration template material from the "Community > Considerations" that addresses the above bullets. > Therefore: Should this specification now allow a combined section > "Namespace and Community Considerations" that focuses on the > (non-)utility of possible alternate namespace re-use and the > *benefits* of an independent new Namespace? > ]] Leslie. On 3/12/12 4:20 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Namespace Definition Mechanisms > Author(s) : Alfred Hoenes > Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > Pages : 30 > Date : 2012-03-12 > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. To structure and > organize their usage, the URN syntax (RFC 2141bis) specifies a > hierarchy that divides the set of possible URNs into "URN Namespaces" > that can be individually defined and managed. URN Namespaces in > particular serve to map existing identifier systems into the URN > system and thereby make available generic, network-based resolution > services for the identified documents, artifacts, and other objects > (and metadata related to them). > > To achive these goals, URN Namespaces need to be specified in a > comparable manner, and their Namespace Identifiers (NIDs) need to be > registered with IANA, so that naming conflicts are avoided and > implementers of services can follow a structured approach in support > of various namespaces, guided by the registry to the related > documents and the particularities of specific namespaces, as > described in these Namespace registration documents. > > This RFC serves as a guideline for authors of URN Namespace > definition and registration documents and the process to be followed > to register a URN Namespace with IANA. It describes the essential > content of such documents and how they shall be structured to allow > readers familar with the scheme to quickly assess the properties of a > specific URN Namespace. > > This document is a companion document to the revised URN Syntax > specification, RFC 2141bis; it supersedes and replaces RFC 3406. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 25 05:59:05 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 8C86821F84AF for ; Sun, 25 Mar 2012 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYcMKYcVINZQ for ; Sun, 25 Mar 2012 05:59:04 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 892E321F84A0 for ; Sun, 25 Mar 2012 05:59:04 -0700 (PDT) Received: from dhcp-4553.meeting.ietf.org ([::ffff:130.129.69.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 08:58:51 -0400 id 015B4080.4F6F168E.00006B2D Message-ID: <4F6F1689.1070704@thinkingcat.com> Date: Sun, 25 Mar 2012 08:58:49 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> In-Reply-To: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [urn] Review period Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 12:59:05 -0000 Hi, This document questions the 2-week mailing list review period for formal namespace registrations, suggestion 4 weeks (or possibly 8). First, that process came from what was standard/accepted practice at the time of writing the first document (RFC2611). That was over a decade ago -- and maybe we all read mail a little more regularly then ;-) I sort of wonder if there isn't generally a better mechanism, overall. What gets experts' attention these days? Do we need an RSS feed? Tweets? (!). All in all, I agree that reviews don't generally happen within 2 weeks. Some of that is because the current designated expert hasn't been paying adequate attention, and should be replaced. But then, authors don't come back quickly with updates, either, so there wind up being iterations before things are actually signed off. I don't actually know that 4 or 8 weeks would capture that whole phase. What I've seen (as the designated expert that needs to be replaced): + namespace proposals that don't get published as I-D's -- Step 0: please publish this as an I-D + namespace proposals that don't follow the correct version of the RFC -- authors need guidance about current version + namespace proposals that need to be cleaned up in terms of having reasonable explanations in the Considerations sections -- offer guidance and repeat + namespace proposals that come in through *other* IETF wgs, and never get put on the urn-nid mailing list -- need AD help to get them to the URN reviewers What I have *not* seen, surprisingly (but pleasantly): + a lot of discussion about whether something really should be a URN namespace. Hurrah. Leslie. On 3/12/12 4:20 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Namespace Definition Mechanisms > Author(s) : Alfred Hoenes > Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > Pages : 30 > Date : 2012-03-12 > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. To structure and > organize their usage, the URN syntax (RFC 2141bis) specifies a > hierarchy that divides the set of possible URNs into "URN Namespaces" > that can be individually defined and managed. URN Namespaces in > particular serve to map existing identifier systems into the URN > system and thereby make available generic, network-based resolution > services for the identified documents, artifacts, and other objects > (and metadata related to them). > > To achive these goals, URN Namespaces need to be specified in a > comparable manner, and their Namespace Identifiers (NIDs) need to be > registered with IANA, so that naming conflicts are avoided and > implementers of services can follow a structured approach in support > of various namespaces, guided by the registry to the related > documents and the particularities of specific namespaces, as > described in these Namespace registration documents. > > This RFC serves as a guideline for authors of URN Namespace > definition and registration documents and the process to be followed > to register a URN Namespace with IANA. It describes the essential > content of such documents and how they shall be structured to allow > readers familar with the scheme to quickly assess the properties of a > specific URN Namespace. > > This document is a companion document to the revised URN Syntax > specification, RFC 2141bis; it supersedes and replaces RFC 3406. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 25 05:59:28 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 8F0CA21F84A0 for ; Sun, 25 Mar 2012 05:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UsGNpyR10c4 for ; Sun, 25 Mar 2012 05:59:27 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id A45EB21F8483 for ; Sun, 25 Mar 2012 05:59:25 -0700 (PDT) Received: from dhcp-4553.meeting.ietf.org ([::ffff:130.129.69.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 08:59:04 -0400 id 015B40D8.4F6F1698.00006F0A Message-ID: <4F6F1695.9090606@thinkingcat.com> Date: Sun, 25 Mar 2012 08:59:01 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <201203122052.VAA22918@TR-Sys.de> In-Reply-To: <201203122052.VAA22918@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd) 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, 25 Mar 2012 12:59:28 -0000 Hi, Is this point in the document: > [[ NOTE: It would be preferable to restore the generic, most > universally supported (HTML) form of the registry be identified by an > implementation-neutral URL, as previously supported by IANA: > . Yet, currently > this URI and similar forms all resolve to an XML version. > The content there should link to alternate forms (.xml, .txt), and > those alternate versions should indicate the *other* versions; i.e., > where the .txt version (currently only available at ftp.IANA.ORG) > also says, "This registry is also available in XML and plain text > formats.", it should better say: "This registry is also available in > HTML and XML formats." Similarly, the XML form should point to the > HTML and plain text forms. ]] actually a question for the URN document, or rather something for the IESG/IAB to explain or take up with IANA? I.e., it seems to me that this is a broader question of references to IANA registries, and not just *this* reference to *an* IANA registry? Leslie. On 3/12/12 4:52 PM, Alfred � wrote: > URNbis colleagues, > [ speaking again as the document editor ] > > I have just (in time) completed and uploaded an update to the > RFC 3406bis draft, one of our basic work items. > > As usual, all related information, starting with the HTML-ized > version of the draft, and including diffs to the previous version > are available at: > > > Please review the draft (and the changes) and focus your comments > on the remaining issues. For your convenience, the change and > issue summaries contained in the draft are attached inline below, > after the forwarded draft announcement. > > > Unfortunately, list discussion has been interesting in the past, > but largely not very focussed on the draft text. > > This has been summed up by Peter Saint-Andre his message > sent on "Wed, 11 Jan 2012 15:52:10 -0700" and archived at > , > which concluded with the question: > >> In any case, what is the practical output of this discussion >> in terms of specification text? > > I have to admit: not very much. :-( > > So please help the editor by giving focussed review comments and > proposed alternative text or text deltas for where you think > it is needed. > > > Kind regards > Alfred. > > > > ----- Forwarded message from internet-drafts@ietf.org ----- > >> From: internet-drafts@ietf.org >> To: ah@TR-Sys.de >> Message-Id:<20120312202035.21803.80702.idtracker@ietfa.amsl.com> >> Date: Mon, 12 Mar 2012 13:20:35 -0700 >> Subject: New Version Notification for >> draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > A new version of I-D, draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > has been successfully submitted by Alfred Hoenes and posted to the > IETF repository. > > Filename: draft-ietf-urnbis-rfc3406bis-urn-ns-reg > Revision: 02 > Title: Uniform Resource Name (URN) Namespace Definition Mechanisms > Creation date: 2012-03-12 > WG ID: urnbis > Number of pages: 30 > > Abstract: > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. To structure and > organize their usage, the URN syntax (RFC 2141bis) specifies a > hierarchy that divides the set of possible URNs into "URN Namespaces" > that can be individually defined and managed. URN Namespaces in > particular serve to map existing identifier systems into the URN > system and thereby make available generic, network-based resolution > services for the identified documents, artifacts, and other objects > (and metadata related to them). > > To achive these goals, URN Namespaces need to be specified in a > comparable manner, and their Namespace Identifiers (NIDs) need to be > registered with IANA, so that naming conflicts are avoided and > implementers of services can follow a structured approach in support > of various namespaces, guided by the registry to the related > documents and the particularities of specific namespaces, as > described in these Namespace registration documents. > > This RFC serves as a guideline for authors of URN Namespace > definition and registration documents and the process to be followed > to register a URN Namespace with IANA. It describes the essential > content of such documents and how they shall be structured to allow > readers familar with the scheme to quickly assess the properties of a > specific URN Namespace. > > This document is a companion document to the revised URN Syntax > specification, RFC 2141bis; it supersedes and replaces RFC 3406. > > > The IETF Secretariat > > ----- End of forwarded message from internet-drafts@ietf.org ----- > > > > -------- begin of excerpt from draft -------- > > C.4. Changes from URNbis WG I-D -01 to -02 > > General text edits based on evaluation of meeting and on-list > comments. > > Updated and tightened the organizatorial requirements for Formal > Namespace requests. > > Restored additional IANA Considerations -- due to observed defects. > > Reserved NID strings "example.*" for documentation (as suggested by > Larry Masinter, Peter Saint-Andre, and Julian Reschke). > > Added text on possible "higher level" methods to establish lexical > equivalence of URNs, with the caveats that such things are rather > unlikely to get traction in general-purpose client software. > > Removed historical Appendix B.1 (Example Template). > > Various editorial enhancements and fixes. > > Updated and expanded "Issues" Appendix (below) in preparation of > usage of the IETF Issue Tracker. > > > Appendix D. Issues in this Draft > > [ Appendix to be replaced by use of IETF Tools issue tracker. ] > > For more details on the issues below, please also see the Editorial > Notes interspersed in the body of this draft. > > Discuss consequences of RFC 2141bis (once consensus is achieved); if > proposal for fragment part is adopted, details need to be described > per Namespace that wants to adopt these possibilities, and maybe the > registration template needs a new clause where this will be specified > -- or the information has to be assigned to existing clauses. > > Do registration documents need more guidance and be caused to be more > precise in their elaboration on the applicability of Services? Since > RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a > URNbis work item), we might need a registry for URN Services > (initially populated from RFC 2483) that can be referred to in > Namespace registration documents, thus avoiding normative > dependencies on a future RFC 2483bis. > > Do we actually need Experimental Namespaces? > [Regarded as CLOSED affirmatively at IETF 80.] > There are concerns regarding usage of "X-" NIDs, which is reported to > having proven impractical in practice. This draft version contains > tentative text to address these concerns; "X-" is now demoted to > "SHOULD" level. > > The syntax of the NID strings for the various NID types is given in > an informal manner (as has been done in RFC 3406); is it worth the > effort to introduce ABNF for this purpose? > [The request for ABNF has been voiced only once; the document Editor > regards this issue as CLOSED.] > > Increase review/timeout periods for urn-nid list and IANA experts > from 2 to 4 (or more) weeks? This draft version tentatively > specifies 4 weeks. > Juha Hakala has argued that the assessment of the responsible > organizations needed to assure their ability to properly operate the > Namespace could never be performed within the present 2 weeks time > span; 8 weeks might be an even better choice for the future upper > limit for the review period. It has been pointed out that even 8 > weeks are miniscule with regard to the expected lifetime of the to- > be-registered Namespace and hence should not matter. In practice, > the subsequent IESG evaluation of URN Namespace registration > documents has typically needed much longer time. > > Clarification of the desired content of the "Namespace > Considerations" and "Community Considerations" sections in > registration documents. Shall we admit a combined section for both > topics? (so far supported by 2 postings) Cf. the NOTEs in Sections > 4.4.1 and 4.4.2 for more details. > [No feedback on the list since -01, so the draft text seems to have > silent consensus and the issue is regarded as CLOSED.] > > Shall other strings beyond "urn" also be 'reserved' in the NID > registry? (e.g. "uri", "url", "urc", ...) There have been voices in > favor of leaving the decision of what is acceptable and reasonable in > practice to the common sense of prospective registrants and the > designated IANA experts. This draft version reserves NID strings > matching the RE "^example.*" for documentation. > > Appendix A: Once RFC 2483 gets updated and an IANA registry for URN > resolution services gets established, the "Process for identifier > resolution" clause in the registration template should call out for > enumerating the registered services that are applicable for the newly > defined URN Namespace. > How far can we go in this respect without an update to RFC 2483 at > hands? > > Do we really still need Appendix B.1 ? (There are lots of real-life > examples now!) > [ Old B.1 removed, old B.2 became Appendix B; ==> CLOSED ] > > -------- end of excerpt from draft -------- > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 25 06:00: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 8B22121F8483 for ; Sun, 25 Mar 2012 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Se0RxWZ8tZ for ; Sun, 25 Mar 2012 06:00:36 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3221F8480 for ; Sun, 25 Mar 2012 06:00:36 -0700 (PDT) Received: from dhcp-4553.meeting.ietf.org ([::ffff:130.129.69.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 09:00:20 -0400 id 015B407B.4F6F16E6.00007D0F Message-ID: <4F6F16E0.70703@thinkingcat.com> Date: Sun, 25 Mar 2012 09:00:16 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> In-Reply-To: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:00:37 -0000 Hi, I am having troubles reconciling this use of fragments with RFC3986, the URI syntax document. My understanding of RFC3986 suggests that fragments are strictly and uniquely tied to media, and thus would be applied to the results of a URN resolution, irrespective of namespace. So, if you have #, you resolve and apply in whatever way makes sense for the media type of what you got back. The issue with doing that with URNs is: they are designed to be flexible enough to support multiple types of response -- the URN does not designate a type. For example, you might get a PDF back instead of HTML, and then your HTML # will be pointless. Even if you say (as the document currently does) that fragments are allowed only on a per-namespace basis, I am concerned that the resulting URN namespaces would have to be severely limited in terms of URN functionality: you are essentially saying that those namespaces must be architected such that they only ever return single media type responses, or responses for which the fragments will make sense across all supported types. That is very constraining on the namespace, and the use of URNs, IMO. For myself, this doesn't make the case that the URN syntax can be updated to allow the use of fragment identifiers. And, if the consensus winds up being that this does make the case to allow that, I would further argue that the text describing the per-namespace use considerations would need 1/ a very thorough review by URI experts to make sure it actually would hold water, 2/ to be clear about the constraints it puts on the overall URN namespace in question 3/ to be in a separate document all on its own, because it is severely distracting from a document that is meant to be the description of the syntax of URNs in general. Leslie. On 3/11/12 9:05 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Syntax > Author(s) : Alfred Hoenes > Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt > Pages : 32 > Date : 2012-03-11 > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. This document serves as > the foundation of the 'urn' URI Scheme according to RFC 3986 and sets > forward the canonical syntax for URNs, which subdivides URNs into > "namespaces". A discussion of both existing legacy and new > namespaces and requirements for URN presentation and transmission are > presented. Finally, there is a discussion of URN equivalence and how > to determine it. This document supersedes RFC 2141. > > 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. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 25 06:00:40 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 14FC921F84C5 for ; Sun, 25 Mar 2012 06:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AftGpTY2GDui for ; Sun, 25 Mar 2012 06:00:39 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3ED21F849A for ; Sun, 25 Mar 2012 06:00:39 -0700 (PDT) Received: from dhcp-4553.meeting.ietf.org ([::ffff:130.129.69.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 09:00:29 -0400 id 015B4081.4F6F16EF.00007EA9 Message-ID: <4F6F16E5.8060909@thinkingcat.com> Date: Sun, 25 Mar 2012 09:00:21 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> In-Reply-To: <20120312202035.21803.90004.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [urn] Authorship Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:00:40 -0000 Hi, This document says: > IETF URNbis WG A. Hoenes > Internet-Draft TR-Sys > Obsoletes: 3406 (if approved) March 12, 2012 > Intended status: BCP > Expires: September 13, 2012 and > 7. Acknowledgements > > This document is heavily based on RFC 3406, the authors of which are > cordially acknowledged. > I don't think this is appropriate. The bulk of the work was done by the original authors/editors/WG, this is not a complete rewrite. I believe the appropriate thing is to list the original authors (unless they don't want to be!), and add the new author. This is also true for the syntax document, but I'm mentioning it here because I'm clearly more implicated, as lead author on both previous iterations of this RFC. Leslie. On 3/12/12 4:20 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Namespace Definition Mechanisms > Author(s) : Alfred Hoenes > Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > Pages : 30 > Date : 2012-03-12 > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. To structure and > organize their usage, the URN syntax (RFC 2141bis) specifies a > hierarchy that divides the set of possible URNs into "URN Namespaces" > that can be individually defined and managed. URN Namespaces in > particular serve to map existing identifier systems into the URN > system and thereby make available generic, network-based resolution > services for the identified documents, artifacts, and other objects > (and metadata related to them). > > To achive these goals, URN Namespaces need to be specified in a > comparable manner, and their Namespace Identifiers (NIDs) need to be > registered with IANA, so that naming conflicts are avoided and > implementers of services can follow a structured approach in support > of various namespaces, guided by the registry to the related > documents and the particularities of specific namespaces, as > described in these Namespace registration documents. > > This RFC serves as a guideline for authors of URN Namespace > definition and registration documents and the process to be followed > to register a URN Namespace with IANA. It describes the essential > content of such documents and how they shall be structured to allow > readers familar with the scheme to quickly assess the properties of a > specific URN Namespace. > > This document is a companion document to the revised URN Syntax > specification, RFC 2141bis; it supersedes and replaces RFC 3406. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From marc.blanchet@viagenie.ca Sun Mar 25 06:07:34 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 E924E21F84B5 for ; Sun, 25 Mar 2012 06:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QowhFkAURvfO for ; Sun, 25 Mar 2012 06:07:33 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D2E8521F84AF for ; Sun, 25 Mar 2012 06:07:32 -0700 (PDT) Received: from dhcp-51c6.meeting.ietf.org (dhcp-51c6.meeting.ietf.org [130.129.81.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B6AB2400DF; Sun, 25 Mar 2012 09:07:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F28597F-BA4A-4D4A-B369-B37F8CC07505" From: Marc Blanchet In-Reply-To: <4F6F1695.9090606@thinkingcat.com> Date: Sun, 25 Mar 2012 15:07:30 +0200 Message-Id: <61D1B733-0575-4DDF-B2CB-CCEDC25BAC1F@viagenie.ca> References: <201203122052.VAA22918@TR-Sys.de> <4F6F1695.9090606@thinkingcat.com> To: Leslie Daigle X-Mailer: Apple Mail (2.1257) Cc: urn@ietf.org Subject: Re: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd) 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, 25 Mar 2012 13:07:35 -0000 --Apple-Mail=_2F28597F-BA4A-4D4A-B369-B37F8CC07505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-25 =C3=A0 14:59, Leslie Daigle a =C3=A9crit : >=20 > Hi, >=20 > Is this point in the document: >=20 >> [[ NOTE: It would be preferable to restore the generic, most >> universally supported (HTML) form of the registry be identified by = an >> implementation-neutral URL, as previously supported by IANA: >> . Yet, currently >> this URI and similar forms all resolve to an XML version. >> The content there should link to alternate forms (.xml, .txt), and >> those alternate versions should indicate the *other* versions; = i.e., >> where the .txt version (currently only available at ftp.IANA.ORG) >> also says, "This registry is also available in XML and plain text >> formats.", it should better say: "This registry is also available = in >> HTML and XML formats." Similarly, the XML form should point to the >> HTML and plain text forms. ]] >=20 >=20 > actually a question for the URN document, or rather something for the = IESG/IAB to explain or take up with IANA? I.e., it seems to me that = this is a broader question of references to IANA registries, and not = just *this* reference to *an* IANA registry? - actually, the note above (the extract from the document) is wrong. + each XML registry has in the note: "This registry is also available = in plain text." and the .txt is available by http. + the html version is redundant. the xml version has xsl statement for = browsers to render it in html on the fly. so no need to have a separate = html page. Marc. >=20 > Leslie. >=20 > On 3/12/12 4:52 PM, Alfred =EF=BF=BD wrote: >> URNbis colleagues, >> [ speaking again as the document editor ] >>=20 >> I have just (in time) completed and uploaded an update to the >> RFC 3406bis draft, one of our basic work items. >>=20 >> As usual, all related information, starting with the HTML-ized >> version of the draft, and including diffs to the previous version >> are available at: >> = >>=20 >> Please review the draft (and the changes) and focus your comments >> on the remaining issues. For your convenience, the change and >> issue summaries contained in the draft are attached inline below, >> after the forwarded draft announcement. >>=20 >>=20 >> Unfortunately, list discussion has been interesting in the past, >> but largely not very focussed on the draft text. >>=20 >> This has been summed up by Peter Saint-Andre his message >> sent on "Wed, 11 Jan 2012 15:52:10 -0700" and archived at >> , >> which concluded with the question: >>=20 >>> In any case, what is the practical output of this discussion >>> in terms of specification text? >>=20 >> I have to admit: not very much. :-( >>=20 >> So please help the editor by giving focussed review comments and >> proposed alternative text or text deltas for where you think >> it is needed. >>=20 >>=20 >> Kind regards >> Alfred. >>=20 >>=20 >>=20 >> ----- Forwarded message from internet-drafts@ietf.org ----- >>=20 >>> From: internet-drafts@ietf.org >>> To: ah@TR-Sys.de >>> Message-Id:<20120312202035.21803.80702.idtracker@ietfa.amsl.com> >>> Date: Mon, 12 Mar 2012 13:20:35 -0700 >>> Subject: New Version Notification for >>> draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt >>=20 >> A new version of I-D, draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt >> has been successfully submitted by Alfred Hoenes and posted to the >> IETF repository. >>=20 >> Filename: draft-ietf-urnbis-rfc3406bis-urn-ns-reg >> Revision: 02 >> Title: Uniform Resource Name (URN) Namespace Definition = Mechanisms >> Creation date: 2012-03-12 >> WG ID: urnbis >> Number of pages: 30 >>=20 >> Abstract: >>=20 >> Uniform Resource Names (URNs) are intended to serve as persistent, >> location-independent, resource identifiers. To structure and >> organize their usage, the URN syntax (RFC 2141bis) specifies a >> hierarchy that divides the set of possible URNs into "URN = Namespaces" >> that can be individually defined and managed. URN Namespaces in >> particular serve to map existing identifier systems into the URN >> system and thereby make available generic, network-based = resolution >> services for the identified documents, artifacts, and other = objects >> (and metadata related to them). >>=20 >> To achive these goals, URN Namespaces need to be specified in a >> comparable manner, and their Namespace Identifiers (NIDs) need to = be >> registered with IANA, so that naming conflicts are avoided and >> implementers of services can follow a structured approach in = support >> of various namespaces, guided by the registry to the related >> documents and the particularities of specific namespaces, as >> described in these Namespace registration documents. >>=20 >> This RFC serves as a guideline for authors of URN Namespace >> definition and registration documents and the process to be = followed >> to register a URN Namespace with IANA. It describes the essential >> content of such documents and how they shall be structured to = allow >> readers familar with the scheme to quickly assess the properties = of a >> specific URN Namespace. >>=20 >> This document is a companion document to the revised URN Syntax >> specification, RFC 2141bis; it supersedes and replaces RFC 3406. >>=20 >>=20 >> The IETF Secretariat >>=20 >> ----- End of forwarded message from internet-drafts@ietf.org ----- >>=20 >>=20 >>=20 >> -------- begin of excerpt from draft -------- >>=20 >> C.4. Changes from URNbis WG I-D -01 to -02 >>=20 >> General text edits based on evaluation of meeting and on-list >> comments. >>=20 >> Updated and tightened the organizatorial requirements for Formal >> Namespace requests. >>=20 >> Restored additional IANA Considerations -- due to observed = defects. >>=20 >> Reserved NID strings "example.*" for documentation (as suggested = by >> Larry Masinter, Peter Saint-Andre, and Julian Reschke). >>=20 >> Added text on possible "higher level" methods to establish lexical >> equivalence of URNs, with the caveats that such things are rather >> unlikely to get traction in general-purpose client software. >>=20 >> Removed historical Appendix B.1 (Example Template). >>=20 >> Various editorial enhancements and fixes. >>=20 >> Updated and expanded "Issues" Appendix (below) in preparation of >> usage of the IETF Issue Tracker. >>=20 >>=20 >> Appendix D. Issues in this Draft >>=20 >> [ Appendix to be replaced by use of IETF Tools issue tracker. ] >>=20 >> For more details on the issues below, please also see the = Editorial >> Notes interspersed in the body of this draft. >>=20 >> Discuss consequences of RFC 2141bis (once consensus is achieved); = if >> proposal for fragment part is adopted, details need to be = described >> per Namespace that wants to adopt these possibilities, and maybe = the >> registration template needs a new clause where this will be = specified >> -- or the information has to be assigned to existing clauses. >>=20 >> Do registration documents need more guidance and be caused to be = more >> precise in their elaboration on the applicability of Services? = Since >> RFC 2483 is considered outdated, but RFC 2483bis not yet alife = (nor a >> URNbis work item), we might need a registry for URN Services >> (initially populated from RFC 2483) that can be referred to in >> Namespace registration documents, thus avoiding normative >> dependencies on a future RFC 2483bis. >>=20 >> Do we actually need Experimental Namespaces? >> [Regarded as CLOSED affirmatively at IETF 80.] >> There are concerns regarding usage of "X-" NIDs, which is reported = to >> having proven impractical in practice. This draft version = contains >> tentative text to address these concerns; "X-" is now demoted to >> "SHOULD" level. >>=20 >> The syntax of the NID strings for the various NID types is given = in >> an informal manner (as has been done in RFC 3406); is it worth the >> effort to introduce ABNF for this purpose? >> [The request for ABNF has been voiced only once; the document = Editor >> regards this issue as CLOSED.] >>=20 >> Increase review/timeout periods for urn-nid list and IANA experts >> from 2 to 4 (or more) weeks? This draft version tentatively >> specifies 4 weeks. >> Juha Hakala has argued that the assessment of the responsible >> organizations needed to assure their ability to properly operate = the >> Namespace could never be performed within the present 2 weeks time >> span; 8 weeks might be an even better choice for the future upper >> limit for the review period. It has been pointed out that even 8 >> weeks are miniscule with regard to the expected lifetime of the = to- >> be-registered Namespace and hence should not matter. In practice, >> the subsequent IESG evaluation of URN Namespace registration >> documents has typically needed much longer time. >>=20 >> Clarification of the desired content of the "Namespace >> Considerations" and "Community Considerations" sections in >> registration documents. Shall we admit a combined section for = both >> topics? (so far supported by 2 postings) Cf. the NOTEs in Sections >> 4.4.1 and 4.4.2 for more details. >> [No feedback on the list since -01, so the draft text seems to = have >> silent consensus and the issue is regarded as CLOSED.] >>=20 >> Shall other strings beyond "urn" also be 'reserved' in the NID >> registry? (e.g. "uri", "url", "urc", ...) There have been voices = in >> favor of leaving the decision of what is acceptable and reasonable = in >> practice to the common sense of prospective registrants and the >> designated IANA experts. This draft version reserves NID strings >> matching the RE "^example.*" for documentation. >>=20 >> Appendix A: Once RFC 2483 gets updated and an IANA registry for = URN >> resolution services gets established, the "Process for identifier >> resolution" clause in the registration template should call out = for >> enumerating the registered services that are applicable for the = newly >> defined URN Namespace. >> How far can we go in this respect without an update to RFC 2483 at >> hands? >>=20 >> Do we really still need Appendix B.1 ? (There are lots of = real-life >> examples now!) >> [ Old B.1 removed, old B.2 became Appendix B; =3D=3D> CLOSED ] >>=20 >> -------- end of excerpt from draft -------- >>=20 >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >=20 > --=20 >=20 > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --Apple-Mail=_2F28597F-BA4A-4D4A-B369-B37F8CC07505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi,

Is this point in the = document:

 [[ NOTE: It would be = preferable to restore the generic, most
  universally supported (HTML) form of the = registry be identified by an
=   implementation-neutral URL, as previously supported by = IANA:
  <http://www.iana.or= g/assignments/urn-namespaces>.  Yet, = currently
  this = URI and similar forms all resolve to an XML = version.
  The = content there should link to alternate forms (.xml, .txt), = and
  those = alternate versions should indicate the *other* versions; = i.e.,
  where the = .txt version (currently only available at ftp.IANA.ORG)
  also says, "This registry is also available = in XML and plain text
=   formats.", it should better say: "This registry is also = available in
  HTML = and XML formats."  Similarly, the XML form should point to = the
  HTML and = plain text forms. ]]


actually a question for the = URN document, or rather something for the IESG/IAB to explain or take up = with IANA?  I.e., it seems to me that this is a broader question of = references to IANA registries, and not just *this* reference to *an* = IANA registry?

- actually, the = note above (the extract from the document) is wrong.
 + =  each XML registry has in the note: "This registry is = also available in plain text."  and the = .txt is available by http.
 + the html version is redundant. the xml version has xsl = statement for browsers to render it in html on the fly. so no need to = have a separate html page.


Leslie.

On 3/12/12 4:52 PM, Alfred =EF=BF=BD= wrote:
URNbis = colleagues,
[ speaking again = as the document editor ]

I have just (in = time) completed and uploaded an update to = the
RFC 3406bis draft, one of = our basic work items.

As usual, all = related information, starting with the = HTML-ized
version of the = draft, and including diffs to the previous = version
are available = at:
<http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02= >

Please review = the draft (and the changes) and focus your = comments
on the remaining = issues.  For your convenience, the change = and
issue summaries contained = in the draft are attached inline below,
after the forwarded draft = announcement.


Unfortunately, = list discussion has been interesting in the = past,
but largely not very = focussed on the draft text.

This has been = summed up by Peter Saint-Andre his message
sent on "Wed, 11 Jan 2012 15:52:10 -0700" and archived = at
<ht= tp://www.ietf.org/mail-archive/web/urn/current/msg01672.html>,
<= /blockquote>
which concluded with the = question:

In any case, what is the practical output of this = discussion
in terms of specification = text?

I have to = admit: not very much.    :-(

So please help = the editor by giving focussed review comments = and
proposed alternative text = or text deltas for where you think
it is needed.


Kind = regards
=   Alfred.



----- Forwarded = message from internet-drafts@ietf.org = -----

From: internet-drafts@ietf.org
<= /blockquote>
To: ah@TR-Sys.de
Message-Id:<201203= 12202035.21803.80702.idtracker@ietfa.amsl.com>
Date: Mon, = 12 Mar 2012 13:20:35 -0700
Subject: New Version = Notification for
=    draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt

A new version of I-D, = draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt
has been successfully submitted by Alfred Hoenes and = posted to the
IETF = repository.

Filename: =        draft-ietf-urnbis-rfc3406bis-urn= -ns-reg
Revision: =        02
Title: =           Uniform = Resource Name (URN) Namespace Definition = Mechanisms
Creation date: =   2012-03-12
WG ID: =           urnbis
Number of pages: = 30

Abstract:

=    Uniform Resource Names (URNs) are intended to serve as = persistent,
=    location-independent, resource identifiers.  To = structure and
=    organize their usage, the URN syntax (RFC 2141bis) = specifies a
=    hierarchy that divides the set of possible URNs into = "URN Namespaces"
=    that can be individually defined and managed. =  URN Namespaces in
=    particular serve to map existing identifier systems = into the URN
=    system and thereby make available generic, = network-based resolution
=    services for the identified documents, artifacts, and = other objects
=    (and metadata related to = them).

=    To achive these goals, URN Namespaces need to be = specified in a
=    comparable manner, and their Namespace Identifiers = (NIDs) need to be
=    registered with IANA, so that naming conflicts are = avoided and
=    implementers of services can follow a structured = approach in support
=    of various namespaces, guided by the registry to the = related
=    documents and the particularities of specific = namespaces, as
=    described in these Namespace registration = documents.

=    This RFC serves as a guideline for authors of URN = Namespace
=    definition and registration documents and the process = to be followed
=    to register a URN Namespace with IANA.  It = describes the essential
=    content of such documents and how they shall be = structured to allow
=    readers familar with the scheme to quickly assess the = properties of a
=    specific URN Namespace.

=    This document is a companion document to the revised = URN Syntax
=    specification, RFC 2141bis; it supersedes and replaces = RFC 3406.


The IETF = Secretariat

----- End of = forwarded message from internet-drafts@ietf.org = -----



-------- =  begin of excerpt from draft --------

C.4. =  Changes from URNbis WG I-D -01 to -02

=    General text edits based on evaluation of meeting and = on-list
=    comments.

=    Updated and tightened the organizatorial requirements = for Formal
=    Namespace requests.

=    Restored additional IANA Considerations -- due to = observed defects.

=    Reserved NID strings "example.*" for documentation (as = suggested by
=    Larry Masinter, Peter Saint-Andre, and Julian = Reschke).

=    Added text on possible "higher level" methods to = establish lexical
=    equivalence of URNs, with the caveats that such things = are rather
=    unlikely to get traction in general-purpose client = software.

=    Removed historical Appendix B.1 (Example = Template).

=    Various editorial enhancements and = fixes.

=    Updated and expanded "Issues" Appendix (below) in = preparation of
=    usage of the IETF Issue = Tracker.


Appendix D. =  Issues in this Draft

=    [ Appendix to be replaced by use of IETF Tools issue = tracker. ]

=    For more details on the issues below, please also see = the Editorial
=    Notes interspersed in the body of this = draft.

=    Discuss consequences of RFC 2141bis (once consensus is = achieved); if
=    proposal for fragment part is adopted, details need to = be described
=    per Namespace that wants to adopt these possibilities, = and maybe the
=    registration template needs a new clause where this = will be specified
=    -- or the information has to be assigned to existing = clauses.

=    Do registration documents need more guidance and be = caused to be more
=    precise in their elaboration on the applicability of = Services?  Since
=    RFC 2483 is considered outdated, but RFC 2483bis not = yet alife (nor a
=    URNbis work item), we might need a registry for URN = Services
=    (initially populated from RFC 2483) that can be = referred to in
=    Namespace registration documents, thus avoiding = normative
=    dependencies on a future RFC = 2483bis.

=    Do we actually need Experimental = Namespaces?
=    [Regarded as CLOSED affirmatively at IETF = 80.]
   There = are concerns regarding usage of "X-" NIDs, which is reported = to
   having = proven impractical in practice.  This draft version = contains
=    tentative text to address these concerns; "X-" is now = demoted to
=    "SHOULD" level.

=    The syntax of the NID strings for the various NID = types is given in
=    an informal manner (as has been done in RFC 3406); is = it worth the
=    effort to introduce ABNF for this = purpose?
=    [The request for ABNF has been voiced only once; the = document Editor
=    regards this issue as = CLOSED.]

=    Increase review/timeout periods for urn-nid list and = IANA experts
=    from 2 to 4 (or more) weeks?  This draft version = tentatively
=    specifies 4 weeks.
   Juha Hakala has argued that the = assessment of the responsible
=    organizations needed to assure their ability to = properly operate the
=    Namespace could never be performed within the present = 2 weeks time
=    span; 8 weeks might be an even better choice for the = future upper
=    limit for the review period.  It has been pointed = out that even 8
=    weeks are miniscule with regard to the expected = lifetime of the to-
=    be-registered Namespace and hence should not matter. =  In practice,
=    the subsequent IESG evaluation of URN Namespace = registration
=    documents has typically needed much longer = time.

=    Clarification of the desired content of the = "Namespace
=    Considerations" and "Community Considerations" = sections in
=    registration documents.  Shall we admit a = combined section for both
=    topics? (so far supported by 2 postings) Cf. the NOTEs = in Sections
=    4.4.1 and 4.4.2 for more = details.
=    [No feedback on the list since -01, so the draft text = seems to have
=    silent consensus and the issue is regarded as = CLOSED.]

=    Shall other strings beyond "urn" also be 'reserved' in = the NID
=    registry? (e.g. "uri", "url", "urc", ...)  There = have been voices in
=    favor of leaving the decision of what is acceptable = and reasonable in
=    practice to the common sense of prospective = registrants and the
=    designated IANA experts.  This draft version = reserves NID strings
=    matching the RE "^example.*" for = documentation.

=    Appendix A: Once RFC 2483 gets updated and an IANA = registry for URN
=    resolution services gets established, the "Process for = identifier
=    resolution" clause in the registration template should = call out for
=    enumerating the registered services that are = applicable for the newly
=    defined URN Namespace.
   How far can we go in this respect = without an update to RFC 2483 at
   hands?

=    Do we really still need Appendix B.1 ?  (There = are lots of real-life
=    examples now!)
   [ Old B.1 removed, old B.2 became = Appendix B; =3D=3D>  CLOSED ]

-------- =  end of excerpt from draft =  --------

_______________________________________________
urn mailing = list
urn@ietf.org
https://www.ietf.org/ma= ilman/listinfo/urn

-- =

------------------------------------------------------------------= -
"Reality:
    Yours to discover."
=             &n= bsp;           &nbs= p;      -- ThinkingCat
Leslie = Daigle
leslie@thinkingcat.com
-----= --------------------------------------------------------------
________= _______________________________________
urn mailing = list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn

= --Apple-Mail=_2F28597F-BA4A-4D4A-B369-B37F8CC07505-- From A.Hoenes@TR-Sys.de Sun Mar 25 12:52:25 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 1BD9C21E800C for ; Sun, 25 Mar 2012 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.609 X-Spam-Level: X-Spam-Status: No, score=-98.609 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 elnrwZRMNMUu for ; Sun, 25 Mar 2012 12:52:23 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 04A5021E8013 for ; Sun, 25 Mar 2012 12:52:22 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA257275074; Sun, 25 Mar 2012 21:51:14 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA20256; Sun, 25 Mar 2012 21:51:12 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203251951.VAA20256@TR-Sys.de> To: stpeter@stpeter.im Date: Sun, 25 Mar 2012 21:51:11 +0200 (MESZ) In-Reply-To: <4F6DD72E.1060301@stpeter.im> from Peter Saint-Andre at Mar "24, " 2012 "03:16:14" 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] 2141bis: incorrect citation 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, 25 Mar 2012 19:52:25 -0000 > Section 1.2 of draft-ietf-urnbis-rfc2141bis-urn-02 cites RFC 1738 but > instead should cite RFC 1737. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ Peter, thanks for the hint. Oops -- apparently I have missed to fix an already known, iterated typo. Will be corrected in the next draft version. Alfred. From A.Hoenes@TR-Sys.de Sun Mar 25 13:16:20 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 7A3DD21E801A for ; Sun, 25 Mar 2012 13:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.613 X-Spam-Level: X-Spam-Status: No, score=-98.613 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 gxPcoYsgD6rc for ; Sun, 25 Mar 2012 13:16:19 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id AE4B421E8015 for ; Sun, 25 Mar 2012 13:16:18 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA257586510; Sun, 25 Mar 2012 22:15:10 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA20420; Sun, 25 Mar 2012 22:15:08 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203252015.WAA20420@TR-Sys.de> To: leslie@thinkingcat.com Date: Sun, 25 Mar 2012 22:15:07 +0200 (MESZ) In-Reply-To: <4F6F1678.1020001@thinkingcat.com> from Leslie Daigle at Mar "25, " 2012 "08:58:32" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Namespace and Community Considerations ... (in rfc3406bis -02 draft) 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, 25 Mar 2012 20:16:20 -0000 Leslie, thanks for your review and comments. I'll answer the various threads separately, slightly shortening the Subject for convenience. > Hi, > > Following up the editorial notes in the current draft (copied below for > ease of reference[*] For clarity to other readers on the list: That's in Section 4.4.2 of the draft, and another, closely related Editorial Note is present in Section 4.4.1 of the draft. > > First, to the question of the bulleted lists: these were merely > suggestions of dimensions in which a proposed namespace might differ > from existing namespaces of similar syntactic structure. > > These 2 sections ("namespace" and "community" considerations) were meant > to address the basic questions of "why do you need a new namespace > anyway?" and "is your audience broad enough that this merits an > Internet-wide identifier scheme?". Yes. And every now and then, it's properties of the interested community that impact the need for a new namespace; so registration documents have been seen to need to explain the community aspects first in order to discuss the first question. > > Mostly what I've seen is that registrants don't understand the > questions, and first drafts often don't particularly address those > questions. [...] That matches my observations. > [...] That some of the registrations may duplicate text between > their answers in each section is, I think, more a function of that > than a reason to conflate the 2 into one section. Maybe the situation is different for already well-established (e.g. standards-based) "foreign" namespaces seeking integration into the URN framework vs. for newly conceived conceptional namespaces that are looking for the "proper" way to address the needs of their community. > > Perhaps a better path would be to more clearly articulate the > question/section requirements in ways that will be compelling to > people who haven't been privvy to this sort of discussion. (And, > I'd send text, but it's my text that is clearly the problem ;-) ). Well, we'd appreciate if years of experience might allow you to anyway now suggest alternate text. :-) But I'm happy that you seem to agree that the original bulleted lists might better be replaced by more elaborate explanations of what should be provided, and that it is most essential that the two primary questions you re-stated above are thought out and answered convincingly in a registration document. > [*] >> [[ Editorial Note: >> It is acknowledged that, in many cases, the Namespace Considerations >> and Community Considerations are closely intertwined. Further, the >> bulleted lists above (from RFC 3406) seems to be more related to the >> items in the registration template entitled "Identifier uniqueness >> considerations", "Identifier persistence considerations", "Process of >> identifier assignment", and "Process for identifier resolution" than >> to the primary objectives presented in the first paragraph above >> (also from RFC 3406). >> In fact, Namespace registration documents seen so far duplicate in >> the registration template material from the "Community >> Considerations" that addresses the above bullets. >> Therefore: Should this specification now allow a combined section >> "Namespace and Community Considerations" that focuses on the >> (non-)utility of possible alternate namespace re-use and the >> *benefits* of an independent new Namespace? >> ]] > > > Leslie. > > -- > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Sun Mar 25 13:57:07 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 5A33421E800C for ; Sun, 25 Mar 2012 13:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.617 X-Spam-Level: X-Spam-Status: No, score=-98.617 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 AQPDHRZrx+fW for ; Sun, 25 Mar 2012 13:57:06 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C2BAA21E8025 for ; Sun, 25 Mar 2012 13:57:04 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA257808956; Sun, 25 Mar 2012 22:55:56 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA20581; Sun, 25 Mar 2012 22:55:54 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203252055.WAA20581@TR-Sys.de> To: leslie@thinkingcat.com Date: Sun, 25 Mar 2012 22:55:54 +0200 (MESZ) In-Reply-To: <4F6F1689.1070704@thinkingcat.com> from Leslie Daigle at Mar "25, " 2012 "08:58:49" am 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] Review period ... draft-ietf-urnbis-rfc3406bis-urn-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: Sun, 25 Mar 2012 20:57:07 -0000 Leslie, please see my remarks inline below. > Hi, > > This document questions the 2-week mailing list review period for > formal namespace registrations, suggestion 4 weeks (or possibly 8). > > First, that process came from what was standard/accepted practice at the > time of writing the first document (RFC2611). That was over a decade > ago -- and maybe we all read mail a little more regularly then ;-) > > I sort of wonder if there isn't generally a better mechanism, overall. > What gets experts' attention these days? Do we need an RSS feed? > Tweets? (!). > > All in all, I agree that reviews don't generally happen within 2 weeks. > Some of that is because the current designated expert hasn't been > paying adequate attention, and should be replaced. [...] I think it's essential for the process to not appear to be too much centered on the decision-forming by the "magic" expert -- community review and feedback should help the expert and show the prospective registrants (communities) that there isn't a high-handed single authority (the magic Expert) at work but that some sort of community (IETF) consensus is emerging on what is good or less good in proposals. Third-party reviews and feedback on the urn-nid list IMO are needed in support of the expert, and it usually needs more time than the previous 2 weeks admit. If the community is not able to help the Expert within the timeframe expected by the procedural rules, it's not the fault of the Expert, and not a priori an indication that the Expert needs to be replaced. It's either a problem of the community or the procedural rules, or both. :-) > [...] But then, authors > don't come back quickly with updates, either, so there wind up being > iterations before things are actually signed off. I don't actually > know that 4 or 8 weeks would capture that whole phase. Well, one important aspect seems to me that most individuals participating actively in the IETF are volunteers that have a day job to perform with varying, but frequently very high priority, and that the decreasing participation from acedemia (at least relative to the entire IETF community) means that there are more folks out there that cannot dedicate time to IETF purposes at their on will. (For comparison: I assume that many of the subscribers to the URN list read the messages from the list, but less than a tenth of them seem to read the documents and provide feedback.) > What I've seen (as the designated expert that needs to be replaced): > > + namespace proposals that don't get published as I-D's > -- Step 0: please publish this as an I-D > > + namespace proposals that don't follow the correct version of the RFC > -- authors need guidance about current version > > + namespace proposals that need to be cleaned up in terms of having > reasonable explanations in the Considerations sections > -- offer guidance and repeat > > + namespace proposals that come in through *other* IETF wgs, and never > get put on the urn-nid mailing list > -- need AD help to get them to the URN reviewers Section 4.3 (2nd half) of the document already says: | Before publication can be requested, however, the draft Namespace ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | specification document must undergo an Expert Review process | [RFC5226] pursuant to the guidelines written here (as well as | standard RFC publication guidelines). [...] | [...] | The proposed | template (including a pointer to a readily available copy of the | registration document) should be sent to the urn-nid@ietf.org mailing ^^^^^^^^^^^^^^ | list for review. [...] | | Working groups generally SHOULD seek early expert review for a | Namespace definition document, before they hand it over to the IESG, | and individual applicants are also advised to seek expert comments | early enough. The aforementioned list can be contacted for informal | advice at any stage. Does that need more emphasis in the draft? For instance, do we need "SHOULD" or even "MUST" in place of the "should" in the second sentence quoted above ? > > What I have *not* seen, surprisingly (but pleasantly): > > + a lot of discussion about whether something really should be a URN > namespace. Hurrah. Maybe the perceived need for third parties to seek help from some "guide" to the IETF processes helps, and writing an I-D seems to be seen as a significant hurdle already these days ... Nevertheless, IIRC, there _have_ been a few cases where "URN Namespace" vs. "URI Scheme" vs. "not in the IETF at all" in fact has been an issue. > > Leslie. > > > ... [snip] > > -- > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Sun Mar 25 14:17: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 C874221F844C for ; Sun, 25 Mar 2012 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.621 X-Spam-Level: X-Spam-Status: No, score=-98.621 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 VPbsa6o6gLUA for ; Sun, 25 Mar 2012 14:17:29 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8E21F844A for ; Sun, 25 Mar 2012 14:17:27 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA257930179; Sun, 25 Mar 2012 23:16:19 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA20683; Sun, 25 Mar 2012 23:16:14 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203252116.XAA20683@TR-Sys.de> To: leslie@thinkingcat.com Date: Sun, 25 Mar 2012 23:16:14 +0200 (MESZ) In-Reply-To: <4F6F1695.9090606@thinkingcat.com> from Leslie Daigle at Mar "25, " 2012 "08:59:01" am 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] IANA repository ... draft-ietf-urnbis-rfc3406bis-urn-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: Sun, 25 Mar 2012 21:17:29 -0000 Leslie, thanks again for your feedback; see my remarks inline below. > Hi, > > Is this point in the document: Note to other readers: This is in Section 6, IANA Considerations. >> [[ NOTE: It would be preferable to restore the generic, most >> universally supported (HTML) form of the registry be identified by an >> implementation-neutral URL, as previously supported by IANA: >> . Yet, currently >> this URI and similar forms all resolve to an XML version. >> The content there should link to alternate forms (.xml, .txt), and >> those alternate versions should indicate the *other* versions; i.e., >> where the .txt version (currently only available at ftp.IANA.ORG) >> also says, "This registry is also available in XML and plain text >> formats.", it should better say: "This registry is also available in >> HTML and XML formats." Similarly, the XML form should point to the >> HTML and plain text forms. ]] > > actually a question for the URN document, or rather something for the > IESG/IAB to explain or take up with IANA? I.e., it seems to me that > this is a broader question of references to IANA registries, and not > just *this* reference to *an* IANA registry? > > Leslie. this Note is more or less the result of some frustration over - first having useful conversation with IANA and seeing things (of admittedly more general impact) improved -- at least for the URN Namespace IANA registry, - but several months later finding the improvements have been lost again. Having it somehow back in the draft again, I wanted to hand the I-D to IANA for a quick pre-evaluation (once some more issues in the I-D have been resolved), and this way an independent inquiry to IANA wrt the loss could be avoided. I agree that the topic is general. Personally having followed the consensus building regarding a few IANA registries during the last couple of years, I thought that the principle of a simple, media-neutral stable URI for IANA registries that resolves to the most versatile presentation form of the registry (i.e. [X]HTML) -- and from which the TXT and possible XML forms are linked -- was consensual between IANA and IETF leadership. Seeing the recent loss of the [X]HTML form of various registries and .txt forms only being available via FTP now might indeed be an indication that you are right that this should perhaps become a topic for IAB/IESG to discuss with IANA. > ... [snip] > > -- > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Sun Mar 25 14:33:40 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 7A8B521E8012 for ; Sun, 25 Mar 2012 14:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.624 X-Spam-Level: X-Spam-Status: No, score=-98.624 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 sdAJ-Fob-7SA for ; Sun, 25 Mar 2012 14:33:40 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1840121E8032 for ; Sun, 25 Mar 2012 14:33:38 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA258091150; Sun, 25 Mar 2012 23:32:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA20793; Sun, 25 Mar 2012 23:32:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203252132.XAA20793@TR-Sys.de> To: marc.blanchet@viagenie.ca Date: Sun, 25 Mar 2012 23:32:29 +0200 (MESZ) In-Reply-To: <61D1B733-0575-4DDF-B2CB-CCEDC25BAC1F@viagenie.ca> from Marc Blanchet at Mar "25, " 2012 "03:07:30" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] IANA repository ... draft-ietf-urnbis-rfc3406bis-urn-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: Sun, 25 Mar 2012 21:33:40 -0000 Marc Blanchet wrote: > Le 2012-03-25 È 14:59, Leslie Daigle a Åcrit : > >> Hi, >> >> Is this point in the document: >> >>> [[ NOTE: It would be preferable to restore the generic, most >>> universally supported (HTML) form of the registry be identified by an >>> implementation-neutral URL, as previously supported by IANA: >>> . Yet, currently >>> this URI and similar forms all resolve to an XML version. >>> The content there should link to alternate forms (.xml, .txt), and >>> those alternate versions should indicate the *other* versions; i.e., >>> where the .txt version (currently only available at ftp.IANA.ORG) >>> also says, "This registry is also available in XML and plain text >>> formats.", it should better say: "This registry is also available in >>> HTML and XML formats." Similarly, the XML form should point to the >>> HTML and plain text forms. ]] >> >> actually a question for the URN document, or rather something for the >> IESG/IAB to explain or take up with IANA? I.e., it seems to me that >> this is a broader question of references to IANA registries, and not >> just *this* reference to *an* IANA registry? > > - actually, the note above (the extract from the document) is wrong. > + each XML registry has in the note: "This registry is also > available in plain text." and the .txt is available by http. Marc, the first statement may be correct, but I've seen examples of the second being definitely not holding any more. > + the html version is redundant. the xml version has xsl statement > for browsers to render it in html on the fly. so no need to have > a separate html page. I do not agree. This is not universally true. For these registries, all I see in my browser is an offer to save the .xml as a file, and hence I don't get a chance to click on a link to an alternate format. At least some of the supported .txt URIs seem to be non-intuitive; e.g. you don't get the .txt form by appending ".txt" to the generic URI. Alfred. > > Marc. >> >> >> Leslie. From A.Hoenes@TR-Sys.de Sun Mar 25 16:25: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 8B54621E804C for ; Sun, 25 Mar 2012 16:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.627 X-Spam-Level: X-Spam-Status: No, score=-98.627 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 Qtn-Gj6IbFfQ for ; Sun, 25 Mar 2012 16:25:47 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C266A21E801C for ; Sun, 25 Mar 2012 16:25:45 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA258577877; Mon, 26 Mar 2012 01:24:37 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA21248; Mon, 26 Mar 2012 01:24:35 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203252324.BAA21248@TR-Sys.de> To: leslie@thinkingcat.com Date: Mon, 26 Mar 2012 01:24:35 +0200 (MESZ) In-Reply-To: <4F6F16E5.8060909@thinkingcat.com> from Leslie Daigle at Mar "25, " 2012 "09:00:21" am 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] Authorship Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 23:25:47 -0000 Leslie Daigle wrote: > Hi, > > This document says: > >> IETF URNbis WG A. Hoenes >> Internet-Draft TR-Sys >> Obsoletes: 3406 (if approved) March 12, 2012 >> Intended status: BCP >> Expires: September 13, 2012 > > and > >> 7. Acknowledgements >> >> This document is heavily based on RFC 3406, the authors of which are >> cordially acknowledged. >> > > I don't think this is appropriate. The bulk of the work was done by > the original authors/editors/WG, this is not a complete rewrite. > > I believe the appropriate thing is to list the original authors > (unless they don't want to be!), and add the new author. > > This is also true for the syntax document, but I'm mentioning it here > because I'm clearly more implicated, as lead author on both previous > iterations of this RFC. > > Leslie. Leslie, I'm a bit surprised that you raise this argument now (and haven't done so much earlier). The delineation of who should appear as an "Author" or be listed in the "Contributors" or Acknowledgements" section of an RFC, and -- by induction -- of an I-D, seems to be a subject of recurring debate. Here is the background I'm aware of: RFC 5378 and its predecessors admit -- notwithstanding specifically indicating-so exceptions -- the unlimited right to prepare derived work within the IETF. Section 5.6 (a) of BCP 78 is rather terse on what "properly acknowledge[ing] all Contributors" means in detail. >From the perspective of the RFC Editor, being listed on the front page of an RFC means active participation during the final RFC Editor processing stages; according to my limited experience, the IESG also expects listed authors to be available for interaction during their evaluation process of a draft (once publication is requested). The RFC Style and Policy documents indicate that people not listed on the front page can be acknowledged in Contributors and/or Acknowledgements sections, which are seen as almost equivalent -- the practical difference being that people listed in a Contributors section optionally can be shown with full contact information like in the Authors' Address section. Working Groups in the IETF at present seem to have divergent policies on whom to list on the front page of their WG documents that revise previous work. Some seem to be very strict in only listing active authors/editors, and that also seems to be the essence of the RFC Editor's policy. The (vaguely) related elaborations in the "Tao" of the IETF also seem to be compatible with this policy (in particular the Tao points out that WG chairs decide who is going to be listed on the front page of WG documents). Until the advent of a related recent thread on the wgchairs list I haven't even been aware of successful diverging practice in other WGs of the IETF. The first version of the rfc2141bis draft was submitted im March 2010 and the first version of the rfc3406bis draft in November 2010. IIRC, you have been engaged in the process leading to the formation of the URNbis WG (but haven't been able to attend the BoF in person) and you have attended the WG's meeting at IETF 80. If you had indicated interest in working on the documents, I would have been honored to work with you and have your name listed on the front page of the rfc3406bis draft, but absent such indication, I simply followed the examples I've seen in the past in other WGs I've been active in, where only individuals working actively on the documents were being listed on the front page of "bis" documents. I also do not recall participation of the author of RFC 2141 in URNbis-related activities or any indication of desire to participate in the work on the rfc2141bis draft -- which of course would have been honored as well. As long as the work distribution remains the same as up to now, I'd like to defer the decision on the front page listing to the RFC Editor or eventually emerging new consensus in the IETF that might in fact invalidate the aforementioned strict practice. If you can commit time to actually perform work on the rfc3406bis draft, I'll readily agree, and you'll of course be listed on the front page of the next draft version. Otherwise, if you would prefer being listed in a distinct "Contributors" section -- maybe including contact information, then please let me know. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ > ... [snip] > > -- > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- From stpeter@stpeter.im Sun Mar 25 16:35: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 E719E21F8456 for ; Sun, 25 Mar 2012 16:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bDN4wQmAg41 for ; Sun, 25 Mar 2012 16:35:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7621F8453 for ; Sun, 25 Mar 2012 16:35:05 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F77C4009B; Sun, 25 Mar 2012 17:47:57 -0600 (MDT) Message-ID: <4F6FABA1.9050806@stpeter.im> Date: Mon, 26 Mar 2012 01:34:57 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Marc Blanchet References: <201203122052.VAA22918@TR-Sys.de> <4F6F1695.9090606@thinkingcat.com> <61D1B733-0575-4DDF-B2CB-CCEDC25BAC1F@viagenie.ca> In-Reply-To: <61D1B733-0575-4DDF-B2CB-CCEDC25BAC1F@viagenie.ca> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd) 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, 25 Mar 2012 23:35:08 -0000 On 3/25/12 3:07 PM, Marc Blanchet wrote: > > Le 2012-03-25 à 14:59, Leslie Daigle a écrit : > >> >> Hi, >> >> Is this point in the document: >> >>> [[ NOTE: It would be preferable to restore the generic, most >>> universally supported (HTML) form of the registry be identified by an >>> implementation-neutral URL, as previously supported by IANA: >>> . Yet, currently >>> this URI and similar forms all resolve to an XML version. >>> The content there should link to alternate forms (.xml, .txt), and >>> those alternate versions should indicate the *other* versions; i.e., >>> where the .txt version (currently only available at ftp.IANA.ORG >>> ) >>> also says, "This registry is also available in XML and plain text >>> formats.", it should better say: "This registry is also available in >>> HTML and XML formats." Similarly, the XML form should point to the >>> HTML and plain text forms. ]] >> >> >> actually a question for the URN document, or rather something for the >> IESG/IAB to explain or take up with IANA? I.e., it seems to me that >> this is a broader question of references to IANA registries, and not >> just *this* reference to *an* IANA registry? > > - actually, the note above (the extract from the document) is wrong. > + each XML registry has in the note: "This registry is also available > in plain text > ." > and the .txt is available by http. > + the html version is redundant. the xml version has xsl statement for > browsers to render it in html on the fly. so no need to have a separate > html page. Yes, this text is quite out of place in the document and needs to be removed. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Sun Mar 25 16:37:10 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 E8C8D21F8456 for ; Sun, 25 Mar 2012 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 y1q8UYWkOMsc for ; Sun, 25 Mar 2012 16:37:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69C21F8453 for ; Sun, 25 Mar 2012 16:37:04 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E67D44009B; Sun, 25 Mar 2012 17:50:01 -0600 (MDT) Message-ID: <4F6FAC1D.80708@stpeter.im> Date: Mon, 26 Mar 2012 01:37:01 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201203252116.XAA20683@TR-Sys.de> In-Reply-To: <201203252116.XAA20683@TR-Sys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] IANA repository ... draft-ietf-urnbis-rfc3406bis-urn-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: Sun, 25 Mar 2012 23:37:11 -0000 On 3/25/12 11:16 PM, Alfred � wrote: > Leslie, > thanks again for your feedback; see my remarks inline below. > >> Hi, >> >> Is this point in the document: > > Note to other readers: This is in Section 6, IANA Considerations. > >>> [[ NOTE: It would be preferable to restore the generic, most >>> universally supported (HTML) form of the registry be identified by an >>> implementation-neutral URL, as previously supported by IANA: >>> . Yet, currently >>> this URI and similar forms all resolve to an XML version. >>> The content there should link to alternate forms (.xml, .txt), and >>> those alternate versions should indicate the *other* versions; i.e., >>> where the .txt version (currently only available at ftp.IANA.ORG) >>> also says, "This registry is also available in XML and plain text >>> formats.", it should better say: "This registry is also available in >>> HTML and XML formats." Similarly, the XML form should point to the >>> HTML and plain text forms. ]] >> >> actually a question for the URN document, or rather something for the >> IESG/IAB to explain or take up with IANA? I.e., it seems to me that >> this is a broader question of references to IANA registries, and not >> just *this* reference to *an* IANA registry? >> >> Leslie. > > > this Note is more or less the result of some frustration over > - first having useful conversation with IANA and seeing things (of > admittedly more general impact) improved -- at least for the > URN Namespace IANA registry, > - but several months later finding the improvements have been lost > again. Venting your frustration in the IANA considerations of an I-D about URNs is not the right approach. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Sun Mar 25 16:46:02 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 DBB1121F8471 for ; Sun, 25 Mar 2012 16:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, 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 6VYPh8QygjTW for ; Sun, 25 Mar 2012 16:46:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7C21E8018 for ; Sun, 25 Mar 2012 16:45:55 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D20064005B; Sun, 25 Mar 2012 17:58:52 -0600 (MDT) Message-ID: <4F6FAE30.2060801@stpeter.im> Date: Mon, 26 Mar 2012 01:45:52 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201203252324.BAA21248@TR-Sys.de> In-Reply-To: <201203252324.BAA21248@TR-Sys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Authorship Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 23:46:03 -0000 On 3/26/12 1:24 AM, Alfred � wrote: > If you can commit time to actually perform work on the rfc3406bis > draft, I'll readily agree, and you'll of course be listed on the > front page of the next draft version. Otherwise, if you would prefer > being listed in a distinct "Contributors" section -- maybe including > contact information, then please let me know. Alfred, this is not accepted practice at the IETF. Please look at, say, RFC 2616 and RFC 3986, on which Tim Berners-Lee didn't do significant work (as far as I know), yet he was still credited as an author. Or draft-ietf-iri-3987bis (to choose a current example), on which Michel Suignard has not contributed actively; here again he was active in working on RFC 3987 but not the bis document, yet he is still credited as an author. In my opinion it is simply disrespectful to remove the old authors when the new documents are very much progressions of the old documents, not complete rewrites. (Notice how the new document in the HTTPBIS WG do in fact remove original authors like Tim Berners-Lee, because they are very significant rewrites, not minor updates.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Sun Mar 25 16:49:34 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 E86EC21E8018 for ; Sun, 25 Mar 2012 16:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, 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 hqL+DWSqaZ3Z for ; Sun, 25 Mar 2012 16:49:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E348F21F8447 for ; Sun, 25 Mar 2012 16:49:33 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D9024005B; Sun, 25 Mar 2012 18:02:31 -0600 (MDT) Message-ID: <4F6FAF09.5040903@stpeter.im> Date: Mon, 26 Mar 2012 01:49:29 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201203252055.WAA20581@TR-Sys.de> In-Reply-To: <201203252055.WAA20581@TR-Sys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Review period ... draft-ietf-urnbis-rfc3406bis-urn-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: Sun, 25 Mar 2012 23:49:35 -0000 On 3/25/12 10:55 PM, Alfred � wrote: > Leslie, > please see my remarks inline below. > > >> Hi, >> >> This document questions the 2-week mailing list review period for >> formal namespace registrations, suggestion 4 weeks (or possibly 8). >> >> First, that process came from what was standard/accepted practice at the >> time of writing the first document (RFC2611). That was over a decade >> ago -- and maybe we all read mail a little more regularly then ;-) >> >> I sort of wonder if there isn't generally a better mechanism, overall. >> What gets experts' attention these days? Do we need an RSS feed? >> Tweets? (!). >> >> All in all, I agree that reviews don't generally happen within 2 weeks. >> Some of that is because the current designated expert hasn't been >> paying adequate attention, and should be replaced. [...] > > I think it's essential for the process to not appear to be too much > centered on the decision-forming by the "magic" expert -- community > review and feedback should help the expert and show the prospective > registrants (communities) that there isn't a high-handed single > authority (the magic Expert) at work but that some sort of community > (IETF) consensus is emerging on what is good or less good in proposals. > Third-party reviews and feedback on the urn-nid list IMO are needed in > support of the expert, and it usually needs more time than the > previous 2 weeks admit. > If the community is not able to help the Expert within the timeframe > expected by the procedural rules, it's not the fault of the Expert, > and not a priori an indication that the Expert needs to be replaced. > It's either a problem of the community or the procedural rules, or both. > :-) > >> [...] But then, authors >> don't come back quickly with updates, either, so there wind up being >> iterations before things are actually signed off. I don't actually >> know that 4 or 8 weeks would capture that whole phase. > > Well, one important aspect seems to me that most individuals > participating actively in the IETF are volunteers that have a day job > to perform with varying, but frequently very high priority, and that > the decreasing participation from acedemia (at least relative to the > entire IETF community) means that there are more folks out there that > cannot dedicate time to IETF purposes at their on will. > > (For comparison: I assume that many of the subscribers to the URN list > read the messages from the list, but less than a tenth of them seem > to read the documents and provide feedback.) > > >> What I've seen (as the designated expert that needs to be replaced): >> >> + namespace proposals that don't get published as I-D's >> -- Step 0: please publish this as an I-D >> >> + namespace proposals that don't follow the correct version of the RFC >> -- authors need guidance about current version >> >> + namespace proposals that need to be cleaned up in terms of having >> reasonable explanations in the Considerations sections >> -- offer guidance and repeat >> >> + namespace proposals that come in through *other* IETF wgs, and never >> get put on the urn-nid mailing list >> -- need AD help to get them to the URN reviewers > > Section 4.3 (2nd half) of the document already says: > > | Before publication can be requested, however, the draft Namespace > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | specification document must undergo an Expert Review process > | [RFC5226] pursuant to the guidelines written here (as well as > | standard RFC publication guidelines). [...] > | [...] > | The proposed > | template (including a pointer to a readily available copy of the > | registration document) should be sent to the urn-nid@ietf.org mailing > ^^^^^^^^^^^^^^ > | list for review. [...] > | > | Working groups generally SHOULD seek early expert review for a > | Namespace definition document, before they hand it over to the IESG, > | and individual applicants are also advised to seek expert comments > | early enough. The aforementioned list can be contacted for informal > | advice at any stage. > > Does that need more emphasis in the draft? > For instance, do we need "SHOULD" or even "MUST" in place of the > "should" in the second sentence quoted above ? > > >> >> What I have *not* seen, surprisingly (but pleasantly): >> >> + a lot of discussion about whether something really should be a URN >> namespace. Hurrah. > > Maybe the perceived need for third parties to seek help from some > "guide" to the IETF processes helps, and writing an I-D seems to be > seen as a significant hurdle already these days ... > > Nevertheless, IIRC, there _have_ been a few cases where > "URN Namespace" vs. "URI Scheme" vs. "not in the IETF at all" > in fact has been an issue. Alfred, I like your emphasis on the community. However, we've also found that it helps to have a few Designated Experts who are actively responsible for reviewing registration requests, because sometimes the amorphous "community" does not come together to review things at all. I think a 2-week review period is fine. That means "someone will review your request within 2 weeks (and raise issues or tell you it looks OK". It does not mean "we promise that all issues raised during the review period will be solved within 2 weeks". Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Sun Mar 25 16:52: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 34BAD21E804C for ; Sun, 25 Mar 2012 16:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, 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 HpZBgNAdBztK for ; Sun, 25 Mar 2012 16:52:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 905D521F8447 for ; Sun, 25 Mar 2012 16:52:46 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4062D4005B; Sun, 25 Mar 2012 18:05:44 -0600 (MDT) Message-ID: <4F6FAFCB.1070404@stpeter.im> Date: Mon, 26 Mar 2012 01:52:43 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201203252015.WAA20420@TR-Sys.de> In-Reply-To: <201203252015.WAA20420@TR-Sys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Namespace and Community Considerations ... (in rfc3406bis -02 draft) 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, 25 Mar 2012 23:52:47 -0000 On 3/25/12 10:15 PM, Alfred � wrote: > Leslie, thanks for your review and comments. I'll answer the > various threads separately, slightly shortening the Subject for > convenience. > > >> Hi, >> >> Following up the editorial notes in the current draft (copied >> below for ease of reference[*] > > For clarity to other readers on the list: That's in Section 4.4.2 > of the draft, and another, closely related Editorial Note is > present in Section 4.4.1 of the draft. > >> >> First, to the question of the bulleted lists: these were merely >> suggestions of dimensions in which a proposed namespace might >> differ from existing namespaces of similar syntactic structure. >> >> These 2 sections ("namespace" and "community" considerations) >> were meant to address the basic questions of "why do you need a >> new namespace anyway?" and "is your audience broad enough that >> this merits an Internet-wide identifier scheme?". > > Yes. > > And every now and then, it's properties of the interested > community that impact the need for a new namespace; so registration > documents have been seen to need to explain the community aspects > first in order to discuss the first question. > >> >> Mostly what I've seen is that registrants don't understand the >> questions, and first drafts often don't particularly address >> those questions. [...] > > That matches my observations. > >> [...] That some of the registrations may duplicate text between >> their answers in each section is, I think, more a function of >> that than a reason to conflate the 2 into one section. > > Maybe the situation is different for already well-established > (e.g. standards-based) "foreign" namespaces seeking integration > into the URN framework vs. for newly conceived conceptional > namespaces that are looking for the "proper" way to address the > needs of their community. In my experience as sponsoring AD for several NID registrations, I would say most of them are new. So the text in several places about "existing" namespaces needs to be adjusted -- that is not the norm. >> Perhaps a better path would be to more clearly articulate the >> question/section requirements in ways that will be compelling to >> people who haven't been privvy to this sort of discussion. >> (And, I'd send text, but it's my text that is clearly the problem >> ;-) ). > > Well, we'd appreciate if years of experience might allow you to > anyway now suggest alternate text. :-) > > But I'm happy that you seem to agree that the original bulleted > lists might better be replaced by more elaborate explanations of > what should be provided, and that it is most essential that the two > primary questions you re-stated above are thought out and answered > convincingly in a registration document. On the other hand, 10 pages of text is not friendly, either. Brevity would be better here, if we can boil the essentials down to a few points of paragraphs (and then point people to some of the recent registration RFCs for examples). Peter -- Peter Saint-Andre https://stpeter.im/ From jehakala@mappi.helsinki.fi Sun Mar 25 23:46:41 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 C3A2F21F8496 for ; Sun, 25 Mar 2012 23:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, 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 W4n6R3nauKX0 for ; Sun, 25 Mar 2012 23:46:40 -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 88F2321F8472 for ; Sun, 25 Mar 2012 23:46:38 -0700 (PDT) Received: from webmail.helsinki.fi (webmail1-vallila2.fe.helsinki.fi [128.214.173.135]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q2Q6kYBj028755; Mon, 26 Mar 2012 09:46:35 +0300 Received: from 189-3.252-81.static-ip.oleane.fr (189-3.252-81.static-ip.oleane.fr [81.252.3.189]) by webmail.helsinki.fi (Horde Framework) with HTTP; Mon, 26 Mar 2012 09:46:34 +0300 Message-ID: <20120326094634.7895124ec4061dje.jehakala@webmail.helsinki.fi> Date: Mon, 26 Mar 2012 09:46:34 +0300 From: jehakala@mappi.helsinki.fi To: "Leslie Daigle" References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> In-Reply-To: <4F6F16E0.70703@thinkingcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.2.2 Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:46:41 -0000 Hello, A few comments below. Quoting "Leslie Daigle" : > > Hi, > > I am having troubles reconciling this use of fragments with RFC3986, =20 > the URI syntax document. > > My understanding of RFC3986 suggests that fragments are strictly and =20 > uniquely tied to media, and thus would be applied to the results of =20 > a URN resolution, irrespective of namespace. > > So, if you have #, you resolve and apply =20 > in whatever way makes sense for the media type of what =20 > you got back. Yes, that is the idea. > The issue with doing that with URNs is: they are designed to be =20 > flexible enough to support multiple types of response -- the URN =20 > does not designate a type. URN in general does not, but there are identifier systems which do. =20 One example of this is ISBN (International Standard Book Number). It =20 is important for everyone involved in the business - publishers, book =20 stores, customers - that books can be identified in this level. If I =20 purchase a book in EPUB 3 format, I certainly don't want a PDF version =20 of it. Different manifestations often have different look and feel, =20 and eventually probably also different intellectual content. This is =20 why at least my community prefers to identify each media type =20 separately. > For example, you might get a PDF back instead of HTML, and then your =20 > HTML # will be pointless. With URN:ISBN this would not happen, since a book published in PDF =20 format will have another ISBN than the book in HTML format (provided =20 that the publisher is using the ISBN system correctly). So it makes =20 sense to attach a to a URN based on ISBN. In the other =20 hand, ISTC (International Standard Text Code) identifies a book as an =20 immaterial work, and can be used to support retrieval of any =20 manifestation of the book. In the case of ISTC we definitely have the =20 problem you describe above; it makes absolutely no sense to attach a =20 fragment to URNs from the ISTC namespace (which has not been =20 registered yet). > Even if you say (as the document currently does) that fragments are =20 > allowed only on a per-namespace basis, I am concerned that the =20 > resulting URN namespaces would have to be severely limited in terms =20 > of URN functionality: you are essentially saying that those =20 > namespaces must be architected such that they only ever return =20 > single media type responses, or responses for which the fragments =20 > will make sense across all supported types. That is very =20 > constraining on the namespace, and the use of URNs, IMO. If the namespace is a priori constrained to single media type =20 responses, there is no problem. I don't know how many of the existing =20 namespaces have been designed in this way, but both namespaces I have =20 been closely involved with (ISBN and NBN) can support fragments =20 (provided that the fragment is not part of the NSS). > For myself, this doesn't make the case that the URN syntax can be =20 > updated to allow the use of fragment identifiers. Fragments certainly cannot be applied in all URN namespaces. But, as =20 ISBN indicates, allowing the fragment use will provide additional =20 functionality to those namespaces where identifying each manifestation =20 of a resource separately is a norm. > And, if the consensus winds up being that this does make the case to =20 > allow that, I would further argue that the text describing the =20 > per-namespace use considerations would need > > 1/ a very thorough review by URI experts to make sure it actually =20 > would hold water, There was quite a lot of discussion on the list about this in the =20 past. The outcome of that discussion is reflected in the current drafts. > 2/ to be clear about the constraints it puts on the overall URN =20 > namespace in question These constraints can be summarized by saying that if the identifier =20 system does not require that each manifestation of a resource (say, =20 PDF, EPUB 3 or HTML version of a book) receives its own identifier, =20 MUST NOT be applied. For such namespaces, using =20 does not make any additional constraints beyond those the identifier =20 standard itself has already imposed. > 3/ to be in a separate document all on its own, because it is =20 > severely distracting from a document that is meant to be the =20 > description of the syntax of URNs in general. We should be able to describe the circumstances in which it is OK to =20 use clearly. If we succeed in this, discussion of this =20 functionality will not distract the readers. As an aside, rfc3187bis is still out of date in the sense that it =20 assumes (erroneously) that the is part of the NSS. If this =20 were so, you could not use in the ISBN namespace since the =20 ISBN standard does not allow the users to add anything to the ISBN =20 string. But a construct where ISBN forms the NSS and and =20 may be added to it, gives us free hands. I shall revise the =20 I-D in this respect in the near future. Such revision requires also =20 discussions with the International ISBN Agency, since via =20 usage URN:ISBN gains functionality which is not available in the ISBN =20 itself. Best regards, Juha > > Leslie. > > > > On 3/11/12 9:05 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts =20 >> directories. This draft is a work item of the Uniform Resource =20 >> Names, Revised Working Group of the IETF. >> >> =09Title : Uniform Resource Name (URN) Syntax >> =09Author(s) : Alfred Hoenes >> =09Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt >> =09Pages : 32 >> =09Date : 2012-03-11 >> >> Uniform Resource Names (URNs) are intended to serve as persistent, >> location-independent, resource identifiers. This document serves as >> the foundation of the 'urn' URI Scheme according to RFC 3986 and sets >> forward the canonical syntax for URNs, which subdivides URNs into >> "namespaces". A discussion of both existing legacy and new >> namespaces and requirements for URN presentation and transmission are >> presented. Finally, there is a discussion of URN equivalence and how >> to determine it. This document supersedes RFC 2141. >> >> 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. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.t= xt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.tx= t >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > --=20 > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From duerst@it.aoyama.ac.jp Mon Mar 26 00:25:26 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 21ECE21F847A for ; Mon, 26 Mar 2012 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.06 X-Spam-Level: X-Spam-Status: No, score=-100.06 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 e5oEqNNKKWSA for ; Mon, 26 Mar 2012 00:25:25 -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 A36BD21F8472 for ; Mon, 26 Mar 2012 00:25:24 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2Q7PHf8012522 for ; Mon, 26 Mar 2012 16:25:17 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 46f1_92e3_d6290a00_7714_11e1_a17c_001d096c566a; Mon, 26 Mar 2012 16:25:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36828) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Mar 2012 16:25:17 +0900 Message-ID: <4F7019DC.5080703@it.aoyama.ac.jp> Date: Mon, 26 Mar 2012 16:25:16 +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: Leslie Daigle References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> In-Reply-To: <4F6F16E0.70703@thinkingcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:25:26 -0000 Hello Leslie, On 2012/03/25 22:00, Leslie Daigle wrote: > > Hi, > > I am having troubles reconciling this use of fragments with RFC3986, the > URI syntax document. > > My understanding of RFC3986 suggests that fragments are strictly and > uniquely tied to media, and thus would be applied to the results of a > URN resolution, irrespective of namespace. > > So, if you have #, you resolve and apply > in whatever way makes sense for the media type of what you got back. > > The issue with doing that with URNs is: they are designed to be flexible > enough to support multiple types of response -- the URN does not > designate a type. > > For example, you might get a PDF back instead of HTML, and then your > HTML # will be pointless. > > Even if you say (as the document currently does) that fragments are > allowed only on a per-namespace basis, I am concerned that the resulting > URN namespaces would have to be severely limited in terms of URN > functionality: you are essentially saying that those namespaces must be > architected such that they only ever return single media type responses, > or responses for which the fragments will make sense across all > supported types. Could this be relaxed to "responses for which there is a commitment that the fragments, if interpretable, are interpreted consistenly"? This would not exclude media types where a fragment identifier doesn't make sense, but would, if implemented diligently, produce consistency across all those media types where fragment identifiers make sense. Regards, Martin. > That is very constraining on the namespace, and the use > of URNs, IMO. > > For myself, this doesn't make the case that the URN syntax can be > updated to allow the use of fragment identifiers. > > And, if the consensus winds up being that this does make the case to > allow that, I would further argue that the text describing the > per-namespace use considerations would need > > 1/ a very thorough review by URI experts to make sure it actually would > hold water, > > 2/ to be clear about the constraints it puts on the overall URN > namespace in question > > 3/ to be in a separate document all on its own, because it is severely > distracting from a document that is meant to be the description of the > syntax of URNs in general. > > Leslie. > > > > On 3/11/12 9:05 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Uniform Resource Names, >> Revised Working Group of the IETF. >> >> Title : Uniform Resource Name (URN) Syntax >> Author(s) : Alfred Hoenes >> Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt >> Pages : 32 >> Date : 2012-03-11 >> >> Uniform Resource Names (URNs) are intended to serve as persistent, >> location-independent, resource identifiers. This document serves as >> the foundation of the 'urn' URI Scheme according to RFC 3986 and sets >> forward the canonical syntax for URNs, which subdivides URNs into >> "namespaces". A discussion of both existing legacy and new >> namespaces and requirements for URN presentation and transmission are >> presented. Finally, there is a discussion of URN equivalence and how >> to determine it. This document supersedes RFC 2141. >> >> 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. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >> >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > From leslie@thinkingcat.com Mon Mar 26 00:55:41 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 E851E21F8543 for ; Mon, 26 Mar 2012 00:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgnm49JzpAFm for ; Mon, 26 Mar 2012 00:55:40 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4155221F850D for ; Mon, 26 Mar 2012 00:55:40 -0700 (PDT) Received: from dhcp-514a.meeting.ietf.org ([::ffff:130.129.81.74]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Mar 2012 03:55:38 -0400 id 015B402F.4F7020FA.00007489 Message-ID: <4F7020F9.4090605@thinkingcat.com> Date: Mon, 26 Mar 2012 03:55:37 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: jehakala@mappi.helsinki.fi References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <20120326094634.7895124ec4061dje.jehakala@webmail.helsinki.fi> In-Reply-To: <20120326094634.7895124ec4061dje.jehakala@webmail.helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:55:42 -0000 I'm just going to follow up 2 points for now: >> The issue with doing that with URNs is: they are designed to be >> flexible enough to support multiple types of response -- the URN does >> not designate a type. > > URN in general does not, but there are identifier systems which do. But this is the general URN syntax. So we should have a syntax that supports the general URN, not other identifier systems. >> For example, you might get a PDF back instead of HTML, and then your >> HTML # will be pointless. > > With URN:ISBN this would not happen, since a book published in PDF > format will have another ISBN than the book in HTML format (provided > that the publisher is using the ISBN system correctly). Your parenthetical remark is key: historicaly experience suggests that there is little reason to expect they will. Just looking at the number of ISBNs assigned to teddy bears in gift shops, for example. >> 1/ a very thorough review by URI experts to make sure it actually >> would hold water, > > There was quite a lot of discussion on the list about this in the past. > The outcome of that discussion is reflected in the current drafts. I'm not sure that you caught that I said URI experts, there. Not the URNbis WG mailing list. Leslie. On 3/26/12 2:46 AM, jehakala@mappi.helsinki.fi wrote: > Hello, > > A few comments below. > > Quoting "Leslie Daigle" : > >> >> Hi, >> >> I am having troubles reconciling this use of fragments with RFC3986, >> the URI syntax document. >> >> My understanding of RFC3986 suggests that fragments are strictly and >> uniquely tied to media, and thus would be applied to the results of a >> URN resolution, irrespective of namespace. >> >> So, if you have #, you resolve and apply >> in whatever way makes sense for the media type of what you >> got back. > > Yes, that is the idea. > >> The issue with doing that with URNs is: they are designed to be >> flexible enough to support multiple types of response -- the URN does >> not designate a type. > > URN in general does not, but there are identifier systems which do. One > example of this is ISBN (International Standard Book Number). It is > important for everyone involved in the business - publishers, book > stores, customers - that books can be identified in this level. If I > purchase a book in EPUB 3 format, I certainly don't want a PDF version > of it. Different manifestations often have different look and feel, and > eventually probably also different intellectual content. This is why at > least my community prefers to identify each media type separately. > >> For example, you might get a PDF back instead of HTML, and then your >> HTML # will be pointless. > > With URN:ISBN this would not happen, since a book published in PDF > format will have another ISBN than the book in HTML format (provided > that the publisher is using the ISBN system correctly). So it makes > sense to attach a to a URN based on ISBN. In the other hand, > ISTC (International Standard Text Code) identifies a book as an > immaterial work, and can be used to support retrieval of any > manifestation of the book. In the case of ISTC we definitely have the > problem you describe above; it makes absolutely no sense to attach a > fragment to URNs from the ISTC namespace (which has not been registered > yet). > >> Even if you say (as the document currently does) that fragments are >> allowed only on a per-namespace basis, I am concerned that the >> resulting URN namespaces would have to be severely limited in terms of >> URN functionality: you are essentially saying that those namespaces >> must be architected such that they only ever return single media type >> responses, or responses for which the fragments will make sense across >> all supported types. That is very constraining on the namespace, and >> the use of URNs, IMO. > > If the namespace is a priori constrained to single media type responses, > there is no problem. I don't know how many of the existing namespaces > have been designed in this way, but both namespaces I have been closely > involved with (ISBN and NBN) can support fragments (provided that the > fragment is not part of the NSS). > >> For myself, this doesn't make the case that the URN syntax can be >> updated to allow the use of fragment identifiers. > > Fragments certainly cannot be applied in all URN namespaces. But, as > ISBN indicates, allowing the fragment use will provide additional > functionality to those namespaces where identifying each manifestation > of a resource separately is a norm. > >> And, if the consensus winds up being that this does make the case to >> allow that, I would further argue that the text describing the >> per-namespace use considerations would need >> >> 1/ a very thorough review by URI experts to make sure it actually >> would hold water, > > There was quite a lot of discussion on the list about this in the past. > The outcome of that discussion is reflected in the current drafts. > >> 2/ to be clear about the constraints it puts on the overall URN >> namespace in question > > These constraints can be summarized by saying that if the identifier > system does not require that each manifestation of a resource (say, PDF, > EPUB 3 or HTML version of a book) receives its own identifier, > MUST NOT be applied. For such namespaces, using > does not make any additional constraints beyond those the identifier > standard itself has already imposed. > >> 3/ to be in a separate document all on its own, because it is severely >> distracting from a document that is meant to be the description of the >> syntax of URNs in general. > > We should be able to describe the circumstances in which it is OK to use > clearly. If we succeed in this, discussion of this > functionality will not distract the readers. > > As an aside, rfc3187bis is still out of date in the sense that it > assumes (erroneously) that the is part of the NSS. If this > were so, you could not use in the ISBN namespace since the > ISBN standard does not allow the users to add anything to the ISBN > string. But a construct where ISBN forms the NSS and and > may be added to it, gives us free hands. I shall revise the I-D > in this respect in the near future. Such revision requires also > discussions with the International ISBN Agency, since via > usage URN:ISBN gains functionality which is not available in the ISBN > itself. > > Best regards, > > Juha >> >> Leslie. >> >> >> >> On 3/11/12 9:05 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Uniform Resource Names, >>> Revised Working Group of the IETF. >>> >>> Title : Uniform Resource Name (URN) Syntax >>> Author(s) : Alfred Hoenes >>> Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> Pages : 32 >>> Date : 2012-03-11 >>> >>> Uniform Resource Names (URNs) are intended to serve as persistent, >>> location-independent, resource identifiers. This document serves as >>> the foundation of the 'urn' URI Scheme according to RFC 3986 and sets >>> forward the canonical syntax for URNs, which subdivides URNs into >>> "namespaces". A discussion of both existing legacy and new >>> namespaces and requirements for URN presentation and transmission are >>> presented. Finally, there is a discussion of URN equivalence and how >>> to determine it. This document supersedes RFC 2141. >>> >>> 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. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >> >> -- >> >> ------------------------------------------------------------------- >> "Reality: >> Yours to discover." >> -- ThinkingCat >> Leslie Daigle >> leslie@thinkingcat.com >> ------------------------------------------------------------------- >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >> > > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From jehakala@mappi.helsinki.fi Mon Mar 26 03:52:35 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 483BF21F84D9 for ; Mon, 26 Mar 2012 03:52:34 -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 86a8s3jQ1izH for ; Mon, 26 Mar 2012 03:52:33 -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 96E6021F84A1 for ; Mon, 26 Mar 2012 03:52:30 -0700 (PDT) Received: from webmail.helsinki.fi (webmail1-vallila2.fe.helsinki.fi [128.214.173.135]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q2QAqRSB004217; Mon, 26 Mar 2012 13:52:27 +0300 Received: from bdv75-10-88-171-40-111.fbx.proxad.net (bdv75-10-88-171-40-111.fbx.proxad.net [88.171.40.111]) by webmail.helsinki.fi (Horde Framework) with HTTP; Mon, 26 Mar 2012 13:52:27 +0300 Message-ID: <20120326135227.11351iy3c1jaatm3.jehakala@webmail.helsinki.fi> Date: Mon, 26 Mar 2012 13:52:27 +0300 From: jehakala@mappi.helsinki.fi To: "Leslie Daigle" References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <20120326094634.7895124ec4061dje.jehakala@webmail.helsinki.fi> <4F7020F9.4090605@thinkingcat.com> In-Reply-To: <4F7020F9.4090605@thinkingcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.2.2 Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 10:52:35 -0000 Hello, Quoting "Leslie Daigle" : > > I'm just going to follow up 2 points for now: > >>> The issue with doing that with URNs is: they are designed to be >>> flexible enough to support multiple types of response -- the URN does >>> not designate a type. >> >> URN in general does not, but there are identifier systems which do. > > But this is the general URN syntax. So we should have a syntax that =20 > supports the general URN, not other identifier systems. I am not sure what you mean by the general URN. URN system consists of =20 namespaces, which establish their own rules as regards what kind of =20 resources they identify and how. There are technical requirements that =20 must apply to all the namespaces, but many things must be left to the =20 namespace level, use of fragment being one of them. >>> For example, you might get a PDF back instead of HTML, and then your >>> HTML # will be pointless. >> >> With URN:ISBN this would not happen, since a book published in PDF >> format will have another ISBN than the book in HTML format (provided >> that the publisher is using the ISBN system correctly). > > Your parenthetical remark is key: historicaly experience suggests =20 > that there is little reason to expect they will. Just looking at =20 > the number of ISBNs assigned to teddy bears in gift shops, for =20 > example. Any identifier system can be misused and alas, ISBN is no exception. =20 More alarming than those teddy bears (which got an ISBN so that they =20 could be entered into a sales system which required ISBNs) is the =20 emerging trend that some publishers especially in the USA would prefer =20 to give the same ISBN to all manifestations of a book. However, as a =20 rule the ISBN system works well. When writing rfc2141bis and namespace registrations we should build =20 upon the identifier standards and established practices on how to =20 apply them, and not on the possibility that someone does not know how =20 to implement the standard (or makes a decision to deviate from it on =20 purpose). > >>> 1/ a very thorough review by URI experts to make sure it actually >>> would hold water, >> >> There was quite a lot of discussion on the list about this in the past. >> The outcome of that discussion is reflected in the current drafts. > > I'm not sure that you caught that I said URI experts, there. Not =20 > the URNbis WG mailing list. OK. Such review is of course welcome. And we need also feedback from =20 some identifier communities who may benefit from the use. Best regards, Juha From leslie@thinkingcat.com Tue Mar 27 08:38:57 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 4D5E921E8240 for ; Tue, 27 Mar 2012 08:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, 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 tbPWc1kqoPut for ; Tue, 27 Mar 2012 08:38:56 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E421E823E for ; Tue, 27 Mar 2012 08:38:56 -0700 (PDT) Received: from dhcp-514a.meeting.ietf.org ([::ffff:130.129.81.74]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 27 Mar 2012 11:38:47 -0400 id 015B4053.4F71DF08.000039FE Message-ID: <4F71DF07.6020803@thinkingcat.com> Date: Tue, 27 Mar 2012 11:38:47 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "=?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?=" References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <4F7019DC.5080703@it.aoyama.ac.jp> In-Reply-To: <4F7019DC.5080703@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:38:57 -0000 Hi Martin, In-line... On 3/26/12 3:25 AM, "Martin J. Dürst" wrote: > Hello Leslie, > > On 2012/03/25 22:00, Leslie Daigle wrote: >> >> Hi, >> >> I am having troubles reconciling this use of fragments with RFC3986, the >> URI syntax document. >> >> My understanding of RFC3986 suggests that fragments are strictly and >> uniquely tied to media, and thus would be applied to the results of a >> URN resolution, irrespective of namespace. >> >> So, if you have #, you resolve and apply >> in whatever way makes sense for the media type of what you got back. >> >> The issue with doing that with URNs is: they are designed to be flexible >> enough to support multiple types of response -- the URN does not >> designate a type. >> >> For example, you might get a PDF back instead of HTML, and then your >> HTML # will be pointless. >> >> Even if you say (as the document currently does) that fragments are >> allowed only on a per-namespace basis, I am concerned that the resulting >> URN namespaces would have to be severely limited in terms of URN >> functionality: you are essentially saying that those namespaces must be >> architected such that they only ever return single media type responses, >> or responses for which the fragments will make sense across all >> supported types. > > Could this be relaxed to "responses for which there is a commitment that > the fragments, if interpretable, are interpreted consistenly"? This > would not exclude media types where a fragment identifier doesn't make > sense, but would, if implemented diligently, produce consistency across > all those media types where fragment identifiers make sense. I'm really not sure what this means, in practice. And, I find myself wondering: what's the _specified_ behaviour when a fragment reference cannot be resolved (by the client)? Leslie. > > Regards, Martin. > > >> That is very constraining on the namespace, and the use >> of URNs, IMO. >> >> For myself, this doesn't make the case that the URN syntax can be >> updated to allow the use of fragment identifiers. >> >> And, if the consensus winds up being that this does make the case to >> allow that, I would further argue that the text describing the >> per-namespace use considerations would need >> >> 1/ a very thorough review by URI experts to make sure it actually would >> hold water, >> >> 2/ to be clear about the constraints it puts on the overall URN >> namespace in question >> >> 3/ to be in a separate document all on its own, because it is severely >> distracting from a document that is meant to be the description of the >> syntax of URNs in general. >> >> Leslie. >> >> >> >> On 3/11/12 9:05 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Uniform Resource Names, >>> Revised Working Group of the IETF. >>> >>> Title : Uniform Resource Name (URN) Syntax >>> Author(s) : Alfred Hoenes >>> Filename : draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> Pages : 32 >>> Date : 2012-03-11 >>> >>> Uniform Resource Names (URNs) are intended to serve as persistent, >>> location-independent, resource identifiers. This document serves as >>> the foundation of the 'urn' URI Scheme according to RFC 3986 and sets >>> forward the canonical syntax for URNs, which subdivides URNs into >>> "namespaces". A discussion of both existing legacy and new >>> namespaces and requirements for URN presentation and transmission are >>> presented. Finally, there is a discussion of URN equivalence and how >>> to determine it. This document supersedes RFC 2141. >>> >>> 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. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt >>> >>> >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >> > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From duerst@it.aoyama.ac.jp Tue Mar 27 21:51:24 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 AB40021F85CE for ; Tue, 27 Mar 2012 21:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.042 X-Spam-Level: X-Spam-Status: No, score=-100.042 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 edkPzwkf-D1O for ; Tue, 27 Mar 2012 21:51:21 -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 11FB321F85C3 for ; Tue, 27 Mar 2012 21:51:19 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2S4p6wo025858 for ; Wed, 28 Mar 2012 13:51:06 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3771_8f03_a13942a0_7891_11e1_b9db_001d096c5782; Wed, 28 Mar 2012 13:51:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35304) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Mar 2012 13:51:11 +0900 Message-ID: <4F7298B7.2050808@it.aoyama.ac.jp> Date: Wed, 28 Mar 2012 13:51:03 +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: Leslie Daigle References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <4F7019DC.5080703@it.aoyama.ac.jp> <4F71DF07.6020803@thinkingcat.com> In-Reply-To: <4F71DF07.6020803@thinkingcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 04:51:24 -0000 Hello Leslie, On 2012/03/28 0:38, Leslie Daigle wrote: > On 3/26/12 3:25 AM, "Martin J. Dürst" wrote: >> Could this be relaxed to "responses for which there is a commitment that >> the fragments, if interpretable, are interpreted consistenly"? This >> would not exclude media types where a fragment identifier doesn't make >> sense, but would, if implemented diligently, produce consistency across >> all those media types where fragment identifiers make sense. > > I'm really not sure what this means, in practice. Okay. Assume as an example that the resource can be served as HTML, as SVG, and as PDF, and that the last one doesn't allow fragment identifiers (that could be wrong, now or in the future). Then what this would mean is that one and the same fragment identifier would identify one and the same thing (chapter, paragraph, figure, whatever) in both the HTML and the SVG version. It's definitely possible to make this work, although it's of course also possible to mess this up. > And, I find myself wondering: what's the _specified_ behaviour when a > fragment reference cannot be resolved (by the client)? A fragment identifier identifies a secondary resource, so if that doesn't work, all we know about is the resource. I don't think there's a spec for this, but I'd assume that most clients would resolve to the resource and then give up. And 'give up' would usually place the user at the top of the document. Actually, I think RFC 3986 is pretty close to what I'm suggesting (third paragraph of http://tools.ietf.org/html/rfc3986#section-3.5): If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations. Each representation should either define the fragment so that it corresponds to the same secondary resource, regardless of how it is represented, or should leave the fragment undefined (i.e., not found). So I think I agree with you the URN spec shouldn't mess around with fragment identifiers, and that individual URN namespaces also should not mess around with fragment identifiers. The only thing these specs may want to do is to point to RFC 3986. Regards, Martin. From juha.hakala@helsinki.fi Tue Mar 27 23:29:01 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 220A721F85C3 for ; Tue, 27 Mar 2012 23:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 PzSv00SLi5pQ for ; Tue, 27 Mar 2012 23:29: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 0A44D21F873D for ; Tue, 27 Mar 2012 23:28: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 q2S6SrdH032709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2012 09:28:55 +0300 Message-ID: <4F72AFA5.10508@helsinki.fi> Date: Wed, 28 Mar 2012 09:28:53 +0300 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <4F7019DC.5080703@it.aoyama.ac.jp> <4F71DF07.6020803@thinkingcat.com> <4F7298B7.2050808@it.aoyama.ac.jp> In-Reply-To: <4F7298B7.2050808@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:29:01 -0000 Hello, A few comments below. Martin J. Dürst wrote: > Hello Leslie, > > On 2012/03/28 0:38, Leslie Daigle wrote: > >> On 3/26/12 3:25 AM, "Martin J. Dürst" wrote: > >>> Could this be relaxed to "responses for which there is a commitment that >>> the fragments, if interpretable, are interpreted consistenly"? This >>> would not exclude media types where a fragment identifier doesn't make >>> sense, but would, if implemented diligently, produce consistency across >>> all those media types where fragment identifiers make sense. >> >> I'm really not sure what this means, in practice. > > Okay. Assume as an example that the resource can be served as HTML, as > SVG, and as PDF, and that the last one doesn't allow fragment > identifiers (that could be wrong, now or in the future). Then what this > would mean is that one and the same fragment identifier would identify > one and the same thing (chapter, paragraph, figure, whatever) in both > the HTML and the SVG version. It's definitely possible to make this > work, although it's of course also possible to mess this up. The URN namespaces in which I consider it is safe to use are those and only those which will always assign separate identifiers to the different (HTML, SVG, PDF and so on) representations / versions / manifestations of the resource. In these namespaces it is never necessary to investigate if the might work correctly with different manifestations of the resource. Of course these identifier systems also require that if the intellectual content of the resource changes (which may have an impact on fragments) even if the file format does not change, a new identifier must be assigned. As Leslie has pointed, it is possible that these identifier systems (ISBNs, NBNs, etc.) can be misused. But IMHO we should not drop useful functionality from URN docs only because some people (a minority ot all users) abuse knowingly or unknowingly identifier systems like ISBN. As regards identifiers which are not representation-specific: although it is possible that different manifestations of the resource have the same internal structure now, there is no way we can guarantee this 10 or 100 years from now. Therefore, if we have an identifier which encompasses several or all manifestations of a resource such as International Standard Text Code (ISTC), I would never recommend the use of with it. You may wonder where the persistence comes from if the URNs are tied to a particular representation of a resource. The idea the national libraries are considering is that the most persistent thing related to the resource is the description of it as immaterial work; a metadata record which will have its own URN. All the representations of the work will be linked to this record, so the user can pick for instance the eldest representation (most authentic, but hard to utilize without specialised rendering application) or the newest one (easy to use, but with altered look and feel). It might be useful to discuss somewhere how national libraries and other institutions which are involved with the long term (meaning centuries) preservation of digital resources intend to do this, and how we plan to use URNs in this work. >> And, I find myself wondering: what's the _specified_ behaviour when a >> fragment reference cannot be resolved (by the client)? > > A fragment identifier identifies a secondary resource, so if that > doesn't work, all we know about is the resource. I don't think there's a > spec for this, but I'd assume that most clients would resolve to the > resource and then give up. And 'give up' would usually place the user at > the top of the document. This sounds like a sensible way of solving the problems which occur when the client cannot find the correct place within the resource, or when it cannot interprete the . > > > Actually, I think RFC 3986 is pretty close to what I'm suggesting (third > paragraph of http://tools.ietf.org/html/rfc3986#section-3.5): > > If the > primary resource has multiple representations, as is often the case > for resources whose representation is selected based on attributes of > the retrieval request (a.k.a., content negotiation), then whatever is > identified by the fragment should be consistent across all of those > representations. Each representation should either define the > fragment so that it corresponds to the same secondary resource, > regardless of how it is represented, or should leave the fragment > undefined (i.e., not found). > > > So I think I agree with you the URN spec shouldn't mess around with > fragment identifiers, and that individual URN namespaces also should not > mess around with fragment identifiers. The only thing these specs may > want to do is to point to RFC 3986. This is pretty much what we have been trying to do in the URNbis I-Ds. But given that URNs are persistent, we have to make it clear that it is only safe to use if the URN is tied to a single representation / manifestation / etc. of the resource. Juha > > Regards, Martin. > _______________________________________________ > 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