Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents

[r&d afrac <[e-mail]>]

At 06:39 08/09/2005, John C Klensin wrote:
>Jefsey,
>Somewhat against my better judgment, I want to respond to a few
>of your remarks in the context of what I said and meant and what
>I think the LTRU work, as a collection of IETF documents and an
>IETF/IANA registry, sets out to do.

Dear John,
Since you ask I will respond in detail. With two liminary remarks:

- what should be discussed is not what you or I may _think_ , but 
what this collection of proposed document may lead to or block. 
Technically, operationally, politically, economically, culturally.
- obviously I would drop most of the points I rise here if the 
document became a standard proposition instead of a BCP and/or if the 
"0-" was supported. That position did not change of a iota since 
mid-december, but was improved by the IESG registration of the 
URI-tags RFC and by the Draft ABNF clarifications obtained at the WG-ltru.

>I believe that you are getting several different issues badly
>intermixed, confusing your readers and possibly even yourself.

By what they address, by the exclusive they claim, the langtags are a 
key part of an internationalisation of the Internet.

I oppose internationalisation of Internet as inadequate. It consists 
in permitting the use of languages by "end users" (an unknown concept 
to IETF), under constraints such as those described by Addison, as 
optional add-on to the ASCII Internet, with English as a default of 
these options. We technically and politically experimented what this 
vision leads to in the IDNA case.

I support a Multilingual Internet providing a multilateral, 
multimodal, multitechnology convergent networking architecture for 
the world digital ecosystem, on an equal linguistic research, 
standardisation, development and usage basis. By nature that Internet 
is "multi" when the legacy Internet is "mono". The point is simple: 
"internationalisation will NOT address the multilingual demand and 
the further vernacularisation needs".

To cope with multilingualism and with many other necessities we need 
to turn architectural parameters from "mono" to "multi". The single 
TCP/IP protocol suite, the single end to end interoperability, the 
single RIR addressing system, the single ICANN naming system, the 
single IANA clearing house, the single English language, the single 
ASCII set, etc. cannot deliver the expected (or already used) 
answers. All over embryonic "multi" are pouring (NATs, P2P, 
alt-roots, PADs, now mDNS and co, blackboxes, etc.)

I know IAB guidance is missing. I know there is no model. I know the 
changes "intermix" everything. I know opposing pro status quo 
commercial interests are powerful. I know Governments are demanding 
and clumsy. I know the Internet geeks never changed technology yet. I 
know the Internet is nearly a billion people wide. But hiding the 
problem and trying to squeeze a global architectural revamp in the 
narrowing (patching?) of an inadequate RFC, IS confusing.

The urgent need is to think hard, to understand and test in what 
directions a "multi-Internet" may go and to permit, document and 
accompany a smooth transition. Multilingualism is one of the main 
aspects, so it can be used for real life testing at low risk.This is 
what I tried:

- having investigated and tested some of the trends of this 
evolution, in line with ICANN suggestions, and other involved leading entities.
- using the WG-ltru opposition for "mono-Internet" ABNF reducing 
confusion risks (and possibilities) - as well described by Addison.
- introducing a "multi-Internet" approach permitting a smooth 
transition based on a mechanism already accepted as an RFC (URI-tags 
- that should need to be documented as IRI-tags).

>Well, I think there may be more than four "propositions", if I
>understand what you intend by that term, but let me return to
>that question below.

Great! Why not to introduce them? are they already supported by an RFC?
Anyway, they all are blocked by the Draft ABNF. Unless we use "0-", 
"1-" etc. for each of them?

>It seems to me that the draft is nothing more or less than a way
>to structure elements of several different base systems into a
>very general language/ script/ location identification system.

"seems" is imprecise. It is or it is not.
In fact it is not.

- it does not want to be "a way", but the internet standard practice. 
Here is the blocking point.
- you know better than to say it is a "general 
language/script/location identification system"!. It is a very 
restrictive limited in scope coding system, correlating ISO codes in 
a way ISO has not accepted, impeaching other correlations which might 
be more adequate and complete, competing instead of cooperating, 
supporting no other modal information than an imprecise (*) script 
code and an inadequate "location" (**) identification.

(*) ISO 15924 is only a list of one hundred codes which can be 
associated to a script concept. More indications on the meaning are 
needed. If Charset is Latin and the langtag says "Cyrl" how will the 
page print?

(**) "location" is not the meaning of RFC 1591, the only place in the 
Internet documents where the concerned codes are used up to now. Jon 
Postel considered local internet communities' authority. This 
document not. Other times, other ways.

>Those base systems have UN, ISO, and UTC origins.  To the extent
>to which you find reasons to disagree with what those bodies
>have put in their standards and registries and how they have
>structured those registries, it seems to me that you should be
>taking it up with them, in their contexts.

??? !!!

Had you followed the debate of this WG-ltru you would know I have 
been denied the quote of the very terms and restrictions these 
authorities use when publishing the used data. These data are NOT 
used in the way they are intended to. This does not mean that they 
cannot, but that an appropriate language is to be provided to 
document it. The WG shown that such a language might lead to 
technical conflicts and alight other lacks.

Why not the Editor simply include the appropriate legal mentions? Why 
not to consider the current debate over ISO 639-4 (ISO 639 guide 
lines). Why not to quote and consider ISO 639-4, 5, 6 drafts, the 
same as this Draft is part of the ISO 639 debate and annexes. I am 
surprised by what could be considered as a cross-contribution loop. I 
am also surprised by your suggestion: would IETF documents have to be 
discussed at ISO?

All the more than I made clear enough that I share in common 
interests efforts. And that I accepted to dedicate time to the lack 
of concern of the WG-ltru for language networking issues. I did not 
think appropriate to involve other people in the WG-ltru rough 
waters. One academic friend tried very politely - he is at the origin 
of the "0-" proposition. He was named a "troll". Do not be afraid if 
I am the one to tell the reality in here (you saw competition wants 
to expel me for that), I always said I represent users interests. My 
architectural vision is user-centric, so I cannot do otherwise. But 
this does not mean than I am alone :-) and only involved in here. But 
a job had to be done: to expose a wrong approach. This is now made.

It only means that I am very respectful of the IETF ways and that I 
think that it is still the best entity to document the 
"multi-Internet". But if the IESG/IETF/IAB says "no" at the end of 
the day, this will obviously not stop the multilingual global NGN to 
develop without them. But I would be sad.

>A second issue is why those particular base systems have been
>chosen rather than others that would accomplish the same
>purposes.  While the WG has better reasons (some of which are
>identified in the LTRU-registry draft), the bottom line is that
>no other systems exist that are global in character, accepted
>internationally by recognized bodies, and generally plausible.

As I documented it, this comment is out of scope.
1. the problem is not with the use of these code, the problem is with 
the way they are used.
2. this problem would not be a big problem if a PS (an inadequate 
tagging would confuse and cost the world because of its initial 
sponsors, but would  soon fade away). The problem is with the BCP 
nature of the document which leaves no choice: accept or balkanise 
(you document this further on).
3. I leave you the responsibility of your review of existing propositions.

My opposition is only to avoid a general balkanisation. But after 
all, may be I am a fool and there might be some advantages. And you 
seem to advocate it...

>You, or for that matter I, might well imagine that a
>better-optimized job could be done for one or more of them if an
>effort were initiated under different assumptions, but to sit
>around waiting for such an effort to materialize or reach
>agreement would delay the real work of internationalization that
>we both believe are important.

What do you mean by "to sit around waiting"?  when our such effort is 
only delayed by the Draft time wasting. This is necessary because 
this is a pure _commercial_ exclusion effort. Do you think that 
financial aspects are not involved? I never hidden I was also 
supported by industrial interests fighting and fought by industrial 
interests. Harald Alvestrand and Peter Constable fully documented 
that central motivation. I will not betray some of my opponents, but 
no one should be fooled: this debate is worth "a lot of money for 
industry". This is something we all agree, we only disagree for who - 
some consider they lost what other consider they saved. I strongly 
_oppose_ this kind of interference in the IETF.

This absurd attempt to commercial exclusive, on "mono-Internet" 
pseudo technical interest grounds, have made us all to lose a full 
year (except getting a cleaner ABNF for that proposition and an RFC 
to support the URI-tags solution).

Our common target is stability, surety, security, innovation 
capability in supported end to end interoperability and serviced 
brain to brain interintelligibility whatever the person, the 
computer, the location, the language. This byte and language oriented 
pervasiveness cannot be supported by what you call 
"internationalisation" (I would call lower layer localisation). You 
say it yourself  when you say that the "real work of 
internationalisation" is ahead. If the Draft is accepted without the 
"0-" hook for IRI-tags that work will be a no-starter.

The proposition is painting on old rust. That we both want the 
painting. But believing we can keep the rust and get a proper 
painting is illusory and a waste of time. But, we may proceed step by 
step. Not remove all the rust and repaint everywhere at the same 
time. Let start with the IRI-langtags. Let get experience (not only 
for multilingualisation) and let build on it.

What is the danger? If I am wrong, it will simply not fly and no 
commercial interest will have been hurt. But if I am right we will 
have protected the Internet unity.

>  Of course, I, and the WG, could
>have missed something: if you sincerely believe that there is a
>better alternative to one of those base systems -- an
>alternative that exists, is global in scope, is generally
>recognized by some appropriate international body, and that is
>generally available-- please identify it and the reasons why you
>think it is superior.

I can only repeat:

1. I sincerely believe there always is a better alternative than exclusion
2. I sincerely believe that inclusiveness is by nature global in scope
3. I submit that the proven experience of a product like Words 
documenting more elements than the tag is to consider
4. I cannot leak IPR but I am sincerely sure that the "mono-Internet" 
exclusive Draft ABNF preventing "0-" is a _major_ mistake.
etc.

and I will always say that NO solution is superior to any others, but 
that specific solutions can be more appropriate in specific cases and 
that is dumb stupid to exclude them on short-sighted commercial 
grounds or technical limitations. Technical limitations are made to 
be addressed.

>A third issue relates to the difference between breaking things
>into categories in order to make lists and the codes, names, or
>labels that are assigned to those categories.  The making of the
>lists is what the relevant based standards are all about.  It is
>typically a difficult task, but it is one for which IETF cannot
>and should not take responsibility (as I hope I have explained
>above).

I am not sure about what you want to say here. This Draft is about 
IETF taking that kind of responsibility. Unless you intend to say the 
IETF delegates the [e-mail] responsibility of 
feeding the IANA, in an equivalent way it delegated the names and 
numbers responsibility to ICANN?

>  But the assignment of codes/ names/ labels to those
>categories is largely arbitrary.  There can be good reasons for
>preferring one system over another, especially in the
>environment of particular assumed applications (or
>"propositions"), and I need to assume that the UN, ISO, and UTC
>have made rational choices.

I am not sure about what you wants to say here either, nor why you 
want to keep quoting the UTC?

What are the UN and ISO to do with this? The rational is not with 
them, but with this Draft to use their codes for needs which were no 
part of their rational. Please pick ISO 639-4 draft and tell me among 
the examples of usage of ISO 639 where ISO 639-4 alludes to 
networking. Please tell me in which way the table of codes related to 
the name of countries may be easily correlated with human language 
dissemination? With human language censoring may be ....

???

>  But substituting a different set of
>codes doesn't change the semantics of the underlying base
>system.  So, if you are looking for a different set of codings/
>names --I don't think you are, but I can't be sure-- I think you
>need a really clear and compelling argument for why the existing
>ones are generally inappropriate and a clear and easily-realized
>proposal for generating a substitute list of codes and mappings.

John investigating the same erroneous issues will lead to nowhere.

- this Draft does not respond an IETF Charter but pursues a business strategy
- in so doing it tries to use the IESG and IANA to exclude competition
- this results from reasons well identified by IAB in RFC 3869. With 
the very provisions discussed by IAB that such a motivations do not 
preclude partial good. But must be replaced by non-commercial 
funding. This is exactly what I am: non profit and building public projects.

I happen to know better about the risks involved because that 
business strategy wants to commercially lock a market that (with many 
others of influence, this debate also helped to gather) I want to 
keep free for longer term common and commercial interests. The 
magnitude of the economical, political, technical, legal and societal 
involved interests and the probable consequences on the control of 
the Internet (due to the load on the IANA and the complexity of the 
involved information - and competition) is such that, should the 
Draft be approved without supporting the IRI-langtags space it would 
either be not applied (leading to delays and confusion) or be opposed 
in a way which would probably balkanise and disband the Internet as 
we know it.

I only try to prevent this from happening. I may very poor at that, I 
would then apologise and call for help.
But, opposing me if I am right is burying the Internet or 
transferring its control (what I believe is attempted).

> > A two minutes consideration of the difference between the way
> > Shakespeare wrote a page and the way you store, distribute and
> > read it today, may give you some hints about the difference
> > between what the Draft wants to do and what the IETF needs.
> > The Draft drastically extends the basic error of the lose RFC
> > 3066 (rigidifying orthogonal language/country information) and
> > wants to see it enforced and made universal.
>
>I see no statement in the draft that would justify the claim of
>wanting or expecting "enforcement".  What I think I do see is a
>wide range of applications that might reasonably take advantage
>of some language and/or script and/or locality and/or "other
>things" coding and identification system.  I imagine the range
>to be broader than the examples you list as "propositions".   I
>am quite certain, philosophically rather than analytically and
>with examples, that the registration system and matching rules,
>as proposed, are too specific or overspecified for some
>plausible uses.  I am equally certain that they are
>insufficiently specific for some other uses that might be
>imagined.
>
>But that is precisely what voluntary standards are all about.
>No one I know is really trying to mandate use of the technique
>specified in these documents and, if there is someone, he or she
>is delusional.

What are you talking about?
This document is the updated of BCP 47 Internet standardized practice.

>I believe that the IETF should be specific, _for
>protocols and other work within IETF's scope_, about whether the
>LTRU work should be used and how it should be used.  If you have
>other applications that could use this work,

John, many people have applications this work is to prevent the use !!!

I do not understand all this. Or you did not read the ABNF?

No one can de facto introduce a global proposition.
- either it must be part of a future revision of a document which 
wants to be a narrowing of RFC 3066
- or it must use subtags shorter or equal to 8 alphanum, without 
possibility to use "-:=?/" etc. So no URI-tags are permitted.
- or it is a language, script, region it must be accepted by 
[e-mail]
- if it is vocal, style, dictionary, contextual, cultural, etc. etc. 
this is not supported.

>and the work is appropriate, that is great: use it with everyone's 
>blessings. If you have applications (or propositions) for which this work
>is just wrong, then go do something else, I assume again with 
>everyone's blessings.

I am not sure you mean by do something else? Would it be like "If 
someone sleeps with your wife, don't worry go do sleep with someone 
else?" Many do _not_ and will _not_ want to be dependent on this Draft. Period.

There are only two solutions. Either the langtag can adopt formats 
they can tune or they will be blocked.
Just understand that langtags may be more dangerous than spam or 
cookies. So at last users must be entitled to control them and to use 
them far more cleverly than the default way the Draft proposes !!!

Opposing this is certainly being sure to kill a few people. We all know that.
Just to support very very short sighted non realistic commercial dreams.

> > A content container should at least document if the language
> > description is from the author, to the reader or for the
> > protocol. It should the document seven properties (language,
> > mode, community, referent, context, style, media) and the
> > property description version. Your own Words program just does
> > that. Each of these elements may include many sub-elements.
>
>Ok.  The LTRU group, presumably with some specific IETF
>applications in mind, including (correctly or not) those
>supported by RFC 3066, concluded either that the level of
>specificity you ask for above was not necessary or that it was
>impractical.

"presumably": you are incorrect in that assumption.
BTW "some specific application" would justify options.
I wish some IETF applications would have been considered :-)
DNS, OPES, Java, etc. have been denied to me.

>For the purposes for which you presumably want
>this, you have two choices, both of which appear to me, in my
>ignorance, to be completely plausible.  The first it to
>completely forget about this IETF effort and do your own thing,
>building on either the LTRU spec or the base documents that
>determine the subtags as you think appropriate.  No one will
>stop you and, if anyone tries, I recommend that you ignore them
>and get on with your work.

This is what I want to prevent. This is no problem.
But the name is balkanisation. Do you support it?
It makes a large difference to me if we have a BCP or a PS.

>The second option is to construct an applicability statement of
>your own, one that specifies the applications or propositions
>that are relevant, the elements of the LTRU registry you want to
>use (if any), the sources of other elements and how they are
>used, and so on.  Whether you should try to put that
>applicability statement through the IETF depends on what the
>application area / proposition is all about: if the IETF is not
>representative of the community you see yourself serving, or
>authoritative about its needs, it seems to me that IETF
>involvement would add little value and probably be very
>frustrating for all concerned.

I wish the IESG to decide that. I maintain that common interest is 
that the Internet documentation stays with the IETF. Or at least that 
the IETF stays as a common focal point. Obviously if the IESG decides 
(and IAB confirms) to exclude the "multi-Internet" starting with the 
Multilingual Internet, I will certainly consider your suggestion. But 
still with great care. Rome was not built in one day, but was burnt 
in one night. We should be very careful at that;

The actual issue is the control of the IANA registry. There are three 
possibilities:

1. the IANA is an exclusive source of langtags.
2. the IANA is one of the sources of the langtags as the IRI-langtags 
are added to the Draft ABNF through the "0-" sequence.
3. the IANA is no more the Internet central clearing house because of 
the distribution of registries.

In the first case, the [e-mail] mailing list will 
become unmanageable and the whole process will be blocked. Leading to 
a decision of authoritative transfer. I then support a transfer to 
the GAC if the WSIS has not taken over.

In the second case, things will continue as per today. There will 
most probably a problem of overload of the IANA and legal issues over 
the nature of the langtags. This will only speed up the need to 
transition to the third solution.

The third case is the eventual solution for a distributed network. It 
still calls for a lot of thinking, experience and work. But can be 
implemented rather quickly now on a test basis with multilingual 
priority. This however represents serious dangers due to the 
commercial competition and political aspects it would exacerbate.

>  > There are three other propositions than status-quo:
> >
> > A. the current Draft using of ISO 639-1, 2, 3 and additional
> > ISO codes. That proposition is based upon the SIL list of 7500
> > documented languages. It is supported by Peter Constable (on
> > the list), author of ISO 639-3.
>
>Ok.  If this has appropriate applications other than those
>covered by the LTRU documents, create an appropriate
>applicability statement.  If necessary, propose a standards
>track document and appropriate IANA registry, but I would assume
>that the ISO 639 registries would be sufficient.

??? This application has the e-commerce, etc. applications it is designed for.
I trust Addison to know what he wants (however he documented he does 
represent W3C positions).

>  > B. Linguasphere (planned to be ISO 639-6). It identifies
> > 20.000 community language 4 letters not reusable codes and is
> > built as ISO 11179 compliant for far more information. They
> > fully replace langtags when no legal aspect is involved. They
> > are planned to be discussed when an ISO standard. It is
> > supported by Debbie Garside (on the list) and Dr. David Dalby.
>
>See above comments about not-yet-complete proposals.  If this
>were to be adopted as an ISO 639 component, the comments above
>would apply exactly.  In the interim, unless you are prepared to
>argue that 3066 is adequate, without fixing the problems that
>LTRU addresses, until the above work is complete and accepted,
>and adequate for _all_ IETF-related language-tagging purposes,
>it seems to me that you should get out of the way of those
>purposes and applications.

This solution is an open source retained solution. This solution is 
appropriate in part to many needs. I am sorry but your "adequate for 
_all_IETF-related language-tagging purpose" is a "mono-Internet" de 
facto deprecated thinking.

As far as I am concerned the Draft addresses none of the RFC 3066 
lacks. It only prevents more applications to use it: this is very 
positive as it clarifies the situation. ISO 639-6 has as much 
interest for IETF as the Draft has interest for ISO 639-4. Except 
that ISO 639-6 reflects a common practice the Draft does not represent.

SIL and Linguasphere are two widely used universally accepted lists. 
SIL is private and limited to a single list. Linguasphere is much 
more complete and ISO 11179 compliant. But they are 
professionally/marketingly of equivalent excellence. The reason why 
Linguasphere is more appealing in terms of use, is that the Draft 
does not uses SIL (ISO 639-3) but a progressive mix of ISO 639-1 and 
ISO 639-2 (the ISO scheduling of -3 and -6 are only a few months apart).

The current thinking of the WG-ltru, if I understand it correctly is 
a confuse usage of ISO 639-6 in an appropriate way as a complement of 
ISO 639-1, 2, 3 and 5. It is likely that routines supporting ISO 
639-6 codes in an open source manner will be available long before 
the Draft support of ISO 639-3 .....

> > C. the "grassroots approach". The approach is to accept in a
> > network and multilingual way everything existing and to relate
> > it to an "ISO 11179" compatible system. Still at basic
> > thinking and experimental stage. This is part of a generalised
> > DRS (distributed registries system) to include every
> > network/local/user registry (including langtag). The URI-tags
> > seem to fully support the network aspects, the IRI-tags the
> > multilingual concept. It obviously support the two systems
> > above which can be its defaults. I accepted to spend time on
> > the representation of  industrial, political and users
> > interests in that area.
>
>See above about systems that are not yet complete and, from what
>I understand of this work, not yet really started.

????
Do not confuse achievement and started. There are millenaries that 
languages have a name. The commercial attempt to standardise the 
printing industry and library classification is not the first, and 
hopefully not the last one.

You probably confuse IRI-langtags which are only a documentation to 
internationally work - probably this falls; and the DRS work which 
has been engaged 2 years ago as an incorporated R&D non-profit effort 
involving various industrial, private, public, etc. French and 
foreign interests. But that work is certainly important (see end).

> > There is no "better" solution. There are more adequate
> > solutions in specific situations (A and B can be defaults of
> > C). Each helping the other to better define itself. However
> > the A proponents think their proposition must be exclusive.
> > They wanted a counter-proposition of mine so the "best" might
> > "win". Their ad-hominems were their way to exclude a
> > "competition". Their non-technical mails on the IETF main list
> > fully exposed that strategy.
>
>I don't think so.  While I think they and I disagree about many
>things, I have generally found them willing to listen and to
>accept constructive input.  There really is a place, in the
>engineering context in which we find ourselves, for deciding
>that, in the presence of a demonstrated problem, a proposal that
>actually exists, and that is structured on top of base documents
>that actually exist, must be accepted in preference to work that
>has not yet completed and ideas that are still being formulated
>-- at least for an identified set of problems and applications
>for which it can be demonstrated to be the solution.

We fully agree. This is why I am sad at the RFC 3869 documented 
motivations many see there and the RFC 3774 documented problems we 
feel we meet.

There is a very simple way to turn us wrong on this two points: to 
accept the "0-" to show the intent is not a registry exclusive and 
that all existing propositions are considered; and to make the Draft 
an SP, to show there was no to intent of exclusion of other propositions.

>  My
>proposal to recast the registry and matching documents into
>Proposed Standards supplemented by one or more Applicability
>Statements should make it more clear that other applications,
>with their own Applicability Statements and scopes, can be
>expected and, if they have different needs, should be able to
>utilize approaches designed to meet those needs.
>
>I believe that approach is structurally and procedurally
>correct.

I agree. The entire issue is here. Even well commercially supported 
an inadequate proposition will eventually fade away.

>  But I also believe it will not help solve the issues
>you are trying to raise and the applications you are trying to
>accommodate, if only because your message, intentionally or not,
>is "just wait until a series of incomplete ideas, some of the
>barely germinated, can fully mature and be considered".  That
>just is not a reasonable request given a number of activities,
>applications, and protocols that need to move forward.

This is _absolutely_not_ what I have asked for !!!

1) I have documented to the contrary how existing development were 
ready to adapt to avoid confusion with the Draft.
2) we generalised our experience and other commercial applications we 
cannot discuss as not being part of them have agreed to use the 
existing URI-tags approved RFC. This is the end of it. Except that we 
will now extend to IRI-tags and have to document an extension.

> > The text proposed in December was not acceptable. The
> > currently proposed text still appears as an "industrial and
> > commercial Trojan Horse" with risks of commercial, political
> > and technical confusion. But its authors have trimmed enough
> > their ABNF "against me" to block "C" leaks there and threfore
> > a lot of confusion. Yet, we have still have no support of
> > non-script mode and three sources of conflicts:
> >
> > - charset of a document vs script.
> > - script of a document in a politically oriented
> > (privacy/racial violation) tag.
> > - lingual community information - what may imply a conflicting
> > language, script and charset - may conflict with langtags.
>
>Once again, if you have applications or situations in which
>these needs are particularly important and for which the LTRU
>documents do not appear responsive, either
>
>* Start work on an applicability statement or profile that will
>make the LTRU tagging system meet your needs for those
>applications.  But, if you want that applicability statement
>discussed in the IETF, please don't waste anyone's time by
>discussing it before you have an Internet-Draft posted.

Once again. This is not what I want.
I want to prevent that all those the draft is designed to prevent to 
do so, do it independently, rising a hell of confusion.
But if you think it is better, I will consider your advise to 
balkanise the Internet.

>* Ignore LTRU entirely, design your own system, and see if you
>can get it into the marketplace well and extensively enough to
>drive LTRU out, either generally or in whatever niches you think
>are most important.  Remember that, if the LTRU is as inadequate
>as you believe, it will disappear on its own, with no need for
>you to push it along.

This is true.
But in the meanwhile it will have caused serious harm.
Also, the Draft in a serious number of case is a very interesting 
default, now the ABNFis clean and possible pretensions reduced.
Also, I prefer good compromise now than exclusion.
Love your enemies says the Gospel.

> > My proposition is:
> >
> > 1. to reduce the charset/script conflicts in defining the
> > Internet meaning of a script (equivalent to ccTLD IDN tables).
> > No big deal, since the tables are already published by Unicode.
>
>ccTLD IDN tables are, to all intents and purposes, just lists of
>characters bound to TLD-registry-specific names or keywords. If
>you really see something important and useful that needs to be
>done, generate an applicability statement.  See above about
>posting I-Ds, however, and also see below about ccTLDs, ICANN,
>etc.

Thank you. But, I am sorry, you do not address the technical issue.

> > 2. to define the relation between ccTLDs and langtags
> > "regions" - probably one sentence to be approved by IANA,
> > ICANN and the ccTLD community.
>
>IANA does not make policy, and hence doesn't approve anything.
>If you have a specific proposal to make in this area, please
>make it to and at ICANN -- not an IETF problem no matter how
>much you might wish otherwise.

Sorry again, you do not address the technical issue.
The IETF understanding of ISO 3166 is documented by RFC 1591.
Not also in the Draft.

> > 3. to include the IRI-tags into the Draft, through the
> > multilingual (numeric) "0-" hook, so we support different but
> > not alternative descriptions.
>
>Applicability statement and profile.  See comments above.  And
>note that, as far as I know, you are the only advocate within
>the IETF for the "0- hook?  That is not what we normally are
>referring to when we talk about the evidence of strong community
>support needed to produce something as an IETF specification or
>standard.

I do not think you need to be many to support common sense 
propositions. But if this was needed we could. Is that so necessary? 
I respect the IETF enough not to play that game.

But I am sure than if you consider it seriously, you would support it yourself.

> > I was opposed over ISO 11179. It seems this has changed since
> > the August ISO meeting. I can only rejoice. IMHO the DRS issue
> > is far more complex than ISO 11179 and should be addressed
> > separately (may be after some experience has been gained with
> > the IRI-langtags?)
>
>Perhaps this is a discussion you should be having with the
>relevant ISO TC or SC?

???
I have no objection that the Internet architecture is discussed at 
TC32 (or TC37), but I am surprised that _you_ would suggest it.
Anyway do not be afraid we did not wait for the suggestion.

Take care.
jfc  


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