Timetable for action: May 31 is suggested

John Clews Scripts2 at sesame.demon.co.uk
Tue May 27 07:49:08 CEST 2003

1. Specific tag requests

In message <p05200a10baf82d4fcea3@[]> Michael Everson writes:
> At 21:18 +0000 2003-05-26, John Clews wrote:
> >My request - which I would happily simplify to Peter's simplificatio
> >to two possibilities - is to see this resolved.
> >
> >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.

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.

> >People have specific _technical_needs_ which RFC 3066 and the
> >associated Language Tag Review process is intended to be able to
> >provide.
> It is not clear that the specific suggestions proposed are the best 
> way to solve the technical needs. Indeed, there seem to be a great 
> many opinions about this matter.

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?

It's main raison d'etre at that time seemed to be the possibility of
its being used with language codes, in an extension of what was then
RFC 1766, which became RFC 3066.

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

What are the codes in ISO 15924 to be used for, if not in situations
like this?

2. Alternative approach

The only arguable possibility - which somebody mentioned earlier, was
instead of having a structure like


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.


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


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


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.

> Applying for a language tag does not guarantee its registration 
> within two weeks. If there is doubt, or room for discussion, then the 
> time frame is extended. We have done this before.
> I have also rejected tags. For instance, I rejected es-americas 
> because it wasn't *a* language. Or no one was able to convince me 
> about it.

I'm glad you did that. For the very valid reason you described above.
Though I know others had other views too, and there seemed to less
people in favour of


then there were in favour of


> >They're not contributing to this list just to add to the philosophy
> >of languages and other attributes that can get associated with 
> >languages.
> Right. Some of this began with Peter Edberg's discussion paper, which 
> was a draft...

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.

> 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 :-)

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.

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

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

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

> 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 :-)

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

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.

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.

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

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

And feelings, hunches, and worries about "dodginess" are not

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.

This might be the solution that overcomes Michael's worries and
hunches, though I don't know the ins and outs or pros ad cons of such
a solution, compared to combining them in the model of


which is defined in RFC 3066.

As I say, I only saw a passing reference to that approach, as if it
had been discussed before somewhere. I don't recall seeing it
previously - it may have been on a separate list - and it may or may
not have been viewed as a runner.

Perhaps "the rest of us" might concentrate on that, and leave Michael
to either allocate new tags as requested, or prepare an explanation
as to why he will not allocate them, on the specific tags he was
requested, in the remaining week that he idicates he has available
for this and other taks before he goes to Baltimore.

It occurs to me that only this week falls within the 2 weeks
mentioned in the RFC (or at least in the discussion) and that
mid-June would fall outside of that period, for those specific tasks
on these specific language tag requests.

So, actions please, all round!

Best regards

John Clews

John Clews,
Keytempo Limited (Information Management),
8 Avenue Rd, Harrogate, HG2 7PG
Tel:    +44 1423 888 432
mobile: +44 7766 711 395
Email:  Scripts2 at sesame.demon.co.uk
Web:    http://www.keytempo.com

Committee Member of ISO/IEC/JTC1/SC22/WG20: Internationalization;
Committee Member of ISO/TC37/SC2/WG1: Language Codes

More information about the Ietf-languages mailing list