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
country."
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
country."
[1] http://en.wikipedia.org/wiki/.su
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
More information about the Ietf-languages
mailing list