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

[Alexey Melnikov <[e-mail]>]

Paul Libbrecht wrote:

> Dear Alexey and Julian,

Dear Paul,

> thank you for your comment. We have discussed the topic and it seems 
> the safest is to indeed not let gzip be considered by the media-type 
> declaration since it would require an extra trip of types. We'll let 
> compressed forms be the sole concern of media transporters such as 
> SMTP or HTTP.
>
> I have now removed the paragraphs and the reference to gzip.
>
>> Checking in xml/media-types.xml;
>> /w3ccvs/WWW/Math/Group/spec/xml/media-types.xml,v  <--  media-types.xml
>> new revision: 1.16; previous revision: 1.15
>> done
>> Checking in xml/references.xml;
>> /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v  <--  references.xml
>> new revision: 1.102; previous revision: 1.101
>> done
>
> Your last comment about the header names in SMTP or HTTP use does not 
> apply anymore.

Yes. This works for me.

> Your also notice that the types application/mathml-presentation+xml, 
> and application/mathml-content+xml are proposed for registration 
> without file extension is intentional: we do not expect such files to 
> be existing, MathML-files are quite rare anyways, but we do expect 
> transmission of such fragments over HTTP or in clipboards.

I think that is Ok. It might be worth mentioning that |.mml can be still 
used for them, e.g. somewhere in the Interoperability Consideration.
|

> The changes are visible on the editor draft:
>   http://monet.nag.co.uk/~dpc/draft-spec/appendixb-d.html#media-types-mathml
>   http://monet.nag.co.uk/~dpc/draft-spec/appendixb-d.html#media-types-mathml-p
>   http://monet.nag.co.uk/~dpc/draft-spec/appendixb-d.html#media-types-mathml-c

This looks good. When will the updated version be officially published?

Best Regards,
Alexey

> paul
>
> Le 29 août 2010 à 20:17, Alexey Melnikov a écrit :
>
>> 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.
>