About appeals (was: Duplicate Busters: Survey #2)

Doug Ewell doug at ewellic.org
Sun Aug 10 23:42:34 CEST 2008

My last post on this thread before taking it off-list, since as Frank 
correctly points out, the real business of this list can easily be 
distracted by side discussions.

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> We obviously disagree about the "spirit" of RFC 1591.

I think we agree to a certain extent, but not to the point where:

"The IANA is not in the business of deciding what is and what is not a 

is interpreted as:

"No RFC may specify the use of ISO 3166 or its code elements in a way 
different from that used by the DNS."

>> a formal appeal would be a better forum for charging LTRU
>> with process violation that this advisory list.
> I simply stated that I'd be not too impressed by an alleged
> LTRU consensus violating "the rules" as I understand them.

You keep mentioning "alleged" LTRU consensus.  I assume this means the 
co-chairs may not have declared formal consensus on this topic.

The LTRU co-chairs have basically not involved themselves in declaring 
formal consensus (or lack) on almost any topic, perhaps partially due to 
fatigue caused by the extreme delays of the project (which they could 
control, however) and perhaps partially due to the backlash from an 
earlier experiment with issue-tracker software, which generated huge 
numbers of list messages that caused some WG members to criticize the 
use of issue trackers in general instead of the specific tool settings.

>> I hope we do not see a return to the working environment
>> of two to three years ago, where a certain poster
>> expressed his disagreement with LTRU WG decisions by
>> making allegations of process abuse, mixed with threats
>> of procedural and/or legal action.
> If that would boil down to a state where you can claim that
> 4646bis is almost in force, while I can't note that this is
> not the case, you are mistaken from my POV.

This thread started with me asking the ietf-languages list to comment on 
*proposals* for the RFC 4646bis Registry.  If RFC 4646bis ends up not 
taking effect after all, which could happen if the delays continue much 
longer and the IETF or IESG responds by shutting down the WG, then none 
of this will matter.  This is not an attempt to rework the current 
Registry as though the proposed new one were already in effect.  I may 
not have made that clear.

> * I strongly supported "record-jar with NCRs", but accepted
>  XML with UTF-8 as an alternative.  In fact I wrote a tool
>  to convert the RFC 4646 format to XML.

Many cogent arguments were made on all sides of the "record-jar vs. XML" 
and "hex NCRs vs. UTF-8" arguments.  (Note that these are two different 
arguments; UTF-8 need not imply XML.)  The group eventually decided 
(probably without formally declared consensus) to keep record-jar due to 
the cost of changing formats, but to switch to UTF-8 due to the 
inscrutability to humans of NCRs.  The group spent ages discussing this 
and I don't think it can be said that all views were not heard.

> * It's IMO okay if you do some limited 4646bis testing here,
>  when this is compatible with RFC 4646.  For the "extended
>  review period of maintenenance updates" my impression was
>  that the outcome was inconclusive:  It might be good idea
>  for folks checking proposed updates.  It could be also bad
>  if the actual update is forgotten due to other discussions
>  here.

When that happens, it is almost always my fault as the Reviewer's 
clerical assistant, and in that case RFC 4646 permits -- nay, 
encourages -- this list to tug on Michael's and my sleeves and remind us 
of pending business.

(For the record, our pending business at present is the batch of 
ISO-related changes I proposed, due for action on August 17, and Mark's 
'pinyin' and 'wadegile' variants, due for action on August 16 but 
currently tied up in debates over the correct prefix(es) and possibly 
other details.)

> * IMHO it is fine if you discuss potential 4645bis oddities
>  here, it helped to fix a bunch of minor nits in ISO 639-3.
>  It helped to find an oddity with Ge'ez under the current
>  RFC 4646 rules, but apparently nobody is going to propose
>  a modification at this time.

It is starting to look like my recommendation on Survey #2 to the 
Reviewer will be "no change."

> * However I consider 4646bis drafts as "work in progress",
>  and not as binding for decisions on this list, no matter
>  what you report about an alleged WG consensus.  And FWIW
>  I think this magic word should be reserved for WG Chairs.
> [That is not against you, I also say it in other contexts.]

I asked the ietf-languages list to help make some LTRU decisions.  I 
respected the input of ietf-languages contributors who have voluntarily 
chosen not to participate in LTRU, including yourself.  I'm sorry it is 
being received this way.

> * There might be even changes in 4646bis I'd support, e.g.,
>  getting rid of "ext-lang" and replacing it by a "scope".
>  I updated the XML-converter for this, and tested it with
>  your actual (May 2008) 4645bis draft:
>  <http://purl.net/xyzzy/home/ltru/ltru2xml.html>

Changes in 4646bis happen on the LTRU list.

> * As far as I'm concerned everybody including IANA is free
>  to use the 4645bis.awk tool in this directory to convert
>  4645bis drafts into a hypothetical UTF-8 registry format.

IANA can certainly use a tool like this if they wish, if they use awk. 
Many editors, such as BabelPad and SC UniPad, also provide conversion 
from NCRs to UTF-8.  Reviewers can use the UTF-8 formats that I already 
provide at <http://www.ewellic.org/rfc4645bis.html>.

> * With respect to the disputed territories the position on
>  this list was that EU cannot be registered under RFC 4646
>  rules.  Besides EU is no concept for linguistic purposes
>  of language tags.  If EU is meant to be a joke then "eur"
>  already covers the funny side of it.  If you feel that a
>  formal appeal is "better" than simply stating it you are
>  of course free to try this approach.  I didn't, but looked
>  into later 464bis drafts limited to this one point, still
>  thinking that it should be fixed before an IETF Last Call.

I don't feel a formal appeal is better than stating objections.  I've 
stated objections many times.

I do feel a formal appeal is better than making veiled allegations about 
the legitimacy of WG decisions and integrity of the I-D editor on 
mailing lists.  In a well-written appeal, you would presumably have to 
back up these allegations with evidence.

> This is only of my objections against 4646bis, but you might
> recall that I consider anything remotely related to TLDs as
> important.  Down to IDN test TLDs in a 2606bis, the toplabel
> question in 1123 vs. 3696, the IANA oddity to permit .eu as
> "ccTLD" (instead of a gTLD like .cat or .asia), our detailed
> pre-4646 debates about CS etc., and so on.

Language tags -- specifically, region subtags -- may look as if they are 
related to ccTLDs, but they are not.  Many other organizations and 
standards refer to ISO 3166 and use its codes, without being related to 
ccTLDs.  UN/LOCODE (which has its own ongoing maintenance problems) uses 
both ISO 3166-1 and 3166-2 codes, but extends both.

The continued existence and maintenance of the .su domain [1] sort of 
kills the argument that ccTLD usage of ISO 3166-1 is exemplary, or that 
IANA/ICANN adhere strictly to ISO 3166/MA determinations of "what is a 

[1] http://en.wikipedia.org/wiki/.su

Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

More information about the Ietf-languages mailing list