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

From: Philippe Le Hegaret <[email-masked]>
Date: Thu, 19 Aug 2010 10:40:59 -0400

Dear IESG participants,

This message is to request approval for the registration of three media
types:
1.
 application/mathml+xml
 B.2 Media type for Generic MathML 
 http://www.w3.org/TR/MathML3/appendixb.html#media-types-mathml
2.
 application/mathml-presentation+xml
 B.3 Media type for Presentation MathML 
 http://www.w3.org/TR/MathML3/appendixb.html#media-types-mathml-p
3.
 application/mathml-content+xml
 B.4 Media type for Content MathML 
 http://www.w3.org/TR/MathML3/appendixb.html#media-types-mathml-c

This message follows the procedure described in the Media Type
Specifications and Registration Procedures, section 5.2, "IESG
Approval" [1]. The proposed media types were sent for preliminary
community review on October 7, 2009:

 http://www.imc.org/ietf-xml-mime/mail-archive/msg01118.html

Comments were received and are believed to be addressed:
 http://www.imc.org/ietf-xml-mime/mail-archive/msg01122.html

We believe the media types are now ready for IESG approval.

Thank you, 

Philippe

[1] http://www.ietf.org/rfc/rfc4288.txt

-- 
Philippe Le Hégaret, W3C Interaction Domain Leader
World Wide Web Consortium (W3C)
http://www.w3.org/People/LeHegaret/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Aug 2010 23:27:37 +0100

>Dear IESG participants,
Hi Philippe,
I will process these for the next IESG telechat (September 9th), unless 
there is some urgency.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 2010 18:19:57 +0100

Paul Libbrecht wrote:

> Dear Alexey,
Dear Paul,

> the timeline of the publication of the MathML 3 specification as a 
> recommendation is that votes close on September 10th and that we reach 
> the recommendation status before September 30th, the end of our 
> working group´s current charter.
>
>  
>
> So September 9th for an acceptance sounds just fine; at least as long 
> as there is no risk in this processing.
>
>
> Can you confirm my belief that there´s no risk?
>
There might be some (possibly blocking) comments on the registrations. I 
will try to send them before next Thursday (September 2nd).

Best Regards,
Alexey

> thanks in advance
>
>  
>
> paul
>
>  
>
>  
>
> Le 25 août 2010 à 00:27, Alexey Melnikov <[email-masked]> a 
> écrit :
>

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 2010 18:40:18 +0100

>Dear IESG participants,
Dear Philippe,

> http://www.imc.org/ietf-xml-mime/mail-archive/msg01122.html
I was preparing a management item for IESG and realized that the review 
request was sent to a different mailing list from the one required by 
MIME type review process. The review request needs to be sent to 
[email-masked] as detailed on 
<http://trac.tools.ietf.org/group/iesg/trac/wiki/MediaTypes>

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 2010 19:17:02 +0100

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: Julian Reschke <[email-masked]>
Date: Sun, 29 Aug 2010 20:25:31 +0200

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

> application/mathml+gzip), each using a separate file extension.

Absolutely.

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

> by SMTP. HTTP is using a different header.

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

Best regards, Julian