Language Identifier List Comments, updated

[JFC (Jefsey) Morfin]

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.

>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?

>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.

>So? So what? IDNA is not adversely affected.

Yes it is. See my other memo.

>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 
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).

>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. 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.

> > 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. 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, ...)

>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?

Also, I fail to see what violates (and wich way) a basic criteria? 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