Re: [Iot-directorate] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09
John C Klensin <john-ietf@jck.com> Wed, 13 January 2021 00:16 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 F38EF3A14AA; Tue, 12 Jan 2021 16:16:14 -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 9GfaARhh_1CN; Tue, 12 Jan 2021 16:16:13 -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 DDC253A14B4; Tue, 12 Jan 2021 16:16:12 -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 1kzTpZ-0009g5-EB; Tue, 12 Jan 2021 19:16:09 -0500
Date: Tue, 12 Jan 2021 19:16:03 -0500
From: John C Klensin <john-ietf@jck.com>
To: Jari Arkko <jari.arkko@piuha.net>
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
Message-ID: <D8003464FF064C592F73FB65@PSB>
In-Reply-To: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net>
References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <B091AE313126430286B0902C@PSB> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net>
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/iot-directorate/mIVEvvCLAGlx4WLYrPlpg7kXwf8>
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: Wed, 13 Jan 2021 00:16:15 -0000
Jari, I think that your proposed text is ok. Some more detailed comments inline below, probably more for information than a suggestion for further changes but others may disagree... --On Wednesday, January 13, 2021 00:21 +0200 Jari Arkko <jari.arkko@piuha.net> wrote: > 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. In general, I would agree that precedence rules are often debatable. However, 3986 asserts that URNs are a type of URIs, something the URN WG did not seriously consider trying to change (and, I'm convinced, would not have been allowed to change had it wanted to). And draft-ietf-core-dev-urn asserted that these are, after all, URNs. Now suppose that, instead, the document had been titled "FiddleFrobs for Device Identifiers". Then I think the WG could have had (and probably would have been forced into) an absolutely fascinating discussion as to whether FiddleFrobs where really URIs in disguise and hence should be bound by 3986 and, if so and they were name-type URIs, whether they were URNs or some other name-type creature [1]. Personally, the only thing I've confident about in terms of such a discussion is that I would want to be as far away from it as possible. > 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]. As I said above, I think it works. However, since the rules that set this discussion off are actually in 3986, I'd be slightly more comfortable, and I think it would serve your readers better in the long run, if you referenced 3986 as well as 8141. I don't think there is any point in going further than that, e.g., by identifying the sections involved. > 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.d > iff.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. But that is similar or identical to the arguments the URNBIS WG tried to make vis-a-vis 3986, i.e., that we could take what 3986 allowed and further restrict the syntax and/or provide more specific interpretations of semantics. As I suggested, and Martin Dürst affirmed, that didn't get us very far. I strongly suggest that you take your proposed paragraph above (preferably with the additional reference), run with it, and put this little blip behind you and behind the WG :-) best, john [1] See Section 1.1.3 of RFC 3986.
- [Iot-directorate] Iotdir telechat review of draft… Russ Housley via Datatracker
- Re: [Iot-directorate] Iotdir telechat review of d… Barry Leiba
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… John C Klensin
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Martin J. Dürst
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Russ Housley
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Barry Leiba
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Russ Housley
- Re: [Iot-directorate] Iotdir telechat review of d… Ãric Vyncke (evyncke)
- Re: [Iot-directorate] Iotdir telechat review of d… Jari Arkko
- Re: [Iot-directorate] Iotdir telechat review of d… Dave Thaler
- Re: [Iot-directorate] Iotdir telechat review of d… Dave Thaler
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Russ Housley
- Re: [Iot-directorate] Iotdir telechat review of d… Jari Arkko
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Jari Arkko
- Re: [Iot-directorate] Iotdir telechat review of d… Carsten Bormann
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Jari Arkko
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Russ Housley
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… John C Klensin
- Re: [Iot-directorate] [Last-Call] Iotdir telechat… Jari Arkko
- Re: [Iot-directorate] [core] [Last-Call] Iotdir t… Carsten Bormann
- Re: [Iot-directorate] [Last-Call] [core] Iotdir t… Jari Arkko
- Re: [Iot-directorate] [Last-Call] [core] Iotdir t… Russ Housley