Skip to main content

Procedural issues with liaison on nextsteps, 19 June 2006

Document Type IAB Statement
Title Procedural issues with liaison on nextsteps, 19 June 2006
Published 2006-06-19
Metadata last updated 2023-08-09
State Active
Send notices to (None)

From: Leslie Daigle
Subject: Re: Procedural issues with liaison on nextsteps (was Re: Unicode Technical Committee Liaison Statement to IETF on
Date: June 19, 2006
To: Mark Davis


This is in response to your message dated May 6, 2006 with subject "Procedural issues with liaison on nextsteps".
Apologies for not getting back to you earlier.

I, and the IAB, are sorry to hear you are concerned with the state of the Unicode Technical Consortium's working
relationship with the IETF.

There are two basic reasons that the IAB's response answered both of your previous missives without providing the
point-by-point response you apparently were expecting:

1. As you know (from our previous communications), the document is an IAB statement, and therefore is scoped to
represent the opinion of the IAB as a body. As such, there may be occasions where its opinion varies from the
stated opinion of others -- we recognize this is one such instance.

2. The IETF (and IAB) do not use formal liaison statements as a replacement for the individual technical
contributions that are the core of our operational model. Many of the issues raised in your missives were
ones you have already brought up as an individual in discussions and hence did not require any additional

After reviewing your feedback and the feedback of the rest of the community we have rewritten and rearranged
some parts of the document with the intention of clarifying its purpose. This has been posted as

In this new version we have separated out the underlying issues in two sections Where section 3 deals with
issues specific to transitioning of IDNA between one version of Unicode and the next, Section 4 now describes
the framework for next steps and section 5 provides the specific recommendations for further work.

We have tried to further clarify that there are issues with normalization that are specific to DNS. In particular,
unlike for other text applications, for DNS operation it is not sufficient that once a string is normalized under
one version of Unicode it will still be normalized under all future versions.

Following from those DNS requirements, we have made it clearer that these are issues with *any* form of

From the IAB's perspective, this document is complete and the actual work will need to be done within the IETF
and other venues. We hope the UTC will continue to be a valuable partner in further completing this work.

Leslie Daigle,
for the IAB.


From: Mark Davis
Subject: Procedural issues with liaison on nextsteps (was Re: Unicode Technical Committee Liaison Statement to IETF on
Date: May 7, 2006
To: Patrik Faltstrom
Cc: Olaf Kolkman; Leslie Daigle;; John Klensin; Martin Duerst ;

There are two separate issues in my message; perhaps I should have separated them, and will do here. The first
is procedural: When an official liaison statement is filed, the originating organization would like to get a
point-by-point response on each of the issues raised, either saying that the comment is accepted and a change
will be made, or explaining why the comment is rejected. The orginating organization may be satisfied with the
explanation, or not conclude that the issue is important enough to pursue, or feel that the explanation is based
on a misunderstanding of the issue, or (worst case) conclude that there is a difference in viewpoints which cannot
be resolved.

This is how our liaisons work with the W3C and ISO, which whom we have very good working relationships, and is
fairly typical of interactions not only between organizations, but between groups within organizations.

Nextsteps is a document with a good deal of value; however, the consortium is very concerned about problems in
certain sections. It is unclear why there is such a need to rush to publish a document that is so concerned with
Unicode without the involvement of the Unicode Consortium, which is not only the organization that orginated the
standard, but also represents the broadest spectrum of companies and engineers with many, many years of experience
in software internationalization on a wide variety of platforms. (While the IETF (or some members thereof) may not
be happy with the results of Corrigendum
#5 (,, the consortium delayed the release of that corrigendum for
well over a year, so as to allow for feedback -- primarily from the IETF. This was despite the strong desire by
many consortium members to have the fix available earlier, in Unicode 4.0.)

There are some tricky technical concepts involved, and for that reason I also suggested that a face-to-face
discussion would be productive.


Patrik Fältström wrote:
> On 6 maj 2006, at 00.20, Mark Davis wrote:
>> Section 4.3 claims that various RFCs can't be updated to later 
>> versions of Unicode. This is not the case.
> Mark, first of all, that is not what the section says. It points at 
> the incompatibles that do exist between the normalization forms in the 
> different versions of Unicode, and urge the IETF to make a decision on 
> how to move forward.
> The fact is that there are incompatibilities that do imply that IF one 
> have normalized a string in one version of Unicode (A->B), and then 
> with a later version of Unicode try to fetch the same string (A) from 
> DNS, they will not "find" it as it might not be normalized to B 
> anymore, but to B'.
> It doesn't matter how much A->B was "a bug". Even I that do not know 
> Chinese can see that the original mapping was wrong.
> The proposed solution from the Unicode Consortium is that for a 
> specific solution one should decide whether the exception table is to 
> be used or not. What some participants in the IETF have seen though is 
> that implementations of charsets in applications include "some"
> normalization already in the process when mapping from the local 
> charset to Unicode. Because of this, we see in some cases problems 
> having different normalization mappings for different applications.
> Another argument for not having different normalization mappings have 
> to do when for example one send a domain name as part of a flowing 
> text in an email. Should that part of the text use the normalization 
> with or without the exceptions?
> Section 4.3 simply say a decision have to be made whether this 
> incompatibility should be accepted between versions, or if one should 
> stay at Unicode 3.2 or whether a special profile of Unicode 4.0 should 
> be used.
> This IS a serious problem for the IETF, and it can not be ignored. The 
> contrary, it has to be discussed in detail in the IETF as part of the 
> development of a possible upgrade of the IDNA spec.
>       Regards, Patrik