Last call for ISO 15924-based updates

Phillips, Addison addison at amazon.com
Tue Mar 17 05:33:12 CET 2009


I agree with Mark’s position.

I note, however, that at Doug’s behest, the reviewer extended the period for this subtag by two weeks on 13 March. We must therefore wait until 27 March, at which point anyone can petition the reviewer for a decision on the original registration. If there is consensus to include a comment at that time, the reviewer should determine that this is the case. Otherwise, I hope that he will approve the original record for inclusion, noting that comments may be registered in the future. In my opinion, this is what should have happened in the first place.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Mark Davis
Sent: Monday, March 16, 2009 8:59 PM
To: Doug Ewell
Cc: ietf-languages at iana.org
Subject: Re: Last call for ISO 15924-based updates

In terms of action, it is simple. You have to add the code, but if there is no consensus to add a comment, then don't add a comment. Additional comments can always be added later on; there is no reason to delay for them.

Mark

On Mon, Mar 16, 2009 at 20:15, Doug Ewell <doug at ewellic.org<mailto:doug at ewellic.org>> wrote:
Mark Davis wrote:
Now, in my opinion, 15924 should provide variants for major orthographic differences; for one thing, it would make usage in major clients like BCP47 work much better in those cases: currently major orthographic differences count as less than minor regional differences in BCP47 lookup. And for another, 15924 already has variants like Latf -- it would not be a great stretch to add major othographic variants.

I'm sure all of us can think of something missing in one of the commonly discussed standards that we wish were there, or something that is present or planned that we wish were not.

Had Addison and I realized that the script JAC wouldn't allow major orthographic variants as script variants, I believe that we would have proposed a way to register subtags in the script position when we did our first draft of 4646, to get around the JAC position, and have BCP47 function more properly. We thought that the JAC would be more practical. But that's water under the bridge.

Actually I don't think using variants for IPA et al. is such a bad idea. I think we had a good idea about the subtags appearing from left to right in decreasing order of "importance," but I don't think a roomful of people, or maybe even a closetful, will agree on which subtags are more "important," and I'm afraid we won't find many applications that actually take this into account.

While I disagree with that position of the JAC regarding orthographies, that doesn't mean that there isn't a principled difference between the cases of IPA and Zinh where they can reasonably draw a line.

I'm hoping we can set aside philosophical differences about ISO 15924 and reach an agreement on this apparently crucial "comment or no comment" decision that is holding 'Zinh' out of the Registry.  I mean, I'm sure nobody is suffering because 'Zinh' is not yet in the Registry, but it would be nice to finish pending business.


--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090316/744502e4/attachment-0001.htm 


More information about the Ietf-languages mailing list