Subject: [Ltru] Section 3.4-16 on ISO 3166 vs UN M49 RE: Ltru Digest, Vol 50, Issue 42

From: Lang Gérard <[email-masked]>
Date: Mon, 4 May 2009 09:58:54 +0200

Dear All,

" registration authority for ISO 3166" does not exist" !
In fact, we are "ISO 3166 Maintenance Agency", also known as "ISO 3166/MA".
Bien cordialement.
Gérard LANG

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 1 mai 2009 06:04
À : [email-masked]
Objet : Ltru Digest, Vol 50, Issue 42

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/ltru

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Send Ltru mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."

Today's Topics:

   1. Re: Ticket #45: AD Issue #12: reason for SHOULD in	4.5extlang
      mapping (Randy Presuhn)
   2. Issue summary (Randy Presuhn)
   3. Re: Ticket #40: AD Issue #7: section 3.4 on ISO 3166
      vs.UNM.49 (Randy Presuhn)
   4. Re: Issue summary (Phillips, Addison)
   5. Re: Ticket #40: AD Issue #7: section 3.4 on ISO	3166
      vs.UNM.49 (Phillips, Addison)
   6. Re: Ticket #43: AD Issue #10: File-Date value (Randy Presuhn)
   7. Re: Ticket #43: AD Issue #10: File-Date value (Phillips, Addison)
   8. Re: It MUST and SHALL be preserved (Randy Presuhn)

----------------------------------------------------------------------

Message: 1
Date: Thu, 30 Apr 2009 14:31:12 -0700
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Ltru] Ticket #45: AD Issue #12: reason for SHOULD in
	4.5extlang mapping
To: "LTRU Working Group" <[email-masked]>
Message-ID: <01e301c9c9da$fcba6fa0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As co-chair...

I'm concerned about the amount of textual change proposed in resultion of this item.  Without prejudicing the merits of these changes, we should recall that the AD's comment merely asked for an explanation of the "SHOULD".  I'm reluctant to declare consensus on a change this extensive without hearing from more working group participants, particularly since this was such a hotly contested portion of the specification.

Randy

------------------------------

Message: 2
Date: Thu, 30 Apr 2009 14:40:45 -0700
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue summary
To: "LTRU Working Group" <[email-masked]>
Message-ID: <01f301c9c9dc$52371720$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As co-chair...

The list of open ltru issues is available at
http://trac.tools.ietf.org/wg/ltru/trac/report/1

In brief:
#31  change titles of ISO docs
#36  AD #3 - rules for UN M.49 codes
#40  AD #7 - section 3.4 on ISO 3166 vs UN M.49
#41  AD #8 - section 3.5 SHOULD vs MUST
#43  AD #10 - section 5.1 vs 3.2 on File-Date value
#45  AD #12 - reason for SHOULD in 4.5 (3) on extlang preferred value mappings

31 is open because I haven't seen confirmation that the edits are understood
36 is open waiting in case others would like to comment before closure 40 has multiple proposals for text change
41 is open waiting in case there are proposals for additional clarification
43 has a proposal, but I'd like to hear from folks whether they think this
   constitutes a technical change, and whether it sufficiently addresses the
   AD comments
45 has an extensive proposal, but I'd like to hear from others in the WG
   since this touches on what were contentious issues

PLEASE respond to any of these on their respective threads!

Randy

------------------------------

Message: 3
Date: Thu, 30 Apr 2009 14:44:24 -0700
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166
	vs.UNM.49
To: "LTRU Working Group" <[email-masked]>
Message-ID: <020001c9c9dc$d4b6aee0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working 
> Group" <[email-masked]>
> Sent: Thursday, April 30, 2009 2:20 PM
> Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 
> vs.UNM.49
...
> Here are the proposed texts:
...

I prefer "B".

Randy

------------------------------

Message: 4
Date: Thu, 30 Apr 2009 14:41:46 -0700
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] Issue summary
To: Randy Presuhn <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

(as editor)

> 31 is open because I haven't seen confirmation that the edits are 
> understood

I have requested that Doug send me his XML sources so that ours are identical. Since I used his private email address, I expect I may hear from him this evening or overnight.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

------------------------------

Message: 5
Date: Thu, 30 Apr 2009 14:42:19 -0700
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO	3166
	vs.UNM.49
To: Randy Presuhn <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

(as contributor)

I have no objection to B.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Randy Presuhn
> Sent: Thursday, April 30, 2009 2:44 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO
> 3166 vs.UNM.49
> 
> Hi -
> 
> As a technical contributor...
> 
> > From: "Phillips, Addison" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>; "LTRU Working
> Group" <[email-masked]>
> > Sent: Thursday, April 30, 2009 2:20 PM
> > Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO
> 3166 vs.UNM.49
> ...
> > Here are the proposed texts:
> ...
> 
> I prefer "B".
> 
> Randy
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 6
Date: Thu, 30 Apr 2009 14:57:25 -0700
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Ltru] Ticket #43: AD Issue #10: File-Date value
To: "LTRU Working Group" <[email-masked]>
Message-ID: <020b01c9c9de$a63fede0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, April 29, 2009 3:29 PM
> Subject: [Ltru] Ticket #43: AD Issue #10: File-Date value
...
> Proposed resolution:
...
> <t>The first record in the registry is always the "File-Date" record.
> This record occurs only once in the file and contains a single field 
> whose field-name is "File-Date". The field-body of this record 
> contains the approval date of the most recent change to the registry, 
> making it possible to compare different versions of the registry.
>  The registry on the IANA website is
> the most current.   Versions with an older date than that one
> are not up-to-date.</t>
...

I think the real problem here is that this text (for section 3.1.2) is an imperfect re-cap of the detailed description in section 5.1.
Rathering than repeating or summarizing (with the risk of getting it wrong), might it be better to make a forward reference? 
Proposed text:

<t>The first record in the registry is always the "File-Date" record.
This record occurs only once in the file and contains a single field whose field-name is "File-Date". The field-body of this record contains a date (see 5.1) making it possible to easily recognize different versions of the registry.

I think this more directly addresses the AD comment.

Randy

------------------------------

Message: 7
Date: Thu, 30 Apr 2009 15:02:38 -0700
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] Ticket #43: AD Issue #10: File-Date value
To: Randy Presuhn <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

(as contributor)

I agree with this proposed change.

(as editor)

I have inserted this version of the text.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Randy Presuhn
> Sent: Thursday, April 30, 2009 2:57 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #43: AD Issue #10: File-Date value
> 
> Hi -
> 
> As a technical contributor...
> 
> > From: "Phillips, Addison" <[email-masked]>
> > To: "LTRU Working Group" <[email-masked]>
> > Sent: Wednesday, April 29, 2009 3:29 PM
> > Subject: [Ltru] Ticket #43: AD Issue #10: File-Date value
> ...
> > Proposed resolution:
> ...
> > <t>The first record in the registry is always the "File-Date"
> record.
> > This record occurs only once in the file and contains a single
> field
> > whose field-name is "File-Date". The field-body of this record 
> > contains the approval date of the most recent change to the
> registry,
> > making it possible to compare different versions of the registry.
> >  The registry on the IANA website is
> > the most current.   Versions with an older date than that one
> > are not up-to-date.</t>
> ...
> 
> I think the real problem here is that this text (for section 3.1.2) is 
> an imperfect re-cap of the detailed description in section 5.1.
> Rathering than repeating or summarizing (with the risk of getting it 
> wrong), might it be better to make a forward reference?
> Proposed text:
> 
> <t>The first record in the registry is always the "File-Date"
> record.
> This record occurs only once in the file and contains a single field 
> whose field-name is "File-Date". The field-body of this record 
> contains a date (see 5.1) making it possible to easily recognize 
> different versions of the registry.
> 
> I think this more directly addresses the AD comment.
> 
> Randy
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 8
Date: Thu, 30 Apr 2009 21:07:53 -0700
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Ltru] It MUST and SHALL be preserved
To: <[email-masked]>
Message-ID: <003d01c9ca12$67a294a0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

> From: "John Cowan" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, April 30, 2009 2:11 PM
> Subject: [Ltru] It MUST and SHALL be preserved
>
> Just to keep things simple, let's change all SHALLs to MUSTs.

As co chair: Let's not.  The two have exactly the same effect from and RFC 2119 point of view.  At this stage, we need to limit ourselves to addressing the AD review comments, stuff we agreed earlier to address (references), and show-stopper bugs that happen to pop up.

Randy (who is known to be somewhat humor-impaired, in case this was meant in jest.)

------------------------------

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

End of Ltru Digest, Vol 50, Issue 42
************************************

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 May 2009 12:32:04 -0700

Hi -

As co-chair:

PLEASE include the issue number in your subject line, if this is
intended to be a comment on proposed text for resolving an
existing issue.

If this is supposed to be a new issue, I will declare it "too late" unless it
can be demonstrated to cause interoperability problems.

Randy

----- Original Message ----- 
From: "Lang Gérard" <[email-masked]>
To: <[email-masked]>
Cc: "Lang Gérard" <[email-masked]>
Sent: Monday, May 04, 2009 12:58 AM
Subject: [Ltru] Section 3.4-16 on ISO 3166 vs UN M49 RE: Ltru Digest, Vol 50,Issue 42

Dear All,

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 1 mai 2009 06:04
À : [email-masked]
Objet : Ltru Digest, Vol 50, Issue 42

If you have received this digest without all the individual message attachments you will need to update your digest options in your
list subscription.  To do so, go to

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Today's Topics:

Message: 1

Hi -

As co-chair...

I'm concerned about the amount of textual change proposed in resultion of this item.  Without prejudicing the merits of these
changes, we should recall that the AD's comment merely asked for an explanation of the "SHOULD".  I'm reluctant to declare consensus
on a change this extensive without hearing from more working group participants, particularly since this was such a hotly contested
portion of the specification.

Randy

Message: 2

Hi -

As co-chair...

In brief:

Randy

Message: 3

Hi -

...
...

I prefer "B".

Randy

Message: 4

(as editor)

> 31 is open because I haven't seen confirmation that the edits are

I have requested that Doug send me his XML sources so that ours are identical. Since I used his private email address, I expect I
may hear from him this evening or overnight.

Addison

Addison Phillips

Message: 5

(as contributor)

Addison

Addison Phillips

Message: 6

Hi -

...
...
...

I think the real problem here is that this text (for section 3.1.2) is an imperfect re-cap of the detailed description in section
5.1.
Rathering than repeating or summarizing (with the risk of getting it wrong), might it be better to make a forward reference?
Proposed text:

<t>The first record in the registry is always the "File-Date" record.
This record occurs only once in the file and contains a single field whose field-name is "File-Date". The field-body of this record
contains a date (see 5.1) making it possible to easily recognize different versions of the registry.

Randy

Message: 7

(as contributor)

(as editor)

Addison Phillips

Message: 8

Hi -

> Just to keep things simple, let's change all SHALLs to MUSTs.

As co chair: Let's not.  The two have exactly the same effect from and RFC 2119 point of view.  At this stage, we need to limit
ourselves to addressing the AD review comments, stuff we agreed earlier to address (references), and show-stopper bugs that happen
to pop up.

---

From: John Cowan <[email-masked]>
Date: Mon, 4 May 2009 15:48:01 -0400

Randy Presuhn scripsit:

> If this is supposed to be a new issue, I will declare it "too late"
> unless it can be demonstrated to cause interoperability problems.

The sentence in question is the 3rd sentence of bullet point 16 of
Section 3.4.  It says that registrants SHOULD do something which
technically is impossible, because the registration authority they
are asked to petition does not exist.  The error is easily patched by
s/registration authority/maintenance agency/ in 3.4-16, and leaving it
in would be an embarrassment.  Please reconsider.

-- 
What asininity could I have uttered     John Cowan <[email-masked]>
that they applaud me thus?              http://www.ccil.org/~cowan
        --Phocion, Greek orator

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 18 May 2009 18:46:00 +0900

[co-chair and shepherd hat on]

Okay, as Randy has reopened issue 40, and I have found the relevant mail 
with the change proposal, I herewith declare that there is consensus for 
the fix below (I haven't seen anybody opposing to this factual fix), and 
instruct the editors to edit their text accordingly.

Regards,    Martin.

P.S.: Randy, can I ask you to update 
http://trac.tools.ietf.org/wg/ltru/trac/ticket/40? You seem to be 
particularly at ease with that tool, whereas I have repeatedly not been 
able to get my head around it. To my defense, I can prove that I have 
successfully submitted and updated bugs in Bugzilla and Redmine, but the 
tool used at the IETF, or the way it's used at the IETF (or maybe it's 
just me), somehow always escapes my grip (at the moment, all IETF sites 
are very slow (excusable, it's still Sunday for them), and it's 
impossible for me to log into the tracking system.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 May 2009 10:18:23 -0700

Hi -

> From: "Martin J. Dürst" <[email-masked]>
> To: "John Cowan" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, May 18, 2009 2:46 AM
> Subject: Issue 40: Re: [Ltru] Section 3.4-16 on ISO 3166 vs UN M49 RE: Ltru Digest, Vol 50, Issue 42
...
> http://trac.tools.ietf.org/wg/ltru/trac/ticket/40?
...

Ok, I've updated the resolution and closed the report
with what I *think* is the result of this piecemeal discussion:

16. UN M.49 has codes for both countries and areas (such as '276'
for Germany) and geographical regions and sub-regions (such as
'150' for Europe). UN M.49 country or area codes for which
there is no corresponding ISO 3166-1 code SHOULD NOT be
registered, except as a surrogate for an ISO 3166-1 code that is
blocked from registration by an existing subtag.

If such a code
becomes necessary, then the
Language Subtag Reviewer SHALL petition the ISO 3166 Maintenance Agency (ISO 3166/MA) to assign a code to the
region. If the petition for a code assignment by ISO 3166-1 is
refused or not acted on in a timely manner, the
Language Subtag Reviewer SHALL use the
registration
process described in Section 3.5
<http://tools.ietf.org/html/draft-ietf-ltru-4646bis-21#section-3.5>
to register
the corresponding UN M.49 code. This way, UN M.49 codes remain
available as the value of last resort in cases where ISO 3166-1
reassigns a deprecated value in the registry.

Randy