Subject: Re: [core] link hierarchies and RFC 5785

From: Zach Shelby <[email-masked]>
Date: Tue, 1 Feb 2011 15:15:11 +0200

Peter,

On Jan 28, 2011, at 10:28 AM, Stok, Peter van der wrote:

> So I like to encourage that the CoAP draft says something about how these different representation standards can be recognized to be present on the host.
> 
> Some suggestions are (given that XXX stands for BACnet, KNX, ZigBee, DALI, oBIX, etc....):
> A path for a given standard is preceded by /representation/XXX/name

It is not possible to globally reserve such a URI for this purpose, but of course you can define a common URI like that for a particular deployment.  The philosophy is that a server is free to organize its URIs. 

> Or is preceded by /XXX/name (is shorter)

Again, the same problem as above. 

> Or is given by /name but with d="XXX" as link extension to be returned by resource query.

This is exactly what the link format was designed to let you do. So you would first get /.well-known/core to discover the entry point for a particular interface type:

GET /.well-known/core

</Dali>; n="Light5"; d="DALI",
</BACnet>; n="Thermostat"; d="BACnet"

This works fine for unicast resource requests. Now the problem to solve is how to coordinate the CoAP servers in a building automation system to place a resource used for multicast access at the same location. Here are a few options:

1. Pre-configuration - The system architect simply defines that all CoAP servers in this system place the Dali resource at /Dali, and this is configured in the nodes during commissioning. 
2. Well-known URI - An RFC is written to request that some well-known entry points are to be reserved for multicast resources in building automation. Then e.g. /.well-known/Dali is globally reserved for this purpose. 
3. Resource directory - A proxy could hold multicast resource descriptions for the whole network which the nodes use to configure themselves. A link entry could describe that in this network /Dali is where the d="DALI" interface type is located.  

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 3 Feb 2011 10:14:21 +0100

Dear Zach and Peter,

Given the remark that RFC 5785 formally
limits a registered name to a single suffix through its use of the segment-nz
production, we asked Mark Nottingham, author of RFC 5785, whether additional structure MAY be possible.
Below I cite his answer, removing his intro:

"In section 3:

   It MAY also contain additional information, such as the syntax of
   additional path components, query strings and/or fragment identifiers
   to be appended to the well-known URI, or protocol-specific details
   (e.g., HTTP [RFC2616] method handling).

The only caution I'd give here is that if the mechanisms are separable (e.g., somebody might want to just use /core/foo for a different application), it might make sense to register separately. Also if the spec's going to evolve and you add things to the namespace later, you'll need a way to manage that yourself (e.g., with a registry)."

Apparently, we may, in a controlled way, support additional structure in /.well-known/core.

Greetings,

peter

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]]
Sent: Tuesday 1 February 2011 14:15
To: Stok, Peter van der
Cc: [email-masked]; core WG
Subject: Re: [core] link hierarchies and RFC 5785

Peter,

GET /.well-known/core

Zach

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.