
[restricting cc's per Larry's suggestion] Chris Lilley wrote:
On Monday, May 21, 2007, 6:24:33 PM, Graham wrote:
GK> Chris Lilley wrote:
On Monday, May 21, 2007, 11:13:58 AM, Graham wrote: GK> For clarification: this would be the case only when a suitable MIME GK> content-transfer-encoding header is applied, n'est pas?
If its compressed on the fly, yes. If its stored compressed on the server, then Content-Encoding is used.
GK> Ah, I hadn't considered Content-encoding here.
GK> I note that this header is defined by RFC2616 and registered only for use with GK> HTTP GK> (http://www.iana.org/assignments/message-headers/perm-headers.html), which GK> suggests that it is defined only as part of an HTTP protocol transfer.
Yes, I was talking of HTTP here.
Well, what you said here was "stored compressed on the server", which is, I think, somewhat beyond the scope of a protocol specification.
Clearly if one uses, for example, FTP then that isn't an option. But then, neither is the Internet Media type :)
This isn't helping me. Let's see if I can rewind. This thread started with a question about whether +xml was appropriate for the MIME type being registered. If the MIME type can contain binary (non-character) data (independently of any applied encoding which can be determined by appropriate MIME encoding headers), then that seems to be inappropriate. Thus far I think we were in agreement. But when you mentioned an HTTP *protocol* header in the context of "stored compressed on the server" I felt we'd strayed from specifications of requirements for interoperability to specification of implementation, which is beyond the scope of a wire-protocol specification. So on that count I think application of Content-encoding is not a consideration. MIME is not protocol-specific (even if it does have its roots in email), so the registration of a MIME content-type should not be dependent on the interpretation in the context of any particular protocol. So on that count too, I think application of Content-encoding is not a consideration. All of which I think does not affect the content type registration under consideration, unless I'm missing something. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact