From nobody Wed Mar 9 00:10:14 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE6B12DF53; Wed, 9 Mar 2016 00:10:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309081011.30488.22133.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 00:10:11 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [urn] Last Call Expired: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 08:10:13 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 10 08:08:27 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10112D53B; Wed, 9 Mar 2016 01:01:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309090100.4700.87450.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 01:01:00 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Thu, 10 Mar 2016 08:08:24 -0800 Subject: [urn] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 09:01:01 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ From nobody Thu Mar 10 08:08:29 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1075612D850; Wed, 9 Mar 2016 10:16:26 -0800 (PST) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F171B12D8E9; Wed, 9 Mar 2016 10:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EivM0kiDZtd7; Wed, 9 Mar 2016 10:16:24 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B3912D850; Wed, 9 Mar 2016 10:16:23 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (8.13.8/8.13.8) with ESMTP id u29IGMwS029561; Wed, 9 Mar 2016 18:16:22 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 4D518C205E5; Wed, 9 Mar 2016 18:16:22 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" In-Reply-To: <20160210134504.31541.12018.idtracker@ietfa.amsl.com> References: <20160210134504.31541.12018.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #891987 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 09 Mar 2016 18:16:22 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 10 Mar 2016 08:08:25 -0800 Cc: draft-martin-urn-globus.all@ietf.org, iesg@ietf.org Subject: [urn] [IANA #891987] Last Call: (A URN Namespace for Globus) to Informational RFC X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-lastcall-comment@iana.org List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:16:26 -0000 (BEGIN IANA COMMENTS) IESG/Authors/WG Chairs: IANA has completed its review of draft-martin-urn-globus-02.txt. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the Formal URN Namespaces subregistry of the Uniform Resource Names (URN) Namespaces registry located at: https://www.iana.org/assignments/urn-namespaces/ a single new Namespace is to be registered as follows: URN Namespace: globus Reference: [ RFC-to-be ] IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN (END IANA COMMENTS) From nobody Thu Mar 10 08:08:32 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D512D91D; Wed, 9 Mar 2016 11:07:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309190752.19356.29274.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 11:07:52 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Thu, 10 Mar 2016 08:08:25 -0800 Subject: [urn] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 19:07:52 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ From nobody Wed Mar 16 21:35:08 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E412DA08; Wed, 16 Mar 2016 21:35:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317043506.24546.33159.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 21:35:06 -0700 Archived-At: Cc: draft-martin-urn-globus@ietf.org, urn@ietf.org, barryleiba@computer.org Subject: [urn] Ben Campbell's No Objection on draft-martin-urn-globus-02: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 04:35:06 -0000 Ben Campbell has entered the following ballot position for draft-martin-urn-globus-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3, title: "Examples (Informative)" The whole draft is informational :-) From nobody Thu Mar 17 02:18:45 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8B412D6EA; Thu, 17 Mar 2016 02:18:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 02:18:43 -0700 Archived-At: Cc: draft-martin-urn-globus@ietf.org, joel.halpern@ericsson.com, urn@ietf.org, barryleiba@computer.org Subject: [urn] Jari Arkko's Discuss on draft-martin-urn-globus-02: (with DISCUSS) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 09:18:44 -0000 Jari Arkko has entered the following ballot position for draft-martin-urn-globus-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for writing this document. Before recommending its approval, I need to have a discussion with you about one aspect. Joel Halpern raised a question in his Gen-ART review: As per the pointer in this document to RFC 3406 section 4.3, this document is required to have a Namespace Considerations section which "outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." While there is a section called Namespace Considerations, what it lists is the envisioned usages, not the reasons existing name spaces are insufficient. Is there an answer, or an update? I cannot imagine adding the requested rationale is difficult to add in this case, but it probably should be added. Thoughts? From nobody Thu Mar 17 05:52:31 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F36AF12DC03; Thu, 17 Mar 2016 05:52:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317125229.17338.81883.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 05:52:29 -0700 Archived-At: Cc: draft-martin-urn-globus@ietf.org, urn@ietf.org, barryleiba@computer.org Subject: [urn] Stephen Farrell's No Objection on draft-martin-urn-globus-02: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:52:30 -0000 Stephen Farrell has entered the following ballot position for draft-martin-urn-globus-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The secdir-review [1] raised a nit you may want to consider, but I didn't see a response. (Apologies if I just missed it.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06382.html From nobody Thu Mar 17 05:55:39 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B912D522; Thu, 17 Mar 2016 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03F9fZ68hXez; Thu, 17 Mar 2016 05:55:35 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6F512DBDB; Thu, 17 Mar 2016 05:54:03 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id h129so98406141ywb.1; Thu, 17 Mar 2016 05:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=AoufBixizjNP1DNr7sz/XKdL3r4L3Z12+XQZb1TI0pc=; b=LGR09l9Ca7fDbP5uu+fD/zyu5cKJAi60/UN58/D4AYruhgsuCkRRlcEpFZ/Q6hfPoH x9BYH0tyyRymNAsJ8BFg9h9gxphszpjwfTqvVUWrYt+yW7zYarpPOVaUaUNB3vVShVoP 5+DNyzK4dKYTzZcBKof5PKMb4JwDD3ROGMwvPpUSmjKv25Pnl/v23S0yOBuCyggDLfin 9w1wGKUl3ikPqWAUJeI3V42PCNgez46fGucgoUBaD82LtPULdFv46+jIdDGgAe45snCR Ag0OmlmmhO6rFE1xJ6pPJQpqdVfgy92mF96Pq+DiLi1AfpTto8nfFWibYdhOXWeHX7QH aTVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AoufBixizjNP1DNr7sz/XKdL3r4L3Z12+XQZb1TI0pc=; b=bGvAJb6F/2m/n311feqEHhXsJ89crQ53VE0zNNRbD4YRwrJRzKmgVLNqVZw+tcnldA /uHiQshmzjDXWGDl8IipYuS3QYyksYfwW4LIxj0M5Geq7FuMm9zPrE3LKr7jYJiabMGt zYo3gARnEBo+HNAGf4WRjr++BcgWwOZWicvYgmE+eom08Onh6gPLY7tOMoBrPfJLPnsH l3P/wU86MMXDvDQGx7WzGjaPwSJq/Sr3qYn+G0MqeQ2gqJwukNBB0UqlJCnX+VnGbjxI VXZmod9o0ziiN8vjxGWcjU+932Mbenf8GtuyEhiK4Y94gOHK4Z8FRlAZqcPIZaVqG7+/ XtWQ== X-Gm-Message-State: AD7BkJKVMWO+rDxZo2pOnW8yAXmETlq2z5s+ky0dEd8EM734chedr4hOtV1KEKISV4BO+I/ITQ12oOCZmCvILQ== MIME-Version: 1.0 X-Received: by 10.129.48.77 with SMTP id w74mr4253033yww.147.1458219242317; Thu, 17 Mar 2016 05:54:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 05:54:01 -0700 (PDT) In-Reply-To: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> References: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 08:54:01 -0400 X-Google-Sender-Auth: smEtdBVl6ulkz6P9v3yI4AJA4sQ Message-ID: From: Barry Leiba To: Jari Arkko Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-martin-urn-globus@ietf.org, Joel Halpern , "urn@ietf.org" , The IESG Subject: Re: [urn] Jari Arkko's Discuss on draft-martin-urn-globus-02: (with DISCUSS) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:55:38 -0000 Repeating what I said in my other note that had different distribution: What I'll say abut this, as responsible AD, is that the almost-finished urnbis work has updated the registration procedure and the registration template, and the "Namespace Considerations", along with the requirement that it "outlines the perceived need for a new namespace", is no longer there. That update (see draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not yet finished and so isn't official, but the intent is clear and the last call of this document has been posted to the urnbis working group for review against the old+new requirements. My view is that we should not be too rigorous about this point at this stage. Barry On Thu, Mar 17, 2016 at 5:18 AM, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > draft-martin-urn-globus-02: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-martin-urn-globus/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for writing this document. Before recommending its approval, I > need to have a discussion with you about one aspect. Joel Halpern raised > a question in his Gen-ART review: > > As per the pointer in this document to RFC 3406 section 4.3, this > document is required to have a Namespace Considerations section which > "outlines the perceived need for a new namespace (i.e., where existing > namespaces fall short of the proposer's requirements)." While there is a > section called Namespace Considerations, what it lists is the envisioned > usages, not the reasons existing name spaces are insufficient. > > Is there an answer, or an update? > > I cannot imagine adding the requested rationale is difficult to add in > this case, but it probably should be added. Thoughts? > > > > From nobody Thu Mar 17 10:17:19 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A6C12DCE2; Thu, 17 Mar 2016 10:17:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317171718.8768.85145.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 10:17:18 -0700 From: IETF Secretariat Archived-At: Subject: [urn] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:17:18 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ From nobody Thu Mar 17 12:53:22 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8F4FE12D56B; Thu, 17 Mar 2016 02:38:02 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D776B12D7DC; Thu, 17 Mar 2016 02:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdigqrsCiyrM; Thu, 17 Mar 2016 02:37:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 30F9C12D56B; Thu, 17 Mar 2016 02:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C986E2CE21; Thu, 17 Mar 2016 11:30:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTajnnmHoXvq; Thu, 17 Mar 2016 11:30:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id D69A32CCBF; Thu, 17 Mar 2016 11:30:00 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BF649EFE-2A43-4974-ACEF-9E4FBE167F59"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: <56BD269D.1040703@joelhalpern.com> Date: Thu, 17 Mar 2016 09:15:16 +0000 Message-Id: References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , "A. Jean Mahoney" Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 09:38:02 -0000 --Apple-Mail=_BF649EFE-2A43-4974-ACEF-9E4FBE167F59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, Joel. Authors, any responses to this? I think we need to discuss this=85 Jari On 12 Feb 2016, at 00:26, Joel M. Halpern wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-martin-urn-globus-02 > A URN Namespace for Globus > Reviewer: Joel M. Halpern > Review Date: 11-Feb-2016 > IETF LC End Date: 9-March-2016 > IESG Telechat date: 17-March-2016 >=20 > Summary: This document is nearly ready for publication as an = informational RFC. >=20 > This reviewer assumes that the appropriate message has been or will be = sent to urn-nid@apps.ietf.org. >=20 > Major issues: > As per the pointer in this document to RFC 3406 section 4.3, this = document is required to have a Namespace Considerations section which = "outlines the perceived need for a new namespace (i.e., where existing = namespaces fall short of the proposer's requirements)." While there is = a section called Namespace Considerations, what it lists is the = envisioned usages, not the reasons existing name spaces are = insufficient. >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --Apple-Mail=_BF649EFE-2A43-4974-ACEF-9E4FBE167F59 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6nWkAAoJEM80gCTQU46qqUEP/0WcupRcZGlQVsGUudoIKTtF m/azy2vKwGDnMP/hF27VWdDxqn6xVH4PtWyRLV6RjBuExNxA06EMJghX7o1a5tbi /67KVWBvnQQtsQ1PNYOjCt5LGLq3zA6reSv+ue9NKcvzIkF1upfzB8FVdCHOxMTM jAfZFfD5kt9zkyE6L+4y3C4PunSijQz42ImzBx0ivtg/xBFFCXiOAKuiHtfC2JHY HaxR1QEze0C/2MBgW1aZcil3iCfKPWn8mFe8iE6Tzc2hqa3mBCqaQCBbCnpzC2EH TkkMRLyyeVW+diVBORX4Du9UV56Z4XeFtBfKRFtVnnAKibmeJBBNmgYU4bOizDdZ XDzU6bzZyDUcJ51oAwpX/BFCHOko3NwkmhgV9jmHjUKDpvk+EBXgv1TxBWRqoyxF 2Emnd5xpzdnlNYjCSj9dtPdhKNKQ3iuQLf36AWq6DOZqC50fxyw0Yuq9H4x1zlEE jouJHHoon3v7DKHd8t6gRTlN8q+gNevfWH3mUblZQnOJzOjzX/pUSOEA/BvQvHr/ BRo9Gp74GduWUhD77mAdKQ/1ecvQYUlZAxfZfC18mnDVvX89vzKaPpQWxvusxL1k zOkwRPnpu+d2zUnBPJEK33gS9aPYEtVWnSpwV8yvGATzDOE+5EuBPckHGSHOQ6nb 6MXtWZkLyz2HgtlKFR2F =fQ1w -----END PGP SIGNATURE----- --Apple-Mail=_BF649EFE-2A43-4974-ACEF-9E4FBE167F59-- From nobody Thu Mar 17 12:53:24 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DE01412D947; Thu, 17 Mar 2016 06:29:41 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6C712D942 for ; Thu, 17 Mar 2016 06:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeM-8raawfMo for ; Thu, 17 Mar 2016 06:29:31 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA0612D511 for ; Thu, 17 Mar 2016 06:29:31 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-06v.sys.comcast.net with comcast id X1VR1s00354zqzk011VWt4; Thu, 17 Mar 2016 13:29:30 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-11v.sys.comcast.net with comcast id X1VU1s0071nMCLR011VV85; Thu, 17 Mar 2016 13:29:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2HDTRrY009990; Thu, 17 Mar 2016 09:29:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2HDTQ2n009982; Thu, 17 Mar 2016 09:29:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Joel M. Halpern" In-Reply-To: <56EAA9AD.2070808@joelhalpern.com> (jmh@joelhalpern.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 17 Mar 2016 09:29:26 -0400 Message-ID: <87io0l9qrt.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458221370; bh=mqco/g2HmgrSfMsKPc9jb7OcoUoM2K8vKbe17GIlunE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=vSvryNJwL038z/2c0SXEJ4L3Gn5NlZCOELN00upxKqu4hwyS7BdTxz+bgJEZmFVAa blP/bSjJStDUv+cUZfsDTz3tOWBGm9Tuyt7eq7xUt5etngB6GLLzIIlML633hQMv/H uX++xUY78iRTmnsOHrkeAVsXTuPkkR1OZywrTIpntOqBGTHJjj5sWrAON2Rudj9lZY QpHTwDqtknbjbsWc3antqigTvW0wYtiSSTQ/3cQ6DabOg3cfsfPyer4B1tU/OIeHRB 69QPQy8ukNMdtWBUDF7aKHwGjUQxQTF1PurZzV4mXITfx2UDCEgH5gXVnlmvB7kBve xkISCckTSDoTg== Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:07 -0700 Cc: draft-martin-urn-globus.all@ietf.org, gen-art@ietf.org, barryleiba@computer.org Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:29:42 -0000 On 3/17/16 8:50 AM, Barry Leiba wrote: > [...] > My view is that we should not be too rigorous about this point at this stage. "Joel M. Halpern" writes: > If it were me, it would seem that a document using a new and > not-yet-approved process would require a normative reference to the new > process, and could not take effect until the new process was approved. It seems that we can meet the current requirement by updating the draft to state why Martin/Globus wants the namespace. I.e., they must have *some* reason. Then per the new requirements, we can be relaxed regarding what constitutes "sufficient" reasons for approval. E.g., looking at the draft, I see in section 1: Globus creates unique identifiers which will be persisted in external systems, and which must be identifiable as references to Globus entities. My guess is that this is why Martin/Globus are going to the effort to register a namespace, and as such, it constitutes "the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." Dale From nobody Thu Mar 17 12:53:26 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6C3A712DA5C; Thu, 17 Mar 2016 05:52:31 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5512D522; Thu, 17 Mar 2016 05:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LisHZdBh_GoA; Thu, 17 Mar 2016 05:52:28 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0763A12DC11; Thu, 17 Mar 2016 05:50:59 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g3so98338903ywa.3; Thu, 17 Mar 2016 05:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=lSiIq/qpIVX7zn5Y5WxwtvKHf8zIO5bftt4RE4e58Wg=; b=i4hz6A65bnfNAPYYFYWIbCy05lTVhZ5JD+3rdTmeog0s7e/W4K8CKmBj6RRUoiW+Ss hVK01TjxaPDrIuTKsKgpR6s+QuOtXIYX85ZL+v8lkMNTiwINz23BX04+E1XvkNvolRho W/UAUROaOCH9YJxpt03+mIWFtU3Mq+02uiRlIVxpx7HsRHUFkBnQgTa6GoG7365DIHCd MimUCMxNc47ixhaVVK5RcLEPtHwhIfpx49FBA8WAJVDbl0VielOOFwuOBXWal3fCbP3b 3RQdYfGNm96YmLT/Naayq+mQ9s9YsmjfTjjr01/qUmKr/RtQ34YEELUO0AJGi/TvtXST mvUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=lSiIq/qpIVX7zn5Y5WxwtvKHf8zIO5bftt4RE4e58Wg=; b=lm0rIuWV3Hu++gfGwSovfVGVgdNo6vbv/ytDfVXj2yGnkfNBzSWUkJCVlFeVe/SSc5 4O550ijnnJY3Rtw2iFokluxlR6GQwGLn7cXC7/Q4jhsHu2Hv/COGH9K5TX55Qp+dZ3jM RRZK6CNNqGtdhbNQV/XYVsWFCdhFg5He8Z8DE22d/mWfIj/YelAUKjaTTlC1KnLNcBBG 7L/PqZO+7ry8q905RpETVmP2RKOpsXtfyOWYsNKhRT6yBGvoUhIYDeeuYlnadwNTivO1 0k01dfVQr3y7gfPRPK7s19Ifxmy0EsoiZ+2ttBbXo/LbgMUdZXJxYIH090MwgvIIVWtP 291A== X-Gm-Message-State: AD7BkJKlETrCIziStqyXrer4C3yQG6RpU/XbliOUGP5pqUNPkgjc0/Lr9vXS1BtOPNNkIPwxQZnvZi4Y1akGRA== MIME-Version: 1.0 X-Received: by 10.129.115.67 with SMTP id o64mr2593177ywc.59.1458219059086; Thu, 17 Mar 2016 05:50:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 05:50:58 -0700 (PDT) In-Reply-To: References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> Date: Thu, 17 Mar 2016 08:50:58 -0400 X-Google-Sender-Auth: wMWkVkSl4uXZ1kJ-J9b71CyO7TU Message-ID: From: Barry Leiba To: Jari Arkko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , "Joel M. Halpern" , "A. Jean Mahoney" Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:52:31 -0000 What I'll say abut this, as responsible AD, is that the almost-finished urnbis work has updated the registration procedure and the registration template, and the "Namespace Considerations", along with the requirement that it "outlines the perceived need for a new namespace", is no longer there. That update (see draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not yet finished and so isn't official, but the intent is clear and the last call of this document has been posted to the urnbis working group for review against the old+new requirements. My view is that we should not be too rigorous about this point at this stag= e. Barry On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko wrote: > Thanks, Joel. > > Authors, any responses to this? I think we need to discuss this=E2=80=A6 > > Jari > > On 12 Feb 2016, at 00:26, Joel M. Halpern wrote: > >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-martin-urn-globus-02 >> A URN Namespace for Globus >> Reviewer: Joel M. Halpern >> Review Date: 11-Feb-2016 >> IETF LC End Date: 9-March-2016 >> IESG Telechat date: 17-March-2016 >> >> Summary: This document is nearly ready for publication as an information= al RFC. >> >> This reviewer assumes that the appropriate message has been or will be s= ent to urn-nid@apps.ietf.org. >> >> Major issues: >> As per the pointer in this document to RFC 3406 section 4.3, this doc= ument is required to have a Namespace Considerations section which "outline= s the perceived need for a new namespace (i.e., where existing namespaces f= all short of the proposer's requirements)." While there is a section calle= d Namespace Considerations, what it lists is the envisioned usages, not the= reasons existing name spaces are insufficient. >> >> Minor issues: N/A >> >> Nits/editorial comments: N/A >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > From nobody Thu Mar 17 12:53:31 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2DC3C12D522; Thu, 17 Mar 2016 05:57:38 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D712D541; Thu, 17 Mar 2016 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu7dp7ruBaFc; Thu, 17 Mar 2016 05:57:36 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF3A12D522; Thu, 17 Mar 2016 05:57:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 030E124E0FC; Thu, 17 Mar 2016 05:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458219434; bh=l/YQy8inKTGEjWkOn2sKxdQ5nYzWnpuhMXHGkAonUtE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=FKkJm1HJm342MOtfRrxVEH1jGagjYViFE3K+eJEX5Jcwew1UZTL6wTMu0SyuqAjPt zIielvBRxOrqp8hDPmg+yR4OIOU8lnFEsNp8bhkzjJYk69CGuBMsLCi7QZmGrglzB3 jISGmCClFKbQwphtl7E0DfJtQ0VNTRrJitSW1sms= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [46.189.28.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DE927240C18; Thu, 17 Mar 2016 05:57:12 -0700 (PDT) To: Barry Leiba , Jari Arkko References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56EAA9AD.2070808@joelhalpern.com> Date: Thu, 17 Mar 2016 08:57:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , "A. Jean Mahoney" Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:57:38 -0000 I guess this is between Barry, Jari, and the IESG. If it were me, it would seem that a document using a new and not-yet-approved process would require a normative reference to the new process, and could not take effect until the new process was approved. Yours, Joel On 3/17/16 8:50 AM, Barry Leiba wrote: > What I'll say abut this, as responsible AD, is that the > almost-finished urnbis work has updated the registration procedure and > the registration template, and the "Namespace Considerations", along > with the requirement that it "outlines the perceived need for a new > namespace", is no longer there. That update (see > draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not > yet finished and so isn't official, but the intent is clear and the > last call of this document has been posted to the urnbis working group > for review against the old+new requirements. > > My view is that we should not be too rigorous about this point at this stage. > > Barry > > On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko wrote: >> Thanks, Joel. >> >> Authors, any responses to this? I think we need to discuss this… >> >> Jari >> >> On 12 Feb 2016, at 00:26, Joel M. Halpern wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> . >>> >>> Document: draft-martin-urn-globus-02 >>> A URN Namespace for Globus >>> Reviewer: Joel M. Halpern >>> Review Date: 11-Feb-2016 >>> IETF LC End Date: 9-March-2016 >>> IESG Telechat date: 17-March-2016 >>> >>> Summary: This document is nearly ready for publication as an informational RFC. >>> >>> This reviewer assumes that the appropriate message has been or will be sent to urn-nid@apps.ietf.org. >>> >>> Major issues: >>> As per the pointer in this document to RFC 3406 section 4.3, this document is required to have a Namespace Considerations section which "outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." While there is a section called Namespace Considerations, what it lists is the envisioned usages, not the reasons existing name spaces are insufficient. >>> >>> Minor issues: N/A >>> >>> Nits/editorial comments: N/A >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >> > From nobody Thu Mar 17 12:53:38 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B1DA712DBD8; Thu, 17 Mar 2016 06:03:36 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9567212DBD9; Thu, 17 Mar 2016 06:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOJNgcMO9uiy; Thu, 17 Mar 2016 06:03:33 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDD212DBD8; Thu, 17 Mar 2016 06:02:34 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h129so98714530ywb.1; Thu, 17 Mar 2016 06:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=c+aBOEQSHj6N/faxTqjx4eFodwxTalKJHnVTOMAYO64=; b=l7zAYoUPT/+uiGfItQdFM2JQ/lsqy4wrEKdWMlxpO2UZK6LSkpU7PeEs7kXmfluZr6 UJ/JIv2xQziPuMhi31qeHpX7FKIXb/8Q/0CF4b+QkTy2vYD1YVbq4d7iVutrcrA5sYgk lFXyWDKr08KgJLxtQXXVnBozMYGOeeHUfbLpblwqy94URWqTqZpRWNQDpLH9BYp9x14W 9g9UuvpH2rJUAmvaKHZz7gE3Unxo7OEB2s0coT+547HrGKpiTaL5gYxqoyYvOXHw/w+M /L2kvdOMxK9kune2kMJx9xX4FeK/4gpfXkWKRg+U3GcWoyzFa4IQbxb0Kpgq92JemcEL J5RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=c+aBOEQSHj6N/faxTqjx4eFodwxTalKJHnVTOMAYO64=; b=hu2utJ10BPWmIUbk0MPPSOZ2R6OrycCX6bZ3OLq/dV1skimqmW6TE0Iqv/ErL8Y8cU TyOZrKSknqgNO6PLluxhTFrtsJ9HwmWIJePjeM2Evjjr668MTguw5N2mv0Q4jV615sco wLFlVr6oGtTfvgQ7fHspd+Mui5ZGL2EFvxLb5gtMLMFqH/VD0dbIIWGphdYDr/hZcAGx 4jkyllJ9ZFS8dc71JRxB9Atg7/zfVHJ/6/cbv/bNPuCR3htvDzly2cfYbbe+w6jm0Onl T5gyCg9qlDZiteweBCi+FDpyhM7kfdWCOsYJ/0H7MsYlv7XOkXtgudcsSLboh/Xtn6a9 CVbg== X-Gm-Message-State: AD7BkJKyjqbQg67S3PEQVVZI3sVO3F490GaSAl3mq1edUG4c41HKOWjfj9t2EbS++FKUBk34+eqXOcw0TWdYQQ== MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr3728091ywx.176.1458219753813; Thu, 17 Mar 2016 06:02:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 06:02:33 -0700 (PDT) In-Reply-To: <56EAA9AD.2070808@joelhalpern.com> References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> <56EAA9AD.2070808@joelhalpern.com> Date: Thu, 17 Mar 2016 09:02:33 -0400 X-Google-Sender-Auth: SwIUJkuFpDvdDPoqOWCGpav83uw Message-ID: From: Barry Leiba To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , "A. Jean Mahoney" Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:03:36 -0000 In general, I completely agree with you on that. That's why I didn't say we should use the new process, but, rather, that on the particular point you raise, we shouldn't be that rigorous right now. b On Thu, Mar 17, 2016 at 8:57 AM, Joel M. Halpern wrot= e: > I guess this is between Barry, Jari, and the IESG. > > If it were me, it would seem that a document using a new and > not-yet-approved process would require a normative reference to the new > process, and could not take effect until the new process was approved. > > Yours, > Joel > > > On 3/17/16 8:50 AM, Barry Leiba wrote: >> >> What I'll say abut this, as responsible AD, is that the >> almost-finished urnbis work has updated the registration procedure and >> the registration template, and the "Namespace Considerations", along >> with the requirement that it "outlines the perceived need for a new >> namespace", is no longer there. That update (see >> draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not >> yet finished and so isn't official, but the intent is clear and the >> last call of this document has been posted to the urnbis working group >> for review against the old+new requirements. >> >> My view is that we should not be too rigorous about this point at this >> stage. >> >> Barry >> >> On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko wrote= : >>> >>> Thanks, Joel. >>> >>> Authors, any responses to this? I think we need to discuss this=E2=80= =A6 >>> >>> Jari >>> >>> On 12 Feb 2016, at 00:26, Joel M. Halpern wrote: >>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> . >>>> >>>> Document: draft-martin-urn-globus-02 >>>> A URN Namespace for Globus >>>> Reviewer: Joel M. Halpern >>>> Review Date: 11-Feb-2016 >>>> IETF LC End Date: 9-March-2016 >>>> IESG Telechat date: 17-March-2016 >>>> >>>> Summary: This document is nearly ready for publication as an >>>> informational RFC. >>>> >>>> This reviewer assumes that the appropriate message has been or will be >>>> sent to urn-nid@apps.ietf.org. >>>> >>>> Major issues: >>>> As per the pointer in this document to RFC 3406 section 4.3, this >>>> document is required to have a Namespace Considerations section which >>>> "outlines the perceived need for a new namespace (i.e., where existing >>>> namespaces fall short of the proposer's requirements)." While there i= s a >>>> section called Namespace Considerations, what it lists is the envision= ed >>>> usages, not the reasons existing name spaces are insufficient. >>>> >>>> Minor issues: N/A >>>> >>>> Nits/editorial comments: N/A >>>> >>>> _______________________________________________ >>>> urn mailing list >>>> urn@ietf.org >>>> https://www.ietf.org/mailman/listinfo/urn >>> >>> >> > From nobody Thu Mar 17 12:53:41 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CCA4412D94D; Thu, 17 Mar 2016 06:38:27 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D2212DBE4; Thu, 17 Mar 2016 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7SALHAnEXmW; Thu, 17 Mar 2016 06:38:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id E914712D94D; Thu, 17 Mar 2016 06:38:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C8D472CCBF; Thu, 17 Mar 2016 15:38:16 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArArTA5wsLXa; Thu, 17 Mar 2016 15:38:16 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4838E2CC9A; Thu, 17 Mar 2016 15:38:04 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Thu, 17 Mar 2016 13:37:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <170D9352-DF63-4EE2-985F-B7B026DB5890@piuha.net> References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> <56EAA9AD.2070808@joelhalpern.com> To: Barry Leiba , "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , iesg@ietf.org Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:38:28 -0000 (Adding the IESG) I=92m open to any solution in this matter. We could bypass the = requirement. Or we could add a sentence either about the non-sufficiency = of the current spaces, or about the upcoming change in process. Or we = could add a reference to the new process. What would you suggest, Barry? Jari On 17 Mar 2016, at 13:02, Barry Leiba wrote: > In general, I completely agree with you on that. That's why I didn't > say we should use the new process, but, rather, that on the particular > point you raise, we shouldn't be that rigorous right now. >=20 > b >=20 > On Thu, Mar 17, 2016 at 8:57 AM, Joel M. Halpern = wrote: >> I guess this is between Barry, Jari, and the IESG. >>=20 >> If it were me, it would seem that a document using a new and >> not-yet-approved process would require a normative reference to the = new >> process, and could not take effect until the new process was = approved. >>=20 >> Yours, >> Joel >>=20 >>=20 >> On 3/17/16 8:50 AM, Barry Leiba wrote: >>>=20 >>> What I'll say abut this, as responsible AD, is that the >>> almost-finished urnbis work has updated the registration procedure = and >>> the registration template, and the "Namespace Considerations", along >>> with the requirement that it "outlines the perceived need for a new >>> namespace", is no longer there. That update (see >>> draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not >>> yet finished and so isn't official, but the intent is clear and the >>> last call of this document has been posted to the urnbis working = group >>> for review against the old+new requirements. >>>=20 >>> My view is that we should not be too rigorous about this point at = this >>> stage. >>>=20 >>> Barry >>>=20 >>> On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko = wrote: >>>>=20 >>>> Thanks, Joel. >>>>=20 >>>> Authors, any responses to this? I think we need to discuss this=85 >>>>=20 >>>> Jari >>>>=20 >>>> On 12 Feb 2016, at 00:26, Joel M. Halpern = wrote: >>>>=20 >>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>> like any other last call comments. >>>>>=20 >>>>> For more information, please see the FAQ at >>>>>=20 >>>>> . >>>>>=20 >>>>> Document: draft-martin-urn-globus-02 >>>>> A URN Namespace for Globus >>>>> Reviewer: Joel M. Halpern >>>>> Review Date: 11-Feb-2016 >>>>> IETF LC End Date: 9-March-2016 >>>>> IESG Telechat date: 17-March-2016 >>>>>=20 >>>>> Summary: This document is nearly ready for publication as an >>>>> informational RFC. >>>>>=20 >>>>> This reviewer assumes that the appropriate message has been or = will be >>>>> sent to urn-nid@apps.ietf.org. >>>>>=20 >>>>> Major issues: >>>>> As per the pointer in this document to RFC 3406 section 4.3, this >>>>> document is required to have a Namespace Considerations section = which >>>>> "outlines the perceived need for a new namespace (i.e., where = existing >>>>> namespaces fall short of the proposer's requirements)." While = there is a >>>>> section called Namespace Considerations, what it lists is the = envisioned >>>>> usages, not the reasons existing name spaces are insufficient. >>>>>=20 >>>>> Minor issues: N/A >>>>>=20 >>>>> Nits/editorial comments: N/A >>>>>=20 >>>>> _______________________________________________ >>>>> urn mailing list >>>>> urn@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/urn >>>>=20 >>>>=20 >>>=20 >>=20 From nobody Thu Mar 17 12:53:43 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 56F0F12D861; Thu, 17 Mar 2016 06:44:01 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859712D912 for ; Thu, 17 Mar 2016 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uchicago-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcLIsGa10T6N for ; Thu, 17 Mar 2016 06:43:57 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C5F12D861 for ; Thu, 17 Mar 2016 06:43:57 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id p65so15145585wmp.1 for ; Thu, 17 Mar 2016 06:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uchicago-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bEWZMEfYETiRv2ZnmvP09sRIa091YuyA2Wj2Bl1SHng=; b=Q/wiHc5hbm3kRKHoSHEozXI76BfJY/IUhM+0VDtOYlcFWyvQtXt0Svy9+5YatyQAsE wVB9KVk2JSU+EZYlMavUfqRo4vm9+XK+MKnrBwHO0rw2cZ9H/XWJj6LPxUhgAAPp36Zh tLU7XI53Eiboq/RgB97TeJRT3Ulf89GWJzrnk24zbtRmhw0AgTzsZ5CZz7K5E25SyBEL 68A9TTvKdxPgpfCyJCZXeXPXCLDYHGpxq3yJfGvif+7msDRT9J67cbqiVe/WFeCy66jP QaTwyPGoVFXJH7j68I2qvUWA9uSg/8+HjROXRyNGwr1EynVmKExjnvwPO4tEBvs7gjX1 0cyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bEWZMEfYETiRv2ZnmvP09sRIa091YuyA2Wj2Bl1SHng=; b=Kt2q8krD0xuijhUvrz83bNabd3cpnAiB1/MOvjRfcmmZ3nMlh220e3VHHCz59Cq1l+ SSseUyNTPNHGP4nOqPiqn1cchXRIownLUdMRUCQt6VzlUuQJJGuUB1rNn7Ar7nYbf1jV /nI9RRmlGY7BugG/oVDgScjvixoBB8vypxYF0+ILsrUS+4TZwPzBz7LSW99W+zdm9uux FbYvSs6TeYQFArNhEJjF59gXIWsul8+ekrk7Ip5JxQaztG/wlKROQosh4D+paQEL3LK/ /W99rq4BUD96eOGQIzOWFs8megukZzSCecv3tXX2daTFq6ZzIRLeDXE7zUyFX8wWTqRZ zw4A== X-Gm-Message-State: AD7BkJJ38k0FOSahJl4vKlMvKiaINW6FZyGdMJ/GOoB2lFj+7ROXZ8PRpVkDKpcJUWtHGQ== X-Received: by 10.28.45.209 with SMTP id t200mr36435059wmt.71.1458222235475; Thu, 17 Mar 2016 06:43:55 -0700 (PDT) Received: from [192.168.1.70] (host109-151-84-245.range109-151.btcentralplus.com. [109.151.84.245]) by smtp.gmail.com with ESMTPSA id bg1sm7779042wjc.27.2016.03.17.06.43.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 06:43:54 -0700 (PDT) To: Jari Arkko , Barry Leiba , "Joel M. Halpern" References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> <56EAA9AD.2070808@joelhalpern.com> <170D9352-DF63-4EE2-985F-B7B026DB5890@piuha.net> From: Brendan McCollam Message-ID: <56EAB499.30002@uchicago.edu> Date: Thu, 17 Mar 2016 13:43:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <170D9352-DF63-4EE2-985F-B7B026DB5890@piuha.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , iesg@ietf.org Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:44:01 -0000 Hello all, Thanks for your feedback. Speaking for Globus, we're open to making whatever changes the reviewers feel are necessary. If you'd be more comfortable with an extra line or two of justification in the "Namespace Considerations" section, we're happy to add that. If we do make revisions, does the review process have to start over? Or can we proceed from this stage after addressing concerns? Best, Brendan McCollam On 03/17/2016 01:37 PM, Jari Arkko wrote: > (Adding the IESG) > > I’m open to any solution in this matter. We could bypass the requirement. Or we could add a sentence either about the non-sufficiency of the current spaces, or about the upcoming change in process. Or we could add a reference to the new process. > > What would you suggest, Barry? > > Jari > > On 17 Mar 2016, at 13:02, Barry Leiba wrote: > >> In general, I completely agree with you on that. That's why I didn't >> say we should use the new process, but, rather, that on the particular >> point you raise, we shouldn't be that rigorous right now. >> >> b >> >> On Thu, Mar 17, 2016 at 8:57 AM, Joel M. Halpern wrote: >>> I guess this is between Barry, Jari, and the IESG. >>> >>> If it were me, it would seem that a document using a new and >>> not-yet-approved process would require a normative reference to the new >>> process, and could not take effect until the new process was approved. >>> >>> Yours, >>> Joel >>> >>> >>> On 3/17/16 8:50 AM, Barry Leiba wrote: >>>> What I'll say abut this, as responsible AD, is that the >>>> almost-finished urnbis work has updated the registration procedure and >>>> the registration template, and the "Namespace Considerations", along >>>> with the requirement that it "outlines the perceived need for a new >>>> namespace", is no longer there. That update (see >>>> draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not >>>> yet finished and so isn't official, but the intent is clear and the >>>> last call of this document has been posted to the urnbis working group >>>> for review against the old+new requirements. >>>> >>>> My view is that we should not be too rigorous about this point at this >>>> stage. >>>> >>>> Barry >>>> >>>> On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko wrote: >>>>> Thanks, Joel. >>>>> >>>>> Authors, any responses to this? I think we need to discuss this… >>>>> >>>>> Jari >>>>> >>>>> On 12 Feb 2016, at 00:26, Joel M. Halpern wrote: >>>>> >>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>>> like any other last call comments. >>>>>> >>>>>> For more information, please see the FAQ at >>>>>> >>>>>> . >>>>>> >>>>>> Document: draft-martin-urn-globus-02 >>>>>> A URN Namespace for Globus >>>>>> Reviewer: Joel M. Halpern >>>>>> Review Date: 11-Feb-2016 >>>>>> IETF LC End Date: 9-March-2016 >>>>>> IESG Telechat date: 17-March-2016 >>>>>> >>>>>> Summary: This document is nearly ready for publication as an >>>>>> informational RFC. >>>>>> >>>>>> This reviewer assumes that the appropriate message has been or will be >>>>>> sent to urn-nid@apps.ietf.org. >>>>>> >>>>>> Major issues: >>>>>> As per the pointer in this document to RFC 3406 section 4.3, this >>>>>> document is required to have a Namespace Considerations section which >>>>>> "outlines the perceived need for a new namespace (i.e., where existing >>>>>> namespaces fall short of the proposer's requirements)." While there is a >>>>>> section called Namespace Considerations, what it lists is the envisioned >>>>>> usages, not the reasons existing name spaces are insufficient. >>>>>> >>>>>> Minor issues: N/A >>>>>> >>>>>> Nits/editorial comments: N/A >>>>>> >>>>>> _______________________________________________ >>>>>> urn mailing list >>>>>> urn@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/urn >>>>> From nobody Thu Mar 17 12:53:49 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F208912D5AD; Thu, 17 Mar 2016 06:50:48 -0700 (PDT) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D751512D937; Thu, 17 Mar 2016 06:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1GoPZZhhIXx; Thu, 17 Mar 2016 06:50:46 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27AE12D5AD; Thu, 17 Mar 2016 06:50:45 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h129so100467435ywb.1; Thu, 17 Mar 2016 06:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RiWj4V3ePGc2mz4JduHabD0XZN0QMuOkY7dZalEGfVQ=; b=TuNep8+mvGsJtNTdHFJCIbNydr1lCODLMxpA/oXBOoBUzIZPT1Jm3hU5w0N0Boz88x 39XbWX32A4/aKHan35wZbsjNqDtlK+zGsUCT8CGNfQl+md3WNFQpmfZ4h8Bo7/HYpIbl OHpPfOBcBNhMY65RZ90p9LghylPXAUdvqOtZe/yfmqf7tZTDymXwQWhgDvNYU0Z/DEPc a6jnv1EE8hoc6xQJA0HqDYKRRZOQ61b/NJFJdoQ447nqAlAtoNccglo6eNLOmr8yCc1a Ao/PJl/ubeeoDc39rzT6mpIDc87PgsHuXVYjZqX/EzGo8eIQ+yo13Tek5gzhiNbdvyHd KeMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RiWj4V3ePGc2mz4JduHabD0XZN0QMuOkY7dZalEGfVQ=; b=gOyqfMdwvAOL5y4dsjouHuPygpBK8vsd2vhJo43rNpPWhS7VIpjQxuYx9tYTfTraZH Jt4kKSqMqenPhNY6gRhIAXHyMbT3j/NFQNDlTp5gHdT54hevu5UA6V0bxxXQ9YCKccIi mQjE4zSIqvE5DyhZMxY8dngjwNLM2lDrfJ+LsYHHQKVdzcVuhjN49zpEupPJdEKPseeH 2cda5mOQDQ2QxwMlyzYCYOJpv3p2GZSPtw7lUn8c/vxvBgDd7mkwg4q3kJ0y1HhfKhgh Cb9I9ylezHDADnAtZ/B6ZV6XuXLHGPWaNjnE0Jwtbzs3zGA9fMu2I9JAb9hHnBwQJwz2 bJ+A== X-Gm-Message-State: AD7BkJKz6srw0GKC6PlWFIuvhTRn9SH1ctZk0TRCivk+nONMexOG3KxpVtS0WV40FvpfyIn3qxL/BJd3jbwesQ== MIME-Version: 1.0 X-Received: by 10.129.71.135 with SMTP id u129mr4487092ywa.162.1458222645254; Thu, 17 Mar 2016 06:50:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 06:50:45 -0700 (PDT) In-Reply-To: <56EAB499.30002@uchicago.edu> References: <56BD072F.4080905@nostrum.com> <56BD269D.1040703@joelhalpern.com> <56EAA9AD.2070808@joelhalpern.com> <170D9352-DF63-4EE2-985F-B7B026DB5890@piuha.net> <56EAB499.30002@uchicago.edu> Date: Thu, 17 Mar 2016 09:50:45 -0400 X-Google-Sender-Auth: uS0Ad5Nrq1Tl9HIJBwdpzqC1_Wc Message-ID: From: Barry Leiba To: Brendan McCollam Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 12:53:19 -0700 Cc: draft-martin-urn-globus.all@ietf.org, General Area Review Team , "Joel M. Halpern" , IESG Subject: Re: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:50:49 -0000 > Thanks for your feedback. Speaking for Globus, we're open to making whatever > changes the reviewers feel are necessary. If you'd be more comfortable with > an extra line or two of justification in the "Namespace Considerations" > section, we're happy to add that. OK, then let's go ahead and add that extra line or two (Dale's suggestion is a fine one), and then there's no controversy. > If we do make revisions, does the review process have to start over? Or can > we proceed from this stage after addressing concerns? Oh, no, no need to start anything over. You just add text (and have a look at Stephen Farrell's comment also when you do that), post a revised I-D, and we continue from where we are. Barry From nobody Fri Mar 18 06:38:06 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E929712D886; Fri, 18 Mar 2016 06:38:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318133803.20123.11077.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 06:38:03 -0700 Archived-At: Subject: [urn] New Version Notification - draft-martin-urn-globus-03.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 13:38:04 -0000 A new version (-03) has been submitted for draft-martin-urn-globus: https://www.ietf.org/internet-drafts/draft-martin-urn-globus-03.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-martin-urn-globus-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 18 06:47:26 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C112D803; Fri, 18 Mar 2016 06:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rob6QYV3f5nG; Fri, 18 Mar 2016 06:47:20 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8233612D5EA; Fri, 18 Mar 2016 06:47:20 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g3so139342190ywa.3; Fri, 18 Mar 2016 06:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NQMqSteK80N+2hHdgJ84DFHfVilROfPeqLREY+Cis1s=; b=UOzVU4C/H+sDfjkdGb7dUyQ8tqZ6iq2/GSfqpxb3S07/XXfG4B4DNRR8N+AOSg3QQl 87qQbLdEelrOy9paZeVzIwK1M0OJnPNM8lrLqitTiYI+86dYVktZtBqjgepxqkEtLVlV U7w98YmWNb7RizvH1Y5OEOjx5DFb7u9zhAkHcHSUqnJcFS16s3TBQJhRTfy2VSGwWVyL 3IK9g8okiMfxJnVmgmesKDTuesUzhLzfs39B+NPoCwppX1bw1Kwsb2++jZyhh/oJBeG8 55nuQ2AAY9Jt4BxXc7d9VHMhSHJVIBPHqM5NwTJU8INiqFwgSwgF49ccH46VBKuuK0F9 aJ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NQMqSteK80N+2hHdgJ84DFHfVilROfPeqLREY+Cis1s=; b=JmFUF8T7dOI2XreHa9C17WYIIzpw48F8GK9Wtn4+Gb8IkkrsIwzEtZd90lwoixREvk 9fj1lXXDXvoEtKxQlXnD6eCjEnPe3z5S54OvL6ZiH0WvNCRwrG1uhX6rk8W8W2fFCbbQ BNBRW4tCTHZZSS29xqvEye+tkkdTyAgT2GfGCg/c/+oU+DY7nJNpIu86gBFJ2XIskdQB XMPouFnIqS+Fj46hdFSIpY8wV6o05xHcUPlCiiIAdMnJrfyp2JExocTQ2+eTTixddciR a06UTrf057JQcoQ05BUImFBWOcy6BRTgNYki5gi5W4wqDLr7IYk2uiuu7hGpxyaB/LQJ MDtg== X-Gm-Message-State: AD7BkJIH3LEZDHlTaDTFQ93P3ImCgC4by5bXYeLyw0ncQWD57xd8D1d8Tkhin+QpmUQ39hYpUVYm6FSAoRm9vw== MIME-Version: 1.0 X-Received: by 10.129.71.135 with SMTP id u129mr7687919ywa.162.1458308839768; Fri, 18 Mar 2016 06:47:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Fri, 18 Mar 2016 06:47:19 -0700 (PDT) In-Reply-To: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> References: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 09:47:19 -0400 X-Google-Sender-Auth: QNKTO87QizavJAj-P0XDME3C__g Message-ID: From: Barry Leiba To: Jari Arkko Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-martin-urn-globus@ietf.org, Joel Halpern , "urn@ietf.org" , The IESG Subject: Re: [urn] Jari Arkko's Discuss on draft-martin-urn-globus-02: (with DISCUSS) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 13:47:22 -0000 Jari, can you check that version -03 addresses your DISCUSS? Thanks, Barry On Thu, Mar 17, 2016 at 5:18 AM, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > draft-martin-urn-globus-02: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-martin-urn-globus/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for writing this document. Before recommending its approval, I > need to have a discussion with you about one aspect. Joel Halpern raised > a question in his Gen-ART review: > > As per the pointer in this document to RFC 3406 section 4.3, this > document is required to have a Namespace Considerations section which > "outlines the perceived need for a new namespace (i.e., where existing > namespaces fall short of the proposer's requirements)." While there is a > section called Namespace Considerations, what it lists is the envisioned > usages, not the reasons existing name spaces are insufficient. > > Is there an answer, or an update? > > I cannot imagine adding the requested rationale is difficult to add in > this case, but it probably should be added. Thoughts? > > > > From nobody Fri Mar 18 07:09:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49F12D5EA; Fri, 18 Mar 2016 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI-T8KHM0QkN; Fri, 18 Mar 2016 07:09:49 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 234CE12D556; Fri, 18 Mar 2016 07:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5F75E2CCE2; Fri, 18 Mar 2016 16:08:45 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6fLcUbI90mt; Fri, 18 Mar 2016 16:08:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B4EFA2CC9A; Fri, 18 Mar 2016 16:08:44 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_972EE63D-526A-4597-B21C-1FAFB7F59CDC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: Date: Fri, 18 Mar 2016 14:08:45 +0000 Message-Id: <62788D8C-61EA-48CA-A283-981FD2663E59@piuha.net> References: <20160317091843.6022.58207.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-martin-urn-globus@ietf.org, Joel Halpern , "urn@ietf.org" , The IESG Subject: Re: [urn] Jari Arkko's Discuss on draft-martin-urn-globus-02: (with DISCUSS) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 14:09:50 -0000 --Apple-Mail=_972EE63D-526A-4597-B21C-1FAFB7F59CDC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii cleared On 18 Mar 2016, at 13:47, Barry Leiba wrote: > Jari, can you check that version -03 addresses your DISCUSS? > > Thanks, > Barry > > On Thu, Mar 17, 2016 at 5:18 AM, Jari Arkko wrote: >> Jari Arkko has entered the following ballot position for >> draft-martin-urn-globus-02: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-martin-urn-globus/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for writing this document. Before recommending its approval, I >> need to have a discussion with you about one aspect. Joel Halpern raised >> a question in his Gen-ART review: >> >> As per the pointer in this document to RFC 3406 section 4.3, this >> document is required to have a Namespace Considerations section which >> "outlines the perceived need for a new namespace (i.e., where existing >> namespaces fall short of the proposer's requirements)." While there is a >> section called Namespace Considerations, what it lists is the envisioned >> usages, not the reasons existing name spaces are insufficient. >> >> Is there an answer, or an update? >> >> I cannot imagine adding the requested rationale is difficult to add in >> this case, but it probably should be added. Thoughts? >> >> >> >> --Apple-Mail=_972EE63D-526A-4597-B21C-1FAFB7F59CDC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW7AvtAAoJEM80gCTQU46q5FkQAIesD4OnksKQ/PmnG9P1GWlN rWsfw+i6tFEgoPakDO9cHSkfRami8kpzc0UY5UU4sQYSymx1CkrVazyud76NipDf eWnXcNay3N6Jty+/jcyRNsUtBoch23ubQv3B3dS4UxORShJ3nOUihAtaQeWRzeFe G+Q1iuLLipDTB/GFOatSoMzHqZSYVfXK/PAWBeePaDz/HaIByGbcln6/b5Lh0pCq caDzS8XBvRYGdm4sFMwXWE8MOYTqQvPZLF4ktXdySTcIyHZbdE/NGH28+wh1zZdK CTKCcTcsk2J9l7C1KS9GasnK7yIl8CE6hn4BwyWut875JuzYwGGxcz/8Ct0gwCW4 Dt7khkMpulH1JgGV5PvzOzkGs/8aeJuIhAceBsrmWCjSZ2Li01nCmDBlcE4AvmsK C/8/LHK8czERkB6xLJBOOm992+1jNiXOXCtec2WIf3C9ARXRrgnnhourbVTbNwuI iIAmSbcZ2XTfmn+zN24r+ZYbtmul6uRYJinAtoNp75X+7wyxDC1mRznIEGGiNpAp N8awukPT5i+7Pw3QeH7ZSt77BEt2EWE8Y23j/JRGyRQsFIBGtbEJGbhx2//zD9LO U1WBf5FksAkq1EeaE4+yc6hOZTjfLzXY2Kj0aUDCJP7TlhvFgIhwd/kYNqpElT5c Eau/Dd2vemVMYZ/L8qZ6 =BCmQ -----END PGP SIGNATURE----- --Apple-Mail=_972EE63D-526A-4597-B21C-1FAFB7F59CDC-- From nobody Fri Mar 18 07:23:23 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68312D8C2; Fri, 18 Mar 2016 07:23:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318142321.5708.78573.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 07:23:21 -0700 From: IETF Secretariat Archived-At: Subject: [urn] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 14:23:21 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ From nobody Fri Mar 18 12:02:39 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DAD12D5AC for ; Fri, 18 Mar 2016 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf_reUwrzI03 for ; Fri, 18 Mar 2016 12:02:27 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2B612D540 for ; Fri, 18 Mar 2016 12:02:16 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1agzf5-000MwD-Pk for urn@ietf.org; Fri, 18 Mar 2016 15:02:15 -0400 Date: Fri, 18 Mar 2016 15:02:10 -0400 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Review comments on 2141bis-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 19:02:39 -0000 Hi. It has now been 3 1/2 weeks since Sean posted his three (or perhaps four, depending on how one counts) sets of review comments on draft-ietf-urnbis-rfc2141bis-urn-15 on 21 February. There has been, AFAICT, one response, from Martin D=C3=BCrst, on = the 22nd, clarifying my earlier comments somewhat and, IMO at least, reinforcing and extending some of Sean's. There were also some comments from Martin on the topic of URNs for media types and related issues, picking up on a thread that started, IIR, on another list. As far as I can tell, that media type thread has no impact on 2141bis although we [1] should perhaps review the examples to be sure that they are clear. I've been silent (except for responses to Cathy Meadows's thread on a quite separate topic) since then. Part of the reason for that is that I wss very busy with some other issues but the more important part is that I've hoped others from the WG would actually comment on the issues involved. There has been no traffic on the list other than that triggered by draft-martin-urn-globus (on which we've been copied for information about new namespace registration requests) since 22 February. Anyone feeling like checking that or otherwise looking at old traffic should see the list archive at=20 https://mailarchive.ietf.org/arch/search/?email_list=3Durn I believe the Globus registration request does raise one issue that should be checked by the WG. I'll post my specific concern about it within a short time after posting this note. I am writing only as an individual participant -- decisions about how or if the WG should proceed would have to come from the co-chairs or AD and the thoughts below are just my perspective.=20 That silence is not a good sign. A reasonable assumption when a draft is posted, there are comments criticizing that draft and claiming that the work should not go forward without those comments being resolved, and there is no response from the rest of the WG is that the WG has run out of energy and no one cares any more. In a way, a debate in which only Sean, myself, and Martin are participating is even worse in terms of assessments of the WG's energy level and ability to reach meaningful consensus about anything. I plan to post responses to Sean's specific comments soon (they were mostly written a few weeks ago but I need to review them to be sure I haven't changed my mind or left significant loose ends). However, I'm not sure that they are even worth the effort if the silence from others is to continue or if, as suggested below, almost no one cares. The comments below are therefore very general and more about the question of how (or if) to proceed than about the details. Based on discussions while 2141bis-14 and -15 were being proposed, I want to offer an alternate hypothesis about the silence that, if true, may suggest some changes in how we go forward. The hypothesis is that, while there may be general agreement that the separation of q-component and r-component is important and that both components are useful, very few people in the WG actually care at this point about how r-components are defined as long as we can move forward. =20 Sean's earlier comments about r-components led us to modify 2141bis (in -15) to provide syntax for an explicit resolverID but to leave details about semantics of r-components and their applicability, resolverID registration, syntax of the string, etc. -- very nearly everything other than that small bit of syntax -- for future work, basically forbidding standards-compliant use of r-components until that work is done. That was intended as a compromise to allow us to move forward. If it is not sufficient, e.g., if a long list of questions starting with the requirements for resolvers to be assigned an ID and the scope of resolverIDs have to be sorted out, answered, and documented, then we have a problem. There may be other possibilities, but I can see the following options: (i) We conclude that those questions are really blocking for the WG. If that is the case, then, unless there is a big infusion of energy from somewhere, we had best just shut down now. To be clear, I don't think that Sean has raised any issues that cannot be resolved; I just see getting them resolved in the current WG as taking a very long time, perhaps years, to reach consensus that we can claim is valid and informed. It could even require some experimental work and documents -- some of the ideas are fairly close to the whatever boundary exists between "research" and "engineering". (ii) We do whatever is needed to move past those questions, postponing them for future work. I don't have a strong option as to whether that would be better facilitated by leaving the text that discusses r-components more or less as it appears in -15 (i.e., including the "resolverID" distinction) or whether it would be better to tear that out and just leave specification of r-components for future work although my intuition tells me that the present arrangement leads to lower risk of serious later interoperability or compatible expansion problems. If we do that, there is an opportunity to create a WG to work on those issues although, if I were an AD evaluating such a request, I'd want to see very strong evidence that there is actually energy to do the work. However, with or without that follow-on WG, we do whatever handwaving is needed in 2141bis, finish up whatever is needed in other respects, and get things to IESG for processing. (iii) We just give up, avoiding having to decide between (i) and (ii). I assume my person preference is clear -- if we can make the decisions implied by (ii), I think I could get -16 out this weekend and we could, at least in principle, wrap things up before the end of the month (and hence before IETF). But the WG (or at least the co-Chairs and AD) need to decide, at least IMO. best, john [1] "We" the WG, not just "we" the editors of 2141bis. From nobody Fri Mar 18 12:04:09 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7912D625 for ; Fri, 18 Mar 2016 12:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddozoexCmsSh for ; Fri, 18 Mar 2016 12:04:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7F812D52E for ; Fri, 18 Mar 2016 12:04:03 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1agzgo-000MwL-BS for urn@ietf.org; Fri, 18 Mar 2016 15:04:02 -0400 Date: Fri, 18 Mar 2016 15:03:57 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 19:04:05 -0000 Hi. This note is prompted by a recent Last Call discussion on the IETF List about a new namespace proposal, draft-martin-urn-globus. Those who are interested in details should have a look at that draft and archives of the IETF discussion list for messages with subject lines containing that string and posted within the last week or so. I don't believe those details are needed to understand what follows. Section 4.3 of RFC 3406 requires that a registration request for a new namespace have a "Namespace Considerations" section that "outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." That requirement was dropped when we folded the registration procedures and requirements into 2141bis and, indeed, was dropped before the posting of the now-obsolete draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 in February 2014 (and probably earlier). That was some time ago. Just to prevent any last-minute surprises, does anyone see a need for a requirement that proposals for new namespaces include consideration of existing ones and why they are not applicable? I note that such a requirement may require significant research, especially as more NIDs are registered, and may not actually be helpful. I assume that is the reason why the requirement was dropped. If anyone does feel that the requirement (or something like it) should be reinstated, I'd appreciate it if they would speak up soon... and that their comment justify the additional costs and explain how whatever claims are made will be evaluated (or not). Sending proposed text would be ideal, but the most important thing, IMO, is to know whether that is an issue that anyone plans to bring up during WG or IETF Last Call. thanks, john From nobody Fri Mar 18 13:23:21 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30212D812 for ; Fri, 18 Mar 2016 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1rvSDD3ckKM for ; Fri, 18 Mar 2016 13:23:18 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E525F12D7AB for ; Fri, 18 Mar 2016 13:23:13 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id o5so66489049iod.2 for ; Fri, 18 Mar 2016 13:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=LrZapVqHL3MY+CPO529ajp4XHlNGCXr5UUXqqfSd1PI=; b=HzERjYSF4x5e1xJIbf/PIYFnFcNZqBcn7R5zG3Mgl/XnEempOY4NASX+fnyejTj0CW vMsS+B85Qa/kQ221+fbBEhP3wi9mZvVqGLomlavXdT1weWET6RJ796cU6lSjhVz0EGvs E5Xr5SAxs7H6pzLBIKYXkjsFPZVjraSJaIi6Rmi5VAcRuVmp3sAPdN3y15NYHeALgwyw fn2XuX7jQxQvOuV3mvMk1ZkaObOUy1lRTmYcMQUb0AUOaiPlZ+YqLZqP0zsrDyl4dN3p 3cnjhNr4p6BV280hA42CoPCWMDxEDkbDrjjCMtq06OOTZ83zEACucV+m8UFkQy29s1Jz PTsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LrZapVqHL3MY+CPO529ajp4XHlNGCXr5UUXqqfSd1PI=; b=TT9VVBb9bs5WWpGC4bYcaARY2cMBhtpTywFxAoX59xFuKL5OTlPOI6gKQjKctKUiuU 3UHT0bfY2jG5DTQpOEzpZWuVJ/c2OeNcx3Vyn9jia45lfZZfaoK9TO2Q/XZyu3BGTEY6 k82SUwx/laH41a8GtOGQxD9cfflEuvqRLM8NkRQSAka7nNRG5OFKQR3p1GHJDdrPodDx eEAVNY6GKlJmSfeqDhSdI1g63AsZiLbXC/7sW/9j2fKqiL0w5WGRyzgQv2RHoVUy+eHv WddC8Cum7KrPiAhPC/Dzk1pelZXwwyHbXYvDIE3jMjIrpHjG/OiSg6fw8HDxOiFrVnZr ZrKQ== X-Gm-Message-State: AD7BkJKJI+W9SkZQ7ZdOMAHuOqo5j5aybbWGxngjZf0xQPPrw1ZaaUFTAlvfAGg2Cxrxjn3dqVh4UNtzqtIE9A== MIME-Version: 1.0 X-Received: by 10.107.134.165 with SMTP id q37mr20114342ioi.41.1458332593139; Fri, 18 Mar 2016 13:23:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.15.139 with HTTP; Fri, 18 Mar 2016 13:23:13 -0700 (PDT) In-Reply-To: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> Date: Fri, 18 Mar 2016 20:23:13 +0000 X-Google-Sender-Auth: uGgi4ptO7t_J0LPubkH76tSVxtQ Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:23:20 -0000 I'll say this as a participant only, but informed by my experience over the last four years as the AD responsible for handling URN NID requests: Essentially all (perhaps exactly all, though I can't remember definitively) NID requests that I've handled over the last four years are from organizations who want namespaces for use by their organizations or industries. It's quite clear that there is little to no value in asking them to document why they need a new namespace: it's because they want one associated with their organization or industry, and that they control. There could be situations where it would be useful to ask the question: if there's already a namespace for, say, naming movies (call it "movie:"), and a film-industry organization asked for one called "film:". We'd definitely want to know why "movie:" doesn't suffice. The problem is that in order for us to ask the question, *we* would have to know that "movie:" exists and seems related, and all the requestor would have to do is to put a boilerplate "we need our own industry namespace that we control" statement in. Unless we notice that they've missed (or intentionally ignored) the related namespace, nothing will be accomplished. I'd support something that said that if there are related namespaces, the request should note them and explain why they are not adequate and this one is different. But I'd not support its being a requirement, because in most cases it's unnecessary and in the others its a requirement that's unlikely to be enforceable. Barry, as participant On Fri, Mar 18, 2016 at 7:03 PM, John C Klensin wrote: > Hi. > > This note is prompted by a recent Last Call discussion on the > IETF List about a new namespace proposal, > draft-martin-urn-globus. Those who are interested in details > should have a look at that draft and archives of the IETF > discussion list for messages with subject lines containing that > string and posted within the last week or so. I don't believe > those details are needed to understand what follows. > > Section 4.3 of RFC 3406 requires that a registration request for > a new namespace have a "Namespace Considerations" section that > > "outlines the perceived need for a new namespace (i.e., > where existing namespaces fall short of the proposer's > requirements)." > > That requirement was dropped when we folded the registration > procedures and requirements into 2141bis and, indeed, was > dropped before the posting of the now-obsolete > draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 in February 2014 (and > probably earlier). > > That was some time ago. Just to prevent any last-minute > surprises, does anyone see a need for a requirement that > proposals for new namespaces include consideration of existing > ones and why they are not applicable? I note that such a > requirement may require significant research, especially as more > NIDs are registered, and may not actually be helpful. I assume > that is the reason why the requirement was dropped. If anyone > does feel that the requirement (or something like it) should be > reinstated, I'd appreciate it if they would speak up soon... and > that their comment justify the additional costs and explain how > whatever claims are made will be evaluated (or not). Sending > proposed text would be ideal, but the most important thing, IMO, > is to know whether that is an issue that anyone plans to bring > up during WG or IETF Last Call. > > thanks, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Mar 18 13:45:09 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A83312D848 for ; Fri, 18 Mar 2016 13:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfQIIvC6klR0 for ; Fri, 18 Mar 2016 13:44:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB4A12D683 for ; Fri, 18 Mar 2016 13:44:57 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ah1GR-000NAU-OT; Fri, 18 Mar 2016 16:44:55 -0400 Date: Fri, 18 Mar 2016 16:44:50 -0400 From: John C Klensin To: Barry Leiba Message-ID: <024D5EA4785AE02CCF7F1695@JcK-HP8200.jck.com> In-Reply-To: References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:45:08 -0000 --On Friday, March 18, 2016 20:23 +0000 Barry Leiba wrote: > I'll say this as a participant only, but informed by my > experience over the last four years as the AD responsible for > handling URN NID requests: > > Essentially all (perhaps exactly all, though I can't remember > definitively) NID requests that I've handled over the last > four years are from organizations who want namespaces for use > by their organizations or industries. It's quite clear that > there is little to no value in asking them to document why > they need a new namespace: it's because they want one > associated with their organization or industry, and that they > control. >... > I'd support something that said that if there are related > namespaces, the request should note them and explain why they > are not adequate and this one is different. But I'd not > support its being a requirement, because in most cases it's > unnecessary and in the others its a requirement that's > unlikely to be enforceable. Thanks. That is certainly consistent with my experience and observations. It would be easy to add a sentence or two to the above effect. I'd personally recommend that we add an entry to the registration template (Appendix A of 2141bis), between "Documentation" and "Revision Information", and say something like "Additional Information. Please include any additional information that would be useful to those trying to understand this registration or its relationship to others, such as comparisons to existing namespaces that might seem to overlap." Better wording would obviously be welcome, as would recommendations as to whether that needs to explicitly include "(Optional)". It is not as strong as "if you know of related namespaces, please explain" or your wording above, but my quick thought is that might be overly-specific and we are better off inviting comments but not trying to specify what is and is not wanted. The people who want to be helpful about other information, including the comparisons, will supply it and the others will just say nothing or, as you suggest, "we just need our own" or "those folks are turkeys". I think that something like the above would deal with this issue and any others that might come along. Does that work for you? Everyone else? john From nobody Fri Mar 18 15:21:04 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403D512D6F0 for ; Fri, 18 Mar 2016 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J91gCnRmwE2V for ; Fri, 18 Mar 2016 15:21:00 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F393D12D692 for ; Fri, 18 Mar 2016 15:20:59 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h65so13289869ywe.0 for ; Fri, 18 Mar 2016 15:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ILMFpcslJYd9eZERz6OOaDpC2/le2V4i4TmL/emUAuw=; b=UdQBFviFkqXqeTRmW1geFvEvJuVjIu6xLRCLV1P1IQjVG03oT4tAzfCneoGTHl4A73 eCQR3seDjd+58ZB47dkgQvJivMyAQR4BcvfS1ZXMomS+DaufC1SnB5DdMGPvFOA3YlMi SIMJnAqg4cbjZ+vquKtKxXODvNfC3PeIU1UgGFwnvrylRl9T2hnLvML5CpAbhjwrnB1Z fpuyOQeziiymxZW0nrrcePoupIvWHNCu+g2wEHsj7FDayM4SHKjPwT9wxu5qF1rY/jMr FDM46O2IHGqDYns7Fx/iuu5mTxVuwyyN6IJ+H27b6ysGiAmnjkRg40lu8+WFPuqOSNm0 hITA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ILMFpcslJYd9eZERz6OOaDpC2/le2V4i4TmL/emUAuw=; b=aXOSRvtoYDJnkhyWnIFXJvYSS+lFBUxBXbYAMziNO3l9i+na2tZUpoc5qFPRC+kmoD XGaFXfThFIpmapU5AP2b0lhsu6imKz0nBj1hhhSsTa23CcU4cIAVsjNXkjZT4+qTrwcu mi4I7fPLmZMD5zLs2sHcycVCT3r/lJxSW2u2ZA9BHp5yNVz82T3641F1+CRW4+WQDHcP rd7oz7VC+dTXBYabHTV3lSxgKZAzU5+EuHzIZeffrvKjYVMCExHAwujrbJHwbZ8uE2q2 JlENhusX5YrRArqE6tP2skaPGDf+/j9/shxiWE6izyPt6zj8LzgT8jVABja5m2ktrd+Y /3sw== X-Gm-Message-State: AD7BkJJrXIAINpDVPodD17abt3u6l8iLiCikBDY2RXmGerF4vCMgZ0FYeDiSf6dFzrsE1IvWq3CFsg/eCErlRw== MIME-Version: 1.0 X-Received: by 10.129.48.77 with SMTP id w74mr9034660yww.147.1458339659251; Fri, 18 Mar 2016 15:20:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Fri, 18 Mar 2016 15:20:59 -0700 (PDT) In-Reply-To: <024D5EA4785AE02CCF7F1695@JcK-HP8200.jck.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <024D5EA4785AE02CCF7F1695@JcK-HP8200.jck.com> Date: Fri, 18 Mar 2016 18:20:59 -0400 X-Google-Sender-Auth: sUOtP6-Ppeje_6-mGPncapumLYw Message-ID: From: Barry Leiba To: John C Klensin Content-Type: multipart/alternative; boundary=001a114084a25a06f5052e5a29fa Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 22:21:02 -0000 --001a114084a25a06f5052e5a29fa Content-Type: text/plain; charset=UTF-8 Works for me, especially in the milder formulation. b On Friday, March 18, 2016, John C Klensin wrote: > > > --On Friday, March 18, 2016 20:23 +0000 Barry Leiba > > wrote: > > > I'll say this as a participant only, but informed by my > > experience over the last four years as the AD responsible for > > handling URN NID requests: > > > > Essentially all (perhaps exactly all, though I can't remember > > definitively) NID requests that I've handled over the last > > four years are from organizations who want namespaces for use > > by their organizations or industries. It's quite clear that > > there is little to no value in asking them to document why > > they need a new namespace: it's because they want one > > associated with their organization or industry, and that they > > control. > >... > > I'd support something that said that if there are related > > namespaces, the request should note them and explain why they > > are not adequate and this one is different. But I'd not > > support its being a requirement, because in most cases it's > > unnecessary and in the others its a requirement that's > > unlikely to be enforceable. > > Thanks. That is certainly consistent with my experience and > observations. It would be easy to add a sentence or two to the > above effect. I'd personally recommend that we add an entry to > the registration template (Appendix A of 2141bis), between > "Documentation" and "Revision Information", and say something > like > > "Additional Information. Please include any additional > information that would be useful to those trying to > understand this registration or its relationship to > others, such as comparisons to existing namespaces that > might seem to overlap." > > Better wording would obviously be welcome, as would > recommendations as to whether that needs to explicitly include > "(Optional)". It is not as strong as "if you know of related > namespaces, please explain" or your wording above, but my quick > thought is that might be overly-specific and we are better off > inviting comments but not trying to specify what is and is not > wanted. The people who want to be helpful about other > information, including the comparisons, will supply it and the > others will just say nothing or, as you suggest, "we just need > our own" or "those folks are turkeys". I think that something > like the above would deal with this issue and any others that > might come along. > > Does that work for you? Everyone else? > > john > > > > > --001a114084a25a06f5052e5a29fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me, especially in the milder formulation.

b
On Friday, March 18, 2016, John C Klensin <john-ietf@jck.com> wrote:


--On Friday, March 18, 2016 20:23 +0000 Barry Leiba
<barryleiba@computer.org> wrote:

> I'll say this as a participant only, but informed by my
> experience over the last four years as the AD responsible for
> handling URN NID requests:
>
> Essentially all (perhaps exactly all, though I can't remember
> definitively) NID requests that I've handled over the last
> four years are from organizations who want namespaces for use
> by their organizations or industries.=C2=A0 It's quite clear that<= br> > there is little to no value in asking them to document why
> they need a new namespace: it's because they want one
> associated with their organization or industry, and that they
> control.
>...
> I'd support something that said that if there are related
> namespaces, the request should note them and explain why they
> are not adequate and this one is different.=C2=A0 But I'd not
> support its being a requirement, because in most cases it's
> unnecessary and in the others its a requirement that's
> unlikely to be enforceable.

Thanks.=C2=A0 That is certainly consistent with my experience and
observations.=C2=A0 It would be easy to add a sentence or two to the
above effect.=C2=A0 I'd personally recommend that we add an entry to the registration template (Appendix A of 2141bis), between
"Documentation" and "Revision Information", and say som= ething
like

=C2=A0"Additional Information.=C2=A0 =C2=A0Please include any addition= al
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information that would be useful to those tryin= g to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 understand this registration or its relationshi= p to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 others, such as comparisons to existing namespa= ces that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 might seem to overlap."

Better wording would obviously be welcome, as would
recommendations as to whether that needs to explicitly include
"(Optional)".=C2=A0 =C2=A0It is not as strong as "if you kno= w of related
namespaces, please explain" or your wording above, but my quick
thought is that might be overly-specific and we are better off
inviting comments but not trying to specify what is and is not
wanted.=C2=A0 The people who want to be helpful about other
information, including the comparisons, will supply it and the
others will just say nothing or, as you suggest, "we just need
our own" or "those folks are turkeys".=C2=A0 =C2=A0I think t= hat something
like the above would deal with this issue and any others that
might come along.

Does that work for you?=C2=A0 Everyone else?

=C2=A0 =C2=A0 =C2=A0 john




--001a114084a25a06f5052e5a29fa-- From nobody Sun Mar 20 22:41:29 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF9512D622 for ; Sun, 20 Mar 2016 22:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNtW1cCdx2jn for ; Sun, 20 Mar 2016 22:41:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D987E12D603 for ; Sun, 20 Mar 2016 22:41:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 859FA20546 for ; Mon, 21 Mar 2016 01:41:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 21 Mar 2016 01:41:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=I2etqlmA7nfFqgN Uf3yq4XdxHpU=; b=p1Q3NEedC69lwMDHo4nXtSTfEYxW8gb+QLFv2Xx83AkLBOU iiZmhfpz0hAjEy6EVU/Kve7SXQTU/0ou9IZBUJo/mkr9t92d33K/14pD3yWhxU4T /S64N3VdEtExpwNXmMoJzk+X5g96DAPmAG0yQIfWsP5wu8ZC96w59rqVNLuo= X-Sasl-enc: z6eu9tYFQflCqzv8SI2v87vpD8bEk275CMQjX3vPecLG 1458538883 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AC2D680183; Mon, 21 Mar 2016 01:41:23 -0400 (EDT) To: urn@ietf.org References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56EF8974.1040308@network-heretics.com> Date: Mon, 21 Mar 2016 01:41:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 05:41:27 -0000 On 03/18/2016 03:03 PM, John C Klensin wrote: > That was some time ago. Just to prevent any last-minute > surprises, does anyone see a need for a requirement that > proposals for new namespaces include consideration of existing > ones and why they are not applicable? It is not a good idea to federate URN space into distinct categories, as this would have the undesirable effect of giving control over naming and perhaps resolution of particular kinds of resources to specific organizations. So the existence of one or more namespaces that are defined for a particular purpose should absolutely not prevent a new namespace being defined with a similar or overlapping purpose. Keith From nobody Mon Mar 21 04:33:43 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9012D74C for ; Mon, 21 Mar 2016 04:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9PAjYMZ88iO for ; Mon, 21 Mar 2016 04:33:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5734E12D53C for ; Mon, 21 Mar 2016 04:33:25 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ahy5L-000Atb-7F; Mon, 21 Mar 2016 07:33:23 -0400 Date: Mon, 21 Mar 2016 07:33:18 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> In-Reply-To: <56EF8974.1040308@network-heretics.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:33:42 -0000 --On Monday, March 21, 2016 01:41 -0400 Keith Moore wrote: > On 03/18/2016 03:03 PM, John C Klensin wrote: >> That was some time ago. Just to prevent any last-minute >> surprises, does anyone see a need for a requirement that >> proposals for new namespaces include consideration of existing >> ones and why they are not applicable? > > It is not a good idea to federate URN space into distinct > categories, as this would have the undesirable effect of > giving control over naming and perhaps resolution of > particular kinds of resources to specific organizations. So > the existence of one or more namespaces that are defined for a > particular purpose should absolutely not prevent a new > namespace being defined with a similar or overlapping purpose. Keith, I don't think even the original requirement, which has been in effect for years, "prevented" registering overlapping namespaces, it just required identifying them and explaining the overlaps. My personal view is that may have been appropriate with the older registration process that attempted to require IETF approval for creating a namespace and, as a side-effect, made overlaps easier to identify, but is not appropriate with the newer, more flexible, and registration-oriented (rather than approval-oriented) approach, so I think our conclusion is the same. I have tentatively added a version of the suggestion from the discussion Barry and I had last week to the working version of -16. In other words, there is now a provision in the registration template for registrants to provide other information of interest including information about overlapping namespaces, but they are under no obligation to do so. best, john From nobody Mon Mar 21 04:45:16 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D012D53C for ; Mon, 21 Mar 2016 04:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI0RjblT05IS for ; Mon, 21 Mar 2016 04:45:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A59A12D50B for ; Mon, 21 Mar 2016 04:45:13 -0700 (PDT) Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3CAC7509B6 for ; Mon, 21 Mar 2016 07:45:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Leonard In-Reply-To: <56EF8974.1040308@network-heretics.com> Date: Mon, 21 Mar 2016 04:45:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0AE8CA93-35DF-40D8-A2EE-A4ECE8E64DCA@seantek.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> To: urn@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:45:14 -0000 > On Mar 20, 2016, at 10:41 PM, Keith Moore = wrote: >=20 > On 03/18/2016 03:03 PM, John C Klensin wrote: >> That was some time ago. Just to prevent any last-minute >> surprises, does anyone see a need for a requirement that >> proposals for new namespaces include consideration of existing >> ones and why they are not applicable? >=20 > It is not a good idea to federate URN space into distinct categories, = as this would have the undesirable effect of giving control over naming = and perhaps resolution of particular kinds of resources to specific = organizations. So the existence of one or more namespaces that are = defined for a particular purpose should absolutely not prevent a new = namespace being defined with a similar or overlapping purpose. This. +1 >=20 > On Mar 18, 2016, at 12:03 PM, John C Klensin = wrote: >=20 >=20 > Section 4.3 of RFC 3406 requires that a registration request for > a new namespace have a "Namespace Considerations" section that >=20 > "outlines the perceived need for a new namespace (i.e., > where existing namespaces fall short of the proposer's > requirements)." >=20 > That requirement was dropped when we folded the registration > procedures and requirements into 2141bis and, indeed, was [...] > does anyone see a need for a requirement that > proposals for new namespaces include consideration of existing > ones and why they are not applicable? I note that such a > requirement may require significant research, especially as more > NIDs are registered, and may not actually be helpful. I assume > that is the reason why the requirement was dropped. Keep it dropped. Simpler and easier are better. Sean From nobody Mon Mar 21 04:59:49 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED812D6A4 for ; Mon, 21 Mar 2016 04:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCqSC9PvfUac for ; Mon, 21 Mar 2016 04:59:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3369712D528 for ; Mon, 21 Mar 2016 04:59:46 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A276F20A81 for ; Mon, 21 Mar 2016 07:59:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 21 Mar 2016 07:59:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=wq1qCQMj4ZCyiSl 2JAJaKE9h89U=; b=RCmU6t5Xag9IyApsFrzs14K3uwkxxYcfGqQ/ok4Nnwsu3hG htdioAs0QzSkr4V8cm8rOPefqrpVG037tC+5X6CWbPKW2By/Qu3cio0CDjh6FnGi UZ73mBofI0jv+bYYbzuCcU+5rLvX1PUXfciuUdww81iK2dnPZYxw0Ec26tAU= X-Sasl-enc: XHSgP18dWJ9mP2ePEaDm3dzZdb8IUFQNxHEzt1dzT1IA 1458561585 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 39CDA6800B4; Mon, 21 Mar 2016 07:59:45 -0400 (EDT) To: John C Klensin , urn@ietf.org References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56EFE222.1040709@network-heretics.com> Date: Mon, 21 Mar 2016 07:59:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:59:47 -0000 On 03/21/2016 07:33 AM, John C Klensin wrote: > > --On Monday, March 21, 2016 01:41 -0400 Keith Moore > wrote: > >> On 03/18/2016 03:03 PM, John C Klensin wrote: >>> That was some time ago. Just to prevent any last-minute >>> surprises, does anyone see a need for a requirement that >>> proposals for new namespaces include consideration of existing >>> ones and why they are not applicable? >> It is not a good idea to federate URN space into distinct >> categories, as this would have the undesirable effect of >> giving control over naming and perhaps resolution of >> particular kinds of resources to specific organizations. So >> the existence of one or more namespaces that are defined for a >> particular purpose should absolutely not prevent a new >> namespace being defined with a similar or overlapping purpose. > Keith, I don't think even the original requirement, which has > been in effect for years, "prevented" registering overlapping > namespaces, it just required identifying them and explaining the > overlaps. My personal view is that may have been appropriate > with the older registration process that attempted to require > IETF approval for creating a namespace and, as a side-effect, > made overlaps easier to identify, but is not appropriate with > the newer, more flexible, and registration-oriented (rather than > approval-oriented) approach, so I think our conclusion is the > same. I think so also. I was somewhat surprised to reach that conclusion. I started out writing that message by expressing my disappointment that there are now so many URN namespaces devoted to very narrow purposes and/or are delegated to organizations that don't exist for the purpose of information dissemination or archiving. I suspect that in the long run this will harm URN persistence and the ability to resolve URNs. So in a way I'd like to see the registration process discourage those registrations. But the original rule clearly did not serve that purpose, and I'm not sure what rule would serve that purpose without creating other problems. (I've never been really comfortable with the registration-oriented rather than approval-oriented fashion that swept IETF a few years ago.) > I have tentatively added a version of the suggestion from the > discussion Barry and I had last week to the working version of > -16. In other words, there is now a provision in the > registration template for registrants to provide other > information of interest including information about overlapping > namespaces, but they are under no obligation to do so. I'm curious - is there any scenario where a registrant would benefit by including such information? Keith From nobody Mon Mar 21 06:46:06 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AFE12D73D for ; Mon, 21 Mar 2016 06:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDls4KdmbLUq for ; Mon, 21 Mar 2016 06:46:04 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8159812D818 for ; Mon, 21 Mar 2016 06:46:02 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o5so125402427iod.2 for ; Mon, 21 Mar 2016 06:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=/YSDqeXPeqvXyaFMrhfxRkl5MqF30THcJMnGZzB/9mg=; b=LIRDEvTTvcmQq5+RVXqg1mAkIaWBA5yCIT5CFbc5Xs03uiYTcbmB4PVGJMXVJh9DYL OlJtnEtDD+gE3CmdX2MfLReRbQAxekN2x+6OOC/F9StWfTH+cS4NsCy2bJro/+7HfOGH Rq8hYnZ7q7Pk7FsqUups4+/NEFSXfFozpu9Fm42cZkGvDXrgaLBFwXdGD7iM7uEFcPet DGKrFxyaCd4pfWDk6kqmUzUSG7qjOwlBdd3xnkSJrqZabziBhXjm026/f83fLtyOrHG8 q1xtanZ9t91XneSyMmHk15SwLsT1WSOhGoEcPxvb4LQfmWpjCFEKDc9iTnPIB9F012Wm RJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/YSDqeXPeqvXyaFMrhfxRkl5MqF30THcJMnGZzB/9mg=; b=LFipGCzK3HiidriySL/UBf37RBe2BWE2Y633Vw7MmoDXVHYxW5apln/mPb7rpm2lcu gl95fEuHrMWyQIqtH3fONNaIhKUG9+WZVx1FirnLOazm3b7AoEvAeORVDW+4i+eo3f4l YfOaLJNCnnVXdIsvzaR0rfOMQbCecOX/6m8LOmh/g14u+Rg79IvoveW4MiCGP4tXDvNB uQAF9cVTyQUA8TVCCN3frFNkw8rtSRN7c+Jc9K9D2EVytZkQYXpZqyhWbCgC7vXU1Ed7 DuwA5uSq7/HOvkSD+ilTm4YO61E7UuyHw9/58Mfqplzw+b3mF/kBx9ztjUsn3QUDV9v0 eVaQ== X-Gm-Message-State: AD7BkJLKCvo10iMJXBHEB/bAFalEZeaCpr+rNaWNza9asXTmq5vbukXaB1ZCBUpQiTiiPVc6ziyfwqqQ3FE7pw== MIME-Version: 1.0 X-Received: by 10.107.12.207 with SMTP id 76mr29788129iom.70.1458567961841; Mon, 21 Mar 2016 06:46:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.15.139 with HTTP; Mon, 21 Mar 2016 06:46:01 -0700 (PDT) In-Reply-To: <56EFE222.1040709@network-heretics.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> <56EFE222.1040709@network-heretics.com> Date: Mon, 21 Mar 2016 06:46:01 -0700 X-Google-Sender-Auth: aDzdEhTY-8G_COk2kUdTJKZ0XsM Message-ID: From: Barry Leiba To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 13:46:05 -0000 > started out writing that message by expressing my disappointment that there > are now so many URN namespaces devoted to very narrow purposes and/or are > delegated to organizations that don't exist for the purpose of information > dissemination or archiving. I suspect that in the long run this will harm > URN persistence and the ability to resolve URNs. So in a way I'd like to > see the registration process discourage those registrations. Actually, I think it's better to have those sorts of URNs corralled off into their own namespace, so one could say, "Yeah, 'urn:flarb:' isn't a reliable namespace because the Flarb organization is flakey about how they manage their URNs." I think that's better than having their stuff mixed in with other stuff in a more general namespace. I also think that discouraging registrations will simply have the effect that organizations will use namespaces without registering them. Saying that Flarb can't register their namespace because they don't have a good plan for handing out persistent URNs isn't going to stop Flarb from using urn:flarb:, if that's what they really want to do. >> I have tentatively added a version of the suggestion from the >> discussion Barry and I had last week to the working version of >> -16. In other words, there is now a provision in the >> registration template for registrants to provide other >> information of interest including information about overlapping >> namespaces, but they are under no obligation to do so. > > I'm curious - is there any scenario where a registrant would benefit by > including such information? Good point... I think it would slightly benefit them by heading off questions that might come up when the registration request is in review. But that's all I can think of. Barry From nobody Mon Mar 21 08:23:16 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D217512D681 for ; Mon, 21 Mar 2016 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3piedgMylbJM for ; Mon, 21 Mar 2016 08:23:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED48B12D849 for ; Mon, 21 Mar 2016 08:23:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8CDE0208D1 for ; Mon, 21 Mar 2016 11:23:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 21 Mar 2016 11:23:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sWmrReffvGLDqc6 6glNyKesF3ZM=; b=R6DX1RM12ZdkR+6csqYNCESU73VpoHazwPvNkmm7Ftu1RFT NA9r8SwhwzOAKvlo0HKOm7subwN/0n6Utp3VPcMzHjZ7N7jU4jxaCa5Jgs7//C4H r6ZnJxZqx2n0TqBWrvmsB5EwHuR3kERHE/ZOdQrk8TeRHXyPmDlx84IV9HF8= X-Sasl-enc: LTdS8XImpcyPJ6n+x6mgfb49RXb0ouHrUY+iYFXt7y+c 1458573789 Received: from [21.24.107.182] (unknown [66.87.79.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C0FC68011A; Mon, 21 Mar 2016 11:23:09 -0400 (EDT) References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> <56EFE222.1040709@network-heretics.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <16E4C509-83BE-469D-AB65-BFC721752A89@network-heretics.com> X-Mailer: iPhone Mail (12F70) From: Keith Moore Date: Mon, 21 Mar 2016 11:23:06 -0400 To: Barry Leiba Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:23:13 -0000 Sent from my iPhone On Mar 21, 2016, at 9:46 AM, Barry Leiba wrote: >> started out writing that message by expressing my disappointment that the= re >> are now so many URN namespaces devoted to very narrow purposes and/or are= >> delegated to organizations that don't exist for the purpose of informatio= n >> dissemination or archiving. I suspect that in the long run this will ha= rm >> URN persistence and the ability to resolve URNs. So in a way I'd like t= o >> see the registration process discourage those registrations. >=20 > Actually, I think it's better to have those sorts of URNs corralled > off into their own namespace, so one could say, "Yeah, 'urn:flarb:' > isn't a reliable namespace because the Flarb organization is flakey > about how they manage their URNs." I think that's better than having > their stuff mixed in with other stuff in a more general namespace. I disagree, and I think this is a fairly fundamental misunderstanding of URN= s. URN namespaces aren't like URI prefixes. The fundamental URN properties= like persistence aren't supposed to be dependent on the namespace at all. =20= >=20 > I also think that discouraging registrations will simply have the > effect that organizations will use namespaces without registering > them. =20 Well, that has certainly happened. Vendors' willingness to violate or ign= ore published specifications never ceases to amaze me . Though I have yet t= o see evidence that registration is actually the barrier or that making regi= strations easier actually helps. =20 > Saying that Flarb can't register their namespace because they > don't have a good plan for handing out persistent URNs isn't going to > stop Flarb from using urn:flarb:, if that's what they really want to > do. Right, but we should not legitimize the practice by declaring such a namespa= ce to be valid. >=20 >>> I have tentatively added a version of the suggestion from the >>> discussion Barry and I had last week to the working version of >>> -16. In other words, there is now a provision in the >>> registration template for registrants to provide other >>> information of interest including information about overlapping >>> namespaces, but they are under no obligation to do so. >>=20 >> I'm curious - is there any scenario where a registrant would benefit by >> including such information? >=20 > Good point... > I think it would slightly benefit them by heading off questions that > might come up when the registration request is in review. But that's > all I can think of. >=20 > Barry From nobody Mon Mar 21 08:28:36 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B712512D8AE for ; Mon, 21 Mar 2016 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex2fzsdBI0a9 for ; Mon, 21 Mar 2016 08:28:33 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6C412D88C for ; Mon, 21 Mar 2016 08:28:33 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g127so218878938ywf.2 for ; Mon, 21 Mar 2016 08:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=gNmQjmiAicbqJnzL1BpBFJC9z6k6jctjVITzkNnVVvM=; b=HMy0CD6IVD4OwVhDLMttOcueJyCl3dapQ22IBIGK82kXtfosLcWjI6nMIfexznnMbR zE/lNBQev2X2Xtno8SNKVxavmI8x+jYw1WtV142vXfx0nN4R31ZZzvduQ5QX8D7Iu586 m3GhRIObZI+lo6/X9I7jDHwCMnBsQ5GGmnpa3qZQZMimlkFkc4e3fu86i37sFxgA8HH8 NSz5ywFw7Gmz1gi/Iy7gXR3FAQ8hNOTmMqX9d2YyjI8EBK3h5PrbrxalZUzVvsQFu8Ad Ov4n3WFiAlYGuumtd3HkX0zOEiZGkHLRP9Y9qqBar2TST4oISodJEPBC+y/1AXsNtALM yQ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gNmQjmiAicbqJnzL1BpBFJC9z6k6jctjVITzkNnVVvM=; b=a2+AVCNfdGtXu6tJUUSu/uLMSv0UU0b7tvjMyv4muPc83bbh68r6suaQ7TuBRs3zVw MqhE6CMjKE7nIKNLofm3memtMMgJKzGD/QIGCcbrZR9MQGZ3aeUiMXGzVGl1Qi0naQn6 as49AWMLl5zkptKMYSWRs8MD3yrpLN5Ha2oC47NSztyhLATu0wjeHeQLHG8vLaEcbTA4 9l7t29gXAWRCwjrl+EdQxoNCHJlQBsx82mjl2ba53eP9xDECAiJzLGFUw68DNSeN2R2u xfso5ePOk5cinWpwH9BnePLowYeBUIPkXM6ba81aSgQabGTulpylHxMdxHiNibxEUqjL H5PA== X-Gm-Message-State: AD7BkJKskT3vywhu/GdkDlVxcz+hjLcn/4Jd0KQJM6YWJPr4cM0FO4arnybDu7Z+0UTiFOhOFNHwjGqoobJQDQ== MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr13482499ywx.176.1458574112449; Mon, 21 Mar 2016 08:28:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Mon, 21 Mar 2016 08:28:32 -0700 (PDT) In-Reply-To: <16E4C509-83BE-469D-AB65-BFC721752A89@network-heretics.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> <56EFE222.1040709@network-heretics.com> <16E4C509-83BE-469D-AB65-BFC721752A89@network-heretics.com> Date: Mon, 21 Mar 2016 08:28:32 -0700 X-Google-Sender-Auth: u48rQaXzTtMfMI4xFMHs3fym2uE Message-ID: From: Barry Leiba To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:28:34 -0000 >> Actually, I think it's better to have those sorts of URNs corralled >> off into their own namespace, so one could say, "Yeah, 'urn:flarb:' >> isn't a reliable namespace because the Flarb organization is flakey >> about how they manage their URNs." I think that's better than having >> their stuff mixed in with other stuff in a more general namespace. > > I disagree, and I think this is a fairly fundamental misunderstanding of > URNs. URN namespaces aren't like URI prefixes. The fundamental > URN properties like persistence aren't supposed to be dependent on > the namespace at all. I'm not suggesting that they are or should be. I'm merely saying that *if* an organization is going to be bad about the persistence (for example) of its URNs, it's better to have that problem isolated to a readily identifiable subset than to have it scattered around and mixed with URNs that do what they're supposed to do. b From nobody Mon Mar 21 09:53:21 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93D312D913 for ; Mon, 21 Mar 2016 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPJvZfIIsoNz for ; Mon, 21 Mar 2016 09:53:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CBF12D8F1 for ; Mon, 21 Mar 2016 09:53:19 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ai34v-000CU9-9H; Mon, 21 Mar 2016 12:53:17 -0400 Date: Mon, 21 Mar 2016 12:53:12 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <06C56A227DA83E57B5D180D6@JcK-HP8200.jck.com> In-Reply-To: <56EFE222.1040709@network-heretics.com> References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <56EF8974.1040308@network-heretics.com> <303E97E085AA1CF66C9CC27E@JcK-HP8200.jck.com> <56EFE222.1040709@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:53:20 -0000 --On Monday, March 21, 2016 07:59 -0400 Keith Moore wrote: >> I have tentatively added a version of the suggestion from the >> discussion Barry and I had last week to the working version of >> -16. In other words, there is now a provision in the >> registration template for registrants to provide other >> information of interest including information about >> overlapping namespaces, but they are under no obligation to >> do so. > > I'm curious - is there any scenario where a registrant would > benefit by including such information? Two answers. The more important one is that, if a registrant wants to supply that information, I think we should let them. If they don't, I don't want to lose sleep over it. That is, I think, consistent with Barry's comment about making this optional. The other, less likely IMO but plausible, is when registrant X comes along and wants to register namespace foobis because, in their opinion, registrant Y, the registrant for foo, has not been sufficiently diligent about persistence or how excluded things things that Y believes should be included and they have been unable to resolve that disagreement. I hope everyone could behave like adults (and that we may have issues to deal with in the future if they don't), but allowing a "this is just like that except..." statement seems to me to be in everyone's best interests. And, fwiw, --On Monday, March 21, 2016 11:23 -0400 Keith Moore wrote: > I disagree, and I think this is a fairly fundamental > misunderstanding of URNs. URN namespaces aren't like URI > prefixes. The fundamental URN properties like persistence > aren't supposed to be dependent on the namespace at all. Unfortunately, once we tried to get down to defining "persistence" in a way that could be incorporated into a document and that was actionable in considering namespace registration applications, we completely failed to reach any sort of consensus. So it is nice as a concept, I think I know it when I see it and assume you do too but that we might not identify exactly the same things. So, sure, "all URNs are persistent" is a great statement. It may even be a definitional tautology. But I'm not sure what it actually does for us, especially in the quest to get this WG's work wrapped up and out the virtual door. best, john From nobody Mon Mar 21 16:53:53 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9012D138 for ; Mon, 21 Mar 2016 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.574 X-Spam-Level: X-Spam-Status: No, score=0.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URI_OBFU_WWW=2.475] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-xcJmQMf_Oo for ; Mon, 21 Mar 2016 16:53:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557E612D10B for ; Mon, 21 Mar 2016 16:53:50 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ai9dt-000GUd-65; Mon, 21 Mar 2016 19:53:49 -0400 Date: Mon, 21 Mar 2016 19:53:44 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <56CA2F42.7090802@seantek.com> References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2F42.7090802@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Embedded characters in the r-component (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:53:52 -0000 --On Sunday, February 21, 2016 13:42 -0800 Sean Leonard wrote: >> The other issue is what we actually mean by "embedding", and >> is a more complex question. So far, the WG has believed that >> simply delimiting the two substrings is sufficient. However, >> if we need to specify that any appearances of "?", or "?=" >> or, most particularly, "?+" in those strings must be >> %-encoded and then that the URN-parser needs to be able to >> decode one level of %-encoding before putting the contents of >> the q-component into a URL as a , it seems to me that >> is easily accomplished in terms of the document and not a big >> deal for a URN-parser/evaluator. > > Ok well here we have a substantive difference, that I hope we > can tease out. I note (again) that the number of people in the WG who have responded to this part of your suggest is, AFAICT, zero. I am violently opposed to having my text prevail simply because there is only one objection, so let's indeed try to tease things out a bit. > I am not sure that "So far, the WG has believed that simply > delimiting the two substrings is sufficient." Some in the WG > have said this (references, please?); my position is that > delimiting is not sufficient. Ok. I have been drawing some inferences from silence, which is always a dangerous business. On the other hand, the alternative to proposing something specific in the draft and notes to the list appears to be to do nothing until a healthy discussion in the WG emerges, something that, for these issues, takes either a long time or considerable stimulation. Waiting for a discussion obviously does not work either, especially since there is some small evidence that the long silences and inability to resolve issues --issues that some participants are unconvinced that they should care about-- are driving people away. > As you pointed out: if you > delimit them with ?= ?+ etc., you must also %-encode the > constituent parts. This means multiple levels of %-encoding, > since % encoded characters will themselves get % encoded to > %25. Yep. As I read it, that is what 3986 requires if those sequences are used inside the component strings. I can't tell you what I think about the requirement in polite language, except that it is a logical and, IMO, inevitable consequence of other parts of the 3986 definition, but, unless I've missed something important, it is the requirement. Do note, however, that 2141bis-15 says that the question mark can be used without percent-encoding inside q-component and r-components. The termination condition is one of the two-character sequences, not a bare "?" or one followed immediately by anything else. I had hoped that was clear from the syntax and discussion in Section 2 of -15; if it is not, I'd appreciate pointers and suggestions. So the scope of "must %-encode the constituent parts" really applies only to embedded "?=" in the r-component and "?+" in the q-component. Again, if that is not clear, please identify where and make suggestions. I don't think it is a major issue, but I'd appreciate comments from anyone who has thought deeply about %-encoding whether, given those two-character sequences, we would be better off with a specific requirement to represent "?+" embedded in an r-component as %3F%3D (and similarly for q-component and "?=") or whether we should just leave well enough (and 3986) alone since %-encoding either "?" or "+" would break up the parsing. > History has shown that double-encoding things is a security > disaster. There is a whole class of security vulnerabilities > where implementations fail to properly double-encode or > double-decode things. Furthermore, it's just not readable. > People are going to transcribe these things by-hand too, > especially for library things. Yep. And double-encoding thing is also an implementation disaster and a pain in various sensitive parts of the anatomy independent of the security issues. >> It would add a bit to the confusion we >> already have with IRIs and where %-encoding is required and >> optional, but not very much. So, while I think we need to >> straighten out whether that encoding requirement is needed, I >> don't see the problem as anything near "unworkable". > > If it is conceded that an additional layer of %-encoding is > required by using ?= and ?+ delimiters (because, as I just > said, a malicious or otherwise specially crafted q-component > could contain ?+ thus switching the URN parser into > r-component-parsing mode), then one also concedes the point > that the current draft-15 text--which makes no mention of > additional %-encoding--is "unworkable". First, I'm not entirely sure I understand the security threat model associated with "switching... into r-component-parsing mode". It seems to me that there are a huge number of ways in which doing something mildly funky to a URI can cause unanticipated behavior and even provide the basis for an attack. I discovered a link on an IETF web page this morning that was equivalent to www/example.com rather than www.example.com. When that link was clicked (because IETF web pages are trustworthy, right?) my trusty web browser promptly routed me to http://www.com/A.B.C.D where A.B.C.D are the IP address of the machine from which I issued the query. That is apparently a site where one does not want to end up, especially by accident and with Javascript and cookies enabled, with or without the privacy issues of fully exposing an IP address. We also see examples equivalent to http://www.good-site.com.really-evil-site.example/ with great regularity, often as the first part of really long and complex URLs. I can understand the desire to avoid adding to the mess but, if the community doesn't take either of those examples seriously, I have trouble getting excited about some possible problems with "?+", if only because the two examples above are a lot easier for a bad guy to construct. In any event, perhaps I am not understanding your point, but I don't think "?+" and "?=" introduce a new problems, partially because even the idea of using "?" and "??" either requires some arbitrary limits on characters that can be used or requires double-encoding. One can argue that, in practice, some approaches will require more double-encoding than others, but that is speculative. More broadly, if anything that contain or requires double-encoding is "unworkable" or worse, the problem lies with 3986, not 2141bis. Stepping back a bit, I suggest the only easy and completely clean way to deal with these issues would be to have a single-character introducer for r-component and a single-character introducer for q-component, with those two characters being unique wrt each other and anything else with a potential special meaning in URIs. If one could do that, then we could cleanly adopt the one-level model of 3986 and define the two components as starting with (or after) the relevant delimiter and continuing to the next relevant (one-character) delimiter (the other component delimiter, "#", or the end of the string). There was a search for such characters and, unfortunately, 3986 uses or reserves all of them. The conclusion from that search and the subsequent discussion was that any creative use of other, single, characters would violate 3986 (btw, staying out of the way of 3968 is also part of the argument for restricting resolverIDs to LDH). IIR, we hadn't gotten to the q-component / r-component distinction yet, but those sorts of constraints were a key reason why we proposed separating URNs from 3986 entirely, an idea that went down in flames. After several rounds of the "what are the delimiters and which comes first" discussion, Andy concluded that the WG had concluded that two-character introducer sequences were the way to go and delegated the choice of characters to be used following "?" to the document editors. Unless I've misunderstood something, you are reopening that argument. I'm not sure I see anything new in your note, but leave that question to the WG co-chairs. >... > To be clear, ? in q-components is foreseeable...in that > q-component = any URI query, so ? can appear in the wild. > I.e., it will appear, especially in deliberately crafted > payloads. Yep. But see above about the absence of any requirement to encode "?" in q-components unless it is followed immediately by "+". > We have control however over r-component, by prohibiting ? or > mandating that ? be %-encoded as %3F. (These are tantamount to > the same thing.) There are lots of other delim characters that > can be imbued with reserved purposes, within an r-component > production. Actually, based on the conclusions of people who have stared even harder at 3986 than I have, "lots of other delim characters..." is, at best, a significant exaggeration. The options are _very_ restricted. My concern, in part connected to the question of whether the choice of resolvers can be used to select what information is returned, rather than only how and maybe where it is looked up, is that people could easily discover they have a need for (deliberately avoiding mashing this into URI/URN syntax or suggesting delimiter structure). urn:ietf:rfc:9999 q-component= "format=pdf" #section 4.1 r-component= "urnresolver.ietf.org?contents='congestion failures'" using the above with the intent of retrieving a copy of the document in PDF, but only those sections that discuss (or contain the string) "congestion failures", and then only the subset of those sections identified as "section 4.1". A little far-fetched, but not very far from some of the ways people have suggested using q-components, r-components, and fragments in combination. And, of course, barring something more ingenious than the WG has been able to come up with so far, that r-component -- which contains a "3986-query"-style instruction to the resolver about what to return-- requires an embedded "?" but not one that is required to be %-encoded. One could require a different syntax to express the same thing, but, IMO, that takes us further into the problem of specifying something rather precisely for which I believe the WG has shown it doesn't want to deal. My recommendation is, again, to take all of that out, relying on 3986 and the two-character starting and ending delimiters. best, john From nobody Mon Mar 21 17:00:00 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3812D183 for ; Mon, 21 Mar 2016 16:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXEo8K4mFEOR for ; Mon, 21 Mar 2016 16:59:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238FB12D55A for ; Mon, 21 Mar 2016 16:59:57 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ai9jo-000GX6-2S; Mon, 21 Mar 2016 19:59:56 -0400 Date: Mon, 21 Mar 2016 19:59:51 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] r-component namespace independence (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:59:59 -0000 (trying to extract the important bits from your note and Martin's and handle your three separate sets of remarks separately, but people may need to go back and look at the original notes to find enough context) --On Sunday, February 21, 2016 13:04 -0800 Sean Leonard wrote: >... =20 >>> From that view, it follows that r-component is >>> namespace-independent, in the sense that the maintainers of >>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a >>> stab at their own spins on the resolverID "foo" or "info" or >>> "abcdefg". The namespaces of "resolverID" and therefore >>> r-components more generally are global and orthogonal to the >>> NID / NSS part. >> I hope that is consistent with what the text says. However, >> the intent of the text was that maintainers of particular >> namespaces _do_ get to specify what resolverIDs are used with >> them, just not how a given resolverID that they intend to >> permit is interpreted. >=20 > I am confused with these two statements/positions and do not > see how to separate them. Yes, I agree, it is confusing and I was confused. However... > I think an example from you would be very helpful. >=20 > As you wrote: "maintainers of particular namespaces [get] to > specify what resolverIDs are used with them". And: namespace > maintainers do not get to specify "how a given resolverID that > they intend to permit is interpreted". >=20 > So the maintainer of urn:isbn can say the resolverID "info" > can be used, and "get" cannot be used. The maintainer of > urn:oid can say the resolverID "info" can be used, and "get" > can also be used. > But why do they say some resolverIDs can be used or not, when > they have no way to promulgate what it means? And, again, no way to predict the future. =20 > It is like saying: "You can use the number 6 in this protocol, > but not the number 7. Oh, but you can do whatever you want > when you receive a 6." For better or worse, we have done that a lot in IETF protocols. I don't think that is helpful for this case. See below. >... > I actually do not care whether the resolverID is > namespace-dependent or namespace-independent. As I have > pointed out, a resolver receives both the resolverID and the > NID (plus the NSS, of course), so at the level of resolver > behavior, the behavior will always be namespace-dependent > because it depends on the identity of the thing being named. Yes. That is part of what I was trying to get at. I think some people has suggested otherwise, that they want resolver definitions and resolvers that are completely namespace-independent with no dependency on the rest of the URN. What they want may or may not be possible, but that is a separate issue; see below and my base note today. > Right now the specification equivocates because sometimes it > says independent and sometimes it says dependent. That is a > problem. Yes. As discussed in the base note, I think the best solution right now is to pull all of that text out. > Upon reasoning it through, my position was: >=20 > "people writing durable, universal naming > schemes should not be required to be in the business > (directly) of dictating what resolution services get developed > or not, and vice-versa. I.e., the URN namespace registration > template should not require new URN namespaces to specify a > set of resolution ops." Ok. =20 > This is based on making it easier to register URNs. If > resolverIDs (resolver operations) are namespace-dependent, we > must expect the URN registration template to define resolution > a lot better. That is more work. And it may change over time > based on different parties' needs. Ok. And that is actually persuasive for me. =20 >...=20 --On Monday, February 22, 2016 14:21 +0900 "Martin J. = D=C3=BCrst" wrote: >> This is based on making it easier to register URNs. If >> resolverIDs (resolver operations) are namespace-dependent, we >> must expect the URN registration template to define >> resolution a lot better. That is more work. And it may change >> over time based on different parties' needs. >=20 > I guess I'm with Sean here. Sean maybe implied this, but I > didn't see it stated explicitly: It would make introduction of > new resolution services (which might perfectly well be able to > deal with preexisting URN namespaces) a lot more difficult. We > don't have any magic to update specs or registrations > automatically. >=20 > So at the most, I'd want to limit us to something like > "Namespace registrations MAY indicate some of the types of > resolvers suitable for the namespace (by listing the relevant > resolverIDs). Such a list does not restrict the use of > resolvers to only the listed types." After reviewing all of the comments and reviewing the document again, I think even that is too much. I think we need to say nothing more than "reserved for future standardization" because the above leads into its own set of issues that would need to be resolved. There is an interesting question about what to do about the registration template -- see base note.=20 At this point, I see the best way to resolve the issues being to pull all of the text out and leave r-components for future standardization. In other words, I think the conclusion from the above (and other things) is to tear any text that attempts to explain the status and evaluation of r-components out. I don't know whether it is worth trying to preserve the two-part syntax idea (i.e., separation of resolverID from the rest) or whether that should be dropped as well. Again, see base note. john From nobody Mon Mar 21 17:13:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC5812D59D for ; Mon, 21 Mar 2016 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJzmOBrRmywo for ; Mon, 21 Mar 2016 17:13:49 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C1E12D1E5 for ; Mon, 21 Mar 2016 17:13:48 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ai9xD-000GZc-JS; Mon, 21 Mar 2016 20:13:47 -0400 Date: Mon, 21 Mar 2016 20:13:42 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <56CA2A98.4010606@seantek.com> References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2A98.4010606@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] r-component syntax (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:13:51 -0000 --On Sunday, February 21, 2016 13:22 -0800 Sean Leonard wrote: >> a discussion, one that is active and focused enough >> to not hold us up for months debating a few characters for >> which there is no demonstrated need beyond "we could...". In >> defense of that position, I think we should remember that it >> is much easier to add (allow) a previously-prohibited >> character if it turns out to be necessary than it is to >> delete one that turns out to be a problem. > > As an implementer, that is not my position. It is one thing to > say that a character is "RESERVED"--it's another thing > entirely to prohibit it in the ABNF. > > Once this thing gets published, people will write code that > implements the ABNF. You can't add characters so easily. > > The limitation of resolverID to LDH is arbitrary and (as far > as I can tell, since the discussion has come up) capricious. > You could say "we could limit it", but you could also easily > say "we could expand it". Up until now the set of characters > has not gotten much airplay. Of course it is both arbitrary and capricious. I think I actually said that on-list. I also asked for comments and specific suggestions and got nothing. The choice between leaving something out of the ABNF and explicitly reserving it is one we've made in different ways in different IETF protocols over the years. I think it is safe to say that neither has worked really well, at least in part because different implementers have understood that what they can do differently. That, in turn, is rooted in the notion that some behavior (including either using a reserved character or using a character that is not covered by the ABNF) is simply "outside the standard", a concept that a number of documents, including the famous RFC 2119, seem to be a little closer than they are to identifying implementations as "non-conforming" in those sorts of cases. FWIW, 3986 follows one model and 5321 follows that other. Opinions differ as to which type of definition has been more successful. > If you want to stuff more in the resolverID production than > LDH, the only way to do it based on the current ABNF in > draft-15 is Punycode, just like DNS. Certainly not the only way, and the specific use of the Punycode algorithm would be a disaster, in part because of other assumptions it makes. Use of an ACE would be feasible although certainly not what I would recommend. Use of %-encoding works too and, AFAICT, 3986 makes it impossible to prohibit (whatever you (or I) think of that encoding). However the more important point is the prohibition was deliberate as was borrowing the RHS from the NID production. Putting actual characters outside the ASCII range (i.e., octets with the high-order bit non-zero) into URNs generally would (again intentionally and, for resolverID, paralleling NID) require a change in the standard. If one goes with restrictive ABNF, them the change is to extend the ABNF. If one goes with some "reserved" construction, then the change is to allow the reserved characters. With one exception, I don't seem much difference there _except_ that the RESERVED approach, depending on how it is written up, probably also requires changes to 3989 because, again, AFAICT, 3986 prohibits _any_ non-ASCII character except in encoded form. FWIW, I believe that the WG reached the conclusion that we didn't want to touch the URI/IRI debate or explicitly incorporate URNs into the IRI space. I think the current structure in the text reflects that conclusion. I also note a pragmatic problem: if we want to open up what I guess would be called IRNs, it would be hard to write the text and be consistent with other URI/IRI work without a normative reference to RFC 3987. However, 3987 is obsolete, not in the sense of formal IETF action, but because the action has shifted to W3C. It is not clear that the state of the work there would meet IETF requirements for normative references from standards-track specs. Simply sorting that out could take months. Absent clear requirements anchored in real needs to deal with the problem of URNs containing non-ASCII characters in non-encoded form (ACE, %, or otherwise), I don't think the delay is acceptable. Now the ASCII non-LDH characters are another matter, but we have applied that restriction to more flavors of identifier than I know how to count, including notably (and as mentioned above and below) the NID itself. If there is an important case to be made for allowing a wider range of syntax in the resolverID than in the NID, I don't think you have made it yet (arguing for non-ASCII names is another matter, but most of those arguments would also apply to the NID). Otherwise, I'd recommend that we just move on or, if specifying a resolverID requires resolving (sic) this and it is actually controversial in the WG, pulling that syntax distinction out of r-component and leaving it all for future standardization. > Keep it expansive. If you want you can add a note to the > effect of, "resolverID is supposed to be limited to LDH, other > characters are RESERVED or may have RESERVED purposes in other > specifications." (I do not advocate for this position, but I > am pointing out how to do it correctly, rather than put the > limit in the ABNF. Note that is how RFC 2141 dealt with the > issue of characters such as "?" and "#".) See above. Also note that the way RFC 2141 dealt with those characters caused us months of debate about whether URNs could be extended at all and about whether there were non-conforming cases (in which those characters had been used in some way) for which we needed to make allowances. >>> ... >>> Since we are defining resolverID, the momentum is sufficient >>> to structure the syntax of the other part. Although I am not >>> combing through the history of the mailing list, I believe a >>> handful of voices called for name/value pairs, and nobody >>> strenuously objected. >> Again, I believe the WG explicitly decided to not do this, > > My recollection is that there were calls for the structure of > name/value pairs that got a lot of serious consideration. If > we can agree on name/value pairs then we will make serious > technical progress. Having first introduced the idea of structuring things around, and requiring, name-value pairs (before the q-component/ r-component separation), I just can't recommend going there, or otherwise trying to structure the syntax of the string, at this stage. I still think name-value pairs would be a good idea for r-component (even if not for q-component) but I just don't see enough energy in the WG to work through the details, decide what needs to be registered and how, sort out permitted characters, etc. At this point, I think the most we can sensibly do is to be sure that reasonable and plausible name-value constructions are not forbidden. What you see as "serious technical progress" is what I see as an opportunity to fuss for months on an issue that is not in the WG's critical path and for which we have little actual experience. Those two views can be held at the same time -- i.e., they are not inherently contradictory -- but I believe the WG's marching orders are to get finished with 2141bis and the documents closely linked to it and to avoid being distracted by issues that are not absolutely necessary to it. In case it isn't clear, that is an expression of agreement with Peter's and Leslie's conclusion in https://mailarchive.ietf.org/arch/msg/urn/78hKQSNHvlBx1RJnPUOczkykkFs -- this needs to be considered far out of scope if we are going to get finished. > The discussion faltered on a *registry* of r-component > name/value pairs, but that was about reserving specific names, > not about the syntactic structure. But Keith's note at https://mailarchive.ietf.org/arch/msg/urn/cOq7rl_zd4pCPdZ-kpLm-ujBvoM suggests that we need "name" as well as "name=value". Again, I don't necessarily disagree, just see a need to route the WG's critical path around this, at least if we would like to finish 2141bis any time soon. john From nobody Mon Mar 21 17:21:25 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1166812D1DC for ; Mon, 21 Mar 2016 17:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4sAifEEye-N for ; Mon, 21 Mar 2016 17:21:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60A912D19E for ; Mon, 21 Mar 2016 17:21:20 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aiA4V-000Gag-Tz; Mon, 21 Mar 2016 20:21:19 -0400 Date: Mon, 21 Mar 2016 20:21:14 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] General r-component issues (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component_ X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:21:23 -0000 (Sorry -- tried sending this from the wrong address, so it is arriving last in the group of four, not first as intended) Sean, I've gone through your 21 February notes, and Martin's response, multiple times, written text each time, and then put that text aside. I did it again Friday and Saturday. I'm going to comment on some of the issues you raise in drastically revised and refocused separate notes, but I think there is a higher-level conclusion on which we need to focus (i.e., people who want to capture the essence of what I have to say and suggest without getting into the details can probably skip the other three notes especially if their main objective is finishing up as soon as possible; those who feel passionately about r-components should probably read all four). My conclusion is close to one that I believe we reached many weeks ago, perhaps even before your note proposing what I abstracted as resolver IDs, which is that the WG simply did not have the energy to pin resolvers and resolver mechanisms down. Given time, I'd personally enjoy working on some of the issues with you, but I just cannot see any hope of doing so successfully within the context of the present Working Group, its charter, and its long-overdue schedule. =20 Now it may be that implies that I (or the WG, because it was mentioned on the list) made a mistake in trying to take a baby step in defining the r-component syntax as containing a resolver-ID and a string. If trying to push the boundary even that far simply exposes a family of other issues that we feel a need to resolve in order to make progress, then it is probably more desirable to simply pull that syntax out of 2141bis and treat the entire r-component as opaque (modulo a restriction on occurrence of terminating strings without encoding; see below) until and unless other standards come along. In that regard, I note another issue that people seem to be making different assumptions about and that is whether the choice of resolver is appropriately an alternative to a q-component or part of the NSS to determine what information is retrieved. In other words (and as a silly example), if I have a URN like=20 urn:ietf:rfc:2141 can I use urn:ietf:rfc:2141?+RFCPageCounter to get the number of pages in the thing? Is that a plausible alternative to urn:ietf:rfc:2141?=3Dpagecount or something like it? >From looking back at discussions since we separated r-component and q-component, I think there are people in the WG who believe in a "yes" answer (perhaps passionately), people who believe in a "no" answer (perhaps passionately), and people for whom the topic is the source of a headache. The only thing about it that seems clear to me is that our trying to reach strong consensus about a conclusion will drop us into another rathole. In particular, note that Martin's comments on your note = includes: --On Monday, February 22, 2016 14:21 +0900 "Martin J. = D=C3=BCrst" wrote: > I think I understand what John is trying to say: If there's a > resolverID "info", and that's (for simplicity's sake) defined > to return info about the author(s) and the length of the > document in bytes, then it's not possible for a namespace > maintainer to say that for the particular namespace, the > "info" resolver also returns the date of creation, or doesn't > return the length in bytes, and so on.=20 >... This was what I was trying to say. However, the mere question of whether it is reasonable to define a resolver whose function is to return particular metadata seems to be controversial, especially when one starts making suggestions about namespace independence. Similarly, it seems fairly clear to me that, as soon as we start pursuing the question about selecting information to be obtained by choice of resolver, we are also going to need to consider whether the semantics and interpretation of a q-component are a function of the choice of resolver rather than that of the namespace. See the "embedded characters" note for an example of where the question might lead. Again, I think that issue can be sorted out, but don't see a way to do it in this WG as it is now chartered and functioning.=20 I'm going to post three other notes (with deliberately different subject lines) immediately after this one. Reading them may be helpful in understanding whether the conclusions that follows are reasonable but, again, my own key priority at this point is moving forward and getting 2141bis published, not how rich and detailed we can make that spec. Conclusions and summary (each of these conclusions requires a decision by the WG or instructions from the Co-chairs): (1) We are not going to be able to fully specify r-components in this WG under this charter and work plan. Things that cannot be "fully specified" include drilling down into the details of resolver functions, syntax of whatever follows the resolverID, whether name-value pairs or similar construction should be required, what sorts of registration models would go with such pairs, registration procedures for resolverIDs, applicability scope for such IDs, etc. The document contains too much, rather than too little, text in some of those areas now, and, to the extent to which the the excess or explanatory material adds confusion, it should be removed rather than debated and fixed. (2) I am operating, and working on 2141bis, on the assumption that I correctly understood Andy's conclusions about WG consensus and his instructions about how we should proceed with r-component and q-component syntax as using two character sequences to introduce each, with the first character being "?" and the second at the discretion of the document editors. If that assumption is not correct, I need new instructions. If it is, it would help the WG move forwzrd if the topic were dropped unless someone identifies a genuinely new issue. (3) The syntax model for r-components in 2141bis-15 is fairly restrictive, including arbitrarily restricting resolverIDs to the same characters allowed in NIDs. If we cannot agree on that, and noting that some possible changes would require careful examination of RFC 3986 to see if they are even possible within the constraints of that document, I suggest that we drop the idea of dividing the r-component into a resolverID and string entirely, making the entire r-component opaque until other standards are specified. (4) It is no secret in this WG or elsewhere that I don't like the character reservation, syntax definition, or encoding specifications of RFC 3986 very much (or at all). However, they are what we are stuck with and, IMO, discussions about the inherent problems with 3986-style encoding or other issues belong in a discussion of 3986, not in efforts to use or constrain URNs to fix or work around them. I'm happy to be wrong about that and do whatever the WG wants, but am at the point where I need instructions from the Co-chairs on the subject, especially when the problems interact with (2) above. (5) One of my main inferences from Sean's notes and the comments above is that, in the absence of active discussion in the WG and/or instructions to the contrary from the Co-chairs, I am to pull as much discussion of r-components out of 2141bis as possible, reducing it to a brief statement about the intent to support instructions about how to "resolve" a URN but that more specific definitions and use are to be the subject of future standardization and the whole construct is reserved until that occurs. That leaves two subsidiary questions: (5.1) Should I retain the "resolverID: string" syntax entirely, including the NID-like syntax for resolverID unless the WG directs otherwise, or should I remove that as well? (5.2) Should I put placeholders, with similar "reserved for future standardizing" text, into the registration template so they at leave have a field for it in the registry. I see some advantages to doing so, mainly saving IANA future difficulties by defining and structuring the NID registry now and then having to redefine or restructure it in the future, and no disadvantages, but maybe I'm missing something. If this is a big deal for anyone, I/we could ask IANA if they care. Barry and Andy, one implication of the above is that, unless you tell me, really soon now, what tentative decisions to make about the above, -16 is certainly not going to make the posting deadline. My personal recommendation is that, if it works for your schedules, we give the WG a week (or, if you prefer, more), time to react to these notes (and, implicitly, additional time to react to Sean's notes) and then you give me the go-ahead to fold the conclusions into -16 and get it posted. best, john From nobody Tue Mar 22 02:32:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDB412D728 for ; Tue, 22 Mar 2016 02:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4SPfB6YsopM for ; Tue, 22 Mar 2016 02:32:30 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0137.outbound.protection.outlook.com [104.47.93.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838D612D6E1 for ; Tue, 22 Mar 2016 02:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RKmLfAnxKsDIfSo0R3XYZJy63nsCZxX307/MUSn9POA=; b=E82tJv0+zvsj7dMkJxy5wygjTUX4WTcezmYDfY9BVYCZ7+y5RQjN1xAB6XihRKDWf6sdIWHgyJr+Xl49yjT1QhKG++XRGELpmsCGu2ric+V8j+2niFEzwY0FIjwqc7GG8pWxKXO1Kxb/j5pr8S2hr2UOWSDpF09dnzCyDUv4l54= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0914.jpnprd01.prod.outlook.com (10.167.178.20) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 09:32:26 +0000 To: John C Klensin , Sean Leonard , References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F11127.4030306@it.aoyama.ac.jp> Date: Tue, 22 Mar 2016 18:32:23 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0011.apcprd06.prod.outlook.com (25.164.91.21) To OS2PR01MB0914.jpnprd01.prod.outlook.com (25.167.178.20) X-MS-Office365-Filtering-Correlation-Id: 4927547a-f0ee-484c-be68-08d35234e1c5 X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0914; 2:zx4HeVao8f3UygtOFELz2/tfpUAa0SRGerNZm2nrbwXUFfm+KGN3uYEruloahxVm+hhbYDnVYUmKGFwUhWkaLaiC+WvMaHH5uYr6G8P9eRXcWs1uHgT7s2V1npzdnTN6oYJ2AHsbBnIllraNQJs3k+7qiVVzlmozP8XCYtReXlYj77AtDBEUGFJWvPuIeeFl; 3:dEhCtkSZp4av/v3+ymph7D1KbOZyZTMb0+UhM7YmEqdQSM8MLzvYPVFnGqhQ83J20e8xoCsVPtoEq6SIwScvM42CHdmXOu5d6qLOETEEMdEZhn8nHjIcaHt0dBmYpbzm; 25:vqrMX0H5+zHNwqvLZ9HHimfPfqODTbLkwEi5LI3gB52Of8SNvtDN4oD3YUDQ3mM9172FU0JoxQlbavB+IDRcZbG252Omk+KzUkEJthRbLwDpK/sBJM21ks7JBpDlzUf2bI/ZuG4XwkghEjOn3Z55GV+DNKhTfKzBZnLqO2cdQX7+ZYKrgEIG9thjpbk/DbeN4xSqZJW9bWYdc2AJCCXjMpgjm3SRNbzh7SycAMWuUqPFNH+J9P4Pyas8vYt+O7DRb6C0EfXsxki2BRvxXFVnUjmPU5+OkX8WlcNagHzy/q6Vk7PLx1xK9Rs9InG8VG8nuQbUBLfTDymD2L1mDwREH/F7nWQSPhc6L74EoaRAGj6XJQ01iNnrGc40LgasMXG1NUJjnAMpyzqBN2EZMjDeoyPtC9EUJyrDGQVXrlFB2DIdxv+//vTHbJN9CRY897qY5v6aH8ENuWMkV+U00JfhlV+LGu5Oo7x4Cc1G2mOUcoo= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0914; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046)(6042046); SRVR:OS2PR01MB0914; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0914; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0914; 4:dm7Tzwb+eSY5ZU+lKFMa0Fbj4pmYon4ksAr1IsVkJoRri7uRBsTQ2Mi/dJcCOqgAlMPya8CblfiN31OH+2lTYwtLKTEcJJo4FiYSoKlGsU8Tw5Ht7X7ls5+TTKJ+vrHmetDpmo5z3Z3BIgX9aEJd7jNd/75etEakJAwC3LiJ3pwXQKkHOfF5kaqjXf2HErf47bdrbhE+Ore5VW/yZPRDvh/KjhHmFEbzlABxTGZbwvt9saFeH7wQgkwMosF7ilrNdvLX7zH6XNEk3VCWj14sAkOPw9Rrj2IS3xOD0l10nCFlGAfpR30FVTXOlT1XucAeYjnMrv4B2wcIKyB4F5huxbXlMYfxN+F9npLY0Pz2OoXprBLCgvOVP8ZvDyE7/Fkl/M518vQkqwYlhDGDI368/XsQc9NltK2AUxpREthPKOw= X-Forefront-PRVS: 08897B549D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(65956001)(5008740100001)(66066001)(65806001)(586003)(189998001)(107886002)(230700001)(4001350100001)(6116002)(33656002)(3846002)(2906002)(5001770100001)(76176999)(50986999)(1096002)(2950100001)(87266999)(65816999)(54356999)(47776003)(77096005)(23676002)(83506001)(86362001)(42186005)(5004730100002)(74482002)(64126003)(50466002)(59896002)(81166005)(92566002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0914; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwOTE0OzIzOkp1RHZRanFsVUdsaEprN0krNmFpbjVReDhT?= =?utf-8?B?enVCLzdMVVRxRzFqVUhod3hiR09tR0k4ZHBoRjlUVzFPbFJPVGlabVFtNTJo?= =?utf-8?B?N3p2bzE0bUJjSWxwODhhanR5ajdvcnhpbFJaamdZeUpXeEEzWUtTVVZHdHhP?= =?utf-8?B?a1JXRzFSaUdlYXoreG9wZ0U5VkNwalFVdTlsMHlyV3dydWxJc2FLMWRkdFJG?= =?utf-8?B?K0t6anZwcUoyamh4dm9YMDBCZnpUTUJwa1RHSVhtRUxzQ2FNdzJJM2hUakZ5?= =?utf-8?B?d1BQeHdRNUJ5YmtScHIyQmVRd3B0Y24xRG1xY2w4dlZ5dlZ3ZERyemFPaDN2?= =?utf-8?B?eDFOekI0RTFtZzNFZzlGeTlQaHkrSE50aEVjYklaUzlzaG5vdTRkSWRlNDVz?= =?utf-8?B?NW5XWWhKSUY2aHUvWW1oc0lnZHc0VFNSR1pUb29ZSHlHVVNmcmxueUwwK2Zr?= =?utf-8?B?eFF2OC9qd3FxTjNEdy9rT2tLSjJveW83cG9hT1BqcitoRnNLYXVJRXV0YVM1?= =?utf-8?B?VUpRTnZuKzl1dW53aXBITTYyR3l4cFRPTmcrVnhwRVRCQ0lWS3VaL0daZjJu?= =?utf-8?B?N3lRTkI3VkJ1eHFNUjJaVXJPaTB3d1o3OENWWFNUN3h6RW52VS9CSFdmeTZS?= =?utf-8?B?M1gxTzBEdlFZaGxIQmR1VmhBcG85aG5ML1cwVWZLVjJRMGVnbGtFUm5pbkcr?= =?utf-8?B?Z1l3YUtybGQwNVMyaHhSVE9XQjBsV29zY1RscDhxZCt2Wi85dllrNXhYUG9w?= =?utf-8?B?MVQwQzJnU0ZzNzRUa0drdFNSMkFTSVlxcTNYRnR3ODhPNEdNVEU4MzZrOHFa?= =?utf-8?B?cjlwaTJZRUJiVjFncGtPWDNyZUVvU3lFZzlrWjRvaG9ub1NwREY4TzJsSTBq?= =?utf-8?B?Q0trYmRZaDA2VVludDJWN2NTOTJ0KzBQbHdLSCs5UXhVUThMZkdhWVdlVS9S?= =?utf-8?B?UXQ2b0R2R29IdEJjRUJ6SWFvVnlqNzhiZDVJbXZNMGw5eUVpbGh4SWo3bUw1?= =?utf-8?B?bW01UjZHUitUaFBMWDJ6WURESEFkVS9WSFI5TFVMU29BWmdTMWt1S3pmY21O?= =?utf-8?B?RFJrOFlLVklIOU5ueVYwOUNIWWRwLzNzYzZIYlpXdDhFWHRoNW5EQ0RmUUMy?= =?utf-8?B?cmtIT3hETmd6QndIQWR3TGFGQXFmSUtnQXRnMi9JWFpodzVmSGErbmpRT21S?= =?utf-8?B?OVpZZUhvcEtqWk80VGh5UXBkYTRkMGNDV1B1dXUxd0l5dFc5c0ZwODhqSk9R?= =?utf-8?B?RnptL3lCNHhZTG1yWVZvZFBFaWpwUGhkSytrU0x4Zmo3NkM1cDZOdi9Qd293?= =?utf-8?B?V2ZxdUV3YjlsVWJiclU4MFhzVXZWUkwxMWpvL2pJRGw4VmhGelM0UzJva0Ft?= =?utf-8?B?dlR6R3lLQk5GRk8yUUs1MlFMYXpRdkk2NmpQZVpXQ29wdllNeWVKN0dkM3Mv?= =?utf-8?Q?dIek54=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0914; 5:0KQXtyZrM1jOrIYHbQozjXh78Qn8S5qA3Wfsjl78bmP+CSa99l/Gkwj+GKyWJ/XIKaDXiC213WDThKYLH7Ckfx25Zk4WOKmr0YJuzbfgFUYOQM3xPaHSTpZeiK9Onp1u30PbxNT0MzfgzHjjZaYRTg==; 24:laN3zTCFCljpW/RaSB2/udX6SnWz9f2BVwY3nLwbgIX1iOqaD6vtEvo2idHmAC90G+/lZ2drSV/0KaLzQUtRKm9G71cbfVy1Fk7LpK1IlhQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2016 09:32:26.7731 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0914 Archived-At: Subject: Re: [urn] General r-component issues (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component_ X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 09:32:34 -0000 Hello John, others, On 2016/03/22 09:21, John C Klensin wrote: > Conclusions and summary (each of these conclusions requires a > decision by the WG or instructions from the Co-chairs): > > (1) We are not going to be able to fully specify r-components > in this WG under this charter and work plan. Things that > cannot be "fully specified" include drilling down into the > details of resolver functions, syntax of whatever follows the > resolverID, whether name-value pairs or similar construction > should be required, what sorts of registration models would go > with such pairs, registration procedures for resolverIDs, > applicability scope for such IDs, etc. The document contains > too much, rather than too little, text in some of those areas > now, and, to the extent to which the the excess or explanatory > material adds confusion, it should be removed rather than > debated and fixed. I agree. Specification of r-components would either need some careful design-team(-like) work, or some existing running code. The later doesn't exist, and neither does the time and energy for the former. > (3) The syntax model for r-components in 2141bis-15 is fairly > restrictive, including arbitrarily restricting resolverIDs to > the same characters allowed in NIDs. If we cannot agree on > that, and noting that some possible changes would require > careful examination of RFC 3986 to see if they are even > possible within the constraints of that document, I suggest > that we drop the idea of dividing the r-component into a > resolverID and string entirely, making the entire r-component > opaque until other standards are specified. I agree with dropping, mainly because of the reasons for (1). > (4) It is no secret in this WG or elsewhere that I don't like > the character reservation, syntax definition, or encoding > specifications of RFC 3986 very much (or at all). However, > they are what we are stuck with and, IMO, discussions about the > inherent problems with 3986-style encoding or other issues > belong in a discussion of 3986, not in efforts to use or > constrain URNs to fix or work around them. Yes. In particular also because there IS a large amount of running code related to RFC 3986. > I'm happy to be > wrong about that and do whatever the WG wants, but am at the > point where I need instructions from the Co-chairs on the > subject, especially when the problems interact with (2) above. > > (5) One of my main inferences from Sean's notes and the > comments above is that, in the absence of active discussion in > the WG and/or instructions to the contrary from the Co-chairs, > I am to pull as much discussion of r-components out of 2141bis > as possible, reducing it to a brief statement about the intent > to support instructions about how to "resolve" a URN but that > more specific definitions and use are to be the subject of > future standardization and the whole construct is reserved > until that occurs. That leaves two subsidiary questions: > > (5.1) Should I retain the "resolverID: string" syntax entirely, > including the NID-like syntax for resolverID unless the WG > directs otherwise, or should I remove that as well? I support removal, but would be okay to leave it in if that helps consensus. > (5.2) Should I put placeholders, with similar "reserved for > future standardizing" text, into the registration template so > they at leave have a field for it in the registry. I see some > advantages to doing so, mainly saving IANA future difficulties > by defining and structuring the NID registry now and then > having to redefine or restructure it in the future, and no > disadvantages, but maybe I'm missing something. If this is a > big deal for anyone, I/we could ask IANA if they care. I don't mind somebody asking IANA, but I think for them, adding an additional column to a registry isn't rocket science. On the other hand, having a field in a registry template where all the registrants are going to wonder what to put in (and our answer would be "nothing for the moment, that's just for the future") will be highly confusing. Regards, Martin. From nobody Tue Mar 22 02:41:57 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A2D12D1B8 for ; Tue, 22 Mar 2016 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8ofikMVV9QK for ; Tue, 22 Mar 2016 02:41:52 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0110.outbound.protection.outlook.com [104.47.93.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8234012D166 for ; Tue, 22 Mar 2016 02:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iDfcWuNlNV5JmpQN1KixxIgRvNbgn/dGb5z8swR1JFU=; b=xAMvWfRzEO2/vUqjl4nNzgKyb8yCy3UQRY3sED7ZeYmVQPkv87MQhlAwOogkv+wuWYfl4aMb/LWQarno6BJa9rjk1+EWRQxoUG8OMgeqNsTVHMLyaZrk1PH6Dr0wzVaMb88uJ0XFv5/kqB4/qdp61pcKwbBw4JBPEuNJ1PuP47w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0924.jpnprd01.prod.outlook.com (10.167.157.135) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 09:41:48 +0000 To: John C Klensin , Sean Leonard , References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2F42.7090802@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F1135B.7040304@it.aoyama.ac.jp> Date: Tue, 22 Mar 2016 18:41:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0034.jpnprd01.prod.outlook.com (25.164.162.144) To TY1PR01MB0924.jpnprd01.prod.outlook.com (25.167.157.135) X-MS-Office365-Filtering-Correlation-Id: a7c1f754-8946-4e2b-4797-08d3523630ba X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0924; 2:SrrFE+jsDAVnph9Nh9S3JC6ihst1DhDni1Vo6w159wND2Wz5bKzd5+3gq04W+lqYpuIc3uP6qzAnHu5PZF/UEHqZTGWu8+MItNyLOc92DTPZopqvINradVvf1KlboNgtYurkdjZrZtxGTyd1YJ1YXG9Uk+2ZlcFq2EUX6WG8/yZbdambA4G796Mzfb8L+fea; 3:c4mz4C+3/8Ea44A0gm6sE4ijIPqxqWABppKY6vUR98Nol7kMhmqcFcFPQLvqKj/Jo3MuYCV/+jhWEMpByXKNGMlG2bLnIloAr61HcA5tFZS+w4u/8Bz655rTet7rCSRI; 25:Ut41Ofbqgu8WJpbNAHHpVvFzSGgOja1zDmC7KvGjZqEzTPLGaF8lstRQsnwTulW5xnHb4YFR1WADLIxgEK3IoQqF/g6MnRJ6hHaLe8CmHbBPzYLwRi8lVj/RDaSjRzpFaZ4rkcXKHKZTVERn2ocx/t4rxgCourWtU1L9wX1jxQdYT0JU7/47LJhv489z0yEOTTzeF2+U+GSCAsNn4ORqNDrmAScZkmEyqozx/K1X7PigV7DKbeWlG9E/Ju00Rkxmr3BRskzxYHzBBmPqTJ2545gSweMcaapbVEXNRhgnVqLi5DhxTCfWKkYZ5TFF9vYni7ogVP2XAtbuXmbcdhO+t0nTv/iII7GYACcflkXgbbZ+pgjtZfU+p80CFpT3hqR5lDiy+o9JYfVlc2UYqKnaIfrdJoopuPP22WG94NWhzLJmkVAeAamPVEdxxgPmnABrf0PAD0UbLae+EQBm4Hel7w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0924; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6042046)(6043046); SRVR:TY1PR01MB0924; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0924; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0924; 4:HZDRPbAOOP9lJFX3R8IPKDiObi9WRzrXSQJLW6rM+ltR4JIRptZqNLH6z5zIcB17n87hYirp2Ht0XyiXy668FbGNgJAxDaL3ufJPL54oIC/mQNL2A4U889VLgmtmpsoedFz0Udwg1qw11ol5Ibg/2hwkTQEyROYNZd79nRHsPziAysz+3uUqJF5EyWTnCMXoNkv+X1bx5ch3SCZe/tKKPjfXl7yzpdO/EgHT9Jzy4ssCvmCAwUIVQwFkRr+00H90jx0ql+kGTtpQgO+p5J+wjhaIH2iKxElnLaJqotnSk7LowKeP4SHJ8/kHB1uRLUwyTx5+jkBqR24ht2KAMrTrBFv+ZDih3RWWGRyiT8TfuDMx1rVHSc9S1rDJ+71Dr5wxwjv5X6pVmafihkasHA2gpLUnVFc0Npai5A9UOD9X0AY= X-Forefront-PRVS: 08897B549D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(4001350100001)(92566002)(5001770100001)(189998001)(2906002)(6116002)(81166005)(86362001)(3846002)(1096002)(33656002)(74482002)(107886002)(586003)(59896002)(50986999)(65816999)(65806001)(5004730100002)(77096005)(230700001)(23676002)(64126003)(93886004)(76176999)(87266999)(47776003)(83506001)(54356999)(5008740100001)(42186005)(2950100001)(19580395003)(50466002)(19580405001)(66066001)(65956001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0924; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwOTI0OzIzOklkMUNFVHFrR1g5Q1FVYVA1Q1RMdWRsaG5a?= =?utf-8?B?MlVDQmYrUXd2TUlFcXlGTFJ0QndiY0hwUDVScmp0SFRJNThpSytuM0JJUGZX?= =?utf-8?B?b29WaVVlRWx1VTQ3d1dBZGtYM2RJcUVBbHFjMTMxK0xzR1lCbWJEQ0poMTJ3?= =?utf-8?B?S1VmS0c5SXY0cXYrS3AwTmQrdWR1UXQwMFNjRkJKNTA2ZGFiSVNkSlNKRDI0?= =?utf-8?B?bmhEcUtlc0p6Wkk3ZEo1dTlJaHJLd1BiQi9wYSt3SEczZE9yM3ZOMU9pVXZQ?= =?utf-8?B?TGxWMTUxWW9Gb3U2YUN3bndSNDlaVEU2NzhaZm5XVUJKT094SjF1Qk9SbEZ0?= =?utf-8?B?bXRHMVZCbWYzMUozTEdVUEVqTm5weTgvTHFFSis0TW8vaUZZaWF1aGY1Y0hL?= =?utf-8?B?TDViMGVONFJNMG1kc01JWG1TWWZheHpSWDNGK1JKV3MwWlpxOHhCbTRlYVNy?= =?utf-8?B?YVF5RzFSNUxPTmNqbXhpVHVSU2htdk4vRTI1am9DZXBBWUxxSVJ4NTEvU0t6?= =?utf-8?B?Zk1MQXcyMDdTOTBQMWNOcWRIRlJpUXphQVVqVER0VGN0U3ZMQjkxYlpNZU5i?= =?utf-8?B?aDcvaWRqZFQzei9rMi9uTVBLUldhUEJ2VVFqUzZHNUdIZXlqeHZKVUkzd3la?= =?utf-8?B?clB3bThLeHM4OVVkZTk0U3ZpYTcyUzdFdlg4ajcrYVFIcU1aWXk0WERzc1p3?= =?utf-8?B?enpxNjltM2oxaHA3Tk5pUjR3SVlzQVBvZjlmRGk2YTRYbkVhUENYbU5HT05q?= =?utf-8?B?WXJKenVUaGNQMVltZm1DWCtVRzBtalo2S2tPWW9MeWlxYkN2VzdqZ1JNaXNu?= =?utf-8?B?alJTZkJBSVJ3VFpVRllPRGdzVHpSUmk0TzZNaFJGb3cxTFp5Q0NBcysyWDQ0?= =?utf-8?B?emJhVExLcjRDMkx3UEpjZkhmQUFtVnAydmt1dS8wa3BtRTdDL2lkRTlza0J3?= =?utf-8?B?NmN2UjlXekllRWZkNTdyR2JVMzA4L3haWDFpS25jS2EzbExzeGZtVXcyK1FL?= =?utf-8?B?U2F2cTNxSDJUa2hMcXpuL3ZmUEp4M0R0ekxyRUxwK3p4ZnF1VnEzOGZZSTNL?= =?utf-8?B?NFRuWnVRWVpBVVFzalRUNEJqY3M3K001TDBERzVERDFBRC8zdjZadnN3Y1E4?= =?utf-8?B?S0FWQ2N5OEtWcXdnYXJ3S1JqWXJZL1NZUFN5NXppTVZtd3hiNmozWExoZkdN?= =?utf-8?B?YjNWbEgzdExwT2xrVC8xcEFJb0plUE1MZUhNelRrdWVRcDdvb216aXhqdUt5?= =?utf-8?B?Y1FQUTM1Nkh5T052SkZXUE42cVZKbnhsWUZjOUNDWDBlS04ydE04czJkR0h1?= =?utf-8?B?WjRKblJjVzhTMnQ3VjhOREo2NndwVitqNjJQbWcyYWhtdzdvQXFWTVJsdWV4?= =?utf-8?B?MDNOSGJmUlBtQmlCVUtsNHgwU3hRV2JZdm82OFJKcXBvVkVMU0FiWEE2Ni95?= =?utf-8?B?ODFzYm1hNFJwdUVnZHA1dmVNbCtpYUNNVEdMcTFvYVB0MXhxMVNnLzlpa3RN?= =?utf-8?Q?+IXsHKd48jEY6ngmbUukx6aPc=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0924; 5:V1kBNj/d4lDv2+wqpBNXJAgUfiegZGdpsRzDysc/eHFufeCkUgYoABz2we5KClWqonx9TqCxbYNga+5SZlGFaipDCkPdeNiZ/ErWb+SkKjjiicRB9j0/C5FzxG/17UZQmmz9AZNub8/wbBgM2YZp4A==; 24:dpJYOy9cnQ3qkPZU2LkOitB5Uk88QwuHodhn/P0U8yZVZCKKe+EOp6pvrXVtiX/SvjowGObyX2PF7t98xyGDT91hU/WOq24pwUPh7dMjWZk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2016 09:41:48.7816 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0924 Archived-At: Subject: Re: [urn] Embedded characters in the r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 09:41:53 -0000 On 2016/03/22 08:53, John C Klensin wrote: > --On Sunday, February 21, 2016 13:42 -0800 Sean Leonard > wrote: >> As you pointed out: if you >> delimit them with ?= ?+ etc., you must also %-encode the >> constituent parts. This means multiple levels of %-encoding, >> since % encoded characters will themselves get % encoded to >> %25. > > Yep. As I read it, that is what 3986 requires if those > sequences are used inside the component strings. I don't think there is a need for multiple levels of %-encoding. There are only two levels: a) payload (which includes any component-internal stuff such as query/resolver parameter names and values,...) b) syntactic delimiters Essentially, anything that looks like b) but is in a) has to be escaped, exactly once. That includes '%'. Whether that's part of domain name (just for the sake of the argument assuming that's possible), part of a path name, part of a NID, part of a namespace-specific string, part of a q-component or an r-component or of anything else, just escape it once, and things should work fine. Regards, Martin. From nobody Tue Mar 22 07:49:02 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E5E12D641 for ; Tue, 22 Mar 2016 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhRqxFKjbpv4 for ; Tue, 22 Mar 2016 07:48:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8419F12D0FF for ; Tue, 22 Mar 2016 07:48:59 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aiNc5-000IDa-Es; Tue, 22 Mar 2016 10:48:53 -0400 Date: Tue, 22 Mar 2016 10:48:48 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Sean Leonard , urn@ietf.org Message-ID: <671FC3D7D18872CA4E6D7851@JcK-HP8200.jck.com> In-Reply-To: <56F1135B.7040304@it.aoyama.ac.jp> References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2F42.7090802@seantek.com> <56F1135B.7040304@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Embedded characters in the r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:49:01 -0000 --On Tuesday, March 22, 2016 18:41 +0900 "Martin J. D=C3=BCrst" wrote: > On 2016/03/22 08:53, John C Klensin wrote: >=20 >> --On Sunday, February 21, 2016 13:42 -0800 Sean Leonard >> wrote: >=20 >>> As you pointed out: if you >>> delimit them with ?=3D ?+ etc., you must also %-encode the >>> constituent parts. This means multiple levels of %-encoding, >>> since % encoded characters will themselves get % encoded to >>> %25. >>=20 >> Yep. As I read it, that is what 3986 requires if those >> sequences are used inside the component strings. >=20 > I don't think there is a need for multiple levels of > %-encoding. There are only two levels: >=20 > a) payload (which includes any component-internal stuff such > as query/resolver parameter names and values,...) > b) syntactic delimiters >=20 > Essentially, anything that looks like b) but is in a) has to > be escaped, exactly once. That includes '%'. Whether that's > part of domain name (just for the sake of the argument > assuming that's possible), part of a path name, part of a NID, > part of a namespace-specific string, part of a q-component or > an r-component or of anything else, just escape it once, and > things should work fine. In case it was not clear from my attempt to reason through the situation, I completely agree (and would accept your judgment even if I had not agreed earlier. thanks for reading the stuff and replying. john p.s. The "part of a domain name" issue is an example of why we need to be very careful about what questions are being asked and to be sure the answers are interpreted in the light of those questions. As far as the DNS is concerned, it is possible to put any octet, including the oft-problematic X'00' and X'FF', spaces, and periods, in a domain name label. However most applications (including anything following 3986) will get thoroughly annoyed by anything outside the ASCII range (i.e., high bit 'on') and almost as many will be annoyed by anything that does not conform to the so-called LDH rule (i.e., what the basic DNS specs call the "preferred syntax"). I know you, Martin, know that, but, in case anyone was confused... From nobody Tue Mar 22 20:14:04 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50CF12D604 for ; Tue, 22 Mar 2016 20:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2JByWWHuMkO for ; Tue, 22 Mar 2016 20:14:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6348D12D1AF for ; Tue, 22 Mar 2016 20:14:02 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 036F3E81EC; Tue, 22 Mar 2016 21:20:43 -0600 (MDT) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Sean Leonard , John C Klensin , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> <56CA9AE6.5020307@it.aoyama.ac.jp> From: Peter Saint-Andre Message-ID: <56F209F7.70409@stpeter.im> Date: Tue, 22 Mar 2016 21:13:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CA9AE6.5020307@it.aoyama.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:14:03 -0000 On 2/21/16 10:21 PM, Martin J. Dürst wrote: > On 2016/02/22 06:04, Sean Leonard wrote: >> On 2/21/2016 12:24 PM, John C Klensin wrote: > > Sean wrote: >>>> From that view, it follows that r-component is >>>> namespace-independent, in the sense that the maintainers of >>>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a >>>> stab at their own spins on the resolverID "foo" or "info" or >>>> "abcdefg". The namespaces of "resolverID" and therefore >>>> r-components more generally are global and orthogonal to the >>>> NID / NSS part. >>> I hope that is consistent with what the text says. However, the >>> intent of the text was that maintainers of particular namespaces >>> _do_ get to specify what resolverIDs are used with them, just >>> not how a given resolverID that they intend to permit is >>> interpreted. >> >> I am confused with these two statements/positions and do not see how to >> separate them. >> >> I think an example from you would be very helpful. > > I think I understand what John is trying to say: If there's a resolverID > "info", and that's (for simplicity's sake) defined to return info about > the author(s) and the length of the document in bytes, then it's not > possible for a namespace maintainer to say that for the particular > namespace, the "info" resolver also returns the date of creation, or > doesn't return the length in bytes, and so on. In other words, opt-in > for each resolverID is binary. > > That still leaves us with the problem below. > >> As you wrote: "maintainers of particular namespaces [get] to specify >> what resolverIDs are used with them". And: namespace maintainers do not >> get to specify "how a given resolverID that they intend to permit is >> interpreted". >> >> So the maintainer of urn:isbn can say the resolverID "info" can be used, >> and "get" cannot be used. The maintainer of urn:oid can say the >> resolverID "info" can be used, and "get" can also be used. >> >> But why do they say some resolverIDs can be used or not, when they have >> no way to promulgate what it means? >> >> It is like saying: "You can use the number 6 in this protocol, but not >> the number 7. Oh, but you can do whatever you want when you receive a 6." >> >> Usually the party that specifies the values, also specifies the meanings >> of the values. >> >> >> I actually do not care whether the resolverID is namespace-dependent or >> namespace-independent. As I have pointed out, a resolver receives both >> the resolverID and the NID (plus the NSS, of course), so at the level of >> resolver behavior, the behavior will always be namespace-dependent >> because it depends on the identity of the thing being named. >> >> Right now the specification equivocates because sometimes it says >> independent and sometimes it says dependent. That is a problem. >> >> Upon reasoning it through, my position was: >> >> "people writing durable, universal naming >> schemes should not be required to be in the business >> (directly) of dictating what resolution services get developed >> or not, and vice-versa. I.e., the URN namespace registration >> template should not require new URN namespaces to specify a >> set of resolution ops." >> >> >> This is based on making it easier to register URNs. If resolverIDs >> (resolver operations) are namespace-dependent, we must expect the URN >> registration template to define resolution a lot better. That is more >> work. And it may change over time based on different parties' needs. > > I guess I'm with Sean here. Sean maybe implied this, but I didn't see it > stated explicitly: It would make introduction of new resolution services > (which might perfectly well be able to deal with preexisting URN > namespaces) a lot more difficult. We don't have any magic to update > specs or registrations automatically. > > So at the most, I'd want to limit us to something like "Namespace > registrations MAY indicate some of the types of resolvers suitable for > the namespace (by listing the relevant resolverIDs). Such a list does > not restrict the use of resolvers to only the listed types." That seems reasonable to me. Peter From nobody Tue Mar 22 20:20:17 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E872512D61D for ; Tue, 22 Mar 2016 20:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_OBFU_WWW=2.475] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txwgIRPsv3ed for ; Tue, 22 Mar 2016 20:20:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 432E612D604 for ; Tue, 22 Mar 2016 20:20:14 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3D98E81EC; Tue, 22 Mar 2016 21:26:56 -0600 (MDT) To: John C Klensin , Sean Leonard , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2F42.7090802@seantek.com> From: Peter Saint-Andre Message-ID: <56F20B6D.6000901@stpeter.im> Date: Tue, 22 Mar 2016 21:20:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Embedded characters in the r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:20:16 -0000 On 3/21/16 5:53 PM, John C Klensin wrote: > > > --On Sunday, February 21, 2016 13:42 -0800 Sean Leonard > wrote: > >>> The other issue is what we actually mean by "embedding", and >>> is a more complex question. So far, the WG has believed that >>> simply delimiting the two substrings is sufficient. However, >>> if we need to specify that any appearances of "?", or "?=" >>> or, most particularly, "?+" in those strings must be >>> %-encoded and then that the URN-parser needs to be able to >>> decode one level of %-encoding before putting the contents of >>> the q-component into a URL as a , it seems to me that >>> is easily accomplished in terms of the document and not a big >>> deal for a URN-parser/evaluator. >> >> Ok well here we have a substantive difference, that I hope we >> can tease out. > > I note (again) that the number of people in the WG who have > responded to this part of your suggest is, AFAICT, zero. I am > violently opposed to having my text prevail simply because there > is only one objection, so let's indeed try to tease things out a > bit. > >> I am not sure that "So far, the WG has believed that simply >> delimiting the two substrings is sufficient." Some in the WG >> have said this (references, please?); my position is that >> delimiting is not sufficient. > > Ok. I have been drawing some inferences from silence, which is > always a dangerous business. On the other hand, the alternative > to proposing something specific in the draft and notes to the > list appears to be to do nothing until a healthy discussion in > the WG emerges, something that, for these issues, takes either a > long time or considerable stimulation. Waiting for a > discussion obviously does not work either, especially since > there is some small evidence that the long silences and > inability to resolve issues --issues that some participants are > unconvinced that they should care about-- are driving people > away. > >> As you pointed out: if you >> delimit them with ?= ?+ etc., you must also %-encode the >> constituent parts. This means multiple levels of %-encoding, >> since % encoded characters will themselves get % encoded to >> %25. > > Yep. As I read it, that is what 3986 requires if those > sequences are used inside the component strings. I can't tell > you what I think about the requirement in polite language, > except that it is a logical and, IMO, inevitable consequence of > other parts of the 3986 definition, but, unless I've missed > something important, it is the requirement. > > Do note, however, that 2141bis-15 says that the question mark > can be used without percent-encoding inside q-component and > r-components. The termination condition is one of the > two-character sequences, not a bare "?" or one followed > immediately by anything else. I had hoped that was clear from > the syntax and discussion in Section 2 of -15; if it is not, I'd > appreciate pointers and suggestions. So the scope of "must > %-encode the constituent parts" really applies only to embedded > "?=" in the r-component and "?+" in the q-component. Again, if > that is not clear, please identify where and make suggestions. > > I don't think it is a major issue, but I'd appreciate comments > from anyone who has thought deeply about %-encoding whether, > given those two-character sequences, we would be better off with > a specific requirement to represent "?+" embedded in an > r-component as %3F%3D (and similarly for q-component and "?=") > or whether we should just leave well enough (and 3986) alone > since %-encoding either "?" or "+" would break up the parsing. > >> History has shown that double-encoding things is a security >> disaster. There is a whole class of security vulnerabilities >> where implementations fail to properly double-encode or >> double-decode things. Furthermore, it's just not readable. >> People are going to transcribe these things by-hand too, >> especially for library things. > > Yep. And double-encoding thing is also an implementation > disaster and a pain in various sensitive parts of the anatomy > independent of the security issues. > >>> It would add a bit to the confusion we >>> already have with IRIs and where %-encoding is required and >>> optional, but not very much. So, while I think we need to >>> straighten out whether that encoding requirement is needed, I >>> don't see the problem as anything near "unworkable". >> >> If it is conceded that an additional layer of %-encoding is >> required by using ?= and ?+ delimiters (because, as I just >> said, a malicious or otherwise specially crafted q-component >> could contain ?+ thus switching the URN parser into >> r-component-parsing mode), then one also concedes the point >> that the current draft-15 text--which makes no mention of >> additional %-encoding--is "unworkable". > > First, I'm not entirely sure I understand the security threat > model associated with "switching... into r-component-parsing > mode". It seems to me that there are a huge number of ways in > which doing something mildly funky to a URI can cause > unanticipated behavior and even provide the basis for an attack. > I discovered a link on an IETF web page this morning that was > equivalent to www/example.com rather than www.example.com. When > that link was clicked (because IETF web pages are trustworthy, > right?) my trusty web browser promptly routed me to > http://www.com/A.B.C.D where A.B.C.D are the IP address of the > machine from which I issued the query. That is apparently a > site where one does not want to end up, especially by accident > and with Javascript and cookies enabled, with or without the > privacy issues of fully exposing an IP address. We also see > examples equivalent to > http://www.good-site.com.really-evil-site.example/ with great > regularity, often as the first part of really long and complex > URLs. I can understand the desire to avoid adding to the mess > but, if the community doesn't take either of those examples > seriously, I have trouble getting excited about some possible > problems with "?+", if only because the two examples above are a > lot easier for a bad guy to construct. > > In any event, perhaps I am not understanding your point, but I > don't think "?+" and "?=" introduce a new problems, partially > because even the idea of using "?" and "??" either requires some > arbitrary limits on characters that can be used or requires > double-encoding. One can argue that, in practice, some > approaches will require more double-encoding than others, but > that is speculative. More broadly, if anything that contain or > requires double-encoding is "unworkable" or worse, the problem > lies with 3986, not 2141bis. > > Stepping back a bit, I suggest the only easy and completely > clean way to deal with these issues would be to have a > single-character introducer for r-component and a > single-character introducer for q-component, with those two > characters being unique wrt each other and anything else with a > potential special meaning in URIs. If one could do that, then > we could cleanly adopt the one-level model of 3986 and define > the two components as starting with (or after) the relevant > delimiter and continuing to the next relevant (one-character) > delimiter (the other component delimiter, "#", or the end of the > string). There was a search for such characters and, > unfortunately, 3986 uses or reserves all of them. The > conclusion from that search and the subsequent discussion was > that any creative use of other, single, characters would violate > 3986 (btw, staying out of the way of 3968 is also part of the > argument for restricting resolverIDs to LDH). IIR, we hadn't > gotten to the q-component / r-component distinction yet, but > those sorts of constraints were a key reason why we proposed > separating URNs from 3986 entirely, an idea that went down in > flames. > > After several rounds of the "what are the delimiters and which > comes first" discussion, Andy concluded that the WG had > concluded that two-character introducer sequences were the way > to go and delegated the choice of characters to be used > following "?" to the document editors. Unless I've > misunderstood something, you are reopening that argument. I'm > not sure I see anything new in your note, but leave that > question to the WG co-chairs. > >> ... >> To be clear, ? in q-components is foreseeable...in that >> q-component = any URI query, so ? can appear in the wild. >> I.e., it will appear, especially in deliberately crafted >> payloads. > > Yep. But see above about the absence of any requirement to > encode "?" in q-components unless it is followed immediately by > "+". > >> We have control however over r-component, by prohibiting ? or >> mandating that ? be %-encoded as %3F. (These are tantamount to >> the same thing.) There are lots of other delim characters that >> can be imbued with reserved purposes, within an r-component >> production. > > Actually, based on the conclusions of people who have stared > even harder at 3986 than I have, "lots of other delim > characters..." is, at best, a significant exaggeration. The > options are _very_ restricted. > > My concern, in part connected to the question of whether the > choice of resolvers can be used to select what information is > returned, rather than only how and maybe where it is looked up, > is that people could easily discover they have a need for > (deliberately avoiding mashing this into URI/URN syntax or > suggesting delimiter structure). > > urn:ietf:rfc:9999 > q-component= "format=pdf" > #section 4.1 > r-component= "urnresolver.ietf.org?contents='congestion > failures'" > > using the above with the intent of retrieving a copy of the > document in PDF, but only those sections that discuss (or > contain the string) "congestion failures", and then only the > subset of those sections identified as "section 4.1". A little > far-fetched, but not very far from some of the ways people have > suggested using q-components, r-components, and fragments in > combination. And, of course, barring something more ingenious > than the WG has been able to come up with so far, that > r-component -- which contains a "3986-query"-style instruction > to the resolver about what to return-- requires an embedded "?" > but not one that is required to be %-encoded. One could > require a different syntax to express the same thing, but, IMO, > that takes us further into the problem of specifying something > rather precisely for which I believe the WG has shown it doesn't > want to deal. > > My recommendation is, again, to take all of that out, relying on > 3986 and the two-character starting and ending delimiters. To state it explicitly: I agree with John here. Peter From nobody Tue Mar 22 20:32:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE112D62C for ; Tue, 22 Mar 2016 20:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12EOunIt6UX5 for ; Tue, 22 Mar 2016 20:32:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAE512D626 for ; Tue, 22 Mar 2016 20:32:54 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 91421E81EC; Tue, 22 Mar 2016 21:39:36 -0600 (MDT) To: Barry Leiba , John C Klensin References: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com> <024D5EA4785AE02CCF7F1695@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: <56F20E64.80203@stpeter.im> Date: Tue, 22 Mar 2016 21:32:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Registration requirement for separation of namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:32:55 -0000 WFM too (in part because my experience with handling URN NID requests as an AD was consistent with Barry's more recently). Peter On 3/18/16 4:20 PM, Barry Leiba wrote: > Works for me, especially in the milder formulation. > > b > > On Friday, March 18, 2016, John C Klensin > wrote: > > > > --On Friday, March 18, 2016 20:23 +0000 Barry Leiba > > wrote: > > > I'll say this as a participant only, but informed by my > > experience over the last four years as the AD responsible for > > handling URN NID requests: > > > > Essentially all (perhaps exactly all, though I can't remember > > definitively) NID requests that I've handled over the last > > four years are from organizations who want namespaces for use > > by their organizations or industries. It's quite clear that > > there is little to no value in asking them to document why > > they need a new namespace: it's because they want one > > associated with their organization or industry, and that they > > control. > >... > > I'd support something that said that if there are related > > namespaces, the request should note them and explain why they > > are not adequate and this one is different. But I'd not > > support its being a requirement, because in most cases it's > > unnecessary and in the others its a requirement that's > > unlikely to be enforceable. > > Thanks. That is certainly consistent with my experience and > observations. It would be easy to add a sentence or two to the > above effect. I'd personally recommend that we add an entry to > the registration template (Appendix A of 2141bis), between > "Documentation" and "Revision Information", and say something > like > > "Additional Information. Please include any additional > information that would be useful to those trying to > understand this registration or its relationship to > others, such as comparisons to existing namespaces that > might seem to overlap." > > Better wording would obviously be welcome, as would > recommendations as to whether that needs to explicitly include > "(Optional)". It is not as strong as "if you know of related > namespaces, please explain" or your wording above, but my quick > thought is that might be overly-specific and we are better off > inviting comments but not trying to specify what is and is not > wanted. The people who want to be helpful about other > information, including the comparisons, will supply it and the > others will just say nothing or, as you suggest, "we just need > our own" or "those folks are turkeys". I think that something > like the above would deal with this issue and any others that > might come along. > > Does that work for you? Everyone else? > > john > From nobody Tue Mar 22 23:00:25 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1234D12D11E for ; Tue, 22 Mar 2016 23:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAZ1VqqA29wj for ; Tue, 22 Mar 2016 23:00:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7629F12D0D8 for ; Tue, 22 Mar 2016 23:00:22 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AEF7050A85; Wed, 23 Mar 2016 02:00:19 -0400 (EDT) To: Peter Saint-Andre , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , John C Klensin , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> <56CA9AE6.5020307@it.aoyama.ac.jp> <56F209F7.70409@stpeter.im> From: Sean Leonard Message-ID: <56F2314B.6020906@seantek.com> Date: Tue, 22 Mar 2016 23:01:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F209F7.70409@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:00:24 -0000 On 3/22/2016 8:13 PM, Peter Saint-Andre wrote: > On 2/21/16 10:21 PM, Martin J. D=FCrst wrote: >> On 2016/02/22 06:04, Sean Leonard wrote: >>> On 2/21/2016 12:24 PM, John C Klensin wrote: >> >> Sean wrote: >>>>> From that view, it follows that r-component is >>>>> namespace-independent, in the sense that the maintainers of >>>>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a >>>>> stab at their own spins on the resolverID "foo" or "info" or >>>>> "abcdefg". The namespaces of "resolverID" and therefore >>>>> r-components more generally are global and orthogonal to the >>>>> NID / NSS part. >>>> I hope that is consistent with what the text says. However, the >>>> intent of the text was that maintainers of particular namespaces >>>> _do_ get to specify what resolverIDs are used with them, just >>>> not how a given resolverID that they intend to permit is >>>> interpreted. >>> >>> I am confused with these two statements/positions and do not see how = to >>> separate them. >>> >>> I think an example from you would be very helpful. >> >> I think I understand what John is trying to say: If there's a resolver= ID >> "info", and that's (for simplicity's sake) defined to return info abou= t >> the author(s) and the length of the document in bytes, then it's not >> possible for a namespace maintainer to say that for the particular >> namespace, the "info" resolver also returns the date of creation, or >> doesn't return the length in bytes, and so on. In other words, opt-in >> for each resolverID is binary. >> >> That still leaves us with the problem below. >> >>> As you wrote: "maintainers of particular namespaces [get] to specify >>> what resolverIDs are used with them". And: namespace maintainers do n= ot >>> get to specify "how a given resolverID that they intend to permit is >>> interpreted". >>> >>> So the maintainer of urn:isbn can say the resolverID "info" can be=20 >>> used, >>> and "get" cannot be used. The maintainer of urn:oid can say the >>> resolverID "info" can be used, and "get" can also be used. >>> >>> But why do they say some resolverIDs can be used or not, when they ha= ve >>> no way to promulgate what it means? >>> >>> It is like saying: "You can use the number 6 in this protocol, but no= t >>> the number 7. Oh, but you can do whatever you want when you receive=20 >>> a 6." >>> >>> Usually the party that specifies the values, also specifies the=20 >>> meanings >>> of the values. >>> >>> >>> I actually do not care whether the resolverID is namespace-dependent = or >>> namespace-independent. As I have pointed out, a resolver receives bot= h >>> the resolverID and the NID (plus the NSS, of course), so at the=20 >>> level of >>> resolver behavior, the behavior will always be namespace-dependent >>> because it depends on the identity of the thing being named. >>> >>> Right now the specification equivocates because sometimes it says >>> independent and sometimes it says dependent. That is a problem. >>> >>> Upon reasoning it through, my position was: >>> >>> "people writing durable, universal naming >>> schemes should not be required to be in the business >>> (directly) of dictating what resolution services get developed >>> or not, and vice-versa. I.e., the URN namespace registration >>> template should not require new URN namespaces to specify a >>> set of resolution ops." >>> >>> >>> This is based on making it easier to register URNs. If resolverIDs >>> (resolver operations) are namespace-dependent, we must expect the URN= >>> registration template to define resolution a lot better. That is more= >>> work. And it may change over time based on different parties' needs. >> >> I guess I'm with Sean here. Sean maybe implied this, but I didn't see = it >> stated explicitly: It would make introduction of new resolution servic= es >> (which might perfectly well be able to deal with preexisting URN >> namespaces) a lot more difficult. We don't have any magic to update >> specs or registrations automatically. >> >> So at the most, I'd want to limit us to something like "Namespace >> registrations MAY indicate some of the types of resolvers suitable for= >> the namespace (by listing the relevant resolverIDs). Such a list does >> not restrict the use of resolvers to only the listed types." > > That seems reasonable to me. I can live with text like what Martin proposed. (With the proposed text=20 being the high-water mark. I.e., namespace registrations may indicate=20 some of the types of suitable resolvers...but they don't have to...and=20 actually if they don't it's okay too...and since it's more text, why=20 burden the namespace registrant with writing much of anything about that = in the first place...) Sean PS There was a huge burst of urn e-mail going back and forth (mostly=20 forth) recently...I intend to reply...but it will take a few days to=20 digest...and quite possibly want to pop up a level and figure out where=20 we have come and how we can get to wherever we're trying to go... From nobody Wed Mar 23 00:56:19 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B834D12D6A6 for ; Wed, 23 Mar 2016 00:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-lCVz3rJzsi for ; Wed, 23 Mar 2016 00:56:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C7A12D6F1 for ; Wed, 23 Mar 2016 00:56:15 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aideB-000LXQ-1Q; Wed, 23 Mar 2016 03:56:07 -0400 Date: Wed, 23 Mar 2016 03:56:02 -0400 From: John C Klensin To: Peter Saint-Andre , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , urn@ietf.org Message-ID: In-Reply-To: <56F209F7.70409@stpeter.im> References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> <56CA9AE6.5020307@it.aoyama.ac.jp> <56F209F7.70409@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 07:56:18 -0000 --On Tuesday, March 22, 2016 21:13 -0600 Peter Saint-Andre wrote: > On 2/21/16 10:21 PM, Martin J. D=C3=BCrst wrote: >> So at the most, I'd want to limit us to something like >> "Namespace registrations MAY indicate some of the types of >> resolvers suitable for the namespace (by listing the relevant >> resolverIDs). Such a list does not restrict the use of >> resolvers to only the listed types." >=20 > That seems reasonable to me. Putting this in context with other discussions and trying to retrofit it into the document, if we were to tear the resolverID stuff out (a decision I don't think has been made yet), the above would replace the second paragraph of Section 6.4.6 (2141bis-15), which starts: "If resolution is intended, then this section SHOULD specify whether the organization that assigns URNs within the namespace intends to operate or recommend any resolution services for URNs within that namespace...")=20 with the above, with the parenthetical comment removed. =20 That takes us to considerably less specificity than RFF 3406, whose Section 4.3 describes differences in resolution/delegation as part of the justification for creating/registering new URNs. More important, the "Namespace Definition Template" in Appendix A of 3406 has a rather specific requirement in a subsection that begins: "Process for identifier resolution: If a namespace is intended to be accessible for global resolution, it must be registered in an RDS (Resolution Discovery System, see [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so- listed in the RDS registry)." Now, that came out because we dropped the RDS (and DDDS) discussions. I assume that Peter or I (can't remember who) wrote the new text to preserve something of the same "if the URN is expected to resolve, you must provide some hint of where and how to find an appropriate resolver" favor of the 3406 requirement. Martin's suggested text above means, I think, that either: -- A new registration of a URN that is expected to be resolved MAY provide no information about resolution or resolution services for that namespace at all =20 or that -- An r-component is effectively required for any URN that is to be resolved. We cannot intend the second if we are intending to leave r-components for future standardization because it would result in a considerable loss of functionality compared to the 2141/3406 combination. It would also get us into a silly state wrt some of the material in the Introduction and elsewhere in 2141bis. I'm ok with the first interpretation and can try to make up (or accept from someone else) some wording elsewhere in the document that would make having a resolvable URN with no information about resolution mechanisms or services (even a disclaimer that punts the problem elsewhere) ok, but it seems drastic enough that I wanted to check that is what the WG (and even Martin and Peter) intend. =20 If not, I need advice or instructions as to how to put Martin's paragraph in and where. That paragraph seemed like a really good idea to me until I started looking at the text. In the process of looking at the document for the above, I discovered that the third paragraph of Section 2.3 of 2141bis-15 ("Whenever a URN resolves to a URL...") says: "The semantics of q-component and f-component for URNs that inherently cannot be resolved to a URL (i.e., for abstract designators) are undefined..." I believe the "i.e." is a typographical error and should be "e.g.". Otherwise, the sentence effectives requires all URNs that can be resolved to resolve to URLs. I think discussions have been clear that we do not intend that restriction. I'm planning to correct it unless someone believe that wording was intended (and either the restriction is too or there is some other interpretation for what the sentence says). One of the accidental advantages of the pen passing back and forth every couple of revisions between Peter and myself is that the odds of little things like the above getting caught and fixed go up. But the document is ultimately the WG's responsibility and publishing it with that sort of error would be bad news, probably requiring issuing a revised document if anyone felt the change was substantive. So please read the thing and read it carefully. john From nobody Wed Mar 23 21:37:54 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98D12D1E6 for ; Wed, 23 Mar 2016 21:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh_JJVFw2CJB for ; Wed, 23 Mar 2016 21:37:50 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0095.outbound.protection.outlook.com [104.47.93.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCAB12D0E8 for ; Wed, 23 Mar 2016 21:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4MwLJyQmXLekJRy+D7a7zJhm/J3WFR0eq09LlP0aNL0=; b=NybiX9u9CMsYCYV9uKlhVe59iTvEhwhqZePWnPMFPdNkwN8WWYf3sbXPrAsQtzBytAmsehX9lzkRPhJk0jUDFqCakxhuK+lUxoTFewnC3yzFthpCRiDSsXXyxMvMPiIRskh/5lj9lWC1vyWtakhq8cyMpXgcSGjeAgMXm5pGNns= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0925.jpnprd01.prod.outlook.com (10.168.45.20) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 24 Mar 2016 04:37:46 +0000 To: John C Klensin , Peter Saint-Andre , References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> <56CA9AE6.5020307@it.aoyama.ac.jp> <56F209F7.70409@stpeter.im> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F36F1A.3000605@it.aoyama.ac.jp> Date: Thu, 24 Mar 2016 13:37:46 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0015.jpnprd01.prod.outlook.com (25.161.225.153) To TYXPR01MB0925.jpnprd01.prod.outlook.com (25.168.45.20) X-MS-Office365-Filtering-Correlation-Id: 9c926f14-e4d9-4e4e-a64f-08d3539e0c82 X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0925; 2:0Kh8aKQ/Vrel42ejLeBv0N47iFYiuRhK5C/WdAZmzBikl4Nlib5R8JtEcgH8yHu5KlEgzf8vrBiHB91HtHzjfbD1wiZGKNBU/KWF72iU69Y60f412Nz6nz/zH4r2QACS6qD73bVO+p2Xep8uOhKHD4GtD38jnanzZggzQ534hNKcsW9Q6ZCS1q48jYJCKors; 3:OpGWtUnlbKEZjAURQJThXhi+f/53eiG/Y0pmj5QrwS8rgHiQEcYdU/9JBMbyRYfiGjduRGn8DXYPXMX1Ne8MqdVpgXrdVjR+X5U8WlLK3qyM1T9bGHnyOG6f9kpNqKyA; 25:Oz4J9hb7fs5wqI45sQ4VP7IEojnj6oOxxOwWjYbSIxuERQVm5yuiSFeR4wf/Eafu2W3ow6URO2iBZ2ELEX78s2w9b/KTO8AN8S6AAsb/VHOm6526YQpX7OZLsoaN2ewkqzJ9CmC/L7ztdMM34orSA0/dB2jhFAsXomu9Hrd/IglbFvavAAfT131U05H2z1i/xc6Wl8W55mxvHZAQ9I8EWdcNxQgpI2NB/lQy2Ow58PX6X42xocoZ+kXDliWYYbp32crYC6X41OovY3WceO0frghhfAhD1xaTqK8gxPw+aRyZvgwdotWHmxZajYpEINmfz2JT6wZ14krOVN2qjBpC2nUZRvWKbXI8HfQlTh7mtDncFbQAtDLfhu/bVEiymkdgBpPqpbdAylLbYv3Ko7VjwFXJiF7KoD0gzySI7R1rgDZ4QAmlNb6172A9BzFVbuvUepsZ0l7M7GvFv3nH9c36KA0Gn5SKFAAPdWimveF0i+TFmxyV61xtbAlwHbx5sNB1nsucy4YIQDJ3p6Bh8BMmHafiwCWibhI+kneBM9NPhiI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0925; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6042046)(6043046); SRVR:TYXPR01MB0925; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0925; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0925; 4:6YCPeG1jJSGIKr7NjPWTpmj5Kpplz1xcdJTE3yc9cyppGX9/yOtjDlWTGmX0Cvf0U1oNXlUZhljb0JCYY4z2DtUhhe+Xt6hKzda39Z3dh6qnxdVuAEOVJykg1RjwRv+mjti6X09+4PvOMDinsI3NXJASH+RPlhrhinvhuF+ljmdkhUG1nEk+PINk3wo9H2Oqm3Gy97NjWJc20zrhfjShdqbNhAwIJ7e3GSlOnmcZKw5uLUCpHygmCbB4/K3DRv64XoDOzxoRym+5comniFbFQuWwllg/etzu+PQciq6BvewuYAu7X26Z4HFXDYK8GwZmxmuvVg5iBYynV0bMLyj5Bix7qByU/2E210pU+M/F1dp8p3FOLIRdbj5MGWvnYn1jErVlzUI5t7gDt/GxcEHvgUKtiZz3wssqZMW+80Bgs/4BxhK908xSjHuqQaY1oNoy X-Forefront-PRVS: 0891BC3F3D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(377454003)(24454002)(83506001)(66066001)(65806001)(86362001)(2870700001)(2906002)(5008740100001)(42186005)(59896002)(93886004)(107886002)(189998001)(65956001)(87266999)(76176999)(54356999)(92566002)(4001350100001)(23676002)(33656002)(5004730100002)(65816999)(3846002)(6116002)(64126003)(2950100001)(77096005)(50986999)(5001770100001)(586003)(81166005)(74482002)(19580405001)(19580395003)(50466002)(1096002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0925; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI1OzIzOlFPY0tQMktPM2QrSnRoMk5BYU1STm5nVmho?= =?utf-8?B?OUxxZWdtNlYxVnNsTDU0Wm1hSGp5Q0ZZMEVSMGl6Mml2SW5hRnBheERGdnRu?= =?utf-8?B?ejRCVjFBNFR1MUQyck9za2tmYjlIU25GRGJlU2pSUFFJeVNIRGZLaHRMSEFL?= =?utf-8?B?S2dWV2tTclRRLzQycHE1dnZyeU5TT2lCamZXazkwOTN0RmFSQmJHMnZIanYz?= =?utf-8?B?NmFpcXc3eXZ0bGNKQnF6aTZtcExCZW5ad3NmT0Y4UkVjMkN5MFJkalFic25l?= =?utf-8?B?cVRxaHRxd29ZL3BNWWtGTGowUUJ5U1JlSlRqTVFSaE5XNTVmWnlKUlVLNGlh?= =?utf-8?B?d2U4YXptQmRyNnY1NmVHZUNkYmlUcmdjeUZEYTFySVRXU3NUUm1BS0J3ZWE0?= =?utf-8?B?NVFKbnZzRXdXdlVhcWhycE02bWhuNU9LdTZEN2M2Z1diNnNmUjZwQ2ZlVEFV?= =?utf-8?B?N3Q3N2dGVm96OThWZThnSDNWUC9iWUdraFl6TDUyUHEzV2RKbERZVnY1K3Fu?= =?utf-8?B?RC9uT1pRUk83YjlXbDM0UnJsL0FSVkV6L1l3TFQvRnUwQ0hybGxHdmJGZXNN?= =?utf-8?B?a1V5OTJiNFYxTk1BRTJwdThCNmtZdEc0SWFULzh0ZWNMYzRwMlVRODBGMngy?= =?utf-8?B?d0VUMGpIaS9rU2tHcDJCSHVtQ0lMbndkS3pOOERqMXhSaERqdWFMMkJBbW1k?= =?utf-8?B?U0VCZ0ovdFV6d1IxZEY3cnhLV0MyVnVvN0RiVldQQ25mdCtZaXBNaGJ2NHpW?= =?utf-8?B?bzl4WllUUURQYk5jMnBDY3d6VW5IbDgvYjRmck52QzFEVFUwOTBYQVpUcktI?= =?utf-8?B?ZnR5SjUrS1NsM25BaXpscVlEVndiUmU0MGN0TXBQeUdQRjNFaFhrVlNaZWty?= =?utf-8?B?c3RWUzVrVE51cWF1TjIvbEk2WGJWV3VmNjg2bjNvNnlGMU1vSmg3K1FTbnNq?= =?utf-8?B?YUR0M042ZmtjRmlPZS9tTjVmVG9IQ0JsNEhVMVpVaG81RFY1eW9XWFE3UzBi?= =?utf-8?B?ei9QZUhXZVdEZ21zWHZqbzZ2WDBEakNlUk4rMnFwQlNReTZ2LzNiOGJOdDd2?= =?utf-8?B?YUROTkFoYWtDZWlnaGFQQVJCL1EvallTQmRlRzVnMjlwWWw0eEUyalpmMEMx?= =?utf-8?B?dkNFT1d5M3M2aVdBNFRua1FOSWFTNEJIQTE5amNlNnpWdXJxcmNYMGgxay9n?= =?utf-8?B?dGZ6TEh4QTQ0K0pYbTZLTm9KK2VlaTUxTnlJUkw4cEs3dUg0MHhjbjZHK3c0?= =?utf-8?B?cllrelNBZDhpTENnWlBYRDRyUWFQeVFsa0lxYkttVFlqV1ducmZhbzNiWURa?= =?utf-8?B?NU9nVFo2NkV2SWp0SkJseTJnVFl5QXJOUG1QcW1wd1I2WXJHWlRlTE91a09t?= =?utf-8?B?aE5OdFJxMGFvOGtUQk1lYzhUYnZzZ1p6Yzh1Q00zbHZGalR5L3hGR3VPRVU4?= =?utf-8?B?NzJCTmN2SGlKdHMxTjZmd3F5Uld4YlBwYUhQdzJsQ3BXbFUzcFZNVm9QTkJv?= =?utf-8?Q?7dPVZlzLuoarYtxgJt6WgufSI=3D?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0925; 5:/iIyWAox9f48f7pS4IK01rNhOX6OwM6b1xaiY+z27pmIO+p8gso88gDQAJ2ZWe3s73XYTXgiarxpXBfylPYmcYY7nUnwaHGirCXuGFf+0JP/SpMpXboXyGpNDcoL+V1UaBrnF0rLCO5yuGtLXSA8IQ==; 24:NigbhqZXdgYtr6+SpEhF/vDj06awCrvylnZ6C1qD6rViCF4TJ4HQEiKvljwYhA99m1md+ZVTtUqviA2+FDfjuxbARB9GgtnpKO8B57kTTvI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2016 04:37:46.4823 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0925 Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 04:37:53 -0000 [Comments further down.] On 2016/03/23 16:56, John C Klensin wrote: > > > --On Tuesday, March 22, 2016 21:13 -0600 Peter Saint-Andre > wrote: > > >> On 2/21/16 10:21 PM, Martin J. Dürst wrote: > >>> So at the most, I'd want to limit us to something like >>> "Namespace registrations MAY indicate some of the types of >>> resolvers suitable for the namespace (by listing the relevant >>> resolverIDs). Such a list does not restrict the use of >>> resolvers to only the listed types." >> >> That seems reasonable to me. > > > > Putting this in context with other discussions and trying to > retrofit it into the document, if we were to tear the resolverID > stuff out (a decision I don't think has been made yet), the > above would replace the second paragraph of Section 6.4.6 > (2141bis-15), which starts: > > "If resolution is intended, then this section SHOULD > specify whether the organization that assigns URNs > within the namespace intends to operate or recommend any > resolution services for URNs within that namespace...") > > with the above, with the parenthetical comment removed. > > That takes us to considerably less specificity than RFF 3406, > whose Section 4.3 describes differences in resolution/delegation > as part of the justification for creating/registering new URNs. > More important, the "Namespace Definition Template" in Appendix > A of 3406 has a rather specific requirement in a subsection that > begins: > > "Process for identifier resolution: > > If a namespace is intended to be accessible for global > resolution, it must be registered in an RDS (Resolution > Discovery System, see [RFC2276]) such as DDDS. Resolution > then proceeds according to standard URI resolution > processes, and the mechanisms of the RDS. What this > section should outline is the requirements for becoming a > recognized resolver of URNs in this namespace (and being > so- listed in the RDS registry)." > > Now, that came out because we dropped the RDS (and DDDS) > discussions. I assume that Peter or I (can't remember who) wrote > the new text to preserve something of the same "if the URN is > expected to resolve, you must provide some hint of where and how > to find an appropriate resolver" favor of the 3406 requirement. > Martin's suggested text above means, I think, that either: > > -- A new registration of a URN that is expected to be > resolved MAY provide no information about resolution or > resolution services for that namespace at all That was my intent, although in a spec, I'd write it positively: A new registration of a URN that is expected to be resolved MAY provide some information about resolution or resolution services for that namespace > or that > > -- An r-component is effectively required for any URN > that is to be resolved. > > We cannot intend the second if we are intending to leave > r-components for future standardization because it would result > in a considerable loss of functionality compared to the > 2141/3406 combination. Not only that, it would also mean that all currently URNs currently existing in the wild are unresolvable without further tweaking, which hopefully nobody would want. As far as I understand the intention behind r-components, their primary purpose is to be able to indicate resolution details if necessary, not to be a prerequisite for resolution. Also, it would heavily disadvantage URNs vs. URLs, which in most cases "just work". > I'm ok with the first interpretation and can try to make up (or > accept from someone else) some wording elsewhere in the document > that would make having a resolvable URN with no information > about resolution mechanisms or services (even a disclaimer that > punts the problem elsewhere) ok, but it seems drastic enough > that I wanted to check that is what the WG (and even Martin and > Peter) intend. Ah, I see, you (and maybe the WG) are afraid that without any explanations on how URNs in a namespace might actually get resolved, there's not much of resolvability left. That's a valid concern. I didn't consider that when I wrote the proposed text that's now at the start of this mail, because then I was just concerned with the wording about resolver types (which were connected to resolver IDs). If we are scaling down the text on resolvers and leave r-component details as "future work", then resolver IDs are no longer relevant. The text would then be meant in a much more generic fashion, i.e. "resolver types" being just a generic term, rather than something well-defined. But dropping the whole paragraph would also be fine. Regards, Martin. From nobody Thu Mar 24 10:00:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE512D5E0 for ; Thu, 24 Mar 2016 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEV9oM4dqTIA for ; Thu, 24 Mar 2016 10:00:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5E412D5D3 for ; Thu, 24 Mar 2016 10:00:11 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aj8c5-0001Nd-32; Thu, 24 Mar 2016 13:00:01 -0400 Date: Thu, 24 Mar 2016 12:59:56 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Peter Saint-Andre , urn@ietf.org Message-ID: In-Reply-To: <56F36F1A.3000605@it.aoyama.ac.jp> References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> <56CA9AE6.5020307@it.aoyama.ac.jp> <56F209F7.70409@stpeter.im> <56F36F1A.3000605@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 17:00:13 -0000 --On Thursday, March 24, 2016 13:37 +0900 "Martin J. D=C3=BCrst" wrote: >> I'm ok with the first interpretation and can try to make up >> (or accept from someone else) some wording elsewhere in the >> document that would make having a resolvable URN with no >> information about resolution mechanisms or services (even a >> disclaimer that punts the problem elsewhere) ok, but it seems >> drastic enough that I wanted to check that is what the WG >> (and even Martin and Peter) intend. >=20 > Ah, I see, you (and maybe the WG) are afraid that without any > explanations on how URNs in a namespace might actually get > resolved, there's not much of resolvability left. That's a > valid concern. Yes. That is the issue. Right now, if a URN is resolvable, we have a requirement that the registration say something specific about the mechanism to be used or how to find it. =20 > I didn't consider that when I wrote the proposed text that's > now at the start of this mail, because then I was just > concerned with the wording about resolver types (which were > connected to resolver IDs). Right. As I tried to say, my initial reaction was the same and I was very happy with your text. It was only after I tried to insert it into the document that I realized there was a problem. > If we are scaling down the text on resolvers and leave > r-component details as "future work", then resolver IDs are no > longer relevant. The text would then be meant in a much more > generic fashion, i.e. "resolver types" being just a generic > term, rather than something well-defined. >=20 > But dropping the whole paragraph would also be fine. Let's see if anyone else wants to comment... then I'll try to make a specific proposal. Of course, if all discussion of r-component is removed other than "future standardization", this particular part becomes easy because the existing text probably works. thanks, john