Message-Id: <6.2.1.2.2.20050624094307.03ee4eb0@mail.afrac.org>
Date: Fri, 24 Jun 2005 11:22:44 +0200
To: "Peter Constable" <petercon@microsoft.com>,
	"LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] additional changes...
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE0658F9E7@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE0658F9E7@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 00:21 24/06/2005, Peter Constable wrote:
> > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org=
]
>On Behalf Of r&d
> > afrac
> > If I am correct (but I did not look in detail), ISO 3166 codes define
>the
> > name of  the countries.
>
>Need to be careful here: an ISO standard cannot normatively specify what
>a country shall be called.

Glad we agree.

>At best, it can normatively specify how a
>country shall be referred to in conformant implementations of that
>standard. In fact, I suspect that all that ISO 3166 really intends to do
>is to document the political entity/geography region denoted by an
>alpha-2 identifier (or one of the others provided) using English and
>French names for those countries.

No. It does not even do that. It just codifies the English and French nam=
es.
If you wish to know more I suggest you discuss this with G=E9rard Lang to=
=20
have it from the horse's mouth. You know his e-mail. I am sure he will be=
=20
glad explaining you this so you may document this WG in your own words.

> > ISO 639-3 are just codes and autonyms or english
> > names are attached to them. ISO15924 is a list and I am not sure
>anyone
> > knows what a script can exactly be (not clear in the text and in
>Michael's
> > references to it: usually discussed as a reference to the Unicode
> > script.txt file). All this is not ISO 11179 conformant because a
>metamodel
> > must be homogenous and ... clear.
>
>To the extent that I've looked at ISO 11179, I haven't come across any
>conformance criteria. It defines a conceptual model for creating
>metadata registries, and provides some guidelines for handling certain
>tasks within a metadata registry. The langtag registry* implements some
>aspects of the ISO 11179 model, though not all; and I suspect that the
>langtag registry can be fully analyzed in terms of the ISO 11179. Unless
>there are conformance requirements stated somewhere, however, I don't
>think anyone can say that the langtag registry is or isn't conformant.
>(If there were something in the langtag registry that went beyond and so
>could not be analyzed in terms of the ISO 11179 model, then I think one
>might be able to claim some non-conformance. I don't know if that
>actually occurs in this case, though.)

My point is that the Draft could easily be made conformant to ISO 11179 i=
n=20
documenting what it wants to document provided that the resulting metamod=
el=20
is homogenous (no layer violation). This means that you cannot mix concep=
ts=20
and metaconcept as I think we do. Where it would not be ISO 11179=20
conformant would be in assimilating ISO concepts or metaconcept with=20
different IETF concept and metaconcepts. I am not ISO 11179 expert and IS=
O=20
11179 is not a finished document in the areas of concern to us but we bot=
h=20
have ISO 11179 experts (committee members) in our relations and there are=
=20
one or two lurking this list.

So, you fully make my point in saying "I don't think anyone can say that=20
the langtag is or isn't conformant".

- the Charter asks we make sure that the Draft conforms the underlying IS=
O=20
standard, so if you don't know you should work on it.
- obviously there are many people able to say it does not conforms asnd w=
e=20
all know it because ISO 11179 is a very complex thing and in ignoring it=20
the chances we conforms to it probably reach the threshold of the Borel's=
=20
law (probability beyong which something cannot happen).
- you say that the langtag registry implements "some aspects of the ISO=20
11179 model". Does this means "of the ISO 11179 standard" or "of an ISO=20
Model" what makes an important difference. In any case these aspects shou=
ld=20
be documented and the other aspects should at least be listed and=20
explained. This is because their non-support can be understood as a Chart=
er=20
disrespect and lead to security problems. Any user believing that the Dra=
ft=20
is ISO 11179 conformant, in a part where it is not, will face a trust=20
discontinuity. Unless this is documented. Unfortunately ISO 11179 is not =
a=20
decalogue or a check-list of pointg of conformance, it is a complex=20
doctrine and vocabulary.

This is why you have two possible ways to corelate the Internet with the=20
ISO system:

- either you consider the ISO as underlying what you want to do (this see=
ms=20
to be what the charter says) and it calls for still much more unless you=20
document more precisely your scope and the consequences of this limitatio=
ns=20
(what I always proposed).

- or you document the Internet vision of language based on person to pers=
on=20
interintelligibility, as a layer above end to end interoperability,  and=20
you think as a network architect, addressing the real world multimedia=20
issues. This should result in a cross network technologies converging=20
clear, simple, stupid, scalable description in a few paragraphs. Then you=
=20
build from it a standard support framework. Then you relate that=20
user/reality based network modes to other modes through RFC like the=20
langtag/filter for XML and the protocols which may want to use it.

But you cannot stay in between focusing on a single application case.=20
Because, even for that application case, the result will not stand: at so=
me=20
stage it will be incompatible with other aspects of reality and you will=20
have to build another interface, and another, etc. until you are stuck.


>* Ditto wrt ISO 639, ISO 3166 and ISO 15924.

No. I took the example of ISO 3166 because it is the most referred to=20
standard, the clearest in term of what it defines (due to its multiple=20
tables) the oldest too (started in UIT in 1865). And I documented that IS=
O=20
639 and ISO 15924 were different and that their correlation with ISO 639=20
and ISO 15924 was precisely a subject under study, within the ISO 11179=20
(and others) framework by TC 37.

Why to hide this WG that what it considers is also discussed by the peopl=
e=20
in charge of the documents this WG has the charter to respect? Is this=20
because the Draft of this WG is precisely used to document the ISO debate=
.=20
Please be clear: there is actually a joint work between ISO and IETF on t=
he=20
same issue, for the same result, where you want a convergence.

We all want a convergence. We may even agree with your idea that this=20
convergence is based upon your propositions. But we cannot accept that th=
is=20
is not transparent and that this is based _only_ on your ideas. All the=20
more when you come and say you don't know if their common glue (ISO 11179=
)=20
applies, and Debbie Garside says ISO 639-6 wants to be ISO 11179 conforma=
nt=20
and I say they do not match the whole Internet architecture.

> > One of the major discrepancy you face is about "script", because you
>are
> > specifying "langtag" for a multimedia system and use two general
>attributes
> > (languages and country) and a specialised one (script) making yoursel=
f
> > incompatible with all the non written modes.
>
>As Jefsey has acknowledged in the past, the draft does not create any
>incompatibility with non-written content: it can be applied equally well
>to written and non-written content alike.

True. But that I acknowledged that it _can_ only documents that we may=20
reach an agreement, not that it is documented in the Draft :-) But you ar=
e=20
most welcome adding it and foreseing the registration procedure. This Dra=
ft=20
only refers to ISO 15924.

Also, Peter's response denotes a substantial difference in conception whi=
ch=20
affects the whole issue.

- Peter speaks of "written and non-written content alike". This means tha=
t=20
the reference is the content (i.e. the value)
- I speak (so is ISO) of mode. This means that the reference is the=20
container (i.e. the concept).

This may seem a slight difference but this is the whole issue. This Draft=
=20
considers a langtag in a W3C vision, this means based on content. There=20
have been documentation enough that adverse changes in formats would affe=
ct=20
huge existing content (forgetting that XML is a young format and that it =
is=20
likely than in the coming decades and centuries much more content will be=
=20
affected by the langtag).

My position, as is ISO and as is to be by nature IETF is on modes, that i=
s=20
to say in exchange parlance on protocols. What is considered is the=20
concept, the container. Why? Because the same information (concept) on=20
language, script and region (not to mention the needed information on=20
referent and context I say needed) can be conveyed in many different ways=
=20
(values) associated to the content. I will take two to make this clearer:

- the Charter says we must use ISO 639, with a mention of ISO 639-3 as an=
=20
example. We can understand this in two different ways (Peter can probably=
=20
better document as he most probably shared in the writing of the Draft).=20
Either this means that ISO 639-3 is the leading part and that the IETF=20
Draft is to establish the guidelines ISO is establishing in ISO 639-4, or=
=20
it means that ISO has already two code versions to document some language=
s=20
and will add two more, starting with ISO 639-3 and then ISO 639-6. The=20
charter the means that this WG should not only focus on ISO 639-1 and -2=20
but on new documents starting with ISO 639-3. This and its consequences a=
re=20
to be documented in the Draft.

- there is no definition of a language given. There is no rule given to=20
associate the language of an exchange to a language code. There is no=20
documentation to say if the language codes are used as values ("this is=20
English") or as concepts ("this is a version of English"). I can associat=
e=20
filtering rules which will define the script and language from the conten=
t=20
(this is what we do mentally all the time). The problem is that it is not=
 a=20
commonly accepted authoritative statement we can trust and build=20
applications upon. The is no ISO-English.

To be better understood I will take an example: the lang3tag is going to=20
tell me "this is English" and I may have a conflict with my Franglish=20
(Randy fully documented that). I will have a vital security issue if the=20
"English" security alert was expressed an English I do not understand (my=
=20
Franglish is usually more extended than Basic English). Example "en-Latn =
->=20
in case of Danger depress key 'D'" and "en-Latn -> in case of Danger hit=20
key 'D'", because 'style' was missing and I did not call Randy's experts,=
 I=20
am dead. Security consideration due to ISO 11179 disrespect: "English" I=20
took as a value was a concept.

Last example, fully documented by this WG. This WG assumes that the=20
difference of positions with me are due to my poor Franglish (cf? Randy)=20
(sorry to refer to me again, but it makes a good example of cooperative=20
international relations, before being confronted to agressive multilingua=
l=20
issues of the real life). This common belief makes a dangerous alibi whic=
h=20
hides the WG that in most of the cases if I am not "corrigible" it is=20
because I am right, or at least consistent with a general position they=20
refuse to consider.

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru