Randy Presuhn scripsit:
> One of the motivations for the formation of this working group was
> to provide a way to insulate language tags from what was perceived as
> excessive instability in some of the code sources.
That is to say, we couldn't at the time trust ISO 3166/MA not to reassign
code elements to new meanings; in addition, there was no one-stop shop
for subtags (see below).
> After all, if we're just going to blindly track the ISO code du jour
> for every little piece of dirt, there's really little point to even
> bothering to put these things in our registry.
I would be slow to call a sovereign nation a "little piece of dirt".
> If consistency with other uses of those source specifications trumps
> stability as a consideration, then we should throw out our current
> procedures and registry, just say "see ISO registry mumble for these
> codes", and limit our registry and procedures exclusively to codes
> for things that ISO hasn't coded.
I disagree entirely: even if it weren't stable (in my sense), the
convenience of having a single registry to look at in a machine-readable
format, instead of four registries in random prose formats, is
considerable.
> Otherwise, we will find ourselves in the situation that a tag found
> to be OK be a validating processor will suddenly become not OK.
> That's simply not acceptable.
Are you under the impression that either RFC 4646 or the current draft
requires a validating processor to reject deprecated subtags? That is not
so. There is language in 3.1.5 (of either version) that says validating
processors SHOULD NOT *generate* them, but that's a different story.
--
A poetical purist named Cowan [that's me: cowan at ccil.org]
Once put the rest of us dowan. [on xml-dev]
"Your verse would be sweeter http://www.ccil.org/~cowan
If it only had metre
And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.