Re: [apps-discuss] Feedback on draft-shelby-exi-registration-01

[Zach Shelby <[e-mail]>]

Hi Robin,

First some background here. We have two different M2M applications that are using EXI in Schema-informed mode, are already using other +xml/+json etc. media types and have been requesting to use a +exi suffix. Through discussion on this mailing list we determined that the way we are using this probably doesn't fit well under the category of content-encoding (but that is philosophical) and that a registration would be useful for interoperability around the use of the schemaID field. 

- ZigBee Smart Energy 2.0
- SenML (http://tools.ietf.org/html/draft-jennings-senml-08) 

I was the poor soul to volunteer to write up this draft to see what such a registry would look like. None of us involved here are absolutely determined to do it like this, but we do want to explore if this could ensure better interoperability for this use of EXI. 

On Apr 4, 2012, at 4:28 PM, Robin Berjon wrote:

> Dear all,
> 
> please find some notes below on the draft-shelby-exi-registration-01 proposal that describes a +exi media type suffix. Before I jump in, I would like to make it clear that these comments are strictly my own and are not made as any of former chair of the EXI WG, the XBC WG, or as member of the W3C TAG.
> 
> 
> • It is mentioned that the +exi suffix is defined "for use in a specific class of protocols". It further seems to be implied that these protocols do not support conveying content encoding separately from the type. I think that it would be helpful to specify what those protocols are. Given the cost and impact of introducing a +exi structure suffix across the board, without that information I can only suspect that it may be both cheaper and simpler to update the relevant protocols.

That is not the case. By "protocols" here I am referring to "applications". The web transfer protocols in questions, HTTP and CoAP, can both handle content-encoding. 

> Additionally, if those protocols are designed to be simpler, easier to process profiles of HTTP, given that the use case covers devices that obviously already have an EXI decoder, in absence of further information I also wonder if those protocols could not be replaced by some form of EXI-encoded HTTP (possibly minus a number of headers). But naturally this is just a speculation made in absence of information.

The IETF already has an efficient RESTful transfer protocol called CoAP which is a great match for carrying Schema-informed EXI payloads. Thus the increased activity around EXI in the IETF these days. 

http://tools.ietf.org/html/draft-ietf-core-coap-09

> 
> • Reading the following:
> """
> The "+exi" Structure Syntax Suffix defined in this document is 
> appropriate for use with a special class of protocols that:
> 
>   o  Make use of a Media Type to identify the semantics of the protocol
>      payload, and offer more that one serialization of the payloads.
>      For example, some protocols may offer JSON, XML and EXI
>      representations"
> """
> I cannot help but get a strong sense that this is actually making a case for using content coding rather than a structured suffix since it mirrors (certainly in the case of EXI) the semantics versus serialisation distinction. EXI was deliberately defined to be a content coding for XML; the group's decision to define an "exi" content coding rather than a +exi suffix was intentional and not an oversight.
> 
> Conflating content coding and media type seems at the very least strange to me. To take an example, we currently have image/svg+xml. This draft introduces image/svg+exi. Can you explain why that would be a good thing to introduce, and if it is should we also look into adding image/svg+gzip and image/svg+identity?

Well no, that is not what this draft is doing. It does not automatically create a +exi suffix for every media type on earth. It creates registration rules if such a media type would be registered and makes those rules strict to limit the number of registrations as this is for a particular use case. 

> • This part "use EXI as a native encoding (without the use of XML as an interemediate)" worries me because it seems to stem from a rather fundamental misunderstanding of what EXI is. EXI is XML. There is no form of requirement to hop through XML Data Model -> XML -> EXI, and whichever way the EXI bitstream was produced really, really should be immaterial for any protocol transmitting it as well as for a potential media type registration.

Yes, I understand that fully. This is more of a documentation problem with EXI is Schema-informed mode. 

> • This is worrying: "The registration of a Media Type using this suffix MUST describe how to determine the XML Schema that is used to encode/decode a payload identified by that Media Type." What it does is register a generic suffix for a very specific usage. For instance, SVG has no XML Schema. The above therefore precludes SVG from potentially registering image/svg+exi (assuming it would be a sensible thing to do).

That is exactly the point, SVG should use content-encoding as this suffix is only meant for use with Schema-informed EXI. This +exi suffix would only be allowed for use with applications that are using EXI in a way where further information in the registration (use of schemaID) is required for interoperability. All other uses of EXI would be required to continue to use application/exi or content-encoding exi. 

> What's more, EXI is not limited to relying on schema information from XML Schema. It is perfectly valid to use DTDs, RelaxNG, JSON Schema, domain-specific knowledge, etc. in order to generate a schema-informed EXI encoding. So the above essentially rules out a large (possibly the majority) of XML content, and rules out valid EXI encodings.

Agreed, this could obviously be expanded to other valid ways of generating a grammar. 

> Again, 1) that seems very restrictive to justify a structured suffix; and

Correct, that is the whole point as you already have a content-encoding defined. 

> 2) it reinforces the feeling that this registration may be in part motivated by some misunderstanding of EXI

Nope, that is not an excuse that I can claim :-)

Zach

> .
> 
> 
> Thanks!
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
> 

-- 
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: [phone]