Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
John C Klensin <john-ietf@jck.com> Wed, 08 January 2020 05:08 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E20120041; Tue, 7 Jan 2020 21:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 dwM6zHv61ByI; Tue, 7 Jan 2020 21:08:47 -0800 (PST)
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 BCA8B120025; Tue, 7 Jan 2020 21:08:47 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ip3aC-000A6x-Tu; Wed, 08 Jan 2020 00:08:40 -0500
Date: Wed, 08 Jan 2020 00:08:34 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@mozilla.com>, Adam Roach <adam@nostrum.com>, iesg@ietf.org
cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org
Message-ID: <83F6216862324B84D43C9280@PSB>
In-Reply-To: <f082480f-d114-4c97-5c54-4caeebe66acd@mozilla.com>
References: <87E116C31DAF1434C3C3937F@PSB> <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com> <444B2465A9B73F3D0DE59FFF@PSB> <f082480f-d114-4c97-5c54-4caeebe66acd@mozilla.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: <https://mailarchive.ietf.org/arch/msg/art/ParjA7Gpx99tNE6Bo1TfzR2PEtE>
Subject: Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 05:08:50 -0000
--On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre <stpeter@mozilla.com> wrote: >... >> If >> you want to ask the slightly different question of whether, if >> RFC 7320 made things worse, does this I-D make things even >> worse than that, I don't have an easy answer except to note >> at least one example: The last paragraph of Section 2.3, >> which appears to be new, says >> >>> Extensions MUST NOT define a structure within individual URI >>> components (e.g., a prefix or suffix), again to avoid >>> collisions and erroneous client assumptions. >> >> But, as I understand that rule, it is precisely what some >> rules, and provisions for namespace-specific rules, in RFC >> 8141, do. > > It's not clear to me whether a URN namespace counts as a > 7320bis protocol extension (which can "offer new capabilities > that could apply to any identifier, or to a large subset of > possible identifiers"); however a definition of, say, URN > r-components would probably fit the bill, and such a > definition might well define structures that would violate the > aforementioned MUST NOT. I was trying to avoid getting dragged down into details, both in the hope of keeping the message as short as possible and to avoid a distracting side-discussion, but, yes r-components and the issues associated with pass-through information for those URN namespaces that resolve to one or more URLs were examples that crossed my mind. >> Again, the solution at this point appears to be either to be >> much more careful about binding the statements in the I-D to >> the concept of ownership or to indication that this >> specification does not apply to URNs (or, if preferred, to >> what 3986 describes as "name" URIs) at all. > > That might be the best approach. If we don't want both the discussion and the document to drag out, I believe so. best, john
- Re: [art] URNs and Last Call: <draft-nottingham-r… Phillip Hallam-Baker
- [art] URNs and Last Call: <draft-nottingham-rfc73… John C Klensin
- Re: [art] URNs and Last Call: <draft-nottingham-r… Michael Richardson
- Re: [art] URNs and Last Call: <draft-nottingham-r… Adam Roach
- Re: [art] URNs and Last Call: <draft-nottingham-r… Barry Leiba
- Re: [art] URNs and Last Call: <draft-nottingham-r… John C Klensin
- Re: [art] URNs and Last Call: <draft-nottingham-r… Phillip Hallam-Baker
- Re: [art] URNs and Last Call: <draft-nottingham-r… Christian
- Re: [art] URNs and Last Call: <draft-nottingham-r… Larry Masinter
- Re: [art] URNs and Last Call: <draft-nottingham-r… Phillip Hallam-Baker
- Re: [art] URNs and Last Call: <draft-nottingham-r… Peter Saint-Andre
- Re: [art] URNs and Last Call: <draft-nottingham-r… S Moonesamy
- Re: [art] URNs and Last Call: <draft-nottingham-r… John C Klensin
- Re: [art] URNs and Last Call: <draft-nottingham-r… Adam Roach
- Re: [art] URNs and Last Call: <draft-nottingham-r… S Moonesamy
- Re: [art] URNs and Last Call: <draft-nottingham-r… Dale R. Worley
- Re: [art] URNs and Last Call: <draft-nottingham-r… John C Klensin
- Re: [art] URNs and Last Call: <draft-nottingham-r… Mark Nottingham
- Re: [art] URNs and Last Call: <draft-nottingham-r… John C Klensin
- Re: [art] URNs and Last Call: <draft-nottingham-r… S Moonesamy