Tags for Identifying Languages
draft-ietf-ltru-registry-14

Appeal reviewed and denied by the IESG on 6 November 2005.  Announcement to be sent.  Documents will be approved after the IESG decision is made public.  I just have one last question to address with the RFC Editor about BCP status and the matching draft.

IANA Comments:
Upon approval of this document, the IANA actions are as follows:
The following 2 registries will be marked as OBSOLETE (these will not
be added to or modified).
http://www.iana.org/assignments/language-tags
http://www.iana.org/assignments/lang-tag-apps.htm
The IANA will create/maintain 2 registires:
Language Subtag Registry
Extensions Registry

[Ballot discuss]
A minor typo in the ABNF: there needs to be a space in between the ) and [ of

field-name = (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]

'(ALPHA/DIGIT)' and '[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]' are both , which is a degenerate of , and concatenation is

concatenation  =  repetition *(1*c-wsp repetition)

note 1* = at least one whitespace

[Ballot comment]
I think that as this draft is structured today, it needs to be a BCP.
I do share the concerns of those who believe we may have gotten
something wrong and that we wish we had a good mechanism for
incremental updates or for progression.  I don't think calling this a
proposed standard gives us any of those things; it just confuses what
is going on.  I hope we're right with this draft or the mess will be
impressive.

I'd like to thank Scott and the WG chairs for all the hard work in
dealing with the /last call.  I found the summary absolutely essential
to reviewing the discussion.  I did end up going back and reading most
of the messages, but the summary was quite useful in focusing my
efforts.

I explicitly evaluated the security concern regarding privacy and
information exposure through tags. q I think the current text in
security considerations is appropriate for that issue.

[Ballot comment]
In section 3 of draft-ietf-ltru-initial-05, it might be useful for the
  document to include the URL of the IANA registry.  It seems to me that
  anyone interested in this document will want to locate the IANA
  registry too.

[Ballot comment]
Disclosure: Mark Davis, co-editor of draft-ietf-ltru-registry,
works for the same employer as me, but in a different department.

Editorial nit from Gen-ART review by Elwyn Davies:

The new title of Figure 2 should be 'Registry Record Format' and not
'record-jar format' (which it isn't in any case).

Per an IESG discussion note from Sam, who requested "a statement from you that you've reviewed the ietf discussion and you believe that there are no IETF consensuses that are in conflict with the group".

I have reviewed the working group discussion, last call discussion, and the group's efforts to address comments received during the working group and IETF review process.  I believe that the current documents accurately reflect community consensus, with one issue unresolved: should draft-ietf-ltru-registry-13 be published as a BCP or a Proposed Standard RFC?  IESG guidance is requested; the working group can live with either option.  BCP is the current intended status because RFC 3066 is BCP 47 and the group has been chartered to produce "a successor to RFC 3066".

A summary of IETF last call comments and the working group's actions taken to address those comments can be found in the archives of the group mailing list:

http://www1.ietf.org/mail-archive/web/ltru/current/msg03807.html

AD evaluation comments:

It's common practice to note documents being obsoleted in the first page
document header.  It should be noted that RFC 3066 is being obsoleted.  This
can be done using xml2rfc as follows:



Yes, I noticed the text in the introduction.  Both are needed.

This is not a significant issue.  Add it to the queue for processing after
the last call has been completed.

Question 1.f writeup (long):

This is the write-up for section 1.f (on appeals) for the publication
request for , which will be sent out
shortly.

There have been numerous threats and allusions to threats to appeal
by one WG participant, Jean-Francois Charles Morfin, also known as
"Jefsey", "jfc", etc.

It is difficult to present the substance of these in any coherent
manner.  The key concerns seem to be the following, as raised
in various threats to appeal on the working group mailing list:

http://www1.ietf.org/mail-archive/web/ltru/current/msg01326.html
  (1) a desire to add *translations* (not just the native names
      and the identifiers from the source standards) of various
      fields in the registry.  The WG consensus on this issue was
      to provide UTF-8 support so that the native name(s) of languages
      could be included, as well as references, but there was opposition
      to treating the registry as some sort of language name localization
      database.

http://www1.ietf.org/mail-archive/web/ltru/current/msg01379.html
  (2) the belief that issues raised in his messages did not receive
      adequate discussion.  This assertion has found no support on
      the working group mailing list.

http://www1.ietf.org/mail-archive/web/ltru/current/msg01487.html
  (3) the belief that the syntactic limitation of language tags to
      ASCII (for reasons of backwards compatibility with existing
      protocols and applications which employ language tags) is somehow
      discriminatory.  The WG discussion gave a clear consensus that
      language tags are not intended for human consumption, and that
      the costs of changing the repertoire would far outweigh any
      conceivable benefits.

http://www1.ietf.org/mail-archive/web/ltru/current/msg01539.html
  (4) this one seems to be a general dissatisfaction with the WG's
      trying to stick to the terms of its charter and timetable, as
      well as the use of the RT (https://rt.psg.com/) system used
      by other working groups as an issue tracker.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03029.html
  (5) an objection to the charter's direction to the working group
      to produce a "a successor to RFC 3066" (the charter's words),
      and an insistance that it should instead "complement RFC 3066".
      No one else supported such a change.
  (6) a desire to change the language tag syntax (ABNF) to permit
      productions that would have been forbidden under RFC 3066, etc.
      This proposition was repeatedly reject by the working group,
      receiving no support from any other participant.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03069.html
  (7) We're not sure what he's trying to say here.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03084.html
  (8) This one probably is referring to his intention to produce
      a competing language tag registry, which does not conform
      to the agreed syntax in this document and which is not
      compatible with the syntax used in RFC 3066, etc.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03087.html
  (9) appears to be driven by a profound misunderstanding of what
      the significance of the BCP designation implies.  He seems
      to believe that adoption of this as a BCP would somehow
      prohibit other ways of identifying languages in other contexts.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03207.html
  (10) seems to be about alignment with ISO 11179 (WG rejected
      this issue) and an objection to identifying the editors'
      affiliations (IETF practice)

http://www1.ietf.org/mail-archive/web/ltru/current/msg03274.html
  (11) is about the use of language tags for speech and other
      non-textual forms of language.  The WG already agreed that
      the draft is adequate for such uses.  he also tries to
      resurrect the decision (ratified by the WG) to limit its
      scope to human language, and exclude such things as programming
      languages from its scope.

http://www1.ietf.org/mail-archive/web/ltru/current/msg03330.html
  (12) he objects to the co-chair extending the period for comment
      on an issue to permit participants in Asia, Europe, etc. time
      to comment.  Other WG members supported the time allotted as
      reasonable and sufficient.  (The substance of the issue in
      question was whether to add a file-level "description" field
      or a way to insert comments not associated with any record
      into the registry file.  This would have no impact whatsoever
      on the use of language tags or on the registration process.)

http://www1.ietf.org/mail-archive/web/ltru/current/msg03360.html
  (13) seems to be focused on a misunderstanding of the meaning of
      "BCP" status, but in followup also revisits a question of
      how mailing lists are hosted, which was discussed and rejected
      by the working group.

There may be others, but we think these are the majority of the
questions on which he might try to appeal.  We think all are
without merit, and are at odds with clear working group consensus.

This participant also threatened or alluded to appeals in
these off-list messages:
==============================================================
Status:  U
Return-Path:
Received: from montage.altserver.com ([63.247.76.195])
by samuel.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1dlAsq4Of3Nl3pv0
for ; Wed, 13 Apr 2005 01:30:34 -0400 (EDT)
Received: from lns-p19-1-idf-82-251-86-165.adsl.proxad.net ([82.251.86.165] helo=jfc.afrac.org)
by montage.altserver.com with esmtpa (Exim 4.44)
id 1DLaSP-0002bj-Tc
for randy_presuhn@mindspring.com; Tue, 12 Apr 2005 22:30:34 -0700
Message-Id: <6.1.2.0.2.20050413033840.03359eb0@mail.jefsey.com>
X-Sender: jefsey+jefsey.com@mail.jefsey.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 13 Apr 2005 07:29:52 +0200
To: "Randy Presuhn"
From: "JFC (Jefsey) Morfin"
Subject: Re: recently-approved tags
In-Reply-To: <00b501c53fc7$716c6c60$7f1afea9@oemcomputer>
References:
<6.1.2.0.2.20050412221722.055e2eb0@mail.jefsey.com>
<000d01c53fbf$2d4aafe0$7f1afea9@oemcomputer>
<6.1.2.0.2.20050413023022.0331b3b0@mail.jefsey.com>
<00b501c53fc7$716c6c60$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - mindspring.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-ELNK-AV: 0

[private]

At 03:23 13/04/2005, Randy Presuhn wrote:
>You spoke of participation by European, Asian, and African students.

Yes.

>Do you believe their participation would be more disruptive than yours?

My participation is not disruptive. It is systematically counter objected
and twisted to that end (I regret it is without humor - BTW John Cowan's
post is so clumsy we are satisfied for the time being: we will show it to
our relations ). We both know you try to fool the IESG. So they do not
listen to my last call objections and appeal.

I object a poor Draft which already failed two last calls and has not even
been reworked. Even if you fool the IESG, win in appeal and have Editor
rewording it, it will not fly. I, you, we, they know it. Addison eventually
documented it is an XML patch, it does not know about DNS, etc. and is
ignorant about OPES and my own CRC needs. As such is it harmful to the
network as a BCP. IETF is so uninterested in languages that they do not
realize that. Until they realize it or you prove me wrong in seriously
discussing the Multilingual Internet, I will defend the Internet against it.

>If so, why?

Because serious people who understand what you try hate it. As I explained
it many times, I see further and I think this could be an opportunity to
make IETF understand. But I have to convince.  And you do not help  in
having none of the serious Charter issues discussed.

I fully understand you delay me this way. But I am concerned by a network
by the people for the people. This has cons and pros. One pro is time.
Something Mark Davis has not. Michael (may be not the Chinese Gov...)
agreed on his Chinese tags, making you believe you won the day, but you
still have to fool the IESG and get accepted by the IETF with the exact
very same Draft.

Even if I have not a green light for my Draft before May, I doubt you can
make it before September. Brian Carpenter may want to closely at the lack
of change. Then what are we targeting, counting appeal and IANA, December
or February. And then?

Had you (the W3C/Unicode team) accepted John Klensin's proposition, RFC
3999 would have patched the XML, and we would be working on BCP 047
seriously in line with the preparation of ISO 639-4.
jfc

==============================================================
Status:  U
Return-Path:
Received: from montage.altserver.com ([63.247.74.122])
by samuel.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1dtlrr1X73Nl3pv0
for ; Wed, 4 May 2005 11:05:37 -0400 (EDT)
Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org)
by montage.altserver.com with esmtpa (Exim 4.44)
id 1DTLRP-0006uI-Ug
for randy_presuhn@mindspring.com; Wed, 04 May 2005 08:05:36 -0700
Message-Id: <6.2.1.2.2.20050504134407.033f9040@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 04 May 2005 14:32:51 +0200
To: "Randy Presuhn"
From: "JFC (Jefsey) Morfin"
Subject: Re: [Ltru] Re: Last registry for now
In-Reply-To: <004d01c55063$1dcbb140$7f1afea9@oemcomputer>
References:
<6.2.1.2.2.20050504021323.0311e500@mail.jefsey.com>
<004d01c55063$1dcbb140$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - mindspring.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-ELNK-AV: 0

On 06:38 04/05/2005, Randy Presuhn said:
>Hi -
>The translation of field identifiers is the registry file is not this WG's
>problem.

Dear Randy,
thank you to accumulate the clear expressions disagreeing with the Charter
as I understand it. It will certainly help the IESG, the IETF and the
Internet Community to grasp the differences.

The use of the proper reference IS our problem. To provide an equal access
to information without exclusive, and stability of identification. In five
(seven) areas at least: the script I use, the language I use, the region I
am from, the reference I use/want, the way I use it, the date I said this
and where I said this if these two are not documented otherwise.

ASCII textual reminders are of no interest in our network usage context as
long as their counter part is not supported in every user script (supported
does not mean actually implemented otherwise than by a default solution to
be defined).

>If someone want to do it in some file they've generated from the registry,
>that's *their* (and their users') problem, not ours.

I am afraid you confuse here the Unicode proposition which actually
provides such a file, and the IANA needed multilingual evolution the
Internet community expects from this WG. Please read the Charter with an
open mind, and not a narrow vision. I expect you contributed to the Charter
and you beleive you understand it: but words used in a restrictive meaning
have also a general meaning. What you described for one case, becomes an
example of a global issue, and you doiscover that you will not find its
stable solution somewhere else than the global resolution.

Anyway I am not interested in what authors wanted to say, but in what is
published and everyone can read.

>Others one this list have already explained why, in general,
>translating these bits is probably a bad idea.  If someone
>does it anyway, they've simply created their own format, and
>it's no longer our problem.

Our problem is what the IESG has listed in the Charter.  And the Charter
says it is. In postponing the debate on the understanding of the Charter
you only delay the whole process. I fully understand you want to force your
vision of the Draft first and you think it will help the debate on the
Charter. This is your right as a Chair. You may be right, you may be not.

Either you will obtain a "consensus" among the 26 people who ever
participated even with one mail in this WG, and end with this process. Or
the debate will confirm the preceding IESG positions and decide the Draft
conceptions inadequate. We will have gained some experience but will have
delayed the whole process.

I frankly cannot pursue on my own Draft before that debate. Because it will
be either a better, a counter or a parallel Draft and a real waste of time
and a source of further confusion if ill targeted. I suppose that I am also
entitled to learn from this debate and get new ideas or ideas refinements.

>Jefsey: if you truly believe this merits an appeal to the IESG, please do
>so *now*.

There are two _possible_ matters for appeal.

1. the shocking expressions of exclusion concerning lingual majorities and
minorities (the lack of expertise is different). I owe you to wait for you
to step in as a Chair to bring back some ethics and therefore credibility
to the debate. I will only act, in a progressive way, if you say you do not
intend to blame the comments on my demand for an equal multilingual support
of every language in field names, as part of a general multilingual support
of every language. I still hope that what wrote was just dumb teasing.
Boring, but also part of this exclusion.

2. the Draft itsefl. I have grounds a plenty but no reasons yet for an
appeal. As noted above you are entitled to your strategy and its outcome
can still be correct. I will appeal if this Draft is the Draft eventually
endorsed by this WG as the first document (I support parts of it as one of
the second documents), due to the way it has been prepared and discussed.
But until the last minute I have no reason for a claim since your approach
may eventually convince me I am wrong.

So, the decision of an appeal is yours: either you make the Draft to
address the Charter (in my understanding of the Charter) what is still
possible, or you lead a clean sheet review of the Charter (or whatever
else) which convinces me that the Draft is OK and the IESG was twice wrong
in evaluating the lack of consensus over its approach by the IETF, or the
IETF Members were wrong in not seeing thay had actually such a consensus
over its approach.

jfc

>Randy, ltru co-chair
>
> > From: "JFC (Jefsey) Morfin"
> > To: "Peter Constable" ; "LTRU Working Group"
>
> > Sent: Tuesday, May 03, 2005 6:37 PM
> > Subject: RE: [Ltru] Re: Last registry for now
> >
> > At 19:58 03/05/2005, Peter Constable wrote:
> > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]
> > >On Behalf Of JFC
> > > > (Jefsey) Morfin
> > > > This is shocking under the pen of a global standadizer. I will not
> > > > comment on the contempt for "end-users", non for the exclusion
> > > > of non-Latin script programmers.
> > >
> > >Do you make as much fuss about (say) the fact that HTTP headers use
> > >Latin characters and that one can't substitute Arabic or other scripts?
> > >
> > >We're talking about documentation of protocol elements. When end users
> > >are involved, I think everyone here would strongly support the need for
> > >"multilingualization", but his is not an end-user issue.
> >
> > Dear Peter,
> > This kind of question is always embarassing, because it shows how much the
> > author do not understand what he discusses. I know this is not on purpose.
> > I will address it to show IESG, and possibly IAB, in appeal that I tried
> > every time I could to explain how much this WG is out of its track.
> >
> > This is not an accademic meeting over three ISO standard's conflicting
> > oddities. This is not a W3C forum trying to patch an XML misconception.
> > This is not a few followers helping with the wording of a twice last-calls
> > denied concept.
> >
> > This is an IETF WG having to study, check and document an Internet and
> > Internet application wide response to the need of identifying and tagging
> > the languages. For and according to the Internet standard process to
> > generate standards, documents, procedures, protocols, best practices. For
> > the Internet to become legally acceptable as a global system.
> >
> > To do that this WG should have attracted enough authoritative experts (or
> > declare itself uncompetent) to study and complet from their own experience,
> > developments and plans, the points in the Charter.
> >
> > I am sure that in this process you would have realized that HTTP is an
> > Internet protocol in the area of this WG as are every Internet protocol. So
> > you would understand that I am making no special, but general, fuss. Your
> > contribution to the WG would have been still more valuable, because you
> > would have learned from seasoned experts that the very basis of a network
> > architecture is consistency and coherence. A coherence with the human
> > protocols (languages) it supports the ASCII Internet has not. A big problem
> > our job is precisely to start addressing.
> >
> > For the rest, I am not in a position to comment: please document (RFC?)
> > what is an "end user" for an IETF WG. I obviously understand what it may
> > mean for an host application designer (like W3C?) but here it does not make
> > any sense to me.
> >
> > all the best.
> > jfc
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
>
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru

==============================================================

Shepherd write-up:

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 ,
which is currently in the RFC editor queue.  There are no other
normative references to internet-drafts.