Subject: [Ltru] Re: 639-3 updates

From: "Doug Ewell" <[email-masked]>
Date: Sat, 12 May 2007 21:40:46 -0700

John Cowan <cowan at ccil dot org> wrote:

> 639-3/RA (i.e. SIL) has said that it will announce in July the outcome
> of 129 change requests (the list closed as of March), some of which
> affect us:  for example, 2006-044 merges Yinglish into English,
> retiring 'yib'; 2006-001 splits Belgian Sign language into French
> Belgian Sign and Dutch Belgian Sign, retiring 'bvs'; and 2006-129
> converts Catalan into a macrolanguage, encompassing "Catalan
> (individual language)" and "Valencian".

I wish I'd known about that last one before we registered 'valencia'.

> IMHO it would be way better if we waited to find out which of these
> changes go through and which don't, so that we don't end up adding
> records to the LSR only to deprecate them immediately thereafter.
> Remember that if 639-3/RA makes a change, we *must* follow them; there
> is no choice in the matter by the terms of 4646bis.

Absolutely correct.  "Deprecated in infancy" is almost as bad as
"deprecated at birth."

OK, expect to see draft-ietf-ltru-4645bis-02 sometime in July, I guess.

--
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: John Cowan <[email-masked]>
Date: Sun, 13 May 2007 03:03:16 -0400

Doug Ewell scripsit:

> >and 2006-129

Don't assume that any particular change will actually go through.

-- 
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!
        --Duck Soup                     John Cowan <[email-masked]>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 13 May 2007 14:05:23 +0200

> Don't assume that any particular change will actually go through.

Rejecting variant registration requests because there _might_ be new
RFCs in 2008 deprecating them would be anyway an appealable offense.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 13 May 2007 16:01:09 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, May 13, 2007 5:05 AM
> Subject: [Ltru] Re: 639-3 updates
>
> John Cowan wrote:
> 
...

Is this a request to change or clarify sections 3.2, 3.5, or 3.7, of the
registry draft, (the parts that currently mention appeals) currently
found at http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-06.txt?
If so, specific text for discussion here would be helpful.

If this is a threat to appeal the handling of a specific registration
request by the language subtag reviewer, it does not belong on
the [email-masked] mailing list.

Randy
ltru co-chair

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 May 2007 18:03:00 +0200

Randy Presuhn wrote:

> Is this a request to change or clarify sections 3.2, 3.5, or 3.7, of
> the registry draft, (the parts that currently mention appeals)

[3.5]
| When the two-week period has passed, the Language Subtag Reviewer
| MUST take one of the following actions:
|
| o  Explicitly accept the request and forward the form containing the
|    record to be inserted or modified to [email-masked] according to
|    the procedure described in Section 3.3.
| o  Explicitly reject the request because of significant objections
|    raised on the list or due to problems with constraints in this
|    document (which MUST be explicitly cited).
| o  Extend the review period by granting an additional two-week
|    increment to permit further discussion.  After each two-week
|    increment, the Language Subtag Reviewer MUST indicate on the list
|    whether the registration has been accepted, rejected, or extended.
|
| Note that the Language Subtag Reviewer MAY raise objections on the
| list if he or she so desires.  The important thing is that the
| objection MUST be made publicly.
[...]
| Decisions made by the Language Subtag Reviewer MAY be appealed to the
| IESG [RFC2028] under the same rules as other IETF decisions [RFC2026].
| This includes a decision to extend the review period or the failure
| to announce a decision in a clear and timely manner.

Section 3.5 is very clear, and it's in essence the same as in RFC 4646.

> the [email-masked] mailing list.

The "valencia" variant subtag was registered 2007-03-06.  Its rejection
with reason "might be deprecated by an unpublished RFC 4645bis based on
an unpublished version of 639-3 in the future" was a hypothetical case:
<http://permalink.gmane.org/gmane.ietf.ltru/7843>

RFC 4646 had a rule (3.8) that all pending requests are finished under
the old (3066) rules, 4646bis has the same rule (as MUST) for pending
4646 requests.  The requesters can decide that they're willing to wait
for some potential future event.  If they're not willing to wait, and
their requested variant is rejected only because it might be deprecated
by a possible future language subtag, they can appeal that decision as
speculation in violence of 3.8.

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 May 2007 11:44:20 -0700

Frank -

As is abundantly clear from the texts you cite, [email-masked]
is NOT the place for such an appeal.  So unless you're
requesting a change to the procedure, this discussion
does NOT belong on the ltru WG mailing list.  Furthermore,
if what you desire is a dialog with the language subtag
reviewer, the correct mailing list is [email-masked],
NOT the ltru WG mailing list.

Randy
ltru co-chair

> Sent: Monday, May 14, 2007 9:03 AM

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 May 2007 21:23:00 +0200

Randy Presuhn wrote:

> is NOT the place for such an appeal.

Od course not.  But the topic of rejecting a requested variant
only because it might be deprecated later was brought up, and
I've stated that that can be appealed.  If you don't disagree
with that statement I don't know what you're getting at.
 
> reviewer, the correct mailing list is [email-masked],

The tag in question was NOT rejected, there was no problem with
"valencia".  The _hypothetical_ case here was started by John's 
remark that "valencia" might become a regular language subtag,
with a conclusion:
 
| IMHO it would be way better if we waited to find out which of
| these changes go through and which don't, so that we don't end
| up adding records to the LSR only to deprecate them immediately
| thereafter.

Doug's reply:

| I wish I'd known about that last one before we registered 'valencia'.
[...]
| "Deprecated in infancy" is almost as bad as "deprecated at birth."

John's qualifier:

| Don't assume that any particular change will actually go through.

And after that I added my statement that rejecting requests only
because they might be later deprecated can result in an appeal.

Nobody's forced to wait for potential future events with their
registration requests for variants like "valencia".  Exceptions
are attempts to register a language subtag - then they have to
present the evidence that the ISO 639 RA rejected it - or attempts
to register UN numbers for countries not listed by ISO 3066, and
for these exceptions than can take some time.  In all other cases
the timeout for decisions is two weeks.  Not July, continuing the
hypothetical example of a pending "valencia" request today.

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 May 2007 12:30:23 -0700

Hi -

Forgive me for being dense.  On this list we're supposed to be working
on an update to BCP 47.  Exactly what change is being proposed?

Randy

> Sent: Monday, May 14, 2007 12:23 PM

---

From: John Cowan <[email-masked]>
Date: Mon, 14 May 2007 15:35:17 -0400

> on an update to BCP 47.  Exactly what change is being proposed?

This is about the timing of the next draft of 4645bis;
stripped of the side issues, Doug's going to wait until July
so that any ISO 639-3 changes made then will be reflected.

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

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 May 2007 22:01:12 +0200

Randy Presuhn wrote:

> Exactly what change is being proposed?

My proposal is to change *_nothing_*.  If folks wish to register a
variant that might be obsoleted in July or whenever, then trying
to persuade them to wait with their request, because a new subtag
"deprecated in infancy" most likely isn't what they want, is fine.

And if they don't wish to wait for this potential event, maybe for
a good reason like expecting that this will never happen, or for a
bad reason like wanting their very own last minute subtag, then
the RFC 4646 or later 4646bis rules should be followed as they are,
with a decision after "two weeks" (where I don't care if it's some
days more depending on the discussion or similar delays).

But a clear decision is REQUIRED, otherwise nobody including the
proponents and the reviewers know when the more or less two weeks
ended, and what the final outcome was, let alone the reasons for a
rejection if that's the unknown outcome.

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 May 2007 13:13:09 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, May 14, 2007 12:35 PM
> Subject: Re: [Ltru] Re: 639-3 updates
>
> Randy Presuhn scripsit:
> 
...

Ah.  Now it all makes sense.  Thank you for your patience.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 May 2007 22:29:09 +0200

John Cowan wrote:

> Doug's going to wait until July so that any ISO 639-3 changes
> made then will be reflected.

That's fine, and if all goes well the RFC with an updated registry
might be available at the end of this year or in early 2008.

For the hypothetical "valencia" case (in March) rejecting this
request because there might be something better nine months later
would be wrong.  The proponents can have reasons why they want a
variant "now" (in March) without waiting for a possible language 
nine months later.

Because the real (non-hypothetical) variant exists 4645bis might
have to deprecate it in favour of the future language subtag, and
that's no big problem.  There are already some grandfathered tags
deprecated by future language subtags in 4645bis-00.  One more is
only a problem if we forget about it.  Unlikely after this thread.

Frank