Message-Id: <6.2.1.2.2.20050630113403.041ffeb0@mail.afrac.org>
Date: Thu, 30 Jun 2005 13:00:30 +0200
To: Martin Duerst <duerst@it.aoyama.ac.jp>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07
In-Reply-To: <6.0.0.20.2.20050630171138.08f7f790@localhost>
References: <OFE6340F15.8832D024-ON8825702E.00691482-8825702E.006A1D06@spe.sony.com>
	<6.0.0.20.2.20050629090236.06d7fd60@localhost>
	<02b201c57cbf$39d67180$666e3009@sanjose.ibm.com>
	<6.0.0.20.2.20050630171138.08f7f790@localhost>
Mime-Version: 1.0
Cc: ltru@ietf.org
Precedence: list
Content-Type: multipart/mixed; boundary="===============1254639756=="
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

--===============1254639756==
Content-Type: multipart/alternative;
	boundary="=====================_33090381==.ALT"

--=====================_33090381==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dear Martin,
as a co-Chair of the IETF WG-ltru working group, you wrote on 30/06.2005:

>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.

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.







--=====================_33090381==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Dear Martin,<br>
as a co-Chair of the IETF WG-ltru working group, you wrote on
30/06.2005:<br><br>
<blockquote type=cite class=cite cite="">Just to make things clear, I was
not asking for a lengthy explanation<br>
of every issue that ever came up on the mailing list, or in some
other<br>
discusson. I was also not proposing to delay the schedule. I was
just<br>
proposing that documenting the arguably most disussed point in the<br>
whole proposal, namely the position of the script tag.<br>
But I'll leave it to the editors to do the right thing.</blockquote><br>
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. <br><br>
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.<br><br>
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.<br><br>
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
(<a href="http://jprs.co.jp/en/topics/050405.html">
<font face="arial" size=2>http://jprs.co.jp/en/topics/050405.html</a>)
due to the positions of corporations and persons directly involved in the
sponsoring of this Draft.&nbsp; We can reasonably estimate that this
comparison would be to the </font>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.<br><br>
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 &quot;linguistic Yalta&quot;.<br><br>
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.<br><br>
I note that this Draft also opposes on several points the linguistic
equal opportunity declaration currently circulated among international
organisations and civil society spheres. <br><br>
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.<br><br>
I just outline a problem to be solved. I propose a solution. <br>
It is now to the Chairs and authors to decide.<br><br>
JFC Morfin<br><br>
(*) 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. <br><br>
<br><br>
<br><br>
<br>
</body>
</html>

--=====================_33090381==.ALT--



--===============1254639756==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

--===============1254639756==--