Hi MJ,
With 1st option, oic/d should be retrieved first which means discovery(oic/res) should not be done before this action. However, oic/d retrieving is not mandatory path prior to all the other communication. BR, Uze Choi From: MyeongGi Jeong [mailto:[email protected]] Sent: Wednesday, March 23, 2016 6:43 PM To: ???; ????; 'Mitch Kettrick' Cc: iotivity-dev at lists.iotivity.org; oswg at openinterconnect.org Subject: Re: [dev] [IoTivity versioning scheme] RE: Backward Compatibility for IoTivity Hi, Uze. Thanks for proposals. I feel, the first one is more attractive than others. If we decide that applying versioning scheme, I think, it will be better to handle as a resource attribute, not an option of CoAP. Thanks. Best Regards, --- MyeongGi Jeong Principle Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 | +82-2-6147-7699 ------- Original Message ------- Sender : ???<uzchoi at samsung.com> S6(??)/??/IoT Lab(S/W??)/???? Date : 2016-03-23 17:36 (GMT+09:00) Title : [dev] [IoTivity versioning scheme] RE: Backward Compatibility for IoTivity Hi, Regarding version negotiation for backward compatibility, let me approach the problem from IoTivity perspective. Regarding versioning scheme, there were several discussion and proposals but all has some problems. However, I?ll list up the proposal as follows because of better than nothing. Proposal1. /oic/d resource with version attribute(property) This will affect the communication sequence as /oic/d always first for version negotiation. Proposal2. Use the CoAP optional field for version. This will be big overhead even if version info only take 1 byte. (CoAP header is 4 bytes) Proposal3. Use the CoAP optional field for version only in /oic/res. We can reduce the packet size after discover done. But two issues happens. . IoTivity stack internally manager the resource and version mapping list. . Some corner cases : RD/GW case, real target device can have different version, OTA updated stack can have different version after discovery. In case of not start from discovery, no version info(becuase discovery is not mandatory step always..) Please raise the idea to make version negotiation realized. Greg, any idea for this? BR, Uze Choi From: Dwarkaprasad Dayama [mailto:[email protected]] Sent: Wednesday, March 23, 2016 3:41 PM To: 'Mitch Kettrick' Cc: ??? Subject: RE: Backward Compatibility for IoTivity Dear Mitch, ?icv? may solve in some case while it will not in some case. Think about /oic/res schema change, if a device using new schema responds to old versioned client, client will not understand the schema at all. So I was thinking something out of band or using CoAP header to communicate the version number. But again, we just started this discussion and hence will have to think about every possible case, and make sure sender and receiver are able to know versions without getting into payload. This topic has been assigned to OSWG ? Developer Eco Build TG (Uze) with Ravi, Greg to share their expertise. You can share your thoughts too. Regards Dwarka ---------------------------------------------------------------------------------- Software R&D Center | Software Platform Team | IoT Lab Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair Iotivity Steering Group ? Advisory Committee From: Mitch Kettrick [mailto:[email protected]] Sent: Wednesday, March 23, 2016 9:47 AM To: Dwarkaprasad Dayama Subject: Backward Compatibility for IoTivity Hi Dwarka, I saw this slide. You do know that the ?icv? Property of /oic/d contains the version of the core spec that each device is implemented to. Does this solve part of the problem (i.e. each device signaling its capability)? Mitchy -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160324/5e2eadac/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 30476 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160324/5e2eadac/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 13168 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160324/5e2eadac/attachment.gif>
