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