UDDI and WS-I Basic Profile - on the subject of encoding

Lately I've been using some time on UDDI and during my post on case-insensitivity on encoding declations on XML documents I came across WS-I Basic Profile that I haven't looked at for some time. In this post i touch on some the surprises on UDDI, WS-I BP and encoding. The most recent BP document (version 1 branch) is Basic Profile Version 1.2, Working Group Approval Draft (2007-10-24)

describes the relation to UDDI in 5. Service Publication and Discovery:

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages whose envelopes are encoded in either UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) That there should be such a discrepancy is hardly surprising given that UDDI V2 was designed and, in many cases, implemented before the Profile was developed. UDDI's designers are aware of UDDI V2's nonconformance and will take it into consideration in their future work.

i don't agree on their evaluation since the XML Specification demands that XML Processors should support both UTF-8 and UTF-16. More important it's still stuck on UDDI V2.0, which is sort of all right since the other standards are frozen as well. But there's a new version on it's way that can read in Basic Profile Version 2.0, Working Group Draft (2007-10-25). The difference between the version 1 and 2 branch is descibed in 1.3 Compatibility with Basic Profile 1.1 and 1.2:

The Basic Profile 2.0 is the first version of the WS-I Basic Profile that changes the version of SOAP in the profile scope from SOAP 1.1 to the W3C SOAP 1.2 Recommendation. As such, clients, servers and the artifacts that comprise a Basic Profile 1.0, 1.1 or 1.2 conformant application are inherently incompatible with an application that is conformant with the Basic Profile 2.0. However, in general, the Basic Profile WG members have tried to preserve in the Basic Profile 2.0 as much consistency with the guidance and constraints of the Basic Profile 1.0, 1.1 and 1.2 as possible. This has been in part facilitated by the fact that the WG tried to remain consistent in the guidance and constraints of the original Basic Profile with the decisions that were being made in the context of the W3C XML Protocols WG as they were concurrently working on the SOAP 1.2 specificatons. For the most part, issues that were resolved in the context of the development of the Basic Profile 1.0, 1.1 and 1.2 were not revisited.

It's still a WSDL 1.1 thing (not that it's a problem to me) and on UDDI it's the same section 5. Service Publication and Discovery with what looks like the identical content.

One simple conclusion is that if you are relying on UDDI V3.0, you've in principle denied yourself the WS-I Conformance badge (UDDI Conformance claim).

Encoding requirements in UDDI V3.0

One interesting question is whether UDDI V3.0 has changed to WS-I conformance on the mentioned issue. The answer is in section 4.2 XML Encoding Requirements:

All messages sent to and received from UDDI nodes MUST be encoded in either UTF-8 or UTF-16, and MUST specify the Hyper Text Transport Protocol (HTTP) Content-Type header with a charset parameter of "utf-8" or "utf-16" respectively and a content type of text/xml. Other encoding name variants, such as UTF8, UTF_8, etc. MAY NOT be used.

First there's no issue anymore and second It's funny to see both upper and lower case used in the same paragraph, and since the values for charset parameters are given in quotes it looks like it's normative? Nope - in the next paragraph:

All parts of the Content-type header are case insensitive and quotations are optional.

With a reference to Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies though I think RFC 3023 is another good place look XML Media Type. The lat little thing is consequent use af lower case for charset and upper case on the encoding declation in the XML declaration, in ex. 4.1.1 Support for SOAPAction.