Subject: [Ltru] draft review

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

Gentlemen,
This is the review I made of the current draft : the text and the way it 
addresses the Charter. I accept there is a challenge in the charter, which 
is to reconcile two of its assigned challenges. Its authors chose to 
address one of them (to identify the role of the subtags in the langtag), 
while my approach is to start from the other (stability) to address both, 
in a more general way.

The result is that my review has only a very limited number of positive 
remarks. But that does not mean that I full oppose. It confirms the only 
two possibilities already offered by the [email-masked] mailing list:

-	either to accept the draft in the strict area quoted by the Charter (XML, 
HTML and CLDR) to describe the language human readers should know to read a 
tagged text.

-	or to write another one, in a totally different perspective, to support 
the multilingual internet architectural consistency we need.

In any case the first solution would only be a temporary patch until the 
second one can support the world priority for a multilingual internet.

I only hope this will permit Addison Philips and Mark Davis to improve 
their text so it might make an RFC.

DRATF RELATED COMMENTS AND QUESTIONS

This review only concerns the points discussed in the proposed draft, not 
the points which are missing.

1.	Abstract: "indicate the language" does that mean qualify (tell about) or 
define (show the way) or both?
2.	Abstract: "information object": does that include programs, services, 
users communities
3.	Abstract: "interchange". Is there a special reason to use the word 
"interchange" (quoted 13 times in the IETF RFC database) and not 
"exchanges" (38 times). What are the differences intended?

4.	Introduction: the word identify/identifier is used 6 times, while 
indicate/indicating only 2 to avoid repetition of identify. Why not to use 
the word "identify" in Abstract (cf. question 1)?
5.	Introduction: the introduction describes the use of the tag to name a 
menu of references (dictionaries) and documents that it is often necessary 
to document style related elements (dialect, orthography) and writing 
system. These are the 5 elements I want to see documented.
6.	Introduction: documents that knowing the language is useful (qualifies) 
or required (defines) for some processes. What is the intended meaning?
7.	Introduction: indicates that labels are one of the means of indicating 
(meaning?) languages used. No other means is alluded to, and no comments 
about their common consistency is provided?
8.	Introduction: identifies only two functions for the document: an 
"identifier mechanism" and a "registration function". It does not talk of 
the dissemination of that information, nor of the way applications should 
use it.
9.	Introduction:  the sentence should say "This document intended to 
replace RTC 3066 and as such to become the new RFC 047" if this is the intent.

10.	The language Tag: introduction talks about labels. What is the 
difference between the labels which have been documented as necessary and 
the languages tags now documented?

11.	Syntax: the sentence "this makes it possible to construct a parser 
…even if specific subtag values are not recognised" is quite obscure. What 
is the exact meaning of "recognised": understood, known, accepted, 
authoritative, canonical, identified?
12.	Syntax: "a parser need not have an up-to-date copy .. to perform .. 
most .. searching and matching", what tells the parser the values it uses 
are up-to-date? How can we quantify the "most" and the number of 
occurrences of the remaining cases, for one billion users and more?

13.	2.1.1: how can the complex subtag sequence adding more precision can 
"seldom add useful distinguishing information" they are obviously intended 
to? Where is documented the authority of the following "because" saying 
that more granular tags interfere with the meaning, etc.. intended by the 
user. I do not oppose that users can be clumsy, but I think that the idea 
they are seldom smart should be explained. I feel the problem is more with 
filtering/analysis limitations.
14.	2.1.1: that subtags SHOULD be limited to four subtags is not 
documented. The allusion to the 2.3. for more information (which provides 
guidance about best choice of subtag content) does not seems to document 
this at all.
15.	2.1.1: is accepted as a "conformant implementation" an application not 
supporting a non specified length (1, 10, 100 chars?). The consequences on 
usage are not documented.

16.	2.2: it is noted that the language used for the "language tags 
namespace" and its registry is quite similar to the domain name system. 
However the proposed semantic is not consistent with other Internet spaces 
like DNS, IPv4, OID, etc. where the dot-separation is used, something users 
and parsers are accustomed to and existing processes have identified in 
different scripts. It relies to the contrary on the "-" as a separator 
which is more confusing and may have less identified homographs.
17.	2.2: the proposed design of language tags mixes identification of 
subtags by their position unless it is by their length. It is probable that 
in the particular case of the legacy and initial situation this can work. 
Such a two, possibly contradictory, systems format will never scale, is far 
too dependent from external changes and unable to support innovation. This 
cannot be made a world-wide standard through an IETF BCP except in the 
cases defined by the charter if the IESG wants to run into the risk of 
endless conflicts and of a quick obsolescence. It is to be noted that the 
referred ISO standard to be used are less than 30 years old and yet ISO 
3166-2 cannot be supported.

18.	2.2.1: primary language: fixed length identification starts with 2 or 3 
and possibly 8 but discouraged language ID coming this way only from ISO 
639. This removes the possibility to consider computer related (non only 
programming) languages, dialects, etc. nor to adapt to evolutions, 
adjustments, and passed languages. For example, ISO 3166 could back to 1800 
and possibly to 1000 and even to much before, either as a an ISO document 
or as a consistent table. Support of historic languages will be required. 
Blocking document historical consistency is unthinkable  let just consider 
the current effort by Google and various libraries.
19.	2.2.1.: the 2 letters code for language is an oddity inherited from 
earlier times of RFC 1776 and ISO 639. Nothing against this being the 
default in some legacy or private application. It is likely that at some 
time it will be timed out by ISO or/and by usage  may be even by 
anti-racist laws Time is now to update existing applications rather than to 
increase complexity of the years/century to come. This makes me think to 
"UK" instead of "GB". I know why Mr. Peter Jones made the world to use 
".uk": I will be also able to tell my grand-grand-son why they are to riot 
against the 2/3 letters cultures discrimination. This seems also in 
contradiction with the spirit of the quoted ISO 639/RA-JAC statement which 
says "users are directed in Internet applications to employ the alpha-3 
code" which sounds as the part of the statement which will stay as 
universal .. for a short while (?).

20.	2.2.2: language subtags are permitted only if they are 3 characters (a 
permanent rigid position) based the anticipation of a non documented ISO 
639 works. This is also a violation of the Internet standard process: the 
document in reference should be quoted and cannot be a draft. Language 
extended subtags are the most active part of languages, yet the rigidity 
imposed by the chosen format obliges to prevent their registration by IANA 
(what is the very purpose of the document: to permit flexibility to support 
real network life, where ISO would be too slow).

21.	2.2.3: Script subtags follow the same rigid logic and constraints from 
the format.  What happens if the memory waste of ISO 15924 (3 bytes lost) 
is corrected, or if another code element has a fixed  4 characters length 
in the future?

22.	2.2.4: I understand that all the regional language differences of the 
world are to be supported by the ISO 3166 alpha-3/digit-3 list. This means 
that regions like NY, TX or California are not entitled a code but the 56 
persons of Pitcairn Island yes? I doubt that disparity can hold very long, 
all the more than ISO 3166-2 provides all the possibilities for a far more 
adequate granularity.

23.	2.2.9: There is a MUST in "there MUST be an attempt to register" which 
cannot be enforced if there is not a non-delaying procedure to verify that 
a language was attempted to be registered with ISO 639. Otherwise this part 
is to be understood as a disguised way, concerted with ISO, to block names. 
The concern on this point is high enough to see the Draft blocked. It seems 
that the second paragraph is a smoky verbose replay of the same idea, 
without any procedural description nor request/provision of formal proof. 
The general idea is precisely in opposition with the purpose of the 
proposed RFC: to be able to register names not registered by ISO. This 
amount to a legitimisation of censoring, and censoring against the very 
intent of this document.
24.	2.2.9: registrations are left to a decision of appropriateness by 
someone debating with undefined  others for a matter without any importance 
on the network stability and security (documented in in part 4) non on the 
end to end interoperability. This seems to amount to pure intellectual 
censoring.

25.	2.3: recommendation 3 seems inappropriate. Aliases are aliases. All the 
aliases must be equally supported because (a) they are aliases (b) to make 
sure developers develops correct code.

26.	2.4. "language tags always define a language as spoken by human being 
for communications of information to other human beings. Computer languages 
… are explicitly excluded" has no ground in the Charter and in reality. Web 
Services relations are excluded which may speak limited languages. Coded 
human languages should be supported: they fit the definition.

27.	2.4.1: in the canonicalization part "" is reminded as a deprecation 
indicator, yet this is not documented earlier. It seems this is an external 
ISO practice. This should be documented in the format description part. All 
the more than this practice is counter intuitive "" being understood 
intuitively as "-(nul)-". And the "" being used in IDN there could be some 
homograph confusion to investigate.

28.	3: the reference to RFC 2434 is correct but the rest of the part 3 
seems inappropriate.  RFC 2434 says "If the IANA is expected to play a role 
in the management of a name-space the IANA must be given clear and concise 
instructions describing that role". The part 3 is neither clear and concise 
and is contradictory with the document which describes a IANA file to be 
maintained by an IESG reviewer. The IESG having authority on the IANA, the 
role of the IANA is to store and disseminate the current file version as 
maintained by the reviewer.

29.	3.1: Description of "description" is clueless. It is a description but 
does not intend to be an English description but it is one. The addition 
made in the IANA file are intended to be additions to  corresponding 
documented ISO tables. They MUST comply with the format of these tables 
otherwise they add a disparity between the table and their IANA "appendix".
30.	3.1. includes a registry format description (OK) but also 
considerations on the way the tags should be formed which have nothing to 
do in a file description. They should be moved into 2.4.1
31.	3.1. also includes direction to the Reviewer which should be presented 
in a separate part from the format description.

32.	3.2. this part is not a IANA procedure but a long guidance for the 
Reviewer and the Reviewing process participants,  limited to current 
possible cases.

33.	3.3 : Understanding the meaning of "Subtags required for stability and 
to keep the registry synchronised" will probably be a source of long 
debates. It should be documented.
34.	3.3.  why a "MAY" concerning the "description, note and prefix fields" 
is not documented by conditions? Is that not a "CAN".
35.	3.3. the registration procedure is of extreme confusion and mixes the 
form to use, the lack of definition of the requester, the iana.org list 
which is not introduced, the registration request which must be guessed, a 
non commented MAY, registration tricks, comments on probable behaviour of 
the reviewing list, digression on Slovenian, designation of the reviewer by 
the IESG, what should happen when the review period has elapsed without any 
guidance to the reviewer, that a IANA list Members and an IESG designated 
reviewer make an IETF decision, that the initial registrant has some moral 
pre-eminence (under the form of a comment) and that languages are not 
considered for registration on the fact they actually exist, but on their 
own (non documented) merits.

36.	3.4. Difficult to understand. The first sentence is probably inherited 
from the former versions of the draft. "compatible with applications that 
process language tags according to this specification" seems to refer to 
filtering which should be part of the of the second document produced by 
the WG-ltru.
37.	3.4. The description of information to be maintained is clear, but the 
format is not described. This permits IANA to freely change it or to 
present it in HTML form. This does not help its automated reading.

38.	4. security considerations should not deal with users political 
security outside of their network usage. Otherwise tons of such 
considerations should be presented.
39.	4. An important security consideration is homographs. It is certainly 
possible to include part of text in a foreign language which look printed 
as in another language or having a different meaning or printing 
(phishing). Concerns are also the double "-" which is specifically used by 
the IANA code "xn".
40.	4. Fourth paragraph  tend to say that specification of valid sub-tags 
MUST be available over the internet but that applications should take 
possible DoS into consideration. This is an important indication on the way 
the Draft proposes the registry file to be used and accessed. It can be 
read that applications can freely access it and proposed mirrors: this may 
impose on the IANA a load which will result in its permanent inability of 
service.

41.	5. character set consideration are contradictory: they say that 
character a-z exist in most character sets (good news)  [what means that 
there are some where they do not exist] so there should not be character 
set presentation issue [in the character set where they do not exist?]. 
Also the consideration only concerns the "display" what has a limited 
interest if the a-z characters do not exist on the keyboard. But may be 
this supposes that "intelligent people" use ascii compatible keyboards (see 
below).

42.	6. compatibility is preserved with RFC 3066 but not with evolution of 
ISO code elements. The XML Schema version 1.0 requirements are quoted but 
not documented.
43.	6. Stability. Confusion between document. This document does not 
provide a mechanism but a format that can be used by the mechanism 
described in the next document. This text has not been adapted after the split.
44.	6. Validity. This document should define the IQ of the "intelligent 
people" being considered or the collective IQ augmentation necessary to 
understand the system ??  Please see the ideas of the one who created the 
NIC and grand fathered the RFC system (http://bootstrap.org).
45.	6. Extensibility such as presented actually results (in a very limited 
way) from the underlying ISO codes. This is not the target of Charter which 
is to permit scalability even when a code element it is not supported by ISO.
46.	6. the document uses several times the term "extlang" but does not 
defines it.
47.	6. last: added text for "" is not sufficient enough, or is missing in 
my version.

CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS

48.	language preferences are uniquely understood in HTML, XML only. CLDR 
are quoted in the charter and not quoted in the Draft. The Charter does not 
prevent other applications, systems to be supported. The Draft does not 
allude to them.

49.	The charter lists RFC 3066 problems. These problems are: (a) 
stability  there is a paragraph on the matter; (b) accessibility to the 
underlying ISO standard  this is definitely impeached by the format (no ISO 
3166-2, no other ISO 639 format  than 2 or 3 characters  no other script 
description format than 4 characters, etc. as if the current ISO 
presentation will never improve); (c) difficulty with registration and 
acceptance: this could be improved by the subtag registration system but it 
seems to be made worse, due to the censoring rules introduced to prevent 
non-ISO entries to be entered in the IANA non-ISO table; (e) lack of clear 
guidance to identify script and region: scripts are Unicode only, region 
are 2 letter Telex codes; (f) lack of parseability and well-formedness : 
this has certainly been addressed [it seems to be both the major 
improvement of the Draft … and the source of most of its problems due to 
the rigidity it introduces].

50.	The main purpose of this Draft from the charter is to describe the IANA 
registry to support the resolution of the above problems, and how 
transition from RFC 3066. This is to be in a clear and concise way. RFC 
3066 represents roughly 17.000 characters and the draft 70.000 (out of the 
IETF format and verbose). This makes it confuse. From what I understand it 
includes 3 parts: (a) the subtags file with a clear format (b) the 
accompanying registration/update forms (c) the variant tables with a clear, 
yet less precise format. From what I understand (a)(b) are the real 
responsibility of the old aliased distribution list and of a Reviewer 
designated by IESG with unlimited veto powers; (c) of the IESG when 
reviewing RFCs requesting entries, and of the updating mechanism defined by 
these RFC.

51.	it lists challenges to be addressed. Stability: "how the language tags 
remains stable even if the underlying references should change". This means 
a process where the tag name is unrelated to its underlying components, 
like a domain name is stable even if the underlying IP address changes. 
This is not provided.

52.	it lists challenges to be addressed. Accessibility: "a simple way to 
determine if a subtag is valid as of a given date. Like receiving a 404 
when calling an expired domain name". Such a mechanism is not provided.

53.	it lists challenges to be addressed. extensibility: this meant not 
having to record millions of combinations. This is provided. To the price 
of format rigidity, impossible use of foreseen or existing ISO code 
elements, and a censoring of the non-ISO extensions which may lead to more 
harassment. It also meant addition of the script in language tags. This is 
permitted by the proposed format but to the detriment of other 4 letters 
entries. Registration  of non ISO scripts is not permitted.

54.	it lists challenges to be addressed. "provide mechanism to support the 
evolution of the underlying standards, in particular ISO 693-3, mechanisms 
to support variant registration and format extensions, as well as allowing 
generative private use when necessary": I am not sure what "generative" may 
mean in here but I feel it is not supported, the rest is certainly opposed 
by the chosen format;

55.	it lists challenges to be addressed: "to specify a mechanism for easily 
identifying the role of each subtag  in the language tag". This is 
addressed by the Draft. But this challenge is contradictory with stability 
challenge above. If a language tag displays an identifiable subtag, it 
becomes by nature dependent from the underlying value of the subtag.

I will study carefully the responses to this review before introducing my 
own Draft, to try to build  if possible  on the largest possible number of 
consensual elements.

My current thinking is totally different. It is an open framework which 
respects the XML, HTML, CLDR requirements in welcoming your own (adapted) 
Draft, the ISO evolution, the requirements of an Internet for the people of 
the world by the people of the world, at an affordable cost, with an highly 
innovative technical approach, a great care for operation security and 
stability and in total continuity with the funding concept which gave us 
thirty years of international public network stability.

But I think the issues it rises are important enough to call on an 
understanding, comments, and a support by all those concerned by a 
"multilingual cyberspace", an equal cultural dignity empowerment on the 
digital ecosystem and an open e-commerce. This is because language tags are 
by nature the basic building blocks of the multilingual internet which is 
also to be user centric, multitechnology (convergence), multicontent 
(information society), multilateral, as the WSIS shows it.

jfcm 

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

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 09:51:46 -0400

I apologize in advance for the length of this document.  It is a formal,
but entirely personal, reply to M. Morfin's draft review.  The points
which I consider valuable in that review are not taken up here; I have
concerned myself in this particular message only with M. Morfin's errors,
misapprehensions, and insinuations, in the faint hope that they can be
disposed of once and for all.

> DRATF RELATED COMMENTS AND QUESTIONS

Comments 1-15 are editorial in nature and I have addressed them elsewhere.

> namespace" and its registry is quite similar to the domain name system.

The analogy is vague and specious, and utterly ungrounded in the text,
which does not even contain the phrases "domain name system" or "DNS".

> However the proposed semantic is not consistent with other Internet
> spaces like DNS, IPv4, OID, etc. where the dot-separation is used,
> something users and parsers are accustomed to and existing processes
> have identified in different scripts. It relies to the contrary on the
> "-" as a separator which is more confusing and may have less identified
> homographs.

What is more confusing about "-" than "."?  In any case, "-" has been
used in all language tags until now, and is required for backward
compatibility.

> 17. [...]  Such a two, possibly contradictory, systems format will
> never scale, is far too dependent from external changes and unable to
> support innovation.

This is handwaving.  Scale to what, millions of countries and trillions
of languages?  Of course it is dependent on external changes, or rather
the lack of them.  A format that is designed to depend on anything external
cannot possibly adjust in advance to radical changes of an unknown nature.

> This cannot be made a world-wide standard through an IETF BCP except
> in the cases defined by the charter if the IESG wants to run into the
> risk of endless conflicts and of a quick obsolescence.

The alleged risk is not supported by the history of RFC 1766/3066 in
the last ten years.

> It is to be noted that the referred ISO standard to be used are less
> than 30 years old and yet ISO 3166-2 cannot be supported.

ISO 3166-2 (subnational regions) is not freely available; it costs CHF 200
for a copy without even update service.  (Approx. EUR 129 or USD 167.)
It has never been proposed or used for language tagging.  In addition,
it is extremely unstable, because countries are allowed to rewrite
their parts of it pretty much ad lib as they reorganize their internal
subdivisions from time to time.

> 18.	2.2.1: primary language: fixed length identification starts
> with 2 or 3 and possibly 8 but discouraged language ID coming this way
> only from ISO 639. This removes the possibility to consider computer
> related (non only programming) languages, dialects, etc. nor to adapt
> to evolutions, adjustments, and passed languages.

Untrue.  36^8 possible language tags is more than enough.  Discouraging
something does not imply removing the possibility of it.

> 19.	2.2.1.: the 2 letters code for language is an oddity inherited
> from earlier times of RFC 1776 and ISO 639.

It is unquestionably a theoretical wart, but is absolutely required
for backward compatibility.

> It is likely that at some time it will be timed out by ISO or/and by
> usage  may be even by anti-racist laws.

This is a truly amazing bit of prophecy worthy of Michel de Notredame.

> Time is now to update existing applications rather than to increase
> complexity of the years/century to come.

Applications are not at issue; data is.  Where is the money going to
come from to re-mark-up the billions of existing documents and metadata
repositories worldwide that rely on ISO 639-1 codes?

>  This makes me think
> to "UK" instead of "GB".

Words like "united" and "kingdom" are avoided when possible in ISO 3166-1
codes because they are shared by many nations.  You would be better off
pressing for GN (Great Britain and Northern Ireland) or for changing
US to some other code.

> 20.	2.2.2: language [extended] subtags are permitted only if they
> are 3 characters (a permanent rigid position) based the anticipation
> of a non documented ISO 639 works. This is also a violation of the
> Internet standard process: the document in reference should be quoted
> and cannot be a draft.

ltru-registry is also only a draft at present.

> Language extended subtags are the most active part of languages,

Where is the evidence for this claim?  Are you confusing the function
of extended language subtags with that of variant subtags?

> 21.	2.2.3: Script subtags follow the same rigid logic and constraints
> from the format.  What happens if the memory waste of ISO 15924 (3
> bytes lost) is corrected, or if another code element has a fixed  4
> characters length in the future?

We cannot design the draft to adapt to unpredictable massive changes
in the format of ISO codes, especially when there is not the slightest
evidence that such a thing will ever happen.

> 22.	2.2.4: I understand that all the regional language differences
> of the world are to be supported by the ISO 3166 alpha-3/digit-3 list.

Incorrect.  National and supranational regions are supported by ISO 3166-1
alpha-2 and UN M.49 digit-3 codes.

> This means that regions like NY, TX or California are not entitled a
> code but the 56 persons of Pitcairn Island yes? I doubt that disparity
> can hold very long, all the more than ISO 3166-2 provides all the
> possibilities for a far more adequate granularity.

See above.

> 23.	2.2.9: There is a MUST in "there MUST be an attempt to register"
> which cannot be enforced if there is not a non-delaying procedure to
> verify that a language was attempted to be registered with ISO 639.

Forward verification would surely suffice; a copy of a dated email to
ISO 639/RA showing an ignored registration would suffice.  In facct,
however, the RA is quite responsive.

> Otherwise this part is to be understood as a disguised way, concerted
> with ISO, to block names.

There is no evidence for this allegation.

> The concern on this point is high enough to see the Draft blocked.

Whose concern?  Blocked by whom?  Vague and unfounded.

> It seems that the second paragraph is a smoky verbose replay of the
> same idea, without any procedural description nor request/provision
> of formal proof.

It may *seem* so to you.  We deal here in what is so, not in what seems so.

> amount to a legitimisation of censoring, and censoring against the
> very intent of this document.

Libelous nonsense.  The general idea is of course to avoid duplication
of effort, so that ISO and ietf-languages are not considering the same
language at the same time.

> 24.	2.2.9: registrations are left to a decision of appropriateness
> by someone debating with undefined  others for a matter without any
> importance on the network stability and security (documented in in
> part 4) non on the end to end interoperability. This seems to amount
> to pure intellectual censoring.

Non sequitur.

> 25.	2.3: recommendation 3 seems inappropriate. Aliases are aliases.
> All the aliases must be equally supported because (a) they are aliases
> (b) to make sure developers develops correct code.

All aliases are equally supported.  Not all aliases are equally recommended.

> 26.	2.4. "language tags always define a language as spoken by human
> being for communications of information to other human beings. Computer
> languages are explicitly excluded" has no ground in the Charter and
> in reality.

Computer languages are not languages, save metaphorically.  See ISO 639.

> Web Services relations are excluded which may speak limited languages.

Do you suppose that SOAP is a language?

> Coded human languages should be supported: they fit the definition.

What is a coded human language?

> 27.	2.4.1: in the canonicalization part "" is reminded as a
> deprecation indicator, yet this is not documented earlier. It seems this
> is an external ISO practice. This should be documented in the format
> description part. All the more than this practice is counter intuitive
> "" being understood intuitively as "-(nul)-". And the "" being used
> in IDN there could be some homograph confusion to investigate.

I suppose that by "" you mean "--".  This is not a deprecation indicator,
as the draft clearly explains.

I will address comments 28-33 elsewhere.

> 34.	3.3.  why a "MAY" concerning the "description, note and prefix
> fields" is not documented by conditions? Is that not a "CAN".

CAN does not appear in RFC 2119.

I will address comment 35 elsewhere.  Comment 36 is editorial in nature
and has already been addressed elsewhere.

> 37.	3.4. The description of information to be maintained is clear,
> but the format is not described. This permits IANA to freely change it
> or to present it in HTML form. This does not help its automated reading.

3.4 is about extensions, which are documented through the RFC process
and only through the RFC process, as is plainly stated.  There is no
expectation that information about extensions will be machine-processable.

> considerations should be presented.

The point has been raised and is documented.

> 39.	4. An important security consideration is homographs. It is
> certainly possible to include part of text in a foreign language which
> look printed as in another language or having a different meaning or
> printing (phishing).

This is a security consideration related to the existence of text
altogether, not to the tagging of it.  Or at most it is related to
the absence of tagging.

> Concerns are also the double "-" which is specifically used by the
> IANA code "xn".

The IDN code space is unrelated in any way to the language tag code space.

> 40.	4. Fourth paragraph  tend to say that specification of valid
> sub-tags MUST be available over the internet but that applications
> should take possible DoS into consideration. This is an important
> indication on the way the Draft proposes the registry file to be used
> and accessed. It can be read that applications can freely access it
> and proposed mirrors: this may impose on the IANA a load which will
> result in its permanent inability of service.

There are several possible solutions, including mirrors, upgrades to
IANA infrastructure, and load throttling by IANA.  Which of these is
done, if any, is an internal IANA question and off-topic here.

Comments 41-42 are editorial in nature and will be addressed elsewhere.

> 43.	6. Stability. Confusion between document. This document does
> not provide a mechanism but a format that can be used by the mechanism

This does not seem to reflect draft-ietf-ltru-registry-01.

> 44.	6. Validity. This document should define the IQ of
> the "intelligent people" being considered or the collective IQ
> augmentation necessary to understand the system ??  Please see the
> ideas of the one who created the NIC and grand fathered the RFC system
> (http://bootstrap.org).

Irrelevant.  The draft says that *even* intelligent people may do
inconsistent things in the absence of guidance.

> 45.	6. Extensibility such as presented actually results (in a very
> limited way) from the underlying ISO codes. This is not the target of
> Charter which is to permit scalability even when a code element it is
> not supported by ISO.

That is one of many points mentioned in the charter.  It is not the
singular goal of the draft.

Comment 46 is editorial in nature and will be addressed elsewhere.

> 47.	6. last: added text for "" is not sufficient enough, or is
> missing in my version.

Unintelligible.

> CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48.	language
> preferences are uniquely understood in HTML, XML only.  CLDR are
> quoted in the charter and not quoted in the Draft. The Charter does
> not prevent other applications, systems to be supported. The Draft
> does not allude to them.

As stated in earlier postings, these are merely consumers of RFC 3066
language tags.  There are others.  There is no reason for the draft
to mention its consumers; rather they mention it.

> underlying ISO standard  this is definitely impeached by the format
> (no ISO 3166-2, no other ISO 639 format  than 2 or 3 characters  no
> other script description format than 4 characters, etc. as if the
> current ISO presentation will never improve);

Answered above.  There is no reason to expect such changes, and no
evidence is given that they constitute improvements.

> (c) difficulty with registration and acceptance: this could be improved
> by the subtag registration system but it seems to be made worse,
> due to the censoring rules introduced to prevent non-ISO entries to
> be entered in the IANA non-ISO table;

"Prevent" is a malicious falsehood.

> (e) lack of clear guidance to identify script and region: scripts are
> Unicode only,

Untrue.  See the ISO 15924/RA registry, which lists many non-Unicode
scripts.

> region are 2 letter Telex codes;

They are part of an international standard, whether originally
derived from Telex codes or not.

> (f) lack of parseability and well-formedness : this has certainly been
> addressed [it seems to be both the major improvement of the Draft
> )B… and the source of most of its problems due to the rigidity
> it introduces].

Rigidity about matters which cannot be expected to change is not only
reasonable but desirable.

> 50.	The main purpose of this Draft from the charter is to describe
> the IANA registry to support the resolution of the above problems,
> and how transition from RFC 3066. This is to be in a clear and concise
> way. RFC 3066 represents roughly 17.000 characters and the draft 70.000
> (out of the IETF format and verbose).

Out of the IETF format in what way?

> This makes it confuse. From what I understand it includes 3 parts:
> (a) the subtags file with a clear format (b) the accompanying
> registration/update forms (c) the variant tables with a clear, yet
> less precise format.

What "variant tables"?  This expression does not appear in the draft,
nor is anything described that could be so designated.

> From what I understand (a)(b) are the real responsibility of the old
> aliased distribution list and of a Reviewer designated by IESG with
> unlimited veto powers;

As the draft (and RFC 3066 and 1766) clearly state, the Reviewer's
decisions may be appealed to IESG.  That is not an unlimited veto.

> 51.	it lists challenges to be addressed. Stability: "how the language
> tags remains stable even if the underlying references should change".
> This means a process where the tag name is unrelated to its underlying
> components, like a domain name is stable even if the underlying IP
> address changes. This is not provided.

The analogy to the DNS is specious.  A more correct analogy would be
attemping to keep a domain name stable when one of its enclosing
domains changes its name.

> 52.	it lists challenges to be addressed. Accessibility: "a simple way
> to determine if a subtag is valid as of a given date. Like receiving
> a 404 when calling an expired domain name". Such a mechanism is not
> provided.

The expression in quotation marks is not, in fact, a quotation from
the charter, and so need not be addressed.

> 53.	it lists challenges to be addressed. extensibility: this meant
> not having to record millions of combinations. This is provided. To
> the price of format rigidity, impossible use of foreseen or existing
> ISO code elements, and a censoring of the non-ISO extensions which
> may lead to more harassment. It also meant addition of the script in
> language tags.  This is permitted by the proposed format but to the
> detriment of other 4 letters entries. Registration  of non ISO scripts
> is not permitted.

Answered above.

> 54.	it lists challenges to be addressed. "provide mechanism to support
> the evolution of the underlying standards, in particular ISO 693-3,
> mechanisms to support variant registration and format extensions,
> as well as allowing generative private use when necessary": I am not
> sure what "generative" may mean in here but I feel it is not supported,
> the rest is certainly opposed by the chosen format;

"Generative" refers to the ability to create complex elements from
the systematic assembly of simpler elements.  ISO 639-3 concerns have
been taken into account from the start.  Variant registration is
directly supported.  Format extensions are provided for.

> 55.	it lists challenges to be addressed: "to specify a mechanism for
> easily identifying the role of each subtag  in the language tag". This
> is addressed by the Draft. But this challenge is contradictory with
> stability challenge above. If a language tag displays an identifiable
> subtag, it becomes by nature dependent from the underlying value of
> the subtag.

It certainly does.  To use your favorite analogy, a domain name
is not independent of the name of its enclosing domains; were the .fr
TLD to change its name to .gaul tomorrow, all subdomains of .fr would
have to change likewise.

-- 
As you read this, I don't want you to feel      John Cowan 
sorry for me, because, I believe everyone       [email-masked]
will die someday.                               http://www.reutershealth.com
        --From a Nigerian-type scam spam        http://www.ccil.org/~cowan

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 08 Apr 2005 00:27:10 +0200

Dear John,
I thank you for this review. If I am correct my response here should only 
be to say if I maintain the point or if I accept that your objection is 
correct and I should remove it?

There are many comments which root in a different vision of the Internet 
and of the Charter. I note them the first time they occur. They should be 
debatted separately. Some mignt lead to the need of a call on an IAB 
Guidance, due to their fundamental aspect for the Internet, if theyr were 
still shared by a significant proportion of the score of participants to 
this WG.

>which does not even contain the phrases "domain name system" or "DNS".

I have however a general comment which is that you seem to entertain some 
confusion about what is the DNS and its main usage. This is a common 
confusion. I suggest you study STD 013. I will not comment your further 
allusions to DNS.

>used in all language tags until now, and is required for backward

Not a objection to a factual remark. The point is not that the format would 
be wrong, but that the format wants to be unique and general. This 
misunderstanding affects most of the remarks about the format. I will 
therefore not comment it, only the specifics of each point.

>cannot possibly adjust in advance to radical changes of an unknown nature.

The charter is precisely about making the format independent from external 
elements. This confusion is part of several reponses. I will not comment them.

>The alleged risk is not supported by the history of RFC 1766/3066 in

This is precisely the point. The way this RFC is writen and applied makes a 
real difference with the Draft. Here is were comes the risk.

>for a copy without even update service.  (Approx. EUR 129 or USD 167.)

I fail to see what is the problem about the rightness of the content? The 
point is not in the access to the ISO document, but the inability of the 
proposed format to support IANA registrations of ISO 3166-2 equivalents.

>subdivisions from time to time.

This is precisely the second point. When they do that it is usually for a 
reason which is regionally or locally the same as ISO 3166-1 at national 
level. This is what makes ISO 3166 consistent, but not the proposed format.

>something does not imply removing the possibility of it.

Document the "more than enough" please. There is a general trend in these 
remarks to assume things. This is also a noted remark of the Draft. Rather 
than to discuss them I will note the remarks made on assumptions. To be 
constructive we should discuss these assumptions separately and probably 
list them as a leading part of the Draft, indicating the real scope of the 
Draft. What I can only support.

>for backward compatibility.

Yes. We are in agreement. You therefore do not contest the validity of this 
point. Its discussion is obviously another thing.

>This is a truly amazing bit of prophecy worthy of Michel de Notredame.

This represents a certain lack of legal international culture. The French 
law used in the Yahoo case (which has equivalent in the world) makes this 
illegal. It is also most probably a case to be made with the WTO as an 
unfair commercial advantage. We are here discussing standards. Standards 
concerned with stability (if they are stable and used they probably are 
adequate). The legal enforcement of a change in Standard is then real fear 
we should share.

>repositories worldwide that rely on ISO 639-1 codes?

I do not understand this point. The point is not to re-mark-up billions of 
existing documents (backward compatibility will address that) but to save 
the money that trillons of clumsy tagging will cost. Improving on something 
existant is usually for a ROI.

>pressing for GN (Great Britain and Northern Ireland) or for changing

I was refering to the origin of UK being used instead of GB. I know this is 
because Mr. Peter Jones. I will know and will be able to tell my grand-sons 
that I also know the lang3tag origin....

>ltru-registry is also only a draft at present.

Same comment as Scott Hollebeck's remark as about ABNF format.

>of extended language subtags with that of variant subtags?

This can be certainly be discussed.
Could you write a few lines on this. A Draft writter should not assume 
three things:
- that his readers are intelligent - I know this is a fault I commonly commit
- that his readers know things which are not documented in the Draft (need 
of an explanation or of a link)
- that his readers share his visions, this is why he has to explain them so 
they understand where he comes from and adapt.

>evidence that such a thing will ever happen.

Charter. This is also easy. I do not see any "massive" change here.

>alpha-2 and UN M.49 digit-3 codes.

:-)
Your comment is serious. Let stay this way.

> > possibilities for a far more adequate granularity.

wart? agree.

>however, the RA is quite responsive.

Document it. This is a standard, not a newspaper.

>There is no evidence for this allegation.

Many in ISO question ISO 15924 document. IETF and IANA have massive 
additions (starting with DNS Tables), Michael Eversom already made clear he 
will not consider. Being on both sides there is a CIO with the current text.

>Whose concern?  Blocked by whom?  Vague and unfounded.

Unless IESG drops the rule of consensus, there is no possible consensus on 
the present Draft. I am a documentation of it. At the present stage I can 
only oppose. This is why I try to see my opposition reduced. But this is a 
consensus process, not a compromise and obviously not an enforcement 
process. This means that at the end of the day APMD and I must be equally 
satisfied with the result.

>It may *seem* so to you.  We deal here in what is so, not in what seems so.

I was polite.

As a general comment, an RFC is an IETF delivery to readers. What counts is 
not what the authors intended to say but what the readers will understand. 
This is why the last call, the IESG and the Editor contribute after the WG. 
This is why also all the RFC do not become standards. This case is 
particular due to the status of BCP 047 of the RFC 3066.

>language at the same time.

No. Such a legitimate preoccupation would be satisfied by a registration 
except if a serious documented objection is risen within a 15 days 
consideration period _and_ documented (for the very point you make) by the 
ISO MA.

> > to pure intellectual censoring.

???
Unless you agree with my comment that these proposition do not make real sense.

>All aliases are equally supported.  Not all aliases are equally recommended.

Not the text.

>Computer languages are not languages, save metaphorically.  See ISO 639.

Sorry, ISO 639 is not the Charter. ISO 639 has obvious lacks that ISO 639-4 
is meant to correct. Impeaching supported Internet applications to benefit 
from ISO 639-4/6 probable positions, together with a disregard of the 
Charter, is a responsibility I will not assume.

But it can be discussed it in your assumptions.

>Do you suppose that SOAP is a language?

I have difficulty in understanding the question.

>What is a coded human language?

arbaille.

>as the draft clearly explains.

Please give reference of the part. May be I missed it.

>CAN does not appear in RFC 2119.

Sure. But this is not a reason to use a wrong term.

>expectation that information about extensions will be machine-processable.

There is mine. As you may know I maintain a daily survey of some IANA files 
(http://ccmso.org/intldate.txt - http://ccmso.org/intlfile.txt) and 
langtags will certainly be included in it.

>The point has been raised and is documented.

I do not understand this comment. I raise the point. Please indicate the 
documentation?

>altogether, not to the tagging of it.  Or at most it is related to

Security considerations are where people will go and look when a security 
concern is raised. Again this is a standard, not a newspaper or a lawyer 
defense. The "at most" means we agree: there is an impact. The role of the 
security considerations part is to discuss it. It can be positive or limited.

>The IDN code space is unrelated in any way to the language tag code space.

Private assumption.
BTW I say otherwise. It is at least through RFC 1958 basic principle and 
consistency rule.

>done, if any, is an internal IANA question and off-topic here.

Private assumption.
Several on-going debates (WebDAV, LDAP, DNS) in addition show that the 
point start being a point of consensus.

An important issue is that the Draft _does_not_document_ in which way 
applications may use it. This means what is to be the expected process of a 
parser reading a langtag. We are here in an ISO debate, not in an IETF debate.

>This does not seem to reflect draft-ietf-ltru-registry-01.

We work on the published draft. Glad if next draft goes for a better response.

>inconsistent things in the absence of guidance.

The reference given is to the root of the "IETF core values" and to the 
idea of the founders than computers augmented the intelligence of a 
bootstrap (a concept today translated in WGs). The best reading is 
therefore "even for the members of the WG" which is an acceptable 
auto-derisive remark. Beyond that, the remark is hurting. This is a 
standard, not a newspaper.

>singular goal of the draft.

This prioritization is your personal assumption.
You do not constest the goal. This qualifies the remark.

> > 47.   6. last: added text for "" is not sufficient enough, or is

Probable mail transliteration. "--" is quoted. You constest the point, but 
did not provide the reference (I may have missed).

>to mention its consumers; rather they mention it.

Debate has shown that authors intended to exclude some. This is unadvisable 
since it can only kill consensus possibility.

>evidence is given that they constitute improvements.

Private assumptions used not to address Charter requirements.

>"Prevent" is a malicious falsehood.

Please propose a more adequate wording than my Franglish.

>Untrue.  See the ISO 15924/RA registry, which lists many non-Unicode

I am not sure of the ISO 15924 copy I have. It wears the name and the 
copyright of its author. Would you have an URL for a stable version of the 
standard? Until I have a final document I cannot comment.

>derived from Telex codes or not.

Unproductive comment. IETF is Datacoms.

>reasonable but desirable.

all the more if the Charter says that you are to document how they will 
match these "not expected" changes.

>Out of the IETF format in what way?

I documented: http://mltf.org/addmark.pdf.

>nor is anything described that could be so designated.

IRT the Draft: this concerns additions made by other RFCs.

>decisions may be appealed to IESG.  That is not an unlimited veto.

Yes it is. De facto as I observed the mailling list. In the way a CIO 
results from his position and from his copyrigths ISO 15924.

>domains changes its name.

DNS.

>the charter, and so need not be addressed.

The quotation is not of the Charter. It is a quote of the need.
Its author will be dismayed from your dispise. The remark certainly hold.

> > detriment of other 4 letters entries. Registration of non ISO scripts

No answer above, disqualifies this question.

>directly supported.  Format extensions are provided for.

Charter says ISO 639-3 "in particular", not "exclusively". I will wait for 
ISO 639-6 and for ISO 639-4 and on MLTF positions to disqualify this point.

>TLD to change its name to .gaul tomorrow, all subdomains of .fr would

DNS. This makes no sense to me.

As a general comment. This review is interesting. It underlines the need to 
have the throughout review of the charter we did not initially carried. It 
shows there is a misunderstanding about consensus process we have to 
clarify. Also that the target is not to enforce a format but to get 
backward compatibility with a new format. It also shows the need for the 
score of participants to this work to know better about the other "clients" 
of their intended deliverable. I will try to word an begning of analysis of 
the use of the langtag, for everyone to add to it.

It also starts some additional small debates and possibility of tuning, 
both for the draft and for my own position. I therefore thank John for this 
work and wait for the next batch of comments. I will also delay my own 
draft to permit comments to come in (as also indicated by Randy's mail) and 
permit my own mailing list to review them before.

Best regards.
jfc

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 7 Apr 2005 09:27:37 -0700

Thanks, John, for taking the trouble to go through all of this!

‎Mark

----- Original Message ----- 
From: "John Cowan" <[email-masked]>
To: "JFC (Jefsey) Morfin" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 07, 2005 06:51
Subject: Re: [Ltru] draft review

See above.

Non sequitur.

Unintelligible.

> )B. and the source of most of its problems due to the rigidity
> it introduces].

Answered above.

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Apr 2005 09:19:54 -0400

> correct and I should remove it?

Your responses are entirely at your own discretion -- and the Chair's.

> confusion about what is the DNS and its main usage. 

I know very well what the DNS is and what its main usage is.

> Not a objection to a factual remark. The point is not that the format 
> would be wrong, but that the format wants to be unique and general.  

Formats don't "want" things.  This is unintelligible.

> The charter is precisely about making the format independent from 
> external elements. This confusion is part of several reponses. 

Not so.  Construe more closely: the charter is about making the format
independent of *changes* in external elements.

> This is precisely the point. The way this RFC is writen and applied makes 
> a real difference with the Draft. Here is were comes the risk.

Unintelligible.

> proposed format to support IANA registrations of ISO 3166-2 equivalents.

It is entirely able to support such IANA registrations via the registration
of variant tags.  There is no problem with registering 'texas' or 'lyons',
for example.

Unintelligible.

> Document the "more than enough" please. 

The burden of persuasion is on you to show that 2,091,771,330,064 variant
tags (36^8+36^7+36^6+36^5+10^4) is insufficient.

> Yes. We are in agreement.

You are too quick to claim that someone agrees with you when in facct
there is no such agreement.

> You therefore do not contest the validity of 
> this point. 

I more than contest it, I deny it absolutely.

> illegal. 

Do you imagine that the fact that fr has a 2-alpha code but bug does
not would be the subject of a lawsuit anywhere in the world, given
the clear standards for assigning 2-alpha codes stated on the
ISO 639/RA page?  Cite a legal action on point, if you please.

> I do not understand this point. The point is not to re-mark-up billions 
> of existing documents (backward compatibility will address that) but to 
> save the money that trillons of clumsy tagging will cost. 

What is the evidence that this tagging system is clumsy?

> - that his readers know things which are not documented in the Draft 
> (need of an explanation or of a link)
> - that his readers share his visions, this is why he has to explain them 
> so they understand where he comes from and adapt.

The purpose of extended language subtags is to deal usefully with a
semantic mismatch between ISO 639-1/639-2 and ISO 639-3, whereby certain
languages coded by the former are treated as more than one language
by the latter.  For example, zh is a single language in ISO 639-1, but
is a is listed as both a single macrolanguage and a group of individual
languages in ISO 639-3.  The intention is that these individual languages
which are parts of a macrolanguage be tagged using the extended language
tag:  zh will mean "Chinese" in general, whereas zh-gan will specify
the specific language "Gan Chinese".

> Charter. This is also easy. I do not see any "massive" change here.

A change in code length amounts to changing every code in a particular
ISO standard, and is a massive change indeed.

> Document it. This is a standard, not a newspaper.

*shrug*

I don't propose to write the responsiveness of the RA into the RFC.
Look at the timestamps of emails in the ietf-language archive.

> additions (starting with DNS Tables), Michael Eversom already made clear 
> he will not consider. Being on both sides there is a CIO with the current 
> text.

Give your evidence for these statements or withdraw them.

> Unless IESG drops the rule of consensus, there is no possible consensus 
> on the present Draft. I am a documentation of it. At the present stage I 
> can only oppose. This is why I try to see my opposition reduced. But this 
> is a consensus process, not a compromise and obviously not an enforcement 

Not so.  Consensus is not unanimity.

> >It may *seem* so to you.  We deal here in what is so, not in what seems 

Charges of obscurity and verbosity, especially without supporting arguments,
are scarcely polite.

> consideration period _and_ documented (for the very point you make) by 
> the ISO MA.

Why 15 days?  Languages don't arise out of nothing like software or new
Internet hosts.  They are pre-existing facts.  Surely it is worth
taking some time and trouble over their permanent encodings.

> Unless you agree with my comment that these proposition do not make real 

I don't.

> >All aliases are equally supported.  Not all aliases are equally 

A direct consequence of it.

> Sorry, ISO 639 is not the Charter. ISO 639 has obvious lacks that ISO 
> 639-4 is meant to correct. Impeaching supported Internet applications to 
> benefit from ISO 639-4/6 probable positions, together with a disregard of 
> the Charter, is a responsibility I will not assume.

You might as well say that STD 3 is binding on human hosts as well
as computer hosts.

> I have difficulty in understanding the question.

Well, all right, what do you mean by "limited languages"?

> >What is a coded human language?

Googling shows this only as the name of several places in the Basque
country.  But if it is an argot, then there is no problem tagging
argots using an appropriate variant subtag; en-boont is such an argot.

> Please give reference of the part. May be I missed it.

Maybe.

> There is mine. As you may know I maintain a daily survey of some IANA 
> files (http://ccmso.org/intldate.txt - http://ccmso.org/intlfile.txt) and 

Excellent.  But what has this to do with extensions, which are licensed
only by new (and as yet unwritten) RFCs?

> I do not understand this comment. I raise the point. Please indicate the 

You claimed that the security consideration in Section 4 ought not to
appear there.  Someone asked for it between RFC 1766 and RFC 3066, and
Harald put it in, and it remains there.

> concern is raised.

A concern with the use or misuse of the standard, not with its non-use.

> BTW I say otherwise. It is at least through RFC 1958 basic principle and 

Cite the section of RFC 1958 you are talking about, please.  I note
BTW that the second sentence of 3.2 disposes of your desire for
incompatible language tags.

Unintelligible.

> applications may use it. This means what is to be the expected process of 
> a parser reading a langtag. We are here in an ISO debate, not in an IETF 
> debate.

(looks around)

Funny, I thought this was the IETF.

> standard, not a newspaper.

You are missing my point, and I despair of clarifying it for you, but
I will try.  The reference here is to the fact that intelligence
alone is not enough: one also needs guidance from the RFC to determine
how to proceed.

> This prioritization is your personal assumption.

It is you, not I, who have prioritized the goals by claiming that
*the* target of the Charter is to handle things that the ISO
registration authorities do not.

This may reflect a mismatch between English "the" and French "le/la";
the English form has much stronger connotations of definiteness and
uniqueness.  Let me urge you once again to write in your own language;
ce qui n'est pas clair n'est pas franc,ais, whereas English is often
the language of muddle.

Unintelligible.

> Probable mail transliteration. "--" is quoted. You constest the point, 
> but did not provide the reference (I may have missed).

Even with this clarification I still cannot understand your point.

> Debate has shown that authors intended to exclude some.  

Evidence?

> Private assumptions used not to address Charter requirements.

No, no, the burden of persuasion is on you.  You must show why there
is reason not to trust the ISO authorities to do what they have
documented they will do.

> Please propose a more adequate wording than my Franglish.

I will not assume the responsibility of guessing what you might have
meant.  (The Western Alliance, it is said, nearly broke down during
WW II over an incorrect translation of "demander" as "demand" (exiger)
rather than "request".)

> copyright of its author. Would you have an URL for a stable version of 
> the standard? Until I have a final document I cannot comment.

As is well known, official copies of ISO standards are available through
your national body or directly from ISO.  If you want the registry,
it is available at http://www.unicode.org/iso15924/codelists.html .

> Unproductive comment. IETF is Datacoms.

Irrelevant.

> match these "not expected" changes.

That refers to changes in individual codes, not the entire system.

> I documented: http://mltf.org/addmark.pdf.

@@

> IRT the Draft: this concerns additions made by other RFCs.

Ah, extension subtags.  Please make an effort not to confuse technical
terms defined in the draft; it's not conducive to understanding.

> results from his position and from his copyrigths ISO 15924.

Of course Michael does not own the copyright to an ISO standard.
If no one has appealed his decisions, perhaps no one disagreed with
them sufficiently to do so.  That does not make him a dictator.

> Its author will be dismayed from your dispise. The remark certainly hold.

This section is about conflicts between the draft and the charter.
This is not one.

> Charter says ISO 639-3 "in particular", not "exclusively". I will wait 
> for ISO 639-6 and for ISO 639-4 and on MLTF positions to disqualify this 
> point.

You are mistaken about the identity and purpose of ISO 639-4, which has
been explained several times.  Please do your work instead of expecting
others to do it for you.

I will not comment further in this thread.

-- 
It was dreary and wearisome.  Cold clammy winter still held way in this
forsaken country.  The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
        --"The Passage of the Marshes"          http://www.ccil.org/~cowan