Re: please comment on media-type registrations for MathML

Paul Libbrecht <paul@activemath.org> Tue, 24 November 2009 16:04 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOG40OO094376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 09:04:00 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nAOG40qG094375; Tue, 24 Nov 2009 09:04:00 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from smtp.dfki.de (lnv-106.sb.dfki.de [134.96.191.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOG3mwx094354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-xml-mime@imc.org>; Tue, 24 Nov 2009 09:03:59 -0700 (MST) (envelope-from paul@activemath.org)
Received: from smtp.dfki.de (localhost [127.0.0.1]) by imss.7 (Postfix) with ESMTP id B7D9C31743; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
Received: from mail.dfki.de (lnv-104.sb.dfki.de [134.96.191.146]) by smtp.dfki.de (Postfix) with ESMTP id A4E2331737; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
Received: from [192.168.3.43] (p5DDEF067.dip.t-dialin.net [93.222.240.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.dfki.de (Postfix) with ESMTPSA id 306D131165; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
From: Paul Libbrecht <paul@activemath.org>
To: Paul Libbrecht <paul@activemath.org>
Subject: Re: please comment on media-type registrations for MathML
References: <D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.corp.dessci>
Message-Id: <22D72CB8-C5B2-49F9-BC47-9CC22C259BA5@activemath.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 24 Nov 2009 17:02:56 +0100
X-Mailer: Apple Mail (2.936)
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>

Dear media-types-expert,
Dear Björn,


> Forwarded-from : member-math@w3.org
> From : "Robert Miner" <robertm@dessci.com>
> Date : 24 novembre 2009 03:43:50 GMT+01:00
> To : <member-math@w3.org>
> Archived-At: <http://www.w3.org/mid/D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.corp.dessci 
> >
>
> Dear Björn,
>
> I am writing in response to your comments on the media-type
> registrations for MathML given in Appendix B of the Last Call draft of
> the MathML 3 Specification.  Your original comments are recorded at
> http://www.alvestrand.no/pipermail/ietf-types/2009-October/ 
> 002268.html.
>
> We have modified Appendix B, and believe we have addressed the issues
> you noted. The changes are explained below, and you can see the draft
> changes in an editor's draft of the spec located at
>
> http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html
>
> Since we need to record the resolution of all Last Call comments,
> could we ask you to let us know whether you accept these changes as
> addressing your comments?  Thanks in advance.
>
> The specific actions taken are:
>
> > 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.
>
> A new introductory section entitled "Selection of Media Types for
> MathML Instances" was added to specifically address this issue.  The
> related text in section 6.2.3 of the spec is essentially summary in
> nature, and was therefore left unchanged.  It already referred to
> appendix B for detailed information on the usage of the media types,
> and that information is now given.
>
> The section carefully defines the presentation and content MathML
> vocabularies, and gives a clear rule for determining what media type
> should be used for a given MathML instance based on the contents of
> that instance.
>
> The section also contains some explanation and examples to motivate
> the usage of the three MathML media types.  The section ends by
> addressing use of the media types with earlier versions of MathML
>
> > 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."
>
> These sections have been edited to match the proper format.
>
> > The security considerations are missing (in fact the specification
> > as a whole does not have a security considerations section either).
>
> Security considerations have been added. We have listed both the
> generic issues common to similar XML languages, and two issues
> specific to MathML: the possible presence of executable code in
> semantic annotations, and the (possibly inadvertant) denial of service
> risks arising in computational contexts from trying to solve
> unsolvable problems.
>
> > I believe the text you have under "interoperability considerations"
> > is misplaced there in all three cases.
>
> This text has been completely rewritten.  Again, there are some
> generic considerations common to similar XML languages, as well as
> several MathML specific issues.  In particular, lack of versioning
> information in MathML instances introduces a backward compatibility
> concern, and the result of evaluating MathML expressions is not
> guaranteed to be the same in different computational systems.
>
> > 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.
>
> Thank you for the clarification on the purpose.  We have filled out
> the section appropriately.
>
> > 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
>
> Following other media type registrations under the BCP13 process, we
> have changed this to list Paul as the person, with the Math WG group
> mailing list for the address, followed by a pointer to the public W3C
> Math web site for additional information.
>
> --Robert
>
>