Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

John C Klensin <> Wed, 08 January 2020 05:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57E20120041; Tue, 7 Jan 2020 21:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dwM6zHv61ByI; Tue, 7 Jan 2020 21:08:47 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCA8B120025; Tue, 7 Jan 2020 21:08:47 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) 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 <>
To: Peter Saint-Andre <>, Adam Roach <>,
Message-ID: <83F6216862324B84D43C9280@PSB>
In-Reply-To: <>
References: <87E116C31DAF1434C3C3937F@PSB> <> <444B2465A9B73F3D0DE59FFF@PSB> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2020 05:08:50 -0000

--On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre
<> 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.