Re: [urn] NEW NAMESPACE REGISTRATION: KNX

[John C Klensin <[e-mail]>]

--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