RE: Issue 501 closed

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,

Addison

[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
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

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