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

Frank Ellermann nobody at xyzzy.claranet.de
Sat Aug 9 21:11:23 CEST 2008


Doug Ewell wrote:

> there is no conflict with the informative RFC 1591 or 3071.

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

> 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. 

And if you don't want to discuss this here we're in violent
agreement, let's stick to facts such as RFC 4646 rules here.

> 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.  Just in case:

* I strongly supported RFC 4646, down to proposing the text
  in an "RFC editor note" that was later appealed by that
  person.

* 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.

* For some time, years ago, I wanted "all ccTLDs" instead of
  directly using ISO 3166 country codes, but I accepted the
  outcome in RFC 4646 (obviously, I still support RFC 4646).

* 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.

* 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.  

* 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.]

* 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>  

* 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.

* 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 expect that this ever makes it into a published RFC.

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.  

> You win some, you lose some.

You also decide *when* something is lost.  Sixty days after
the approval is the point where I'd be forced to admit that
I need a new plan if I still think that something is wrong.

 Frank



More information about the Ietf-languages mailing list