Subject: [Ltru] review of the day.

From: Jefsey Morfin <[email-masked]>
Date: Sat, 18 Jun 2005 02:57:31 +0200

At 20:21 17/06/2005, Addison Phillips wrote:
>Oh Mighty Co-Chairs: dare I broach the subject of a Last Call and how we 
>reach that?

Before that there must be the debate on the WG-ltru Charter. I recall that 
I committed to produce my own Draft within 2 weeks after the end of that 
debate. I removed myself from the WG-ltru seeing that its would lead 
nowhere but to contention (as a remark of Addison on another list shown it) 
as long as we would not have discussed and agreed on a common and involved 
reading of the Charter.

NB. I submit from several face to face meetings and  from a substantial 
number of mail exchanges with members of this list and people waiting for 
the debate on the "thorny points of the Charter", there is _no_ observed 
consensus of the target of this WG. I submit that there is however the 
possibility to find an agreement between the two prevailing positions which 
are:

- to impose to the whole internet as BCP 47, the complex increase of rules 
of Draft 3066 bis, non ISO conformant (I quote positions over OSI 11179) 
non scalable solution (quotes a plenty)
- to fully permit that solution in its own area (XML/HTML/CLDR 
classification) through a dedicated RFC in line with fulfillment of the 
Charter requirements through a scalable simplification of RFC 3066, based 
upon the acquired experience, RFC 1958 guidelines and a correlation with 
the ISO equivalent works and registry extensibility doctrine.

At 01:56 16/06/2005, Randy Presuhn wrote
   RFC 3934 is clearly in terms of giving authority to working group chairs.
>In the case of [email-masked], there isn't a working group chair
>per se.  Thus RFC 3934 wouldn't be applicable unless we were to
>add language saying we wanted it to apply.  To make it work, we'd need
>to identify who, for purposes of that process, would fulfill the role normally
>taken on by a WG chair.

And by the AD.

At 15:49 17/06/2005, Doug Ewell wrote:
>Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
> > As an observer of the [email-masked] mailing list, it seems
> > to me that the registry draft might benefit from an explicit statement
> > about the applicability of RFC 3683 or some other means of maintaining
> > order on that mailing list.  Using RFC 3683 itself seems too
> > heavyweight, but RFC 3934 is formulated in terms of working groups.
> >
> > Separate from the language tag reviewer, would it make sense to
> > appoint the administrator of the [email-masked] mailing list,
> > and to empower the administrator to fulfil the role of "WG chair"
> > *solely* for the purpose of carrying out the procedures of RFC 3934
> > for that mailing list?
> >
> > Would it make more sense to lift the appropriate paragraphs from 3934,
> > substituting phrases to fit the ietf-languages situation?
> >
> > Or should we just leave things as they are?
>
>The current administrator of that list has, of course, just exercised
>something comparable to RFC 3934, while acknowledging that it was a
>personal list-owner's right and not provided in RFC 3934.

The problem Harald faced was that I say that [email-masked] 
is not the mailing list documented by RFC 3066, is not operated by IANA, 
does not benefit from the exposure of a IANA list, does not respect the RFC 
3066 procedure, a place full of ad hominems (*) and foul language. At the 
occasion of a specific problem and of its implications, he saw that my 
support was gaining momentum. To stop me his only solution was to confirm 
my position; acknowledging that this list was a personal list, where the 
RFC 3934 procedure is not respected, and appeals ignored.

I will not appeal to IESG/IAB but I will use this to document that:
1. the [email-masked] isto be a IANA organized and chaired list to 
help the Examiner(s) chosen by IESG
2. the rules of the IANA/IETF/ICANN MoU apply to it - including appeal to 
the IESG and IAB
3. reach out of that list benefits from the adequate exposure on the IANA site.

(*) ad hominems show that this list is not an IETF list:
On 14:52 17/06/2005, Brian E Carpenter said:
>>I thought that ad hominem attacks were considered unacceptable on this list?
>On any IETF list, actually. It's best all round if people remain
>professional and polite, however strong the disagreement.

>It might not be a bad idea to include a short statement to the effect
>that the list administrator has authority to maintain order, and lift an
>appropriate passage, or maybe a reference to RFC 3934 together with a
>clarification that it is expressly being applied to a non-WG list.

Its administrator is the IANA. The IANA is to decide the rules.

At 22:01 17/06/2005, Frank Ellermann wrote:
>No problem if the list owner wants it, but it's tricky:  Who
>appoints the moderator, what if the list owner doesn't agree,
>where's the appeal and recall procedure, can the tag reviewer
>also be the moderator, etc. ad nauseam.

ad nauseam seems to be a true characterisation.
The capacity to remove the Chair must also be granted.

<quote MoU>
4.5. ... For protocols within the IETF scope (i.e., registries created by 
IETF action), appeals against such denials may be made to the IESG and 
subsequently to the IAB as provided in 4.2 above.
</quote>

I take this occasion to recall to the Chair  of this WG the subsequent part 
of the agreement:

<quote>
4.6. The IANA shall have non-voting liaison seats on appropriate IETF 
committees as determined by the IETF, and may participate in all IETF 
discussions concerning technical requirements for protocol parameter 
assignment through such liaisons.
4.7. The IANA shall review all documents in IETF Last Call to identify any 
issues of concern to the IANA, and shall raise these issues with the IESG.
</quote>
At the end of the day this means Doug Barton participating to the work of 
this WG. I suggested several time it was the role of the Chairs to discuss 
with him if we could not speed up the process in inviting him.
,
>Maybe it's simpler to solve these problems generally for all
>review lists, add them to the general area and let the Chair
>pro forma appoint the list owner as listmom.

No. This situation is ruled by RFC 2860.

>Randy's plan B "Or should we just leave things as they are?" is attractive.

No. Because I am going to use my "banning from a IANA list exercised by a 
private person without the protection of RFC 3934 rules nor the appeal 
capacity of RFC 2860" to oppose the Draft 3066 bis.

The propositions I made above are probably good enough.

>There can be conflict only for old libraries using new applications. But 
>the old libraries do not support the new features. So if I want to use the 
>new features I need the new libaries.
>
>I have another way to address the need: to register in the applications 
>registry one tag per language and per comment: 7500 * comment nr. With ISO 
>639-6 20.000 * comment nr. This may quickly make billions of entries. All 
>this just to stay compatible with a non used experimental format?
>F. Charles.

You do not necessarily need to do that. I suggest you use the x-tags format 
x-6aaaabbb.

- x-6 is a prefix for ISO 639-6 codes.
- aaaa is an ISO 639-6 cod
- bbb is a comment code. You can register nearly 40000 of them (that anyone 
car read in his own langage)
- aaaa being a concept, you can use bbb as container of the associate 
values by a referent following an ISO 11179 logic: this way you can link 
many many things, while keeping your page crispy.

This way you stay conform to the old experimental RFC 1776 they want to 
respect - even if this Draft passed you are all correct.

jfc

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

---

From: [email-masked]
Date: Sat, 18 Jun 2005 14:24:19 -0700 (PDT)

> At 11:03 18/06/2005, r&d afrac wrote:
> > Oh Mighty Co-Chairs: dare I broach the subject of a Last Call and how
we reach that?
>
> Before that there must be the debate on the WG-ltru Charter!

May be should it start on [email-masked] and continue here? The response
I did not get show you need more than a mail to be heard.

> You do not necessarily need to do that. I suggest you use the x-tags
format x-6aaaabbb we are discussing at AFRAC.

This is a possibility. But I prefer mine, because "comment" in
"x-fr.comment-sn" is free. Will you support it on your own Draft?
F. Charles

---

From: r&d afrac <[email-masked]>
Date: Mon, 20 Jun 2005 08:59:36 +0200

[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/[email-masked]>
>   [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 
"[email-masked]" 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

---

From: "Peter Constable" <[email-masked]>
Date: Mon, 20 Jun 2005 13:29:30 -0700

> From: r&d afrac [mailto:[email-masked]]

> >A consensus does not require unanimity; it only requires an attempt
at
> >unanimity that results in at least a solid majority, which we have...
 
> IETF goes by rough consensus.

That is the point I wished to make. That is all that is relevant on this
matter for purposes of this WG.

> Who are the Chaires of the Internet WG associated to ISO
> 639-1 and ISO 639-2, as listed by TC 37?
> No similar relationship of ISO 639-3 to the business environment?

I'm not sure precisely what you by "the Internet WG". There is no
liaison relationship between IETF or any other Internet governing agency
and either ISO/TC 37 or ISO/TC 37/SC 2.

Peter Constable