Re: [urn] NEW NAMESPACE REGISTRATION: KNX

[Michael Critchfield <[e-mail]>]

Dear IETF Team, 
Thank you for pointing out some of our necessary editorial changes in our KNX IoT Point API Specification.
    - We have triggered internally the change of "relative URN" towards "truncated URN".
    - Considering the comments made by Dale in a previous eMail, we also streamlined the use of {...} vs. <...> for the definitions/uses/examples of urn:knx.

Please understand that these changes now started a process of updating and formal acceptance internally at KNX and the changes will take some weeks to become available publicly.
We hope this clarifies our request for the URN Namespace Registration of KNX.
Please let us know if the registration can now be processed.

Many thanks!
Best regards,
Michael

-----Ursprüngliche Nachricht-----
Von: John C Klensin <[e-mail]> 
Gesendet: Dienstag, 5. September 2023 20:22
An: Dale R. Worley <[e-mail]>; Peter Saint-Andre <[e-mail]>
Cc: Michael Critchfield <[e-mail]>; [e-mail]; Joost Demarest <[e-mail]>; André Hänel <[e-mail]>; Steven De Bruyne <[e-mail]>; W. van der Beek <[e-mail]>
Betreff: Re: [urn] NEW NAMESPACE REGISTRATION: KNX



--On Tuesday, September 5, 2023 13:51 -0400 "Dale R. Worley"
<[e-mail]> wrote:

> Peter Saint-Andre <[e-mail]> writes:
>> I disagree. There *is* a contradiction, the KNX specification is 
>> using  the term "relative URN" (which is undefined), and allowing 
>> this is not a  responsible way to proceed.
>>
>> Why do the authors of the KNX specification apparently feel the need 
>> to  elide 'urn:knx' from the start of (some) URNs in the KNX 
>> namespace? Is  this being done to save a few bytes over constrained 
>> links for IoT?

> There actually *is* a definition of "relative URN", although the 
> discussion admits that relative URNs are largely worthless.  See RFC 
> 8141 section 4.3 "URNs and Relative References".

Yes, and Peter cited it his note.  My recollection is that it was a compromise to avoid saying something close to "relative URN, at least defined consistently with the 3986 definition of relative URI, are a stupid idea and MUST NOT be allowed in any namespace".  At least in part, the feeling was that such a statement would contradict statements in 3986 that applied to all URIs.

> As far as I can tell from the document, the KNX people want to save 
> the 7 bytes over constrained links.

In its simplest form, the problem described above is that whether a particular "relative" string is a KNX URN, or any URN at all, requires either context or heuristics on the hier-part, heuristics that might not work.  AFAICT, independent of the niceties of 3996, common practice these days assumes that anything that might be a reference is an HTTPS (or maybe still
HTTP) URL.  To partially borrow an example from 3986, if "ftp.is.co.za/rfc/rfc1808.txt" appeared in running text, it is almost certain to be treated as a URL with an implicit scheme name.  And, borrowing heuristics that I don't think have been observed in the wild, that scheme name would not be "ftp".

Now, if the links are sufficiently constrained, that is a non-issue ... until some KNX device or its user has a need to reference foo.bar.baz and wants it to be interpreted as https://foo.bar.baz/ and the namespace requires that it be interpreted as urn:knx:... instead.  I don't understand the KNX environment well enough to know if that could be a major future constraint of not, but that seems like a bad idea to me.  And saying that, within the KNX environment anything that might be interpreted as relative but is not a KNX URN MUST specify the scheme name, would probably stretch the limits of 3986.


> IMHO the KNX usage would better use the word "abbreviated", as the 
> connotations of the word are closer to the intended usage
> -- the transmitted string is shorter, but it is not interpreted 
> *relative to* another string.

I like "abbreviated" for those reasons and because it neither requires redefining a term used elsewhere or using one we did our best to identify as undefined.

> But I'm OK with a
> second meaning being given to a word when the situation is 
> syntactically distinguishable from the original meaning and almost 
> certainly will be confined to a circumscribed subfield.

And I suggest, as above, that it is unlikely that those constraints can be met/guaranteed for the long term.

   john

This email comes from outside KNX organization.
Do not click links (with or without explicit IP addresses) or open attachments unless it is an email you expected to receive.