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

Mark Davis mark.davis at icu-project.org
Thu Jun 14 00:02:25 CEST 2007


Let me rephrase my first paragraph, since it's likely to be confusing.

I differ from Ken in this respect. I think having the method used to derive
the property be described in the document is fine.
[That is, I don't think that the current description nor the result is fine,
but having a very explicit, justified description in this document is good,
since it lets us judge whether the methodology is valid or not.]

On 6/13/07, Mark Davis <mark.davis at icu-project.org> wrote:
>
> 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




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


More information about the Idna-update mailing list