Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP)

From: "Peter Constable" <[email-masked]>
Date: Sat, 9 Apr 2005 05:04:36 -0700

> From: [email-masked] [mailto:[email-masked]]
On

> The analogy is a stretch in and of itself, but it is also irrelevant
since
> the
> basis of comparison is a strawman. We're not talking about incompliant
> implementations here.
> 
> A compliant RFC 3066 implementation can (and I know for a fact has)
been
> written that handles these exceptions through an exception table, but
> still
> operates under the assumption that a two letter code in the second
> position is
> a country code but a two letter code elsewhere is not.
> 
> Like it or not, there are lots of application domains where script
> information
> is much less readily available than country information. As such, it
is
> entirely reasonable for these implementations to rely on extraction of
> country
> code information for the purposes of making finer grained matches. And
> this
> proposal breaks this.

This whole argument is a strawman. The number of cases in which tags of
the form ll-Ssss-CC will be used are limited. In the cases in which they
will be used, the script distinction is almost certainly to be a more
relevant distinction, so there's actually a greater likelihood that what
will be used is a tag of the form ll-Ssss (indeed, likely one that is
already registered under 3066), in which case your existing
implementation will be just as incapable of extracting country
information as if ll-Ssss-CC were used. Sure, in the latter case at
least there was a *potential* for extracting such information, but I'd
contend that the failure to realize that potential is less of a problem
than all the existing implementations that would use left-prefix
matching and give greater priority to minor regional distinctions than
to script distinctions if a subtag sequence ll-CC-Ssss were required.

It is a completely invalid to say that "backward compatibility" is being
broken. That assumes that backward compatibility is defined in terms of
certain expectations that have never been guaranteed: that if a second
subtag exists, it would be a country ID. The appropriate way to present
an argument on this issue is to say that some specific functionality
would not exist, and then to evaluate in relation to realistic scenarios
just how great a loss that would be.

> Not true. The question is what was or was not standardized in the
past.
> The
> rules for country code positioning were clearly written and clearly
> normative.

(Here we go again.) The rules that were clearly written state that *if*
a tag has the form ll-CC or lll-CC, then CC must be from ISO 3166. It's
a one-way implication; that's it! It does *not* say that an ISO 3166
country ID *must* occur as the second subtag.

> The difference is that there was never any guarantee given that the
> shortest-prefix-match approach would work well in all cases.

And there was never any guarantee that country IDs would always occur as
the second subtag.

> You're effectively moving country codes to a new position in the
string.
> That's
> breaking compatibility in my book.

This is *not* a valid argument:

- Tags like "en-US" will still be "en-US" with the country ID in the
same position they were always in.

- The only cases in which one could possibly contend that the country ID
moved to a new position would be in comparing e.g. zh-TW with
zh-Hant-TW, and in such cases the loss of functionality resulting from
the country ID "moving" when the latter tag is used on one side of a
match (remember: zh-TW will still be valid) is less of a loss than
having implementations match for regional distinctions that pale in
relation to script distinctions.

- Again, neither RFC 1766 or RFC 3066 stated that a country ID could
only occur as the second subtag, and it has always been invalid to
assume that this must be the case.

Peter Constable

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: [email-masked]
Date: Sat, 09 Apr 2005 08:13:47 -0700 (PDT)

> the form ll-Ssss-CC will be used are limited.

You have absolutely no way of knowing that that will be the case. As I pointed
out in other mail, script information is something that often can be derived
from other data. Country information is often something you have available as
well. This makes it entirely possible that such tags will be created in an
attempt to make things more informative.

> In the cases in which they
> information as if ll-Ssss-CC were used.

You have no way of knowing this either. And even if it is true in all cases, it
is beside the point if you have country information but not script information.

> Sure, in the latter case at

> broken.

On the contrary, it is completely demonstrable that that is what is happening.

> That assumes that backward compatibility is defined in terms of
> subtag exists, it would be a country ID.

This isn't the expectation.

> The appropriate way to present

I disagree. It's a big world out there, and it is next to impossible to figure
out what people have done or will do. The best we can do is to try and maintain
compatibility. And if we have to break compatibility, an effort needs to be
made to minimize the degree of breakage.

> country ID *must* occur as the second subtag.

I have _never_ claimed otherwise.

> And there was never any guarantee that country IDs would always occur as

I HAVE NEVER CLAIMED OTHERWISE.

> relation to script distinctions.

You're assuming that script codes will only be inserted where they are needed.
Until Addison's proposal came up I saw no way to encourage this.

> assume that this must be the case.

And it has always been valid to handle this issue through an list of
exceptions, resulting in a fully compliant implementation.

				Ned