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