Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07

From: [email-masked]
Date: Tue, 28 Jun 2005 12:16:09 -0700

I'm a newcomer to the list, so forgive me if I have a historical question: 
Why was the decision made to put the script variant before the regional 
variant? I likely would have structured it with the regional variant 
before the script variant because for me, the script variant only applies 
if the content is written while the regional variant would apply in both 
the written and spoken contexts. If you can point me in the direction of 
an archive on the topic, that would help.

Thank you,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

"Addison Phillips" <[email-masked]>
Sent by: [email-masked]
06/27/2005 10:22 AM

        To:     <[email-masked]>
        cc:     LTRU Working Group <[email-masked]>
        Subject:        [Ltru] Submission: draft-ietf-ltru-registry-07

Dear Editor,

Please find draft-ietf-ltru-registry-07 attached.

Best Regards,

Addison (for the editors)

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com

Chair, W3C Internationalization Core Working Group
http://www.w3.org/International

Internationalization is not a feature.
It is an architecture. 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Jun 2005 13:53:07 -0700

Hi Karen -

> From: <[email-masked]>
> To: "Addison Phillips" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, June 28, 2005 12:16 PM
> Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07
>

> an archive on the topic, that would help.
...

The ticket manager is at https://rt.psg.com/ (user & password "ietf")
and this particular issue was number 999.  There was *lots* of
discussion on this, and it took a long time to come to a compromise.
A good place to start is with message
http://www.ietf.org/mail-archive/web/ltru/current/msg00974.html
The short version is that if we did not have legacy code and data
to deal with, we'd probably have done it differently.

Randy

---

From: "John.Cowan" <[email-masked]>
Date: Tue, 28 Jun 2005 17:14:31 -0400

[email-masked] scripsit:
> variant?

Because the same language in different scripts is more likely to be a barrier
to intelligibility than the same language in different regional variants.
As a native speaker and reader of en-us, I have no trouble with most kinds
of en-gb spoken or written, but English in Braille is totally useless to me.

> I likely would have structured it with the regional variant 
> the written and spoken contexts. 

True enough, but nothing *requires* the use of a script subtag, and in some
particular cases (where there is an obvious default) they are actually forbidden:
you use the Latn tag with en, e.g.

-- 
John Cowan   www.reutershealth.com   www.ccil.org/~cowan   [email-masked]
Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue did
rudely yerk me on the knob, wherefrom my wits still wander."
An Englishman: "Ay, a filchman to the nab betimes 'll leave a man  
crank for a spell." --Harry Turtledove, Ruled Britannia

---

From: Martin Duerst <[email-masked]>
Date: Wed, 29 Jun 2005 09:08:46 +0900

Addison, others,

This question is probably the most frequent question that comes
up from newcommers. Is there any chance that the reason for this
decision is documented in the draft, e.g. in an Appendix?

There are some examples of how to do this, see e.g.
RFC 3987, Appendix A, or RFC 3023, also Appendix A.

Are there any other difficult-to-understand things that might
benefit from such documentation? We already have some documentation
about how we got to the various length restrictions; maybe that
could be moved to the appendix, too.

Regards,    Martin.

---

From: r&d afrac <[email-masked]>
Date: Wed, 29 Jun 2005 15:04:25 +0200

>could be moved to the appendix, too.

Dear Martin,
this a very sensible proposition which could spare us a lot of contention 
and wasted time. It could permit to document many points and leave them 
open for the future. I will take as an example the sensible question of ISO 
11179 which is the further compatibility with the other real world issues. 
There is an enormous difference between not alluding to it and a comment 
explaining why (for example that due to the importance and the global 
nature of the issue, a specific work of the IETF on the matter is 
necessary, and that it has been noted that ISO 639-6 will comply with ISO 
11179).

The list of these comments could result from the analysis of the Charter. 
By this WG or in response to mine (if there is a warrantied result and the 
possibility to possitively get out of this dead-end I am ready to work on 
it). Every serious point of disagreement could result into a short summary 
of the responses given on the list. It would clearly describe the options 
of the document. In such a case I would even drop my opposition to BCP 47 
since this appendix would clearly define the scope and the doctrine of the 
document, the only thing we want.
best regards
jfc

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 29 Jun 2005 08:28:38 -0700

With any document, it is always possible to have incremental improvements.
But we will never finish at that rate. It is now the 60th of May, so if we
are going to finish by the end of May as planned, we have to wrap things up,
instead of having continual tweaks.

‎Mark

---

From: r&d afrac <[email-masked]>
Date: Wed, 29 Jun 2005 18:47:56 +0200

>instead of having continual tweaks.

Mark,
let be realistic. What Martin proposes has my agreement and I am quite sure 
the agreement of those I team with (I sent a mail, we have the EGENI 
meeting tomorrow and the Luxembourg meetings the week after - so we can 
concert f2f [I will have to make some convincing, but I feel confident]). 
So the options are:

- either we work seriously on this and you have a final text (which will 
not be changed, only commented) within one month, which will seamlessly go 
through the LCs (unless there is real disagreement over the description of 
the motives of this WG, but I suppose that you guys know why you want what 
you want?) This will be obtained at least effort for all (we _really_ have 
other things than to protect our work and users from you). If the wording 
is clear I have no objection that Peter uses it for ISO.

- or we do not. I suppose that we will list at least 70 points to be 
discussed for the WGLC. The same at the IESG LC. This will most probably 
give us the time to work and develop, test and document (running code and 
on-line applications, plus report of Varsaw) why your approach is out of 
scope for the Internet and cannot scale (I say Internet, not W3C). My 
guesstimate is that we have no problem showing there is no consensus in the 
coming two LCs, building a consensus against your Draft within the next 
three to six months and for our common work within one year. At IETF or 
WSIS. The IDN WG has lasted three years. It was just on domain names.

IMHO the work is simple. It simply consists for us in reviewing the 
document to list not what we oppose, but where we need a clarification of 
the reasons why. The text should most probably result from the past 
exchanges of the list. These are its "whereas".

Don't you think we have other things to do in life than to fight one another?
I am not paid for all this, I am ethically/technically right, I am 
supported by many and if grow too old there are several better than me to 
replace me ...
No one owns the IETF.
your choice.
jfc

---

From: Martin Duerst <[email-masked]>
Date: Thu, 30 Jun 2005 17:13:37 +0900

Just to make things clear, I was not asking for a lengthy explanation
of every issue that ever came up on the mailing list, or in some other
discusson. I was also not proposing to delay the schedule. I was just
proposing that documenting the arguably most disussed point in the
whole proposal, namely the position of the script tag.
But I'll leave it to the editors to do the right thing.

Regards,   Martin.

At 00:28 05/06/30, Mark Davis wrote:
 >窶皿ark

---

From: r&d afrac <[email-masked]>
Date: Thu, 30 Jun 2005 13:00:30 +0200

Dear Martin,

>But I'll leave it to the editors to do the right thing.

This is exactly the way I understand it and I propose to proceed. I do not 
leave it however to the editors: this is a step too far away. But this is 
not the most arguably point in the whole proposal and I think the Chairs 
and the Authors should agree to consider this solution to clarify all these 
points.

I therefore repeat my proposition: if Chairs and authors formally agree, I 
will present within the delay of the WGLC a public list of the points 
needing an explanation of the authors' rationale. Authors will then do what 
they want with the list which will be published and advertised. IESG, 
public and users will then be able to decide of their own adherence to the 
resulting text.

This would permit to clarify the extremely confused and non documented 
application scope and context of the proposition. In such a case, there 
would be no objection anymore on my side and of the team, organisations and 
contact I accepted to speak for, to a Draft which is currently heavily 
opposed by concerned user spheres, for its political and commercial 
practical surroundings. Having been active in identifying its layer-8 (*) 
connotation and its layer-9 (*) issues, I am certainly aware of the 
consequence of publishing the current text without that explanations. This 
is why I cannot see any future to this Draft other than a very poor impact 
on the IESG/IETF image, should it be accepted, and a resulting technical 
confusion highly detrimental to the stability of the Internet and costly to 
all the industries.

We are here in a situation comparable to the IDNA situation which currently 
results into a secondary DNS root by the largest country of the planet and 
in an industrial controversy 
(<http://jprs.co.jp/en/topics/050405.html>http://jprs.co.jp/en/topics/050405.html) 
due to the positions of corporations and persons directly involved in the 
sponsoring of this Draft.  We can reasonably estimate that this comparison 
would be to the power due to the impact on industries, policies, cultures, 
of a too restrictive tagging via a IANA registry of the most valuable and 
cherished common good of the mankind. The current IETF debate shows the 
increasing and firm opposition to such attempts to control the world 
through the restrictive control of a IANA registry.

We also know that should it be accepted by the IESG and actually enforced 
by the IANA, the impact of the created scarcity and dominated languages 
namespace would be pervasive and irreversible while it is still currently 
unthinkable to most. This means that the identification process will be 
slow but deep. The political consequences will be grave, in a world where 
cultural and national sovereignties issues are exacerbated by a global 
uniformisation this Draft proceeds from. It will probably be soon 
unanimously identified (this is already the case in informed spheres) as 
its core because it confuses ASCII Internationalisation and 
Multilingualisation. Being commercially driven will be an important 
opposition factor: the resulting IANA process starts being referred to as 
the "linguistic Yalta".

This is why it is likely that this proposition will never take-off and will 
be quickly replaced by the propositions currently discussed by the ISO 639 
series and harmonized with the other multimodal and general aspects along 
the guidelines of ISO 11179 this WG refuses to consider. This ISO 
compatible proposition is already under implementation by efforts 
comparable to the one I direct on the granular distribution of the IANA 
extensions. However, the confusion created by the use of prestigious 
sponsors and the innovation blockade the proposition represents will most 
probably last for a long time and have consequences on the image of the 
involved technologies. This is all the more difficult to understand that 
this is directly opposed to the desire of harmonisation of the IESG Charter 
of this Working Group.

I note that this Draft also opposes on several points the linguistic equal 
opportunity declaration currently circulated among international 
organisations and civil society spheres.

I know this will genuinely not be understood by some of the participants to 
the WG-ltru IETF Working Group and may be some of the Members of the IESG 
who will want to discuss it. I therefore want to clarify: this is not a 
point for discussion, this is a simple description of the reality this WG 
wants to rule. Debating of its forecast and solution is desirable. 
Disputing its diagnosis would only denote a disqualifying ignorance as a 
standardiser.

I just outline a problem to be solved. I propose a solution.
It is now to the Chairs and authors to decide.

JFC Morfin

(*) Layer-8 and Layer-9 are traditional IETF ways to identify commercial 
and political aspects. I suggest the use of Layer-10 for the cultural 
aspects. This refers to the OSI 7 layer model. They should not be confused 
with the Extended Network Systems model developped by Tymnet in the mid-80s 
and used by Intlnet and AFRAC which use Layers 8 to 12 to qualify the 
Interapplicative, Agent, Actor, Organisation and Societal layers.

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 30 Jun 2005 07:26:15 -0700

I realize that your intentions were good, but we are way behind schedule.

‎Mark

----- Original Message ----- 
From: "Martin Duerst" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Addison Phillips"
<[email-masked]>
Cc: <[email-masked]>; "LTRU Working Group" <[email-masked]>
Sent: Thursday, June 30, 2005 01:13
Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07

---

From: Erkki Kolehmainen <[email-masked]>
Date: Thu, 30 Jun 2005 17:39:45 +0300

Dear All,

I'd like to note that the language tagging mechanism being produced here 
could be characterized as an urgently needed, pragmatic, best-effort, 
yet arguably state-of-art solution to the practical problems at hand.
In doing this, it is recognized that there are and will be everlasting 
disputes on what are proper languages and proper scripts, and what kind 
of granularity can or should reasonably be applied to the definition of 
regional variants of any given language - in essence, what is the 
minimum or optimal granularity of the tagging mechanism (for each 
application). These shortcomings don't, however, invalidate the result 
nor make it a short-lived, interim-only solution.

I'm under the impression - although I may be wrong - that making a 
statement somehow along the above lines could make the draft more 
palatable to Mr. Morfin and others who seem to be targeting for 
something beyond what the majority considers viable at this stage.

Sincerely,
Erkki I. Kolehmainen

r&d afrac wrote:

> This is exactly the way I understand it and I propose to proceed. I do 
> not leave it however to the editors: this is a step too far away. But 
> this is not the most arguably point in the whole proposal and I think 
> the Chairs and the Authors should agree to consider this solution to 
> clarify all these points.
> 
> I therefore repeat my proposition: if Chairs and authors formally agree, 
> I will present within the delay of the WGLC a public list of the points 
> needing an explanation of the authors' rationale. Authors will then do 
> what they want with the list which will be published and advertised. 
> IESG, public and users will then be able to decide of their own 
> adherence to the resulting text.
> 
> would be no objection anymore on my side and of the team, organisations 
> and contact I accepted to speak for, to a Draft which is currently 
> heavily opposed by concerned user spheres, for its political and 
> commercial practical surroundings. Having been active in identifying its 
> layer-8 (*) connotation and its layer-9 (*) issues, I am certainly aware 
> of the consequence of publishing the current text without that 
> explanations. This is why I cannot see any future to this Draft other 
> than a very poor impact on the IESG/IETF image, should it be accepted, 
> and a resulting technical confusion highly detrimental to the stability 
> of the Internet and costly to all the industries.
> 
> We are here in a situation comparable to the IDNA situation which 
> currently results into a secondary DNS root by the largest country of 
> the planet and in an industrial controversy ( 
> http://jprs.co.jp/en/topics/050405.html) due to the positions of 
> corporations and persons directly involved in the sponsoring of this 
> Draft.  We can reasonably estimate that this comparison would be to the 
> power due to the impact on industries, policies, cultures, of a too 
> restrictive tagging via a IANA registry of the most valuable and 
> We also know that should it be accepted by the IESG and actually 
> enforced by the IANA, the impact of the created scarcity and dominated 
> languages namespace would be pervasive and irreversible while it is 
> still currently unthinkable to most. This means that the identification 
> process will be slow but deep. The political consequences will be grave, 
> in a world where cultural and national sovereignties issues are 
> exacerbated by a global uniformisation this Draft proceeds from. It will 
> probably be soon unanimously identified (this is already the case in 
> informed spheres) as its core because it confuses ASCII 
> Internationalisation and Multilingualisation. Being commercially driven 
> will be an important opposition factor: the resulting IANA process 
> starts being referred to as the "linguistic Yalta".
> 
> This is why it is likely that this proposition will never take-off and 
> will be quickly replaced by the propositions currently discussed by the 
> ISO 639 series and harmonized with the other multimodal and general 
> aspects along the guidelines of ISO 11179 this WG refuses to consider. 
> This ISO compatible proposition is already under implementation by 
> efforts comparable to the one I direct on the granular distribution of 
> the IANA extensions. However, the confusion created by the use of 
> prestigious sponsors and the innovation blockade the proposition 
> represents will most probably last for a long time and have consequences 
> on the image of the involved technologies. This is all the more 
> difficult to understand that this is directly opposed to the desire of 
> harmonisation of the IESG Charter of this Working Group.
> 
> I note that this Draft also opposes on several points the linguistic 
> equal opportunity declaration currently circulated among international 
> I know this will genuinely not be understood by some of the participants 
> to the WG-ltru IETF Working Group and may be some of the Members of the 
> IESG who will want to discuss it. I therefore want to clarify: this is 
> not a point for discussion, this is a simple description of the reality 
> this WG wants to rule. Debating of its forecast and solution is 
> desirable. Disputing its diagnosis would only denote a disqualifying 
> ignorance as a standardiser.
> 
> aspects. This refers to the OSI 7 layer model. They should not be 
> confused with the Extended Network Systems model developped by Tymnet in 
> the mid-80s and used by Intlnet and AFRAC which use Layers 8 to 12 to 
> qualify the Interapplicative, Agent, Actor, Organisation and Societal 
> layers.
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>