Request for review of 9 MIME type for 3GPP SA4

[Bjoern Hoehrmann]

* Magnus Westerlund wrote:
>Please review the proposal in the attached word document in the previous 
>mail as it intended to fix the total lack of MIME type specifications in 
>the referenced 26.346.

Well, I did, but it seems that this information was added later to the
document; not all viewers support such editing information, using more
portable formats might be more appropriate here.

The +xml types all lack a charset parameter. This is needed to allow
general purpose XML applications like Validators to decode the format
without hard coded knowledge of the media type.

Some of the XML types have encoding considerations like "The content
is well formed XML document without any binary parts" which sort of
misses the point of the field. These should simply refer to the
considerations in RFC 3023.

For application/mbms envelope+xml it is unclear what the syntax of the
optional parameters is, from the brief description it seems these are
meant to be boolean parameters but it's not clear how to specify true
or false values.

  This media format contains XML and may contain binary embedded
  objects using CDATA sections within the XML. Thus for transports
  not supporting binary content BASE64 [82] encoding is suitable.

This is incorrect, XML documents cannot include binary data, only
text. CDATA sections are not exception, they are just concerned with
characters that introduce markup like & and <.

application/mbms-user-service-description+xml is also a bit unclear
about the serviceID parameter, in particular, it is not clear whether
a single service identifier must stille be quoted, or if there are
constraints about what is a legal identifier for the purposes of the
paramter; it should be possible to derive a clear grammar for legal
parameter values from the registration.

The security considerations are

  This media format is used to configure the receiver on how to
  participate in a service. This format is highly suspectible to
  manipulation or spoofing for attacks desring to misslead a receiver
  about a session. Both integrity protection and source authentication
  is recommend to prevent missleading of the receiver.

It is unclear how to protect the integrity of such data objects, a
brief look at the corresponding schema suggest that e.g. use of XML
digital signatures with such content is prohibited.
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/