Subject: Re: [Ltru] On "code" in ISO standards

From: "Doug Ewell" <[email-masked]>
Date: Mon, 8 Jun 2009 19:55:45 -0600

John Cowan <cowan at ccil dot org> wrote:

> During the WG discussion of 4646, I proposed changing "code" to "code 
> element" for conformity with ISO 639 and ISO 3166; however, that 
> proposal failed to gain consensus.

I don't remember what my opinion was at the time, if any, but I would 
support such a proposal today.  (Which is not the same as saying, "Let's 
reopen the document and change 2,000 occurrences of a term.")

It's a shame we don't have the convenient French terms "code" and 
"codet" at our disposal.  "Code element," while correct, sounds stilted 
and awkward.

--
Doug Ewell  *  Thornton, 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  ˆ

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 8 Jun 2009 20:02:51 -0600

Alexey Melnikov <alexey dot melnikov at isode dot com> wrote:

> A registrations request is sent on date T1 and approved by you on date 
> T2. You send a message to IANA saying that it was approved, the 
> message is eaten by IANA's antispam engine (or whatever). Another 
> request approved on date T3 (T3 > T2) is integrated to the registry, 
> IANA updates the registry date to be T3.
> Then later on the first request is discovered to be lost and resend. 
> If IANA is to act according to the procedure as described in 4646bis 
> right now, IANA will not change the registry date, because T2 < T3 (== 
> the registry date)

I understand now.  What IANA would actually do in this case is apply a 
File-Date of T4 (= "later on") and all would be well.  But this isn't 
what the draft says they would do.

>> so the passage in 5.1 about a new File-Date record having "a later 
>> date than the record being inserted or modified" often does apply.
>
> I don't understand how you came to this conclusion. This probably 
> means that this sentence is already ambiguous.

You're right.  The passage says that in your example above, IANA would 
apply T3 (again) instead of T2.  Both would be wrong.

>> 4. IANA usually tends to ignore the File-Date records attached to the 
>> replacement records anyway, and instead applies the date on which 
>> they process the changes and release the new Registry.
>
> I agree that this is what IANA should do. In fact as per recent 
> discussion I think IANA MUST always do that. But IANA is violating the 
> procedure described in 4646bis as written.
>
> So I am basically asking to align the document with the current 
> procedure Michael/you and IANA are already using.

I understand and agree.

> In another message Doug Ewell <doug at ewellic.org> wrote:
>
>> You should always be able to use the File-Date to determine whether a 
>> local copy is up to date.  A later revision of the Registry will 
>> always have an later File-Date than an earlier version, unless (a) 
>> somebody makes a mistake or (b) IANA generates two revisions in a 
>> single day.  Both (a) and (b) are possible, but about equally 
>> unlikely.
>
> I agree that (a) is unlikely. Even if (b) is possible, I think it is 
> Ok stating this explicitly in the document.

Something like "IANA MUST process only one batch per day, to avoid 
File-Date ambiguity problems"?

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 20:53:34 -0700

I recall that I opposed it strictly because it was stilted and awkward sounding. I agree with John that it is technically more correct. But it isn't now nor was it necessary then to change it.

Addison

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: Monday, June 08, 2009 6:56 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] On "code" in ISO standards
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 16:04:06 +0900

Hello Doug, others,

co-chair hat off:

On 2009/06/09 11:02, Doug Ewell wrote:
>>> single day. Both (a) and (b) are possible, but about equally unlikely.
>>

I think this goes into the right direction, but "File-Date ambiguity 
problems" will raise questions with our readers.

What about:

To make sure that updates to the registry, and different versions of the 
registry, can be distinguished by only checking their File-Date, IANA 
will publish at most one new version of the registry per day, and will 
make sure that the File-Dates in subsequent publications of the registry 
are strictly in temporal order.

Regards,    Martin.

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

---

From: Lang Gérard <[email-masked]>
Date: Tue, 9 Jun 2009 09:04:38 +0200

1-Please note that only "ISO 3166/MA" exists, not "ISO 3166/RA". 
2-I confirm that ISO 3166 (and also ISO 639) make a firm distinction between a code (that is a codification scheme) and a code element (that is a value given by the code scheme for a given entry).
3-What would be the drama to forge "codet" (that is the french word for "code element") as a new english word to replace "code element" ?
Gérard LANG

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 8 juin 2009 22:52
À : [email-masked]
Objet : Ltru Digest, Vol 52, Issue 7

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Send Ltru mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."

Today's Topics:

   1. On "code" in ISO standards (Peter Constable)
   2. Re: On "code" in ISO standards (Phillips, Addison)
   3. Re: On "code" in ISO standards (John Cowan)
   4. Re: On "code" in ISO standards (Peter Constable)
   5. Re: On "code" in ISO standards (Phillips, Addison)
   6. Re: Issue #40: AD #7 - section 3.4 on ISO 3166 vs UN M.49
      (Alexey Melnikov)
   7. Re: Registering a primary language subtag (was: Additional
      issues with 4646bis...) (Alexey Melnikov)
   8. Re: Issue #43: AD #10 - section 5.1 vs 3.2 on File-Date value
      (Alexey Melnikov)

----------------------------------------------------------------------

Message: 1
Date: Mon, 8 Jun 2009 12:19:53 -0700
From: Peter Constable <[email-masked]>
Subject: [Ltru] On "code" in ISO standards
To: Kent Karlsson <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Karlsson

> "Code" is what these items are called in the respective source standards.

I'll start off by saying I'm have no qualms with the use of "code" in 4646bis at present. 

That said, Kent's claim is not generally true. While it's clear that there is common usage of "code" to refer to individual coding identifiers, in ISO coding standards "code" is usually formally defined as the complete coding system. The use of plural in the title of ISO 639 does was not a reflection of there being multiple identifiers / coded entities, but that there is more than one scheme. (The authors of 639-2 were a little bit imprecise in defining terms, so at times it may seem like "code" is used to mean an individual ID. Unfortunately, ISO 15924 used 639-2 as a model and went the wrong way, becoming the exception to the norm.)

For instance, here are definitions from various standards (I find the wording from 2382-4 makes this clearest):

ISO 639: 1988
language code: A set of symbols used to designate languages.

ISO 639-2:1998
code: data representation in different forms according to a pre-established set of rules language code: combination of characters used to represent a language or languages

ISO 2382-4:1999
code / coding scheme: a collection of rules that maps the elements of a first set onto the elements of a second set code value / code element / code (deprecated in this sense): the result of applying a code to an element of a coded set

ISO 3166-3:1999 (same definitions as ISO 3166-1:1997)
code: data transformation or data representation in different forms according to pre-established rules [Adapted from ISO 5127-1:1983, 1.1.4-06] code element: result of applying a code to an element in a set of elements to be coded country code: listing of country names with their representations by code elements

ISO 639-1:2002
code: data transformed or represented in different forms according to a pre-established set of rules code element: individual entry in a code

ISO 639-3:2007
code: data transformed or represented in different forms according to a pre-established set of rules code element: individual entry in a code table

ISO 3166-1:2005
code: set of data transformed or represented in different forms according to a pre-established set of rules [ISO 5127:2001, 1.1.4-07] code element: the result of applying a code to an element of a coded set [ISO/IEC 2382-4:1999, 04.02.04] NOTE 2 In this part of ISO 3166 a code element represents a country name.
country code: listing of country names with their representations by code elements

Peter

------------------------------

Message: 2
Date: Mon, 8 Jun 2009 12:29:23 -0700
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] On "code" in ISO standards
To: Peter Constable <[email-masked]>, Kent Karlsson
	<[email-masked]>, LTRU Working Group <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

> 
> > "Code" is what these items are called in the respective source
> standards.
> 
> I'll start off by saying I'm have no qualms with the use of "code"
> in 4646bis at present.

I'll point out that we define the word 'code' in 4646bis (and 4646, for that matter) strictly as internal terminology. We did so to distinguish items from the underlying standards from items in the registry in the many places in the document where 'codes' from a standard are discussed in relation to 'subtags' in the registry. It's an important distinction and one that should be preserved. In fact, I'm slightly incredulous about the comment.

Addison

------------------------------

Message: 3
Date: Mon, 8 Jun 2009 15:35:29 -0400
From: John Cowan <[email-masked]>
Subject: Re: [Ltru] On "code" in ISO standards
To: Peter Constable <[email-masked]>
Cc: LTRU Working Group <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Peter Constable scripsit:

> I'll start off by saying I'm have no qualms with the use of "code"
> in 4646bis at present.

[details snipped]

During the WG discussion of 4646, I proposed changing "code" to "code element" for conformity with ISO 639 and ISO 3166; however, that proposal failed to gain consensus.

-- 
Even a refrigerator can conform to the XML      John Cowan
Infoset, as long as it has a door sticker       [email-masked]
saying "No information items inside".           http://www.ccil.org/~cowan
        --Eve Maler

------------------------------

Message: 4
Date: Mon, 8 Jun 2009 13:04:13 -0700
From: Peter Constable <[email-masked]>
Subject: Re: [Ltru] On "code" in ISO standards
To: "Phillips, Addison" <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="utf-8"

With my comment? 

I was merely commenting on Kent's suggestion that our use is derived from ISO standards. Your clarification makes it clear that our use was definitely not derived from ISO standards, and so is not incompatible with my comment.

Peter

-----Original Message-----
From: Phillips, Addison [mailto:[email-masked]]
Sent: Monday, June 08, 2009 12:29 PM
To: Peter Constable; Kent Karlsson; LTRU Working Group
Subject: RE: On "code" in ISO standards

> In fact, I'm slightly incredulous about the comment.

Addison

------------------------------

Message: 5
Date: Mon, 8 Jun 2009 13:05:08 -0700
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] On "code" in ISO standards
To: Peter Constable <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

> With my comment?

No, with the original comment.

Addison

------------------------------

Message: 6
Date: Mon, 08 Jun 2009 21:20:03 +0100
From: Alexey Melnikov <[email-masked]>
Subject: Re: [Ltru] Issue #40: AD #7 - section 3.4 on ISO 3166 vs UN
	M.49
To: Doug Ewell <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

>> # 40: The new text is better, but it doesn't specify any dealine (as 
>> other cases do). If the WG and Expert Reviewers think that this is 
>> Ok, then it is Ok with me.
>
> I think this is expected to be such a rare and extraordinary 
> situation, and we have so little experience (i.e. none) petitioning 
> ISO 3166/RA in this way, that the vagueness seems justified and 
> harmless. Any number of days we specify is likely to be as arbitrary 
> as any other.

Right.

What I had in mind is that the default action is going to be done after the period expires, but not before.

> Remember that the new ISO 3166-1 rule about not reusing code elements 
> for 50 years should greatly reduce or eliminate the stated scenario of 
> "an ISO 3166-1 code that is blocked from registration by an existing 
> subtag."
>
> This is a corner-of-the-corner case, and as one of the Designated 
> Experts likely to be caught in the middle of the whole scenario should 
> it ever occur, I don't see a problem here.

This is not a big deal, I am Ok leaving the current text as is.

------------------------------

Message: 7
Date: Mon, 08 Jun 2009 21:30:34 +0100
From: Alexey Melnikov <[email-masked]>
Subject: Re: [Ltru] Registering a primary language subtag (was:
	Additional issues with 4646bis...)
To: Doug Ewell <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

>Sorry, there is no ticket for this yet, but at least this e-mail deals 
>with only one issue.
>
>>>>>At the time this document was created, there were no examples of 
>>>>>this kind of subtag and future registrations of this type are 
>>>>>discouraged: primary languages are strongly RECOMMENDED for 
>>>>>registration with ISO 639, and proposals rejected by ISO 639/ 
>>>>>RA-JAC will be closely scrutinized by the Language Subtag Reviewer 
>>>>>before they are registered with IANA.
>>>>>
>>>>This might be a big deal, so this might actually require wider 
>>>>review, such as IETF LC.
>>>
>>>What is a big deal? Why would an IETF LC be appropriate for this?
>>
>>To alert IAB and other interested parties about the situation.
>  
>Huh?
>
>Someone wants to register a language subtag for (say) Loxian and 
>submits a proposal form to ietf-languages. The Language Subtag 
>Reviewer, or designee, submits a proposal to ISO 639/RA-JAC. That body 
>consults with Linguist List, and after due process decides not to 
>assign a code element. The original requester makes a convincing case 
>to ietf-languages that the subtag is justified. The Reviewer and group 
>"closely scrutinize" the request and decide to assign the subtag.
>
>
>Why would this matter deserve special attention by the Internet 
>Architecture Board? Who are the "other interested parties" who need to 
>review this?
>The tag "i-enochian" was registered in 2002. If done under
>4646 or 4646bis, it would have been the primary language subtag 
>"enochian" instead. As I recall, neither the IAB nor "other interested 
>parties" were specially alerted. What problems did this cause?

Doug, this suggestion wasn't because of my mistrust to Language Tag Reviewers, or anything like this. I am just relaying the sentiment expressed by the Apps Team reviewer.

After thinking more about this, I think suggesting that interested parties should subscribe to the mailing list where reviews take place and closing this part of the issue as "no change" would be just fine.

------------------------------

Message: 8
Date: Mon, 08 Jun 2009 21:51:35 +0100
From: Alexey Melnikov <[email-masked]>
Subject: Re: [Ltru] Issue #43: AD #10 - section 5.1 vs 3.2 on
	File-Date value
To: LTRU Working Group <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Doug Ewell <doug at ewellic.org> wrote:

> Can someone give an example scenario with example dates, to help me 
> understand what the problem is?

A registrations request is sent on date T1 and approved by you on date T2. You send a message to IANA saying that it was approved, the message is eaten by IANA's antispam engine (or whatever). Another request approved on date T3 (T3 > T2) is integrated to the registry, IANA updates the registry date to be T3.
Then later on the first request is discovered to be lost and resend. If IANA is to act according to the procedure as described in 4646bis right now, IANA will not change the registry date, because T2 < T3 (== the registry date)

> Remember that:
>
>
> 1. It isn't expected to be possible to tell, just by looking at a 
> given version of the Registry, whether IANA has processed all of the 
> changes submitted to them.

This is fine.

Note, that this observation is not stated anywhere in the document.

> 2. Modifications to existing records do not cause an update to the 
> Added date,

Right.

> so the passage
> in 5.1 about a new File-Date record having "a later date than the 
> record being inserted or modified"
> often does apply.

I don't understand how you came to this conclusion. This probably means that this sentence is already ambiguous.

> 3. As stated previously, Michael and I usually batch the requests 
> together before submitting them to IANA, even if they were originally 
> submitted a few days apart or their review periods ended on different 
> days for some reason. It would be very unusual for us to send IANA a 
> few requests on Monday, a few more on Tuesday, and so on.

I don't see a problem with that.

> replacement records anyway, and instead applies the date on which they 
> process the changes and release the new Registry.

I agree that this is what IANA should do. In fact as per recent discussion I think IANA MUST always do that.
But IANA is violating the procedure described in 4646bis as written.

So I am basically asking to align the document with the current procedure Michael/you and IANA are already using.

================
In another message Doug Ewell <doug at ewellic.org> wrote:

> Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:
>
>>I don't think there is any actual problem in current practice, just 
>>that the formal handling is not calling for this actual handling and 
>>leaves a hole open for the possible problem of not being formally 
>>"guaranteed" to be able to use the file-date alone to determine if a 
>>local copy is up-to-date or not.
>>Plugging that hole seem to not change actual current practice, just to 
>>reinforce it.
>
> local copy is up to date.
> A later revision of the Registry will always have an later File-Date 
> than an earlier version, unless (a) somebody makes a mistake or (b) 
> IANA generates two revisions in a single day.
> Both (a) and (b) are possible, but about equally unlikely.

I agree that (a) is unlikely. Even if (b) is possible, I think it is Ok stating this explicitly in the document.

> I'm glad our efforts to work out the big problems have been so 
> successful that we have to resort to hypothetical cases like this to 
> find flaws in the process.

------------------------------

End of Ltru Digest, Vol 52, Issue 7
***********************************

---

From: Kent Karlsson <[email-masked]>
Date: Tue, 09 Jun 2009 11:51:49 +0200

> are strictly in temporal order.

Then we would have a somewhat complicated rule for handling File-Date (as
in the current draft, which is already not followed) and *then* say "by the
way, that does not really work, we need to add this extra complication too".

As I mentioned before, I'd like something much more straightforward,
and indeed what seems to be the actual case already.

======OLD TEXT=================

Whenever an entry is created or modified in the registry, the 'File-Date'
record at the start of the registry is updated to reflect the most recent
modification date in the [RFC3339] (Klyne, G., Ed. and C. Newman, "Date and
Time on the Internet: Timestamps," July 2002.) "full-date" format: included
in any request to insert or modify records will be a new File-Date record
indicating the acceptance date of the record. This record is to be placed
first in the registry, replacing the existing File-Date record. In the event
that the File-Date record present in the registry has a later date than the
record being inserted or modified, then the latest (most recent) record will
be preserved. IANA should attempt to process multiple registration requests
in order according to the File-Date in the form, since one registration
could otherwise cause a more recent change to be overwritten.

======END OLD TEXT=============

======PROPOSED TEXT=================

Whenever an entry is created or modified in the registry, the 'File-Date'
record at the start of the registry is updated to reflect the most recent
modification date. The date format SHALL be the "full-date" format of
[RFC3339] (Klyne, G., ed. and C. Newman, "Date and Time on the Internet:
Timestamps", July 2002). The date SHALL be the date that version of the
registry was first published by IANA. There SHALL be at most one version of
the registry published in a day.

A File-Date record is also included in each request to IANA to insert or
modify records indicating the acceptance date of the records in the request.

======END PROPOSED TEXT=============

It appears that this is already current practice.

        /kent k

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 19:03:41 +0900

Hello Kent,

Many thanks for providing actual new text. I'm fine with that, except 
for a little nit below.

On 2009/06/09 18:51, Kent Karlsson wrote:
> Den 2009-06-09 09.04, skrev "Martin J. Dürst"<[email-masked]>:

> It appears that this is already current practice.

"the date that version" is a bit difficult to read, and may lead to 
misunderstandings. I propose to make this "the date on which that 
version". The new text would be:

Whenever an entry is created or modified in the registry, the 
'File-Date' record at the start of the registry is updated to reflect 
the most recent modification date. The date format SHALL be the 
"full-date" format of [RFC3339] (Klyne, G., ed. and C. Newman, "Date and 
Time on the Internet: Timestamps", July 2002). The date SHALL be the 
date on which that version of the registry was first published by IANA. 
There SHALL be at most one version of the registry published in a day.

Regards,    Martin.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 9 Jun 2009 07:04:20 -0600

I think Kent's proposed text, together with Martin's slight edit, is 
excellent.  It reflects current IANA practice, which works well and is 
really better than what 4646 says, and it provides a justification for 
the File-Date records in the replacement records even though IANA 
doesn't use them verbatim.  Let's go with it.

> "full-date" format of [RFC3339] (Klyne, G., ed. and C. Newman, "Date
> and Time on the Internet: Timestamps", July 2002). The date SHALL be
> the date on which that version of the registry was first published by
> IANA. There SHALL be at most one version of the registry published in
> a day.
>
> A File-Date record is also included in each request to IANA to insert
> or modify records indicating the acceptance date of the records in the
> request.
>

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 06:59:31 -0700

+1

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 9 Jun 2009 07:44:51 -0700

+1

Addison Phillips

> Behalf Of Peter Constable
> Sent: Tuesday, June 09, 2009 7:00 AM
> To: Doug Ewell; LTRU Working Group

---

From: Mark Davis <[email-masked]>
Date: Tue, 9 Jun 2009 08:35:35 -0700

+1

Mark

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 10:11:03 +0900

[hats on]

I have counted 6 people in favor of the new text, and nobody against.
Editors, please replace the old text (see Kent's earlier mail in this 
thread) with the text below.

Randy, please close this issue.

Regards,    Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Jun 2009 09:49:15 -0700

Hi -

> From: "Martin J. Dürst" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, June 09, 2009 6:11 PM

Done.

Randy