Subject: Re: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts

From: Yusuke DOI <[email-masked]>
Date: Mon, 03 Dec 2012 15:43:26 +0900

Because I'm hearing none, let me continue a bit.
If it requires some discussion on Content Encoding, let's move
it to apps-discuss.

(2012/11/29 19:00), Carine Bournez wrote:
> We believe that the choice of a content-type parameter is a good one
> (as long as it does get implemented effectively by endpoints). However,
> the cleanest way would be still to use a content-encoding mechanism
> rather than a separate content-type indicating that EXI is used. So
> instead of:
>
> 'Accept: application/example-exi;sv=1.4'
>
> we suggest:
>
> 'Accept: application/example;sv=1.4'
> 'Accept-encoding: exi'

However, content-encoding EXI for schema-informed EXI is not accepted in 
IETF (so far). This is simple because just saying 'EXI' does not help
to understand the contents. Schema-informed EXI requires schema information.

In this case, the content type 'example-exi' could be just an 'example'. 
Anyway, the spec of the content type defines the encoding+schema.

> For the schema versioning concern mentioned in section 2.1, we interpeted
> the text (in the light of the core-parameter-option I-D ) as
> "schemaId will be sent as a content-type parameter".
> We want to highlight the fact that in practice the idea of using a
> 'Major.Minor' version number might not be needed. For minor changes to the
> schema, it may be interesting to use the deviation capabilities of the
> EXI processors, rather than offering a new schema for the content-type
> and deploy the change on a lot of endpoints. It would be easier to
> advise users to change the schema (to be negotiated) only when really
> necessary, i.e. format changes enable measurable performance improvements.

It seems to me that the argument is orthogonal to the schema versioning 
issue and I believe it should be up to protocol/schema designer's decision.

The use case in my mind is to ship new version of products with a new 
schema without breaking interoperability. Personally I don't think I 
would try to update the schema of previous lines of products.

// Yusuke DOI <[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Dec 2012 09:27:08 +0100

> 'Accept: application/example;sv=1.4'

Carine,

thank you for your input.
One piece of background that seems to be important here:

In CoAP, we do not separately deal in media-types and content-codings, on the basis that few constrained nodes will have that level of flexibility.
Instead, we have a concept of content-format, which essentially is the cross-product of the two, i.e., a number given to each desirable combination:  One content-format implies one media-type and one content-coding, as well as a specific setting of all media-type parameters.

A CoAP Accept Option specifies an acceptable content-format, i.e. a combination of media-type, parameters, and content-coding.
The CoAP Content-Format Option specifies the media-type, parameters, and the content-coding of the representation enclosed.
(We confusingly continued calling that option "Content-Type" for a while; this was recently fixed.)

So while what you are saying would be possible on the HTTP side (as Yusuke said, considering exi as a content-coding in the schema-informed case is controversial), on the CoAP side it's all multiplied out and therefore practically doesn't make a difference.

My view of Yusuke's draft is that it is essentially exploring what part of the picture cannot be factored into this single number because that disables the recognition of structure needed e.g. for version number arithmetic, and how to encode that information separately from the Content-Format Option.

Grüße, Carsten

---

From: Carine Bournez <[email-masked]>
Date: Thu, 6 Dec 2012 09:43:08 -0500

Hi,

> So while what you are saying would be possible on the HTTP side (as Yusuke said, considering exi as a content-coding in the schema-informed case is controversial), on the CoAP side it's all multipl…

The draft that the EXI Working Group reviewed had only negotiation techniques
in terms of HTTP Content-Type, it seems. If you have some draft written in
terms of Content-Format explaining the different cases (with EXI encoding, 
with textual XML or other encoding...) in terms of a single Content-Format
concept, we may review and send comments. We understand that full flexibility 
with various HTTP headers and parameters may not be desirable in certain 
use cases (we also work on an EXI Profile for devices with limited resources)
and for a number of these cases we abstained from defining all the details so
that EXI users can choose what suits best their use cases (e.g. out-of-band
schema negotiation.)

-- 
Carine Bournez -+- W3C Europe