Subject: [Ltru] Updated editor's copy, ready for submission...

From: Addison Phillips <[email-masked]>
Date: Tue, 27 Mar 2007 09:40:50 -0700

All,

I have prepared an updated editor's copy of 4646bis. I intend to submit 
it tomorrow, so comments now will make it into the document.

Note that I have removed the changes I proposed making the file UTF-8.

See:

  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.html
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.txt
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.xml

Wdiff is at:

  http://tinyurl.com/23jv2b

Addison
-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 27 Mar 2007 18:02:21 -0700

I'd like to see an open issues section, that lists the items still to be
resolved. Also, in requiring prefixes for variants -- is that safe with the
current registry, or would it create grandfathered variants?

Mark

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Tue, 27 Mar 2007 19:25:59 -0700

Ur... we didn't require that variants have a Prefix. We required that 
prefix references not be circular (your text, actually). Presence of a 
prefix is still not required ("MAY") in the registry and still strongly 
encouraged ("SHOULD") at registration time.

Open issues should really be tracked by the chairs. However, if you want 
me to put in the list we corresponded about off-list a couple days ago, 
I'll include it in the "changes" section before submission.

Addison

Mark Davis wrote:
> resolved. Also, in requiring prefixes for variants -- is that safe with 
> the current registry, or would it create grandfathered variants?
> 
> Mark
> 
> On 3/27/07, *Addison Phillips* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     All,
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www1.ietf.org/mailman/listinfo/ltru>
> 
> 
> 
> 
> -- 
> Mark

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 28 Mar 2007 09:02:47 -0700

> encouraged ("SHOULD") at registration time.

Ok. I was misinterpreting part of the diff.

   variant1      =  9 (MUST have language *(needs 'language'* as a prefix)
   variant2      =  9 (MUST have language-variant1 *(needs
'language-variant1'* as a prefix)

> I'll include it in the "changes" section before submission.

Yes, let's do that.

Addison

---

From: Addison Phillips <[email-masked]>
Date: Wed, 28 Mar 2007 09:43:35 -0700

Mark Davis wrote:
>    variant2      =  9 (MUST have language-variant1 *(needs 'language-variant1'
> * as a prefix)

Actually, that normative language was inappropriate (it's both an 
example and not technically correct)... and the change relaxes, rather 
than restricts it (I replaced "MUST have" with "needs").

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 28 Mar 2007 09:52:54 -0700

Yes, I agree with your change; I was just saying that when I made my
comments I had misinterpreted the change.

---

From: John Cowan <[email-masked]>
Date: Wed, 28 Mar 2007 14:53:35 -0400

> it tomorrow, so comments now will make it into the document.

[ISSUE #1]

While I agree that the change to the ABNF for 'singleton' works, it is
obfuscatory compared to:

	singleton = "a"-"w" | "y"-"z" | DIGIT

The whole point of this change is to take advantage of the fact that
case doesn't matter in ABNF definitions, so the above allows a, b,
..., w, y, z, A, B, ..., W, Y, Z, 0, ... 9, which is what we want.
%-escapes for letters are useful only when being case-sensitive, and
language tags are and always have been case-blind.

[ISSUE #2]

As the ABNF now stands, all language tags match the 'grandfathered'
production except private-use tags.  This does not seem to me to be
a syntactically useful notion.	I propose that 'grandfathered' be
removed from the ABNF.	It is referred to in two places: in the ABNF
for 'Language-Tag' it can just be replaced by 'irregular', removing a
useless ambiguity in parsers based on the ABNF; the sentence in 3.1.2
that refers to it does no useful work (obviously private-use tags won't
appear in the registry) and should just be removed.

[ISSUE #3]

I have complained about the language in 2.2.2 before; it doesn't match
the ISO 639 standards and as such is confusing.  I propose that the
first two sentences be replaced with this:

	Certain languages are defined by ISO 639-3 to be macrolanguages;
	that is, groups of very closely related languages which are
	treated as a single language in certain domains.  In order to
	improve matching behavior, each language encompassed by a ISO
	693-3 macrolanguage is represented in the IANA registry using
	an extended language subtag, provided that it is not already
	represented using a language subtag.

And the final two (example) paragraphs as follows:

	For example, the 'gan' and 'cmn' subtags represent the languages
	Gan Chinese and Mandarin Chinese, which are both encompassed by
	the macrolanguage Chinese.  Therefore, they both have the prefix
	"zh" in their registry records.  Consequently, Gan Chinese
	is represented as "zh-gan" and Mandarin Chinese as "zh-cmn".
	The language tag "zh" may be still used to label a resource
	as some unspecified variety of Chinese (which in practice will
	usually be Mandarin, the dominant variety of Chinese, but may
	be another variety).

	If the ISO 639-3 Registration Authority were to decide that Gan
	Chinese is actually two different closely related languages,
	it might reclassify it as a macrolanguage and introduce two new
	code elements.	In that case, these code elements would
	be added to the IANA registry as extended language subtags with
	prefixes of "zh-gan".  No change would be made to the registry
	record for 'gan'.

-- 
Babies are born as a result of the              John Cowan
mating between men and women, and most          http://www.ccil.org/~cowan
men and women enjoy mating.                     [email-masked]
    --Isaac Asimov in Earth: Our Crowded Spaceship

---

From: Addison Phillips <[email-masked]>
Date: Wed, 28 Mar 2007 12:04:55 -0700

> 	singleton = "a"-"w" | "y"-"z" | DIGIT

That's not legal ABNF. It's not the casing that's at fault. It's the use 
of a quoted string with a hyphen denoting a range of values. That's why 
the ABNF was reverted.

> appear in the registry) and should just be removed.

I'm okay with that.
> first two sentences be replaced with this:

I'm okay with your proposed text here.

I'll make these last two changes in the new editor's copy of draft-04. 
Proposals for making the ABNF less icky looking are welcome.

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 28 Mar 2007 12:25:25 -0700

I'm ok with all but the last part. I don't think it's productive to futz
with the language around extlang until we have have settled the issue.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Mar 2007 09:32:35 +0200

On Wed, Mar 28, 2007 at 02:53:35PM -0400,
 John Cowan <[email-masked]> wrote 
 a message of 74 lines which said:

> I propose that 'grandfathered' be removed from the ABNF.

Interesting idea. "grandfathered" is an useful concept but it is a
semantic one, not a syntactic one (some grandfathered tags are
regular, some are not).

I would say +1

---

From: Addison Phillips <[email-masked]>
Date: Thu, 29 Mar 2007 11:19:38 -0700

> appear in the registry) and should just be removed.

I have changed the editor's copy. A notable addition to this comment: I 
edited the existing entry about ABNF changes in the "changes" section to 
reflect the edits.

> [ISSUE #3]

Notwithstanding Mark's desire not to muck around with the text when it's 
been proposed we scrap it, I've incorporated these changes as shown 
below (since it is easier to track it this way).

> 	represented using a language subtag.

For consistency with other subsections as well as my understanding of 
the situation, I edited this text when I inserted it to read:

<t>Extended language subtags are used to identify languages that are 
encompassed by a "macrolanguage". ISO 639-3 defines certain languages to 
be "macrolanguages"; that is, they are groups of very closely related 
languages which are treated as a single language in certain contexts. In 
order to improve matching behavior and tagging consistency, each 
language encompassed by a ISO 693-3 macrolanguage is represented in the 
IANA registry using an extended language subtag, provided that it is not 
already represented using a language subtag. The following rules apply 
to the extended language subtags:</t>

> 	usually be Mandarin, the dominant variety of Chinese, but may

This was modified slightly, mostly to canonicalize tags ("") vs. subtags 
(''):

<t hangText="Note:">For example, the 'gan' and 'cmn' subtags represent 
the languages Gan Chinese and Mandarin Chinese. Each is encompassed by 
the macrolanguage 'zh' (Chinese).  Therefore, they both have the prefix 
"zh" in their registry records.  Consequently, Gan Chinese is 
represented as "zh-gan" and Mandarin Chinese as "zh-cmn". The language 
subtag 'zh' may be still used to label a resource as some unspecified 
variety of Chinese (which in practice will usually be Mandarin, the 
dominant variety of Chinese, but may be another variety).</t>

> 	prefixes of "zh-gan".  No change would be made to the registry

And this para was modified, mostly to keep the emphasis on the 
suppositional aspect of the example:

<t>Now suppose that, in the future, the ISO 639-3 Registration Authority 
were to decide that Gan Chinese is actually two different closely 
related languages: it might reclassify 'gan' as a macrolanguage and 
introduce two new code elements. In that case, these code elements would 
be added to the IANA registry as extended language subtags with prefixes 
of "zh-gan".  No change would be made to the registry record for 'gan'.</t>

I have not yet posted the new editor's copy of draft-04 online yet.

---

From: John Cowan <[email-masked]>
Date: Thu, 29 Mar 2007 14:55:30 -0400

Addison Phillips scripsit:

> The language subtag 'zh' may be still used to label a resource as
> some unspecified variety of Chinese (which in practice will usually be
> Mandarin, the dominant variety of Chinese, but may be another variety).

This change hides my point, which is that "zh" (the tag) is still fully
usable as a tag, despite the introduction of more specific tags
"zh-cmn", "zh-gan", etc.

-- 
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         [email-masked]
      --Edsger Dijkstra                         http://www.ccil.org/~cowan

---

From: Addison Phillips <[email-masked]>
Date: Thu, 29 Mar 2007 12:16:04 -0700

> usable as a tag, despite the introduction of more specific tags

Your point wasn't clear to me, hence my edit. Perhaps a concrete example 
would help?

--
The language subtag 'zh' may be still used on its own in a tag to label 
a resource as some unspecified variety of Chinese. For example, the tag 
"zh-Hans" remains a valid way to represent Chinese written in the 
Simplified script. (In practice 'zh' will usually be Mandarin, the 
dominant variety of Chinese, but it may represent some other variety).
--

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 29 Mar 2007 15:19:19 -0400

> dominant variety of Chinese, but it may represent some other variety).

How about s/on its own/without an extended language subtag/?

That motivates your example better.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman

---

From: Addison Phillips <[email-masked]>
Date: Thu, 29 Mar 2007 13:37:52 -0700

Changed...

A draft-04 is now posted as the editor's copy on my personal website:

  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.txt
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.html
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.xml

Addison