More comments on draft-03

Doug Ewell dewell at
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

> 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

More information about the Ietf-languages mailing list