Subject: [core] core-interfaces-05

From: peter van der Stok <[email-masked]>
Date: Mon, 27 May 2013 14:10:57 +0200

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.
They concern the manipulation of the resource structure.
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.

Greetings

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: Mon, 27 May 2013 22:16:06 +0300

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.

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

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