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> Thu, 09 January 2020 06:21 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 7AEC9120118 for <art@ietfa.amsl.com>; Wed, 8 Jan 2020 22:21:42 -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 x4hFNsYBEor9 for <art@ietfa.amsl.com>; Wed, 8 Jan 2020 22:21:40 -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 C7FF5120020 for <art@ietf.org>; Wed, 8 Jan 2020 22:21:40 -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 1ipRCE-000DhG-Ju; Thu, 09 Jan 2020 01:21:30 -0500
Date: Thu, 09 Jan 2020 01:21:24 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mark Nottingham <mnot@mnot.net>
cc: Adam Roach <adam@nostrum.com>, S Moonesamy <sm+ietf@elandsys.com>, art@ietf.org
Message-ID: <3997764BF11775ABCD720F02@PSB>
In-Reply-To: <0384BB91-938A-4EFC-95AD-0BBDD14EC485@mnot.net>
References: <87E116C31DAF1434C3C3937F@PSB> <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com> <6.2.5.6.2.20200107163256.0f2810b8@elandnews.com> <9eda86bf-a31d-a45f-ac8c-98cb7f38e9d1@nostrum.com> <36528CF21FDE2B32FA1E3C06@PSB> <0384BB91-938A-4EFC-95AD-0BBDD14EC485@mnot.net>
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/trk5arFDIJTfgP3ZpXukrltqf04>
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: Thu, 09 Jan 2020 06:21:42 -0000


--On Thursday, January 9, 2020 15:41 +1100 Mark Nottingham
<mnot@mnot.net> wrote:

> John,
> 
> In my mind (albeit containing limited knowledge of URNs),
> exempting URNs isn't the right solution, because they
> potentially face the same issues as more traditional URIs.
> 
> For example, if someone were to come along and say "the string
> 'foo' in fragment identifiers is magical", that would affect
> URNs as well, probably to their detriment unless the proper
> work were done.
> 
> Of course, if the definition of a particular NID or whatever
> allowed such a thing to be done, it would be fine -- within
> that scope -- and I think that's already covered by the draft.
> 
> Likewise, if URNs want to define special conventions overall
> for URNs, that's also within scope -- provided that the scheme
> is updated properly.
> 
> If this isn't clear enough in the document, I'm happy to make
> it so.

Mark, I don't think it is clear enough in the document.  To a
certain extent, what you've said above is that a rather
different way of looking at all of this is that scope of control
associated with various bits of URIs is very important and one
has to be quite clear about scope of control and what those
scopes cover (possibly with different answers for different URI
components and/or schemes).  

I also suggest that interpretation, and at least some of what
you write above, is problematic given Barry's reading and
interpretation that the whole document does not apply to URNs
(and maybe not to other things that share some of the properties
of URNs) because of lack of hierarchy, at least at the scheme
level.

It seems to me that, in turn, takes us squarely into the middle
of the problem that Adam is trying to avoid, which is going back
and reexamining the basic assumptions and structure of the text
rather then, e.g., applying a simple patch about scope.  While
the copies to the IETF and IESG lists have been removed, I hope
and trust someone will make non-ART IESG members aware of that
direction before the teleconference.

If there is really the urgency to get this approved and done
that Adam seems to believe there is, this is really unfortunate
and I apologize for my part in it.

best,
  john