Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP)

From: "Addison Phillips" <[email-masked]>
Date: Wed, 24 Aug 2005 08:49:10 -0700

I don't necessarily agree that the changes in 3066ter, etc., would mark a change in functionality. The changes would be to the rules affecting registration of values in the registry. I believe that we have described the operation of the tags themselves completely in 3066bis.

ISO 639-6 codes are easily dealt with: there is a slot reserved for them in the ABNF that implementers ignore at their peril and the only change is the management of registrations.

ISO 639-3 is slightly more complicated. Most values are simply added to the existing language subtag collection (no change for implementations!!!). The big change is that extlang subtags can be registered. Rules for deciding what is an extlang and what is not may need to be worked through (although I expect that ISO 639-3 itself will provide the rationale there). But notice that Section 2.2.2 in draft-registry already says *exactly* what form these subtags will take and how to handle them!

In other words, I don't see how small rules tweaks on what is allowed into the registry (not the format of the registry or of subtags, please note) would affect implementations. We could follow the Std track along the lines of what Frank says, provided the scenario above is correct.

Of course, I do not object to going down the BCP path either. It makes no difference in practice.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> McDonald, Ira
> Sent: 2005?8?24? 8:15
> To: 'Harald Tveit Alvestrand'; Frank Ellermann; [email-masked]
> Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'
> to BCP)
> 
> Hi Harald,
> 
> Thanks for pointing out that one can't add functionality to an
> IETF 'standards track' document and simultaneously advance it on
> the 'standards track'.  The new version MUST stay at the same
> level as the previous version.  So all of those updates below
> in Frank's suggested list would have to be published as 'PS'
> (Proposed Std) and then later be advanced on the 'standards
> track'.
> 
> Which is (possibly) the rationale for RFC3066bis staying 'BCP'.
> Implementors are warned in the IETF standards process that a
> 'PS' may well change significantly before advancing to 'DS'.
> Perceived instability in language tag specifications isn't going
> to help their adoption.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Harald Tveit Alvestrand
> > Sent: Wednesday, August 24, 2005 2:26 AM
> > To: Frank Ellermann; [email-masked]
> > Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying
> > Languages' to BCP)
> >
> >
> >
> >
> > --On 24. august 2005 07:22 +0200 Frank Ellermann
> > <[email-masked]>
> > wrote:
> >
> > > JFTR, nothing new, I still prefer standards track:
> > >
> > > 3066bis   could obsolete 3066 (BCP 47) also as PS.
> > > 3066ter   oould integrate ISO 639-3 as DS (minor update)
> > > 3066tetra oould integrate ISO 639-6 as STD
> >
> > can't do that.... it's added functionality.....
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "John.Cowan" <[email-masked]>
Date: Wed, 24 Aug 2005 12:19:40 -0400

Addison Phillips scripsit:

> ISO 639-3 is slightly more complicated. Most values are simply
> added to the existing language subtag collection (no change for
> implementations!!!). The big change is that extlang subtags can be
> registered. Rules for deciding what is an extlang and what is not may
> need to be worked through (although I expect that ISO 639-3 itself
> will provide the rationale there). 

Indeed.  We'll probably want to issue another I-D to reload the registry
with all the thousands of new values.  Another reason for going dormant rather
than shutting up shop when RFC 3066bis and friends are finished.

> no difference in practice.

Quite so.

A process question: does a BCP go into effect when it is passed for
publication as an RFC, or when it is actually published as an RFC,
months or years later?

-- 
Dream projects long deferred            John Cowan <[email-masked]>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
        --James Lileks                  http://www.reutershealth.com

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 24 Aug 2005 09:50:22 -0700

> publication as an RFC, or when it is actually published as an RFC,

When it is passed (see tradition with BCP 101). Setting up the 
administrative details to actually act like the BCP says can take a little 
time, of course.

                Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Aug 2005 20:00:51 +0200

John.Cowan wrote:

> A process question: does a BCP go into effect when it is
> passed for publication as an RFC, or when it is actually
> published as an RFC, months or years later?

On average four months, not years.  For an RfC the "effect"
(as far as IANA is concerned) is apparently very fast, one
experimental RfC approved less than two months ago with two
IANA "effects" is ready for at least three weeks now, IIRC.

In other words, IMHO we can post registration requests for
missing Suppress-Scripts as soon as IANA is ready with the
initial registry.  Or in theory one minute after it was
approved, but waiting until we're sure that IANA got the
idea might be better.
                      Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Aug 2005 11:20:24 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, August 24, 2005 11:00 AM
> Subject: [Ltru] IANA effects (was: STD)
...
> IANA "effects" is ready for at least three weeks now, IIRC.
...

Before a document is even approved for hand-off to the RFC editor,
IANA will take a look at in in conjunction with the IESG review.  In my
experience, they go through the IANA considerations sections *very*
carefully, and are not shy about asking questions or requesting clarification.
Consequently, by the time the RFC appears, IANA has already known
for some time what would need to be done to implement a registry,
so it should not come as a surprise that they are able to activate them
quickly.

Randy