Subject: [Ltru] Progress

From: "Doug Ewell" <[email-masked]>
Date: Thu, 8 Feb 2007 06:52:18 -0800

ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 
Web site has been edited [2] and files renamed to remove the "FDIS" 
qualifier throughout.

This removes our last external obstacle to moving RFC 4646bis and 
4645bis forward.  Our goals were to submit these documents for IETF Last 
Call by the end of January, provided that ISO 639-3 had been published 
(the charter actually says "fully approved," which is surely implied by 
publication).  As Mark might put it, it is now the 39th of January and 
we need to get moving if we are going to make the deadline.

I have received no detailed comments on changes to be made in RFC 
4645bis, and will be completely ready to go in a day or so with a 
draft-02, intended for WG LC, that uses the (apparently final) 639-3 
download tables.  However, I don't think I'm supposed to do this unless 
4646bis is ready for WG LC as well (partly because of the lingering 
hex-NCRs question).  Maybe there is some other reason we should be 
waiting and not taking action to move these documents forward, but I 
can't think of any.

[1] 
http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639
[2] http://www.sil.org/iso639-3/

--
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: Thu, 8 Feb 2007 06:56:10 -0800

> 4646bis

I can. Not all of my requests for changes have been considered (they may of
course be rejected, but that needs to be explicit). I will put together a
list and send to this group.

Mark

-- 
Mark

---

From: Peter Constable <[email-masked]>
Date: Thu, 8 Feb 2007 17:50:49 -0800

I can think of another reason: ISO Central Secretariat completed publication faster than we expected: we thought they'd take a few weeks but they posted it the very next day. We still have some details in the code table wrt what to do with certain 639-2 entries that we're sorting out. Now we have an unfortunate quandary: because of the ISO announcement, the downloadable data files can be considered published even though there may be a few things in there that are not ideal meaning we'd be stuck with them. I wish we could clear those up before they got incorporated into a 4645bis draft.

Peter

________________________________
From: Mark Davis [mailto:[email-masked]]
Sent: Thursday, February 08, 2007 6:56 AM
To: Doug Ewell
Cc: LTRU Working Group
Subject: Re: [Ltru] Progress

> 4646bis

I can. Not all of my requests for changes have been considered (they may of course be rejected, but that needs to be explicit). I will put together a list and send to this group.

Mark
On 2/8/07, Doug Ewell <[email-masked]<mailto:[email-masked]>> wrote:
ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3
Web site has been edited [2] and files renamed to remove the "FDIS"
qualifier throughout.

[1]

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 8 Feb 2007 23:07:42 -0800

Peter Constable wrote:

> I can think of another reason: ISO Central Secretariat completed 
> publication faster than we expected: we thought they’d take a few 
> weeks but they posted it the very next day. We still have some details 
> in the code table wrt what to do with certain 639-2 entries that we’re 
> sorting out. Now we have an unfortunate quandary: because of the ISO 
> announcement, the downloadable data files can be considered published 
> even though there may be a few things in there that are not ideal 
> meaning we’d be stuck with them. I wish we could clear those up before 
> they got incorporated into a 4645bis draft.

I can delay the draft as long as necessary so you can get the changes 
in.  It looks like that's going to happen anyway.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Feb 2007 16:04:10 +0100

> in.  It looks like that's going to happen anyway.

If you or Peter like to get a plausibility check based on my registry
to XML to validator.w3 approach you could publish the actual state
anyway (as I-D or proto-registry file).  Of course you can also do
that directly with the gawk script.

For 4646bis I think we're still far from ready, there were tons of
editorial details (including stuff about the review list operation).

But that's not directly related to your part unless we find that the
only way to get the missing Suppress-Scripts right for the pre-639-3
languages is to do it "here" (in 4645bis).

Frank

---

From: Martin Duerst <[email-masked]>
Date: Fri, 09 Feb 2007 15:48:42 +0900

Hello Peter,

What timeline do you expect for this cleanup work?
What is the chance that it can actually be done
(as opposed to being frozen because publication is already done)?

Regards,   Martin.

At 10:50 07/02/09, Peter Constable wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_"
>
>I can think of another reason: ISO Central Secretariat completed publication faster than we expected: we thought they壇 take a few weeks but they posted it the very next day. We still have some details in the code table wrt what to do with certain 639-2 entries that we池e sorting out. Now we have an unfortunate quandary: because of the ISO announcement, the downloadable data files can be considered published even though there may be a few things in there that are not ideal meaning we壇 be stuck with them. I wish we could clear those up before they got incorporated into a 4645bis draft.
> 
>Peter
> 
>
>----------
>On 2/8/07, Doug Ewell <<mailto:[email-masked]>[email-masked]> wrote:
><http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639>http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639
><http://users.adelphia.net/~dewell/>http://users.adelphia.net/~dewell/
><http://www.alvestrand.no/mailman/listinfo/ietf-languages>http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>
><mailto:[email-masked]>[email-masked]

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Feb 2007 11:04:25 +0100

On Thu, Feb 08, 2007 at 06:52:18AM -0800,
 Doug Ewell <[email-masked]> wrote 
 a message of 35 lines which said:

> download tables.

I just tested 4645bis with my registry checking program and I (it)
found no problem.

The only thing that puzzles me is the:

Added: 2008-01-01

for all the ISO 639-3 languages. I assume it should be replaced by the
actual date of publication of 639-3?

For the fun, I loaded it in a database:

lsr2=> SELECT count(*) FROM Languages;
 count 
-------
  7186
(1 row)

lsr2=> SELECT count(*) FROM Languages WHERE added > now();
 count 
-------
  6697
(1 row)

lsr2=> SELECT count(*) FROM Languages WHERE added <= now();
 count 
-------
   489
(1 row)

lsr2=> SELECT count(*) FROM Extlangs;
 count 
-------
   480
(1 row)

lsr2=> SELECT count(*) FROM Variants;
 count 
-------
    12
(1 row)

Congratulations for the huge increase in size :-)

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 13 Feb 2007 06:16:19 -0800

>From Section 2.1, "Starting Point":  "The value of the File-Date field 
and of the Added date for each new subtag record are set to a date near 
the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates 
would be updated during AUTH48.]"

I've found that using a "real" date as a filler in this situation gets 
confusing.  We are adding 7000 entries to a living Registry that is 
simultaneously undergoing its own changes, e.g. adding Meitei Mayak and 
Moon.  Using an artificial date like 2008-01-01 clearly identifies the 
changes that are part of the bulk update.  Ideally this date will be 
changed to the exact date of approval of the RFC.  Last time around, the 
date of the final draft (2005-10-16) ended up enshrined as the "Added" 
date for everything in the Registry even though the RFC wasn't published 
until 11 months later.

l

---

From: Marion Gunn <[email-masked]>
Date: Tue, 13 Feb 2007 14:48:10 +0000

Personally, I feel that adding an artificial date only worsens the  
confusion of genuine and other errors. As an Archivist, I felt  
comfortable enough adding "g.d." (abbreviation in Irish for  
"undated") to entries _sans- known   date of publication. I think  
following that principle/convention (which is accepted  
internationally), would help.
mg

On 13 Feb 2007, at 14:16, scríobh Doug Ewell:

> ... I've found that using a "real" date as a filler in this  
> situation gets confusing.  We are adding 7000 entries to a living  
> Registry that is simultaneously undergoing its own changes, e.g.  
> adding Meitei Mayak and Moon.  Using an artificial date like  
> 2008-01-01 clearly identifies the changes that are part of the bulk  
> update.  Ideally this date will be changed to the exact date of  
> approval of the RFC.  Last time around, the date of the final draft  
> (2005-10-16) ended up enshrined as the "Added" date for everything  
> in the Registry even though the RFC wasn't published until 11  
> months later.

- -
Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: Martin Duerst <[email-masked]>
Date: Sat, 17 Feb 2007 16:23:50 +0900

I think an artificial date is good, but I'd prefer to have one
that look more artificial, e.g. 2099-01-01 or so (e.g.
2029-09-09 to address a point mentioned by John Cowan). Otherwise,
some people might think that we plan to finish this work at
the start of 2008, which would be terriby misleading.

Regards,    Martin.

At 23:16 07/02/13, Doug Ewell wrote:
>> for all the ISO 639-3 languages. I assume it should be replaced by the actual date of publication of 639-3?
>
>>From Section 2.1, "Starting Point":  "The value of the File-Date field and of the Added date for each new subtag record are set to a date near the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates would be updated during AUTH48.]"
>
>I've found that using a "real" date as a filler in this situation gets confusing.  We are adding 7000 entries to a living Registry that is simultaneously undergoing its own changes, e.g. adding Meitei Mayak and Moon.  Using an artificial date like 2008-01-01 clearly identifies the changes that are part of the bulk update.  Ideally this date will be changed to the exact date of approval of the RFC.  Last time around, the date of the final draft (2005-10-16) ended up enshrined as the "Added" date for everything in the Registry even though the RFC wasn't published until 11 months later.
>
>--

---

From: Marion Gunn <[email-masked]>
Date: Mon, 19 Feb 2007 12:53:29 +0000

Thank you for that, Martin. That is precisely the point I was trying  
to make, only put more clearly by you. However, this is not so  
important, so I accept what has been decided already on that point.
mg

- -

---

From: Martin Duerst <[email-masked]>
Date: Wed, 28 Feb 2007 11:09:00 +0900

Hello Peter,

I haven't seen any news on this issue. Although we have other things
to sort out, this one is crucial for our timeline, and so any info
is appreciated!

Regards,   Martin.

At 15:48 07/02/09, Martin Duerst wrote:
>>Content-Type: 
>multipart/alternative;boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_"
>>
>publication faster than we expected: we thought they壇 take a few weeks but 
>they posted it the very next day. We still have some details in the code 
>table wrt what to do with certain 639-2 entries that we池e sorting out. Now 
>we have an unfortunate quandary: because of the ISO announcement, the 
>downloadable data files can be considered published even though there may 
>be a few things in there that are not ideal meaning we壇 be stuck with 
>them. I wish we could clear those up before they got incorporated into a 
>4645bis draft.
>> 
>>Peter
>> 
>>
>>----------
>>I can. Not all of my requests for changes have been considered (they may 
>of course be rejected, but that needs to be explicit). I will put together 
>a list and send to this group.
>>
>>Mark