W3C home > Mailing lists > Public > www-svg@w3.org > April 2005

RE: SVG12: RFC 3066 reference

From: Addison Phillips <addison.phillips@quest.com>
Date: Mon, 18 Apr 2005 15:00:18 -0700
Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E17C@irvmbxw01.quest.com>
To: "Chris Lilley" <chris@w3.org>, "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: <www-svg@w3.org>, <public-i18n-core@w3.org>

Hi Chris and SVG WG,

Let me see if I can clarify. What follows, unless otherwise noted, is a PERSONAL response, for reasons that will be obvious.

There is a Working Group at the IETF (LTRU) working on the replacement to RFC 3066. I am the editor (with Mark Davis of IBM) of the document. He and I were the originators of the 'stuck' I-D (it failed its Last Call in part due to the fact that it was an Individual Submission). Now that it is in a Working Group, I think this work will move forward quickly (quickly being a relative term, of course), and especially so since the major sticking point appears to have reached consensus over the weekend.

One of the goals of this project is compatibility with existing RFC 3066 and its implementations. All tags described by the current draft are compatible with the ABNF and design of RFC 3066. 

There is some objection to the fact that implementations may have inappropriately been written to assume that all language tags were of the language-region ("en-US", "tlh-AQ") flavor and they may have assumed that region was guaranteed to be in the second position (it is not). Certain language tag patterns under the new design may cause specific kinds of matching issues for implementations of "remove-from-right" matching schemes described in RFC 3066. These issues are described in a companion Internet-Draft related to matching. I would be happy to illustrate this further if necessary.

I18N Core WG is chartered to work on shepherding this or any update to RFC 3066 through the W3C if and when it reaches maturity. We also are chartered to produce a spec better describing language identification in W3C specifications as part of our REC-track deliverable to define locale identifiers. See:

http://www.w3.org/2004/11/i18n-recharter/core-charter#langtags

At the present time, RFC 3066 is the normative standard. You should reference it, I think. You should also make the usual RFC allowance (by referencing it "or its successor": we've already had a wave of errata from when RFC 3066 obsoleted RFC 1766). Personally, I would be sure that my spec avoided bad assumptions about the structure of language tags. Notice that many tags using the RFC3066bis pattern have already been registered under RFC 3066.

The current draft changed name, since it comes from a WG. It is located at:

http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt

I am in the process of preparing its replacement for publication. Editor's copies of this revision and links to the working group, etc., can be found on my personal website:

http://www.inter-locale.com

The IETF group is scheduled to produce a new Last Call sometime in the next two weeks. I think that draft-01 under preparation will be very close to that document.

I would also encourage members of the W3C community to participate in the IETF process if language tags are of interest to them.

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: public-i18n-core-request@w3.org [mailto:public-i18n-core-
> request@w3.org] On Behalf Of Chris Lilley
> Sent: lundi 18 avril 2005 14:17
> To: Bjoern Hoehrmann
> Cc: www-svg@w3.org; public-i18n-core@w3.org
> Subject: Re: SVG12: RFC 3066 reference
> 
> 
> On Monday, April 18, 2005, 12:59:12 AM, Bjoern wrote:
> 
> 
> BH> Dear Scalable Vector Graphics Working Group,
> 
> BH>   http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/struct.html
> section
> BH> 5.8.5 states "The attribute value is a comma-separated list of
> language
> BH> names as defined in [RFC3066]." This is inappropriate as RFC3066 is
> BH> about to be obsoleted. Please change the draft such that it does not
> BH> depend on soon to be obsoleted specifications.
> 
> This comment would apply equally to XML, which also references RFC 3066.
> 
> The latest description in the Internationalisation activity also
> represents 3066 are correct:
> http://www.w3.org/International/articles/language-tags/
> 
> Copying public-i18n-core for expert comment.
> 
> I assume you refer to draft-phillips-langtags
> 
> I see mail from John Klensin saying this draft is 'stuck' and making a
> particularly worrying statement:
> 
>   But, if, in the process, it succeeds in identifying 3066 as Obsolete
>   without replacing it with anything that is usable and compatible, that
>   could cause a serious reduction in interoperability in the areas where
>   3066, today, is good enough or just about good enough
> 
> Where is draft-phillips-langtags now, in the process? Is it in the
> RFC editor queue? If so, what status will it come out as? I see that it
> version -08 entered Last Call as a BCP
> http://xml.coverpages.org/LangTag200412.html
> (useful article to read, by the way)
> 
> Latest version I could find was -10
> http://www.ietf.org/internet-drafts/draft-phillips-langtags-10.txt
> 
> --
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
> 
Received on Monday, 18 April 2005 22:00:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT