Language Identifier List Comments, updated

[Addison Phillips [wM]]

Responses follow.

Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com

Chair, W3C Internationalization Working Group
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: JFC (Jefsey) Morfin [mailto:jefsey at jefsey.com]
> Sent: 2004年12月28日 11:39
> To: aphillips at webmethods.com; John Cowan
> Cc: ietf-languages at alvestrand.no
> Subject: RE: Language Identifier List Comments, updated
> 
> 
> Qucik review of Addison comments.
> 
> At 18:51 28/12/2004, Addison Phillips [wM] wrote:
> >draft-langtags, as RFC 3066 before it, is not shaping the world. 
> It merely 
> >defines a standardized way for users--anyone at all--to describe or 
> >request their content language. It doesn't closely define what a 
> specific 
> >language is or usurp authority from anyone.
> 
> See Seda's mail.

Which I replied to: discussions that occur on this list, even offensive ones, are not the same thing as standards being promulgated. Seda's email was based on concerns about the content of some threads of discussion (threads having nothing to do, please note, with draft-langtags itself but rather with efforts to catalog some RFC 3066 language tags). Draft-langtags neither favors nor discriminates against minority languages, wherever they may arise. In fact, it provides avenues for minority languages to register subtags to support important distinctions at a very low level.
> 
> >IANA isn't one in this case. RFC 3066/3066bis doesn't define the 
> >combinations, only the rules for making them. What users (including IANA 
> >itself, in the case of the ccTLD thing) do with it is not 
> necessarily our 
> >concern here. And the inference of "meaning" to a language tag is left 
> >deliberately up to the end user.
> 
> This is the problem. Draft does not permit to address the IANA/Internet 
> standard process needs.
> I am not sure it addresses W3C needs either?

The draft isn't a process draft. Take your process problems to the IETF or IESG (or W3C or appropriate standards body). This draft defines language tags. Other drafts, RFCs, specs, etc. define processes and applications that use them. The appropriate use of language tags is the concern of those specifications. If there is some text that this draft should carry to help guide implementations, please suggest it so that we can all consider it.
> 
> >Your mapping is definetely of no interest to anyone in the IETF.
> 
> We agree: this is what I explain. However it documents Internet standard 
> process unfullfiled needs.

I really don't understand what "process unfulfilled needs" this draft might address other than the need to identify certain kinds of language distinctions or stabilize the meaning of language tags...
> 
> >So? So what? IDNA is not adversely affected.
> 
> Yes it is. See my other memo.

Not that I can tell, it isn't. You didn't explain what it was in draft-langtags that adversely affects IDNA and how it affects it. You merely pointed at various documents and various uses of language tags (like ar-PL), none of which is germane to draft-langtags, only to IDNA and its (you allege misguided) use of language tags. This draft doesn't *break* IDNA's use of language tags. If IDNA isn't using them correctly, well, that's bad... but not a concern that draft-langtags can address.
> 
> >Your claims of incompatibility are clearly false: the registration form 
> >you point to merely asks for a Language Tag and then a textual 
> description 
> >of the language. draft-langtags language tags are compatible 
> with the RFC 
> >3066 ABNF and will work just fine in this context.
> 
> RFC 3066 was produce before IDNA.
> Dont feel attacked. I say it is incompatible. It does not mean this is 

I'm not feeling attacked. I'm feeling mystified and trying to grasp what you are getting at.

> wrong. It only means that whoever wrote that procedure was confused and 
> thought RFC 3066 addressed the RFC 1859 requirements (you may 
> note that RFC 
> 3066 does not even quote RFC 1859).

Then the place to take it up is with IDNA. Nothing we put into draft-langtags can possibly change, affect, improve, or ameliorate what some application (such as IDNA) uses language tags for. There are plenty of bad applications of language tags, but this isn't the job of the draft to fix it. For example, I've seen language tags use as country identifiers, which is hilarious if you think about it. We don't need to add language to draft-langtags forbidding foolishness or stupidity in the use of language tags. Instead we need to resist using language tags incorrectly in other standards. If you think this is a problem, write a FAQ about it.

> 
> >The draft-langtags ABNF tightens, rather than loosens, the 
> restrictions on 
> >what strings form a valid language tag. No existing RFC 3066 
> language tags 
> >are invalidated by draft-langtags and none of the tags defined by 
> >draft-langtags would be invalid under the ABNF of RFC 3066 (or the text, 
> >for that matter). draft-langtags does not address what applications do 
> >with language tags. If the IDNA registry chooses to do odd things with 
> >language tags, then your complaint is with them.
> 
> Fully correct, if you define the scope of RFC 3066bis with the mental 
> restriction that it only applies to what RFC 3066 fully 
> supported. 

No, the revision clearly expands the scope of language distinctions that can be represented with a language tag--quite significantly in some cases. But its grammar is much more restrictive, in part to ensure full backwards compatibility with tiny little applications like, oh, say XML. It also restricts future development of compatible language tags in an effort to ensure that implementations of draft-langtags are stable over time and extended in a controlled manner.

> I would 
> be dismayed but I have no problem with that. I only think your 
> draft could 
> support much more at low additional cost and spare us a lof of problems.

Problems such as....? please enumerate the things that we need to address.

We greatly expanded what can be represented in four major ways:

1. Added script subtags for writing system variations.
2. Mixed generative and private use subtags for private minor distinctions in tags.
3. Extensions for really specialized distinctions.
4. UN M49 region codes, including supra-national regions to represent geographical distinctions not covered by ISO 3166 or by instability in same.

Used with responsible registration of variants, draft-langtags could (although it probably shouldn't be widely used to) represent the most microscopic distinctions in language along almost any line of distinction one might care to define.

> 
> > > As I say: yes for ABNF. No for an escape procedure.
> >
> >What "escape procedure"? Escape from *what*? What is it you think needs 
> >escaping in a language tag?You need to explain your problem 
> here, because 
> >I don't understand it.
> 
> When the tag you ask is missing what is to be the response. 

This is dealt with in Section 2.4.2 "Matching". This section clearly details the fallback mechanism (which is compatible with the one in RFC 3066), as well as some considerations for additional matching that can be done by specialized processors that implement a different mechanism. The matching algorithm is the standard one, but is not mandatory. In fact, I have a paper with Jeremy Carroll on a different matching algorithm that an OWL implementation might use. Read this section of the draft carefully.

> Also when you 
> do not obtain a response for all the elements in the tag but 
> could have for 
> some (like for example you do not have en-FR but you have en-UK, ...)

That would be "en-GB". If one specifies "en-FR", then one should not expect to receive anything less specific than "en-FR". If you carefully read the draft (or RFC 3066 before it) you'll notice that language tag matching works in the *opposite* way that locale matching in software works.

In software resources generally one specifies the *most specific* (granular) tag that one will accept and may receive less specific content (which may include the default content). In language tag matching one specifies the *least specific* tag that one will accept and won't receive anything less specific (although you might receive something more specific).

> 
> >Your ruminations about other ways to form language tags are interesting, 
> >but incompatible with the existing RFC and applications derived from it. 
> >This violates one of the basic criteria used to create draft-langtags.
> 
> Personal comments forgiven,  I do not see what is incompatible with the 
> existing RFC and which applications may suffer? I see and I documented 
> which RFCs and procedures are not supported. This is not a dispute but a 
> brain-storming for your draft to be the best one. Please help in 
> documenting how you perceive my way (? I only made propositions 
> in a mail I 
> send now) hurts something?

The language tag syntax from RFC 3066 itself cannot be changed. draft-langtags carefully adds restrictions to the ABNF and grammar of the tags to ensure that this is so. Changing the sources for existing subtags or the interpretation of any particular existing language tag is not permitted if we are to maintain backwards compatibility.

> 
> Also, I fail to see what violates (and wich way) a basic 
> criteria? 

The basic criteria Mark and I adopted in writing the draft are in the changes section (Section 6).

To be perfectly blunt: we've worked over a year on this project. If you have specific comments on this draft, with suggestions for improvements, please send those to the list so that they can be viewed by the community and so that Mark and I can address them. Your suggestions for additional changes to the syntax of language tags we find to be incompatible (to the extent that we understand them) with RFC 3066 and our own work on draft-langtags. You will note that draft-langtags can accommodate your requirements using the mechanisms spelled out above and in the draft... so I fail to see what we should change. If you can express that, we'll consider it. Otherwise you are free to do as we did and write your own draft. Internet-Drafts are a volunteer effort and do not write themselves. Neither is there a Star Chamber of people who create them in the dead of night. If you see a need, fill it. I would suggest: wait for draft-langtags to be an RFC and write an extension that does what you want.

> If I am 
> wrong be sure I will be the first to acknowledge it (I have a BIG work 
> right now using these concepts, I would hate to fail).
> 
> Take care.
> jfc
> 
> 
> 
> 
> 
> 
> 
> 
> 
>