Subject: [core] proposal: remove required support for resource discovery

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 08:48:30 -0500

After my unfortunate encounter with the axle of multicast URI authorities, I
held back a long email related to similar issues.  Here's one of the
still-relevant pieces:

Section 6 currently requires that a node support "/.well-known/r" as a
resource.  But section 6 imposes no requirements on what resources must be
described by the node.  (I thought it interesting that in the test servers I
probed the other day nobody included "/.well-known/r" in the list of
resources provided by that very URI, though any requirement for completeness
would have mandated its inclusion.)

In my case, I know my infrastructure requires external traffic to come
through a gateway that can provide an external mechanism for any
authenticated client to obtain resource information; it could also provide
this function via "/.well-known/r" in CoAP.  But I should not be obliged by
CoAP to add to each internal node an end-point on the well-known port with
its only responsibility being to send an empty string in response to a
request for "/.well-known/r", when all the real work is done over a
different end-point that is accessed via 6lowpan using a compressed port.

I question the value of a MUST requirement for a feature that is not itself
required to do anything.

If this requirement is removed, the motivation behind requiring presence of
an end-point that listens on IANA_TBD_PORT is also gone, changing the MUST
in section 4.4 to at best a SHOULD.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Tue, 27 Jul 2010 15:56:54 +0200

Peter,

On Jul 27, 2010, at 3:48 PM, Peter Bigot wrote:

> Section 6 currently requires that a node support "/.well-known/r" as a resource.  But section 6 imposes no requirements on what resources must be described by the node.  (I thought it interesting that in the test servers I probed the other day nobody included "/.well-known/r" in the list of resources provided by that very URI, though any requirement for completeness would have mandated its inclusion.)

That is because there is no requirement for a node to advertise all its resources as you noted. It doesn't make sense to describe /.well-known/r in a resource description as you just requested that resource, and it is anyways well-known. Now e.g. /.well-known/r/sensors is a different story. 

> In my case, I know my infrastructure requires external traffic to come through a gateway that can provide an external mechanism for any authenticated client to obtain resource information; it could also provide this function via "/.well-known/r" in CoAP.  But I should not be obliged by CoAP to add to each internal node an end-point on the well-known port with its only responsibility being to send an empty string in response to a request for "/.well-known/r", when all the real work is done over a different end-point that is accessed via 6lowpan using a compressed port.

True, we have been considering if this is a MUST or SHOULD earlier. You are correct, if a node has nothing there it should not respond. 

> I question the value of a MUST requirement for a feature that is not itself required to do anything.
> 
> If this requirement is removed, the motivation behind requiring presence of an end-point that listens on IANA_TBD_PORT is also gone, changing the MUST in section 4.4 to at best a SHOULD.

I would have no problem with this, but we need to hear more thoughts from the WG.

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