Subject: [core] Fwd: Re: core-interfaces-05

From: peter van der Stok <[email-masked]>
Date: Tue, 28 May 2013 12:43:23 +0200

Hi Zach,

To clarify the scope of the draft, and reacting to:

>> However the subsections on actuator, RO parameter, parameter and 
>> sensor restrict the interfaces of the devices which are described 
>> (accessed).
>> According to me that should be the subject of other documents which 
>> describe concrete Function sets for a given "standardized" set of 
>> devices.
> Well, you need some building blocks to start with, without
> restricting what interfaces a device can provide. That is the point of
> those interface descriptions, they give someone defining a function
> set some basic interfaces that *could* be used. Someone defining a
> function set of course needs to define the resources in the function
> set, their resource types, and possibly new interface descriptions for
> more complex purposes. So we're not in any way restricting what a
> device uses for its resources.

If I understand correctly, link-list, batch, linked batch and binding 
tables are proposals for standardization
but sensor, actuator and parameter are examples. I would suggest to put 
them in different sections.
And I think the section suggests restricting the use of the device, for 
example by specifying that a POST can only do a toggle on a device.
It is certainly interesting to suggest examples of device interfaces, 
but completeness will be difficult to attain, and the suggestion for 
standardization should be removed. Question, are you aiming at an 
Informational document?

> I don't see the IETF being in the business of defining device or
> application specific function sets. There are other organisations such
> as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do that
> kind of definition work. But we definitely can give some simple REST
> design tools to work with.

I definitely agree that other SDOs should do the standardization of 
concrete devices and Function sets.
But design tooling is different from interface example specification, 
in my view. Are you suggesting design patterns with relations between 
resources specified in the binding tables?

Peter

Zach Shelby schreef op 2013-05-27 21:16:
> On May 27, 2013, at 3:10 PM, peter van der Stok <[email-masked]> 
> wrote:
> 
>> Hi Zach et al.
>> Reading through the document I came up with two questions concerning 
>> the scope of the document.
>> In the examples of section 5, the content formats are text and 
>> senml+json.
>> Is that meant as a standardization restriction or are xml and exi 
>> also allowed as content formats?
>> Some additional text or examples in xml may be welcome to get scope 
>> clearer.
> Sure, we can add examples for the use of senml+xml or senml-exi.
> 
>> The subsections of section 5 treat the structuring of links in a 
>> list, batch and discuss binding tables.
>> They concern the manipulation of the resource structure.
> These provide pretty generic interface descriptions for those
> purposes, however e.g. batch only works with simple text/plain
> resources. It fits together nicely with the other interface
> descriptions defined in the document (or something similar).
> 
>> However the subsections on actuator, RO parameter, parameter and 
>> sensor restrict the interfaces of the devices which are described 
>> (accessed).
>> According to me that should be the subject of other documents which 
>> describe concrete Function sets for a given "standardized" set of 
>> devices.
> Well, you need some building blocks to start with, without
> restricting what interfaces a device can provide. That is the point of
> those interface descriptions, they give someone defining a function
> set some basic interfaces that *could* be used. Someone defining a
> function set of course needs to define the resources in the function
> set, their resource types, and possibly new interface descriptions for
> more complex purposes. So we're not in any way restricting what a
> device uses for its resources.
> I don't see the IETF being in the business of defining device or
> application specific function sets. There are other organisations such
> as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do that
> kind of definition work. But we definitely can give some simple REST
> design tools to work with.
> 
>> Appendix A is just fine for me because it makes earlier text more 
>> concrete and is tagged as example text.
> I agreed, having a concrete examples helps.
> Thanks,
> Zach
> 
>> Greetings
>> Peter
>> --
>> Peter van der Stok
>> mailto: [email-masked]
>> www: www.vanderstok.org
>> tel NL: +31(0)492474673     F: +33(0)966015248
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Tue, 28 May 2013 15:12:22 +0300

Peter,

Let me quote the WG adoption mail that Andrew sent:

"Since REST is not yet in wide use in the microcontroller community,
documenting some examples of good CoAP design will be beneficial.  In
particular, it is not widely understood how to map certain concepts
such as batching or binding to REST.  We don't have an explicit
charter item for documenting this, but it is natural to have
explanatory material with the base specification.  (LWIG is not the
right group for this as this is not about protocol implementation, but
about design of REST interfaces.)

• Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational

(Again, the objective is to provide examples of good usage for
implementers, not to standardize or even give strong recommendations.)"

So we are talking about an informational document here. So we really can't categorise batch, link etc. as "more informational" and sensor, actuator, parameter as "less informational". In the end they all give REST design guidelines that people may find useful and re-use :-) 

The same goes for giving an example of handling Observe parameters with a REST interface. It is useful informational guidance, as people are already doing this anyways. 

Zach 

On May 28, 2013, at 1:43 PM, peter van der Stok <[email-masked]> wrote:

>>> However the subsections on actuator, RO parameter, parameter and sensor restrict the interfaces of the devices which are described (accessed).
>>> According to me that should be the subject of other documents which describe concrete Function sets for a given "standardized" set of devices.
> If I understand correctly, link-list, batch, linked batch and binding tables are proposals for standardization
> but sensor, actuator and parameter are examples. I would suggest to put them in different sections.
> And I think the section suggests restricting the use of the device, for example by specifying that a POST can only do a toggle on a device.
> It is certainly interesting to suggest examples of device interfaces, but completeness will be difficult to attain, and the suggestion for standardization should be removed. Question, are you aiming at an Informational document?
> 
> I definitely agree that other SDOs should do the standardization of concrete devices and Function sets.
> But design tooling is different from interface example specification, in my view. Are you suggesting design patterns with relations between resources specified in the binding tables?
> 
> Peter
> 
>> On May 27, 2013, at 3:10 PM, peter van der Stok <[email-masked]> wrote:
>>> Hi Zach et al.
>>> Reading through the document I came up with two questions concerning the scope of the document.
>>> In the examples of section 5, the content formats are text and senml+json.
>>> Is that meant as a standardization restriction or are xml and exi also allowed as content formats?
>>> Some additional text or examples in xml may be welcome to get scope clearer.
>>> The subsections of section 5 treat the structuring of links in a list, batch and discuss binding tables.
>>> However the subsections on actuator, RO parameter, parameter and sensor restrict the interfaces of the devices which are described (accessed).
>>> According to me that should be the subject of other documents which describe concrete Function sets for a given "standardized" set of devices.
>>> Appendix A is just fine for me because it makes earlier text more concrete and is tagged as example text.

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