Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Jun 2007 09:48:41 -0700

Mark Davis <mark dot davis at icu dash project dot org> proposed:

> The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According 
> to ISO 639, it is used to identify linguistic content whose language is 
> known but which does not *currently* have a corresponding subtag. It is 
> thus intrinsically unstable -- the addition of other codes in the future 
> can render its application invalid at any point without any warning -- and 
> hence incompatible with the stability goals of BCP 47. It is thus always 
> preferable to use other subtags: either "und" or -- with prior 
> agreement -- private use subtags.

I am OK with this except for the recommendation to use "und".  If the 
"language is known," then it is not "undetermined."  I suggest:

"It is thus always preferable to use private-use subtags with prior 
agreement."

I might quibble with the wording "without any warning," since every time a 
new language subtag is added to the Registry, that language is potentially 
removed from the scope of "mis" (or it might be removed from the scope of 
some other language subtag, which is thus "narrowed," which is its own 
discussion).

I hate the way this minor and largely theoretical edge case is dragging down 
the project.  Are we almost ready to go with 4646bis except for "mis"?  Do 
any other issues needs to be resolved?  If so, can we spend some time on 
those issues as well?

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 16 Jun 2007 10:19:15 -0700

> "language is known," then it is not "undetermined."  I suggest:

"und" is always a possible alternate tag for any content. That is, even if I
know that content in my web page is English, I don't *have to* tag it with
English -- I can leave it untagged, which is the equivalent of "und". And
private use codes can present their own issues -- if you don't have any
prior agreement then "und" is arguably better.

I agree that it is usually better to tag content with as much information as
possible, but nothing in BCP 47 can require that. We could reorder the
sentence to express the priority, however.

It is thus always preferable to use other subtags: either a private use
subtag with prior agreement or failing that, "und".

> agreement."

I like the rewording of "prior"

> some other language subtag, which is thus "narrowed," which is its own

The key difference is that for other cases, it doesn't make any difference
when a future code is added, but for this one it breaks stability. However,
I'm ok with dropping it.

> any other issues needs to be resolved?  If so, can we spend some time on

Referring to http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html

There are quite a number of fixes that still need to be made.

Example - cleaning up extlang to still be reserved.

extlang       = *3("-" 3ALPHA)         *; specific ISO 639-3 codes
=>
*extlang       = *3("-" 3ALPHA)         *; reserved for future use*

Records of type 'extlang' MUST have *exactly* one 'Prefix' field.
=>
[delete]

Values in the field 'Prefix' in records of type 'extlang' MUST NOT be
modified.
=>
[delete]

as new records.

   1. Codes that have a defined "macro-language" mapping at the time of
   their registration MUST be entered into the registry as records of type
   'extlang' with a 'Prefix' field containing the appropriate prefix tag.
   2. Codes that represent sign languages MUST be entered into the
   registry as record of type 'extlang' with a 'Prefix' field that matches the
   Basic Language Range "sgn" (see Section 3.3.1 "Basic Filtering" in
   [RFC4647] (Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
   Tags," September
2006.)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html#RFC4647>).

   3. All other codes MUST be entered into the registry as records of
   type 'language'.

=>
as new records of type 'language'.

record of type 'language' or 'extlang'
=>
record of type 'language'
[multiple instances]

script or extlang
=>
script

Extended language subtags (type 'extlang' in the registry; see Section
3.1 (Format
of the IANA Language Subtag
Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html#ianaformat>)
also appear between the primary language and subsequent (script, region, or
variant) subtags. Applications sometimes benefit from their judicious use in
forming language tags.
=>
[delete]

(unlikely: needs prefix="language-extlang1")
=>
(unlikely)

language-extlang combination "zh-hak" when this document was adopted
=>
language combination "zh" when this document was adopted

some examples and some items in the Changes section.

--

-- 
Mark

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Jun 2007 14:13:24 -0700

Mark Davis wrote:

> "und" is always a possible alternate tag for any content. That is, even if 
> I know that content in my web page is English, I don't *have to* tag it 
> with English -- I can leave it untagged, which is the equivalent of "und". 
> And private use codes can present their own issues -- if you don't have 
> any prior agreement then "und" is arguably better.

I don't agree that "und" is equivalent to "no tag," but I don't want to 
spend a lot of time arguing about it, since I believe "und" (like "mis") is 
an exceptional subtag that is likely to see very little use in the real 
world.

> Referring to 
> http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html
>

Whoa, time out.  When did we agree NOT to use the extlang mechanism for new 
639-3 languages that have a macrolanguage?  I know you wanted that, but 
where was the consensus that makes these wishes into "fixes that need to be 
made"?  This is why I wish we were using the issue tracker as we did for 
3066bis.