> 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
