Re: [art] Question regarding RFC 8089

John C Klensin <john-ietf@jck.com> Tue, 18 December 2018 17:48 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 CF42B131186 for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 09:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 WhRH-Z2n2_QZ for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 09:48:29 -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 12625131185 for <art@ietf.org>; Tue, 18 Dec 2018 09:48:29 -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 1gZJTf-000Njc-6t; Tue, 18 Dec 2018 12:48:19 -0500
Date: Tue, 18 Dec 2018 12:48:13 -0500
From: John C Klensin <john-ietf@jck.com>
To: Adam Roach <adam@nostrum.com>
cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Mark Nottingham <mnot@mnot.net>, "Julian F. Reschke" <julian.reschke@gmx.de>, "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, Matthew Kerwin <matthew@kerwin.net.au>, Stephan Bergmann <sbergman@redhat.com>
Message-ID: <1BC0BB52B4D6D8E19665949A@PSB>
In-Reply-To: <43cc02ad-9ff0-bdd6-47a7-ae7ed24f0921@nostrum.com>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/plduB6GZSe7vvIz6EYuFxzCm6Z0>
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: Tue, 18 Dec 2018 17:48:31 -0000


--On Tuesday, December 18, 2018 11:24 -0600 Adam Roach
<adam@nostrum.com> wrote:

> On 12/18/18 2:53 AM, Martin J. Dürst wrote:
>> The 'mailto:' scheme is about as non-standard an URI scheme
>> as there is,
> 
> Just for clarification, I'm not sure that's true. Off the top
> of my head, schemes like 'sip:' 'tel:', 'xmpp:', 'im:',
> 'iax:', 'jabber:', 'h323:', 'msrp:', 'pres:', 'sms:', 'mms:',
> and their various secure variants have very similar properties
> for the purposes of this conversation (and that's ignoring a
> host of provisional schemes like 'aim:' and 'facetime:').

Adam, you might have added "urn:", which has the added
distinction of being a name rather than a locator.   

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.)

best,
   john