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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Sep 2010 21:13:18 +0100

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2010 10:48:02 +0100

Paul Libbrecht wrote:

> Dear Alexey,

Dear Paul,

> In the working group teleconference right now, it was agreed to add 
> the following paragraphs to the interoperability considerations of the 
> specific MathML media-types.
>
> For application/mathml-presentation+xml:
>
>> This specification does not record a file extension for the media 
>> type "application/mathml-presentation+xml" because we expect 
>> tools processing files with MathML inside to have sufficient 
>> information with the generic media-type (application/mathml+xml) 
>> while other content negotiation forms will take advantage of specific 
>> media-types.
>
> For application/mathml-content+xml:
>
>> This specification does not record a file extension for the media 
>> type "application/mathml-content+xml" because we expect 
>> tools processing files with MathML inside to have sufficient 
>> information with the generic media-type (application/mathml+xml) 
>> while other content negotiation forms will take advantage of specific 
>> media-types.
>
> The changes are visible in the editor draft at:
>
> (in the group's spec).
> I believe this addresses all comments received thus far; MathML should 
> move to recommendation stage at the end of tomorrow.

Sounds good and your recent additions look good as well.

> If it is possible to include the quote to an IESG registration, it'd 
> be the best timing!

FYI, IESG has approved the registrations yesterday. The official 
announcment should be sent out early next week.

> paul
>
> On 6 sept. 2010, at 23:25, Paul Libbrecht wrote:
>
>>> 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.
>>
>> I'll discuss it with the group.
>> Since these are "sub-types", it is indeed a logical consequence that 
>> the .mml suffix is applicable.
>>
Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address