Subject: [Ltru] Solving the UTF-8 problem

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jul 2007 15:58:48 -0700

This is intentionally cross-posted to LTRU and ietf-languages, since it 
deals with both implementation policy and proposed changes to RFC 4646bis 
and 4645bis.

CE Whitehead <cewcathar at hotmail dot com> wrote on ietf-languages:

> I want to update the 1694acad comments field to include a transliteration 
> into Basic Latin (also--perhaps???--to fix the inconsistency as 4eme is 
> missing the accent grave on the e!! :
>
> Comments: 17th century French, as catalogued in the "Dictionnaire de 
> l'acad&#xE9;mie fran&#xE7;oise" ("l'academie francoise"), 4&#xE8;me (4eme) 
> ed. 1694; frequently includes elements of Middle French, as this is a 
> transitional period.

I really, really don't like the direction this is headed.  Ultimately we 
will find ourselves having to provide duplicate Description and Comments 
content for every non-ASCII character in the Language Subtag Registry, 
removing most of the advantage of being able to represent non-ASCII in the 
first place.

What are we going to do when the ISO 639-3 code list is finalized and we 
have to deal with adding the following pairs of languages, whose names 
differ only by diacritical marks?

aru  Arua
arx  Aruá

bfa  Bari
mot  Barí

kgm  Karipúna
kuq  Karipuná

sbe  Saliba
slc  Sáliba

wbf  Wara
tci  Wára

Are we going to include an ASCII version of every name that contains an 
accented letter?  There are several hundred in ISO 639-3.  As CE has shown 
above, we are already strongly considering adding duplicative Comments 
information to get around our own technical limitations.  Will we also have 
to include elaborate Comments fields distinguishing the "real" Arua from the 
one we invented by lopping off the accent from Aruá?

Section 3.1 mentions transcription of non-Latin Description fields into the 
Latin script.  It does not talk about providing a pure-ASCII equivalent for 
every non-ASCII French- or Spanish-language string, and I don't believe that 
was the WG's intention.  Transcriptions are useful when the content is in 
Arabic or Cyrillic or Han, to make the material available to 
Latin-script-only readers.  Providing "transcriptions" like "4#xE8;eme 
(4eme)" merely announces to the world that we can't solve our own technical 
character-encoding problems without resorting to unwieldy kludges.

We really need to take another hard, serious look at maintaining the 
Registry in UTF-8.  The current scheme is one of the biggest sources of 
misunderstanding that newcomers have about the Registry, and one of the 
biggest bones of contention among regular list participants.  We need to 
consider this soon, before the release of the "final" ISO 639-3 data moves 
RFC 4645bis onto the LTRU critical path, because the way it is decided will 
have huge implications for RFC 4645bis.  And we need to consider it WITHOUT 
dragging in side discussions like XML.

As far as I can tell, the objections to moving the Registry to UTF-8 are as 
follows:

1.  UTF-8 doesn't play well with e-mail, which is invaluable for discussing 
changes on the ietf-languages list and sending the changes to IANA (stated 
by several).

Clearly there are problems with the diversity of character encodings as 
e-mail travels from a sender's machine across the Internet and onto each 
recipient's client, or gets processed into Web archive pages.  Even on the 
Unicode mailing list and mail archive pages, where you might think the 
problem would be solved, you can see numerous examples of this.  This isn't 
limited to UTF-8; it is not uncommon to see Latin-1 or (especially) 
Windows-1252 get corrupted or displayed incorrectly.

As Ira McDonald suggested, it would make sense to conduct all preliminary 
discussion using escape sequences or some other mechanism:

"(Note: the name 'Aruá' is actually spelled 'A, r, u, a-with-acute'.)"

but then send the final change to IANA in UTF-8 so they could simply drop it 
into the Registry with little or no editing, as they do now.  We would have 
to figure out some way for the list to confirm that the changes seen on the 
list are those that are sent to IANA, with no alteration other than the 
recoding to UTF-8.  This should not be difficult.  I am willing do whatever 
is deemed necessary on my part to make this work.  We need to figure out how 
to make it work, instead of using it as a reason not to adopt UTF-8.

2.  Converting the Registry to UTF-8 would break existing implementations 
that expect hex NCRs (Addison Phillips).

Addison is correct; any structural change to the Registry will break RFC 
4646-conformant processors.  This is true not only for UTF-8, but also for 
new fields such as "Macrolanguage" or "Modified."  (Section 3.1 says the 
Type "MUST" be one of the seven currently defined values.)

If there are implementations that read and interpret the Registry and will 
choke on non-ASCII input, whose authors are not on one of these mailing 
lists, then we need to get the word out that the format may change, just as 
we would if we decide to add new field values.  Personally I doubt there are 
large numbers of such implementations.

3.  UTF-8 can't be read on some, espcially older, computer systems (Frank 
Ellermann, months ago, and CE Whitehead).

With the continuing adoption of Unicode by OS and software vendors, I really 
can't get behind this argument.  It simply isn't appropriate to "dumb down" 
all computerized text to match the least capable systems that might be 
running somewhere.  This is especially true considering the language names 
listed above.  We don't restrict text to uppercase to maintain compatibility 
with BCDIC and Sinclair ZX81 systems.

A Windows system running Internet Explorer 4.0 or above can display a local 
text file as UTF-8.  According to Wikipedia, of the 78% of Windows machines 
that run IE, fewer than 1% are running a version lower than 6.0.  Support 
for UTF-8 is probably the same, if not better, for non-Microsoft browsers; 
see http://www.alanwood.net/unicode/browsers.html for more information.

In thinking about "display," we should step back and remember why we have a 
Language Subtag Registry at all.  It exists to support BCP 47 language 
tagging by providing a complete list of all subtags that can be used to form 
a language tag, plus all grandfathered tags that can be used on their own. 
It provides some additional information, such as comments, to help tag 
producers and consumers make tagging decisions, but it is not intended to be 
a general compendium of language information, meant for casual browsing.

Another possibility is to have IANA post an official version of the Registry 
in one encoding, such as UTF-8, and additional, unofficial versions in other 
encodings, such as Latin-1 or hex NCRs.  This is the approach chosen by the 
ISO 639-3 Registration Authority.  Potential problems with this approach are 
unintentional mismatches between the versions (I caught one of these 
problems for the ISO 639-3 people recently) and a perception that the 
"simplified" version is actually the official one.

My suggestions, very simply, are:

* For LTRU, to amend RFC 4646bis to change the format of the Registry to 
UTF-8, and to work out the details such as compatibility with existing RFC 
4646 processors and avoidance of UTF-8 in e-mails.

* For ietf-languages, to impose a moratorium on changes to Description and 
Comments fields whose only purpose is to transcribe hex NCRs to ASCII, until 
the matter is resolved within LTRU.

--
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: John Cowan <[email-masked]>
Date: Sun, 1 Jul 2007 19:28:23 -0400

Doug Ewell scripsit:

> 1.  UTF-8 doesn't play well with e-mail, which is invaluable for 
> discussing changes on the ietf-languages list and sending the changes to 
> IANA (stated by several).

I note for the record that your message arrived encoded in Latin-1
but tagged "utf-8".

-- 
We pledge allegiance to the penguin             John Cowan
and to the intellectual property regime         [email-masked]
for which he stands, one world under            http://www.ccil.org/~cowan
Linux, with free music and open source
software for all.               --Julian Dibbell on Brazil, edited

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jul 2007 16:50:22 -0700

John Cowan <cowan at ccil dot org> wrote:

> I note for the record that your message arrived encoded in Latin-1 but 
> tagged "utf-8".

(For reference: Microsoft Outlook Express 6.00.2900.2180.)

When I saved the sent message as a text file and then opened it in a hex 
editor, I saw the UTF-8 sequences.  So it may have been changed somewhere 
along the way.  Maybe I should have included a non-1252 character somewhere.

In any case, I don't dispute that e-mail support for UTF-8, whether in 
clients or gateways, is unreliable.  I suggested an approach to get around 
that problem.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Jul 2007 15:47:07 +0200

On Sun, Jul 01, 2007 at 03:58:48PM -0700,
 Doug Ewell <[email-masked]> wrote 
 a message of 161 lines which said:

> If there are implementations that read and interpret the Registry
> and will choke on non-ASCII input,

They are perfectly right: this is what RFC 4646 asks. Without this
behaviour, some typos will go unnoticed.

> Personally I doubt there are large numbers of such implementations.

I tested my own implementation, GaBuZoMeu and I'm mortified to
announce that it accepts UTF-8 without even a warning (I did not want
that, I regard it as a bug).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Jul 2007 15:55:33 +0200

On Sun, Jul 01, 2007 at 03:58:48PM -0700,
 Doug Ewell <[email-masked]> wrote 
 a message of 161 lines which said:

> Another possibility is to have IANA post an official version of the
> Registry in one encoding, such as UTF-8, and additional, unofficial
> versions in other encodings, such as Latin-1 or hex NCRs.

Why not? Currently, we do exactly the opposite: IANA publishes the
official registry in hex NCR
(http://www.iana.org/assignments/language-subtag-registry) and
langtag.net publishes an unofficial version in UTF-8
(http://www.langtag.net/registries/language-subtag-registry.utf8).

> Potential problems with this approach are unintentional mismatches
> between the versions (I caught one of these problems for the ISO
> 639-3 people recently)

I do not get it. If the unofficial version is produced by a program,
how can a mismatch exist (unless there is a bug in the program)? 

And if the unofficial version is done by hand, should we tell ISO
639-3 that computers are better than people for boring and repetitive
tasks?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Jul 2007 22:15:55 +0200

On Sun, Jul 01, 2007 at 03:58:48PM -0700,
 Doug Ewell <[email-masked]> wrote 
 a message of 161 lines which said:

> 3.  UTF-8 can't be read on some, espcially older, computer systems
> (Frank Ellermann, months ago, and CE Whitehead).
> 
> With the continuing adoption of Unicode by OS and software vendors,
> I really can't get behind this argument.

Sorry but UTF-8 adoption is far from ubiquitous. Many tools still have
problems with UTF-8. I discovered today that ht://Dig, one of the two
most common free search engines has no UTF-8 support at all (see
http://www.htdig.org/FAQ.html#q4.27 and
http://www.htdig.org/FAQ.html#q4.10) which is quite sad for a Web
search engine (and, yes, the explanations they give are wrong, too).

Another common example is the Postscript tool a2ps.

> It simply isn't appropriate to "dumb down" all computerized text to
> match the least capable systems that might be running somewhere.

I understand the reasoning and, yes, switching the registry to UTF-8
might be one more signal sent to software developers, to tell them
they really should upgrade but do not claim that everything is done
yet.

So, I basically agree that UTF-8 for the registry is better but I do
not want to see bold sentences like "Anyone but Frank Ellermann can
run a full UTF-8 environment by now". This is not true.

> This is especially true considering the language names listed above.
> We don't restrict text to uppercase to maintain compatibility with
> BCDIC and Sinclair ZX81 systems.

I'm not talking about dead systems but about programs which are live,
used and maintained.

Note from the trenches: as an implementor, I promise to follow
whatever LTRU will decide and to improve my UTF-8 parsing abilities in
Haskell, should we decide to use it.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 Jul 2007 20:54:56 -0700

Hi -

As a technical contributor...

> From: "Stephane Bortzmeyer" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, July 02, 2007 1:15 PM
> Subject: [Ltru] Re: Solving the UTF-8 problem
...
> run a full UTF-8 environment by now". This is not true.
...

Granted, but we really need to be mindful of who the users of the registry
(rather than things built using information from the registry) would be.
These are the use cases that I think are important to support:

   1) Developers of software packages to support localization and
        internationalization.  It's hard to imagine them not having UTF-8
        capabilities.

    2) Developers of software used to identify the language(s) used in content.
         It's hard to imagine them not having UTF-8 capabilities.

    3) Reviewers (typically linguists or technologists, I'd hope) evaluating
         language subtag registration requests.  It's hard to imagine them
         not having UTF-8 capabilities, even though we've heard from two
         people whose circumstances prevent them from being able to
         use current technology.  (I can't imagine continuing to work under
         such conditions, and don't know why they put up with it.)

     4) People with a need to request a new subtag registration.  If they
         are linguists, I'd strongly suspect that they'd have access to UTF-8
         capable technology.  Otherwise, I suspect they'd already be
         covered by (1), (2), or (3) above.

Am I missing something?

Randy

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Jul 2007 23:00:01 -0700

Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

> So, I basically agree that UTF-8 for the registry is better but I do not 
> want to see bold sentences like "Anyone but Frank Ellermann can run a full 
> UTF-8 environment by now". This is not true.

You're correct.  I restated three objections to converting the Registry to 
UTF-8, and tried to show why they don't outweigh the advantages of 
converting.  All three are, in fact, true:

1.  UTF-8 doesn't play well with e-mail.
2.  Converting will break processors that expect only ASCII.
3.  Some computers can't display UTF-8.

But we can work out the e-mail problem, and the breakage to processors is no 
worse than adding new fields (nor are there that many fully-conformant 
processors to be fixed).  And the display problem is really not as much of a 
showstopper as it is being portrayed.  People are saying that the hex 
escapes are a display problem too, and adding "Arua" and "Aru&#xE1; (Arua)" 
to the Registry is going to confuse a LOT of people, no matter how many 
comments we add.

---

From: Peter Constable <[email-masked]>
Date: Tue, 3 Jul 2007 08:24:32 -0700

From: Doug Ewell [mailto:[email-masked]]

> I restated three objections to converting the Registry to
> UTF-8, and tried to show why they don't outweigh the
> advantages of converting.  All three are, in fact, true:
>
> But we can work out the e-mail problem

+1

> And the display problem is really not as much of a
> showstopper as it is being portrayed.  People are saying
> that the hex escapes are a display problem too...

+1. I don't see the display issue as being a show-stopper at all. Anybody that has a need to view this registry has access to means of viewing UTF-8.

> the breakage to processors is no worse than adding new
> fields (nor are there that many fully-conformant
> processors to be fixed).

I'm inclined to agree, but am waiting to see if anyone makes a strong counterargument.

Peter

---

From: John Cowan <[email-masked]>
Date: Tue, 3 Jul 2007 11:28:49 -0400

> I'm inclined to agree, but am waiting to see if anyone makes a strong counterargument.

Nobody actually knows how many fully conformant processors there are.

I still think the email argument is the compelling one.  We *will*
have corruption no matter what.

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 3 Jul 2007 10:48:49 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Peter Constable" <[email-masked]>
> Sent: Tuesday, July 03, 2007 8:28 AM
> Subject: Re: [Ltru] Re: Solving the UTF-8 problem
...
...

This argument is only meaningful for the format we use to discuss changes
to the registry content.  It has no bearing on the format of the registry itself.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Wed, 04 Jul 2007 15:43:59 +0900

At 00:24 07/07/04, Peter Constable wrote:
>> advantages of converting.

Dougs argument that most newcommers are confused by the
numeric character references is a very strong one.

>>  All three are, in fact, true:
>>

I'm confident this can be done. I'm one of the people who
cannot view UTF-8 in email, but I consider that my problem,
not a problem of the WG or the subtag registration mailing
list.

One thing we should try to get solved (if it's not already
done) is to make sure that the mailing list archive serves
emails with the correct charset setting. This may or may not
already the case.

>+1. I don't see the display issue as being a show-stopper at all. Anybody 
>that has a need to view this registry has access to means of viewing UTF-8.

I strongly agree with this.

>I'm inclined to agree, but am waiting to see if anyone makes a strong 

I agree here too. There are not too many implementations that
read in the registry, and of these, some are known and can be fixed,
some are know to be 8-bit tolerant, and some are run only in batch
mode in a central place and can be fixed when an update occurs.

For the implementations where this really matters, i.e. stuff that
is field-deployed with a software upgrade mechanism and polls the
registry, first, such implementations should be rather rare, and
second, they should have been implemented in a robust way, because
with the network, there are no guarantees at all. Explained in another
way, if the implementation throws up because it sees an eigth bit
on a byte, and becomes completely useless (e.g. it clears its
internal language information cache or just blows up), then that's
a very bad implementaion. Even if we keep all our stability guarantees,
there is no guarantee that the network will never turn any bits.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Thu, 5 Jul 2007 20:03:41 -0400

Randy Presuhn scripsit:

> This argument is only meaningful for the format we use to discuss
> changes to the registry content.  It has no bearing on the format of
> the registry itself.

That is only so if we have some means other than email for communicating
with IANA.

-- 
There are three kinds of people in the world:   John Cowan
those who can count,                            [email-masked]
and those who can't.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Jul 2007 19:50:52 -0700

Hi -

As a technical contributor:

> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 05, 2007 5:03 PM

...

No.  The format of the email discussion does not need to be the same as
the format of the registry itself.  That is a simplifying, but not necessary,
assumption.  The email discussion only needs to contain information that
could be used to generate the necessary changes.  Though I wouldn't want
to make unnecessary work for IANA, I also think that they are quite capable
of operations more sophisticated than mere cut-and-paste.

The current situation is, in my opinion, a result of over-specification of the
interface between the reviewer and IANA.

Randy

---

From: Chris Newman <[email-masked]>
Date: Mon, 09 Jul 2007 23:38:10 -0700

Doug Ewell wrote on 7/2/07 23:00 -0700:

> showstopper as it is being portrayed.  People are saying that the hex escapes
> are a display problem too, and adding "Arua" and "Aru&#xE1; (Arua)" to the
> Registry is going to confuse a LOT of people, no matter how many comments we
> add.

UTF-8 has been the recommend charset for Internet interchange since RFC 2277. 
Our past experience with ASCII encodings of non-ASCII text in the IETF has been 
questionable.  RFC 2047, 2231, IMAP modified-UTF-7, and quoted-printable have 
all had mixed results.  Meanwhile, UTF-8 based IETF protocols have been less 
problematic from an interoperability viewpoint.  The EAI WG is putting together 
an experiment to try UTF-8 in email headers and addresses and that will 
increase the pressure to update email infrastructure.

Rough edges are inevitable during the adoption of new technology, but where do 
we want to be 5-10 years from now?  What's the least painful path to get there?

                - Chris

---

From: Peter Constable <[email-masked]>
Date: Tue, 10 Jul 2007 09:20:28 -0700

> From: Chris Newman [mailto:[email-masked]]

> questionable... Meanwhile, UTF-8 based IETF protocols have been less
> problematic from an interoperability viewpoint...

Sound to me like good arguments for us to be considering UTF-8 for the LSTR.

Peter

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 11 Jul 2007 15:03:23 +0100

Couldn't we just put it to the vote?  I thought we had this discussion a
year or so ago?

FWIW, my vote would be +1

Best regards

Debbie 

> -----Original Message-----
> From: Peter Constable [mailto:[email-masked]] 
> Sent: 10 July 2007 17:20
> To: LTRU Working Group; [email-masked]
> Subject: RE: [Ltru] Re: Solving the UTF-8 problem
> 
> > Our past experience with ASCII encodings of non-ASCII text 
> in the IETF 
> > has been questionable... Meanwhile, UTF-8 based IETF protocols have 
> > been less problematic from an interoperability viewpoint...
>

---

From: Addison Phillips <[email-masked]>
Date: Wed, 11 Jul 2007 07:13:18 -0700

Voting isn't the measure: rough consensus is the measure. I agree that a 
strawpoll would help establish if we have consensus, though.

I, of course, have always supported putting the registry into UTF-8. If 
folks are happy with the resolution to the parser compatibility issue, 
I'm happy to go to UTF-8.

So:

+1

Addison

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

Internationalization is an architecture.
It is not a feature.

---

From: Peter Constable <[email-masked]>
Date: Wed, 11 Jul 2007 10:03:12 -0700

+1

-----Original Message-----
From: Addison Phillips [mailto:[email-masked]]
Sent: Wednesday, July 11, 2007 7:13 AM
To: Debbie Garside
Cc: Peter Constable; 'LTRU Working Group'
Subject: Re: [Ltru] Re: Solving the UTF-8 problem

So:

+1

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 11 Jul 2007 14:13:36 -0700

+1

-- 
Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 Jul 2007 15:48:44 -0700

Hi -

As a co-chair...

There appears to be an emerging consensus that having UTF-8 in the
registry would make sense.  Before we can claim to have completed
this item, however, we should identify and get agreement on updated
text for 4646bis to make it so, as well as any additional
instructions for the conversion and "bulk update" of the registry
itself.  The devil is frequently in the details, so we can't declare
consensus here until we've worked throught the rest of the exorcise.

Randy

---

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 12 Jul 2007 01:05:32 +0200

+1

  _____  

From: Mark Davis [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 11:14 PM
To: Peter Constable
Cc: LTRU Working Group
Subject: Re: [Ltru] Re: Solving the UTF-8 problem

+1

+1

-----Original Message-----
From: Addison Phillips [mailto:[email-masked]]
Sent: Wednesday, July 11, 2007 7:13 AM
To: Debbie Garside
Cc: Peter Constable; 'LTRU Working Group' 
Subject: Re: [Ltru] Re: Solving the UTF-8 problem

So:

+1

Addison

Debbie Garside wrote:
>> From: Peter Constable [mailto:  <mailto:[email-masked]> [email-masked]]
>> Sent: 10 July 2007 17:20

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

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Wed, 11 Jul 2007 16:13:27 -0700

> The devil is frequently in the details, so we can't declare

Understandable, although, pace any showstoppers, the question currently 
is whether there is consensus toward pursuing this course.

Here's my thought on "order of battle": I will prepare the current text 
and submit it tomorrow.

Then I will incorporate the various pending bits of text plus the 
necessary changes for UTF-8 into a new prototype draft, which I will 
publish on inter-locale.com. When the ID Editors publish the draft 
mentioned just above, I'll submit this new draft. Given their recent 
history of prompt action, this could even be sometime Friday. This would 
give us a basis for diff comparisons [and XML2RFC source] (in case we 
decide to revert Yet One More Time).

Since I've already done this exercise once, it shouldn't prove to be 
that difficult.

NB> Doug will need to add instructions in 4645 about how he's converting 
hex escapes in the original registry to Unicode.

Addison

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jul 2007 19:30:15 -0400

Addison Phillips scripsit:

> necessary changes for UTF-8 into a new prototype draft, 

Since UTF-8 is controversial and the other bits are (AFAIK) not,
please make a separate all-pre-UTF-8 fixes draft.  I know this
uses up another positive integer as a draft number, but we have
lots of those.

That way we can focus on just what diffs constitute the UTF-8 change.

-- 
A poetical purist named Cowan           [that's me: [email-masked]]
Once put the rest of us dowan.          [on xml-dev]
    "Your verse would be sweeter        http://www.ccil.org/~cowan
    If it only had metre
And rhymes that didn't force me to frowan."     [overpacked line!] --Michael Kay

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 Jul 2007 18:03:48 -0700

Hi -

> To: "Addison Phillips" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, July 11, 2007 4:30 PM

...

Both as a technical contributor and as a co-chair, I like this idea.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Thu, 12 Jul 2007 10:42:48 +0900

The comment below seems to say that changes due to UTF-8 will
be all over the place. That should not be the case. Even if
they are, it's easy in a consolidated diff to identify what
has changed due to UTF-8.

I'd propose that the editors look over the draft, and send
some proposed text for changes to the list, but that we don't
burn another integer (because at the moment, the furnace is closed :-).

Regards,    Martin.