Subject: [Ltru] Just checking...

From: "Debbie Garside" <[email-masked]>
Date: Thu, 16 Nov 2006 01:10:42 -0000

To see if you are awake...

I wrote:

"kcao	Khanty Written Cyrillic Script Obdorsk Model" could be tagged as:

----

kca-Latn-RU-6-kcao

----

This should, of course, be:

----

kca-Cyrl-RU-6-kcao

----

:-)

Debbie Garside
Managing Director

ICT Marketing Ltd
Corner House
Barn Street
Haverfordwest
Pembrokeshire SA61 1BW
Wales UK

Tel: 0044 1437 766441
Fax: 0044 1437 766173

Web: http://www.ictmarketing.co.uk 

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Nov 2006 20:20:55 +0100

> "kcao   Khanty Written Cyrillic Script Obdorsk Model" could be tagged as:
[...]
> kca-Cyrl-RU-6-kcao

Okay.  And what about kcac, would we / you / someone offer an equivalence
table "for kcac use kca-Cyrl-RU if in 4646ter territory, and try to avoid
kcy-Cyrl-RU-6-kcac, because it's redundant" ?

The RFC for the 6-extension registry could probably manage that.  Thanks
for the examples, it's much clearer now what you're talking about.  And
hopefully better than the current variant registration business.

Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 16 Nov 2006 14:30:40 -0500

> kcy-Cyrl-RU-6-kcac, because it's redundant" ?

That is the "complete-flag" field that I have been talking about:
it is true for 'kcac' and false for 'kcao'.  I do, however,
prefer '6kcao' (a variant) to '6-kcao' (an extension).

-- 
"Well, I'm back."  --Sam        John Cowan <[email-masked]>

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 16 Nov 2006 19:48:55 -0000

Frank wrote:

> Okay.  And what about kcac, would we / you / someone offer an 
> equivalence table "for kcac use kca-Cyrl-RU if in 4646ter 
> territory, and try to avoid kcy-Cyrl-RU-6-kcac, because it's 
> redundant" ?

A flag would be provided in the data tables to indictate where a 639-6
identifier is redundant when it is equal to the combined language subtag
containing ISO 639-3/3166-1/15924.
 
> The RFC for the 6-extension registry could probably manage 
> that.  Thanks for the examples, it's much clearer now what 
> you're talking about.  And hopefully better than the current 
> variant registration business.

Hopefully :-)

Debbie

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Nov 2006 21:12:18 +0100

John Cowan wrote:
 
> That is the "complete-flag" field that I have been talking about

Yes, I read and replied in reverse chronological order by thread,
Debbie's "just checking" was the newest thread from my POV.  Later
I found your explanation.

> I do, however, prefer '6kcao' (a variant) to '6-kcao' (an
> extension).

As usual I prefer extensions, when there's a clear topic or issue,
and the variant approach would result in an "emulated" singleton,
fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz.  

Why use an informal convention if you can also get an RFC with all
details, here your "flag" algorithm to determine equivalences ?  
For variants it's so far not possible to specify "conventional"
rules in separate documents.

Frank

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 16 Nov 2006 21:06:05 -0000

Frank wrote:

> John wrote
> As usual I prefer extensions, when there's a clear topic or 
> issue, and the variant approach would result in an "emulated" 
> singleton, fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz.  

If I had to state a preference it would be for an extension because it
presents the alpha4 as is.  But maybe I don't fully understand the issues
involved.  Would someone like to enlighten me?

Debbie

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: 16 November 2006 20:12
> To: [email-masked]
> Subject: [Ltru] Re: Just checking...
> 
> John Cowan wrote:
>  
> Yes, I read and replied in reverse chronological order by 
> thread, Debbie's "just checking" was the newest thread from 
> my POV.  Later I found your explanation.
> 
> As usual I prefer extensions, when there's a clear topic or 
> issue, and the variant approach would result in an "emulated" 
> singleton, fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz.  
> 
> Why use an informal convention if you can also get an RFC 
> with all details, here your "flag" algorithm to determine 
> equivalences ?

---

From: John Cowan <[email-masked]>
Date: Fri, 17 Nov 2006 01:48:57 -0500

> fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz.  

This is what variants are *for*.  Read the section on them in
4646 again.

> rules in separate documents.

Why not?  When we do RFC 4646ter we can explain all of this.

-- 
John Cowan     http://ccil.org/~cowan    [email-masked]
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

---

From: Martin Duerst <[email-masked]>
Date: Sat, 18 Nov 2006 11:36:56 +0900

>This is what variants are *for*.  Read the section on them in

Two points:
1) This is indeed what variants are for, but there is no restriction
   on what extensions are for, in partucular there is nothing saying
   that you can't use extensions for variants.
2) One reason where an extension would be better is that the necessary
   data (flags and such) could easily go on a separate place (IANA
   or elsewhere), whereas extensions all have to go on the same page
   (unless we would decide to change that).

Regards,     Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Sat, 18 Nov 2006 11:36:56 +0900

Two points:

Regards,     Martin.