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 at ietf.org [mailto:ltru-bounces at ietf.org] De la part de ltru-request at ietf.org Envoyé : jeudi 6 août 2009 20:35 À : ltru at 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 at 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 at ietf.org You can reach the person managing the list at ltru-owner at 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 at ewellic.org> Subject: Re: [Ltru] RFC 3282: should we revise it? To: "LTRU Working Group" <ltru at ietf.org> Message-ID: <292E8A1E354941089DE14D0A4B506207 at 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 at amazon.com> Subject: Re: [Ltru] RFC 3282: should we revise it? To: Doug Ewell <doug at ewellic.org>, LTRU Working Group <ltru at ietf.org> Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA01AC46657F at 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 at ewellic.org> Subject: Re: [Ltru] RFC 3282: should we revise it? To: "LTRU Working Group" <ltru at ietf.org> Message-ID: <DAB87004F2524683827A9CF792178948 at 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 at ictmarketing.co.uk> Subject: [Ltru] ISO FDIS 639-6 To: <ltru at ietf.org> Message-ID: <0d4a01ca1670$03d6d6c0$0c00a8c0 at 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 at macchiato.com> Subject: [Ltru] Any information on SF? To: LTRU Working Group <ltru at ietf.org> Message-ID: <30b660a20908061116w60cfe214hf4b89bf783aeedf3 at 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 at mindspring.com> Subject: Re: [Ltru] Any information on SF? To: "LTRU Working Group" <ltru at ietf.org> Message-ID: <001401ca16c4$286e5180$6801a8c0 at 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 at iana.org would be the place to do it. Randy ----- Original Message ----- From: "Mark Davis ?" <mark at macchiato.com> To: "LTRU Working Group" <ltru at 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 at ietf.org > https://www.ietf.org/mailman/listinfo/ltru > ------------------------------ Message: 7 Date: Thu, 6 Aug 2009 11:34:21 -0700 From: Mark Davis ? <mark at macchiato.com> Subject: Re: [Ltru] Any information on SF? To: Randy Presuhn <randy_presuhn at mindspring.com> Cc: LTRU Working Group <ltru at ietf.org> Message-ID: <30b660a20908061134p1daa02cau9536cf302214d627 at 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 at 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 at iana.org would be the place to do it. > > Randy > > ----- Original Message ----- > From: "Mark Davis ?" <mark at macchiato.com> > To: "LTRU Working Group" <ltru at 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 at ietf.org > > https://www.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ > Ltru mailing list > Ltru at 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 at ietf.org https://www.ietf.org/mailman/listinfo/ltru End of Ltru Digest, Vol 54, Issue 2 ***********************************
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.