Hi Carsten, You understood right about 1st point, there is possiblity of break in interop.
Since Open Source can have more than 1 release in between 2 major release of Spec, there is possibility of "alpha" in an Ioivity version released between 2 major release of Spec. Hence IoTivity can have all OLD features and partial/some NEW feature. In such instance IoTivity's own versioning mechanism will be required. Regards Dwarka ---------------------------------------------------------------------------------- Software R&D Center | Convergence Team | IoT Lab Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair Iotivity Steering Group ? Advisory Committee -----Original Message----- From: Carsten Bormann [mailto:[email protected]] Sent: Friday, December 09, 2016 6:35 PM To: Dwarkaprasad Dayama Cc: "??? (Uze Choi)"; iotivity-dev at lists.iotivity.org Subject: Re: [dev] [Versioning] Add option number for IoTivity version > On 9 Dec 2016, at 08:15, Dwarkaprasad Dayama <dwarka.dayama at samsung.com> > wrote: > > Hi Carsten & All, > > Think about following cases - > > - old client <-> old server > - old client <-> new server > - new client <-> old server > - new client <-> old server > > Now let's say there was change in server protocol format among versions. Best > case would new Clients support both old and new server formats. And for the > case of old client with new server, client must receive an error. Ah, you really have the objective to disallow interoperation. > To let above feature work, we need a method to communicate the version > information. > > Since version of Standard Spec and Open Source are not same always and there > is possiblity of having mutiple Open Source version per Standard Spec > version, Open Source will have to know what other side supports before it > takes a call to switch parser or encoder. This kind of versioning is something you do in tightly coupled systems. The Web is usually run in a more loosely coupled way. If a new version adds a new feature, new clients that happen not to use that feature will continue to work well with old servers. Unless a version number change creates an artificial incompatibility. If a new version removes a feature, old clients that do not rely on this feature will continue to work well with new servers. Unless?. Only if a new version changes the protocol fundamentally do you have to start a new ?version?. But this is really more of a new protocol, not a new version of an existing protocol. The client can find about the capabilities and features of the server using discovery. Nothing is needed in the actual protocol. The server will need to find out about the client capabilities from the request, unless they know each other from before. We tend to use options to indicate capabilities, either actual CoAP options or indications in the data structures exchanged. Gr??e, Carsten
