Historic scripts as MAYBE?

[Debbie Garside]

I have to say that I agree with Mark.  I think he is very much on the right track.  I do not think DISALLOWED should be set in stone.  

 

We, in this forum, do not have sufficient knowledge of possible future use to do so. 

 

Best regards

 

Debbie Garside

 

 

  _____  

From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of Mark Davis
Sent: 28 April 2008 05:36
To: Paul Hoffman
Cc: idna-update at alvestrand.no
Subject: Re: Historic scripts as MAYBE?

 

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 CHARACTER.

*	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?

Mark

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.




-- 
Mark 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080428/77cabd5d/attachment.html