New version, draft-faltstrom-idnabis-tables-02.txt, available

Mark Davis mark.davis at icu-project.org
Wed Jun 13 23:59:46 CEST 2007


I differ from Ken in this respect. I think having the method used to derive
the property in the document is fine.

In fact, I think that one of the major failings of the document is precisely
the reverse. For each rule that restricts characters that were allowed in
IDNA2003, it should have a compelling justification, *with examples* of why
such a restriction must be made. If a compelling case with examples cannot
be provided, it casts clear doubt on the rationale for having the rule.

Mark

On 6/13/07, Harald Tveit Alvestrand <harald at alvestrand.no> wrote:
>
>
>
> --On 13. juni 2007 13:29 -0700 Kenneth Whistler <kenw at sybase.com> wrote:
>
> > Patrik Fältström wrote:
> >
> >> I have got privately many many comments on all algorithmic
> >> specifications posted (including mine, and yours Mark). I have also
> >> got many suggested algorithmic specifications privately. I think I
> >> have around 10 different ways of describing what we want to do --
> >> calculate the value of the derived property value.
> >
> > Well, I think this is one of the key issues with the document.
> >
> > This *should* be a data specification, not an algorithmic specification.
> >
> > It defines a table with data values in it.
> >
> > For clarity, it should do so by specifying a series of criteria
> > for inclusion or exclusion in that table, and values specified
> > in that table. And then it should describe the data specification
> > in terms of set logic.
> >
> > Mark's contribution shows how much cleaner, clearer, and *correct*
> > such a specification is.
> >
> > Trying to turn this into an algorithmic specification is -- in
> > my opinion, of course -- just wrong.
>
> Ken,
>
> I can't tell the difference between an algorithm specified in terms of
> selection criteria and an algorithm specified in terms of set operations.
>
> Either they achieve the same result, or they don't.
>
> > But...
> >
> > The details of the algorithm to generate the table
> > itself are *completely* uninteresting. There is no
> > reason whatsoever why the data
> > specification for the table needs to be specifying algorithms
> > for the generation of the table, because nobody outside this
> > room, so to speak, needs to *re*implement such an algorithm
> > in code somewhere. The data is simply there in a table, for
> > use by *other* algorithms that we *do* need to specify --
> > namely the ones that determine whether a given Unicode
> > string is or is not a valid U-label and does or does not
> > match a particular DNS entry.
>
> That's a basic difference in approach that the two of us have disagreed on
> before.
> If you specify the algorithm, and allow discussion of the algorithm, new
> data can be evaluated according to the algorithm, or it can be shown that
> the algorithm is incomplete, which may lead to a reevaluation of data
> generated erroneously earlier (which is a problem for stability, of
> course.
> You don't get something for nothing.)
>
> The tables, unsupported by the algorithm that generated them, have no way
> in which people can distinguish a systematic application of rational rules
> from "we just felt like picking this value" - an accusation that the UTC
> is
> far more familiar with than it wants to be, I think.
>
>                           Harald
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20070613/247f7e8e/attachment.html


More information about the Idna-update mailing list