Subject: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Mar 2012 11:49:40 +0200

As per the discussion regarding an +exi suffix on this list, I wrote up a short draft describing the registration for such a suffix, when it would be applicable, and what the interoperability requirements are. I will send this to the CoRE list and to ZigBee SE2 for comments as well.

http://www.ietf.org/id/draft-shelby-exi-registration-00.txt

Zach

Begin forwarded message:

> From: [email-masked]
> Date: March 5, 2012 11:43:30 AM GMT+02:00
> To: [email-masked]
> Subject: New Version Notification for draft-shelby-exi-registration-00.txt
> 
> A new version of I-D, draft-shelby-exi-registration-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-exi-registration
> Revision:	 00
> Title:		 The +exi Media Type Suffix
> Creation date:	 2012-03-05
> WG ID:		 Individual Submission
> Number of pages: 5
> 
> Abstract:
>   Efficient XML Interchange (EXI) is an XML representation technique
>   specified by the W3C to provie a binary alternative to the standard
>   text XML representation.  This document defines a new Structure
>   Syntax Suffix "+exi" for use in a specific class of protocols, where
>   &quot;exi&quot; content-type encoding or the generic "application/exi" Media
>   Type are not applicable.
> 
> 
> 
> 
> The IETF Secretariat

-- 
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: Carine Bournez <[email-masked]>
Date: Thu, 8 Mar 2012 03:33:54 -0500

Hi,

Quoting part of the IANA considerations section:

>   Interoperability considerations:  The registration of a Media Type
>      using this suffix MUST reference the XML Schema that is used to
>      encode/decode a payload identified by that Media Type.  If multi
>      versions of this Schema will evolve during the lifetime of the
>      protocol, the protocol MUST either register multiple Media Types
>     (one for each version) or use the Schema ID option of EXI to
>     indicate the version of the Schema.

I think this is a really bad idea. The schemaID option is meant to 
convey the information about the schema(s) in use when the schema-informed
mode is chosen. Tying the schema to the media type is very likely to
produce interoperability issues as well as compatibility issues 
between versions of a schema. In any case, you have to agree on other options
or send them in the EXI stream, so why schemaID should get special treatment
here? 

A +exi suffix might help conveying the original media type *and* the 
encoding whenever the content-encoding header is not available
in a protocol. However, the suffix should not try to replace some of
the existing EXI mechanisms at all.

-- 
Carine Bournez -+- W3C Europe

---

From: Zach Shelby <[email-masked]>
Date: Thu, 8 Mar 2012 11:33:21 +0200

Hi Carine,

> or send them in the EXI stream, so why schemaID should get special treatment

I agree that the EXI header should be used to convey the EXI specific options needed to decode the payload (I got a similar comment on the CoRE list). The SchemaID field is not very useful on its own however, so the goal of this text should be that the media type registration for +exi needs to define what to place in the SchemaID field of the header. It needs to point to a specification of the schemas, and how the value in the SchemaID field corresponds to them. It may also e.g. define a default schema to use if the SchemaID field is elided. This is an important aspect to the efficiency of EXI for M2M applications, where often our EXI payloads are only tens of bytes long. Placing a 30-50 byte URI reference to the XSD in the header of that EXI payload would be unacceptable, however a short integer ID or such is OK. 

I am fine with removing the text that implies the media type alone identifies the schema. However the media type does define the semantics and meaning of the data carried in the payload once it is decoded (regardless of the schema version or variation). 

> the existing EXI mechanisms at all.

Right, and in particular the +exi suffix is only meant to be used in cases where content-encoding is not being performed, in other words Schema-informed mode is used and there is no intermediate use of XML. For other use cases this document should recommend the use of the exi content-encoding or the generic application/exi media type.

Zach

---

From: Carine Bournez <[email-masked]>
Date: Thu, 8 Mar 2012 12:47:09 -0500

Hi,
> I agree that the EXI header should be used to convey the EXI specific options needed to decode the payload (I got a similar comment on the CoRE list). The SchemaID field is not very useful on its o…

Specifying the schemaID format for a foo+exi media type is indeed an
interesting idea, this is not what I understood from your draft text.
In any case, a MUST requirement for that is probably too strong.

> I am fine with removing the text that implies the media type alone identifies the schema. However the media type does define the semantics and meaning of the data carried in the payload once it is…

Changing the text to something clearer about specifying schemaID, and 
possibly about the use of EXI extension points (datatype representation
maps), would be useful as interop consideration..

> Right, and in particular the +exi suffix is only meant to be used in cases where content-encoding is not being performed, in other words Schema-informed mode is used and there is no intermediate us…

"there is no intermediate use of XML" is a bit obscure to me, EXI *is* XML.
If you mean no text serialization of XML, I don't see the relation with
the ability or not to use the content-encoding. The content-encoding is also
not reserved to schema-informed mode.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Mar 2012 19:06:34 +0100

> In any case, a MUST requirement for that is probably too strong.

Well, no.

The point here is to have media types such that their instances can be parsed by extremely constrained devices.
The viability of such a format is pretty much proportional to the number of MUSTS (well, inversely proportional to the number of choice points).
*Any single* variability in the format may double the cost of decoding it.

Big-device (where a smartphone is a very big device) considerations just don't apply for class-1 devices.

Flexibility is overrated.  Nail things down!

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Sun, 11 Mar 2012 15:13:08 +0200

Carine,

Based on this thread, I think I have enough input to make a new update to the draft and try to focus on the media type registration defining how the schemaID is to be interpreted. I will also look at the EXI extension point issue. We should clearly point out that all EXI settings etc. are controlled by the EXI header. I will post a link to this list when the new version is available - latest during the IETF week...

Thanks,
Zach