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

[Julian Reschke <[e-mail]>]

On 29.08.2010 20:17, Alexey Melnikov wrote:
> 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).

That's true for Transfer (En)Codings in HTTP. There are also 
Content-Codings, which, as Alexey said, operate at the payload level.

Most importantly, there is no Content-Transfer-Encoding header in HTTP.

> 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.

Absolutely.

I recall that we had the same discussion about the SVG registration?

> 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.

So much for starting commenting before reading the whole mail :-)

Best regards, Julian