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

[Mark Davis]

The first thing wrong with the description is that you have to provide an
explanation of what the proposed operational difference is between Maybe Yes
and Maybe No. If you don't provide a clear explanation of why you need these
two different catagories when the normal English meaning is identical, it is
impossible to really assess what is going on. The relation between property
values and operation has to be crystal-clear.

Wording like

   "For each rule, it is specified whether it is a rule that increase or
   decrease the value of the property (regarding likelihood to be
   included in a U-label),"

I find extremely fishy. It makes it sound like IDNA will only give you a
*probability* that an IDN is valid, instead of saying that a particular IDN
is valid or not.


My take on what we meant by Always, Maybe, and Never are:

Always: Is accepted as part of an IDN in IDNAbis, and will be accepted in
all future versions (unless the IETF decides otherwise).

Never: Is not accepted as part of an IDN in IDNAbis, and will not be
accepted in any future versions (unless the IETF decides otherwise).

Maybe: Is not currently accepted as part of an IDN in IDNAbis, but may move
to Always or Never in a future version (on decision of the IETF or some
registrar or some other undisclosed mechanism).

It is not at all clear how you think that Maybe No and Maybe Yes differ from
Maybe, nor what is motivating this move. What is the problem you are trying
to solve, and why is this the solution??

===

Now, as far as the calculation goes. One presumes, although it is not
stated, that the rules are evaluated in order, based on the suffix "P
rocessing terminates" in the first two clauses. Unfortunately, that phrase
is missing from the remainder of the clauses, which makes them formally in
conflict.

What I'm guessing you are trying to do based on what you have written is
have something equivalent to the following, which incorporates both the
rules and the calculation. I'm using sets rather than the corresponding
property notation.

Create the following sets based on the properties of each code point cp.

Grandfathered = set of all cp such that

   - cp is in [-A-Z0-9]


Functional = set of all cp such that

   - generalCategory(cp) is {Ll, Lu, Lo, Lm, Mn, Mc, Nd}, AND
   - NFKC(cp) == cp, AND
   - casefold(cp) == cp, AND
   - !defaultIgnorableCodePoint(cp)


Archaic = set of all cp such that

   - script(cp) in {Xsux, Ugar, Xpeo, Goth, Ital, Cprt, Linb, Phnx, Khar,
   Phag, Glag, Shaw, Dsrt}, OR
   - block(cp) in {Combining_Diacritical_Marks _for_Symbols,
   Musical_Symbols, Ancient_Greek_Musical_Notation}


Favored = set of all cp such that

   - script(cp) in {Latn, Grek, Cyrl},


Then derive the following sets:

   - Always = Grandfathered | (Favored & Functional)
   - Maybe_Yes = !Favored & Functional
   - Maybe_Not = Archaic | (!Favored & !Functional)
   - Never = everything else

where | is UNION, & is INTERSECTION, ! is COMPLEMENT

The property values align with the corresponding sets.

The names for these sets are arbitrary and short. Archaic would be better
phrased as "not in modern, customary use", but that's too long.

Mark

On 6/13/07, Patrik Fältström <patrik at frobbit.se> wrote:
>
> On 13 jun 2007, at 03.50, Mark Davis wrote:
>
> > But 3. "Calculation of the derived property". that section is very
> > hard to
> > make out. Moreover, it is impossible to assess what it is supposed
> > to be
> > doing until the difference between Maybe Yes and Maybe No is
> > completely
> > spelled out operationally, and the goal is made clear.
>
> 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.
>
> I choose one that I feel I have most "votes" for. But I know I also
> have people that dislike it.
>
> Mark, if I ask you differently: Do you see anything WRONG in my  way
> of describing the calculation? As a different question than whether
> you feel it is hard to follow or "not the most optimal way of
> describing what we want to do".
>
> I must start there, to see what I can do about it in the document.
>
>      Patrik
>
>


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