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

[Ned Freed <[e-mail]>]

> On 2012-04-11 17:15, Henry S. Thompson wrote:
> > Carsten Bormann writes:
> >
> >> EXI requires out of band information to use the "Schema-Informed"
> >> mode.  In the Internet, This would normally be provided in an
> >> Internet media-type definition.  The media-type definition may also
> >> want to constrain the allowable values for the numerous options EXI
> >> provides, allowing for constrained implementations of EXI.
> >
> > Your conclusion (use media type) doesn't follow.  Consider the analogy
> > of Content-Encoding: gzip -- suppose gzip provided improved
> > performance based on the decade in which the encoded document was
> > written, since natural language priors slowly shift over time.  Now
> > decoding requires OOB information about document creation date.  How shall
> > we provide it.  I know -- we'll define media types
> > application/...+gzip for every decade of interest!  I hope it's
> > obvious that would be a mistake. . .
> >
> > If decoding requires some parameters, surely the right thing to do is
> > to transmit them in the obvious place, i.e. in the response message
> > header.

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

				Ned