Picking and choosing

[Doug Ewell]

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

>>> The reviewer could refuse to do this.
>> Actually he could not
>
> Of course he can, that this could then trigger an appeal,
> because it violates MUSTard in 4646 is a different issue.

I wasn't counting expressly prohibited activities among the things the 
Reviewer may do.  Of course he can do whatever he likes, if he is not 
concerned about being overturned or removed.  We saw in the past few 
years that virtually anything, including breathing in and out, can 
trigger an appeal anyway.

>> There's no evidence that 'eur' conflicts with an existing
>> Registry entry.
>
> There's some evidence that copying ISO 639-3 input "as is"
> to a IANA registry without allowing sanity checks is unwise.

Find that for me in Section 3.3, please.

>> What is a "disputed" territory?
>
> When I used that adjective I had DG, EA, IC, etc. in mind as
> proposed in three "disputed" memos posted after 4646bis-08.

Actually, I should not have addressed that issue in my response.  The 
decision to add the ISO 3166 exceptionally reserved code elements was 
made in LTRU, not ietf-languages, and any further discussion on that 
topic should take place there.

For the Reviewer to reject 'DG', 'EA', 'IC', etc. on the basis on 
"sanity," after they were explicitly added to 4646bis, would be the 
fastest possible route to an appeal.

> The question of catching obvious / likely errors before they
> are added to the IANA registry is not limited to ISO 639-3
> input.  You can substitute my polemic "disputed" by a better
> word, maybe "humbug" is clearer.

In another message you had written:

> Unable to judge    => register.
> No obvious problem => register.

Don't we have to define words like "obvious" and "likely" a little more 
explicitly before we open ourselves up to charges of complete 
arbitrariness?

> There were no *similar* problems with ISO 3166-1 and 639-2,
> and real problems (for our purposes) with ISO 3166-1 were
> fixed by RFC 4646.

I've heard often that 'AQ' in 3166-1 and 'mis' in 639-2 were "obvious 
errors" or "bogus" or what have you, and should have been singled out 
for removal.  It's still cherry-picking.

> It wasn't clear for me that jokes can end up in ISO 639-3,
> where it's hard to find out why they were added.

I do wish the ISO 639-3 site included this item, and unknown other like 
it, on its change pages.  The only changes I see there are those 
requested by individuals through the change request process.  'eur' 
wasn't one of these.

> It also
> wasn't foreseeable that 4646bis-09 ff. will try the stunt
> of an *intentional* IETF process failure with DG, EA, etc.

Where is the process failure?

--
Doug Ewell  *  Fullerton, California, 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  ˆ