Re: Requesting IESG Approval for the Media Type application/mathml+xml, application/mathml-presentation+xml, and application/mathml-content+xml

[Alexey Melnikov <[e-mail]>]

Dear Philippe/Paul,
I have the following comments on the registration templates. All of them 
contain the following text:

>     MathML documents may be transmitted in compressed form using gzip 
> compression. For systems which employ MIME-like mechanisms, such as 
> HTTP, this is indicated by the Content-Transfer-Encoding header; for 
> systems which do not, such as direct filesystem access, this is 
> indicated by the filename extension and by the Macintosh File Type 
> Codes. In addition, gzip compressed content is readily recognised by 
> the initial byte sequence as described in [RFC1952] section 2.3.1.

It looks like this text is talking about 2 different transfer encodings 
of the same MIME type. If that is correct, then I don't think this 
paragraph belongs here, because transfer encodings operate at protocol 
levels (e.g. HTTP, SMTP) from MIME types (payloads).

On the other hand, if this text is saying that the same MIME type and 
file extension is being used for both XML and Gzipped representation of 
XML, then I think there is a bigger problem here. My understanding is 
that that is a violation of MIME type design and that you should really 
be using 2 separate MIME types (e.g. application/mathml+xml and 
application/mathml+gzip), each using a separate file extension.

Also, I've noticed that application/mathml-presentation+xml, and 
application/mathml-content+xml don't actually register any new file 
extensions.

And finally, Content-Transfer-Encoding is not used by HTTP, it is used 
by SMTP. HTTP is using a different header.

/**/