More comments on draft-03
Doug Ewell
dewell at adelphia.net
Sun Jun 13 07:43:01 CEST 2004
Addison Phillips [wM] <aphillips at webmethods dot com> wrote:
>> "Corrected spelling of 'superseded'."
>
> Whatever. A little humor never USED to hurt anything... I'll try to
> behave responsibly in the transient notes in the future :-).
Explained offline. Some people have the heart of a cowboy; I have the
heart of a copy editor.
>> 5. I agree with John Cowan that if "-x-" is reserved to introduce
>> private-use subtags, it seems unnecessary to define private-use
>> subtags as beginning with the letter "x" as well. If these are two
>> different mechanisms, I can't see them and thus I think the text
>> needs clarification; and if it's the same mechanism, then the
>> "starting with x" restriction seems unnecessary.
>
> Mark and I disagree [with me]. There is a difference between a
> private-use variant and a private use subtag: you know what role a
> variant fills in the tag. There is actually text in the language,
> script, and region subtags about preferring the private use codes in
> the underlying ISO standards over using extensions for exactly this
> purpose. Consider:
>
> en-QM vs. en-x-myRegion
>
> Processors can assign "QM" to the region field, whereas "myRegion" is
> an opaque code. That's why there are two mechanisms.
OK, I'll try reading it again. It's possible that the distinction
between "en-x-foo" and "en-xfoo" is explained clearly enough in the
text, and I just didn't get it. That might not be a deficiency in the
text.
> I don't believe Harald is actually suggesting that we wait. He used
> the terminology "RFC 3066ter" to indicate a follow-on (third version)
> to "RFC 3066bis", which is this one.
I did catch the "ter" reference. What concerned me was Harald's
comment, "from the viewpoint of RFC 3066 and its successors, I am
entirely happy to not change a thing now," which to me implied that RFC
3066 should not be changed now, i.e. "bis" should be shelved.
> The existing RFC 3066 and existing practice actually allow the
> deprecated codes into tags. Although we recognize the problem of
> maintaining a tiny alpha2 namespace in an imperfect world, we also
> have to point out: content (which is where many language tags live)
> has a long shelf life. Making the langauge tags stable suggests that
> we have chosen the right course, which is that as of a certain date in
> the near future, the ISO xxx standards will be treated as stabilized
> by RFC 3066bis.
I'm not arguing against stability, even though it may look that way. I
do feel strongly that the deprecated but allowable codes (ISO 639 calls
them "withdrawn") need to be listed in a freely available registry, so
users of RFC 3066bis don't have to search hard and/or pay for valid RFC
3066bis component codes.
> We may have to burden IANA with more registry work. Mark and I will
> have to consider some text here.
Remember the message I sent a while back, listing the UN M.49 codes that
would currently be valid in RFC 3066bis tags? I plan to put that list
on my Web site, along with lists of the "withdrawn" but allowable ISO
639 and ISO 3166 codes. I hope people will review the lists so they can
serve as a good starting point for that registry.
Thanks for listening,
-Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
More information about the Ietf-languages
mailing list