Subject: [core] proposal: drop HTTP Resource Discovery

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 08:43:37 -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:

I propose that section 6.4 be dropped completely.  A protocol designed for
interaction with constrained devices should not be attempting to supply
HTTP with a resource discovery mechanism.

Peter

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 27 Jul 2010 06:47:44 -0700

HI Peter,

If we drop Section 6.4, then I think CoAP will not really gain traction
unless the intent is to align behind an existing resource discovery solution
like DNS-SD which can work for both HTTP and CoAP.

I think in an M2M setting, resource discovery is a MUST.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource Discovery

Peter

---

From: "Skip Ashton" <[email-masked]>
Date: Tue, 27 Jul 2010 10:01:38 -0400

I agree with Don - for unattended and unassisted devices, resource
discovery to allow them to set themselves up is critical market need.
 
Skip

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Sturek
Sent: Tuesday, July 27, 2010 9:48 AM
To: 'Peter Bigot'; 'core'
Subject: Re: [core] proposal: drop HTTP Resource Discovery

HI Peter,

If we drop Section 6.4, then I think CoAP will not really gain traction
unless the intent is to align behind an existing resource discovery
solution like DNS-SD which can work for both HTTP and CoAP.

Don

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:

I propose that section 6.4 be dropped completely.  A protocol designed
for interaction with constrained devices should not be attempting to
supply  HTTP with a resource discovery mechanism.

Peter

---

From: Guido Moritz <[email-masked]>
Date: Tue, 27 Jul 2010 16:36:24 +0200

>I think in an M2M setting, resource discovery is a MUST.

Jep, discovery is a main mechanism/functionality of most (all I get into my
mind within 10 seconds) M2M protocols and even some H2M.

Guido

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Don
Sturek
Gesendet: Dienstag, 27. Juli 2010 15:48
An: 'Peter Bigot'; 'core'
Betreff: Re: [core] proposal: drop HTTP Resource Discovery

HI Peter,

Don

Peter

---

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 11:55:45 -0500

Section 6.4 specifically proposes that CoAP provide resource discovery for
HTTP, not for CoAP.  I believe this is out of scope.  Does anybody disagree
with that assessment?

I fully support the need for both service-discovery and resource-discovery
for CoAP nodes.

My other email proposed removing the requirement that every CoAP node
provide a resource discovery service that currently is not required to list
any resources.  After a telecon this morning I believe we have a resolution
to the problems I have with that service as described, and that it will be
straightforward to provide both (basic) service and (complete) resource
discovery within CoAP.  However, I still feel it is asking too much that
every constrained device be required to support the service as described in
section 6.

I will follow up later today with some details on a workable solution.
After that, if you believe it should be a requirement on every node that it
directly support a resource discovery service, please reply on that thread.

Peter

On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz
<[email-masked]>wrote:

> *Von:* [email-masked] [mailto:[email-masked]] *Im Auftrag
> von *Don Sturek
> *Gesendet:* Dienstag, 27. Juli 2010 15:48
> *An:* 'Peter Bigot'; 'core'
> *Betreff:* Re: [core] proposal: drop HTTP Resource Discovery
>
>
>
> HI Peter,
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Peter Bigot
> *Sent:* Tuesday, July 27, 2010 6:44 AM
> *To:* core
> *Subject:* [core] proposal: drop HTTP Resource Discovery
>
>
>
> 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:
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 21:54:10 -0500

My starting point: I want to avoid use of multicast addresses in REST
messages, for reasons I've explained before.  (If you believe it's
unnecessary to avoid this, please respond to point 2 in my email titled
"REST, URIs, and constrained devices".)

Here's how we can do service and resource discovery without requiring
multicast in REST.  Instead we use multicast in the transaction layer of
CoAP, without a REST message.  Thanks to Zack on this morning's telecon for
the clue that makes this possible.

Service discovery is the act of finding the address and port of nodes that
provide CoAP control of resources.  In the current draft, the term
"end-point" refers to the service that is discovered.

Service discovery can be accomplished by sending a CoAP CON message with
zero-valued code and no options to the link all-hosts multicast address on
the IANA_TBD_PORT.  Such a message does not incorporate a REST transaction.

Nodes that participate in service discovery are obliged to listen on the
all-hosts multicast address and the IANA_TBD_PORT, even if this is not their
normal end-point.  They respond to CoAP messages with a zero-valued code
with either an ACK or a RST depending on whether the WG decides whether such
a message has any meaning.  The discoverable node must transmit this ACK or
RST using the unicast source address and port of the end-point on which it
listens.

The original node receives unicast responses from all CoAP end-points on the
local link.  It can subsequently send a CON message to GET the
"/.well-known/r" from each node using the end-point address and port
provided by the response.

Code to support service and resource discovery in this manner, and an
example script that identifies the end-points on the local link and
retrieves their resource directories, even when the end-points are not
running on the default port, has been added to coapy.  The example is ugly,
but it does prove this approach works.  Pull from the git repository.

Peter

On Tue, Jul 27, 2010 at 11:55 AM, Peter Bigot <[email-masked]> wrote:

> On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz <[email-masked]
> > wrote:
>
>> Jep, discovery is a main mechanism/functionality of most (all I get into
>> my mind within 10 seconds) M2M protocols and even some H2M.
>>
>>
>>
>> Guido
>>
>>
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Peter Bigot

---

From: Guido Moritz <[email-masked]>
Date: Wed, 28 Jul 2010 08:29:00 +0200

Just to clarify, you mean implementing Discovery on a CoAP node hast o be
something different then a "MUST"? Agree, CoAP must define a mechanism but
it might be optional.

Guido

Von: Peter Bigot [mailto:[email-masked]] 
Gesendet: Dienstag, 27. Juli 2010 18:56
An: Guido Moritz
Cc: [email-masked]; core
Betreff: Re: [core] proposal: drop HTTP Resource Discovery

Peter

Guido

HI Peter,

Don

still-relevant pieces:

Peter

---

From: Zach Shelby <[email-masked]>
Date: Wed, 28 Jul 2010 11:03:28 +0200

On Jul 27, 2010, at 6:55 PM, Peter Bigot wrote:

> Section 6.4 specifically proposes that CoAP provide resource discovery for HTTP, not for CoAP.  I believe this is out of scope.  Does anybody disagree with that assessment?

I brought that up in the CoAP presentation this morning and will open up a ticket for that. Personally, I have no problem removing that subsection. I understand that it may be confusing.

> I fully support the need for both service-discovery and resource-discovery for CoAP nodes.
> 
> My other email proposed removing the requirement that every CoAP node provide a resource discovery service that currently is not required to list any resources.  After a telecon this morning I believe we have a resolution to the problems I have with that service as described, and that it will be straightforward to provide both (basic) service and (complete) resource discovery within CoAP.  However, I still feel it is asking too much that every constrained device be required to support the service as described in section 6.
> 
> I will follow up later today with some details on a workable solution.  After that, if you believe it should be a requirement on every node that it directly support a resource discovery service, please reply on that thread.

Presented the basic ideas (a couple bullet points) in the presentation this morning, thanks for working on the details! 

Zach

> 
> Peter
> 
> On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz <[email-masked]> wrote:
> Jep, discovery is a main mechanism/functionality of most (all I get into my mind within 10 seconds) M2M protocols and even some H2M.
> 
>  
> Guido
> 
>  
>  
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Don Sturek
> If we drop Section 6.4, then I think CoAP will not really gain traction unless the intent is to align behind an existing resource discovery solution like DNS-SD which can work for both HTTP and CoAP.
> 
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Bigot
> 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:
> 
> I propose that section 6.4 be dropped completely.  A protocol designed for interaction with constrained devices should not be attempting to supply  HTTP with a resource discovery mechanism.
> 
> Peter
> 
> 

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