Subject: [core] shelby-core-interfaces-05

From: peter van der Stok <[email-masked]>
Date: Fri, 10 May 2013 11:26:13 +0200

Hi Zach and Matthieu,

looking at ways to use core-interfaces I stumbled on an ambiguity in 
the binding methods:
The document specifies: polling, observe, and push.
For the latter it specifies PUT without indication whether this a PUT 
sending a confirmable or a non-confirmable messages.
Non-confirmable messages are preferably sent wehen the destination is a 
multicast group.

I would suggest a distinction netween a push and a distribute mode:
- Push to be used with PUT and confirmable unicast message
- Distribute to be used with PUT and non-confirmable multicast message.

Or any other combination of syntax and semantics.

Or a clarification that the text already includes both cases without 
ambiguity

Many thanks,

peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Zach Shelby <[email-masked]>
Date: Fri, 10 May 2013 13:06:53 +0300

Peter,

Sounds reasonable that we could clarify that. I think the current binding mechanism works fine. Probably what we should define is that a push binding with a unicast address is always sent confirmable and with a multicast address is always sent non-confirmable. I don't think we need a new "distributed" mode as such. The URL in the target of the link already carries the IP address (or FQDN that will be resolved to one). 

Zach 

On May 10, 2013, at 12:26 PM, peter van der Stok <[email-masked]> wrote:

> Hi Zach and Matthieu,
> 
> looking at ways to use core-interfaces I stumbled on an ambiguity in the binding methods:
> For the latter it specifies PUT without indication whether this a PUT sending a confirmable or a non-confirmable messages.
> Non-confirmable messages are preferably sent wehen the destination is a multicast group.
> 
> Or a clarification that the text already includes both cases without ambiguity
> 
> Many thanks,
> 
> peter
> 
> -- 
> Peter van der Stok
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: peter van der Stok <[email-masked]>
Date: Fri, 10 May 2013 12:12:38 +0200

Zach,

OK, works for me. The suggested relation covers my known use cases.

Peter

Zach Shelby schreef op 2013-05-10 12:06:
> Peter,
> 
> Sounds reasonable that we could clarify that. I think the current
> binding mechanism works fine. Probably what we should define is that a
> push binding with a unicast address is always sent confirmable and
> with a multicast address is always sent non-confirmable. I don't think
> we need a new "distributed" mode as such. The URL in the target of the
> link already carries the IP address (or FQDN that will be resolved to
> one).
> 
> Zach
>