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

[Arle Lommel <arle@lisa.org>]

Whatever reasons may dictate for or against adoption of UTF-16 as a
possibility, the first reason Klaus gives should be sufficient to nix the
idea of including it in version 2. Lack of UTF-16 compatibility is not an
error (at least not in the sense of an inadvertent mistake or oversight), as
Klaus' other points make clear, so issuing an erratum for this point would
be a mistake and would undermine implementers' confidence in having a stable
standard on which to base their work.

> 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.

Although it was agreed in the first phone meeting that version 3 would serve
as the basis for all further work, if it were it agreed that version 2
needed "fixing" for purposes of UTF-16 support, and that an erratum is not
the proper way of addressing the issue, would it be possible to issue a
version 2.1 specifically for this purpose, and which would be identical to
version 2, except for support for UTF-16?

I don't know that this is a good idea in reality (I don't know what other
issues and/or problems might arise in this situation), except that it might
allow those who could easily add UTF-16 support to do so (looking forward to
any future versions that require it), while still allowing them to stay as
they are, if they choose. Either way they could point to an established spec
as the basis for their decision.

I merely throw this out as one way to handle this issue, although it seems
that consensus is moving in the direction of saying that UDDI (at least in
older versions) doesn't need to be UTF-16 compatible.

Best regards,

Arle Lommel
LISA