Subject: [Ltru] Re: editor's copy updated...

From: "Doug Ewell" <[email-masked]>
Date: Wed, 7 Mar 2007 23:03:41 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> 2. I changed the registry to UTF-8. I realize that Frank still doesn't 
> love this change, but most all other respondents supported it.

I'm fine with it as long as we have a solid assurance that IETF and IANA 
will accept it, and not throw it back in our face during or after LC. 
We know, for example, that RFCs may not contain non-ASCII characters, 
but the Registry contents will be removed from the I-D before it becomes 
an RFC.  Will the IETF allow an I-D to contain non-ASCII characters?

--
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: "Doug Ewell" <[email-masked]>
Date: Wed, 7 Mar 2007 23:47:39 -0800

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

> 5. We need to have SOME statement on whether the ordering of variants 
> is important or not. My suggestion is that it should not be important. 
> Since the canonicalization is designed to remove irrelevant 
> differences, it should then contain the text.
>
> Any sequence of variant tags MUST be reordered such that for each 
> variant subtags A and B, A comes before B if
> ...

I've probably misunderstood this explanation in some way, but just in 
case I haven't:  How does your suggestion that the ordering of variants 
should not be important square with your proposal to require the tag 
producer to put variants in a particular order?

N.B.  I note in passing, while reading Section 4.4, that the passage 
about mapping "zh-guoyu" to "zh-cmn" in "some future update of this 
document" needs to be revised, since that time is now; the Registry 
already has:

Type: grandfathered
Tag: zh-guoyu
Description: Mandarin or Standard Chinese
Added: 1999-12-18
Preferred-Value: zh-cmn
Deprecated: 2005-07-15

---

From: Addison Phillips <[email-masked]>
Date: Thu, 08 Mar 2007 07:24:34 -0800

You could, of course, use (ASCII) escapes in the RFC that get unescaped 
when the registry itself is created.

Addison

Doug Ewell wrote:
> will accept it, and not throw it back in our face during or after LC. We 
> know, for example, that RFCs may not contain non-ASCII characters, but 
> the Registry contents will be removed from the I-D before it becomes an 
> RFC.  Will the IETF allow an I-D to contain non-ASCII characters?
> 
> -- 

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: Addison Phillips <[email-masked]>
Date: Thu, 08 Mar 2007 07:29:08 -0800

> Description: Mandarin or Standard Chinese

Good catch. Thanks.

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 8 Mar 2007 07:58:25 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> You could, of course, use (ASCII) escapes in the RFC that get 
> unescaped when the registry itself is created.

But then we are relying on IANA to make the conversion.  Although IANA 
has done a far, far better job of updating the Registry in the past year 
or so, I wonder if this type of character conversion isn't a bit out of 
their realm.  If they can handle it, great.

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 8 Mar 2007 08:15:32 -0800

They are firmly linked. Maybe that will be clearer if you look at case.

It is because we ignore case differences, that we canonicalize to fixed
casing. If we didn't ignore case differences, we couldn't and shouldn't
change the case in canonicalizing: we couldn't change "En-Us" to "en-US" if
"En" meant something different from "en". And because case differences are
ignored, canonicalizing should change to a unique case: because "en" and
"En" mean the same thing, canonicalizing them should transform them to the
same string so that comparisons are binary.

Mark

-- 
Mark

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Mar 2007 16:59:12 +0100

Doug Ewell wrote:

> Will the IETF allow an I-D to contain non-ASCII characters?

That would indicate a bug at the IETF Secretariat.  But I'm
not sure where it's checked, idnits (=> no business for the
IETF Secretariat at the moment) or directly on submission.

I recall an I-D that was never announced (and it contained
some MS Word constructs, either UTF-8 or windows-1252), but
I also recall an announced draft with a few UTF-8 char.s.

You could simply test it after IETF 68, or ask them before.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Mar 2007 18:34:30 +0100

Doug Ewell wrote:

> I wonder if this type of character conversion isn't a bit out of

Of course they can, there's a "IANA considerations" section in your
I-D, and they check this during or before the IESG evaluation.  It
also affects registration templates in 4646bis.  If this bad idea
survives the IETF last call and possible appeals, I hope it doesn't.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Wed, 28 Mar 2007 10:07:42 -0700

Note: I just incorporated a change to fix this item.

The new text reads:

--
or are the result of later registrations or additions to this
document (for example, "zh-hakka" was deprecated in favor of the
language-extlang combination "zh-hak" when this document was adopted).
--