Message-Id: <6.1.2.0.2.20050407161438.0513ec50@mail.jefsey.com>
Date: Fri, 08 Apr 2005 00:27:10 +0200
To: John Cowan <jcowan@reutershealth.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] draft review
In-Reply-To: <20050407135146.GI1795@skunk.reutershealth.com>
References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com>
	<20050407135146.GI1795@skunk.reutershealth.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear John,
I thank you for this review. If I am correct my response here should only=
=20
be to say if I maintain the point or if I accept that your objection is=20
correct and I should remove it?

There are many comments which root in a different vision of the Internet=20
and of the Charter. I note them the first time they occur. They should be=
=20
debatted separately. Some mignt lead to the need of a call on an IAB=20
Guidance, due to their fundamental aspect for the Internet, if theyr were=
=20
still shared by a significant proportion of the score of participants to=20
this WG.

At 15:51 07/04/2005, John Cowan wrote:
> > 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 syste=
m.
>
>The analogy is vague and specious, and utterly ungrounded in the text,
>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=
=20
confusion about what is the DNS and its main usage. This is a common=20
confusion. I suggest you study STD 013. I will not comment your further=20
allusions to 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 th=
e
> > "-" as a separator which is more confusing and may have less identifi=
ed
> > 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.

Not a objection to a factual remark. The point is not that the format wou=
ld=20
be wrong, but that the format wants to be unique and general. This=20
misunderstanding affects most of the remarks about the format. I will=20
therefore not comment it, only the specifics of each point.

> > 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 exter=
nal
>cannot possibly adjust in advance to radical changes of an unknown natur=
e.

The charter is precisely about making the format independent from externa=
l=20
elements. This confusion is part of several reponses. I will not comment =
them.

> > 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.

This is precisely the point. The way this RFC is writen and applied makes=
 a=20
real difference with the Draft. Here is were comes the risk.

> > 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 2=
00
>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=
=20
point is not in the access to the ISO document, but the inability of the=20
proposed format to support IANA registrations of ISO 3166-2 equivalents.

>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.

This is precisely the second point. When they do that it is usually for a=
=20
reason which is regionally or locally the same as ISO 3166-1 at national=20
level. This is what makes ISO 3166 consistent, but not the proposed forma=
t.

> > 18.   2.2.1: primary language: fixed length identification starts
> > with 2 or 3 and possibly 8 but discouraged language ID coming this wa=
y
> > 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.

Document the "more than enough" please. There is a general trend in these=
=20
remarks to assume things. This is also a noted remark of the Draft. Rathe=
r=20
than to discuss them I will note the remarks made on assumptions. To be=20
constructive we should discuss these assumptions separately and probably=20
list them as a leading part of the Draft, indicating the real scope of th=
e=20
Draft. What I can only support.

  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.

Yes. We are in agreement. You therefore do not contest the validity of th=
is=20
point. Its discussion is obviously another thing.

> > 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.

This represents a certain lack of legal international culture. The French=
=20
law used in the Yahoo case (which has equivalent in the world) makes this=
=20
illegal. It is also most probably a case to be made with the WTO as an=20
unfair commercial advantage. We are here discussing standards. Standards=20
concerned with stability (if they are stable and used they probably are=20
adequate). The legal enforcement of a change in Standard is then real fea=
r=20
we should share.

> > 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?

I do not understand this point. The point is not to re-mark-up billions o=
f=20
existing documents (backward compatibility will address that) but to save=
=20
the money that trillons of clumsy tagging will cost. Improving on somethi=
ng=20
existant is usually for a ROI.

> >  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.

I was refering to the origin of UK being used instead of GB. I know this =
is=20
because Mr. Peter Jones. I will know and will be able to tell my grand-so=
ns=20
that I also know the lang3tag origin....

> > 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.

Same comment as Scott Hollebeck's remark as about ABNF format.

> > 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?

This can be certainly be discussed.
Could you write a few lines on this. A Draft writter should not assume=20
three things:
- that his readers are intelligent - I know this is a fault I commonly co=
mmit
- that his readers know things which are not documented in the Draft (nee=
d=20
of an explanation or of a link)
- that his readers share his visions, this is why he has to explain them =
so=20
they understand where he comes from and adapt.

> > 21.   2.2.3: Script subtags follow the same rigid logic and constrain=
ts
> > 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.

Charter. This is also easy. I do not see any "massive" change here.

> > 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.

:-)
Your comment is serious. Let stay this way.

> > 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 disparit=
y
> > can hold very long, all the more than ISO 3166-2 provides all the
> > possibilities for a far more adequate granularity.
>
>See above.

wart? agree.

> > 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.

Document it. This is a standard, not a newspaper.

> > Otherwise this part is to be understood as a disguised way, concerted
> > with ISO, to block names.
>
>There is no evidence for this allegation.

Many in ISO question ISO 15924 document. IETF and IANA have massive=20
additions (starting with DNS Tables), Michael Eversom already made clear =
he=20
will not consider. Being on both sides there is a CIO with the current te=
xt.

> > The concern on this point is high enough to see the Draft blocked.
>
>Whose concern?  Blocked by whom?  Vague and unfounded.

Unless IESG drops the rule of consensus, there is no possible consensus o=
n=20
the present Draft. I am a documentation of it. At the present stage I can=
=20
only oppose. This is why I try to see my opposition reduced. But this is =
a=20
consensus process, not a compromise and obviously not an enforcement=20
process. This means that at the end of the day APMD and I must be equally=
=20
satisfied with the result.

> > 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.

I was polite.

As a general comment, an RFC is an IETF delivery to readers. What counts =
is=20
not what the authors intended to say but what the readers will understand=
.=20
This is why the last call, the IESG and the Editor contribute after the W=
G.=20
This is why also all the RFC do not become standards. This case is=20
particular due to the status of BCP 047 of the RFC 3066.

> > The general idea is precisely in opposition with the purpose of the
> > proposed RFC: to be able to register names not registered by ISO. Thi=
s
> > 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.

No. Such a legitimate preoccupation would be satisfied by a registration=20
except if a serious documented objection is risen within a 15 days=20
consideration period _and_ documented (for the very point you make) by th=
e=20
ISO MA.

> > 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.

???
Unless you agree with my comment that these proposition do not make real =
sense.

> > 25.   2.3: recommendation 3 seems inappropriate. Aliases are aliases.
> > All the aliases must be equally supported because (a) they are aliase=
s
> > (b) to make sure developers develops correct code.
>
>All aliases are equally supported.  Not all aliases are equally recommen=
ded.

Not the text.

> > 26.   2.4. "language tags always define a language as spoken by human
> > being for communications of information to other human beings. Comput=
er
> > languages are explicitly excluded" has no ground in the Charter and
> > in reality.
>
>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=20
is meant to correct. Impeaching supported Internet applications to benefi=
t=20
from ISO 639-4/6 probable positions, together with a disregard of the=20
Charter, is a responsibility I will not assume.

But it can be discussed it in your assumptions.

> > Web Services relations are excluded which may speak limited languages.
>
>Do you suppose that SOAP is a language?

I have difficulty in understanding the question.

> > Coded human languages should be supported: they fit the definition.
>
>What is a coded human language?

arbaille.

> > 27.   2.4.1: in the canonicalization part "" is reminded as a
> > deprecation indicator, yet this is not documented earlier. It seems t=
his
> > is an external ISO practice. This should be documented in the format
> > description part. All the more than this practice is counter intuitiv=
e
> > "" 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.

Please give reference of the part. May be I missed it.

>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.

Sure. But this is not a reason to use a wrong term.

>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 i=
t
> > or to present it in HTML form. This does not help its automated readi=
ng.
>
>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-processabl=
e.

There is mine. As you may know I maintain a daily survey of some IANA fil=
es=20
(http://ccmso.org/intldate.txt - http://ccmso.org/intlfile.txt) and=20
langtags will certainly be included in it.

> > 38.   4. security considerations should not deal with users political
> > security outside of their network usage. Otherwise tons of such
> > considerations should be presented.
>
>The point has been raised and is documented.

I do not understand this comment. I raise the point. Please indicate the=20
documentation?

> > 39.   4. An important security consideration is homographs. It is
> > certainly possible to include part of text in a foreign language whic=
h
> > 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.

Security considerations are where people will go and look when a security=
=20
concern is raised. Again this is a standard, not a newspaper or a lawyer=20
defense. The "at most" means we agree: there is an impact. The role of th=
e=20
security considerations part is to discuss it. It can be positive or limi=
ted.

> > 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 spac=
e.

Private assumption.
BTW I say otherwise. It is at least through RFC 1958 basic principle and=20
consistency rule.

> > 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.

Private assumption.
Several on-going debates (WebDAV, LDAP, DNS) in addition show that the=20
point start being a point of consensus.

An important issue is that the Draft _does_not_document_ in which way=20
applications may use it. This means what is to be the expected process of=
 a=20
parser reading a langtag. We are here in an ISO debate, not in an IETF de=
bate.

>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 mechanis=
m
> > described in the next document. This text has not been adapted after
> > the split.
>
>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 resp=
onse.

> > 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 syste=
m
> > (http://bootstrap.org).
>
>Irrelevant.  The draft says that *even* intelligent people may do
>inconsistent things in the absence of guidance.

The reference given is to the root of the "IETF core values" and to the=20
idea of the founders than computers augmented the intelligence of a=20
bootstrap (a concept today translated in WGs). The best reading is=20
therefore "even for the members of the WG" which is an acceptable=20
auto-derisive remark. Beyond that, the remark is hurting. This is a=20
standard, not a newspaper.

> > 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.

This prioritization is your personal assumption.
You do not constest the goal. This qualifies the remark.

>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.

Probable mail transliteration. "--" is quoted. You constest the point, bu=
t=20
did not provide the reference (I may have missed).

> > 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.

Debate has shown that authors intended to exclude some. This is unadvisab=
le=20
since it can only kill consensus possibility.

> > 49.   The charter lists RFC 3066 problems. These problems are: (a)
> > stability  there is a paragraph on the matter; (b) accessibility to t=
he
> > 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.

Private assumptions used not to address Charter requirements.

> > (c) difficulty with registration and acceptance: this could be improv=
ed
> > 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.

Please propose a more adequate wording than my Franglish.

> > (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.

I am not sure of the ISO 15924 copy I have. It wears the name and the=20
copyright of its author. Would you have an URL for a stable version of th=
e=20
standard? Until I have a final document I cannot comment.

> > region are 2 letter Telex codes;
>
>They are part of an international standard, whether originally
>derived from Telex codes or not.

Unproductive comment. IETF is Datacoms.

> > (f) lack of parseability and well-formedness : this has certainly bee=
n
> > addressed [it seems to be both the major improvement of the Draft
> > )B=85 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.

all the more if the Charter says that you are to document how they will=20
match these "not expected" changes.

> > 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 concis=
e
> > way. RFC 3066 represents roughly 17.000 characters and the draft 70.0=
00
> > (out of the IETF format and verbose).
>
>Out of the IETF format in what way?

I documented: http://mltf.org/addmark.pdf.

> > 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.

IRT the Draft: this concerns additions made by other RFCs.

> > 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.

Yes it is. De facto as I observed the mailling list. In the way a CIO=20
results from his position and from his copyrigths ISO 15924.

> > 51.   it lists challenges to be addressed. Stability: "how the langua=
ge
> > tags remains stable even if the underlying references should change".
> > This means a process where the tag name is unrelated to its underlyin=
g
> > 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.

DNS.

> > 52.   it lists challenges to be addressed. Accessibility: "a simple w=
ay
> > 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.

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.

> > 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.

No answer above, disqualifies this question.

> > 54.   it lists challenges to be addressed. "provide mechanism to supp=
ort
> > 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 supporte=
d,
> > 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.

Charter says ISO 639-3 "in particular", not "exclusively". I will wait fo=
r=20
ISO 639-6 and for ISO 639-4 and on MLTF positions to disqualify this poin=
t.

> > 55.   it lists challenges to be addressed: "to specify a mechanism fo=
r
> > easily identifying the role of each subtag  in the language tag". Thi=
s
> > 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.

DNS. This makes no sense to me.


As a general comment. This review is interesting. It underlines the need =
to=20
have the throughout review of the charter we did not initially carried. I=
t=20
shows there is a misunderstanding about consensus process we have to=20
clarify. Also that the target is not to enforce a format but to get=20
backward compatibility with a new format. It also shows the need for the=20
score of participants to this work to know better about the other "client=
s"=20
of their intended deliverable. I will try to word an begning of analysis =
of=20
the use of the langtag, for everyone to add to it.

It also starts some additional small debates and possibility of tuning,=20
both for the draft and for my own position. I therefore thank John for th=
is=20
work and wait for the next batch of comments. I will also delay my own=20
draft to permit comments to come in (as also indicated by Randy's mail) a=
nd=20
permit my own mailing list to review them before.

Best regards.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru