Subject: RE: [Ltru] Re: status? last call?

From: "Addison Phillips" <[email-masked]>
Date: Tue, 28 Jun 2005 17:27:35 -0700

See below.

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 Frank Ellermann
> Sent: Dienstag, 28. Juni 2005 16:36
> To: [email-masked]
> Subject: [Ltru] Re: status? last call?
> 
> Addison Phillips wrote:
> 
> > I'll make a special exception for listed codes that are valid
> > for registration in Section 2.2.4 clause 3.E
> 
> Sorry, I'm completely confused.  IIRC we agreed that 830..833
> and similar future cases of "UN region number without alpha-2"
> are _not_ registered, never, no exception.
[Addison Phillips] 

Exactly so. 830..833 are not registrable?by rule. The MAY rule in draft-initial however can be implemented using this text:

--
UN numeric codes and ISO 3166 alpha-2 codes for countries or areas listed as eligible for registration in [initial-registry] (Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.) but not presently registered MAY be entered into the IANA registry via the process described in Section 3.4 (Registration Procedure for Subtags). Once registered, these codes MAY be used to form language tags.
--
> 
> Maybe I got it wrong, but I didn't ask for exceptional rules,
> if that's what you thought.  If Doug removes your old MAY in
> his -01 it's fine, that's compatible with your -07 2.2.4 (3.E)
[Addison Phillips] 

The new text allows items listed as registrable to be registered, provided they meet other rules.
> 
> >> no "conflict", maybe extract the 6th "no alpha-2" item from
> >> "bullet 10" and add it after bullet 10 before the last
> >> bullet.
> 
> > Agreed.
> 
> No serious problem of course, moving one sublist item to the
> parent list shouldn't delay Randy / Martin / Scott with their
> "last call" business.
> 
> >> Is there really no way to initialize the counter for a
> >> <list style="numbers"> or for a <list style="letters"> ?
> [...]
> 
> > Sure there is. I just didn't make the change previously.
> 
> Oops, how does it work ?  My experiments with a list nested
> within a <list style="format Changes in version 0%d"> failed
> miserably, and a negative hangIndent= value had no effect.
[Addison Phillips] 

Isn't that what "counter" is for? But I misread that as your desire that we used numbers or letters and not bullets (where we all go bonkers counting stars and stuff). A list of rules should really be numbered.
> 
> > I'll change it to letters or numbers once I've looked at
> > which is more appropriate.
> 
> For 2.2.4 (3E) you have letters within numbers.  Bye, Frank
> 
I matched that.

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 04:29:28 +0200

Addison Phillips wrote:

> UN numeric codes and ISO 3166 alpha-2 codes for countries or
> areas listed as eligible for registration in
> [initial-registry] (Ewell, D., Ed., "Initial Language Subtag
> Registry," June 2005.)

We better wait to see what that will be, an "initial registry"
with a separate section of obscure unregistered subtags is odd.

> but not presently registered MAY be entered into the IANA
> registry via the process described in Section 3.4

So 830..833 can be registered "manually" if they somehow make
it to the obscure unregistered subtags section in the initial
registry ?  

And what unregistered ISO 3166 alpha-2 codes are "eligible for
registration" ?  IMHO there should be no section about obscure
unregistered subtags in the initial registry, it's not some
kind of "unregistry".

> Once registered, these codes MAY be used to form language
> tags.

Don't write this in the draft.  Of course registered subtags
"MAY" be used to form tags, that's the point of the registry.

> The new text allows items listed as registrable to be
> registered, provided they meet other rules.

I'm not yet convinced.  IIRC we said that 830..833 must not be
registered because that would block a future GG, IM, and JE as
stated in 3.3 (8):

| Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do
| not conflict with existing subtags of the associated type and
| whose meaning is not the same as an existing subtag of the
| same type are entered into the IANA registry as new records.

IM would have the same type "region" as 832.  There's no other
region IM in the registry, so there's no conflict.  But IM has
the same meaning as 832 => TILT.

You could fix it by removing "and whose meaning is the same as
an existing subtag of the same type".  If one of the 3 source
standards intentionally creates an alias without simultaneously
deprecating the old code it's no real problem, let them do it.

Just get rid of "and whose meaning is the same as an existing
subtag of the same type", it only creates confusion.  What if
the former CS, YU, or SU are recreated with a new name and a
new alpha-2 code ?  Weird example, but IM + 832 could be real.

What's the effect of your proposed change for 888 Somaliland,
if ISO 3166 refuses to create an alpa-2 code ?  Apparently no
effect at all, 888 cannot be registered,  If that's the case,
why an exception for 830..833 ?  Either 888 can be registered
like 830..833, or they all cannot be registered,  

For some days I thought that we agreed on the latter.  Now you
apparently try to dig a loophole for 830..833 but not 888 (?)

 [xml2rfc]
> Isn't that what "counter" is for?

Maybe.  I read the 'list' section (= #rfc.section.2.3.1.2) in
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
and thought that it's _only_ about style="format whatever %d".

> A list of rules should really be numbered.

Yes please, it's much easier to say 2.2.4 (3E), bye, Frank