Re: [core-parameters] NEW INTERFACE DESCRIPTION - KNX IoT Point API

[Esko Dijk <[e-mail]>]

Hi Wouter,

It's the requirement in RFC 6690 Section 7.4:

   URIs are reserved for free use as extension values for these attributes and MUST NOT be registered

The registration is not useful in this case because the owner of the URI/URN is able to freely define the values and what they mean within that namespace.
If KNX registers the "urn:knx" namespace, then it can fully define the contents of this in own specs and registration at IETF should not be needed/desired.

In RFC 3986 section 1.1.3 it explains how URNs are a subclass of URIs, and specs may refer to "URI" to include "URN"s.

If the goal would be to register "knx.if.foo" entries instead of "urn:knx.if.foo", then registration in the CoRE Parameters Registry would be required.

(Also with URNs there's always the risk that someone could start using a URN namespace without having registered it; even when that person doesn't own the namespace formally.
Same thing for using "knx.foo" type CoRE attributes - anyone could start misusing these. )

Esko
________________________________
From: [e-mail] <[e-mail]>
Sent: Friday, September 1, 2023 18:21
To: Esko Dijk <[e-mail]>; 'Michael Critchfield' <[e-mail]>; [e-mail] <[e-mail]>
Cc: 'Joost Demarest' <[e-mail]>; 'André Hänel' <[e-mail]>; 'Steven De Bruyne' <[e-mail]>
Subject: RE: NEW INTERFACE DESCRIPTION - KNX IoT Point API


Hi Esko,



Based on which RFC is the urn not required or possible to register? There must be some evidence for such position.



Note that these values are used in the public wellknown core, hence having a clash that someone else would use the urn:knx prefix would not be good for an SDO like KNX.

Hence why KNX (as organisation) wants to register it.



Kind Regards,
Wouter



From: Esko Dijk <[e-mail]>
Sent: Thursday, August 31, 2023 12:32 PM
To: Michael Critchfield <[e-mail]>; [e-mail]
Cc: Joost Demarest <[e-mail]>; André Hänel <[e-mail]>; Steven De Bruyne <[e-mail]>; [e-mail]
Subject: RE: NEW INTERFACE DESCRIPTION - KNX IoT Point API



Sure, no problem. So my take is that registration is not required nor possible for any URN values for CoRE attributes. If others on this list want to comment on that, I’m happy to hear about it.



Regards

Esko



From: Michael Critchfield <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 30, 2023 22:43
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Joost Demarest <[e-mail]<mailto:[e-mail]>>; André Hänel <[e-mail]<mailto:[e-mail]>>; Steven De Bruyne <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: AW: NEW INTERFACE DESCRIPTION - KNX IoT Point API



Thank you Esko, we did request the URN namespace registration like you suggested as well, right after requesting the Interface registration here.

But there we got feedback requesting more information (from your colleague Ted Hardie) and will discuss internally how to respond.

I will get back to you here once that is clarified.

Can you hold the registration request until then?



Best regards,

Michael



Von: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Gesendet: Mittwoch, 30. August 2023 17:59
An: Michael Critchfield <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Joost Demarest <[e-mail]<mailto:[e-mail]>>; André Hänel <[e-mail]<mailto:[e-mail]>>; Steven De Bruyne <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Betreff: RE: NEW INTERFACE DESCRIPTION - KNX IoT Point API



Thanks Michael, I would like to check with other list members/experts if registration is possible at all.



The interface names all are URNs. RFC 6690 states for URIs (which includes all URNs) a registration MUST NOT be made in the registry. All URNs are free to use by the respective namespace owner.



So what KNX would need to do , is register its (top level) URN namespace at the registry over here: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml .

Then KNX can define all the items in there as it wants without requiring any IETF/CoRE expert involvement.



Regards

Esko



PS I’m noting that Table 6 shows the interface values without the URN prefix, however, the examples in the spec and normative language make clear that the “urn:knx:” needs to be preprended to all the items.











From: core-parameters <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael Critchfield
Sent: Wednesday, August 30, 2023 16:04
To: [e-mail]<mailto:[e-mail]>
Cc: Joost Demarest <[e-mail]<mailto:[e-mail]>>; André Hänel <[e-mail]<mailto:[e-mail]>>; Steven De Bruyne <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [core-parameters] NEW INTERFACE DESCRIPTION - KNX IoT Point API



Dear Core Parameters Team,

As KNX Association cvba, we would like to register the following Interfaces from our KNX IoT Point API Specification with you for listing in Constrained RESTful Environments (CoRE) Parameters (iana.org)<https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#if-link-target-att-value>.



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.

The Table below refers to the KNX IoT Information Model in various places, you can find this on https://schema.knx.org and https://knxcloud.org/index.php/s/E12pxbhctLEREaO/download.

If required, Registration contact shall be Joost Demarest, CTO at KNX Association, [e-mail]<mailto:[e-mail]>.



Type

Interface

Method

Description

Link List

urn:knx:if.ll

GET, (OBSERVE)

Read a linked list and, in combination with if.o, subscribe to all Points of the list.

Parameter

urn:knx:if.p

GET, PUT, (OBSERVE)

Adjust parameter Point (see [03] "KNX Information Model").

Diagnostic

urn:knx:if.d

GET, (OBSERVE)

Read diagnostic Point (see [03] "KNX Information Model").

Configuration

urn:knx:if.c

GET, PUT, POST, DELETE

Configuration and programming of a device.

Logical Input

urn:knx:if.i

PUT, POST

Write and command runtime input Group Object Point (see [03] "KNX Information Model").

Logical Output

urn:knx:if.o

GET, POST, OBSERVE

Read and subscribe runtime output Group Object Point (see [03] "KNX Information Model").

Group Communication

urn:knx:if.g.s

POST, GET (OBSERVE)

Group communication (S-Mode) runtime interworking (input and output) address.

Batch

urn:knx:if.b

GET, PUT, POST

Read or write a collection (e.g., Point list).

Actuator

urn:knx:if.a

GET, PUT, POST

Hardwired actuator (see [03] "KNX Information Model").

Sensor

urn:knx:if.s

GET, PUT

Hardwired sensor (see [03] "KNX Information Model").

Security

urn:knx:if.sec

GET, PUT, POST, DELETE

Configuration (read and write) of security, incl. authorization-related data.

Software Update

urn:knx:if.swu

GET, PUT, POST, DELETE

Software update (push and pull) related data.

Programming Mode

urn:knx:if.pm

GET

Data that can be read in Programming Mode.

Manufacturer

urn:knx:if.m.{name}

Manufacturer-specific definition

Manufacturer-specific interface types.

Interface definitions and methods (from Table 6 of the KNX IoT Point API Specification on https://schema.knx.org)



In the meantime, please contact me for any registration related questions in this regard.



Many thanks in advance.

Best regards,



MICHAEL CRITCHFIELD

ETS Product Management

[e-mail]<mailto:[e-mail]> • T [phone]



KNX Association

De Kleetlaan 5, B-1831 Brussels-Diegem • Belgium

www.knx.org<http://www.knx.org/>



[cid:image001.jpg@01D9DCF8.B9A61610]<https://knxperience.knx.org/>





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.