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

[Zach Shelby <[e-mail]>]

Ned,

On Apr 11, 2012, at 6:57 PM, Ned Freed wrote:

>> If decoding requires additional information, than IMHO you can't use
>> HTTP's Content-Coding or Transfer-Encoding. By all means, if you think
>> otherwise then send feedback to the HTTPbis WG.
> 
> Julian is 100% correct here. If EXI requires knowledge of the type itself, it's
> not a separable encoding, which is what Content-Coding, Transfer-Encoding, and
> Content-Transfer-Encoding all require. And while I suppose we could adopt the
> foo+exi approach, having an explosion of encodings is a really bad idea.
> 
> And if this is the case, it really isn't suitable for a +exi suffix either.
> +exi is supposed to mean the format can at least be parsed,  independent of any
> knowledge of the type semantics. This is why I support the idea of having +ber
> and +der but not +per - with +per you have to know the ASN.1 schema in order to
> parse the material properly.
> 
> For better or worse, we don't currently have a place in the architecture for
> these entities. We could define some other sort of type naming convention if
> there's really a need for it, but adding additional out of band information
> that has to be processed in order to interpret the material correctly is rather
> obviously highly problematic.

I agree with your analysis in general. Luckily the situation with EXI schema-informed mode is not as bad as with PER. We actually do have a schemaID field in the EXI header where some indication about the OOB schema information can be included. The standard itself however doesn't specify how to use that field. It is really a documentation problem we're trying to solve, where the application/foo+exi registration includes the definition of how to interpret the schemaID field of the EXI header. 

Let me use SenML as a practical example. Here draft-jennings-senml-08 defines a schema for use with the EXI serialization (version 1 of the markup). In the application/senml+exi IANA registration, I would indicate that in the absence of the schemaID field the schema is by default version 1 of SenML. For future versions, the integer of the SenML version is to be included in the schemaID field. This way a single senml+exi registration can handle this, and all future versions of the SenML markup.  

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