Re: Review of Content-Encoding: value token [exi]

Dear HTTPbis,
 
Thank you for your careful review and consideration of the W3C EXI working
group's proposal for a new HTTP content coding token. In reviewing this
thread, I see there have been some initial questions and concerns regarding
the proposal and that some of these may have already been addressed through
the course of discussion. While evaluating various options for EXI content
coding, the W3C EXI working group has had similar discussions both
internally and with W3C Technical Architecture Group (TAG) members. As part
of our evaluation, we considered other alternatives, such as the use of a
specific application/exi media type, a parameterized media-type and media
types of the form svg+exi; however, the EXI content coding solution turned
out to be the lesser of several evils that best satisfied our requirements
and use cases. 
 
While there seems to be a general preference that content codings be
octet-preserving, we noted that the current definition provides the
flexibility to support content codings that are not strictly
octet-preserving. We also noted there the IANA content coding registry
already contains a precedent for this [1]. In particular, the pack200
content coding is not byte preserving.
 
In speaking with Mark Nottingham last week, I understand HTTPbis will be
re-instating the registry for HTTP content coding value tokens and reviewing
requests for new content codings. The W3C EXI working group would like to
submit a request to register the value token "exi" as a new content coding.
They have asked me to work with you to answer questions about this request
and elaborate as needed regarding our use cases and rationale. 
 
Would it be possible to add this request to you current list of work items?
 
    Respectfully,
 
    John
 
[1] http://www.iana.org/assignments/http-parameters
 
Editor, W3C EXI specification
 <mailto:john.schneider@agiledelta.com> john.schneider@agiledelta.com
 <http://www.agiledelta.com> http://www.agiledelta.com
 
 

Re: Review of Content-Encoding: value token


*	This message: [ Message body
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0779.html#start
779>  ] [ Respond
<mailto:ietf-http-wg@w3.org?Subject=Re%3A%20Review%20of%20Content-Encoding%3
A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.loc
aldomain%253E&References=%253C1245887149.9223.192.camel%40localhost.localdom
ain%253E>  ] [ More
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0779.html#optio
ns3> options ] 

*	Related messages: [ Next
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0780.html>
message ] [ Previous
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0778.html>
message ] 

From: Henrik Nordstrom <henrik@henriknordstrom.net
<mailto:henrik@henriknordstrom.net?Subject=Re%3A%20Review%20of%20Content-Enc
oding%3A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localh
ost.localdomain%253E&References=%253C1245887149.9223.192.camel%40localhost.l
ocaldomain%253E> > 
Date: Thu, 25 Jun 2009 01:45:49 +0200
To: David Morris <dwm@xpasc.com
<mailto:dwm@xpasc.com?Subject=Re%3A%20Review%20of%20Content-Encoding%3A%20va
lue%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.localdoma
in%253E&References=%253C1245887149.9223.192.camel%40localhost.localdomain%25
3E> > 
Cc: ietf-http-wg@w3.org
<mailto:ietf-http-wg@w3.org?Subject=Re%3A%20Review%20of%20Content-Encoding%3
A%20value%20token&In-Reply-To=%253C1245887149.9223.192.camel%40localhost.loc
aldomain%253E&References=%253C1245887149.9223.192.camel%40localhost.localdom
ain%253E>  
Message-Id: <1245887149.9223.192.camel@localhost.localdomain> 

tor 2009-01-22 klockan 22:40 -0800 skrev David Morris:

> Exact reconstruction is always safest. But it seems to me that a new 

> encoding for an html (or xml) document which stripped trailing blanks and 

> tabs might satisfy the above constraints. Since ETag creation is the 

> responsiblity of the origin server, I don't think the transformation I

> describe would matter. The ETag would need to change if the pre-encoding 

> content changed.



Note: Content-Encoding changes REQUIRES ETag to change as well, even for

weak etags. Two repesentations of the same URI with different

Content-Encoding MUST NOT share the same ETag. ETag selection is AFTER

content-encoding, not before.



HTTP as such does not really care what kinds of transforms

Content-Encoding applies. The genereal expectation is that it's a

lossless transform, but this is not a requirement and do not need to be

a requirement.



Regards

Henrik