Message-Id: <6.2.3.4.2.20050829072137.03a47710@mail.afrac.org>
Date: Mon, 29 Aug 2005 09:13:56 +0200
To: "Doug Ewell" <dewell@adelphia.net>, <ietf@ietf.org>,
	<iesg@iesg.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: Last Call: language root file size (long)
In-Reply-To: <01b801c5ac4f$b79ada60$030aa8c0@DEWELL>
References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr>
	<431090C2.20804@blueyonder.co.uk>
	<6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com>
	<4310E7E8.4070408@blueyonder.co.uk>
	<6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com>
	<6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com>
	<009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL>
	<6.2.3.4.2.20050829022911.0595eeb0@mail.afrac.org>
	<01b801c5ac4f$b79ada60$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

At 06:11 29/08/2005, Doug Ewell wrote:
>JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:
> > I am sorry to impose that kind of response - and a large number of
> > mails. But this shows the problem to protect an open R&D capacity
> > against a chapel, which as some good points. And a non-profit R&D
> > against people sharing in a commercial competing consortium.
>
>Since most of M. Morfin's messages make at least passing mention of this
>supposed conflict between "open" and "commercial" interests -- the
>forces of good vs. the forces of evil, as it were -- I suppose some
>explanations about my own motives are in order.

Dear Doug,
I read very carefully your mail. I apologise if you felt personally=20
concerned. None more than myself can understand that. You may realise=20
that I am even accused to have defended my own consulting practice=20
(you are an employee, I am an independent, sharing in non-profit I=20
often also subsidise) because I started losing clients because a=20
member used mails with his corporate name.

My own involvement is in this area dates of 25 years and I accepted=20
much to defend the users needs. This lead to many experimentations.=20
The potential is huge for the users (to get back for everyone to what=20
I did in 1985 for countries). All this is directly endangered by the Draf=
t.

>Very importantly, this program is **NOT** a commercial endeavor.  It
>could conceivably be made into one, or it culd be offered as freeware or
>shareware (although I have no specific plans to do either), but it could
>just as easily be converted to an "open source" project of the type
>often mentioned by M. Morfin.

I refer to the piratical capacity to freely develop what they want.=20
Open to all, but also open to innovation.

>The point is that there is NO dichotomy between "free" (or "open" or
>"non-profit") and "commercial" (or "corporate") when it comes to the
>current drafts.

I do not speak of "free". I actually want to talk of "open standard"=20
but I am not sure there is a consensus on the meaning?
I do not really consider commercial money, but commercial dominance.=20
Of Open Culture. This is in particular described in=20
http://nicso.org/equilang.tm equal lingual opportunity.

>The draft contains NO restrictions against open-source
>or non-profit implementation (I would think they would be strongly
>encouraged).

The problem is that the nature of the market makes that Draft=20
favorable to market dominant. And the threat on open source is=20
important. This is not the place to discuss this analysis. It was=20
made by Gov officials and international analysts I trust.

>There is nothing in the ABNF that prevents open-source
>development based on the proposed BCP.

The problem is not the ABNF, it is the pretension to exclusive.=20
Because the ABNF does not address _all_ the situations.
Status quo by nature favors commercial dominants. Status quo is=20
opposed to innovation.

>  There are no IP constraints on
>any of the technology used in its development.

Can you warranty that? Unfortunately the experience does not say that....

>Any existing protocols
>that make use of language tags, and stand to benefit from the proposed
>update, will benefit equally regardless of whether they are commercial
>or not.
>
>M. Morfin has argued that there are prevalent "running code"
>implementations that use his expanded language-tag syntax, which is not
>compatible with the syntax in the present draft.  However, to date I
>have not seen any pointers to such an implementation, nor any evidence
>of the "prevalence" of this alternative syntax.  Obviously any developer
>can write code that *does not conform* to a given standard, or proposed
>standard, but that says nothing about the standard itself, or about
>whether the non-conformant code or the syntax it does follow is somehow
>better.

I have documented enough the dot-root experiment which is at the=20
basis of our effort. The daily information we publish on the network.=20
We are currently blocked by the lack of data (we wait for stability=20
of ISO 639-3 and ISO 639-6 availability). The work engaged is of=20
magnitude and is based upon underlying effort. We have a plan and try=20
to stick to it at our expense.  The cost the WG-ltru and the threat=20
it represents on us is significant (hence my delegation as an=20
interface). We try to be free to stay independent in advising Govs=20
and international entities.

>The arguments that RFC 3066 is widely ignored

Never said that !!! I say it is loosely enforced. And that the target=20
of the Draft is to use it much more.

>are specious as well;
>there are numerous examples of protocols that adhere to the RFC 3066
>model.  The fact that non-conformant implementations (like the culture
>identifiers) exist is not a justification for throwing away the model.

???? I am _defending_it_ if you really like it !!! I just want it=20
_not_to_want_to_be_exclusive_ and to warn people about its dangers.
You are throwing away the model: in wanting to oppose others, you=20
will lead a generalised approach to develop which will also deprecate you=
rs.

>To cite an example from another thread, we acknowledge that some mail
>software implements "Reply-To" poorly, but that does not mean the whole
>notion of "Reply-To" should be thrown away as irrelevant, or "not
>supported by open R&D solutions."
>
>I apologize for the length of this particular point, but I feel it is
>important.  Not everyone who supports the draft does so out of
>commercial greed, and even those who happen to work for Big Commercial
>Behemoths might have higher motives.  Some people just like the feel of
>an "open software vs. closed software" struggle, =C3=A1 la Richard Stall=
man
>or Eric Raymond -- note M. Morfin's reference to a "chapel," evoking
>images of Raymond's "The Cathedral and the Bazaar" -- but the truth is
>that this image simply doesn't apply to the LTRU draft.

I am sure this is the way you see me. But read what I say, do not imagine=
 it!

I documented enough that I defend industry non-dominants! I say that=20
I defend Govs and cultures! I am for _free_ commercial and trade=20
against a de facto monopoly. We do not want a _unique_ limited=20
langtag removing the capacity to refer non-dominant industries, and=20
imposing a vision foreign to people vernacular culture/way of life=20
(context). Because  it does not sell. And does not permit open=20
source. Let take an example: TCP/IP is open to all. Can you give me=20
the source of a Windows socket?

Do you know what is the turn-over of the printing industry? Imposing=20
a single langtag helps the market, technology unification. A few may=20
want to become book/press industries Majors. You will understand many=20
do not want.

A chapel/church is usually (and this is the way it is often used in=20
here) as a religious way to support an idea received as a faith,=20
rather as the result of an experimentation or a serious analysis. A=20
serious analysis would have started with a clean sheet reading of the Cha=
rter.

You may recall that I started this WG in proposing to be a co-writer=20
of the Draft. The response was something like "no, they are Addison=20
and Mark. They will publish the WG Draft tomorrow"

> >> What I said, as anyone can see from reading the quote above, is that
> >> a 740-page I-D might be unwieldy enough that the IETF might consider
> >> a different procedural mechanism for delivering the information to
> >> IANA.
> >
> > Correct.
> > I do not see the need of all the innuendo above to repeat what I
> > quoted.
>
>It was quoted as though it proved "some of the problems resulting from
>the expected size of the language tag registry and the capacity of the
>langtag solution to fulfill the WG-ltru Charter."  It does nothing of
>the sort.  Whether IETF or IANA wants to deal with a 740-page I-D is
>entirely up to them.

It was quoted period. So people may just decide that!

> >> Since the charter neither refers nor alludes to ISO 639-6, there is
> >> no conflict with the charter if WG members disagree in regard to the
> >> *eventual* expansion of the scope of language tags to involve ISO
> >> 639-6.
> >
> > This repeated allusion to the Charter neither refering nor alluding
> > to ISO 639-6 is to be compared with the text of the Charter
> > (http://ietf.org/html.charters/ltru-charter.html) which says "It is
> > also expected to provide mechanisms to support the evolution of the
> > underlying ISO standards, in particular ISO 639-3".
>
>Peter Constable has already addressed the meaning of "the underlying ISO
>standards."

I am not interested in "underlying" but in "evolution"....

>ISO 639-6 is not an underlying ISO standard for purposes of
>this draft.  (It's not even a standard, in fact, not even a CD yet.)
>For that matter, ISO 6709 is also not an underlying ISO standard for
>purposes of this draft, so the draft does not permit tags of the form
>"fr+484816+0020708" either.

Do you really think this detail carry any weight when you consider=20
engaging the final lingual orientation of the Internet, hence of the worl=
d?

> > This kind of problem may be related to the refusal of the WG to start
> > from/analyse the Charter requirments?
>
>I understand the charter requirements just fine.  Almost all of the WG
>does.

How do you know? Randy documented 57 participants at some stage. May=20
be twenty participated. Really less than a dozen ....

> > I do not know if I share concerns with Doug. I do share the concerns
> > of Doug.
>
>The concern quoted above was that a 740-page I-D might be unwieldy.  I
>acknowledge that M. Morfin might share that concern.  Happily, it is a
>concern for the next draft, not this one.

See above. Do you buy a car without considering the cost of=20
insurance; repairs, gas, etc. ?

> >> I hereby disassociate myself with any statements made by M. Morfin
> >> concerning the drafts produced by the LTRU WG.  I hope that is clear
> >> enough for IETF members.
> >
> > Since I said I supported his Draft ....
>
>"Disassociate" does not mean "disagree."  It means I do not speak so as
>to bolster his point.
>
> >>> 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped=
)
> >>> to 650 K (100 K zipped). This information, updates and additions
> >>> MUST be available to each of the on-line application of the devices
> >>> of billions of users. The Draft does not explain how.
> >>
> >> The WG decided this was an IANA implementation issue, and out of
> >> scope.
> >
> > Correct. This is exactly what I say.
>
>I suppose if we want to pursue this issue of huge daily updates and
>bandwidth consumption, we should start by asking how many
>implementations currently perform daily updates on the existing IANA
>Language Tag Registry, a resource which (of course) is necessary to
>implement RFC 3066 fully.

Very good idea. Do you have figures?
My experience of networks is different from yours. Let add experience=20
and experimentation.
I have no predefined solution. But I have questions no one wants to addre=
ss....

> > Doug said in another mail "I just think the two figures (7,600 and
> > 20,000) could be seen as representing a fundamental disagreement."
> > This is a legitimate concern at a time a LC is to engage the whole
> > IETF in a direction where you think this is unclear. I would not
> > qualify that of ust "talk". This is something loyalty calls you to
> > say, even if it is to explain why there is no fundamental
> > disagreement.
>
>1.  The charter does not refer to ISO 639-6, which will eventually
>encode 20,000 "languages and dialects."

ISO 639-6 is an officially planned "evolution" of ISO standard (refer=20
to Charter). In any case we support Linguasphere.

>2.  The charter does refer to ISO 639-3, which will encode 7,600
>languages, but only for future planning, for "evolution."

This is totally irrelevant remark: what does it change? We talk of=20
the Internet of the world.

>3.  The proposed initial registry contains subtags based only on the
>existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and
>United Nations M.49, as well as "variant" and "grandfathered" subtags
>based on the RFC 3066 registry.

Yes. Then?

>4.  Normative references to a not-yet-completed standard are bad, for
>the same reason that normative references to an I-D are bad.

I am not interested in paper work, I am interested in stability,=20
security, surety, innovation capacity, multilingualism, multimode,=20
multitechnology etc. The common interest is that we can agree on=20
solutions. If we disagree (like SID and SPF) the user will decide,=20
not the vendor. This takes more time, delays everyone, cost to=20
everyone: so it is better than users and vendors agree.

> > NB. As a user, the langtag solution does not provide as much
> > possibilities, simplicity, flexibility than solutions using ISO 639-6
> > (with the possible use of ISO 639-1/2/3 when necessary. This is IETF
> > not ISO.
>
>THERE IS NO ISO 639-6.  There will be, some day, but such a standard
>oes NOT exist now.  Good heavens, the data is not even publicly
>available yet!  Of course the language tag solution is not going to be
>based on a vapor standard.

..... in which world do you live?

> > I have documented enough (too much :-)) during these last days that I
> > support (one can read my mails of end of December 2004) the Draft
> > with the provision it is not exclusive and serves the Internet
> > community rather than exclude its R&D and innovation capacity.
>
>The purpose of language tags is interoperability.

This is the problem: the need of the langtag is interintelligibility.

>This purpose is not served if every organization invents its own extensi=
ons.

The purpose is served if every community can invent what it needs.=20
More complex for the vendor. Risk of local solutions being sold....

>The sections
>of the draft that deal with private-use tags and subtags are heavily
>laden with caveats to explain this.

There is no private-use tags.

> > Happily I support my Unicode co-Member Doug's own Draft and I thanked
> > him for the work he consciensiously achieved over the months
> > maintaining the base he now proposes as a Draft! (even if I doubt a
> > 740 pages I-D can be of real use in the future).
>
>I acknowledge M. Morfin's support for draft-initial, and thank him for
>his restraint in this message.

I am afraid that I have been often hurt - for example on my Franglish=20
which is a very interesting demonstration of the difficulty of the=20
participants to deal with multilingualism :-) - despised, joked at,=20
etc. I do not think I ever retaliated. If I did I was wrong. I prefer=20
to explain. Even if it takes and not read. No one knows.

jfc


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru