Re: please comment on media-type registrations for MathML

Paul Libbrecht <> Wed, 07 October 2009 15:09 UTC

Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id n97F9OlX002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 08:09:24 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id n97F9OAf002993; Wed, 7 Oct 2009 08:09:24 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id n97F9LoK002982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Wed, 7 Oct 2009 08:09:22 -0700 (MST) (envelope-from
Received: from (localhost []) by imss.7 (Postfix) with ESMTP id 6CDAF317B2; Wed, 7 Oct 2009 17:09:00 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 5951A31702; Wed, 7 Oct 2009 17:09:00 +0200 (CEST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D56583111D; Wed, 7 Oct 2009 17:09:19 +0200 (CEST)
Cc:,, Math Working Group WG <>
Message-Id: <>
From: Paul Libbrecht <>
To: Bjoern Hoehrmann <>
In-Reply-To: <>
Content-Type: multipart/signed; boundary=Apple-Mail-9--404430391; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: please comment on media-type registrations for MathML
Date: Wed, 7 Oct 2009 17:09:16 +0200
References: <> <>
X-Mailer: Apple Mail (2.936)
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

thank you Bjoern,
Le 07-oct.-09 à 16:14, Bjoern Hoehrmann a écrit :

>> In this specification draft, one can find three registrations for
>> media-types related to MathML in the appendix B:
> The first problem I have with this is that there is no word on what
> exactly the various types are for, like if there are any restrictions
> on what should be in a mathml-content+xml vs a mathml-presentation+xml
> document, or if the types can be used with MathML 2.0.

that is defined in chapter 6:
should it be repeated in our appendix hence in this registration then?

> As per RFC 3023, the charset definition and encoding considerations
> should be referenced as follows, which the proposals fails to do:
>  Registrations for new XML-based media types under top-level types
>  other than "text" SHOULD, in specifying the charset parameter and
>  encoding considerations, define them as: "Same as [charset parameter
>  / encoding considerations] of application/xml as specified in RFC
>  3023."

I can change this.
Wouldn't it be wishable to reference draft-murata-kohn-lilley-xml-03  
Does anyone know when it'd be authoritative.

> The security considerations are missing (in fact the specification
> as a whole does not have a security considerations section either).

Can you suggest something?
MathML entities exchanged on the web have the same risks as any  
document that could contain relative references. Is this the kind of  
sentence that could be there?

> I believe the text you have under "interoperability considerations"
> is misplaced there in all three cases.

misplaced like it's wrongly formulated? Formatted?

> I note that under "Applications that use this media type" you have
> "(todo)". Going to Last Call with "todo" markers left is not a good
> practise. I note that the purpose of this field is to give a general
> idea of what kind of applications use it, not to list individual
> software products.

thanks, will do.

> Under "Person & email address to contact for further information"
> the proposal fails to properly separate name and email address, use
> something like "Name <address>" instead.

this appears clear

> I do not think having a generic W3C / W3C Webmaster combination  
> there is a good practise.

Should there be an email? (there's one three lines above)
Should there be a group? That is easy to add.