Timetable for action: May 31 is suggested

Tex Texin tex at i18nguy.com
Tue May 27 22:56:56 CEST 2003


1) Yes, you have done everything that has been asked of you and I can
understand why you don't see much changing with a few more weeks.
However, I thought if the 2 weeks was insufficient for the reviewer, if the
reviewer would declare how long was needed, that would help the process and
give some assurance to everyone that closure would be reached.

2) Ken said it "amounts to just one more (ad hoc) extension of an already ad
hoc system".
Isn't that a hack of an already hacked system?

As for the rest of your 2 and 3, I don't disagree. I thought I had said that
the proposal was making do as best we could.

4) Well, I understand your frustration and the hyperbole that resulted, but
I'll clarify anyway that I was looking for an end date to consideration, and I
had weeks in mind rather than years or decades. I was hoping to have the
reviewer declare what it would take to get to a decision. 

Yes, the need for script information is important. The industry will hardly
fall apart in the next few weeks without this being decided. And I hardly
think that this will suddenly make Microsoft fall in line nor prevent other
proprietary solutions for particular language issues to be developed.


Mark Davis wrote:
> 1. This discussion has been going not for 24 or 48 hours, but for
> about 1,400 hours. Based on that earlier discussion, I posted specific
> proposals for each of the 9 tags on Wed Apr 30 15:24:20 CEST 2003:
> http://eikenes.alvestrand.no/pipermail/ietf-languages/2003-April/000933.html
> Despite the fact that it is well known that these written languages
> exist, and are distinct, the reviewer wanted specific references.
> (Note that http://www.ietf.org/rfc/rfc3066.txt does not explicitly
> require that specific references be supplied.) I resubmitted them May
> 22, in:
> http://eikenes.alvestrand.no/pipermail/ietf-languages/2003-May/000992.html
> (and following)
> The first time, I did not hold the reviewer to the two week limit as
> he is required by the RFC, hoping more discussion would be productive.
> If I thought that a few more weeks (on top of the many so far) would
> let hold-outs review the issues carefully and come to reasoned
> conclusions, that would be worth waiting for. But based on the
> progress I see so far, I'm not very hopeful, so I'm planning to
> prepare an appeal for the 5th of June.
> 2. RFC 3066 already makes many distinctions according to writing
> language, as evidenced by
> http://www.iana.org/assignments/language-tags.
> You say wedging scripts into languages is kind of a hack. " Look at
> Ken's message:
> http://eikenes.alvestrand.no/pipermail/ietf-languages/2003-May/001039.html
> The entire basis for RFC 3066 is to be practical, and to be able to
> recognize the practical distinctions among written forms that people
> must make. Allowing the productive addition of country code in any ID,
> for example, allows for all of the codes on
> http://eikenes.alvestrand.no/pipermail/ietf-languages/2003-April/000817.html,
> despite the fact that the VAST majority of these are duplicates (in
> the sense that there is no real distinction among the forms that they
> refer to). However, IMPORTANTLY, this does not actually cause a
> problem in practice. Even if 3066bis is extended to allow for script
> codes generatively, the same thing would happen.
> 3. The vast majority of systems using RFC 3066 do, in fact, use it to
> make distinctions among written language. And that is certainly the
> important feature to industry and users. While on the margins, it
> might be used for spoken language distinctions, the 99% case for RFC
> 3066 is written language. This point seems to be completely lost on
> the people that object to the registrations.
> It matters a lot to a great many users if a webpage is served up, and
> some of the pieces on that page are in simplified Chinese and others
> are in traditional Chinese. It matters a lot to Azeri users if some
> pieces are Cyrillic Azeri, some in Arabic Azeri, and some pieces in
> Latin Azeri. This matters a heck of a lot more than if part of a web
> page is in de-1996 and part in de (pre 1996).
> 4. There is a clear and present need for the codes that have been
> proposed. I understand that you have no sense of urgency, and that you
> think that this can just meander along for a few years. (Although
> based on what I can see in this group, it would more likely take
> decades.) And remember, when you talk about "new frameworks" you are
> asking for is NOT just a new RFC for some different framework of
> organizing text, it is asking for changes in all of the Web standards
> and others that use RFC 3066. Not going to happen soon!
> We, and the industry, and the customers, cannot afford that. These are
> important distinctions in written language, distinctions such as
> between simplified and traditional Chinese, which are FAR AND AWAY
> MORE IMPORTANT TO INDUSTRY THAN de-1901, i-bnn, i-enochian, yi-latn,
> and most of the other registrations on
> http://www.iana.org/assignments/language-tags.
> People must be able to interoperate with systems, such as Windows,
> that do (*correctly*) make these distinctions. (It is more than a bit
> ironic that such closed systems are far more responsive to user's
> needs here that this purportedly open system.) If RFC 3066 cannot make
> these distinctions, then people work around it. What will happen is
> that people will make up their own mechanisms or use other IDs such as
> Windows instead. In practice, you will see a proliferation of
> private-use RFC 3066 codes, or worse yet, non-conformant codes RFC
> 3066 codes. Either is not exactly wonderful for interoperability.
> Mark

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