Timetable for action: May 31 is suggested

Tex Texin tex at i18nguy.com
Tue May 27 12:40:29 CEST 2003


Sorry to say this, but as I read this I thought you made out a pretty good
case for delay rather than action.

a) It may be to proponents that every consideration (principles, alternatives)
is a delaying tactic, but it's not fair to the process to presume that, and
not all voices can be heard within the span of 24 or 48 hrs.

b) By describing an alternative and especially, the deprecations that would
occur, John outlined a pretty good reason for going slow. Creating and
deprecating codes would be very expensive to the software industry, and make a
right mess for years. Having lived so may years without scripts in language
codes, another year wouldn't kill us, if it meant getting a permanent and
well-defined solution.

c) actually es-americas wasn't formally rejected as much as the discussion was
allowed to die out (after much more than 2 weeks if I recall correctly) and
its proponents gave up.

d) To my mind, the fact that es-americas was not accepted is indicative of why
the current approach is faulty and a new framework should be adopted.
Michael made clear that the registry is about providing tags for languages,
and only by determining that a language exists and needs a tag according to
LINGUISTIC standards, would a tag be granted. The software industry has needs
that do not align with linguistic standards, es-americas being one of them.
Therefore the software industry should ideally have a separate tag registry
(and/or production rules) that is aligned with software requirements.

e) wedging scripts into languages is kind of a hack. Having it will help some
applications and likely be confusing for others.

f) However, practically, getting agreement to produce a new framework is
difficult, and solutions as are being proposed will solve some problems, even
if it makes the existing framework a bit more rickety. I am not sure if it is
the least of all evils, but the debate certainly feels like an American
presidential race to me. ;-) (i.e. no good choices.)

g) To my mind, the best solution would be to identify the principles that
would work for the software industry and create a new framework. Given that
that isn't going to happen, this discussion could take a few more weeks
without incurring major harm to the industry and the proponents could be a bit
more patient. At the same time, there perhaps shouldn't be delay for delays
sake, and if there are legitimate objections to consider, they need to be
articulated. If it will take time to formulate those objections, we perhaps
need an estimate of how long it would take. So for example, and not to put
words in his mouth, if Michael or others need time to consider the proposal
and the 2 week schedule is not sufficient, it would not be unreasonable to say
this issue will take n weeks, to give time to all parties to respond.
At least then, the clamoring for appeal etc. might die down and we could just
focus on the proposal, knowing at the end of the period a decision would


John Clews wrote:
> 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
>         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
> 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.
> > 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
>         lang=es-Americas
> then there were in favour of
>         lang=yi-Latn
> > >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
> sufficient.
> 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
>         lang=lan-Scrip
> 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
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages

Tex Texin   cell: +1 781 789 1898   mailto:Tex at XenCraft.com
Xen Master                          http://www.i18nGuy.com
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World

More information about the Ietf-languages mailing list