Doug Ewell wrote:
>> Let Doug remove it.
> Let the WG remove it, with the chairs' declaration of
> consensus, and Doug will be happy to do the mechanical
> work.
Yeah, that's what I meant, IIRC nobody but Mark, John, you,
and me ever discussed it, and I guess that Mark won't insist
on the 200 if that means more than one additional second of
discussions. Admittedly I forgot John's position about 200,
and maybe Randy likes this odd code, so I can't guess where
we are exactly in the "rough. Must be the 17th hole.
["frozen" Preferred-Value]
> If this was, in fact, the way the issue was resolved, then
> the draft is correct in reflecting that.
Indirections over several hops make no sense from my POV, but
as long as they finally arrive at the one and only actual sub-
tag it's a minor issue.
But I'd still like to see the article where that was declared
to be the resolution, ticket number and Randy's stamp, maybe I
only missed it => my problem.
>> Could we please run a simulation, Doug plays tag reviewer
[...]
> Sure.
[...]
> Notice that TP points to TL, and TL points to TE.
Okay, that works, modulo one unnecessary indirection from TP.
And if they added XX forgetting to deprecate TL ? Apparently
they do whatever pleases them, and whenever it pleases them.
We're building on quicksand in the case of ISO 3166-1 codes.
> it seems to contradict the passage in the same section that
> says, "Thie [sic] field 'Preferred-Value' contains a mapping
> between the record in which it appears and a tag or subtag
> which should be preferred when selected language tags." In
> fact, TE should be preferred, not TL.
Okay, let Addison and Mark fix this in draft -05. We have 36
hours to make the cut-off for Monday's draft submissions.
> Example 2: Somaliland's claim to independence is recognized
> by the UN, which assigns it the code 888 (Frank's choice)
> and assigns 708 to the new, smaller Somalia (withdrawing
> 706).
Nice, but I don't insist on the logical 708. We have seen for
830 => 831 + 882 vs. 830 + 831 + 832 that these UN assignments
are not always logical.
> Some time after, ISO 3166 assigns the code element SP to
> Somaliland (not having had the good sense to use it in 2003
> instead of CS). The remaining portion of Somalia retains SO.
> Type: region
> Subtag: SO
> Description: Somalia
> Added: 2004-07-06
Okay (now 708, was 706, maybe you'd add a comment about this)
> Type: region
> Subtag: SP
> Description: Somaliland
> Added: 2006-01-01
Okay. That was "draft -04 as is". What about the period when
888 already existed, just say "no, you must wait for ISO 3166-1"
to Debbie / Karen / Mark / Peter on the languages list ? In
the worst case they wait forever, or have to submit a 3066ter ?
> The way I read the draft, the rules for the initial registry
> (use whatever is in the core standards) differ from the rules
> for maintaining it (use UN codes only when stability requires
> it).
IMHO that's a dubious plan, as we have seen for 831...833. Or
in this example 888.
> It also implies that when the UN macro codes are changed,
> which just happened a few months ago, the registry is not
> changed to match.
No problem from my POV. BTW, what was the resolution for the
dubious 003 ? You still have it in "File-Date: 2005-06-05".
> 4.3 should be changed to refer to a valid example:
> "Example: The language tag "en-NH" (English as used in the
> New Hebrides) is not canonical because the 'NH' subtag has
> a canonical mapping to 'VU' (Vanuatu), although the tag
> "en-NH" maintains its validity."
Indeed. We've discussed this how often now, four times, about
once per month since LTRU was established ?
> it should be quick and easy to replace this non-normative
> example.
Mark fighted hard for date-A 1988 allowing to keep BU, so let's
use BU -> MM instead of NH -> VU. Or ZR -> CD. Or YU -> CS.
Bye, Frank
_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.