MPEG asks for MIME review for the MPEG21 file format

[Graham Klyne]

[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