Re: draft-phillips-langtags-08, process, sp ecifications, "stability",

> ned(_dot_)freed(_at_)mrochek(_dot_)com scripsit:
> > Now, it may be the case that all _registered_ tags have avoided the use of
> > non-country code two letter codes in the third and later position. But this 
> > is
> > 100% irrelevant.
> If you say so.
> > The point is that conformant code implementing RFC 3066 is
> > broken if it simply assumes any 2 letter code after the first subtag is a
> > country code. Rather, the rule is simply that a country code, if present,
> > always appears as a two letter second subtag.
> Not quite.  The rule is that a 2-letter second subtag is a country code.
> Country codes could have appeared elsewhere, and may still wind up doing so
> before RFC 3066 is obsoleted.
But it is wrong for a compliant 3066 implementation to assume that such a two
letter code is a country code!

I really cannot fathom why this issue is so hard for you to understand.

> > The new draft changes this rule,
> > so applications that pay attention to coutnry codes in language tags have to
> > change and the new algorithm for finding the country code is trickier.
> But not much.  As an advantage, country codes can always be found in the new
> draft, whereas in RFC 3066 they could in principle be anywhere.
Not really. Anyhing that puts a country code in some other location in the
3066 world isn't going to get the benefit of automatic recognition of the
code as such by a 3066-compliant parser.

> > > (A private correspondent notes that the reference to "-x-" should
> > > in fact be a reference to any singleton, though "-x-" and "i-" are
> > > the only singletons currently usable.)
> > I have to say I find it quite interesting that one of the main proponents of
> > the new draft, while arguing that the new draft doesn't make the matching
> > problem a lot harder, ended up giving an erroneous rule for extracting 
> > country
> > codes from a language tag.
> Like other people, I sometimes post when tired; I don't think this 
> particularly
> interesting.
Whereas everyone who writes code when they implement this stuff will be as
fresh as a daisy?

> > Sure, in the general case most if not all of these nasty corner cases you've
> > created can be blithly assumed away because they only appear in specific
> > problem domains. Actual applications that operate in those specific domains
> > aren't so lucky, however. And the metric we're supposed to apply in the 
> > IETF is
> > real world implementability.
> I fail to see what this has to do with the merit of marking scripts in 
> language
> tags.  The preferred IETF charset, UTF-8, contains no information about script
> whatever.
Sadly, the IETF's preferences haven't managed to catch on in many parts of the
world.

> > As it happens I deal with messaging applications, and in this space 
> > text/plain
> > with all sorts of nasty charset issues is the rule, not the exception.
> Extended language tags will neither help nor harm you, then.
This actually may be true, because as I have said before, the likely outcome if
this draft is adopted in its present form will be that it will simply be
ignored in its entirety. But is this what we want?

                                Ned

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf