Subject: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200)

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

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

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

It's acceptable *to you* because we've removed the pre-1988 codes.  Many
others found it acceptable before that change was made.

There is solid evidence that having a language tagging mechanism that
relies on the stability of ISO standards causes problems when those
standards show instability.  The draft seeks to remove or reduce that
instability by introducing a stable layer on top of it.  I do not
believe there is any evidence that the stability of the extra layer will
cause the problems you have described.

>> 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

I don't know where this example keeps coming from.  Possibly Addison
used it when we were talking about making comments a parsable field.

Nevertheless, it is simply NOT the case that canonical-value information
has ever been buried in a comment field, parsable or not, since the dawn
of the registry idea.  There has ALWAYS been a canonical-value field.

Please re-read Section 3.1 of the current draft, in particular the
description of the Canonical field.  Then visit
http://www.inter-locale.com/ID/draft-phillips-langtags-04.html to see
the very first version of the draft that involved a registry.  It also
includes a canonical-value field, intended to be parsed by machines, and
a separate comment field, intended to be read by humans.

Please do not take an example that was meant to illustrate the value of
a parsable comment field, and use it to claim that canonical values are
buried inside comments.

> 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

Or how about:

Canonical: VU

Which is exactly what the registry has.  (Except that NH was purged as
having been withdrawn before 1988, so I really don't see why we are
using it as an example anyway.)

-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: Sun, 10 Apr 2005 10:47:18 -0700

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

> 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.

I did not create an implementation in order to misrepresent the status
of the proposed language-tag mechanism.

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 20:28:33 +0200

> It's acceptable *to you* because we've removed the pre-1988
> codes.  Many others found it acceptable before that change
> was made.

In fact Jefsey said somewhere that he wants all the old codes
(pre-1988) back.  Anyway, Addison's example about NH and VU
was fictitious, asuming that we have NH today, and later it's
changed to VU, and still later changed again to XX.

So that would "deprecate" (ISO 3166-1 view) NH, and later it
would again "deprecate" VU.  Is Addison's example now clear ?

What exactly is the outcome for the LTRU registry ?  Do we get
pointers from XX to VU to NH, or vice versa, or in any way ?

Or do we get three unrelated entries NH, VU, and XX, where the
only hint that these entries belong to "the same piece of land"
is hidden in a comment ?

The latter would be very bad.  That's all I've said (in reply
to Addison's article).

> I don't know where this example keeps coming from

I can't reconstruct it, your References header field is broken,
it points to a Message-ID which doesn't exist in the list:

<[email-masked]>

But it was in "this thread" if you can reconstruct it, one or
two articles before I've changed the subject from 200 to VU.

> Canonical: VU

Excellent idea, but it was you who said that this won't work
after date-B, because NH would then be "forever canonical".

So what happens if an existing NH is somehow renamed to VU ?

We don't need Addison's double-renaming for this question, so
you could also use "VU renamed to XX" (after date-B).  I would
want "VU...deprecated...canonical XX", but you said that this
is bad.  What do you get ?

"VU...deprecated" + "XX...canonical VU" is IMO gibberish.  Bye.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 20:51:23 +0200

Doug Ewell wrote:

> I did not create an implementation in order to misrepresent
> the status of the proposed language-tag mechanism.

Sure, I know this.  But I've no good idea how to get rid of a
"best common practice", that's some IETF magic.  Maybe 3066bis
could be a "normal" RfC on standards track, and still obsolete
BCP 47 a.k.a. RfC 3066.  I don't feel comfortable with RfC 3066
as BCP, it didn't survive four years.  And I'm not completely
convinced that RfC 3066bis would last much longer, finding some
"3066ter" on this list.
                           Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 10 Apr 2005 15:21:53 -0400

> using it as an example anyway.)

We are imagining for the purpose of this example that it didn't happen
until after Date A.

-- 
It was dreary and wearisome.  Cold clammy winter still held way in this
forsaken country.  The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
        --"The Passage of the Marshes"          http://www.ccil.org/~cowan

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 10 Apr 2005 12:37:27 -0700

> We are imagining for the purpose of this example that it didn't happen

Sorry, I missed that.  I was going to suggest that in that case, we
should use BU and MM instead, but I guess I was the only one confused by
this.

Type: region
Subtag: BU
Description: Burma
Date: 2004-07-06
Canonical: MM
Deprecated: 1989-12-05

The Vanuatu example, if it had not happened until after Date A, would
have been:

Type: region
Subtag: NH
Description: New Hebrides
Date: 2004-07-06
Canonical: VU
Deprecated: 1980-01-01

-Doug Ewell
 Fullerton, California

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 19:55:23 +0200

>cause the problems you have described.

I would be very interested in your description of this layer. The draft 
proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO 3166". I 
fail to understand how tag is inderpendent from a change in one of the ISO 
subtags.

An independent layer would be xml:lang="jefsey-2005" and "jefsey-2005" 
being documented at http://jefsey.langtags.org.
jfc

---

From: John Cowan <[email-masked]>
Date: Sun, 10 Apr 2005 16:03:26 -0400

JFC (Jefsey) Morfin scripsit:

> fail to understand how tag is inderpendent from a change in one of the 
> ISO subtags.

To spell it out:

If a code is *unassigned* by an ISO authority, it remains in the IANA
registry as a subtag of the relevant kind and therefore valid.

The ISO 639 and 15924 registration authorities have guaranteed not
to *reassign* codes.

When the ISO 3166 maintenance authority (which is under different pressures
from the other two and has a different status and history with ISO)
reassigns a code, we ignore the reassignment and make use of a UN M.49
numeric code instead.  The UNSD also guarantees not to reassign tags.

In this way, we stay completely compatible with the ISO codes and
yet independent of changes.  There is no need to create syntactically
independent tags such as you propose.

-- 
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"              http://www.ccil.org/~cowan
        The cause of his sorrow                 http://www.reutershealth.com
        Was para-dichloro-                      [email-masked]
Diphenyltrichloroethane.                                (aka DDT)

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 10 Apr 2005 13:28:33 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> ... The draft seeks to remove or reduce that
> >instability by introducing a stable layer on top of it...
>
> I would be very interested in your description of this layer. The
> draft proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO
> 3166". I fail to understand how tag is inderpendent from a change in
> one of the ISO subtags.

This is one of the fundamental features of the draft, and has been
discussed at great length.

The subtags are BASED ON code elements in ISO standards, but may deviate
from them to preserve stability when the ISO code elements are changed,
and especially so when they are reused.

-Doug Ewell
 Fullerton, California

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Apr 2005 04:08:34 +0200

At 22:28 10/04/2005, Doug Ewell wrote:
> > 3166". I fail to understand how tag is independent from a change in
> > one of the ISO subtags.
>

Dear Doug,
This means (I obviously assume big changes which are claimed never to 
happen :-) that nothing opposes that fra-Cyrl-US would still mean French 
writen in Cyrilic as spoken in the USA - while fra may have changed in that 
far future to Franglish, Cyrl to Cypriot revision of Latin and US to United 
States of Australia.

- this is IETF not ISO and no position by ISO can be taken for granted: we 
have no control.
- the draft precisely wants a solution which rules out any risk of that kind
- this is indeed a fundamental features of the Draft, and that it has been 
discussed at great length. This does not change anything to it. This WG is 
to discuss Drafts only to address its Charter.

You document that the draft does not match the charter. I noted that, and 
also the conflict in the charter which calls for an independence from the 
ISO evolutions and the possibility to identify the subtags in the tag. IMHO 
this calls for a request of guidance to the IESG if the debate on the 
charter (we still need to have, as Randy underlined it) does not deliver a 
solution.
jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 10 Apr 2005 22:16:48 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> happen :-) that nothing opposes that fra-Cyrl-US would still mean
> French writen in Cyrilic as spoken in the USA - while fra may have
> changed in that far future to Franglish, Cyrl to Cypriot revision of
> Latin and US to United States of Australia.

Correct, except that the language subtag in question would be 'fr', not
'fra'.

> - this is IETF not ISO and no position by ISO can be taken for
> granted: we have no control.

Correct.

> - the draft precisely wants a solution which rules out any risk of

Correct.

> - this is indeed a fundamental features of the Draft, and that it has
> been discussed at great length. This does not change anything to it.
> This WG is to discuss Drafts only to address its Charter.

Correct.

> You document that the draft does not match the charter.

Absolutely FALSE.  How can you possibly reach that conclusion?  The
charter says:

"For stability, it is expected that the document will describe how the
meaning of language tags remains stable, even if underlying references
should change, and how the structure is to remain stable in the future."

Decoupling the subtags in the registry from strict adherence to the ISO
standards is how the draft achieves this goal.

> I noted that, and also the conflict in the charter which calls for an
> independence from the ISO evolutions and the possibility to identify
> the subtags in the tag.

For God's sake.  The length and position of subtags within the tag
identify their type, and the description fields in the registry identify
their meaning.

> IMHO this calls for a request of guidance to the IESG if the debate on
> the charter (we still need to have, as Randy underlined it) does not
> deliver a solution.

Every day you amaze me more.

-Doug Ewell
 Fullerton, California

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Apr 2005 11:51:15 +0200

Dear Doug,
I thank you for this loyal and clear response, where you show that a tag 
could mean something totally different from what it would mean if it was 
currently built according to the current ISO standard, and that you fully 
support to such a proposition. I did not considered the conflicts or 
confusion in IANA registration during the ISO standard evolution, but I 
suppose your response would be the same.

Since you are one of the most competent, active and acknowledged members of 
this Working Group, I am interested to know if - me apart - this is the 
consensus of this Working Group?
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 11 Apr 2005 12:01:10 -0700

Hi -

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Sunday, April 10, 2005 7:08 PM
> Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove regionsubtag 200)
...
> charter (we still need to have, as Randy underlined it) does not deliver a

The charter us not up for debate.

Jfc: Bogus claims that a co-chair supports a particular position
are not a good way to win friends or favorably influence people.

Randy, co-chair ltru