W3C home > Mailing lists > Public > xmlp-comments@w3.org > October 2004

RE: Issue 501 closed

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Fri, 29 Oct 2004 13:29:19 -0700
To: "Martin Gudgin" <mgudgin@microsoft.com>, <andrea.vine@sun.com>, <xmlp-comments@w3.org>
Cc: "I18n WSTF" <public-i18n-ws@w3.org>, "Martin Duerst" <duerst@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHOELLILAA.aphillips@webmethods.com>

Hi Martin, 

We discussed the results of our teleconference with you at our meeting yesterday and are satisfied with your resolution. Our official response is: "You may consider issue 501 closed."

I should note that one thing I did not point out during our meeting related to this topic did surface in our discussion yesterday. I want to take the time to point it out to XMLP, but you should not consider it as cause for re-opening this issue. It is, however, a consideration at implementation time and as a reinforcement/ratification of the changes we discussed.

The issue is that MIME content-types, as defined in various RFCs [1][2], have a well-known implementation issue related to the charset parameter. Namely: if the parameter is omitted, the charset to apply to the content must be US-ASCII. This is true even for self-announcing file formats, such as XML (it is one reason why the application/xml+* MIME types exist). 

Basically, these definitions mean that implementations of Representation which send text must introspect the character encoding (much as web servers are wont to do) or receivers are (supposed to be) compelled to infer the unlikely-to-be-true US-ASCII encoding. In practice this can be very hard for a server, such as a SOAP processor, to do accurately. (The counter argument is that the SOAP processor may have transcoded the data without modifying internal character encoding identifiers, such as the XML document declaration or HTML <meta> tag, when attaching the data).

We note that many applications (such as web browsers) try to heuristically determine the encoding when the charset parameter is missing. However this is likely to be new ground for implementations of your spec and may represent a challenge to interoperability. 

Again, this is not in disagreement with your solution to issue 501 or as an attempt to raise a new issue: there is no substantive issue with your document. I merely point it out as an implementation consideration (hardly new or original to XMLP) that bears repeating, since it may not occur to folks in the Web services world. The wording proposed during our teleconference with you performs the task adequately.

Best Regards,


[1] http://www.ietf.org/rfc/rfc2376.txt
[2] http://www.ietf.org/rfc/rfc2046.txt

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: 2004年10月29日 10:24
> To: andrea.vine@sun.com; aphillips@webmethods.com; xmlp-comments@w3.org
> Cc: I18n WSTF; Martin Duerst
> Subject: Issue 501 closed
> Andrea, Addison,
> With respect to issue 501[1] the XMLP WG decided to add the following
> text to section 4.3.2:
> "If the media type identified by the value of an xmime:contentType
> attribute information item is a text based media type then the value of
> the xmime:contentType attribute information item SHOULD include a
> charset parameter."
> as discussed with you on our telephone conference on 2004-10-27. The
> latest editor's copy[2] reflects this change.
> We trust this satisifies your concern and therefore resolves issue 501.
> Regards
> Martin Gudgin
> For the XMLP WG
> [1] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x502
> [2]
> http://www.w3.org/2000/xp/Group/3/06/Attachments/Representation.xml#rep-
> media-type
Received on Friday, 29 October 2004 20:29:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:00 UTC