Message-Id: <6.2.1.2.2.20050620085827.04f5e210@mail.afrac.org>
Date: Mon, 20 Jun 2005 08:59:36 +0200
To: ltru@ietf.org
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: review of the day.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

[sent by mistake to Frank only]

On 04:30 19/06/2005, Frank Ellermann said:
>Unless it's about false-positive-spam or accepting articles
>from unsubscribed sources.

This is what happened, I think.

> > The first thing a WG should do, in common opinion (see
> > debate on ietf@ietf on the matter) is first to have a common
> > understanding of the Charter. This WG has not done this yet
>
>That's your position.

Randy said this debate will be after the Draft is finished. My experience 
of this WG is that there no way to change this schedule. So I just wait for it.

>...and I still think we're on track. 3066 has several problems
>and we fixed them.  We're supposed to add scripts, and we did.

You think we are on track. We think we are not. This is the reason of a 
debate. There is no consensus.

>We're not forced to like the idea, and in fact I'm no big fan
>of it, but we carefully avoided havoc with the Suppress-Script
>concept, solved the problem of too many 693-3 extlangs, and got
>it in a shape where Bruce cannot fault us for ignoring MIME.

These are minor issues relating to the global vision of the problem at hand.

>And we checked especially the most perverse tag under the most
>perverse condition, RfC 2231/2047 for pc-multilingual-850+euro.
>It's my local charset, I was interested to get it right.

I have no idea of what you are talking since charsets are not supposed to 
be concerned :-)

>Finally we also found a solution for the funny region codes,
>we go with the source standards a far as possible, or in other
>words until ISO 3166-1 reycles alpha-2 country codes.  And for
>that case we have an emergency exit.

You found _a_ solution.

Better was to conform to the standard we use (your position over ISO 3166 
will make the tags unconsistent with ISO tags). This standard (ISO 639) is 
subject to ISO 11179 and ISO 639-4 rules. The same persons are active in 
both arenas (ISO and IETF). I do not think this WG should be a way to use 
IETF to influence ISO, no more than I think ISO committees should be a way 
to influence IETF. We have parallel and complementary technical work and we 
want to stabilise solutions for the best convenience of users and trade. 
Crosspolenisation  is good, iterative pushing may help, but this must be in 
the open. Also commercial support has limits (RFC 3869) and politics makes 
poor technical reasons.

>It's _much_ better than the old draft-10.  Minus one round of
>final nitpicking it's ready.  Run it through the "idnits" tool,
>the W3C spell checker, Bill's XML validator (after adding the
>important <?rfc strict="yes" ?>), maybe the ABNF checker again,
>and mark the third milestone as "done" on the WG charter page.

We are not talking of the same thing. You are talking of a function to be 
used by some applications  to deliver a classification tag. I am talking of 
the Internet and of the Language Identification tag to be use in a broad 
range of issues including normative ones (read the RFC 3066, the Draft 
introduction and the Charter).

This WG is like if we were only considering the  scope of ISO 639-3 but 
wanting the Draft to influence ISO 639-6. All this boils down to market 
share and political influence: this is something for ISO, not for IETF. 
Once ISO has sorted this issue at general's satisfaction, IETF will be able 
to build on it.

> > there is no consensus on the reading of the Charter.
>
>That's your position.  For my reading of the charter see above.

Yes. This is your own reading. This is not a general one among ISO Members. 
This will be discussed in Varsaw in August. Not our concern however, the 
IESG cannot be used as a way to influence that ISO debate. If IESG and IANA 
wzez officially warned by organisations and Govs, I do not think it would 
be good for the IETF and ICANN, while the world community is discussing 
ICANN's and IANA's role and its trust into the IETF. I think it is 
advisable to leave the things develop harmoniously, ISO sorting ISO matters 
and IETF sorting IETF matters.

> > Randy promised this debate once the Draft would be completed.
>
>Discussing the work plan after the work is done would be odd.

I am not to judge the plan of the Chairs. This is their show and 
responsibility. When you consider it, due to the history of the Draft, this 
might not be a bad idea. Actually I would support it, if the target is (a 
very advisable thing when you write a document) to write the introduction 
once the work is completed and cannot be changed, so we know what we talk 
about. The Draft is good for those wanting/needing to use it. The problem 
is that it wants to be normative instead of descriptive and to be forced 
upon everyone instead of being proposed. This can be easily addressed in 
correcting the first page.

> > I have no real interest in this WG until it discusses what
> > the Charter means.
>
>Yes, as I said, love it or leave it.

No. This is the Internet: it belongs to you as much as to me :-) . And to 6 
billions other people.

The real problem is network stability. W3C and XML may seem to be big to 
you, today. You did not know them 10 years ago and you may not know them 10 
years from now. Look at BTX and Minitel. Minitel grown up to 92% of the 
population using it in France. Everyone still have a Minitel and use it 
quite often (far better than the net for phone directory). But who would 
make standards depend on Minitel? In a way W3C is very similar to my 
approach a long ago (hypelinks, tags, metaformats/data, etc. but also more 
compact and page embedded search engines...)

>  I was more interested to
>avoid the havoc of the old draft-10, and IMHO the result is now
>presentable.  I'm even confident that I could answer each and
>every question about MIME-compatibility.  I've forwarded one
>technical question to USEFOR, and they can certainly solve it:
><http://mid.gmane.org/42A8F4D6.7C54@xyzzy.claranet.de>
>   [private WG]

> >> I don't see your point here.
> > The point is that if there are two supported conflicting
> > Drafts on the same matter, this will only delay both.
>
>With the IESG you never know, some days ago somebody announced
>to publish technically incompatible drafts simultaneously.  If
>it wouldn't be both unethical and unprofessional it would be
>ridiculous.
>
>But your idea to block a draft

Never intended to block anything! I want the Internet not to be blocked by 
the inappropriate usage of the Daft. I only want things to be carried in 
due time and good order, by who is their accepted responsible.

>by publishing your own does not
>fly:  First you'd have to submit it a.s.a.p., and then LTRU is
>a WG, so they'd tell you to discuss it here (if it's about the
>language tag registry).

This is why I wait for the debate over the Charter. It not only "about the 
language tag registry", it is about the Charter. If the debate over the 
charter does not occur I will be forced to do that.

> > I am interested in an ISO 11179 consistent approach that ISO
> > 639-6 will provide, and that ISO 639-4 will determine a few
> > things about ISO 639-3 and -6.
>
>ISO 639-6 and 639-4 don't exist yet, I'm not sure what 11179
>is, we prepared anything as far as possible for ISO 639-3, and
>waiting for vaporware is not "engineering".

? you may want to contact the DIN to get some information. ISO 639-3 would 
be the most "vaporeware" of all. All the more if ISO Committees realise 
that this WG is used to force ISO 639-3.

I suggest you really look into ISO 11179. Not to read it: it would take 
years to fully understand it and to correct it (500 pages, not finished). 
But to understand what it is about, how the solutions this WG may chose may 
conflict and where and why.

To make you and interested people understand the thing is "simple" enough:

- there is ISO 639-1 and ISO 639-2. They result from mainly US Librarian 
efforts.

- there is an ISO plan which includes ISO 639-3 -4 -5 and -6. The key 
document (it should be understood as 639-0) is ISO 639-4 which is to give 
the guide linbes for the whole series. In a way ISO 639-3 cannot be 
published before ISO 639-4.

- ISO 639-3 effort is conducted by Peter Constable. It uses the SIL 
database to list 7500 language names. SIL is a real life publisher (they 
translated and published the Bible in many languages). There are common 
needs between publishers and printers/typographers. Peter pushed for 
cooperation with Unicode. They identified they needed the name of the 
script to sort books in a library. Unicode identified their need was the 
same when dealing with "locales" and W3C when dealing with XML pages, etc. 
However "locales" make them normative and a way to control something in 
every OS, etc. Hence the concerns about IP rights when you know who is Unicode.

- ISO 639-6 is a cooperation of a correlation of interests with the target 
to be ISO 11179 conformant (i.e. compatible with any ISO based system - 
from Telecoms to consumer goods, etc.) . It is based upon David Dalby's 
Linguasphere work. The debate over the "gsw" illustrates amore general need 
than to sort books in a shelf, but also DVDs, music intruments, cars, etc. 
along with languages, terms, and many other language objects.  This is of 
interest to W3C for VXML, but not really to Unicode. On 
"ietf-language@alvestrand.no" someone said that a usage was RFC 3066 bis 
conformant, but not XML appropriate. The main question now is an ISO 639 
metamodel: this is where AFRAC is interested, not in the old ABNF of a tag 
which will be forgot in 10 years. But if the place of that tag is 
misuderstood it can create havoc and delay everything.

- the next question is networking. I would say ISO is "flat" and the 
Internet is distributed. The IANA is not the best solution because IANA 
centralises things and risks. Governments, starting with the USG, European, 
China, India, etc. have expressed their concerns about centralised 
concepts. Afrac was created after concertation meetings over the 
vulnerability of France and of other European countries to the Internet. We 
only followed the US reference document (http://whitehouse.gov/pcipb). It 
partly addressed the list of concerns I gathered when I proposed an ICP-4 
collective document (ICANN/BC) over network e-security after 9/11. This 
should be the real concern of this WG.

What is at stake is that everyone is most probably OK for a green light to 
ISO 639-3. But with some provisions. One is that what belongs to ISO 639-4 
in ISO 639-3 is removed (Peter pasted some paragraphs in both). Another one 
is that things stay consistent and defined by ISO 639-4. This means that 
ISO 639-3 and ISO 639-6 are treated equal, each in its area. Giving  green 
light to ISO 639-3 would permit to address the needs Peter fights for years 
(but no one wants this way to give away the languages market to Microsoft). 
It would also permit to gain experience with a much larger list and non 
written languages. It would decrease the pressure from the text oriented 
people and permit a better work on ISO 639-6. This is to be discussed in 
Varsaw in August. The best would be that Peter "loses" ISO 639-4 (one year 
delay to work) but gets a lean ISO 639-3 everyone could use immediately in 
a descriptive manner.

The Internet (and therefore this WG) shares the two needs: a descriptive 
tag and a linguistic metamodel: ISO 639-3 and ISO 639-6. The best way would 
be to:

- decide to use the ISO tables, but with the possibility to extend them 
(this is the purpose of the RFC 3066 Registry)
- to acknowledge the principles of ISO 639-4 within an ISO 11179 framework, 
but with the possibility to adapt to networking and multilingualism (not 
addressed by ISO 11179 yet). ISO/AFRAC priorities are: multilingual, 
multimodal, multimedia, multitechnology, multitude of users implications. 
These should be this WG concerns.
- to share in the ISO metamodel evolution.
- to apply that metamodel in identification (Draf), application (XML, CLDR) 
and protocols solutions

> > So W3C and Unicode people can have their classification now.
>
>The Unicode consortium is interested in funny 3066bis language
>tags ?

Did you read the Charter? Please read about the CLDR is: 
http://www.unicode.org/cldr/

These funny tags are supposed to permit to classify languages related 
issues. The limited subtag number and capacity will make dominant 
solution/product associated to the langtags in people's mind. Both ways. 
These funny 3066 bis language tags are worth more gold than the funny 
domain names. Except that DNs gold comes from their number, while langtags' 
one come from their limited number. The same people fight over 
"mercedes.com" the same they do not know how to register "gsw" and rushed 
for Chinese languages. Adding my referent and context (style) subtags would 
make them unlimited. User flexibility for all is often an commercial "waste".

>Sometimes when you talk about UN, OECD, ITU-T, and what
>else I think you overestimate the relevance of the IETF and its
>language tags.

I underestimated the relevance of our RFC 920 consensus when listing the 
constraints of our naming system.... I learned that the hysteresis of the 
Internet brainware (common ways of use) is very long.

>  It will be more than one decade until the last
>3066-application dies, billions of documents will never use a
>language tag, other billions use 3066 tags, and it will take
>some time before 3066bis is more relevant than say DC.

No one really cares about RFC 3066 (bis) oddities. They care about the term 
"RFC 3066" in documents all over the place. Because it permits to rule many 
things one shot. Let be candid: most probably non one will really use RFC 
3066 bis tags, because they will soon be overcome by ISO 639-6/ISO 11179 
compliant RFC 3066 ter tags. These will be supported by CRC access grids. 
We work on that. But if this Draft is presented as BCP 47 iy will create 
confusion and delays. Otherwise it could speed up the process.

> > removing its desire to replace BCP 47
>
>That's something you should really discuss with Brian, I never
>got an answer when I asked here why 3066bis can't return to
>the normal standards track.  [ But I forwarded an info from
>Carl Malamud to Addison how "intended status BCP" could be
>done with xml2rfc. ]
>
>This "BCP" and "experimental" stuff is apparently an easy way
>to bypass community review.  But Brian proposed "two-step", so
>you might run into a wall there.

This was the community response to the Last Calls. "do what you want except 
becoming BCP 47". This is where the two documents idea come from: (1) a 
lean, simpler, clearer, scalable revision of RFC 3066 as an information 
framework (2) the Draft as a standard track RFC within the framework of 
that new BCP 47. This is not what the authors wanted. Should John Klensin's 
propositions have not been called "odious" by the authors, the Draft would 
have been published a long ago - as a standard track RFC.

> > (this what Debbie Garside, says)
>
>I've never heard her say "wait for 639-6".  IIRC Randy asked
>whether waiting for 639-3 could be a good idea, but a majority
>didn't want to wait.  We have reserved 4ALPHA for ISO 639-6.

see above.

> > trusting the ISO process
>
>When I have my doubts about the IETF process it doesn't mean
>that I trust ISO more.  Only the IETF can fix RfC 3066 / BCP 47
>- it's their (= in theory "our") document.

see above.

> > which rebuilds the world instead of patching an XML need
>
>See ?  There's no "rebuilding the world" here, we're talking
>about simple language tags and a somewhat inadequate RfC 3066.

True. But the claim to be BCP 47 makes it rebuilding the world. Just 
removing a sentence ("replacing RFC 3066") changes everything and gets the 
Draft a universal support (including mine). I first explained than around 
December 28, 2004 I suppose. And repeated ever since.

> > Anyway IETF goes by the rule, not by the persons.
>
>In theory.  In practice the best you'll get is that they try
>it, and the worst is that they pretend it.  Everywhere.

The only IETF legitimacy is there. If we do not go by the rules, everyone 
and every language equal, we lose all our interest. This is why the 
attitude of Michael Everson over the 15 days delays would dramatically hurt 
the image of the whole process should his list not be private.

If the deliverable of this WG is not perceived as a consensus, no one will 
take it seriously except among "developers", increasing the 
misunderstanding between them and "users". This means delays and costs, and 
at the end a commercial waste: users will be the winners, all the more than 
now they can develop and standardise by themsleves and that 70% of the 
people and Govs money is here to help.

Cheers.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru