Duplicate Busters: Survey #2
nobody at xyzzy.claranet.de
Mon Aug 4 08:19:18 CEST 2008
Doug Ewell wrote:
> 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
> The Registry is moving to UTF-8. This has been
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.
More information about the Ietf-languages