Re: [art] Question regarding RFC 8089

John C Klensin <john-ietf@jck.com> Wed, 19 December 2018 00:18 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 4C29A130DC7 for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 16:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 LiZzVxotPZBw for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 16:18:56 -0800 (PST)
Received: from bsa2.jck.com (bsa2.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 1704E130DC0 for <art@ietf.org>; Tue, 18 Dec 2018 16:18:56 -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 1gZPZe-000PNp-6f; Tue, 18 Dec 2018 19:18:54 -0500
Date: Tue, 18 Dec 2018 19:18:48 -0500
From: John C Klensin <john-ietf@jck.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
cc: art@ietf.org
Message-ID: <F86BD9E36E8FFD27F53B2CA2@PSB>
In-Reply-To: <c3075627-59d6-c398-8e07-f22f37dca1bf@alum.mit.edu>
References: <f49638dc-4a0e-e03d-7e91-b968a1217679@redhat.com> <CACweHNBps_O0JqAUFj5FD3V+LzbTWUKNKuFzKk82WR+33b8seA@mail.gmail.com> <45967886-f3f4-12b8-75b7-2b9199e59bfa@gmx.de> <114E58B9-0CB4-4B98-B6C8-D2B84879EE6B@mnot.net> <1FC45B47B703AED3FAE346F4@PSB> <19f1968e-e110-e26f-7639-bf57605f940e@it.aoyama.ac.jp> <43cc02ad-9ff0-bdd6-47a7-ae7ed24f0921@nostrum.com> <1BC0BB52B4D6D8E19665949A@PSB> <c3075627-59d6-c398-8e07-f22f37dca1bf@alum.mit.edu>
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/jRqZqSH_p9-d8DxIT4vZ8eEU474>
Subject: Re: [art] Question regarding RFC 8089
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, 19 Dec 2018 00:18:57 -0000


--On Tuesday, December 18, 2018 13:49 -0500 Paul Kyzivat
<pkyzivat@alum.mit.edu> wrote:

> On 12/18/18 12:48 PM, John C Klensin wrote:
> 
>> In addition to the above, URNs add another complexity to the
>> discussion: RFC 2141 rather explicitly forbade fragments (and
>> specifically the "#" character) for use in "urn:" URIs,
>> reserving that character for future use.   Objections were not
>> raised at the time and 3986 does not update 2141 to change
>> that rule, so, while the default may be "yes", there is
>> certainly precedent for schemes banning the use of fragments.
>> (Of course, for URNs, RFC 8141 removed that restriction but
>> did it explicitly.)
> 
> Perhaps this should have simply been considered a statement of
> fact rather than a normative requirement. Since the URN is a
> name rather than a value, there is nothing for a fragment to
> reference.
> 
> Similar arguments would apply to TEL, SIP, and some of the
> others.

In the case of URNs, it is more complicated than that.   While
some URN namespaces involve names and not objects (e.g., a
namespace could be set up as part of a registration procedure to
ensure uniqueness) others are object identifiers although
usually more abstract ones than traditional HTTPS URLs.  To use
an overused example, a URN for an ISBN namespace identifiers a
book, but in somewhat abstracted form because any book with the
number will satisfy an unadorned query.  One might even resolve
the URN into a URL that described exactly where to find the
book.  However, a fragment identifier associated with an ISBN
URN makes perfectly good sense to point to, e.g., a chapter of
the book although there are some messy issues associated with
whether the fragment identifier refers to the the URN itself or
to the object to which the URN points through one or several
levels of abstraction.  Getting that right is not obvious, but
that doesn't make the fragment on the URN any less reasonable.
See RFC 8141 from a more extensive discussion of these issues.

I do, however, agree with your "statement of fact" observations
about SIP, TEL, etc.

best,
   john