Re: [urn] URN Namespace Registration Request for "PNO"
worley@ariadne.com Mon, 15 April 2024 18: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 515B8C14CE53 for <urn@ietfa.amsl.com>; Mon, 15 Apr 2024 11:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.982
X-Spam-Level:
X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, 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 2XVD7mRNlQGp for <urn@ietfa.amsl.com>; Mon, 15 Apr 2024 11:06:37 -0700 (PDT)
Received: from resqmta-c2p-569298.sys.comcast.net (resqmta-c2p-569298.sys.comcast.net [96.102.19.36]) (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 E3A47C15106E for <urn@ietf.org>; Mon, 15 Apr 2024 11:06:07 -0700 (PDT)
Received: from resomta-c2p-539727.sys.comcast.net ([96.102.18.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-569298.sys.comcast.net with ESMTPS id wNRsrqnJ9fULQwQgYrxOpz; Mon, 15 Apr 2024 18:04:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1713204246; bh=LNpbMsh3fRbRVxurEHGFMPJ/hbEWH5Frrpd1kEhy3ik=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=MCU1hP80/H+h+dR4fMjegi4t4W/qmo6/sLp/Ikh1yKmz7CFvE1Vhkx1DhX8xUa2kx BR5m5J0Pw61TvGKNbXyrklRaljBLharf6cinLo/8EhmnqTYUFewtPwSRoyQl5u8vpR wv3Zum8vpdC7UzwEhGuPMdBMpWxkzZCqJJVbZBMgQD0sXwg3hawzmPFVUlb1S1NIQS Zf4rwcHXKh8Lqe11S/W2RE2Wtf2jm9c/HGf5N1p1g/Q3C8NZrIQHmqkHYxBTCr81VS GQ7pvcLR7HHXkLmYtkUkKcmDkILkA6qxc7cdq/5NQkYDol16GRsBQvJ+q6mBJkiZze GbfgtWpMMKaow==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::5cc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-539727.sys.comcast.net with ESMTPSA id wQgCr7D2MGQGewQgDrQSq9; Mon, 15 Apr 2024 18:03:45 +0000
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 43FI3hfJ4128746 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 15 Apr 2024 14:03:44 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 43FI3hle4128743; Mon, 15 Apr 2024 14:03:43 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: "Steindl, Guenter" <guenter.steindl=40siemens.com@dmarc.ietf.org>
Cc: urn@ietf.org
In-Reply-To: <PR3PR10MB40299B1911F1D947DC8F66D7E6092@PR3PR10MB4029.EURPRD10.PROD.OUTLOOK.COM> (guenter.steindl=40siemens.com@dmarc.ietf.org)
Sender: worley@ariadne.com
Date: Mon, 15 Apr 2024 14:03:43 -0400
Message-ID: <87v84i5wqo.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4xfLpUXqN+C7BKmpBjuY3NosiZfvy2ybtxkLnQEZjbOJXikzilXdCjz36D2SSE0vS8N/3+R2E9FX/IndYAGlRbmBREiYuhXDWNMUagZmRI+TH0VkEmm2fX p8rg2xIsp0edo68FF2ruN9li0B/zjc0Nl6PuB91EEVBEQi3/Mp55Eo5ITREZ9RZuICzJpDpqEikIVbGPC1l+qgX/g0YkYseUEmMsDY5KIHOsKflOlQtY7f/X zuRjGCD2YEPjCfEw3uJseRroqbVDVpkkbjTJUBuRFTI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/FQvpc_Z_BE424TSL_j8EvznulP8>
Subject: Re: [urn] URN Namespace Registration Request for "PNO"
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, 15 Apr 2024 18:06:41 -0000
"Steindl, Guenter" <guenter.steindl=40siemens.com@dmarc.ietf.org> writes: >> Is it possible to say more at this time about the format of PNO URNs? >> In general, we like to see as much detail as possible when registering >> new namespaces. > > PNO (https://www.profibus.com/pi-organization/about-pi) is working > together with SDOs (IEC, IEEE, DKE, ...) for more than 30 years. > > PNO is the host for technologies like PROFIBUS, PROFINET, OMLOX, > IO-Link, MTP, ... In general, the URN committee is fairly lax about requests made by known SDOs, and it seems that PNO qualifies as a known SDO. However, it is useful to have discussions about the proposed namespace and its URNs. > Thus, the principal structure will be > > urn:pno:profibus:{identifier} > > urn:pno:profinet:{identifier} This structure allows further sub-namespaces to be created whenever PNO starts working with another protocol. It would be useful to document this explicitly in the registration. > Example: > urn:pno:profinet:uci/v1?=VendorID=0xFFFF > &OrderID=ABCDEF&IM_Serial_Number=12345&IM_Hardware_Revision=0x0001 This example URN uses "q-components" to designate the specific device (given that it contains "Serial_Number"). Looking at RFC 8141 sections 2.3.1 and 2.3.2, it seems that q-components and r-components are intended more as *modifiers* of base URNs than as intrinsic components of the name of the entity that is named. In both cases the RFC says that the component "SHALL NOT be taken into account when determining URN-equivalence". Thus, for example this URN would be considered URN-equivalent to the above example despite obviously naming a different device: > urn:pno:profinet:uci/v1?=VendorID=0xFFFF > &OrderID=PQRSTU&IM_Serial_Number=67890&IM_Hardware_Revision=0x0001 Although there is no required function for URN-equivalence, so it's possible to just ignore this question. But as section 3.1 says, the intention is that information that is indexed by URNs can be cached, and the cache can be indexed by URNs "up to URN-equivalence". Clearly, the above two examples couldn't be used in such a cache. Let me propose an alternative syntax that avoids this complexity, and also aligns more closely with other URN namespaces. Instead of using q-components, separate the keyword=value pairs from the fixed part of the URN with ":". Thus > urn:pno:profinet:uci/v1:VendorID=0xFFFF: > OrderID=VWXYZ:IM_Serial_Number=13579:IM_Hardware_Revision=0x0001 Thinking a little more about this question, it seems to me that the semantics of the example keywords is not uniform. In this example, clearly "VendorID" and "IM_Serial_Number" are *necessary* for identifying the device (the entity that is named) and are *fixed* across time for that entity. Looking at "OrderID", one possibility is that it is just the vendor's order number under which the device was purchased. That is, it's an *attribute* of the device, but it gives no intrinsic characteristic of the device. On the other hand, it's possible that the "IM_Serial_Number" may only be understandable in the context of the "OrderID"; this would be the case where "OrderID" has the semantics of a product number. In the first of these cases, "OrderID" would be suitable as a q-component, as removing it or ignoring it in URNs would not confuse the URNs for two distinct devices. In the second case, it should be part of the "base" URN. "IM_Hardware_Revision" has similar complexities. Does one need to know this attribute to know which device is being named, or is it an annotation that informs the recipient how the device can be dealt with? Indeed, is this datum constant over time, or is it (like software revisions) subject to periodic update? Dale
- Re: [urn] URN Namespace Registration Request for … Peter Saint-Andre
- [urn] URN Namespace Registration Request for "PNO" Steindl, Guenter
- Re: [urn] URN Namespace Registration Request for … Steindl, Guenter
- Re: [urn] URN Namespace Registration Request for … worley
- [urn] Re: URN Namespace Registration Request for … Steindl, Guenter