[MathML3-last-call] comment on media-type registrations for MathML

The following comment was made about the media-types appendix of  
MathML3 last call.

Most of these comments are easy to address.
The biggest ones are the provision of security considerations and the  
provision of the appropriate text so that it easy to identify what the  
type are for.

paul


as found on http://www.alvestrand.no/pipermail/ietf-types/2009-October/002270.html

> De : Bjoern Hoehrmann <derhoermi@gmx.net>
> Date : 7 octobre 2009 16:14:13 GMT+02:00
> À : Paul Libbrecht <paul@activemath.org>
> Cc : ietf-types@iana.org, ietf-xml-mime@imc.org
> Objet : Rép : please comment on media-type registrations for MathML
>
> * Paul Libbrecht wrote:
>> In this specification draft, one can find three registrations for
>> media-types related to MathML in the appendix B:
>> 	http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixb.html
>
> 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
>  3023."
>
> 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 · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http:// 
> www.websitedev.de/





as found on: http://www.alvestrand.no/pipermail/ietf-types/2009-October/002268.html
> Réenvoyé-De : member-math@w3.org
> De : Bjoern Hoehrmann <derhoermi@gmx.net>
> Date : 7 octobre 2009 17:53:51 GMT+02:00
> À : Paul Libbrecht <paul@activemath.org>
> Cc : ietf-types@iana.org, ietf-xml-mime@imc.org, Math Working Group  
> WG <member-math@w3.org>
> Objet : Rép : please comment on media-type registrations for MathML
> Archived-At: <http://www.w3.org/mid/necpc51tlcncic58sv7igkhm7k394stb32@hive.bjoern.hoehrmann.de 
> >
>
> * Paul Libbrecht wrote:
>>> 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:
>>  http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter6.html#encoding-names
>> should it be repeated in our appendix hence in this registration  
>> then?
>
> That does not say whether I can use these types with MathML 2.0 or  
> not.
> I would rather say that the contents of 6.2.3 should be kept together
> with the registration information, and it would not hurt to  
> elaborate a
> little bit more than the proposal does at the moment. Personally I  
> can-
> not tell, for example, when I'd ever use mathml-content+xml.
>
>> Wouldn't it be wishable to reference draft-murata-kohn-lilley-xml-03
>> instead? Does anyone know when it'd be authoritative.
>
> There have been proposals under that name for over five years now, it
> is not very likely that consensus around proposed changed will be  
> found
> and reflected in updated drafts in the near future.
>
>>> 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?
>
> MathML implementers will know better what kind of security problems
> they have addressed in their implementations, so perhaps they could
> contribute something to this. Yes, that would be the kind of sentence
> except that it's a bit too obvious perhaps. An actual issue that may
> have security implications is, for example, what if you get a MathML
> document that's labeled as "content" but actually has "presentation"
> markup or vice versa?
>
>>> I believe the text you have under "interoperability considerations"
>>> is misplaced there in all three cases.
>>
>> misplaced like it's wrongly formulated? Formatted?
>
> As in, it does not belong there. Interoperability considerations are
> for known and anticipated interoperability problems. To take the first
>
>  entities with this media type also have the media type
>  application/xml and may also have the media types
>  application/presentation-mathml+xml or
>  application/content-mathml+xml.
>
> That does not mention a problem, but makes a somewhat redundant state-
> ment, and then a misleading statement about the relationship of this
> type to other types (I would say both are in fact incorrect, entities
> are labeled with media types, they do not intrinsically "have" them).
> This is something I would expect in a discussion of the type that pre-
> cedes the template information.
>
>>> 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
>
> If you mean that you disagree, then regardless of whether it is clear
> or not, it is common practise to do so.
>
>>> 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.
>
> I would be fine with a pointer to the authorship and contact infor-
> mation in the specification.
> -- 
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http:// 
> www.websitedev.de/
>



>