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

[[e-mail]]

Hi Esko,

 

Any news on this topic?

 

Kind Regards,
Wouter

 

From: Esko Dijk <[e-mail]> 
Sent: Wednesday 11 October 2023 09:53
To: [e-mail]; 'Michael Critchfield'
<[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 Wouter,

 

I’ll raise this topic in the CoRE WG interim call of today – see if there
are some opinions on this. Some ideas: there could be an optional
‘informational’ registration of URNs allowed, or an informational RFC could
be published that lists the urn:knx:… values and explains their use.

Though, the purpose of using URNs is precisely to delegate such registration
to the organization owning the URN namespace, so trying to achieve something
contrary to this purpose may not be easy.

 

Regards

Esko

 

From: [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> > 
Sent: Friday, October 6, 2023 18:29
To: Esko Dijk <[e-mail]
<mailto:[e-mail]> >; '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]> >
Subject: RE: NEW INTERFACE DESCRIPTION - KNX IoT Point API

 

Hi Esko,

 

KNX has now its own urn listed at IANA (it took a while..).

 

However after the (internal) KNX meeting today we still see value for KNX to
list the interfaces mentioned below.

The reasoning behind this is the recognition (for IETF & KNX) that KNX is
actively using RFC 6690: Constrained RESTful Environments (CoRE) Link Format
(rfc-editor.org) <https://www.rfc-editor.org/rfc/rfc6690> 

Just having the urn registered does not give this kind of information.

 

How can we proceed?

 

Kind Regards,
Wouter

 

 

From: Esko Dijk <[e-mail]
<mailto:[e-mail]> > 
Sent: Monday 4 September 2023 15:28
To: [e-mail] <mailto:[e-mail]> ;
'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]> >
Subject: Re: NEW INTERFACE DESCRIPTION - KNX IoT Point API

 

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] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >
Sent: Friday, September 1, 2023 18:21
To: Esko Dijk <[e-mail]
<mailto:[e-mail]> >; 'Michael Critchfield'
<[e-mail] <mailto:[e-mail]> >;
[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]> >
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]
<mailto:[e-mail]> > 
Sent: Thursday, August 31, 2023 12:32 PM
To: 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]> 
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]> 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-l
ink-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

 <mailto:[e-mail]> [e-mail] • T +49
151 50 666255 

 

KNX Association

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

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

 

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