Re: [urn] NEW NAMESPACE REGISTRATION: KNX
worley@ariadne.com Mon, 04 September 2023 19:06 UTC
Return-Path: <worley@alum.mit.edu>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B5C137392 for <urn@ietfa.amsl.com>; Mon, 4 Sep 2023 12:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Level:
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX9kh3mqYkQU for <urn@ietfa.amsl.com>; Mon, 4 Sep 2023 12:05:57 -0700 (PDT)
Received: from resqmta-a1p-077437.sys.comcast.net (resqmta-a1p-077437.sys.comcast.net [96.103.146.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FE6C137393 for <urn@ietf.org>; Mon, 4 Sep 2023 11:56:56 -0700 (PDT)
Received: from resomta-a1p-077053.sys.comcast.net ([96.103.145.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-a1p-077437.sys.comcast.net with ESMTP id dDwfqYuV9vy0PdEitq9HjU; Mon, 04 Sep 2023 18:54:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1693853695; bh=pPEbhZr3shjESP9vc020GTcKXdsXHNcG8iCbXfvDLE8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=MTPeZUsY+QwBmOGMqVLcHbRvxrUfcivbl0yt7uFAXo4PIlZLoA4cnUy3G7pQzRfug J+Kvv4KkBDQIzd0LiVnCkwVWFkeEYcUK7m3wIxVGBmHgVOzFEcZjdsTzYSbc333uNi 8uIlsE8v+wNP6W34sQ9k5ExcMWy5mXWTG2ncW7sxWgG5fV+5qB/n2AsPtGuAqiADmU sMA4MaJRNam2Uln85VYRWzRhWbtt3HNyNLcbnu+fJ491Jw4VUIgpV8z/xbNnXs9usS EJEGoUaozpD+PW4UN873ySMqnAONenSxkr6aBS8ileLr1mJBgpkoqPlIEGpb2vtBNW B077zUjY3PZ4A==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::62d7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-a1p-077053.sys.comcast.net with ESMTPA id dEiTq31JGmr8DdEiTq6Hkg; Mon, 04 Sep 2023 18:54:32 +0000
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 384IsSL72857752 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 4 Sep 2023 14:54:29 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 384IsSsE2857749; Mon, 4 Sep 2023 14:54:28 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Michael Critchfield <michael.critchfield@knx.org>
Cc: urn@ietf.org, joost.demarest@knx.org, ahaenel@knx.org, steven.debruyne@knx.org, w.vanderbeek@cascoda.com
In-Reply-To: <AS8P251MB0199DFD95358D7D57EE51BBEFFE6A@AS8P251MB0199.EURP251.PROD.OUTLOOK.COM> (michael.critchfield@knx.org)
Sender: worley@ariadne.com
Date: Mon, 04 Sep 2023 14:54:28 -0400
Message-ID: <87v8cp93bv.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/fibSQeSSq5rBcaBDVY4Awjvo_6g>
Subject: Re: [urn] NEW NAMESPACE REGISTRATION: KNX
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Sep 2023 19:06:02 -0000
Michael Critchfield <michael.critchfield@knx.org> writes: > As KNX Association cvba, we would like to register the following > Namespace from our KNX IoT Point API Specification with you for > listing in Uniform Resource Names (URN) Namespaces > Reference is our KNX IoT Point API Specification available on > https://schema.knx.org. Specifically, the KNX IoT Point API > Specification is found under this link > https://knxcloud.org/index.php/s/KNjAyyO0ojm5LSc/download. Looking quickly at "KNX IoT Point API" and the definitions/uses/examples of urn:knx therein, I see urn:knx:dpa.321.51 urn:knx:dpa.352 urn:knx:dpa.352.51 urn:knx:dpa.352.55 urn:knx:dpa.<functionalblock-id>.<property-id> urn:knx:dpt.<stuff> urn:knx:dpt.binaryValue urn:knx:fb.0 urn:knx:fb.321 urn:knx:fb.auth urn:knx:fb.swu urn:knx:g.<group-type>.<group-address> urn:knx:g.p.1 urn:knx:g.s urn:knx:g.s.1234 urn:knx:g.s.<group-address> urn:knx:ia.21 urn:knx:ia.22 urn:knx:if.o urn:knx:if.pm urn:knx:<namespace-specific-identifier> which we can use to get some idea of how urn:knx is intended to be used. Let me note that the document is inconsistent about how meta-components are designated. Some are given as <...>, some are given as {...}, and some are begun and ended with nonmatching characters. (In the above list, I've normalized all of them to <...>, which seems to be the intended form.) Particularly, please check lines 271, 912, 1608, and the last column of the "ga" row of the table at the top of page 61. Generally, we want the namespace application to provide some description of how namespace-specific-identifiers are expected to be formed and used, but in this case, it appears that the number that will be specified will be small (as opposed to, say, open-ended assignment by multiple users), so I don't see a need for detailed specification of what patterns are expected. Ted Hardie <ted.ietf@gmail.com> writes: > First, you probably want to update the reference within it to RFC 8141 > and you probably should review in particular section 4.3, which > discusses using relative references with URNs. Your document discusses > "relative URNs" in a way that I don't think quite matches the RFC 8141 > approach. Please note that "you probably want to" is a polite phrase; since RFC 2141 was obsoleted by RFC 8141, all registrations must be done using the template and procedures of RFC 8141. So you're going to have to update your template and it would be best to update the reference in the KNX document. In regard to "relative URNs", comparing the KNX document line 272 ("Relative URN without namespace identifier (with ":" at the beginning)") with RFC 8141 section 4.3 ("URNs and Relative References") and RFC 3986 (the syntax of "relative-ref"), I see that relative URNs (in the KNX sense) *must* start with ":", but relative URIs (in the IETF sense) *never* start with ":". So though we might consider the KNX definition confusing, there is no contradiction, as syntax distinguishes whether a "relative URN" is to be interpreted per KNX or per RFC 3986. Dale
- [urn] NEW NAMESPACE REGISTRATION: KNX Michael Critchfield
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Ted Hardie
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Ted Hardie
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Michael Critchfield
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Lars G. Svensson
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX worley
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Martin J. Dürst
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Julian Reschke
- [urn] "relative URNs" Peter Saint-Andre
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Peter Saint-Andre
- Re: [urn] "relative URNs" John C Klensin
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX worley
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX John C Klensin
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Peter Saint-Andre
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Michael Critchfield
- Re: [urn] NEW NAMESPACE REGISTRATION: KNX Peter Saint-Andre