Duplicate Busters: Survey #2

[Frank Ellermann]

Doug Ewell wrote:
 
 <ot>
> some gateway along the way applied the base64 layer.

Okay, the wonders of 8BITMIME are as you say somewhat
off topic here.  John's ***DOOM*** message to another
list said it all.

> it is 2008 and mail agents are supposed to be able
> to deal with base64-encoded UTF-8 by now.

If the Ethi apostrophe made it back to you together
with my Phaistos glyph our MUAs can handle this, in
theory

> </ot>

> The Registry is moving to UTF-8.  This has been
> decided.

s/decided/proposed in various drafts/

> You don't ever have to worry about anybody else's
> fonts, only your own.

NAK, for discussions here all participants need to
be sure which code points they are talking about. 
How they are displayed if at all is less relevant.

> I don't believe the solution is "encode everything
> twice."  Others do.

I believe in "follow the sources", that is somewhat
orthogonal.  Ge'ez is not in the source, therefore
I'd support a modification request to eliminate it.

A modification request under RFC 4646 rules, it is
not appropriate to update this in the bulk update
concerned with ISO 639-3.
 
> Let me try again: Do they depend on the EXACT name,
> to the extent that any change in hyphenation or 
> apostrophe usage will cause compatibility problems?
> Please provide examples.

Ainu is an example, it is possible that taggers used
it for what the exact name says.  Possibly they did
not want *this* Ainu, and the registry better offers
a hint what went wrong.

>>> Comments: Listed as "Ainu" in ISO 639-2

>> Yes, I'm not sure how important or helpful the info
>> is. The GG-IM-JE comment is a similar idea.
 
> Neither am I.  But we can consider adding such 
> comments to any subtags where the exact ISO name
> isn't preserved.

IMO this isn't about *exact*, it is about "some Ainu"
vs. "Ainu (Japan)".  Everything tagged with the "old"
Ainu is suspicious.  I'd have gotten this wrong... :-(

>> The solution to pick one name in both source 
>> standards is fine.
 
> Do you mean "one name from each standard,"
[...]

No, I mean that ISO 639-2 and 639-3 will be aligned 
to use one name => problem solved for your purposes.
Just pick the *one* name supported by Joanne. 

If the ISO 639 folks later decide to use the *other*
name the registry can be updated.  

>> How did a name get into the registry if it is not
>> in the source, did we miss the change ?
 
> RFC 4646 doesn't prohibit this list from adding 
> Description fields beyond those in the source
> standards.  They must not conflict with the 
> existing description(s).

Something the hypothetical successor hopefully fixes.
It's the job of *Comments* to offer opinions of this
list.  Descriptions are supposed to reflect sources,
there is no Ge'ez in the source.

 Frank