Request for review of 9 MIME type for 3GPP SA4

[Chris Lilley]

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 at w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG