Thank you for response.
In my understand, iotivity has no issue when user uses iotivity open source as client and server.
Because iotivity 1.2.(server - oic1.1) will response error as '4.06 Not Acceptable' about request of iotivity 1.3.0(client - ocf1.0).
at this time, iotivity 1.3.0 will resend discovery packet according to oic1.1. spec. automatically.
But some other implementation will response '4.02 Bad Option' or will drop request message.
in this case, iotivity 1.3.0 can not resend discovery request automatically.
In conclusion, if someone uses other implemenation (oic 1.1), they should do something accoridng to version negotiation.
and about 'Elective option' i mentioned, i've thought, there should be no CoAP option parsing error.
Thanks,
bt.jo
--------- Original Message ---------
Sender : Thiago Macieira <[email protected]>
Date : 2017-07-22 00:33 (GMT+9)
Title : Re: [dev] FW: [Question] about iotivity 1.3.0 new CoAP options
On Thursday, 20 July 2017 14:22:53 PDT Gregg Reynolds wrote: > wouldn't that mean the recieving endpoint can do whatever it pleases? > doesn't that mean the sender must add a bunch of code to determine whether > or not the receiver understood the option? You can tell from the format of the discovery reply and from the fact that there is no version number in that reply. But yes, the device needs extra code to confirm that. BT is right that other implementations of OIC 1.1 will simply drop the message altogether and not reply. So that means the device needs to resend without the version number to find out if it's an OIC 1.1 device. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
|
|
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
