Dear All,

0-In fact the alpha-2 code element "SF" never was an official entry of ISO 3166, and appears in the decoding table as a reserved code element only for historic reasons.
So that if the case of "SF" inside ISO 3166(-1) is rather singular, the decodong table is nevertheless quite correct..

1-SF (for "Suomli/Finland") was  the initial distinguishing sign declared by Finland as a contracting party of the 1949 convention on road traffic, and seems to have been replaced by FIN within the 1968 convention on road traffic that replaced the 1949 one, but this change happened only in 1994 (I am not sure that this resumé is completely accurate !). 

2-So that, inside the ISO Recommendation R 639 "Symbols for languages, countries and authorities" that was published by ISO in November 1967 and is the common ancestor of ISO 639 and ISO 3166,  the country symbol for Finland is "SF" (UDC 480), and the symbol for Finnish is "Fi" (UDC 945.41), the combination "Fi/SF/" being given as an example inside the Turanian language family.

3-When the first edition of ISO 3166 was published, on 1974-12-15, the code elements retained for the representation of the country name "Finland/Finlande" were based on the distinguishing sign for vehicles plate "FIN" that was yet officially in vigor, so that (FI, FIN) were choosen.

4-The second edition of ISO 3166, published on 1981-05-15, added the numeric-3 code issued by the UNSD (United Nations Statistical Division) inside the standard, so that Finland is represented by (FI, FIN, 246). A new clause "6.4 reservation of codes" was added inside the normative text of the standard, whose 6.4.2 writes:
"6.4.2 For an indeterminate period, certain code designations existing at the time of publication of this International Standard but differing from those established in the Standard should not be used for designating others entities. This applies to:
- Country designations reported under the conventions on Road Traffic (1949 and 1968);
- Codes allocated by the World Intellectual property Organization for specific purposes;
- Identification marking code for freight containers (see ISO 6346)..

5- It is on the basis of this clause 6.4.2 that ISO 3166/MA decided to include the alpha-2 code element "SF" inside the initial list of indetermined reserved alpha-2 ISO 3166(-1) code elements. When SF became replaced by FIN for finnish vehicles, ISO 3166/MA decided on 1995-09 to transfer code element "SF" from the list of indeterminately reserved ISO 3166-1 code elements to the list of transitionally reserved alpha-2 ISO 3166-1 code elements

Bien cordialement.
Gérard LANG



-----Message d'origine-----
De : ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] De la part de ltru-request@ietf.org
Envoyé : jeudi 6 août 2009 20:35
À : ltru@ietf.org
Objet : Ltru Digest, Vol 54, Issue 2

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
	ltru@ietf.org

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
	ltru-request@ietf.org

You can reach the person managing the list at
	ltru-owner@ietf.org

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


Today's Topics:

   1. Re: RFC 3282: should we revise it? (Doug Ewell)
   2. Re: RFC 3282: should we revise it? (Phillips, Addison)
   3. Re: RFC 3282: should we revise it? (Doug Ewell)
   4. ISO FDIS 639-6 (Debbie Garside)
   5. Any information on SF? (Mark Davis ?)
   6. Re: Any information on SF? (Randy Presuhn)
   7. Re: Any information on SF? (Mark Davis ?)


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

Message: 1
Date: Wed, 5 Aug 2009 19:37:38 -0600
From: "Doug Ewell" <doug@ewellic.org>
Subject: Re: [Ltru] RFC 3282: should we revise it?
To: "LTRU Working Group" <ltru@ietf.org>
Message-ID: <292E8A1E354941089DE14D0A4B506207@DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
	reply-type=original

"Phillips, Addison" <addison at amazon dot com> wrote:

> Ever the optimist, I would hope that such a revision wouldn't require 
> the level of effort needed for the BCP 47 work.

You never know.  In September 2005 on ietf-languages, Peter Constable mentioned the upcoming 4646bis effort and said:

"For my part, I hope that *that* revision is completed in a *much* shorter time that 3066bis has taken."

As we now know, 4646bis took a year or so longer than 4646.

But a quick look at RFC 3282--which is possible, since it's only 8 pages long including boilerplate and page breaks--suggests that the following changes might be all that is necessary:

* Update reference to ABNF and remove EBNF in sections 2 and 3.

* Update examples in Section 2.1 using i-languages to use ISO 639-based,
  grandfathered, hypothetical 5-to-8-character registered, or private-
  use tags instead.

* Consider a simple update to Section 4, possibly just a pointer to the
  security section of 4646bis.

* As suggested by CE Whitehead, update reference to Language "Tag"
  Reviewer (which was correct at the time 3282 was written) to refer to
  the Language "Subtag" Reviewer instead.  (On the other hand, it's just
  an acknowledgement.)

* Split references into normative and informative.

* Update [TAGS] reference to 3066 to point to 4646bis instead.

* Consider removing references to ISO standards, as the syntax and
  content of tags are fully defined by 4646bis and the Registry.

This in turn suggests that it should be feasible for an individual to prepare and submit an update without experiencing the surreal delays of the LTRU process, and without being subjected to undue slings and arrows.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ?



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

Message: 2
Date: Wed, 5 Aug 2009 21:22:27 -0700
From: "Phillips, Addison" <addison@amazon.com>
Subject: Re: [Ltru] RFC 3282: should we revise it?
To: Doug Ewell <doug@ewellic.org>, LTRU Working Group <ltru@ietf.org>
Message-ID:
	<4D25F22093241741BC1D0EEBC2DBB1DA01AC46657F@EX-SEA5-D.ant.amazon.com>
Content-Type: text/plain; charset="utf-8"

> 
> "For my part, I hope that *that* revision is completed in a *much*
> shorter time that 3066bis has taken."
> 
> As we now know, 4646bis took a year or so longer than 4646. You forget that there were a dozen or so draft-davis-phillips documents before the WG even started.

No it didn't. Mark and I started 4646 on the very first day of the Iraq war.

> This in turn suggests that it should be feasible for an individual
> to
> prepare and submit an update without experiencing the surreal
> delays of
> the LTRU process, and without being subjected to undue slings and
> arrows.
> 

Well, as noted, "ever the optimist".....

Addison

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

Message: 3
Date: Wed, 5 Aug 2009 23:28:38 -0600
From: "Doug Ewell" <doug@ewellic.org>
Subject: Re: [Ltru] RFC 3282: should we revise it?
To: "LTRU Working Group" <ltru@ietf.org>
Message-ID: <DAB87004F2524683827A9CF792178948@DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
	reply-type=original

"Phillips, Addison" <addison at amazon dot com> wrote (slightly 
rearranged):

>> As we now know, 4646bis took a year or so longer than 4646.
>
> No it didn't. Mark and I started 4646 on the very first day of the 
> Iraq war. You forget that there were a dozen or so 
> draft-davis-phillips documents before the WG even started.

I didn't forget.  My copy of draft-phillips-langtags-00 is dated 
2003-12-17.  The final draft which became RFC 4646, 
draft-ietf-ltru-registry-14, was approved by IESG on 2005-11-15, or 699 
days later.  We did wait another 10 months for RFC numbers, but that 
time was mostly spent working on the relatively uncontroversial 
draft-4647 and planning for LTRU 2.0.

Draft-ietf-ltru-4646bis-00, the first LTRU 2.0 draft, was dated 
2006-09-11 -- perhaps coincidentally, the same date RFC 4646 was 
published.  Draft-ietf-ltru-4646bis-23 was approved by IESG on 
2009-06-18 (the formal announcement came a week later).  That's a span 
of 1,011 days, or 315 days longer for LTRU 2.0 than for LTRU 1.0.  And 
of course, we're still waiting for RFC numbers.

I'd be willing to bet we spent more days actually *working* on the first 
set of drafts than on the second, but we had a LOT of downtime over the 
past 3 years.  Some issues were left unresolved and undiscussed for 
weeks at a time.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ?



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

Message: 4
Date: Thu, 6 Aug 2009 09:29:28 +0100
From: "Debbie Garside" <debbie@ictmarketing.co.uk>
Subject: [Ltru] ISO FDIS 639-6
To: <ltru@ietf.org>
Message-ID: <0d4a01ca1670$03d6d6c0$0c00a8c0@CPQ86763045110>


Hi

Just to let you know that the FDIS for 639-6 will be published on Thursday,
August 6, 2009 -- According to ISO Central Secretariat.  There is a 2 month
comments/voting window where editorial comments may be received.

Regards


Debbie Garside
Editor

The World Language Documentation Centre
Corner House
Barn Street
Haverfordwest
Pembrokeshire SA61 1BW
Wales UK

Tel: 0044 1437 766441
Fax: 0044 1437 766173

Web: http://www.thewldc.org






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

Message: 5
Date: Thu, 6 Aug 2009 11:16:16 -0700
From: Mark Davis ? <mark@macchiato.com>
Subject: [Ltru] Any information on SF?
To: LTRU Working Group <ltru@ietf.org>
Message-ID:
	<30b660a20908061116w60cfe214hf4b89bf783aeedf3@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

(That's not "San Francisco" or "Science Fiction", or any confluence of the
two.)

We're in the process of updating to the new IANA registry, and I was
cross-checking to http://www.iso.org/iso/iso-3166-1_decoding_table. The code

SF stands out.

*Transitionally reserved*
BU    Burma
CS    SERBIA AND MONTENEGRO
NT    Neutral Zone
*SF    Finland     Not in IANA. CLDR maps to FI??
*TP    East Timor
YU    Yugoslavia
ZR    Zaire

I had first presumed that SF is not included because it was withdrawn before
RFC1766. But SF is not even listed in
http://en.wikipedia.org/wiki/ISO_3166-3 as a retired code. (ISO makes it
exceptionally painful, as we all know, to get access to 3166-3:
http://www.iso.org/iso/country_codes/background_on_iso_3166/iso_3166-3.htm).
Note that http://www.iso.org/iso/iso-3166-1_decoding_table definitely has
some oddities. For example, instead of "officially assigned", for two items
it has "officiellement attribu?". So for all we know, SF is just a mistake
in that table!

Does anyone know more about the code SF?

For comparison, here are the "Exceptionally Reserved", two of which are
obsolete codes.

*Exceptionally Reserved*
AC    Ascension Island     ok
CP    Clipperton Island     ok
DG    Diego Garcia     ok
EA    Ceuta, Melilla     ok
EU    European Union     ok
*FX    France, Metropolitan     Deprecated in IANA: IANA maps to FR
*IC    Canary Islands     ok
*SU    USSR     Deprecated in IANA: CLDR maps to RU AM AZ BY EE GE KZ KG LV
LT MD TJ TM UA UZ
*TA    Tristan da Cunha     ok
*UK    UNITED KINGDOM     Not in IANA. CLDR maps to GB*

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/ltru/attachments/20090806/e02e2e7a/attachment.htm>

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

Message: 6
Date: Thu, 6 Aug 2009 11:31:46 -0700
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
Subject: Re: [Ltru] Any information on SF?
To: "LTRU Working Group" <ltru@ietf.org>
Message-ID: <001401ca16c4$286e5180$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As technical contributor...

My suggestion would be to not worry about it.

As co-chair...

It's *way* too late and too unlikely to be the source of
any kind of problem to open it up as an issue here.  If
someone thinks it would be *useful* to add it to the registry,
ietf-languages@iana.org would be the place to do it.

Randy

----- Original Message ----- 
From: "Mark Davis ?" <mark@macchiato.com>
To: "LTRU Working Group" <ltru@ietf.org>
Sent: Thursday, August 06, 2009 11:16 AM
Subject: [Ltru] Any information on SF?


(That's not "San Francisco" or "Science Fiction", or any confluence of the
two.)

We're in the process of updating to the new IANA registry, and I was
cross-checking to http://www.iso.org/iso/iso-3166-1_decoding_table. The code

SF stands out.

*Transitionally reserved*
BU    Burma
CS    SERBIA AND MONTENEGRO
NT    Neutral Zone
*SF    Finland     Not in IANA. CLDR maps to FI??
*TP    East Timor
YU    Yugoslavia
ZR    Zaire

I had first presumed that SF is not included because it was withdrawn before
RFC1766. But SF is not even listed in
http://en.wikipedia.org/wiki/ISO_3166-3 as a retired code. (ISO makes it
exceptionally painful, as we all know, to get access to 3166-3:
http://www.iso.org/iso/country_codes/background_on_iso_3166/iso_3166-3.htm).
Note that http://www.iso.org/iso/iso-3166-1_decoding_table definitely has
some oddities. For example, instead of "officially assigned", for two items
it has "officiellement attribu?". So for all we know, SF is just a mistake
in that table!

Does anyone know more about the code SF?

For comparison, here are the "Exceptionally Reserved", two of which are
obsolete codes.

*Exceptionally Reserved*
AC    Ascension Island     ok
CP    Clipperton Island     ok
DG    Diego Garcia     ok
EA    Ceuta, Melilla     ok
EU    European Union     ok
*FX    France, Metropolitan     Deprecated in IANA: IANA maps to FR
*IC    Canary Islands     ok
*SU    USSR     Deprecated in IANA: CLDR maps to RU AM AZ BY EE GE KZ KG LV
LT MD TJ TM UA UZ
*TA    Tristan da Cunha     ok
*UK    UNITED KINGDOM     Not in IANA. CLDR maps to GB*

Mark



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


> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>




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

Message: 7
Date: Thu, 6 Aug 2009 11:34:21 -0700
From: Mark Davis ? <mark@macchiato.com>
Subject: Re: [Ltru] Any information on SF?
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: LTRU Working Group <ltru@ietf.org>
Message-ID:
	<30b660a20908061134p1daa02cau9536cf302214d627@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I am NOT suggesting adding it to the registry. I just wanted to find out
what it is, to see if we need a mapping in CLDR.

Mark


On Thu, Aug 6, 2009 at 11:31, Randy Presuhn <randy_presuhn@mindspring.com>wrote:

> Hi -
>
> As technical contributor...
>
> My suggestion would be to not worry about it.
>
> As co-chair...
>
> It's *way* too late and too unlikely to be the source of
> any kind of problem to open it up as an issue here.  If
> someone thinks it would be *useful* to add it to the registry,
> ietf-languages@iana.org would be the place to do it.
>
> Randy
>
> ----- Original Message -----
> From: "Mark Davis ?" <mark@macchiato.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Thursday, August 06, 2009 11:16 AM
> Subject: [Ltru] Any information on SF?
>
>
> (That's not "San Francisco" or "Science Fiction", or any confluence of the
> two.)
>
> We're in the process of updating to the new IANA registry, and I was
> cross-checking to http://www.iso.org/iso/iso-3166-1_decoding_table. The
> code
>
> SF stands out.
>
> *Transitionally reserved*
> BU    Burma
> CS    SERBIA AND MONTENEGRO
> NT    Neutral Zone
> *SF    Finland     Not in IANA. CLDR maps to FI??
> *TP    East Timor
> YU    Yugoslavia
> ZR    Zaire
>
> I had first presumed that SF is not included because it was withdrawn
> before
> RFC1766. But SF is not even listed in
> http://en.wikipedia.org/wiki/ISO_3166-3 as a retired code. (ISO makes it
> exceptionally painful, as we all know, to get access to 3166-3:
> http://www.iso.org/iso/country_codes/background_on_iso_3166/iso_3166-3.htm
> ).
> Note that http://www.iso.org/iso/iso-3166-1_decoding_table definitely has
> some oddities. For example, instead of "officially assigned", for two items
> it has "officiellement attribu?". So for all we know, SF is just a mistake
> in that table!
>
> Does anyone know more about the code SF?
>
> For comparison, here are the "Exceptionally Reserved", two of which are
> obsolete codes.
>
> *Exceptionally Reserved*
> AC    Ascension Island     ok
> CP    Clipperton Island     ok
> DG    Diego Garcia     ok
> EA    Ceuta, Melilla     ok
> EU    European Union     ok
> *FX    France, Metropolitan     Deprecated in IANA: IANA maps to FR
> *IC    Canary Islands     ok
> *SU    USSR     Deprecated in IANA: CLDR maps to RU AM AZ BY EE GE KZ KG LV
> LT MD TJ TM UA UZ
> *TA    Tristan da Cunha     ok
> *UK    UNITED KINGDOM     Not in IANA. CLDR maps to GB*
>
> Mark
>
>
>
>
> --------------------------------------------------------------------------------
>
>
> > _______________________________________________
> > Ltru mailing list
> > Ltru@ietf.org
> > https://www.ietf.org/mailman/listinfo/ltru
> >
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/ltru/attachments/20090806/8efa2380/attachment.htm>

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

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru


End of Ltru Digest, Vol 54, Issue 2
***********************************