Minority WG Opinion on XML C14N and Unicode C14N

I have an action item to explain the minority opinion for XML C14N's not
including Unicode I18N.

Unicode C14N and XML C14N are logically indepedent processes.  Making
XML C14N include Unicode C14N is non-modular and non-orthogonal.  Not
only are they are logically indepedent but they are in practice
performed at completely different times: Unicode C14N is performed early
(when documents are created), or at least is supposed to be according to
the W3C Character Model; XML C14N is performed at a much later stage
(typically on the fly).

XML C14N is supposed to be useful for conformance testing as well as
digital signatures.  Requiring vendors to create a complex and subtle
(and thus potentially buggy) piece of code just to test conformance is
both unnecessary and inappropriate.  I suspect in practice people using
XML C14N for conformance testing will simply not implement the Unicode
C14N part.

Relative to the rest of XML C14N, I believe Unicode C14N is relatively
complex and resource intensive.  It will make a significant difference
to either code size or speed (you can probably implement slowly in a
little code, or fast in a lot of code).  In the context of its use for
digital signatures, XML C14N needs to be performed in scenarios where
processing resources are strictly limited. Requiring Unicode C14N in
such scenaries is problematic, especially since it will in most cases be
unnecessary because of the early-normalization policy of the W3C
character model.

I feel this decision has a significant chance of creating a split in the
market.  I believe many applications for which Unicode C14N is
unncessary or inappropriate will simply not implement it, whatever the
spec says.  If the decision was reversed, I believe no such danger
exists.  I would also point out that a version of XML C14N (my original
C14N spec) that does not require Unicode C14N has been very widely
implemented and deployed for a long time.  Making a substantial change
like this at the last stage in the process is a mistake.

James

Received on Wednesday, 12 January 2000 10:50:33 UTC