Historic scripts as MAYBE?

Mark Davis mark.davis at icu-project.org
Mon Apr 28 06:36:25 CEST 2008

Various people may want different things; that doesn't mean that all desires
can be simultaneously satisfied -- one has to balance the importance. And to
balance, one needs to have a clear statement as to the pros and cons.

There is a distinct cost to making DISALLOWED be permanent, once assigned.
While I would expect the number of future exceptional characters to be very
small, I posed the following question:

> For example, as an exception, suppose that U+02DE<http://unicode.org/cldr/utility/character.jsp?a=02DE>( ˞ ) MODIFIER LETTER
RHOTIC HOOK were to to be added in some future version to the exception
list, because it was found to be needed for a particular African language.
This would involve changing from DISALLOWED to ALLOWED. What would be the
practical problem that this causes?

Let's suppose that it was *your* language at stake, and you could not us som
vry ky lttr -- you wouldn't xactly lik it. So we have to weigh the
advantage, if any, of an unyielding filter on the client side against the
ability to make an exceptional, but perhaps necessary, change in the future.

You say "Patrik's statements about what a developer would want (a stable
list of what is prohibited so they can filter) seems logical to me." But
what is the case to be made for that? I'm not hearing any concrete examples.
Why is this so important that it be set in stone? I fully understand the
requirement of backwards compatibility for *valid* labels, but not for (only
some) *invalid* ones.

I'll give a concrete case. Let's suppose that IDNA 2008 is issued based on
Unicode 5.1, and that in the version corresponding to U5.2, PVALID were
updated to include MODIFIER LETTER RHOTIC HOOK (and it was removed from
DISALLOWED). U5.2 also adds a new assigned character, U+xxxx IMPORTANT THAI

   - Application A implements the u5.1 version, and never changes
   (Patrik's case).
   - Application B updates to the U5.2 version.

Application A will disallow some perfectly valid U5.2 labels; labels that
Application B allows. That is, it will disallow both RHOTIC HOOK and
IMPORTANT THAI CHARACTER. Application B will allow both of them. What
advantage is it to functionally distinguish between these two characters?
Why is it vital for Application B or A to do so?


On Sun, Apr 27, 2008 at 8:39 PM, Paul Hoffman <phoffman at imc.org> wrote:

> At 7:42 PM -0700 4/27/08, Mark Davis wrote:
> > True, but remember that there is no bright line with "archaic/historic".
> >
> I took inclusion in Chapter 14 of TUS to be a bright enough line. Maybe
> you're saying it isn't.
>  If you mean: "nobody uses it", then no script qualifies!
> >
> I do not mean that at all. I mean "another qualified standards body has
> defined it for us".
>  I have gotten no reply back from my message of 5 days ago ("Re: Stability
> > of valid IDN labels"). Without some concrete user scenerios making a
> > compelling case, all we have a bald statement about unnamed "application
> > creators". That is hardly the way to go about doing a specification.
> >
> We disagree. Patrik's statements about what a developer would want (a
> stable list of what is prohibited so they can filter) seems logical to me.
> You might code differently, of course. If we go down a path where we require
> that developers code in a certain fashion, that makes the spec much more
> fragile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080427/85bcbb5b/attachment.html

More information about the Idna-update mailing list