Re: please comment on media-type registrations for MathML

Bjoern Hoehrmann <> Wed, 07 October 2009 14:14 UTC

Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id n97EEExA098637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 07:14:14 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id n97EEEU8098636; Wed, 7 Oct 2009 07:14:14 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with SMTP id n97EE9Lm098627 for <>; Wed, 7 Oct 2009 07:14:10 -0700 (MST) (envelope-from
Received: (qmail invoked by alias); 07 Oct 2009 14:14:06 -0000
Received: from (EHLO hive) [] by (mp056) with SMTP; 07 Oct 2009 16:14:06 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19C2fEBZZpCAYFFaqAzZVz0olr00+Efj/UWqfbFux ugpG36cpme+jpJ
From: Bjoern Hoehrmann <>
To: Paul Libbrecht <>
Subject: Re: please comment on media-type registrations for MathML
Date: Wed, 07 Oct 2009 16:14:13 +0200
Message-ID: <>
References: <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.58
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

* Paul Libbrecht wrote:
>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.

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

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

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

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.

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. I do not think having a
generic W3C / W3C Webmaster combination there is a good practise.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·