Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.txt

From: Zach Shelby <[email-masked]>
Date: Wed, 11 Jul 2012 14:47:27 +0300

Matthieu and I have posted a new version of the CoRE Interfaces draft. This now includes a useful new mechanism to create bindings between resources on the same or different endpoints. For example for a light switch to control a light, or to handle just about any interaction between resources. The draft also updates all resource types and interface descriptions to the -14 version of CoRE Link Format.

Try it out - comments welcome! 

Zach

Begin forwarded message:

> From: [email-masked]
> Date: July 11, 2012 2:42:56 PM GMT+03:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-shelby-core-interfaces-03.txt
> 
> 
> A new version of I-D, draft-shelby-core-interfaces-03.txt
> has been successfully submitted by Zach Shelby and posted to the
> IETF repository.
> 
> Filename:	 draft-shelby-core-interfaces
> Revision:	 03
> Title:		 CoRE Interfaces
> Creation date:	 2012-07-11
> WG ID:		 Individual Submission
> Number of pages: 24
> URL:             http://www.ietf.org/internet-drafts/draft-shelby-core-interfaces-03.txt
> Status:          http://datatracker.ietf.org/doc/draft-shelby-core-interfaces
> Htmlized:        http://tools.ietf.org/html/draft-shelby-core-interfaces-03
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-shelby-core-interfaces-03
> 
> Abstract:
>   This document defines well-known REST interface descriptions for
>   Batch, Sensor, Parameter and Actuator types for use in contrained web
>   servers using the CoRE Link Format.  A short reference is provided
>   for each type that can be efficiently included in the interface
>   description attribute of the CoRE Link Format.  These descriptions
>   are intended to be for general use in resource designs or for
>   inclusion in more specific interface profiles.  In addition, this
>   document defines the concepts of Function Set and Binding.  The
>   former is the basis element to create RESTful profiles and the latter
>   helps the configuration of links between resources located on one or
>   more endpoints.
> 
> 
> 
> 
> The IETF Secretariat

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 11 Jul 2012 16:32:43 +0000

Hi guys

I am currently reading the new version and I am a bit confused about the binding part.
It implies that both ends provide resources, i.e., also Web clients expose their internal state as resources.
This sounds a little odd to me... bindings also exist when a client does not have server-functionality.

Maybe I am just missing an introduction that says that it is best when clients export their configuration as resources.
But, still I feel this mismatch of links between resources versus client-server interaction.

Ciao
Matthias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Zach Shelby
> Sent: Mittwoch, 11. Juli 2012 13:47
> To: [email-masked] WG
> Subject: [core] Fwd: New Version Notification for draft-shelby-core-
> interfaces-03.txt
> 
> Matthieu and I have posted a new version of the CoRE Interfaces draft. This
> now includes a useful new mechanism to create bindings between resources
> on the same or different endpoints. For example for a light switch to control
> a light, or to handle just about any interaction between resources. The draft
> also updates all resource types and interface descriptions to the -14 version
> of CoRE Link Format.
> 
> > has been successfully submitted by Zach Shelby and posted to the IETF
> > repository.
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: [email-masked]
Date: Thu, 12 Jul 2012 10:21:29 +0200

Hi Matthias

Thanks for your feedback. See my comments inline.

>It implies that both ends provide resources, i.e., also Web clients 
expose their internal state as resources.

We aim at providing a solution to connect sensor resources (or more 
generally producer resources) with actuator resources (consumers).

>This sounds a little odd to me... bindings also exist when a client does 
not have server-functionality.

In that case you need an out-of-band channel to configure bindings on a 
client-only endpoint from a third-party. And if the client can 
automatically configure itself using resource/service discovery, you also 
need an OOB mechanism to publish this configuration. With CoRE bindings 
you just use the web protocol. If you don't need to publish or configure 
your bindings then you don't need a binding representation.

>Maybe I am just missing an introduction that says that it is best when 
clients export their configuration as resources.
>But, still I feel this mismatch of links between resources versus 
client-server interaction.

Actually I assume that most endpoints are client and server (except 
sleeping endpoints but in that case a mirror server is client/server on 
behalf of the SEP). So the client/server role is not so important for the 
abstract binding concept (it is for a specific binding method).

Matthieu

---

From: M Pouillot <[email-masked]>
Date: Mon, 23 Jul 2012 16:16:41 +0000

Hello Zach and Matthieu,

Great job on the binding mechanism, I have just little question about the 4.3. Why a profile should allow only one resource table per endpoint?  What is the issue to have several bindings on one endpoint?

More generally, now we have the RD, or the well-known/core to discover the features of each device. We have the mean to do a bind between several devices... Is there a work to describe how a device can recognize automatically with others  it can make a binding? A generic ressource source "switch/onoff" could control a "a/light" actuator but a "a/pwr" actuator too. These two actuators have the same functionalities (on/off/ toggle) but how the source could know that these specific actuators have the good features. It could be interesting to specify generic features and publish them in the ressource type . example:  </a/1/led>;rt="simple.act.led.onoff";if="core.a"

regards,

Mathieu

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Zach Shelby
Envoyé : mercredi 11 juillet 2012 13:47
À : [email-masked] WG
Objet : [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.txt

Zach

---

From: Matthieu Vial <[email-masked]>
Date: Mon, 30 Jul 2012 09:49:52 +0200

Hi Mathieu,

> Great job on the binding mechanism, I have just little question about the 4.3. Why a profile should allow only one resource table per endpoint?  What is the issue to have several bindings on one en…

In the draft, a binding table contains a list of bindings so it's
possible to have several bindings on one endpoint.
Also the draft proposes to centralize information about bindings in a
unique resource containing the binding table for the endpoint.
An alternative would be to derocate all resources with either a query
string or a sub-resource to access binding information about the
target resource.
This solution may conflict with an already defined interface for the
resource. Finally the centralized method makes life easier when we
need to get all bindings at once.
Some advanced servers running multiple virtual devices might need more
than one binding table hence the SHOULD instead of a MUST.

Matthieu