Re: NEW NAMESPACE REGISTRATION: KNX

Michael Critchfield <[email protected]> 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 <[email protected]> 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