[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: MS 021c: Content-Type: multipart/related;charset clarificatio n,please
This topic was brought up before. I am cut-pasting excerpts from a previous discussion.
My understanding was that the "charset" attribute at multipart/related level would be
removed, for the same reasons you pointed out.
Dick and others, please comment.
on Fri, 28 Jul 2000 23:32:20 -0400 (EDT) ....
3. BTW what does charset specification at message envelope level (multipart/related) mean? Does it imply, the spec is applicable to all parts in the message (hdr + payload)? I mean what is the purpose of specifying it at that level, as opposed to individual parts (e.g. application/xml, that already supports encoding attribute).
Several people have provided feedback that a charset parameter would make life easier on implementers. I investigated the use of this attribute in both MIME (RFC 2046 section 4.1.2) and HTTP (RFC 2616, section 3.4). Both strongly encourage its use, especially for text entities. The HTTP spec states:
"Applications SHOULD limit their use of character sets to those defined by the IANA registry."
RFC 2387, the multipart/related spec, does not include a "charset" parameter and use of this parameter at the ebXML message envelope level appears to be a non-standard use of the multipart/related media type.
The character set of the payload body part is determined at runtime, and cannot be "set" within the context of the ebXML packaging spec. I suppose the packaging spec could "RECOMMEND" that payload envelopes include the charset attribute when appropriate. I'll be happy to include this "suggestion" under the section describing the payload, if the group thinks this would help. Do I hear a Yea or a Nay?
With regard to the ebXML header document, it is a given that this document is expressed in XML and all XML compliant processors must be capable of handling both UTF-8 and UTF-16 (ref section 2.2 of XML 1.0 spec). The XML prolog contains an attribute (called "encoding") to identify the character set used in the document. It seems to me the information regarding character set is of most value to the XML processor and for this reason the identification of character set should be stated within the XML prolog as opposed to the MIME envelope. By placing the encoding into the XML prolog the XML parser will then have access to the information and can invoke proper processing. If the character encoding were placed into the MIME envelope then the program used to parse the XML document would have to be made "aware" of the encoding either programmatically or by altering the XML document prolog to include the encoding attribute, set to the character set that was identified in the Content-type header. BUT, making such alterations is risky, especially when dealing with signed documents.
The bottom line is this; It appears the character set encoding for the ebXML header should be identified within the XML prolog of the ebXML header document. The ebXML payload envelope Content-type is dynamic and germane to the type of object contained in the payload, in other words. the Content-type is determined by the implementer at runtime. It would appear the BEST we can do within the packaging spec is RECOMMEND that implementers specify the charset attribute within the Content-type of all payload body parts whenever appropriate.
I feel like I'm rambling, but hopefully this diatribe will help you understand my conclusions.
Powered by eList eXpress LLC