[uddi-spec] Issue u11: UDDI mandates UTF-8

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

All,	cc: UDDI Spec TC

During its recent conference call, the OASIS UDDI Spec TC proceeded its discussion about our UTF-8 issue. Here are the discussion's main items and the current resolution.

First, the change of the UDDI specifications would have to be treated as errata, but since this issue does not constitute an error in the specification, but is instead a request for a functional change, it was questioned whether an errata is appropriate in general.

Second, there was much discussion on whether it is appropriate in particular to make such a change to existing implementations of UDDI Version 2, such as the UDDI Business Registry. The change can be considered for UDDI Version 3, which is obviously not implemented yet.

Third, it was mentioned that UDDI is not the only specification that relies on UTF-8 only. For example, DSML (http://www.oasis-open.org/committees/dsml/) restricts itself to UTF-8, also.

Fourth, the UDDI Spec TC has not yet been presented with a compelling technical argument for supporting UTF-16. Requiring UTF-16 simply because XML allows it, seems not to be appropriate. Requiring UTF-16 because the byte stream on the wire may be shorter for certain languages is not compelling since XML itself already "inflates" the reference data. Also, a client that uses a given character encoding for a request message cannot expect to get back response messages in the same character encoding, since the server can choose the character encoding for the response message at it's own discretion. And finally, as already mentioned by Dave Ehnebuske previously on this list, no interoperability issues are known for UDDI and existing implementations.

Fifth, the necessary testing for Web services that implement a request-response scenario and support both UTF-8 and UTF-16 is four times higher than for UTF-8 only:
client UTF-8 / server UTF-8, client UTF-8 / server UTF-16, client UTF-16 / server UTF-8, and client UTF-16 / server UTF-16. This is actually one reason why the UDDI specifications from Version 1 on "profiled" the XML specification by using UTF-8 only.

As a consequence, the UDDI Spec TC agreed to NOT change the set of UDDI Version 2 specifications. Whether UDDI Version 3 will be changed in an errata process, is not decided yet. Again, if there are compelling arguments for the additional support of UTF-16, the TC will revisit this issue.

Comments?

Best regards,
 Claus