Subject: [Ltru] draft review

From: Jefsey Morfin <[email-masked]>
Date: Tue, 05 Apr 2005 00:10:23 +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