Historic scripts as MAYBE?

[Mark Davis]

On Sun, Apr 27, 2008 at 11:37 PM, Patrik Fältström <patrik at frobbit.se>
wrote:

> On 28 apr 2008, at 04.04, Mark Davis wrote:
>
>  If historic scripts are to be excluded, the up-to-date list recommended
> > by
> > the consortium for U5.1 is at
> >
> > http://www.unicode.org/reports/tr31/#Specific_Character_Adjustments
> >
>
> As someone said already, in todays algorithm, we block things based on
> blocks, not scripts. If people want the selection on scripts back, fine, but
> that is something I want consensus on (as well).


I'm not arguing for that; I was just pointing out where to get a list that
was relevant to someone else's  thread.

>
>
>  (BTW, I'm strongly against restoring MAYBE, for a number of reasons
> > already
> > discussed. Haven't heard back from Patrik as to why, though, we couldn't
> > in
> > exceptional circumstances move characters from DISALLOWED. If that is
> > allowed, then it would be reasonable to exclude historic scripts, since
> > even
> > if there were an out-of-the-blue revival, they could be handled.)
> >
>
> I though I explained and that I had not heard back from you :-)


I seen no response from you to my message of:

fromMark Davis <mark.davis at icu-project.org>toPatrik Fältström <
patrik at frobbit.se>,
ccMartin Duerst <duerst at it.aoyama.ac.jp>,
idna-update at alvestrand.no,
Andrew Sullivan <ajs at commandprompt.com>,
dateTue, Apr 22, 2008 at 10:24 PMsubjectRe: Stability of valid IDN labels
mailed-bygmail.com


>
> Reason is that applications that block those codepoints will not let the
> codepoints be resolved. So starting using those codepoints will create
> problems.


That is circular, and doesn't address my question. Let me repeat my
questions again, since somehow it is not getting through in the email. Let
me call -- just for discussion! -- *IDNA 2008-U5.2* the version of IDNA that
uses Unicode 5.2 as a base. I'll try to change the wording to be clearer.

*I'll give a concrete case. Let's suppose that in IDNA 2008-U5.2**, the IETF
(through some mechanism) changes PVALID to include MODIFIER LETTER
RHOTICHOOK (and removed from DISALLOWED). Unicode 5.2 also adds a new
assigned
letter, U+xxxx IMPORTANT THAI CHARACTER, which is thus automatically added
to IDNA 2008-U5.2 as PVALID (it was UNASSIGNED in **IDNA 2008-U5.1)**.*

   - *Application A implements **IDNA 2008-U5.1**, and it is not updated
   for 10 years. (Patrik's case)
   *
   - *Application B updates to **IDNA 2008-U5.2**.*

*Application A will disallow some perfectly valid **IDNA 2008-U5.2** labels;
labels that Application B allows. That is, it will disallow a label X
containing RHOTIC HOOK and it will disallow a label Y containing IMPORTANT
THAI CHARACTER. Application B will allow both of the labels.

What advantage is it to functionally distinguish between these two
characters?
Why is it vital for Application A to do so, since it will disallow both X
and Y anyway?*

>
>
> This was exactly why we had MAYBE NOT category.


This is quite different from the MAYBE NOT category.

>
>
> And the reason why we have the backward compatibility category (so that
> the algorithm can be kept in sync with the Unicode data).
>
> That said (which we said in earlier discussions) every time RFCs are
> updated a decision has to be made regarding the change, and the reason why
> etc etc.


What do you mean by "the change"? I think part of the reason that we appear
to be talking past one another is that we're not using the same terminology
or perhaps model. It sounds like what you are saying here is that DISALLOWED
*can* be changed if another RFC is issued that obsoletes IDNA2008, adding
(for example) RHOTIC HOOK to the exception table as PVALID. Do you mean
that, or am I misinterpreting?


>
>   Patrik
>
>
>
>  Mark
> >
> > On Sun, Apr 27, 2008 at 6:19 PM, Paul Hoffman <phoffman at imc.org> wrote:
> >
> >  At 2:24 AM +0200 4/28/08, Frank Ellermann wrote:
> > >
> > >  In Unicode 5.1 Phaistos Disc, Carian, Lycian, and Lydian were added.
> > > >
> > > >
> > > Ah. Where? I don't see that on <
> > > http://www.unicode.org/versions/Unicode5.1.0/>.
> > >
> > > For IDNAbis the list could be extended with say Glagolitic, Deseret,
> > >
> > > > and Shavian.
> > > >
> > > >
> > > If we want to hand-pick them, yes. I proposed that we only use what
> > > The
> > > Unicode Consortium has decided.
> > >
> > > But that requires great care, excluding Osmanyan could
> > >
> > > > backfire if a future country in the former Somalia adopts it again.
> > > >
> > > >
> > > ...an even better reason not to hand-pick.
> > >
> > > _______________________________________________
> > > Idna-update mailing list
> > > Idna-update at alvestrand.no
> > > http://www.alvestrand.no/mailman/listinfo/idna-update
> > >
> > >
> >
> >
> > --
> > Mark
> > _______________________________________________
> > 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/20080428/af20646a/attachment.html