Subject: [Ltru] Re: Description field ordering

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Dec 2006 10:45:14 -0800

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> The "perceived problem" is that current programs that read the file 
> would need to be updated before they would get the new field. Now, if 
> we did option 1a (see email Dec 15), that would still work, assuming 
> that the programs used the forward-compatibility strategy of skipping 
> fields they don't understand, but at the slight cost of duplicating 
> information.
>
> This it still would be simpler to just use the first Description.

What if you added a Reference-Name field, but *only* for subtags that 
have more than one Description, or whose single Description does not 
match the ISO reference name?

Then the Registry would not be clogged with thousands of lines of 
duplicated information, and the rules would be simple:

1.  If the subtag entry has a Reference-Name field, its value is the ISO 
reference name.

2.  Otherwise, if there is only one Description field, its value is the 
ISO reference name, or no ISO reference name exists for that entity.

3.  Otherwise, no ISO reference name exists, and any of the Description 
fields may be used by applications for that purpose.

Rules 2 and 3 leave it ambiguous whether an ISO reference name actually 
exists or not.  (For example, no such thing appears to exist for the 
UN-based numeric region subtags.)  If a user needs this information, the 
best place to go is probably the ISO standard itself.

Problem:  Whenever there a proposal to add, change, or remove a 
Description field, it would be necessary for the ietf-languages 
administrative and clerical types to check whether the Reference-Name 
field would be affected (i.e. whether one would have to be added or 
deleted).

Problem 2:  Some parsers may not have been built to ignore unrecognized 
tags, and may crash if we introduce *any* new field type.  I couldn't 
finding any wording in 4646 that parsers are supposed to do this, 
although it's a good idea.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages 

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

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Dec 2006 13:28:15 -0800

That's an interesting suggestion. I would still prefer just using the first
one, but this is a tenable alternative. Will send separate note on other
issue.

Mark

---

From: Addison Phillips <[email-masked]>
Date: Mon, 18 Dec 2006 13:37:01 -0800

It just isn't necessary to add a new field. Ensuring that the first 
Description matches a particular description provided by the source 
standard is hardly Earth-shaking. We're not making the description any 
more normative than it was before, nor prohibiting the addition of other 
descriptions, nor saying anything about relative quality or preference 
for any particular description. We're just saying: if you look up this 
subtag, which came from ISO 639, in ISO 639, you'll find this name as 
the Reference Name.

I can live with that and think that's actually useful (when we have 7000 
of these things).

We could probably do the same for the other subtag types, except that it 
isn't necessary.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Dec 2006 14:08:19 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> standard is hardly Earth-shaking.

I am fine with that or with my proposal, and will leave it at that. 
With just over six weeks left before our IETF Last Call deadline, we 
need to reach a decision on this and move along.