Re: [T2TRG] [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version

Hi all

I want to point out that this is related to the parameter option discussion we had for a long time: https://tools.ietf.org/html/draft-doi-core-parameter-option-03
The work was dropped because there was too much resistance to include this feature (it least in my understanding).

Coming from the design guidelines discussed in T2TRG, it is expected that versioning is handled within the representation format (while a good design also ensures backward and forward compatibility). If a representation format is not compatible with previous versions, it is a different format that needs a new media type, and hence CoAP identifier.
(Note that these guidelines have not reached consensus, and hence cannot be referenced. Please add other views; it might be a valuable T2TRG discussion.)

Ciao
Matthias

> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Alexander Pelov
> Sent: Sunday, 9 April 2017 22:01
> To: Klaus Hartke <hartke@tzi.org>
> Cc: Core <core@ietf.org>
> Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-
> Version and Content-Format-Version
> 
> Hi Klaus,
> 
> 
> > Le 9 avr. 2017 à 16:54, Klaus Hartke <hartke@tzi.org> a écrit :
> >
> > Alexander Pelov wrote:
> >> IANA has received a request from Michael Koster to register two new
> >> CoAP
> >> options:
> >> - Accept-Content-Format-Version
> >> - Content-Format-Version
> >
> > Spec?
> >
> >> One of the major questions that needs to be discussed is the following:
> >
> > What are the other questions?
> 
> The other questions are mostly details that we can (easily) figure out once the
> major one is answered. For example, should the Accept-Content-Format-Version
> be Repeatable or Not? (I don’t want to get to more details on this for the
> moment - and they will surely come up if necessary).
> 
> >
> >> What are the reasons *NOT* to allocate a new Content-Format number
> >> (RFC
> >> 7252) for each new version? (in the HTTP world, "version" is a simple
> >> parameter to the Content-Type, so why not treat it as such?)
> >
> > None?
> >
> >> The question is not trivial, as it touches upon content format
> >> negotiation, e.g. how  should the Server use the
> >> Accept-Content-Format-Version in order to indicate that it is willing
> >> to accept both application/vnd.ocf+cbor AND
> >> application/application/vnd.ocf+cbor;version=2.0, with a preference
> >> for the latter? In the semantics of the version parameter, the two should be
> considered completely independent/incompatible types.
> >
> > CoAP currently has no features for content format negotiation, only
> > for the selection of an available content format. If a server wishes
> > to indicate available content formats, it needs to do so in the
> > (hypermedia) representation. (The CoAP Accept option can only be used
> > in requests, not in responses.)
> >
> > Are the two options a proposal to change that?
> >
> > Need spec.
> 
> Yes, you are right indeed. The *Client* indicates in its CoAP Accept option the
> Content-Format it is willing to accept. Now, if you have the same Content-
> Format, but with different versions, then you could imagine having something
> like:
> Accept: 10000 (which maps to application/application/vnd.ocf+cbor)
> Accept-Content-Format-Version: 2.0
> 
> Instead of:
> Accept: 10001 (application/application/vnd.ocf+cbor;version=2.0 which would
> need to be registered to 10001 for example)
> 
> The intent here is to always indicate "10000" in your hypermedia links, and
> without changing them to be able to upgrade/downgrade the version of the
> content-format (e.g. I like to think of this as changing APIs - you upgrade a Client,
> and then it is on ver2 - but still using the original Content-Format, but this may
> not be the only reason Michael proposes these options).
> 
> >
> >> The current way of doing this would be to allocate separate
> >> Content-Format numbers to "application/application/vnd.ocf+cbor"
> >> (10000 as it stands now) and
> >> "application/application/vnd.ocf+cbor;version=2.0" (e.g. 10001).. and then
> use some form of content negotiation.
> >
> > Yes.
> >
> >> This however can have its disadvantages, .. and the way industry does
> >> use versioning in some cases (e.g. people DO use the version
> >> parameter to version their RESTful APIs.. which means, that NOT
> >> having such mechanism in CoAP could theoretically drive them to
> >> re-register blocks of Content-Format numbers, just to differentiate between
> their APIs).
> >
> > Working as intended.
> >
> >> In any case, we need to have this discussion documented on the
> >> mailing list (as previously discussed with Michael), so here we go..
> >
> > I'm sure Michael has analyzed the problem, evaluated different options
> > to solve the problem, and contacted the experts with the best solution
> > he could find. However, since the identifier spaces in CoAP are so
> > small and the unrestricted addition of new CoAP features can lead to
> > fragmentation, every addition must be carefully considered. For that,
> > it is really helpful to establish an understanding of the problem
> > before pushing a particular solution.
> 
> I agree with you on this. Having this understanding - and documented on the
> mailing list - is the intent of this discussion.
> 
> Alexander
> 
> 
> >
> > Klaus
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core