[Fiware-iot] ETSI M2M RESTful binding for the mId

[Bisztray, Denes (NSN - HU/Budapest)]

Hi Wafa,

 

Please find my answers inline.

 

-          To be compliant with the ETSI M2M, we 'll have 2 kind of devices in FIWARE : either the device has its own SCL (i.e  it contains the depicted resource structure) and  that means that the device will use the mld interface to communicate with the centralized backend; or  the device doesn't contain an SCL, and in that case cannot use the mld interface and must communicate with its gateway via the dIa interface. Is that what you mean in your introduction ?

 

I want to introduce a resource structure and set of interactions based on the ETSI M2M standard that can be exposed by and ETSI M2M compliant device.

 

I'm a bit skeptic with the concept of SCL in ETSI M2M. It turned out that the service capabilities are just ideas that are not connected to the actual resource structure.  I'm also a bit puzzled by the difference between device-gateway mId and device-gateway dIa. What is the exact difference there? What difference does the SCL make there?

 

-          Could we keep the same notation as in the ETSI M2M Release 1 ?  I think it will be easier and more homogeneous for the mapping ( <container>  instead of {container}, keep the name of the primitive "containersRetrieveRequestIndication" to GET the list of child containers, ...)

 

The notation of <container> can be used I agree, I just wanted to use the same notation as the NGSI-10. The primitive name was omitted indeed, I found no reason to include it, however it can be done. I'll do it possibly today.

 

-          The mld interface is between 2 SCL (device <--> backend or gateway <--> backend): some arguments are missing from the input message like  targetID, PrimitiveType which are mandatory. Any reasons for that ? 

 

There is a supplementary document called Annex C: HTTP Mapping. It states that the HTTP URI should be derived from the targetID attribute, ie. the targetID is basically the URI, thus I omitted it. 

The primitivetype is omitted with the same justification: the HTTP method makes it clear what we want to do with the resource, so the field is not necessary. 

 

-           In the Data Structure of a Container, the "searchStrings" and "announceTo" attributes are missing. Why? 

This supposed to be a minimal set of resources on the device. The "searchStrings" attribute is used for discovery that I don't want to provide in the first release. The "announceTo" makes sense on a gateway, and I had the device in mind.

 

-          Just to be sure of my understanding, implementing this subset in the architecture that would amount to implement it in the Device, in the Gateway (IOT API) and in the Backend (Device Level API)?

 

Only on the device. I need some help to define the dIa and the mId on the gateway.

 

Did you get the XSD files for the ETSI M2M?

 

No, Gian Piero did not send it to me.  However, I found it from other sources.

 

Best,

Dénes

 

De : Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] 
Envoyé : vendredi 17 février 2012 16:01
À : fiware-etsim2m at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu
Cc : NAGELLEN Thierry RD-BIZZ-SOP; SOUBRA Wafa RD-BIZZ-SOP
Objet : ETSI M2M RESTful binding for the mId

 

Dear all,

 

I just created a proposal for the RESTful binding on the mId interface with the minimal set of resources that we should implement for the April release.

 

It is uploaded to the IoT SVM under this link:

https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/FIWARE-ETSI-M2M-RESTful-binding.docx

 

Also if someone does not have the access right, I attached to this email.

 

Best,

Dénes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120221/5f04cbee/attachment.html>