Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Apr 2005 08:26:07 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> 2. mixed feelings among English culture Members, where confusion
> results from the bundling of various questions in a single one "do you
> support Jefsey's non detailed provision".

Speaking only for myself, I wasn't confused at all.  Randy's blanket
term, "Jefsey's provisos," was sufficiently vague that I had to actually
go back and read the post(s) in question, which I had skimmed over
before.  After reading them, I clearly understood Jefsey's various
suggestions, and was confident of my opposition to them.

Partitioning the group into "French culture Members" and "English
culture Members" and pitting the two against each other is not how I
thought consensus was built within Working Groups, but I could easily be
wrong here.  I don't have 27 years of Internet experience to draw on.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Apr 2005 08:30:12 -0700

John Cowan <jcowan at reutershealth dot com> wrote:

> A language tag generator UI, therefore, should have two modes, normal
> script mode and unusual script mode.  In normal script mode, only the
> scripts in Associated_Script should be offered to the user (and if
> there is no such header, then no scripts should be offered).  In
> unusual script mode, every script should be offered.
>
> (Hint, hint, Doug.)

Interesting thought.

-Doug Ewell
 Fullerton, California

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 14 Apr 2005 01:46:46 +0200

>suggestions, and was confident of my opposition to them.

you increase the problem rather than clarifiy it. What you oppose is my 
bundled personal positions (plural). Not different questions (each 
singular). But may be this is a normal way of thinking in this group, since 
the main problem it faces is of same nature: the bundling of XML parameters.

>Partitioning the group into "French culture Members" and "English culture 
>Members"

See below.

>and pitting the two against each other is not how I thought consensus was 
>built within Working Groups, but I could easily be wrong here.

I feel the term "pitting" out of context.

>  I don't have 27 years of Internet experience to draw on.

True. But this experience shown me that intelligence may replace it 
advantageously.

BTW these different comments lead to realise how much one of the things 
which suprises non-English culture people on this kind of lists is the 
rudeness of people who are most probably very polite in normal life. I 
suppose this is part of the consensus undercovering in these IETF related 
Working Groups?

Some IETF participants make a very common error using the formula 
"consensus building", which by essence has no meaning. This may result from 
the different motivations of people in participating in the IETF 
interestingly discussed on the main list rigth now. This seems to actually 
mean "to build a proposition" that "rough consensus rules" will permit to 
impose to the WG to obtain the publication of a document. By essence this 
is a Pyrhus victory, and the main reason why every RFC do not make a standard.

By nature a consensus is something which pre-exists, otherwise it is a 
compromise or a trap. The difficulty is to discover it as it is hidden 
behind many conditions ("we are in agreement if you we agree on something 
else before" - governing by consensus is to make fulfil these condition so 
the consensus may survive). The reason why we need consensuses is it is the 
best hope we have that what is true in a WG will also be true in the real 
world. The reason why we are not interested in compromise, votes, 
positions, etc. is that they only concern the group which discusses them 
and not the real world.

Here we have two consensuses (which is a normal possibility). One is clear 
and supported by determined and able people (the position of this WG will 
not affect the real world deployment and the plans we work on). The other 
is confuse and contradictory (it makes the registry empty since ISO 639-3 
uses reference names which by essence are not of a language, therefore not 
English. And even if you twisted the text of the  "consensus" in accepting 
ISO 639-3 reference names of English origin, the autonyms should stay 
blocked .... these people refusing "1000" languages, forgetting that ISO 
639-3 uses probably more than 1000 languages ...

So, we can only say from this that two opposing consensus emerged. These 
two consensus seem to be supported (a) by what seems to be an extended 
anglo-saxon culture group, (b) by a non-extended-anglo-saxon culture. The 
limited number of participants in (b) does not make it clear if that 
culture is limited to one single individual, extended to the cultures of 
the various authoritative entities he is related to. The response will be 
possibly observed during the Last Call, etc. , the IANA implementation and 
the MRP (market real practices).

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Apr 2005 04:01:25 +0200

JFC (Jefsey) Morfin wrote:

> supported (a) by what seems to  be an extended anglo-saxon
> culture group, (b) by a non-extended-anglo-saxon culture.

Ground control to major Jefsey, are you talking about Randy's
5.49 : 3.51 decision ?  None of these nine people represents
any culture, they just have different _technical_ reasons to
want more or less info in the registry.  Among these reasons
are the size of the registry, the problems for the tag review
procedure, the "ugliness" of too many NCRs in the registry,
and the bogosity of adding Féroé to Faroe if the real (native)
name is Føroyar (maybe).
                           Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 14 Apr 2005 11:50:32 +0200

>and the bogosity of adding Féroé to Faroe if the real (native)

Dear Frank,
we obviously are not here for the fun. But for the technical, political, 
economical and societal implications every IETF standard and procedure has. 
IETF has made the choice of having no market study/review prior its 
publications and to wait for the market inputs before making an RFC a 
standard. This has lead some technical, political, economical and societal 
interests to join the IETF to use its RFC mechanism to try to influence the 
market in its favor. This is precisely right now under debate on the main 
list between the Chair and Members from various types of organizations - 
including non-profits like me - and individual dedicated voluntaries like 
you (from what you explained). This creates a problem between people who 
are paid and have time and people who pay and have far less.

The diversity of their cultures and interests is precisely what permits the 
IETF to propose valuable documents and acknowledge de facto standard 
resulting from these documents. There are cases where the same need is 
addressed by different solutions due to the impossibility to find a common 
background between two positions.

I think we have fully demonstrated that in this case. As you indicate there 
are 9 persons on side, attracting no more (*). There is one opponent 
because no one in the real world seem to accept that what these nine 
people  propose makes enough sense to worry about. Let get real, if I am 
the only opponent here it is because I probably am the only opponent who 
instead of shrugging shoulders, acknowledge the real need expressed by Addison.

(*) we could obviously call upon number like in the MARID case. What would 
be the interest?

We could also evaluate who is for that among paid and paying members 
communities. This is usually a good way to evaluate what is of medium and 
what is of long range interest to the users. Commercial interest run market 
studies and if they are big enough will impact the market anyway. NonCom 
have usually the liberty of the vision and the determination which "makes 
it happen". They have not the immediate time - but they have the long term 
time.

In this case we have two opposed interests. People wanting to patch XML, 
proceed with CLDR like plans, possibly sell their work and expertise 
through ISO and similar channels. These are good and legitimate interests. 
But they conflict - and will not defeat - with the fact that a Multilingal 
Internet is not an "Internationalized confusion" but based  needs to be 
based upon a clear, stable, user acceptable/ed, network architecture 
integrated identification of the languages parameters. As long as they want 
to lead the game, instead of serving it because they are as every other 
frustrated by the (partly voluntary) lack of understanding of IESG/IETF, 
they will not go through and are wasting time for their totally legitimate 
need.

IRT the practicalities you talk about, you should consider them in the 
broader perspective of true relation assistance services (or extended 
services) and economy. But this is another internet architectural aspect, 
parallel in need and similar to multilingualism (cf. OPES which, IMHO, are 
mudded by the problem as this WG).
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Apr 2005 02:22:41 +0200

JFC (Jefsey) Morfin wrote:

> we obviously are not here for the fun.

I'm here because I didn't like the "country code" rules and
effects in draft 9 and said so in the "last call".  If I don't
like it but have an idea how to fix it, now is my chance.

Anything else are simply side-effects of this POV, trivial ABNF
quirks, normative vs. informative references, STRONGLY, etc.

> But for the technical, political, economical and societal
> implications every IETF standard and procedure has.

The registry will be essentially a frozen summary of four ISO
standards (3166-1, 639-1/2, scripts), some grandfathered tags,
and some UN numbers where ISO 3166-1 doesn't work as expected.

Plus some simple rules to use these subtags in a combined tag.
Any additional info in the source standards isn't lost only
because it's not copied to the language tag registry.  You're
still free to use the sources as they are, e.g. Bruce's draft
about scripts uses the ISO source.

And you're free to use whatever source you like to find the
French name for Faroe.  The registry is about language tags,
it's no all purpose dictionary.  Descriptions ought to be the
minimal "i-default" text we can get away with, but no headache
for a poor tag reviewer.

If you love headaches, the "default_script" is bad enough, but
unfortunately necessary to address some compatibility issues.

Losing regions under the current rules is also bad, I hope to
discuss this here again _after_ the default script problem was
solved in draft -01.

But for the French name of Faroe I really don't care.  It's no
_technical_ problem for users, implementors, or taggers.  From
your POV it might be important, but solving it for you is no
option, French is only one of many languages, and obviously we
can't put descriptions in many languages in the LTRU registry.

If you want a dictionary of language / script / region names
just create it.  IMHO it's unnecessary, dictionaries already
exist.  Here are two utter dubious Google translations:

http://purl.net/net/en2fr/users.adelphia.net/~dewell/lstreg.html
http://purl.net/net/en2de/users.adelphia.net/~dewell/lstreg.html

                          Bye, Frank