Table Derivation

JFC Morfin jefsey at jefsey.com
Sat Dec 22 17:08:40 CET 2007


At 03:18 22/12/2007, Kenneth Whistler wrote:
>jfc said:
> > I doubt the IETF has the available
> > expertise to check this document, so any RFC proposition including
> > this propositions will not survive the IETF LC razor (cf. RFC 3935).
>
>I respectfully disagree.

Dear Kenneth,
I fully hear your points. And I think we agree on the technical side. 
The disagreement is on the advantage, competence, and responsibility 
of the IETF along the lines of the RFC 3935 on the matter I think we 
all agree with (it was authored by the owner of this mailing list, 
and BoD Member of the source and user entities). IMHO, and I think in 
most of the zone managers minds, the proposed IDNA relies too much 
on, and is too much architecturally exclusive of, Unicode inputs, 
expertise, commitments (where the IETF has no say and while it only 
wants no DNS change), for not to be at least of Unicode shared responsiblity.

The IETF is about making the Internet work better for all (RFC 3935). 
IDNA is about making the Internet being used better by some. The IETF 
is to influence those who design, use and manage the Internet. 
Unicode is to commit on referential tables.

The role of the IETF is to make the Internet work better, including 
for the IDNA to permit users to use IDNA better. This is the same as 
when it makes the Internet work better _also_ (not exclusively) for 
the Web defined by the W3C, so the W3C can influence those who 
design, use and manage Web applications so they work better for the 
end-users (a term IETF ignores).

If you carefully consider this and what you expose, you will see that 
this is exactly what you explain. You cannot commit to users that 
Unicode will do for the best IDNA (for this, it must be free to do 
it, from IETF and from other constraints). IETF cannot commit either 
to the entire Internet community that Unicode will do for the best of 
the whole Internet, (because it cannot interfere within Unicode).

Clearly differentiating the involved layers might address current 
difficulties (I know the protocol stack is the source of difficult 
layer violations) . Differentiating what belongs to the IETF (DNS, 
binary support of scripts), and to Unicode (codes and languages) 
would lead to a more robust approach. We all agree that what Patrick 
says is necessary, but what if it is not practically possible on a 
few points? I feel far more confortable if this is dealt with by 
Unicode language support professionnals, than by computer engineers 
also involved in totally different areas.

When you say that IETF has the competences and that they are mostly 
present on this list, this raises the problem. What will then be the 
added value of the IETF LC? Why is this list private and not even an 
IETF WG? We here are in an unformal joint Unicode/IETF (and MLTF as 
far as I am concerned) effort, gathering the IETF more familiar 
people with the Unicode domain, and the Unicode more familiar people 
with the IETF domain. On the IETF issues they are backed by the IETF 
LC. On the Unicode issues they benefit from all the Unicode 
expertise. On multilingual netcentricity I am backed by a few MLTF 
experts. Let make all this something positive, rather than disturbing.

Now, we could certainly discuss the missing element: who is to 
specify and support the resultingly needed application process, while 
the WG-IDNA experience makes the IETF hesitate to create a new WG, 
and I understand this might not be the Unicode charter? Questions: 
(1) would this not be an indication that the approach does not fit 
the network model (2) or that the current internationalized model 
does not fit the multilingual need (3) what does that tell in order 
to simplify and stabilise the deliverable?
jfc



>First of all, for nearly all of the users of the IDNA
>specification, they will simply be using a predefined
>table in the context of the IDNAbis string preparation
>step (defined in the other document). They aren't going
>to need to be checking the detailed derivation of the
>table itself in order to implement correct and conformant
>checking of IDNs according to the future RFC.
>
>What Patrik's document is about, and what Mark's and my
>contribution is about, is really the instructions for
>those who will be checking the derivation of the table
>itself, before its publication.
>
>And even if we turn to the checking of the table itself --
>the expertise required is no more than parsing a few
>values out of simply formattted, publicly available and stable
>plain text data files, and then doing a few set addition and set
>subtraction operations on the results.
>
>As Mark and I have suggested for the table derivation, it
>is not even necessary to have available a conformant
>implementation of Unicode normalization or Unicode casefolding
>to hand in order to derive the desired result: keeping characters
>which are unstable under normalization or casefolding out of the
>set used for IDNs. Those values also can simply be parsed
>out of simply-formatted plain text files without having
>to independently implement Unicode normalization or casefolding
>for that step.
>
>And as I just noted in the message re IDN_Always and IDN_Never,
>I have posted the results of table derivations for all
>versions of Unicode from Version 3.2 through Unicode 5.0
>(and the yet-to-be-released Unicode 5.1). So anyone who wants
>to independently check their parsing and set subtraction has
>an easy way to compare results for any Unicode version. Such files
>could, of course, be made permanently available once we
>agree on all the details of what we want to be in or out of the
>NEVER and ALWAYS classes.
>
>This seems technically quite straightforward to me, and is
>certainly well within the expertise of any number of IETF
>participants, including those discussing this issue here.
>
>Regards,
>
>--Ken
>
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update



More information about the Idna-update mailing list