At 00:10 06/08/05, Addison Phillips wrote:
>>>> The working group will also deliver means to update the current
>>>> IANA language subtag registry with the newly available codes.
>>> I would change this to be slightly more expansive:
>>>
>>> --
>>> The working group will also deliver a means to update the current
>>> IANA language subtag registry with the newly available codes, as well
>>> as procedures for maintaining the registry as codes are assigned or modified in the future.
>> My understanding is that we already have the procedures for
>> updating. Or do we miss something?
>
>We do. The "means of updating" would probably be some form of new "draft-initial".
Yes. This is worded as "means of updating" on purpose, because it gives
us some leeway to choose some other means than an internet-draft if we
think an internet draft really doesn't work (e.g. because of the volume).
>The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today.
I understand that we need these. And they are not covered by the "deliver a
means" sentence. However, they are covered by the following sentence before:
--------
The working group will prepare an update to the Language Subtag
Registry procedures to allow the use of 3-letter code elements
from ISO 639-3 as primary language subtags or extended language
subtags as appropriate.
--------
In my understanding, "procedures" here include the procedures for
updates to the registry at later points in time when new code
elements are added to ISO 639-3.
>>> --
>>>
>>> Or you mighFrom ltru-bounces at ietf.org Sat Aug 05 03:38:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G9Gk7-0002vF-It; Sat, 05 Aug 2006 03:38:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002v2-Ba
for ltru at ietf.org; Sat, 05 Aug 2006 03:38:42 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mZ-LT
for ltru at ietf.org; Sat, 05 Aug 2006 03:38:42 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16])
by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
k757cQ66024240; Sat, 5 Aug 2006 16:38:26 +0900 (JST)
Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp
id 19b8_617661d4_2455_11db_8eda_0014221fa3c9;
Sat, 05 Aug 2006 16:38:26 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBQ0028368;
Sat, 5 Aug 2006 16:38:21 +0900
Message-Id: <6.0.0.20.2.20060805114558.09dd4580 at localhost>
X-Sender: duerst at localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Sat, 05 Aug 2006 16:37:49 +0900
To: Addison Phillips <addison at yahoo-inc.com>
From: Martin Duerst <duerst at it.aoyama.ac.jp>
Subject: Re: [Ltru] Charter update proposal
In-Reply-To: <44D3635C.5020902 at yahoo-inc.com>
References: <6.0.0.20.2.20060726163255.05cb0cf0 at localhost>
<000601c6b286$a34cd0c0$9fcd15ac at ds.corp.yahoo.com>
<6.0.0.20.2.20060804174746.07f62c90 at localhost>
<44D3635C.5020902 at yahoo-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: 'LTRU Working Group' <ltru at ietf.org>
X-BeenThere: ltru at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list
<ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru at ietf.org>
List-Help: <mailto:ltru-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=subscribe>
Errors-To: ltru-bounces at ietf.org
At 00:10 06/08/05, Addison Phillips wrote:
>>>> The working group will also deliver means to update the current
>>>> IANA language subtag registry with the newly available codes.
>>> I would change this to be slightly more expansive:
>>>
>>> --
>>> The working group will also deliver a means to update the current
>>> IANA language subtag registry with the newly available codes, as well
>>> as procedures for maintaining the registry as codes are assigned or modified in the future.
>> My understanding is that we already have the procedures for
>> updating. Or do we miss something?
>
>We do. The "means of updating" would probably be some form of new "draft-initial".
Yes. This is worded as "means of updating" on purpose, because it gives
us some leeway to choose some other means than an internet-draft if we
think an internet draft really doesn't work (e.g. because of the volume).
>The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today.
I understand that we need these. And they are not covered by the "deliver a
means" sentence. However, they are covered by the following sentence before:
--------
The working group will prepare an update to the Language Subtag
Registry procedures to allow the use of 3-letter code elements
from ISO 639-3 as primary language subtags or extended language
subtags as appropriate.
--------
In my understanding, "procedures" here include the procedures for
updates to the registry at later points in time when new code
elements are added to ISO 639-3.
>>> --
>>>
>>> Or you mighFrom ltru-bounces at ietf.org Sat Aug 05 03:38:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G9Gk7-0002vF-It; Sat, 05 Aug 2006 03:38:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002v2-Ba
for ltru at ietf.org; Sat, 05 Aug 2006 03:38:42 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mZ-LT
for ltru at ietf.org; Sat, 05 Aug 2006 03:38:42 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16])
by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
k757cQ66024240; Sat, 5 Aug 2006 16:38:26 +0900 (JST)
Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp
id 19b8_617661d4_2455_11db_8eda_0014221fa3c9;
Sat, 05 Aug 2006 16:38:26 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBQ0028368;
Sat, 5 Aug 2006 16:38:21 +0900
Message-Id: <6.0.0.20.2.20060805114558.09dd4580 at localhost>
X-Sender: duerst at localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Sat, 05 Aug 2006 16:37:49 +0900
To: Addison Phillips <addison at yahoo-inc.com>
From: Martin Duerst <duerst at it.aoyama.ac.jp>
Subject: Re: [Ltru] Charter update proposal
In-Reply-To: <44D3635C.5020902 at yahoo-inc.com>
References: <6.0.0.20.2.20060726163255.05cb0cf0 at localhost>
<000601c6b286$a34cd0c0$9fcd15ac at ds.corp.yahoo.com>
<6.0.0.20.2.20060804174746.07f62c90 at localhost>
<44D3635C.5020902 at yahoo-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: 'LTRU Working Group' <ltru at ietf.org>
X-BeenThere: ltru at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list
<ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru at ietf.org>
List-Help: <mailto:ltru-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=subscribe>
Errors-To: ltru-bounces at ietf.org
At 00:10 06/08/05, Addison Phillips wrote:
>>>> The working group will also deliver means to update the current
>>>> IANA language subtag registry with the newly available codes.
>>> I would change this to be slightly more expansive:
>>>
>>> --
>>> The working group will also deliver a means to update the current
>>> IANA language subtag registry with the newly available codes, as well
>>> as procedures for maintaining the registry as codes are assigned or modified in the future.
>> My understanding is that we already have the procedures for
>> updating. Or do we miss something?
>
>We do. The "means of updating" would probably be some form of new "draft-initial".
Yes. This is worded as "means of updating" on purpose, because it gives
us some leeway to choose some other means than an internet-draft if we
think an internet draft really doesn't work (e.g. because of the volume).
>The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today.
I understand that we need these. And they are not covered by the "deliver a
means" sentence. However, they are covered by the following sentence before:
--------
The working group will prepare an update to the Language Subtag
Registry procedures to allow the use of 3-letter code elements
from ISO 639-3 as primary language subtags or extended language
subtags as appropriate.
--------
In my understanding, "procedures" here include the procedures for
updates to the registry at later points in time when new code
elements are added to ISO 639-3.
>>> --
>>>
>>> Or you might consider using a separate sentence, such as the one I proposed
>>> yesterday:
>>>
>>> --
>>> The working group must decide how ISO 639-3 codes are entered into the
>>> registry, what rules apply to associating a code with the language and/or
>> =>extlang subtag types, and any additional rules or guidance on their adoption
>>> and use.
>>> --
>> I don't see what's substantially different here from the existing
>> text:
>> The working group will prepare an update to the Language Subtag
>> Registry procedures to allow the use of 3-letter codes from
>> ISO 639-3 as primary subtags or extended language subtags as
>> appropriate.
>> In short, we have to update the procedures so that we can use
>> IOS 639-3. I don't think that we need more details here.
>> How codes are entered, what types they are given, and so on,
>> should all be covered under Language Subtag Registry
>> procedures.
>
>Yes, but the things I mention are requirements that the Working Group must address. I favor listing requirements explicitly and treating other items as "potentially out of scope". We might, for example, decide that the best thing to do about, say, transliterations is "nothing". But we must decide in this iteration what to do about extlangs.
I don't see any reason why we wouldn't. The things that you mention
to me are obvious details, not things that need to be called out
because otherwise there would be major misunderstandings.
>>>> Work on the drafts is planned to start before ISO 639-3 is fully
>>>> approved and published. However, the WG will not finalize the drafts
>>>> before ISO 639-3 is fully approved.
>>> I'm not sure that's correct. It would be more appropriate to say
>>> "Publication of the draft(s) as an RFC will depend on final approval of ISO
>>> 639-3." There is ample space in the RFC Editor process for awaiting specific
>>> external events (as we've already discovered). We might well finalize an
>>> update to draft-registry quite quickly, but not the actual registry update
>>> ("draft-initial").
>> Peter said that he would have the approval by the third week of September.
>> Do you think we'll be finished with our drafts before that?
>
>No, but your text was not correct.
Is it still not correct? If yes, how?
>I'm allergic to artificial dependencies, based on our experience with 3066bis. ISO 639-3 might (unlikely as it probably is) take longer than Peter imagines. Our drafts, meanwhile, might go very quickly [if we can avoid the tar pits surrounding issues I personally would prefer to see remain off-topic].
I understand that you want things to be done as quickly as possible.
And I agree. However, I don't think it would be appropriate for
the WG to finalize the new draft and send it to the IESG before
we know that ISO 639-3 is really approved, because the fact that
it is not fully approved may mean that there are some more
changes, in which case we have to go back and make some
changes, too. As ISO 639-3 is the major reason for our new
work, I wouldn't call this an "artificial" dependency.
Regards, Martin.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.