From wafa.soubra at orange.com Mon Feb 20 17:04:31 2012 From: wafa.soubra at orange.com (wafa.soubra at orange.com) Date: Mon, 20 Feb 2012 17:04:31 +0100 Subject: [Fiware-etsim2m] ETSI M2M RESTful binding for the mId In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> References: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> Hello everyone, Thank you Denes for your document. As far as I understand, this proposed subset of the API should be implemented for the first release of FIWARE in April 2012. Therefore, I have questions about some points if you could clarify that for me : - 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 ? - 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 ( instead of {container}, keep the name of the primitive "containersRetrieveRequestIndication" to GET the list of child containers, ...) - 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 ? - In the Data Structure of a Container, the "searchStrings" and "announceTo" attributes are missing. Why? - 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)? Thanks in advance for your answers. If you'd like, I can also update the document. Did you get the XSD files for the ETSI M2M? Best Regards, Wafa. 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: From denes.bisztray at nsn.com Fri Feb 17 16:01:25 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Fri, 17 Feb 2012 16:01:25 +0100 Subject: [Fiware-etsim2m] ETSI M2M RESTful binding for the mId Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: FIWARE-ETSI-M2M-RESTful-binding.docx Type: application/octet-stream Size: 37015 bytes Desc: FIWARE-ETSI-M2M-RESTful-binding.docx URL: From denes.bisztray at nsn.com Tue Feb 21 08:13:05 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Tue, 21 Feb 2012 08:13:05 +0100 Subject: [Fiware-etsim2m] ETSI M2M RESTful binding for the mId In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> References: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> Message-ID: <3F4C11BC54A36642BFB5875D599F47BD0592D92D@DEMUEXC013.nsn-intra.net> 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 ( instead of {container}, keep the name of the primitive "containersRetrieveRequestIndication" to GET the list of child containers, ...) The notation of 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: