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

[Ned Freed <[e-mail]>]

> On 2012-04-14 14:10, Carine Bournez wrote:
> > On Fri, Apr 13, 2012 at 10:16:29PM +0200, Julian Reschke wrote:
> >> On 2012-04-13 22:02, Carine Bournez wrote:
> >>> ...
> >>> I suppose that the registration for application/senml+xml could
> >>> mandate use of a particular schema when encoded with EXI and exclude
> >>> any additional schema (i.e. no schemaId allowed).
> >>> ...
> >>
> >> Nope. Content-Encoding and media type are orthogonal things.
> >
> > It was the case until the pack200 content encoding was registered.
> > EXI has not set any precedent here.

> If "pack200" violates that principle, it shouldn't have been registered.
> (Does it? Pointers, please)

My understanding is that pack200 is a type-specific compression format. That
is, it only works if the input is a jar file. In this sense there is overlap
with EXI - I believe EXI relies on the input having XML syntax (although it
doesn't necessarily have to be well formed), which means it is only applicable
to a subset of media types.

If that's indeed the case, then yes, pack200 is not orthogonal to the media
type. That said, it's not in the same class as EXI. I'm pretty sure I can
decompress anything that's been compressed with pack200 with nothing but
knowledge of the pack200 algorithm. I don't need to to have access to an
external schema or type-specific rules about which schema is the default.

I also note that pack200 doesn't present the same sort of issues for
negotiation. A server knows the types of the objects it sends out and therefore
knows when pack200 can and cannot be applied. And a client requesting pack200
encoding and getting it back won't ever have any difficulty handling it. The
most that can be said is that it requires special-case handling on the server
when an encoding is selected. (Which is also the case with EXI.)

> However, just because it happened once doesn't make it correct to do it
> again.

Quite true. Even if pack200 had exactly the same characteristics as EXI, that
would not provide justification for making the same mistake again.

				Ned