Subject: [Ltru] draft-4645bis-03

From: "Doug Ewell" <[email-masked]>
Date: Sun, 9 Dec 2007 23:47:25 -0800

Editor's copies of draft-4645bis-03 have been posted to my site:

http://home.roadrunner.com/~dewell/draft-ietf-ltru-4645bis-03.txt
http://home.roadrunner.com/~dewell/draft-ietf-ltru-4645bis-03.html

Anyone who wants a preview of these before I submit them to 
Internet-Drafts, probably Tuesday or Wednesday, is invited to take a 
look and report any errors.

As a reminder, even with the removal of 1,400-plus inverted names, these 
are still huge files (up to 819 kB for text version) and care should be 
taken before downloading them via a slow connection, or printing any but 
the first few and last few pages.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://home.roadrunner.com/~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: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Dec 2007 14:41:16 +0100

On Sun, Dec 09, 2007 at 11:47:25PM -0800,
 Doug Ewell <[email-masked]> wrote 

> Editor's copies of draft-4645bis-03 have been posted to my site:

I love this one:

Type: language
Subtag: nb
Description: Norwegian Bokm&#xE5;l
Macrolanguage: no

I first thought it means Bokmal has no encompassing macrolanguage :-)

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 11 Dec 2007 06:52:15 -0800

> I first thought it means Bokmal has no encompassing macrolanguage :-)

See also:

Type: language
Subtag: yes
Description: Yeskwa
Added: 2029-09-09

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Dec 2007 17:59:39 +0100

> Editor's copies of draft-4645bis-03 have been posted to my site:

I made various automatic tests on the proposed registry and found no
problem.

You apparently did not use the possibility of using UTF-8 in the
Description fields?

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Dec 2007 23:47:46 +0100

Stephane Bortzmeyer wrote:
 
> You apparently did not use the possibility of
> using UTF-8 in the Description fields?

Internet Drafts need to be US-ASCII.  Just pipe
it through 4645bis.awk to get the UTF-8 version:
<http://purl.net/xyzzy/home/ltru/4645bis.awk>

 Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 11 Dec 2007 22:03:38 -0800

> You apparently did not use the possibility of using UTF-8 in the 

Regarding the I-D:  my understanding is that non-ASCII is not allowed in 
I-Ds.  This is why the data in the Registry uses NCRs and is accompanied 
by an instruction to IANA (with "MUST") to convert it to UTF-8.

I'm not 100% sure about the non-ASCII restriction; someone once said 
that only applied to RFCs, whereas the non-ASCII part of 4645bis (like 
4645 before it) will be stripped out before the draft is published as an 
RFC.  I seem to remember trying to run UTF-8 through xml2rfc and ending 
up with non-validating HTML and ASCII-mutilated text, and never trying 
it again.

In private mail, Stéphane asked me for a copy of just the proposed 
4645bis Registry, without the surrounding text, and I sent him one.  But 
at 6:50 in the morning, with normal morning family activities around me, 
my brain malfunctioned and I forgot to convert the file to UTF-8.  That 
may be what he was referring to.

In fact, draft-4646bis makes no provision for "optional" hex NCRs, only 
UTF-8.  The description "Volap&#xFC;k" would literally be 12 characters 
long, including the three non-alphabetic characters.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Dec 2007 10:24:10 +0100

On Tue, Dec 11, 2007 at 10:03:38PM -0800,
 Doug Ewell <[email-masked]> wrote 
 a message of 31 lines which said:

> I forgot to convert the file to UTF-8.  That may be what he was
> referring to.

Yes. I suggest to put a version of the proposed future registry online
somewhere. This would work around the I-D limitations. And allow us to
test our tools on a "real" version.
 
> In fact, draft-4646bis makes no provision for "optional" hex NCRs,
> only UTF-8.

Thanks for the reminding. My tool currently converts the NCR to
Unicode. Should I stop?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Dec 2007 21:37:06 +0100

On Tue, Dec 11, 2007 at 11:47:46PM +0100,
 Frank Ellermann <[email-masked]> wrote 

> <http://purl.net/xyzzy/home/ltru/4645bis.awk>

Or ncr2utf8.py, attached :-)

I tested the UTF-8 version of 4645bis and everything is OK. It is much
simpler now :-)

unicodechar = satisfy (\thechar -> 
                 let c = (ord thechar) in
                     (c >= 0x21 && c <= 0x10ffff))
       <?> "Character"
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 12 Dec 2007 22:27:34 +0100

> Or ncr2utf8.py, attached :-)

Better, if unichr() catches bogus codepoints.

> It is much simpler now :-)

Slightly exaggerated, for XML-converters NCRs
or UTF-8 are both fine, for human readers it's
a matter of taste depending on their platform
and their fonts.

 Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 12 Dec 2007 07:57:07 -0800

> Thanks for the reminding. My tool currently converts the NCR to 

A tool that is intended to check the Registry for conformance to the 
spec should stop.

A tool that is intended for practical use in language tagging might 
choose to be robust and continue to interpret hex NCRs, so it will work 
with both old and new versions of the Registry.  This would backfire if 
a subtag were added with a Description or Comments field containing a 
sequence that looked like a hex NCR, which would be a supremely bad 
idea.