Frank Ellermann <nobody at xyzzy dot claranet dot de> 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. > But I'm worried about the TL -> XX bug, > we discussed this for weeks, why is it still incorrect in -04 ? The outcome of the discussion, IIRC, was that a given Preferred-Value field could be added exactly once, and not changed thereafter. If this was, in fact, the way the issue was resolved, then the draft is correct in reflecting that. > Could we please run a simulation, Doug plays tag reviewer, and > we fire some registration requests (based on some hypothetical > events like "TL" wants to be "XX", or the UN assigns 888 to > "Somaliland" - a part of the former and now defunct "Somalia") Sure. Example 1: Timor-Leste (TL), formerly East Timor (TP), decides to change its name again, this time to Timor-Est (forsaking "Portuguese-everywhere" for "German-everywhere"). ISO 3166 assigns the code element TE and withdraws TL. The UN code is unaffected. Registry details (chronological order, not alphabetical): Type: region Subtag: TP Description: East Timor Added: 2004-07-06 Preferred-Value: TL Deprecated: 2002-11-15 %% Type: region Subtag: TL Description: Timor-Leste Added: 2004-07-06 Preferred-Value: TE Deprecated: 2006-01-01 %% Type: region Subtag: TE Description: Timor-Est Added: 2006-01-01 Notice that TP points to TL, and TL points to TE. Thus, following the daisy chain, the true Preferred Value for TP should actually be TE, not TL. This is consistent with the passage in Section 3.1 that says, "The field 'Preferred-Value' MUST NOT be modified once created in the registry." However, 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. 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). 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. Registry details (chronological order, not alphabetical): Type: region Subtag: SO Description: Somalia Added: 2004-07-06 %% Type: region Subtag: SP Description: Somaliland Added: 2006-01-01 Notice that there is no Preferred-Value involved. SP is a completely new ISO 3166 code, and even though the old SO now corresponds to a different UN numeric code (708 instead of 706), this is irrelevant to the process of adding new subtags because no new ISO 3166 code was created that conflicts with existing subtags. Notice also that a subtag for Somaliland is not added in response to the UN addition, but only when ISO adds their code. 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). 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. As a side note, the following text in Section 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." NH was invalidated when Date A was established. Yes, I know it's the 11th hour, but it should be quick and easy to replace this non-normative example. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ 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.