ietf
[Top] [All Lists]

Re: [Ltru] Re: Last Call: language root file size (long)

2005-08-29 04:44:30
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 concerned. None more than myself can understand that. You may realise that I am even accused to have defended my own consulting practice (you are an employee, I am an independent, sharing in non-profit I often also subsidise) because I started losing clients because a member used mails with his corporate name.

My own involvement is in this area dates of 25 years and I accepted much to defend the users needs. This lead to many experimentations. The potential is huge for the users (to get back for everyone to what I did in 1985 for countries). All this is directly endangered by the Draft.

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. 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" but I am not sure there is a consensus on the meaning? I do not really consider commercial money, but commercial dominance. Of Open Culture. This is in particular described in 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 favorable to market dominant. And the threat on open source is important. This is not the place to discuss this analysis. It was 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. Because the ABNF does not address _all_ the situations. Status quo by nature favors commercial dominants. Status quo is 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 basis of our effort. The daily information we publish on the network. We are currently blocked by the lack of data (we wait for stability of ISO 639-3 and ISO 639-6 availability). The work engaged is of magnitude and is based upon underlying effort. We have a plan and try to stick to it at our expense. The cost the WG-ltru and the threat it represents on us is significant (hence my delegation as an interface). We try to be free to stay independent in advising Govs and international entities.

The arguments that RFC 3066 is widely ignored

Never said that !!! I say it is loosely enforced. And that the target 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 _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 will lead a generalised approach to develop which will also deprecate yours.

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, á la Richard Stallman
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 I defend Govs and cultures! I am for _free_ commercial and trade against a de facto monopoly. We do not want a _unique_ limited langtag removing the capacity to refer non-dominant industries, and imposing a vision foreign to people vernacular culture/way of life (context). Because it does not sell. And does not permit open source. Let take an example: TCP/IP is open to all. Can you give me the source of a Windows socket?

Do you know what is the turn-over of the printing industry? Imposing a single langtag helps the market, technology unification. A few may want to become book/press industries Majors. You will understand many do not want.

A chapel/church is usually (and this is the way it is often used in here) as a religious way to support an idea received as a faith, rather as the result of an experimentation or a serious analysis. A serious analysis would have started with a clean sheet reading of the Charter.

You may recall that I started this WG in proposing to be a co-writer of the Draft. The response was something like "no, they are Addison 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 engaging the final lingual orientation of the Internet, hence of the world?

> 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 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 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 and experimentation.
I have no predefined solution. But I have questions no one wants to address....

> 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 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 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, security, surety, innovation capacity, multilingualism, multimode, multitechnology etc. The common interest is that we can agree on solutions. If we disagree (like SID and SPF) the user will decide, not the vendor. This takes more time, delays everyone, cost to 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 extensions.

The purpose is served if every community can invent what it needs. 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 which is a very interesting demonstration of the difficulty of the participants to deal with multilingualism :-) - despised, joked at, etc. I do not think I ever retaliated. If I did I was wrong. I prefer to explain. Even if it takes and not read. No one knows.

jfc


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf