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

[Ned Freed <[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.

I'm afraid I'm not seeing any substantive difference. In fact PER might
arguably be better, because if memory serves the OSI presentation layer
included the means of negotiating use or non-use of PER as well as identifyin
the specific ASN.1 schema involved.

> 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.

But that's only part of the problem. Consistent interpretation of the field is
of course necessary, but not sufficient.

> 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.

And pray tell how is a generic +exi processor going to be able to know that?
Your specification doesn't define any sort of registry for saying "media type
foo has this schema as a default", nor is there any way to query such a
registry, and it's an open question as to whether or not such a registry is
viable or usable in this context.

> 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.

As I said in a previous email, mandating the presence of the SchemaID field
might be an acceptable compromise. Or it might not. This is not up to me, and
to be frank I'm still on the fence about this approach myself.

				Ned