Subject: [Ltru] Delays (was: Re: Charter update proposal)

From: "Doug Ewell" <[email-masked]>
Date: Sat, 5 Aug 2006 13:10:29 -0700

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

>> 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).

This used to worry me simply on the basis of volume -- an I-D like 
draft-ietf-ltru-initial, containing the entire 3066ter initial registry 
contents, would be more than 840 pages long.

After witnessing the extreme delays involved in this process, I'm 
increasingly concerned about the temporal problem as well.

Draft-initial was sent to IESG in August 2005, ostensibly for a 2- to 
4-week Last Call, and spent 3 months there before moving into the RFC 
Editor queue.  During that time alone, the draft had to be updated to 
reflect changes in its proposed initial registry contents.

In the nine months since draft-initial entered the RFC Editor queue, and 
IANA created the initial Language Subtag Registry, they have updated it 
SIX times.  The "meat" of the draft, which is to be removed by the RFC 
Editor before publication, is dreadfully obsolete by now.  John Cowan's 
question about an RFC being superseded before publication is appropriate 
here.

The activities of the WG have been repeatedly stalled by side 
discussions, groundless appeals, IETF activities that take precedence, 
and our own inactivity -- long periods of silence on the list, and Last 
Call comments that are withheld until the last day, necessitating 
lengthy discussions and additional Last Calls.

IESG approved the matching draft on July 6, but it took 18 days to send 
the announcement.  Another 12 days have gone by and the matching draft 
still has not entered the RFC Editor queue.  What is the reason for the 
delay this time?  How long can we expect it to go on?

Whether it's written into the charter or not, the WG will need to 
consider the impact of unexpected, protracted delays on each of its 
activities, and will need to act accordingly to avoid degrading the 
value and credibility of its deliverables.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 5 Aug 2006 21:08:51 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, August 05, 2006 1:10 PM
> Subject: [Ltru] Delays (was: Re: Charter update proposal)
...
> delay this time?  How long can we expect it to go on?
...

When I look at http://www.rfc-editor.org/queue.html,
the matching draft is there in the queue.  What leads
you to believe that it isn't?

Randy

---

From: Martin Duerst <[email-masked]>
Date: Sun, 06 Aug 2006 18:35:37 +0900

At 05:10 06/08/06, Doug Ewell wrote:
>>> 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).
>
>This used to worry me simply on the basis of volume -- an I-D like draft-ietf-ltru-initial, containing the entire 3066ter initial registry contents, would be more than 840 pages long.

Yes indeed, that's the reason for why we have some leeway in the charter.

>After witnessing the extreme delays involved in this process, I'm increasingly concerned about the temporal problem as well.

Your point that draft-initial, and it's complement in the new round of
drafts, are getting obsoleted in the approval and publication process
in a way that doesn't happen for the average internet-draft is well
taken. In my opinion, we will have to be more clear in the registry
draft about what happens with new code elements that get registered
by the ISO registration authority during the approval/publication
process. But I don't think anything about this needs to be said
explicitly in the charter.

One thing I'm wondering about is the expected number of updates to
the ISO 639-3 registry. One theory would be that 639-3 is already
so comprehensive that updates will be very rare. Another theory is
that updates will be proportional to the number of code elements
registered, at a rate similar to 639-2. Peter, others, any idea
which theory might be better?

>IESG approved the matching draft on July 6, but it took 18 days to send the announcement.  Another 12 days have gone by and the matching draft still has not entered the RFC Editor queue.  What is the reason for the delay this time?  How long can we expect it to go on?

I have noted myself that it's not yet listed as "In State: RFC Ed Queue"
in the IETF tracker, although it's already in the RFC Editor Queue.
I'll find out who's fault that is.

>Whether it's written into the charter or not, the WG will need to consider the impact of unexpected, protracted delays on each of its activities, and will need to act accordingly to avoid degrading the value and credibility of its deliverables.

Agreed. I think this applies to any WG, but to this in particular.

Regards,    Martin.

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

---

From: John Cowan <[email-masked]>
Date: Sun, 6 Aug 2006 06:04:53 -0400

> which theory might be better?

According to http://www.ethnologue.com/ethno_docs/introduction.asp , the
15th (2005) edition of the Ethnologue, on which 639-3 is based, contains
7299 code elements, and has an increase of 103 code elements since the
14th (2000) edition.  That is a growth rate of 20 code elements per year,
or 0.27%.  Essentially all of those are splits -- what the 14th edition
called a single language, the 15th edition calls two or more languages
based on additional evidence.

And according to http://www.loc.gov/standards/iso639-2/codechanges.html ,
there have been 68 code elements added to 639-2 in the same period,
a growth rate of 2.9%.  So I'd say that it's unlikely that updates will
be proportional to the number of code elements.

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
You cannot enter here.  Go back to the abyss prepared for you!  Go back!
Fall into the nothingness that awaits you and your Master.  Go! --Gandalf

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Aug 2006 14:51:00 +0200

Martin Duerst wrote:

> One theory would be that 639-3 is already so comprehensive
> that updates will be very rare.

It comes without Suppress-Scripts.  If the review list is
unable to deal with this issue it has to be prepared by the
WG for 639-3 languages where that's possible (= "obvious").

That might be a point for the updated Charter.

> I have noted myself that it's not yet listed as "In State:
> RFC Ed Queue" in the IETF tracker, although it's already in
> the RFC Editor Queue. I'll find out who's fault that is.

http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ltru-matching
says it entered the queue at 2006-07-24 after one day in limbo.

In theory a third party like the W3C could ask the IESG to
accelerate the publication of BCP 47, because they want to fix
their references in say XHTML modularization 1.1.

I think it was our fault when we didn't see the implications of
an RFC editor note causing a "blocked waiting for 'matching'" -
the German word for this could be "Sollbruchstelle". 

The history tool shows this as "20060725 was in REF-EXT since 
20060119 (187 days)" or as "20060726 was in MISSREF*R since 
20060120 (187 days)".  Before that it took 43 days to create
the new IANA registry.

Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 6 Aug 2006 11:24:41 -0400

> WG for 639-3 languages where that's possible (= "obvious").

The argument for Suppress-Script was a backward compatibility
one: that new documents labeled en-Latn-US would not be
matched by old matchers against an en-US pattern.  That
does not apply to the new tags in 639-3, as none of them
have ever been valid before.

-- 
My corporate data's a mess!                     John Cowan
It's all semi-structured, no less.              http://www.ccil.org/~cowan
    But I'll be carefree                        [email-masked]
    Using XSLT
On an XML DBMS.

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 6 Aug 2006 08:50:28 -0700

> From: Martin Duerst [mailto:[email-masked]]

> which theory might be better?

I'd go with the proportionality theory: I expect there will be proportionally more cases in which usage is changing, for which perceptions are changing, or for which our knowledge is evolving.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 6 Aug 2006 08:54:34 -0700

> From: John Cowan [mailto:[email-masked]]

> be proportional to the number of code elements.

OK, I just wrote that I'd expect a proportional increase, but I forgot about one factor: there have been a lot of changes in 639-2 precisely because it was a limited list that has been missing things that people needed, and that is *far* less likely to be the case for 639-3.

I'd still expect some increase in the number of annual changes, but I guess not an order-of-magnitude increase -- i.e. not proportionally greater.

Peter Constable

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Aug 2006 19:37:21 +0200

John Cowan wrote:

> new documents labeled en-Latn-US would not be matched by old
> matchers against an en-US pattern.  That does not apply to
> the new tags in 639-3, as none of them have ever been valid
> before.

Old applications should have no problems with any new language
plus region or similar tags, but for extlangs and scripts they
might behave oddly.

In one case a new language subtag got a Suppress-Script, ngo
(2006-06-05) has Nkoo,  That's how I'd expect it to work for
new language tags (the seven added 2006 excl. zxx), and there
are several old language tags with missing Suppress-Scripts.

Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 6 Aug 2006 14:35:30 -0400

Frank Ellermann scripsit:

> (2006-06-05) has Nkoo.

Quite so, but it's not a requirement.

> That's how I'd expect it to work for

So there are.  ietf-languages should take that up.

-- 
John Cowan   http://ccil.org/~cowan    [email-masked]
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe