Re: [urn] URN Namespace Registration Request for "PNO"

[[e-mail]]

"Steindl, Guenter" <guenter.steindl=[e-mail]>
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