Referencing an alias resource file in 3066:bis
Addison Phillips [wM]
aphillips at webmethods.com
Thu Mar 18 02:05:34 CET 2004
Hi Mike,
Existing implementations that use alpha3 codes are not in conformance with
RFC3066. Adding the alpha3 codes back in won't hurt anything (with regard to
the internal requirements that Mark and I had).... except.... The alpha3
codes are more difficult to obtain authoritatively from ISO than the alpha2
codes and they represent Yet Another Case To Parse in implementing
rfc3066:bis.
So I guess I'm interested in the use cases. Since I'm not aware of any, what
implementations are you thinking of? Maybe the individual instances will be
compelling.
Mark and I will figure out what we want to do with the IANA considerations
text, then, and you can review the new draft (I may send out some previews,
since I hope to make the next draft the LAST one---every new draft resets
the first two week clock and it takes time to get the document published).
Standards work is slow by its very nature... but the cycle time on getting
an RFC through isn't that long, provided there are not any
objections/revisions along the way and also provided that the mechanics of
the process don't break down. Although this is taking longer than I had
originally hoped, I think I see daylight at the end of the tunnel now.
Mid-May isn't so bad.
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: Mike Ksar [mailto:mikeksar at microsoft.com]
Sent: mercredi 17 mars 2004 16:20
To: aphillips at webmethods.com; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Addison,
Thanks for your reply. I know that the current 3066bis allows options for
2 alpha code or 3 digit UN country number, but what I am asking for is to
have a third option to specify alpha3 country codes which do exist and are
used in certain implementations. Again this is needed for backward
compatibility. I am not advocating what the content of ISO 3166 alpha3
codes should be but since those codes exist and have been used then the
syntax should provide this additional option.
I do not have any ready text that can be included for aliasing but if you
want me to review something that you can write based on my input I would be
more than willing to review it.
Thanks for explaining the details of the approval and publication process
in IETF. I was hoping that the cycle of producing and agreeing on an
Internet Draft would take less time that it does at other SDOs.
Mike Ksar
----------------------------------------------------------------------------
--
From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
Sent: Wednesday, March 17, 2004 4:02 PM
To: Mike Ksar; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Hi Mike,
Thanks for the note.
You wrote:
<quot>There are situations in legacy systems, where backward compatibility
is important, where it would be useful to have the option of specifying in
the syntax either the 3-digit UN code or the ISO 3166 alpha country code.
Having such an option for legacy systems does not burden the standard but it
gives implementers a way to be backward compatible.</quot>
The ABNF does, indeed, make ISO3166 alpha2 and UN codes equally optional:
region = 2 ALPHA ; ISO 3166 tag
=/ 3 DIGIT ; UN country number
I think that what Mark and I have constructed is entirely backward
compatible in the way that you have in mind, in that all existing codes are
also valid RFC3066:bis codes.
The UN codes only come into play for NEW countries (that would not
otherwise have ISO3166 codes) that receive formerly assigned 3166 codes. If
you read the text very closely, what you'll see is that RFC3066:bis handles
the UN codes as a kind of informative registration. Legacy implementations
could think of (and treat) a code like sr-891 as an IANA registered code
(probably an unrecognized one--none of the major browsers seem to know about
the list of registrations in any form). Newer implementations (that
understand rfc3066:bis) would be able to associate the '891' with Serbia and
Montenegro.
Older (legacy) implementations that naively emit old-format tags are
actually protected by rfc3066:bis. For example, consider that IE5 might emit
sr-YU, which will continue to mean Serbian for Yugoslavia essentially
forever (rather than morphing into, say, Serbian for some other country
starting with Y, should ISO3166 be required to reassign that code).
It is true that changes to countries (essentially socio-political changes)
have the perverse effect of making language tags obsolete for new data, even
though the speaker populations remain more-or-less constant. I don't see any
way out of that box. At least historic data and legacy systems are somewhat
protected this way, though.
If you have text or just design notes for an updated IANA considerations
section (which is where an aliases registry would go in the draft), I would
be happy to have it. You can send text to the list or just forward it to me
personally.
With regard to the schedule of the next draft, Mark is unavailable this
week. Next week we'll chat about our current list of comments, our
responses, and what actions we intend to take.
With regard to the schedule of moving the RFC forward, the August date is
not what you should be looking at. That's the expiration date of the
Internet-Draft. The IETF process states that two weeks after the publication
of an Internet-Draft, someone (anyone, including the authors) can petition
the IESG to move the draft forward via a "recommendation for action". If
Mark and I publish a new I-D, then we would wait the two weeks (assuming no
one on this list had a reasonable objection or addition) and request such an
action. We have refrained from doing so to this point since we have been
dealing with comments. (Actually, we had hoped to do so with this draft.)
(Aside to list: hello, world: if you have comments, now would be a very
good time to make them.)
RFC3066 is a BCP (best current practices) document. On that standards
track, the IESG will (assuming they agree to accept the document) issue a
Last Call on this list of at least four weeks in duration (since Mark and I
are not an IETF WG). Assuming there are no reasonable reasons not to, they
would then advance the Internet-Draft to become a newly minted RFC (and
BCP), replacing RFC3066 as the BCP. Mark and I both hope that this
transpires L-O-N-G before August rolls around. For the gory details, see
section 6.1 of http://www.ietf.org/rfc/rfc2026.txt. Thus the soonest this
could happen is about 17 May (given a week for each interaction with the
IESG).
Best Regards,
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: Mike Ksar [mailto:mikeksar at microsoft.com]
Sent: mercredi 17 mars 2004 14:58
To: aphillips at webmethods.com; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Addison,
Thanks for your reply and explanation on dropping alpha3 country codes.
There are situations in legacy systems, where backward compatibility is
important, where it would be useful to have the option of specifying in the
syntax either the 3-digit UN code or the ISO 3166 alpha country code.
Having such an option for legacy systems does not burden the standard but it
gives implementers a way to be backward compatible.
I have a couple of more questions:
1. What is the timeline for publishing the next draft which will
include text that covers aliasing as was discussed in previous emails? I
would be more than willing to help in reviewing any text you plan to add.
2.. What is the expected time of publication the updated RFC? Is it
still August 2004 or will that date move forward since there is going to be
another draft?
Mike Ksar
----------------------------------------------------------------------------
From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
Sent: Monday, March 08, 2004 5:34 PM
To: Mike Ksar; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Hi Mike,
Thanks for the note.
While it would be possible to add alpha3 country codes to the draft,
there doesn't seem to be any point in doing so. Unlike ISO639-1/-2, there is
no difference in the range of entries in the two sets of ISO3166 codes. In
other words, every entity that has an alpha3 code also has an alpha2 code.
In fact, this is in some ways the source of the problem with ISO3166--the MA
has a limited range of codes available (about 500) and the requirement that
every country get both an alpha2 and alpha3 code more-or-less means eventual
reassignment of some codes.
An earlier version of the draft used the alpha3 codes as the resolution
mechanism when alpha2 codes were ambiguous. We eliminated that in favor of
the UN numeric codes because unlike the alpha3 codes there is no danger of
instability and because the UN codes provide some other values that some
folks might find useful. Since the alpha3 codes don't add any value and make
parsing slightly more difficult, we removed them.
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: Mike Ksar [mailto:mikeksar at microsoft.com]
Sent: lundi 8 mars 2004 15:36
To: aphillips at webmethods.com; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Addison,
Thanks.
One more questions. Would it be possible to add an optional attribute
to have RFC 3066bis reference the 3-alpha country codes in 3166? Currently
you allow the 2-alpha country codes in ISO 3166 and the 3-digit UN country
code (added in the latest draft).
Mike Ksar
--------------------------------------------------------------------------
From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
Sent: Monday, March 08, 2004 1:54 PM
To: Mike Ksar; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
This would be an addition to section 3 (IANA considerations).
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: Mike Ksar [mailto:mikeksar at microsoft.com]
Sent: lundi 8 mars 2004 13:32
To: aphillips at webmethods.com; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Addison,
XML is a possibility for sure. Where would this be described in
3066bis?
Mike Ksar
------------------------------------------------------------------------
From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
Sent: Monday, March 08, 2004 11:03 AM
To: Mike Ksar; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Hi Mike,
That sounds like a good idea. What format would such a file take?
I've seen suggestions for comma-separated values. Personally, I'd prefer XML
files at the end of a URL. The registration information really isn't very
complicated, so rendering it up in such a manner wouldn't be that difficult.
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: Mike Ksar [mailto:mikeksar at microsoft.com]
Sent: lundi 8 mars 2004 10:46
To: aphillips at webmethods.com; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Addison,
Let me clarify. I am talking about an alternate resource file
that uses a different syntax layout than what RFC 3066 or RFC 3066bis uses
with the same basic information and semantics. I am not talking about
having different semantics.
Mike Ksar
----------------------------------------------------------------------
From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
Sent: Saturday, March 06, 2004 3:15 AM
To: Mike Ksar; IETF-languages list
Subject: RE: Referencing an alias resource file in 3066:bis
Hmmm....
I'm not quite sure I understand your proposal. If by "an alternate
resource file...to validate language-tags" you mean "a way to implement tags
that use a different valiation scheme than the one in RFC3066" (e.g., one in
which the subtags have a different meaning) then I would point to the
extension mechanism. "x-something" can have externally defined semantics.
If that means "a way to implement registered values on an
automatic basis", we can add text to the IANA registration section requiring
some additional file formats, such as comma delimited or XML, be maintained
for each registration or for the lot of them (or both). This would assist
implementers a little bit (the REAL problem, you'll note isn't the small
number of registrations: it's the availability of the underlying ISO
standards in a machine parseable format).
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Mike Ksar
Sent: vendredi 5 mars 2004 20:25
To: IETF-languages list
Subject: Referencing an alias resource file in 3066:bis
I have not seen any feedback on my inquiry about the possibility
of referencing an alias resource file for language tags that do not follow
the syntax of 3066:bis. I am not thinking of this as part of the extension
mechanism but as an alternate resource file to allow the implementer to
choose an additional resource file at IANA or externally to validate
language-tags. This would address the issues raised by the example on
i-klingon deprecation and other examples that have not been raised yet for
implementations that do not follow the exact syntax of 3066:bis.
Mike Ksar
-----Original Message-----
From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Peter Constable
Sent: Tuesday, February 24, 2004 8:54 AM
To: IETF-languages list
Subject: RE: (iso639.1574) New ISO 639 language identifier -
Klingon
> From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Addison Phillips [wM]
> According to the rules in place in RFC3066 (not bis), as I
understand
them,
> the tag 'i-klingon' will never be *deleted*, only deprected
with a
reference
> to 'tlh'.
I think what Mike was suggesting was that the RFC say something
explicit
about how alisasing in such cases is dealt with. It currently is
silent
on this, so while I could look in the registration file for
i-lux
(http://www.iana.org/assignments/lang-tags/i-lux) and find that
it "has
been deprecated by ISO 639 lb", there's nothing in the RFC to
tell me
that that will always be done, or that it will always be done
the same
way.
And more could be done to make life easier for application
developers,
or even to allow for more intelligent apps. For instance, the
IANA
lang-tags folder could contain a tab- or comma-delimited file
alias.txt
containing alias mappings; e.g.
;deprecated,best_practice
i-lux,lb
i-navajo,nv
no-bok,nb
no-nyn,nn
etc.
Or the server could respond to a request along the lines of
http://www.iana.org/langtag_alias.asp?tag=i-lux
by returning parsable information regarding the relationship
between
i-lux and lb.
The fact is that aliases can and do exist. The question is
whether we
are doing all that we could to deal with that reality.
Peter
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-languages/attachments/20040317/74483ae6/attachment-0001.htm
More information about the Ietf-languages
mailing list