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

[Julian Reschke <[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.

> Either use the Content-Encoding (and Accept-Encoding) header itself,
> by registering a new Content-Coding value [1] (foo+exi), or (better)
> ask the W3C EXI WG to publish a Note defining an extension-header for
> specifying or requesting a schemaID (and more generally, perhaps,
> other properties specifiable in the EXI Options docuemtns).
>
> Not only would the second option fit the architecture better, it would
> remove the necessity for publishing a new RFC every time you update
> the relevant schema!

Adding more request headers here is problematic because they contribute 
to the message size, even when they are never used.

Best regards, Julian