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

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Apr 2005 20:49:53 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> 1 - At the moment no RfC 3066bis implementation exists.  Proof:
>     3066bis isn't an RfC at the moment.

I'd like to see the look on your face when I show you my fully compliant
tag generator and validator for RFC 3066bis.  (Cf. the last sentence of
Appendix A.)

Of course, I can't distribute it publicly as being compliant with
anything, since 3066bis is, indeed, not an RFC at the moment.  But I
always smile when someone says, for example, that the mechanism for
identifying subtags based on length and position "doesn't work," or that
parsing or validating tags is too complicated to be practical.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Apr 2005 20:57:30 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> We can and should introduce an exactly compensating exception
>
> First of all we MUST acknowledge that our concept of alpha-2
> country codes was completely wrong.

Even if that were true, it's not relevant.  Language tags that use
alpha-2 country codes are ubiquitous.  Turn the page.

> Until we haven't done this we end up with the bogus "forever
> canonical" rules, and the abomination to hide the canonical
> value in a "comment", where implementations won't find it.

The canonical value isn't hidden inside a comment, and never has been,
even in the very first version of the draft that mentioned a registry,
back in July 2004.  It has always been a normative, machine-readable
field.

"Forever canonical" is the only way to go unless you believe everyone is
going to update their applications and retag all their existing data
every time an ISO code is changed.

-Doug Ewell
 Fullerton, California

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Apr 2005 21:22:16 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> how does one distinguish the French from the English the
>> Language Subtag Directory after we've imported the values?
>
> How about:  English name semicolon French name ?

There are twenty-one language subtags in the current registry with
compound names, separated by semicolons:

Catalan; Valencian
Spanish; Castilian
Kalaallisut; Greenlandic
Limburgan; Limburger; Limburgish
Low German; Low Saxon; German, Low; Saxon, Low
etc.

These names were pulled directly from ISO 639.  Arbitrarily picking the
first name from the list and throwing away the rest doesn't work; there
is no way to know which of the multiple names is preferred for any given
purpose or by different speakers.  All the names are there for a reason.
(OK, I think they went overboard with the "Low German" permutations.)

So, clearly, we can't ALSO implement French names by writing:

English; anglais
French; français
German; allemand
etc.

If there is support for adding French descriptions, then I prefer two
description fields: "English_Description" and "French_Description", or
perhaps "English_Name" and "French_Name".

But only TWO.  Expanding this beyond English and French should not
happen.  The registry is not a general-purpose repository of locale
data; there are other sources for that.  The stated goal of retaining
important information from the ISO standards can be met by adding French
and leaving it at that.  Trying to dig up the Kwanyama word for "Skolt
Sami" is way out of scope for language tagging.

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 07:48:19 +0200

Doug Ewell wrote:

> Even if that were true, it's not relevant.

It's essential, because the rules as they are won't work.

We've already seen that with the "old" proposal, it's now
only acceptable because you've removed the pre-1988 codes.

Without fixing the rules the same would be necessary in
about 16 years (2005-1988=17, 1988-1974=14, 2005+16=2021).

> The canonical value isn't hidden inside a comment

The real canonical value in Addison's NHVU example is VU:

| Subtag: NH
| Deprecated: 2006-01-01
| Comment: use VU for Vanuatu

> "Forever canonical" is the only way to go unless you
> believe everyone is going to update their applications
> and retag all their existing data every time an ISO
> code is changed.

That's not true, you keep all deprecated tags as they are.
Nobody is forced to update his deprecated NH tags or NH
software.  But new software and new tags should use the
new canonical value VU.  The line...

| Comment: use VU for Vanuatu

...is not good enough.  If one side is old software and
asks for NH, and the other side is new and has VU, then
how is the new side supposed to detect this situation if
it's only documented in a human readable comment ?

Software normally cannot interpret a "use VU for Vanatu".
Maybe we have only different ideas of "canonical" here,

I really don't care about the name, as long as it's a
machine readable pointer, how about:

  Alias: VU
or
  See also: VU
                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 08:07:44 +0200

Doug Ewell wrote:
 
> I'd like to see the look on your face when I show you my
> fully compliant tag generator and validator for RFC 3066bis.

My point was "no RfC at the moment".  It's good that you have
a prototype for the draft.  If somebody asks why a completely
new scheme is called "best common practice" we can answer that
one practical implementation exists, and that's automagically
the best, the worst, the only practice.  Not exactly common.

> 3066bis is, indeed, not an RFC at the moment.

Yes, and if we would say language-region-script-variant, or if
we allow any order after language, you probably need 5 minutes
to update your prototype.  A bit longer for the test suite, if
you have edited it manually.

> I always smile when someone says, for example, that the
> mechanism for identifying subtags based on length and
> position "doesn't work,"

Better, your prototype already supports what Ira and Ned were
talking about (see subject).  I can't judge how useful it would
be to organize the subtags in another way.  But all claims that
this is impossible are wrong.
                              Bye, Frank

---

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

> tag generator and validator for RFC 3066bis.  (Cf. the last sentence of

How about the look on your face when some detail in 3066bis changes, rendering
your implemenation invalid in some way?

I've implemented the rules I believe might be part of 3066bis myself. But since
I lack a working crystal ball, I have no way of knowing if that's what will
actually be in 3066bis when it is finally published. I therefore cannot claim
to have a compliant implementation at this point. Nobody can.

> anything, since 3066bis is, indeed, not an RFC at the moment.

Exactly. And more to the point, it may transpire that what actually emerges is
different in some way. We'd all be wasting our time here if such changes
weren't possible.

> But I

Is anyone actually saying that in this group? If so I sure haven't
heard it.

				Ned

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 09 Apr 2005 18:32:59 +0200

At 17:27 09/04/2005, [email-masked] wrote:
>Is anyone actually saying that in this group? If so I sure haven't heard it.

I say it is absurd to define an information by its ... size! But if some 
like it ...
Since I cannot use the whole thing ... as long as they do not make it 
mandatory in it being the only format of BCP 047 ....

FYI the logical network multilingual layers come in the following order :

- script so you can write each other strings
- language so you can read each other commands
- geolegal so you know the applying rules ... this permits interoperationality
- referent so you can understand each other ... this permits 
interintellegibility
- the vernacular style/practice so you can work together ... this permits 
interusability.

If you really want to make it a formated langtag it should be 
script-language-country (in your parlance  [4-]3-2 character strings, with 
2 characters being acceptable in 1st position and script preposition being 
optional. This is what we should have in the IDNA and the big mistake was 
to put it in a different order, not understanding that the Internet is 
actually the ASCII class of the Multilingual Internet system.

jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 10 Apr 2005 10:26:17 -0700

<ned dot freed at mrochek dot com> wrote:

>> I'd like to see the look on your face when I show you my fully
>> compliant tag generator and validator for RFC 3066bis.  (Cf. the last
>> sentence of Appendix A.)
>
> How about the look on your face when some detail in 3066bis changes,
> rendering your implemenation invalid in some way?

Oh, that's happened lots of times.  Usually I just shrug and implement
the change.  Sometimes I smile broadly, because the change is one I
supported.  I don't have to worry about distribution, of course, since
it's only a draft and not expected to be permanent.

> I've implemented the rules I believe might be part of 3066bis myself.
> But since I lack a working crystal ball, I have no way of knowing if
> that's what will actually be in 3066bis when it is finally published.
> I therefore cannot claim to have a compliant implementation at this
> point. Nobody can.

I have a version that is compliant with the draft as it stands today.
Tomorrow's draft may be different enough to break my implementation, but
that's OK because we are in draft mode.

> Exactly. And more to the point, it may transpire that what actually
> emerges is different in some way. We'd all be wasting our time here if
> such changes weren't possible.

Absolutely correct.

>> But I always smile when someone says, for example, that the mechanism
>> for identifying subtags based on length and position "doesn't work,"
>> or that parsing or validating tags is too complicated to be
>> practical.
>

Frank had written on March 19:

"But it would require complex restrictions allowing to identify the
class of some subtags independent of their position.  Most probably that
was discussed years ago before the first of the old drafts, and it
simply doesn't work."

In other messages it had been stated that "smart matching" is
impractical because the parsing rules are too complex.  I can dig out
examples if necessary, either from this list or from ietf-languages.

-Doug Ewell
 Fullerton, California