Subject: [Ltru] Publication request for <draft-ietf-ltru-registry-12.txt> as RFC (BCP)

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 22 Aug 2005 12:34:05 -0700

Hi -

This questionnaire and write-up is being sent to the responsible
Applications Area Director, Scott Hollenbeck, <[email-masked]>,
and to [email-masked] as a request for the publication of
ltru working group document <draft-ietf-ltru-registry-12.txt> as an
RFC, to obsolete RFC 3066 (BCP 47).

The detailed response to question 1.f (on appeals) has
been sent separately to the responsible AD.

The shepherding co-chair for this document is Randy Presuhn,
<[email-masked]>.

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

yes

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has received detailed review within the ltru WG.  Reviews
have been solicited outside the working group, but to date none have
been received.  Given the depth and breadth of expertise of the working
group's members, we are not concerned about the adequacy of the review.

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Strong (rough) consensus, with one outlier.

   1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

Yes, details supplied separately.

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

   1.h) Is the document split into normative and informative references?

Yes.
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?

There is a reference to ABNF <draft-crocker-abnf-rfc2234bis-00.txt>,
which is currently in the RFC editor queue.  There are no other
normative references to internet-drafts.

        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

Technical Summary

   This document describes the structure, content, construction, and
   semantics of language tags for use in cases where it is desirable to
   indicate the language used in an information object.  It also
   describes how to register values for use in language tags and the
   creation of user defined extensions for private interchange.

   This document was produced as part of the effort to develop a
   successor to RFC 3066, and is the primary deliverable the working
   group was chartered to produce.

Working Group Summary

   Use of the existing IANA Language Tag registry revealed several
   shortcomings, leading to the development of this document.
   In addressing the requirements of its charter, the working group
   found it necessary to significantly change the registry format.
   Since language tags are used in a large number of protocols and
   formats, the working group maintained compatibility with existing
   language tag syntax, though it did change the syntax of registry
   entries and updated the procedures for the maintenance of the
   registry.  There was strong consensus on all of these.

   Two issues are noteworthy for the amount of debate needed
   before the working group was able to reach rough consensus on
   them.  The first was the order of subtags, in particular of the script
   identifier.  The second was the "Suppress-Script" registry field.
   These two are closely related, and the tradeoffs involved a desire
   to avoid re-tagging existing data and a need to keep the tag format
   syntactically compatible with existing software, versus a desire
   to provide a tag structure that was in some ways more consistent.
   The working group opted for compatibility and avoiding re-tagging.

Protocol Quality

    This document received extensive review and discussion within the
    ltru working group.

    Since language tags are used in a large number of protocols and
    formats, the working group maintained compatibility with existing
    language tag syntax.

    At the time of this summary, likely additions to the registry had
    already been discussed, but the WG agreed that since such
    changes are part of the normal operation of the IANA Language
    Subtag Registry, they should be handled on the mailing list
    [email-masked] after the registry has been initialized.

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

---

From: r&d afrac <[email-masked]>
Date: Tue, 23 Aug 2005 03:45:14 +0200

The following few comments are in order:

>group's members, we are not concerned about the adequacy of the review.

The documents does not even allude to languages as used in a specific 
networked context. This denotes that the small score of experts 
involved are no experts in that area. The planned participation 
statistics to the WG will document this.

>         complexity, someone familiar with AAA, etc.)?

Languages as interintelligibility protocols are one layer above 
Internet interoperability protocols and support interculturation 
processes. This is a domain commanding the whole development of the 
digital ecosystem relational continuity and usage architectures. It 
is certainly of high complexity: it involves 20.000 listed languages 
(in ISO 639-6 project) and actually the different individual forms of 
speaking, reading and exchanging of 6.5 billions of persons. This may 
amount to thousands of billions of linguistic versions.

Everyone can understand that the attempt to tag them through a 
reduction of the RFC 3066 flexibility is a challenging task calling 
for a pervasive acceptance, an IETF WG (or any WG) cannot deliver at 
this time, with the current status of R&D in the different concerned matters.

>         document, detail those concerns in the write-up.

This WG-ltru obviously has not the technical expertise, the cultural 
consensus and the political support to decide of a IANA language 
identification system users should universally adhere to (BCP). It 
has however the technical expertise, the application need (to be 
confirmed) and the commercial support to document one of the ways 
some Internet users and software publishers could use.

The personal user's risks represented by this langtag system calls 
for high civil society concerns, as it associates a language to a 
Government political line. This may put the IESG at the apex of a 
major political and human right diatribe, in particular at the WSIS: 
it may not be what the IESG wants.

>Strong (rough) consensus, with one outlier.

This consensus is a silent consensus by exhaustion. The WGLC did not 
lead to significant expressed support even of the leading affinity 
group (20% of the Members). As the outlier I will add (as explained 
many times) this was a deliberate effort of mine to keep a working 
relation between the real world and the WG, while preventing the WG 
to be overthrown without real signification and a waste of time for 
all by an opposing group of scholars.

I note that this WG on languages issues is overwhelmingly manned by 
people having the same linguistic vision (English mother-tongue) and 
that an attempt to participate from different vision was qualified of 
"troll" leading the concerned academic person to leave.

>Yes, details supplied separately.

I wait for a courtesy copy of these details to make sure the IESG is 
correctly informed. I proposed the authors of the PROTO Draft to make 
this transparency the rule and not a courtesy.

>    group was chartered to produce.

This document pretends to be _the_ successor to RFC 3066. Should it 
not claim to replace BCP 47 and to support a future global language 
support framework for a Multilingual Internet as indicated here, 
permitting to immediately document and support other language tags 
formats adequate to the users needs, open source projects and current 
developments, there would be an unanimous acceptation of the document.

What is objected is not the content, but the IANA exclusivity and 
status quo: the exclusion of competing solutions and innovation.

>    found it necessary to significantly change the registry format.

Not correct. The very basis of this WG is an undocumented "consensus" 
"obliging" to strictly respect the RFC 3066 ABNF up to
- the absurd obligation to respect old blocking formats for new 
applications (which by nature never used them)
- and the refusal of an escape sequence permitting to seamlessly 
introduce other formats and new developments.

The Charter has never been discussed by the WG.

>    registry.  There was strong consensus on all of these.

"maintaining compatibility" does not means here that the new format 
must support the old format.It means that the old format had to 
contain the new format. This "retro-compatibility"has been qualified 
of "reverse compatibility".

>    identifier.

The script identifier position does not result from a debate of the 
WG but from the continuation of the Addison/Davis Draft which was the 
only discussed matter, from the very fist day of the WG. The lack of 
debate lead in particular to disregard several important issues:

- the lack of documentation of the oral modes. While langtags are 
supposed to be for every usage, voice, sign, etc.attributes are not documented.
- the lack of documentation of the language identification main 
attributes such as the referent system (dictionary, publisher, etc.) 
and the context (style, relation, space of exchange, etc.) and the 
date of publication. Even without being a human relations specialist 
one can understand that what Words supports (dictionary, style, 
version) are elements important to the identification of a content vehicle.

The Draft organises and protect a langtag scarcity. This has serious 
reasons, but these reasons should have been discussed, analysed and 
better addressed. It also represents important commercial and 
industrial interests. The same they should be discussed and an equal 
opportunity for all the concerned stakeholders protected. These 
points have never been investigated.

>   The second was the "Suppress-Script" registry field.

This is another "script only" issue, underlining the WG-ltru did not 
considered multimodal aspects.

>    The working group opted for compatibility and avoiding re-tagging.

This translates the desire to impose for ever a closely constrained 
exclusive format, the status quo of which will benefit to market 
dominants, excluding innovation, pretending that other projects 
re-tag into an inadequate approach.

That attitude can only lead to competition (called by the author: 
"that the best win") between solutions instead of an inclusive 
support of the various user needs and existing/future systems. A 
competition, due to the care importance of the matter to users, can 
only lead to a "tag war", where the only losers will be the IETF, the 
IANA and the users.

>     formats, the working group maintained compatibility with existing

Incorrect. The Charter quotes existing use in HTML, XML, CLDR. HTML 
has not been much discussed. XML has. CLDR has not been, nor even 
been documented (while it is a project conducted by one of the 
authors). Clarifications concerning the CLDR's IPR issues have been 
denied- while the concerns for Open Source are serious. Relations of 
the language tags with LDAP have been partly considered. DNS, OPES 
and programming languages were denied consideration. One or two other 
protocols have been alluded to. No systematic review of all the 
possibly affected protocols has been carried by the WG.

>     [email-masked] after the registry has been initialized.

Incorrect. A Draft has been produced to build an initial registry one 
shot. The IESG should be aware that some entries may rise some 
political controversies.

There is currently not such a list as "[email-masked]". 
There is a alias of that name for the real list 
"[email-masked]". As a result it has not the 
international recognition it should, to warranty a transparent 
process. The organisation of this list creates problems not addressed 
by the Draft; they directly engage the responsibility of the IESG:
- selection and renewal of its reviewer by the IESG
- management of the list - its current manager uses its private 
nature to assimilate it to IETF mailing list, without providing 
appeal protection
- technical expertise of the reviewer is only script oriented
- there is no liaison with other SDOs possibly relying on langtag 
IANA registry entries.

A major point of concern of this registry is its real use by users 
and therefore of its real operation cost and operational feasibility. 
This point has been discussed without offering a documented scenario.

These are only quick comments on the current write-up. They represent 
only a small part of the planned comments for a Last Call and for 
possible IETF, IAB, IANA, etc. appeals.

They would be immediately removed should the intent above of not 
replacing BCP 47, but to only be one of the contributions to a BCP 47 
replacement was confirmed and the concerned sentence to be reworded 
accordingly.

jfc morfin
AFRAC,vp r&d