Request for review of 9 MIME type for 3GPP SA4
Hi, attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them. Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting. TS 26.346 can in its latest form be fetched here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip However some of the references in the chapter relate to text that are being specified and added. They are available in the following document: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050514.zip Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
* Magnus Westerlund wrote:
attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them.
Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting.
"NOTE: The detailed IANA registration information of this content type is tbd." is all I could find with respect to these types. Perhaps the documented is outdated? -- Björn Höhrmann · mailto:bjoern@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/
Hi, 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. Cheers Magnus Bjoern Hoehrmann wrote:
* Magnus Westerlund wrote:
attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them.
Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting.
"NOTE: The detailed IANA registration information of this content type is tbd." is all I could find with respect to these types. Perhaps the documented is outdated?
-- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
* 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@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/
Hi Bjoern, Many thanks for the quick review. See inline for comments and answers. I will work on an update and hopefully be able to send it out before we put it into the next version of the TS 26.346. Bjoern Hoehrmann wrote:
* 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.
Sorry about that, word format with change marks are the by 3GPP required format for contributions. Converting into text would have required me to reformat the sections which wasn't time I like to spend on it.
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.
Okay, adding an optional "charset" parameter is not a problem. If I understand this correctly this equals the encoding="UTF-8" attribute in a <?xml version="1"?> line?
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.
Okay, I will use the "Same as [charset parameter / encoding considerations] of text/xml as specified in RFC 3023." reference sentence. Although I don't think the RFC is easy to use when it comes to referencing it and separating what is for the types registered and what is the general parts.
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.
They are intended to be boolean thou their presence or absence.
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 <.
Okay, this is something I will have to discuss with the group. I think there is some general lack in the scheme on how to embed files within the envelope.
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 identifier is defined as "xs:anyURI" which I think is most suitable to always quote even single instances. I will clarify this.
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.
This protection is intended to be done through the security mechanisms in MBMS. I don't think using the XML digital signatures has been considered at all. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
On Wednesday, August 31, 2005, 3:13:24 PM, Magnus wrote: MW> Hi Bjoern, MW> Many thanks for the quick review. See inline for comments and answers. I MW> will work on an update and hopefully be able to send it out before we MW> put it into the next version of the TS 26.346. MW> Bjoern Hoehrmann wrote:
* 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.
MW> Sorry about that, word format with change marks are the by 3GPP required MW> format for contributions. Converting into text would have required me to MW> reformat the sections which wasn't time I like to spend on it. Even saving to PDF would have been an improvement there.
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.
MW> Okay, adding an optional "charset" parameter is not a problem. If I MW> understand this correctly this equals the encoding="UTF-8" attribute in MW> a <?xml version="1"?> line? Note that this means that all handsets have to read this charset parameter if present, and use it to override the xml encoding declaration in the document if they differ. This is why some groups prefer to rely entirely on the XML encoding declaration, and under 'parameters' state that there is no charset parameter and that encoding is handled "exactly as per RFC 3023 in the case of a missing charset in application/xml".
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.
MW> Okay, I will use the "Same as [charset parameter / MW> encoding considerations] of text/xml as specified in RFC 3023." Don't use text/xml as a model. Use application/xml. text/xml is being deprecated as it has a bunch of problems. MW> reference sentence. Although I don't think the RFC is easy to use when MW> it comes to referencing it and separating what is for the types MW> registered and what is the general parts.
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.
MW> They are intended to be boolean thou their presence or absence. Does MIME syntax allow that?
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 <.
MW> Okay, this is something I will have to discuss with the group. I think MW> there is some general lack in the scheme on how to embed files within MW> the envelope. You might want to take a look at XML-binary Optimized Packaging W3C Recommendation 25 January 2005 http://www.w3.org/TR/2005/REC-xop10-20050125/ -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Hi, I have now updated the registration document. Please review and comment. The document can this time be read using PDF and fetched from this location: http://standards.ericsson.net/westerlund/S4-050563-MIME.pdf Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
Hi, Last year I requested that the media types defined in 3GPP TS 26.346 to be reviewed. They where updated to address the issues listed. I intend to request registration of these types and would therefore like to have them reviewed. Please provide any comments no later than the 5th of November. I know it is the weeks before the meeting. However to be able to address any comments without needing to wait another 3-4 months I need any comments by then. So please review the 11 media types listed in annex C.3 to C.13. A PDF of Annex C is available here. www.denstore.se/IETF/26346-660-annexC.pdf The full document in Word format is available here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-660.zip Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
Hi, There was no comments on the latest request. However as I know actually intend to take care of these media type registrations I like to ensure that no one has any further comment on the current version of the 3GPP specification of the media types. The latest version of the specification is: Whole document in Word format: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/Specs_update_after_SA35/26346-730.z... Media types only in PDF: www.denstore.se/IETF/media-types-26346-730.pdf Please provide any comments by 13th of April. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
participants (3)
-
Bjoern Hoehrmann -
Chris Lilley -
Magnus Westerlund