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

John C Klensin <john-ietf@jck.com> Thu, 07 January 2021 01:00 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6B3A141A; Wed, 6 Jan 2021 17:00:50 -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 HW-K82qiR6iV; Wed, 6 Jan 2021 17:00:48 -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 ACAFB3A1418; Wed, 6 Jan 2021 17:00:48 -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 1kxJfT-000B9i-32; Wed, 06 Jan 2021 20:00:47 -0500
Date: Wed, 06 Jan 2021 20:00:41 -0500
From: John C Klensin <john-ietf@jck.com>
To: Russ Housley <housley@vigilsec.com>, iot-directorate@ietf.org
cc: last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org
Message-ID: <B091AE313126430286B0902C@PSB>
In-Reply-To: <160996930502.21827.5533521556349871834@ietfa.amsl.com>
References: <160996930502.21827.5533521556349871834@ietfa.amsl.com>
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/iot-directorate/7qqfoO-jMuOIv7NHCFLr7fGl-hs>
Subject: Re: [Iot-directorate] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 01:00:51 -0000

Russ, Barry, 

Another small catch...

--On Wednesday, January 6, 2021 13:41 -0800 Russ Housley via
Datatracker <noreply@ietf.org> wrote:

> Nits:
> 
> Section 3.2 says:
> 
>    However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV
> URNs    do not support percent-encoding.
>    
> This does not seem like a "however" statement to me.  Perhaps,
> it is a "Note that" statement.  Or, just drop "However".

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.  I can't
speak to what the URNBIS WG would have done had it been allowed
to consider the options that might have been opened by
developing different requirements for locators and names and, in
particular, whether any such changes would have affected
percent-encoding.   However, it was painfully clear that no URN,
much less any particular URN namespace definition, can alter
those rules.

At this point, the most obvious option would be to change the
statement in  draft-ietf-core-dev-urn to note that the RFC 3986
rules apply and explain (inline or by reference) how
percent-encoding works.  Such a statement might explain that,
given the characters permitted in RFC 8428 Section 4.5.1,
percent-encoding should never be necessary within a DEV URN.
However, because the list in 8428 includes characters that are
defined as "Reserved Characters" in Section 2.2 of RFC 3986,
notably including ":" and "/", the possibility of their being
percent-encoded by some process allowed by 3986 cannot be
eliminated.  

Other alternatives involve updating RFC 8141 and 3986, but I
wouldn't recommend going there, especially if the CORE WG would
like to see the current spec published in 2021.  The narrowest
of those updates would be to change the rather relaxed-sounding
language of RFC 3986 Section 2.1: 

	"used to represent a data octet in a component when that
	octet's corresponding character is outside the allowed
	set or is being used as a delimiter of, or within, the
	component."

To say that percent-encoding MUST NOT be used unless actually
required, but I'd guess that would not go over well with
existing implementations.   

Or, I suppose, the IESG could decide either that 3986 does not
count or that an interpretation that disallowed URN namespaces
prohibiting things that it allows is incorrect.  But someone
would probably take that as a commitment to allow a revision to
8141 that would codify the options that would imply.

     john

p.s. This not being spotted earlier may be a contribution to the
discussion that is now occurring on the IETF list of early
cross-area review and how important it is to facilitate, rather
than discourage, such reviews.  Or not.