Timetable for action: May 31 is suggested

Michael Everson everson at evertype.com
Wed May 28 02:29:35 CEST 2003

At 06:49 +0000 2003-05-27, John Clews wrote:

>  > >It's a request for action - not rhetoric.
>>  The *action* we are undertaking is discussion.
>But your job as Language Tag Reviewer is to decide whether to add
>specific tags.

Well gosh, John, I can't decide about these because there aren't 
clear guidelines about them or the implications of them. Do I have to 
add yi-Hebr now? Somebody says yes. Do people want to parse the tags? 
They do. Can country elements interact with the script tags? 
Evidently. What format should the parsing have? I don't know, and it 
is NOT my job to decide arbitrarily. Or is it?

>If the actions of the Language Tag Reviewer are seen as unsuitable,
>a process exists to appeal. The use of that is now looking 
>increasingly likely.

I *am* doing my job, as I understand it, John.

>If it's such a new thing, why have you yourself spent many man-months
>in developing ISO 15924: Codes for representation of names of
>scripts, and trying to persuade ISO/TC37/SC2, and then persuading
>ISO/TC46/SC2 to take it on as a new Work Item for an ISO standard?

You're being silly. Those would work perfectly in a script= tag, in 
library database fields, and so on.

>Your more recet rejection of the combination of script codes with
>language codes seems not only to call into question your role as
>Language Tag Reviewer,

I take umbrage at this.

>having already registered one of this sort (yi-Latn), but rejecting 
>others on principle, but it also calls into question the value of 
>ISO 15924.

No it doesn't. The yi-Latn "precdent" seems to have raised all sorts 
of new questions. Is there a default script for languages? Will 
yi-Hebr have to be added now, as one person suggested? What about 
yi-US-Latn vs yi-Latn-US -- which should it be? -- isn't one 
structure implied by de-DE-1909? Is that the structure we want for 
zh-Hant and zh-Hans?

>2. Alternative approach
>The only arguable possibility - which somebody mentioned earlier, was
>instead of having a structure like
>         lang=lan-Scrip
>where lan represents language code; Scrip represents script code,
>would be to have something else like two separate entities, each
>specified in a separate RFC, one of which is RFC 3066.
>         lang=lan
>         script=Scrip

Yes, I had suggested that a long time ago. Apparently this will fail 
because current implementations want to conflate script within 
language tags.

>If a separate RFC were developed for the last of these, in addition,
>it would have to be accepted that for historical reasons there were
>one or two tags which had been allocated before, such as
>         lang=yi-Latn
>and - if you register what has been requested this week, again
>it would have to be accepted that for historical reasons there were
>one or two tags which had been allocated before, such as
>         lang=az-Cyrl
>         lang=az-Latn
>         etc.
>Suitable deprecation notices about lang=az-Cyrl and lang=az-Latn
>might be added to any revised/superseding RFC(s) in the future, if
>any problem did arise.

The interaction with country codes has not been addressed, has it? 
THE PROBLEM STILL EXISTS. As tag reviewer, I think it best that we 
decide what we want to do *before* certain tags are added.

What do we do with Chinese? We have tags for a number of Chinese 
languages. None of these have script tags attached. What shall we do 
with the syntax of these regarding script tags?

>For the good of my health, would you - or he - recirculate a copy of 
>this as an email, or point to a URL, which would see if this adds 
>aything to the debate or not? I don't recall it, and the continued 
>allusion to it as "Peter Edberg's discussion paper" or similar, 
>without any detail of what was in it just doesn't help people decide 
>whether this is a useful thing to look at, or what some might see as 
>just a delaying tactic.

Peter has said he will forward it. Peter, please do this right away.

>  > For the record, I agree pretty much with Ken. This stuff is a cheap
>  > hack, and it's idiotic that we have to add stuff like this into
>>  <lang=> tags when it really ought to be in <script=> tags.
>Well, I'm glad you've decided not to go in for rhetoric :-)

Well I feel rather put-upon and frustrated myself.

>In passing, I saw many other parts of Ken's text which to me implied
>that you should just get on and register the language tags.

I would rather have the issues regarding interaction between 
language, script, and country codes in these language tags be SETTLED 
before I do that.

James Seng: What is best? zh-Hans-SG? zh-SG-Hans? zh-guoyu-Hant-SG? 
Etc. etc. etc. I want this question answered before I approve the 
kinds of tags proposed. I think I am RIGHT to insist on this.

>  > We are doing more than just deciding whether to satisfy Mark's
>>  immediate requirements. We are making decisions which can help Yours
>>  Truly actually do this stuff more gracefully in future.
>Well, wouldn't a revision of RFC 3066 which included the possibility
>of combining language tags and script tags, allow everybody to do
>this stuff more gracefully in future?

I myself don't see a need to wait for a complete revision, which will 
take a long time. We could set policy on the PROBLEM raised without 
waiting for a formal revision. But *I* don't want to set such a 
policy by fiat. Hence my insistance on "delay".

>It seems to me that there is a confusion between
>(a) dealing with processig requested tags now, and
>(b) revision of RFC 3066,
>and that (b) is just being used as a delaying tactic against (a).

I think it is offensive to suggest that I am delaying for the sake of delay.

>  > We *DO* need to have a policy on these matters. We *DO* need to have
>>  a consensus decision on syntax. Is it to be zh-Hans-SG or zh-SG-Hans?
>>  Do you know? Do you care? Does it matter?
>Those weren't requested. This merely appears to be another delaying tactic.

Mark's proposals have implications regarding other tag structures, 
and that is why I am not accepting them at present. Is this in any 
way unclear?

>  > And to Addison: the palpable thing you're looking for is that these
>>  proposals are crap, they are hacks for a specific locale tagging
>>  system which itself ought to have been rethought and rewritten, and
>>  now it's dumped on this poor RFC.
>Again, I'm glad you've decided not to go in for rhetoric :-)

In a perfect world, script tags and language tags would not be 
conflated in language tags, in my view. We may do so -- after we have 
dealt with the syntax issues.

>  > And to John Clews: Your Reviewer has about a week in Dublin before he
>>  has to got to Baltimore for the greater glory of encoding Cuneiform,
>>  and then when he gets back he goes to Oxford for the greater glory of
>>  encoding medieval weirdo Latin letters,
>We're not concerned with what the rest of us do: just with what you
>do or don't do - it's you that has taken on the task of
>Language Tag Reviewer.

I am not a rubber-stamper. I am not a number. I am a free man! :-)

>Well, you have a week before you go to Baltimore: good, that gives
>you time to do some action - which you have delayed doing before.
>It seems to me that you are required by the RFC and your role as
>Language Tag Reviewer, to either allocate tags, or give a
>justification as to why not.

I think I have done so here at least.

>Getting whatever actions done now would be far better, than
>waiting for further delays cuased by travel to Baltimore and then
>Oxford, and then people start to go on summer holidays, and so on:
>the possibilities for delay are endless.

If you posit that I am enjoying this process and have some interest 
in dragging this argument out for its own sake you are definitely 

>  > and he is sure that nothing
>>  is going to happen between now and the middle of June,
>so why is the middle of June any better than now for this?

Because the structural questions have not been dealt with and resolved.

>  > which gives
>>  Mark and the rest of you PLENTY of time to talk to Peter Edberg and
>>  Ken and Harald and come up with a MATURE position and policy
>>  document, so that Your Reviewer doesn't have to be BLAMED when he
>  > balks at encoding things that he thinks are dodgy.
>Nobody is going to blame you for allocating these codes.
>Several people will blame you for not allocating these codes.

I've a thick skin. I think I am doing my job.

>It strikes me that the only alternative - and Michael may be right
>when he talks about a task for "the rest of you" - would be to
>determine whether a separate mechanism, such as
>(a)     lang=lan
>(b)     script=Scrip
>(where lan represents language code; Scrip represents script code)
>might be possible, with the first already defined in RFC 3066, and
>the second to be defined in a completely separate RFC, might be a
>better solution anyway.

But this will not work with, apparently, the software that Mark is 
using now; he needs to use language tags only to do what he needs to 
Michael Everson * * Everson Typography *  * http://www.evertype.com

More information about the Ietf-languages mailing list