Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09

Jari Arkko <jari.arkko@piuha.net> Tue, 12 January 2021 22:21 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36463A12D1; Tue, 12 Jan 2021 14:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Q45HTfKvn5HA; Tue, 12 Jan 2021 14:21:06 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id C55383A12CF; Tue, 12 Jan 2021 14:21:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 27D1666012A; Wed, 13 Jan 2021 00:21:05 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiBfbtkaEAVK; Wed, 13 Jan 2021 00:21:03 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 8BAD36600A2; Wed, 13 Jan 2021 00:21:03 +0200 (EET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <B091AE313126430286B0902C@PSB>
Date: Wed, 13 Jan 2021 00:21:03 +0200
Cc: Russ Housley <housley@vigilsec.com>, iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net>
References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <B091AE313126430286B0902C@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/47fkBn-Pon0bSuk7T6nfG3r1n9U>
Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2021 22:21:08 -0000

Hi John, nice to hear from you. Inline:

> Sorry I, or someone in the URN registration review process,
> didn't catch this, but I think it is a little more complicated
> than a nit.  When what became RFC 8141 was being developed,
> several people made very clear to the WG that there was no
> possible way for a URN specification to make an exception to the
> syntax rules for URIs, including the rules about
> percent-encoding in Sections 2.1 and 2.4 of RFC 3986.  

Thanks for bringing this point up. 

I’m not entirely sure that if we dug deeper, what the actual precedence rules between requirements from different RFCs would be*. Be that as it may, I’m not sure we need to have that debate.

How would people feel about the following text which I think describes the correct situation with respect to the percent encoding in DEV URNs, and does not claim to change any rules on 8141:

   … Due to the SenML RFC 8428
   Section 4.5.1 rules, it is not desirable to use percent-encoding in
   DEV URNs, and the subtypes defined in this specification do not
   really benefit from percent-encoding.  However, this specification
   does not deviate from the general syntax of URNs or their processing
   and normalization rules as specified in [RFC8141].

This text is in my soon-to-be-submitted version -10, available here:

   https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html

Jari

*) One could for instance also argue that all URN subtype specifications are narrowing down of the general syntax, although one might equally well point out that there are some real-life limitations of e.g. software processing that occurs before handing a URN to a particular module, which might dictate that some general URN processing rules are adhered to. Or there’s some other reason that prevents the particular narrowing down that’s in -09.