Subject: Re: [Ltru] 3.1.4: description field uniqueness

From: "Doug Ewell" <[email-masked]>
Date: Wed, 9 Jul 2008 19:55:24 -0600

"Phillips, Addison" <addison at amazon dot com> wrote:

> <t>The first 'Description' field assigned to record of any specific 
> type ('language', 'extlang', 'script', and so on)  MUST be unique 
> within that given record type so that users do not become confused 
> about which subtag to use. The Language Subtag Reviewer MUST edit any 
> proposed first 'Description' fields so as to ensure uniqueness and 
> prevent collisions between the first 'Description' fields of the 
> various record types. The Language Subtag Reviewer SHOULD edit other, 
> non-first, 'Description' fields to preserve uniqueness as well.</t>
>
> <t>For example, consider the 'language' subtags 'zza' and 'diq'. Their 
> ISO 639-3 reference names (and thus, their first 'Description' field) 
> are "Zaza" and "Dimli" respectively, and do not collide. It happens 
> that 'zza' (Zaza) also has a description in ISO 639-3 of "Dimli". 
> Although not strictly required, it was edited to read "Dimli 
> (macrolanguage)" in the registry to prevent a collision. If 'zza' had 
> originally had a reference name of "Dimli", then such editing to 
> prevent a collision would have been required.</t>

Apparently my previous comment about this got lost in an overly long 
post, so I'll say it again, a bit stronger:

There is no place in 4646, and no place in draft-4646bis except this new 
text, where we give special normative status to the first Description 
field.  The only time the first Description is specifically mentioned is 
in the next paragraph Addison quoted:

> <t>For fields of type 'language', the first 'Description' field 
> appearing in the Registry corresponds whenever possible to the 
> Reference Name assigned by ISO 639-3. This helps facilitate 
> cross-referencing between ISO 639 and the registry. </t>

But that's not normative, it's just a good idea.  We assign the ISO 
639-3 Reference Name to the first Description, but there is no MUST 
about it, and no expectation that applications will be written to assume 
this convention and will break if the convention is broken.

Draft-4645bis is the same: there are a couple of references to putting 
the 639-3 Reference Name in the first Description, but nothing that 
REQUIRES this to be done.  (Then again, there's almost no RFC 2119 text 
in draft-4645bis in general.)

I don't see the harm in saying that all Description fields MUST be 
edited to prevent collisions.  I don't understand why the Dimli 
collision is OK just because "Dimli" isn't the first Description for 
'zza', it's still *a* Description for 'zza' and the collision still has 
the potential to confuse users.  Nobody is ever obliged to treat the 
first Description as the "best" or "preferred" name for the language; 
consider Spanish and Castilian.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 9 Jul 2008 20:40:38 -0700

We decided on the policy for the first Description being the reference name
quite some time ago (probably over a year). Do you really want to open that
up again??
Mark

On Wed, Jul 9, 2008 at 6:55 PM, Doug Ewell <[email-masked]> wrote:

>  <t>The first 'Description' field assigned to record of any specific type
>> ('language', 'extlang', 'script', and so on)  MUST be unique within that
>> given record type so that users do not become confused about which subtag to
>> use. The Language Subtag Reviewer MUST edit any proposed first 'Description'
>> fields so as to ensure uniqueness and prevent collisions between the first
>> 'Description' fields of the various record types. The Language Subtag
>> Reviewer SHOULD edit other, non-first, 'Description' fields to preserve
>> uniqueness as well.</t>
>>
>> <t>For example, consider the 'language' subtags 'zza' and 'diq'. Their ISO
>> 639-3 reference names (and thus, their first 'Description' field) are "Zaza"
>> and "Dimli" respectively, and do not collide. It happens that 'zza' (Zaza)
>> also has a description in ISO 639-3 of "Dimli". Although not strictly
>> required, it was edited to read "Dimli (macrolanguage)" in the registry to
>> prevent a collision. If 'zza' had originally had a reference name of
>> "Dimli", then such editing to prevent a collision would have been
>> required.</t>
>>
>
> Apparently my previous comment about this got lost in an overly long post,
> so I'll say it again, a bit stronger:
>
> text, where we give special normative status to the first Description field.
>  The only time the first Description is specifically mentioned is in the
> next paragraph Addison quoted:
>
>  <t>For fields of type 'language', the first 'Description' field appearing
>> in the Registry corresponds whenever possible to the Reference Name assigned
>> by ISO 639-3. This helps facilitate cross-referencing between ISO 639 and
>> the registry. </t>
>>
>
> But that's not normative, it's just a good idea.  We assign the ISO 639-3
> Reference Name to the first Description, but there is no MUST about it, and
> no expectation that applications will be written to assume this convention
> and will break if the convention is broken.
>
> Draft-4645bis is the same: there are a couple of references to putting the
> 639-3 Reference Name in the first Description, but nothing that REQUIRES
> this to be done.  (Then again, there's almost no RFC 2119 text in
> draft-4645bis in general.)
>
> I don't see the harm in saying that all Description fields MUST be edited
> to prevent collisions.  I don't understand why the Dimli collision is OK
> just because "Dimli" isn't the first Description for 'zza', it's still *a*
> Description for 'zza' and the collision still has the potential to confuse
> users.  Nobody is ever obliged to treat the first Description as the "best"
> or "preferred" name for the language; consider Spanish and Castilian.
>
> --

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 9 Jul 2008 21:57:31 -0600

Mark Davis wrote:

> We decided on the policy for the first Description being the reference 
> name quite some time ago (probably over a year). Do you really want to 
> open that up again??

We did indeed decide that the first Description would reflect the 
reference name.  At no time, however, did we attach MUSTard to the way 
the first Description *and not the others* would be maintained.

I'm not the one opening anything up.  This suddenly appeared Tuesday in 
the uniqueness text, which I did not contribute to (being at work and 
all).  Check the previous drafts; unless I have been in a cave all this 
time, I don't believe you will find anything *normative* about treating 
the first Description differently from the rest.

I don't object to requiring the first Description to be changed in case 
of duplication, as long as we apply that logic to all of the Description 
fields.  Again: why is it OK for non-first Descriptions to collide?

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 9 Jul 2008 21:05:32 -0700

> why is it OK for non-first Descriptions to collide?
We would prefer it if none of the Descriptions collided; we can live with
the looser condition, so that was just a compromise position. We're fine
with tightening it up.

Mark

On Wed, Jul 9, 2008 at 8:57 PM, Doug Ewell <[email-masked]> wrote:

>> name quite some time ago (probably over a year). Do you really want to open
>> that up again??
>>
>
> We did indeed decide that the first Description would reflect the reference
> name.  At no time, however, did we attach MUSTard to the way the first
> Description *and not the others* would be maintained.
>
> I'm not the one opening anything up.  This suddenly appeared Tuesday in the
> uniqueness text, which I did not contribute to (being at work and all).
>  Check the previous drafts; unless I have been in a cave all this time, I
> don't believe you will find anything *normative* about treating the first
> Description differently from the rest.
>
> I don't object to requiring the first Description to be changed in case of
> duplication, as long as we apply that logic to all of the Description

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 9 Jul 2008 22:09:39 -0600

Mark Davis wrote:

> We would prefer it if none of the Descriptions collided; we can live 
> with the looser condition, so that was just a compromise position. 
> We're fine with tightening it up.

It's a bad compromise.  Since you're fine with tightening it up, and I'm 
adamant about it, it looks like we have an agreement.

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 9 Jul 2008 21:27:52 -0700

Nice of you two to agree :-D.

I don't necessarily think we need to cover all cases with MUSTard, but am happy to update the draft in this direction.

This text:

<t>The first 'Description' field assigned to record of any specific type ('language', 'extlang', 'script', and so on)  MUST be unique within that given record type so that users do not become confused about which subtag to use. The Language Subtag Reviewer MUST edit any proposed first 'Description' fields so as to ensure uniqueness and prevent collisions between the first 'Description' fields of the various record types. The Language Subtag Reviewer SHOULD edit other, non-first, 'Description' fields to preserve uniqueness as well.</t>

Now reads:

<t>'Description' fields assigned to record of any specific type ('language', 'extlang', 'script', and so on)  MUST be unique within that given record type so that users do not become confused about which subtag to use. The Language Subtag Reviewer will check and edit any proposed 'Description' fields so as to ensure uniqueness and prevent collisions between 'Description' fields in different records of the same type. If this occurs in an independent registration request, the Language Subtag Reviewer MUST resubmit the record to ietf-languages, treating it as a modification of a request due to discussion, as described in <xref target="registrationProc"></xref>. Requests whose sole purpose is to introduce a duplicate 'Description' field will be rejected.</t>

I also modified the example to read:

<t>For example, consider the 'language' subtags 'zza' (Zaza) and 'diq' (Dimli). It so happens that 'zza' is a macrolanguage enclosing 'diq' and thus also has a description in ISO 639-3 of "Dimli". This description was edited to read "Dimli (macrolanguage)" in the registry record for 'zza' to prevent a collision.</t>

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Doug Ewell
> Sent: Wednesday, July 09, 2008 9:10 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] 3.1.4: description field uniqueness
>
> Mark Davis wrote:
>

---

From: Peter Constable <[email-masked]>
Date: Wed, 9 Jul 2008 21:51:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Doug Ewell

> adamant about it, it looks like we have an agreement.

Are you suggesting that the LSR MUST also ensure uniqueness across records of a given type for all the other Descriptions?

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 9 Jul 2008 22:17:49 -0700

Yes. That's what they said.

Addison

Addison Phillips

> Behalf Of Peter Constable
> Sent: Wednesday, July 09, 2008 9:51 PM
> To: Doug Ewell; LTRU Working Group
> Behalf Of
> > It's a bad compromise.  Since you're fine with tightening it up,
> and
> > I'm
> Are you suggesting that the LSR MUST also ensure uniqueness across
> records of a given type for all the other Descriptions?
>
>
>
> Peter

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 9 Jul 2008 23:36:04 -0600

> records of a given type for all the other Descriptions?

Yep.

Here is the list of conflicting names (excluding deprecated subtags and 
"PRIVATE USE", which we agree aren't part of the problem space):

Languages:
- Aruá (aru, arx)
- Awa (awb, vwa)
- Borna (bwo, bxx)
- Dimli (diq, zza)
- Kirmanjki (kiu, zza)
- Murik (mtf, mxr)

That's not many conflicts out of (exactly!) 8000 Description fields for 
language subtags.  These can be looked up in Ethnologue (or if people 
insist, another source) and it ought to be possible to disambiguate them 
in some way.

There are no conflicts for any other type of subtag.

---

From: Peter Constable <[email-masked]>
Date: Wed, 9 Jul 2008 22:42:52 -0700

I'm OK with the changes.

Peter

> From: Phillips, Addison [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2008 10:18 PM
> To: Peter Constable; Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] 3.1.4: description field uniqueness
>

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 10 Jul 2008 10:00:07 -0700

Great.

Mark

On Wed, Jul 9, 2008 at 10:36 PM, Doug Ewell <[email-masked]> wrote:

>  Are you suggesting that the LSR MUST also ensure uniqueness across records
>> of a given type for all the other Descriptions?
>>
>
> Yep.
>
> insist, another source) and it ought to be possible to disambiguate them in
> some way.
>