Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181)

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 06:46:20 -0600

From a pragmatic point of view, regardless of what you think the relation between EXI and  XML is I'm very much in favor of CoAP having content-type value along the lines of  

application/se+exi 

On Feb 17, 2012, at 1:14 PM, Guido Moritz wrote:

>> I am not an EXI expert, but my understanding from a conversation with
>> Zach in Taipei (and afterward on the apps-discuss list) is that one
>> could see EXI as either (1) a content-encoding of XML or (2) a new and
>> different content-type. The matter isn't settled, but it would be good
>> to settle it. :)
> 
> I also had to think about this issue for a while, because I have to explain the differences and perspectives as part of my Phd thesis...keep fingers cross to have finished it before Paris ;). Overall I concluded in (2) and describe EXI as a completely new and different 'content-type', i.e. 'on wire encoding' of XML-Infoset serialized object structures.
> 
> I think how and why people favor one of the two options is how they use it. There are applications/implementations that are already using XML and to save bandwidth now the data stream is changed for several parts/communications into the EXI format. In this use case, EXI can even be a compressor, i.e. compression is the process changing the data representation to a more efficient one. But because their applications/implementations are still parsing and processing native Unicode XML, EXI is just another encoding for the existing XML structures. From this perspective absolutely feasibly to favor (1). 
> 
> But EXI is, in contrast to e.g. gzip, also capable to be a standalone representation that can be parsed and processed directly by the implementations. This is how the EXI format was designed by the W3C, as a complete replacement for Unicode XML if required. In this case there is no need to change EXI to XML to process it. In this case (2) is more feasible. And this is also the way we are using EXI within our 6LoWPAN-related implementations. 
> 
> My 2 cents,
> Maybe we can discuss it in Paris while having a nice wine, 
> Guido
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 06:47:43 -0600

application/se+exi

---

From: Zach Shelby <[email-masked]>
Date: Sat, 21 Apr 2012 09:51:12 +0300

Cullen, Guido,

There has been a long discussion on this over on the apps area discuss list (including W3C folks), and if you have an opinion on this it is probably best to speak up there. Right now we are basically stuck in the conversation as it seems Schema-informed mode use of EXI is not a valid content-encoding but nor is it a valid media type suffix according to the media type experts. So it falls between the cracks.  

Instead we are now looking at the use of an informal naming like application/senml-exi where there is no structured suffix exactly, but this still means EXI for the application. What we are now trying to figure out is what to day about that in the media type registration. This means at least the SenML media type registration needs an update. 

Anyways, let's continue that discussion over on the apps area list if needed.

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 21 Apr 2012 09:58:54 +0200

> Instead we are now looking at the use of an informal naming like application/senml-exi where there is no structured suffix exactly, but this still means EXI for the application. What we are now try…

Luckily, we are decoupled from that discussion; we can give the thing a number whenever we want.

The intention is clearly to put application/senml[__]exi into our set of registered content-type/content-coding combinations along with application/senml+json and application/senml+xml.  (Fill in the blank after the discussion in apps-discuss closed.)

We could start agreeing on the numbers that will be registered here.

By the way, continuing to call option 1 Content-Type may now be slightly confusing to HTTP mapper implementers.  (Changing it to something akin to "Content-Type-And-Encoding-Id" is ugly and will confuse the CoAP implementers.  I'm not sure who I want to confuse more.  Maybe sticking with the wrong name is better.)

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Apr 2012 05:56:04 -0700

> By the way, continuing to call option 1 Content-Type may now be slightly confusing to HTTP mapper implementers.  (Changing it to something akin to "Content-Type-And-Encoding-Id" is ugly and will co…

Given that there will be many more implementation is the future than there has been so far, I think we should error not the side of con suing the current developers. I don't think they will be very confused by this so I'd rather see us change things to the best name possible.

---

From: Zach Shelby <[email-masked]>
Date: Mon, 23 Apr 2012 21:51:56 +0300

> Given that there will be many more implementation is the future than there has been so far, I think we should error not the side of con suing the current developers. I don't think they will be very…

Content-And-Encoding-Id?

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 24 Apr 2012 09:08:12 +0200

> Content-And-Encoding-Id?

Media-Encoding ?

---

From: Zach Shelby <[email-masked]>
Date: Tue, 24 Apr 2012 10:42:37 +0300

> On Apr 23, 2012, at 8:51 PM, Zach Shelby wrote:

Yes, I like that better.

Zach

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Apr 2012 08:37:25 -0700

> Media-Encoding ?

Content-Format ?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Apr 2012 17:43:01 +0200

> Content-Format ?

That's closer.
Format = Type + Encoding, very well.

But why content?
Payload-Format?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Apr 2012 17:47:35 +0200

> Payload-Format?

On the other hand, Content-Format can still be abbreviated ct -- no need to change link-format on-the-wire :)

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Apr 2012 08:53:23 -0700

> Format = Type + Encoding, very well.

good point - I like Payload-Format better

---

From: Zach Shelby <[email-masked]>
Date: Tue, 24 Apr 2012 19:39:46 +0300

> On the other hand, Content-Format can still be abbreviated ct -- no need to change link-format on-the-wire :)

Oh, very good point!

My final vote is for Content-Format (keeping ct= as the link-format attribute) :-)

Zach