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

worley@ariadne.com (Dale R. Worley) Thu, 09 January 2020 03:47 UTC

Return-Path: <worley@alum.mit.edu>
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 40F45120020 for <urn@ietfa.amsl.com>; Wed, 8 Jan 2020 19:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level:
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 aePEao62Q5md for <urn@ietfa.amsl.com>; Wed, 8 Jan 2020 19:47:38 -0800 (PST)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 3F710120108 for <urn@ietf.org>; Wed, 8 Jan 2020 19:47:38 -0800 (PST)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id pOCZiLxu00LOmpOnJihLCU; Thu, 09 Jan 2020 03:47:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1578541657; bh=LIk+nGUmj9dsh+ZllqFYe2TKFOBNhhqyibgS4JuJ380=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=KtBSqE7P6oIHwAPzpTfou0HVGqIUDVR7Hmnq7eoBbdKXm//V8oLPej6aF0pirHR5L WxPM6AR0ti7c36LSp1g4Bpb7rGGl+ata1XuBMEFjVYWswtUNED0INuMeZcm3f9+De5 LYX8NjWwRNCSV+vhZDxpVH48Q5+hn3GxoyFUUokOy2lEoj5l0/PPWiNIiGFpMXIyVG 0T7In1B6T1ZEzrlFtsxFCc/cyK9zv642B8DIgl2KWf8FJebW37azRwSWH20JaeNtLs X1XONRIqWBeFdZG0G1oAvrLZn76h5zkrNsOmNnfvEul33C7j3kd9N+8x+AZy/UijeL P95E0Cz2NoUDA==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-08v.sys.comcast.net with ESMTPA id pOnHim3Bday2upOnIiO4Wu; Thu, 09 Jan 2020 03:47:36 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
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 0093lY5M014578; Wed, 8 Jan 2020 22:47:34 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0093lYv6014573; Wed, 8 Jan 2020 22:47:34 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: art@ietf.org, mnot@mnot.net, urn@ietf.org
In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> (john-ietf@jck.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 08 Jan 2020 22:47:33 -0500
Message-ID: <874kx58f56.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/I3kx9xX6U2bTySnyk-6HP9D7izQ>
Subject: Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 03:47:43 -0000

I am surprised to read a document that is marked "best current practice"
but filled with MUST and MUST NOT specifications.  I expect "best
current practice" to be advisory.  However, perhaps I am not
understanding the IETF use of BCP.  But this document does claim the
right to override any existing RFC, which seems to be excessive unless
the document receives very wide vetting and approval:

   There may be existing IETF specifications that already deviate from
   the guidance in this document.  In these cases, it is up to the
   relevant communities (i.e., those of the URI scheme as well as that
   which produced the specification in question) to determine an
   appropriate outcome; e.g., updating the scheme definition, or
   changing the specification.

As a nit, there is a reference to "BCP115":

   [BCP115]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 115,
              RFC 4395, February 2006,
              <https://tools.ietf.org/html/bcp115>.

but my copy of bcp-index.txt says:

0115 [BCP number 115 is retired. It was mistakenly assigned to RFC
     4395. RFC 4395 is BCP 35.]

And I think the name/locator distinction is easy to overemphasize.  It
is often useful, but instead of trying to hammer all applications into a
single theoretical structure separating "names" and "locators", it's
less error-prone and more useful to examine each instance of the
distinction individually in the context within which it will operate, at
which point all sorts of knotty theoretical problems have obvious
solutions.

Getting down to the substance of this document, it seems to largely be
about how ownership of subsets of the universe of URIs is delegated.  We
intend the delegation to look something like:

    URIs->              (owned by the IETF)
        schema->        (owned by the IETF)
            namespace->       (e.g. owned by the URN experts)
                authority->   (owned by the domain registrant)
                    path prefixes->    (owned by the operator of the host)
                        resources      (owned by the application instance)

The problem arises when a single instance of an "application" demands a
particular structure for the URI subset delegated to it, but we expect
the instance's owner to be unwilling/unable to delegate a subset with
that structure, e.g., because the subset demands a particular path
prefix or a particular form of authority, or uses query parts in
specific ways that might not be supported by the instance owner's
preferred deployment method.

So it might be useful to express these rules more explicitly in terms of
delegeated URI subsets, and to say what sort of URI subsets an
application instance can reasonably demand to be delegated to it and
which it cannot.

Dale