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

From: "Doug Ewell" <[email-masked]>
Date: Thu, 7 Jul 2005 23:01:51 -0700

On Wed, 29 Jun 2005 04:29:28 +0200, Frank Ellermann <nobody at xyzzy dot
claranet dot de> wrote:

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

Actually, I think it's a good idea to list the UN codes that were
excluded from the registry and explain why.  This has certainly been one
of the more contentious aspects of the development of 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".

No ISO 3166 codes fall into this category, only UN numeric codes.

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

Section 3.3 (11) of the registry draft now covers this.  We may NOT
register 830 through 833.  Rather, someone is supposed to petition ISO
3166/MA to add the corresponding alpha-2 codes.  (Joseph Martinez, Chief
Information Officer for the MA, told me such a request would have to
come from BSI.)

In other words, the wording in the initial-registry draft is WRONG.
Section 2, item 6 currently reads:

"Items withdrawn, vacated, deprecated, modified, or otherwise judged by
the LTRU working group to be questionable were not added to the ILSR.
These code elements are listed in Section 4 (Omitted Code Elements),
indicating that they are valid for registration using the process in
[I-D.ietf-ltru-registry] but were not included initially. Listing of
these code elements in this section is not a guarantee of future
registration."

This needs to be changed to read:

"Items withdrawn, vacated, deprecated, modified, or otherwise judged by
the LTRU working group to be questionable were not added to the ILSR.
These code elements are listed in Section 4 (Omitted Code Elements),
indicating that they are not valid for registration, except as provided
in Section 3.3 (item 10E) of [I-D.ietf-ltru-registry]."

There's no longer any need for the third sentence; in fact, it's almost
a guarantee that they will *never* be registered.

Likewise, the introductory text in Section 4 currently reads:

"The following code elements from [UN-M.49] were not assigned as subtags
in the initial Language Subtag Registry, but are valid candidates for
registration as region subtags, using the process in
[I-D.ietf-ltru-registry]:"

and should be changed to:

"The following code elements from [UN-M.49] were not assigned as subtags
in the initial Language Subtag Registry, and may not be registered
except as provided in Section 3.3 (item 10E) of
[I-D.ietf-ltru-registry]:"

Thanks to Frank for his diligence in following up on this issue.

I will add these changes to a draft-initial-02, as well as the "leading
whitespace" text mentioned in my other post.  Does anyone have any other
comments besides this?  If not, I think draft-initial-02 will be just
about ready for Last Call.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 7 Jul 2005 23:31:32 -0700

Hi -

With Doug's comments below, can we wrap up issue #1026?

Randy, ltru co-chair

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 07, 2005 11:01 PM
> Subject: [Ltru] Re: status? last call?
>

---

From: "Dylan N. Pierce" <[email-masked]>
Date: Fri, 08 Jul 2005 01:42:30 -0500

> Does anyone have any other

Just a question, for my own peace of mind; no matter what the answer is, 
I have no intention of objecting to the document.

I note in the descriptions of several tags the use of Unicode code 
points. (Example: Proven&#xE7;al). I note that Unicode isn't referenced 
in the document, although draft-10 does reference STD 63.

It is obvious to me that those escapes are meant to represent Unicode 
characters. I just want to make sure that what is obvious to me really 
is obvious. Forgive me if I'm flaunting my ignorance.

Dylan

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 7 Jul 2005 23:56:13 -0700

Dylan N. Pierce <dylanpierce at megared dot net dot mx> wrote:

> points. (Example: Proven&#xE7;al). I note that Unicode isn't
> referenced in the document, although draft-10 does reference STD 63.
>

The initial-registry draft refers the reader to the registry-structure
draft for all details concerning the format and encoding conventions of
the registry.  The registry-structure draft, in turn, does contain an
informative reference to Unicode 4.1.0.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 10:45:31 +0200

Doug Ewell wrote:

> I think it's a good idea to list the UN codes that were
> excluded from the registry and explain why.

For _valid_ UN numbers at date-B I got the idea, and that
covers 831..833 for File-Date: 2005-07-05, even 830, tough.

But not 200. the only "200" on their page belongs to 2005.
200 is AFAIK also no "valid candidate for registration".
And it never was, so even a time machine wouldn't help.

IANA:  Are we sure that they manage it to extract the real
registry from your I-D ?  Scott said "assume the worst" or
similar.

Maybe a short note "remove page headers and three leading
spaces in all lines of chapter 3, the first line should
be the File-Date line" helps in the IANA considerations.

Otherwise I get:
| 958 (sub)tags in 5014 lines, 279 xrefs okay

Some comments like "replaced by ISO code lb" aren't strictly
necessary, the Prefered-Value: lb is clear.  But no problem.

 [eligible 3166 codes]
> No ISO 3166 codes fall into this category, only UN numeric

That's still wrong in draft -08 (2.2.4 3E).

 [830..833]
> Section 3.3 (11) of the registry draft now covers this.

Really, it lists all four #1026 codes, why do they want that
you have a complete chapter about excatly the same four codes ?
IANA is most probably not interested what we do NOT register.

>| The following code elements from [UN-M.49] were not assigned
>| as subtags in the initial Language Subtag Registry, and may
>| not be registered except as provided in Section 3.3 (item
>| 10E) of [I-D.ietf-ltru-registry]:"

Okay (but get rid of 200).

> I think draft-initial-02 will be just about ready for Last
> Call.

ACK, but draft -08 2.2.4 3E might be still wrong, bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Fri, 08 Jul 2005 13:08:33 +0200

>informative reference to Unicode 4.1.0.

This cannot be as this is not an ISO 639-4 accepted reference. Nothing 
protects the IETF which is not an ISO nor a Unicode expert, from conflict. 
As the Chair put it, ISO is ISO and IETF is IETF.
jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 07:33:36 -0700

r&d afrac <rd at afrac dot org> wrote:

>> The initial-registry draft refers the reader to the registry-
>> structure draft for all details concerning the format and encoding
>> conventions of the registry.  The registry-structure draft, in turn,
>> does contain an informative reference to Unicode 4.1.0.
>
> protects the IETF which is not an ISO nor a Unicode expert, from
> conflict. As the Chair put it, ISO is ISO and IETF is IETF.

I have no idea what this means.  Are you saying that the
initial-registry draft needs to include an explicit reference to the
Unicode Standard, instead of indirectly referencing it through the
registry-structure draft?  I don't see what ISO 639-4 has to do with any
of this.

---

From: r&d afrac <[email-masked]>
Date: Fri, 08 Jul 2005 19:54:54 +0200

At 16:33 08/07/2005, Doug Ewell wrote:
>registry-structure draft?

No. I say directly or indirectly you cannot reference an third party. 
Unicode is a consortium of private interets, the same as W3C, etc. This WG 
is to deal with ISO 639, 3166 and 15924, plus UN M.49 (in a way I partly 
disagree with because the format is confusing). Outside of that no other 
code has been accepted: because no other maintainer has committed to stay 
compatible with these codes and her commitment accepted by the IETF.

>I don't see what ISO 639-4 has to do with any of this.

ISO 639-4 is the ISO document which commits on the consistency of ISO 639 
series, 15924 and 3166 series. ISO 639-4 is to describe the possible 
relations between these codes. The matter is debated and not made. It would 
be odd if IETF standardised relations between codes the authors of that 
codes would identify as wrong. This is why we must do the things in 
sequence. Our charter is to deal with ISO 639. The author of ISO 639-3 
being at the origin of all this effort, I undersnand that he insisted on 
ISO 639-3. I find other ISO 639-3 based formats more interesting 
networkwise, but all this is a question of technical experimentation and 
testing by users. I always marvel at people who invent best common practices.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 12:52:55 -0700

Hi -

Issue #891 (support for non-ASCII representations of language names),
issue #934 (repertoire for descriptions in registry entries)
issue #987 (format of character references)
were resolved long ago.

No technical argument to re-open any of these has been presented in
this thread.  The resolution of these requires reference to the NCR
notation.  Complaints that such a technically necessary reference would
be inappropriate seem disingenuous at best.

Let's waste no more time or electrons on this.

Randy, ltru co-chair

----- Original Message ----- 
> From: "r&d afrac" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Friday, July 08, 2005 10:54 AM
> Subject: Re: [Ltru] Re: status? last call?
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 14:00:11 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 08, 2005 1:45 AM

> And it never was, so even a time machine wouldn't help.
...

PLEASE keep the issue number in your postings.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 14:04:25 -0700

Hi -

...
...

As a technical contributor, I think this is overengineering.
>From experience with other RFCs that establish registries, I know that
IANA works closely with document editors and WG chairs in setting
things up.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 14:17:49 -0700

Hi -

...
...

The text that is there in the -08 registry draft says:

       E.  UN numeric codes and ISO 3166 alpha-2 codes for countries or
           areas listed as eligible for registration in [initial-
           registry] but not presently registered MAY be entered into
           the IANA registry via the process described in Section 3.4.
           Once registered, these codes MAY be used to form language
           tags.

As a technical contributor, I think this is the right thing to do, but it sounds like
Frank and I are having trouble reconciling it with, for example, Doug's
understanding:
"In regard to the general matter of registering UN numeric code elements
for countries and country-like entities (as opposed to macro regions), I
believe they should NOT be eligible for individual registration, so that
they may remain available as the "last resort" option in case of ISO
3166 code conflicts."

As a thought experiment, work through the "es-419" case using both
approaches.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 14:22:55 -0700

Hi -

----- Original Message ----- 
> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 08, 2005 2:00 PM
> Subject: [Ltru] issue #200 is resolved (was: Re: status? last call?)
...

Ooops.
Instead of issue #200, I meant issue #900, whose topic is code 200.
The editors should ensure that their documents indeed reflect the
resolution of that issue.

Randy