Subject: [Ltru] Re: Solving the UTF-8 problem

From: "Doug Ewell" <[email-masked]>
Date: Sat, 7 Jul 2007 11:27:19 -0700

John Cowan <cowan at ccil dot org> wrote:

>>> I still think the email argument is the compelling one.  We *will* 
>>> have corruption no matter what.
>>
>> 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.

I really think we can overcome this is we aren't limited to both (1) 
plain-text e-mail and (2) sending IANA something that they can paste in 
with no processing.

I suggested sending the payload as an attachment, and Randy suggested 
that IANA might be able to handle some amount of post-processing.  We 
might combine approaches: we could send hex-escaped ASCII in the body of 
the message *and* attach a file containing the same content in UTF-8, 
and leave it up to them to either post-process the hex escapes or just 
use the attachment.  (Or we could ask them which they prefer.)  Either 
way, there will be no shortage of eagle eyes double-checking the new 
Registry to make sure they did it right.

--
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, 7 Jul 2007 18:40:39 -0700

I agree with that. I also think it would be a better process for IANA to
incorporate the changes and post a "beta" for a quick review, only
afterwards updating the official version. Without that, there is always the
possibility of them posting a file, and someone using that file before the
error is discovered. Witness the jv/jw goofup, where a typo became ensconced
in implementations.

Mark

-- 
Mark

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 7 Jul 2007 19:17:54 -0700

Mark Davis wrote:

> I also think it would be a better process for IANA to incorporate the 
> changes and post a "beta" for a quick review, only afterwards updating 
> the official version. Without that, there is always the possibility of 
> them posting a file, and someone using that file before the error is 
> discovered. Witness the jv/jw goofup, where a typo became ensconced in 
> implementations.

Will people have the patience to wait a few days before going ahead and 
using the beta as if it were official?  If they don't, that eliminates 
the whole benefit of having a beta.

---

From: Addison Phillips <[email-masked]>
Date: Sun, 08 Jul 2007 08:03:29 -0700

> the whole benefit of having a beta.

The only fields that can contain non-ASCII characters are Description 
and Comment fields. Neither has a stability guarantee and neither is 
normative. A data encoding error, furthermore, would probably cause 
implementation failures rather than lead to enshrinement of mojibake.

A beta period for the registry is critical for stabilized fields. 
However, I note that IANA wouldn't ever change a record sent by the LSR 
(we require whole records to be sent) and we introduced a "beta-period" 
for the final record in 4646bis. An additional beta for the registry 
seems like gilding the lily.

Addison

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

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 8 Jul 2007 19:30:44 -0700

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

> However, I note that IANA wouldn't ever change a record sent by the 
> LSR (we require whole records to be sent) and we introduced a 
> "beta-period" for the final record in 4646bis. An additional beta for 
> the registry seems like gilding the lily.

I agree that we want to avoid adding excessive process to our interface 
with IANA.  Some other RFCs that specify IANA registries spend much less 
time describing the exact steps than we do.

To play devil's advocate, however, there were four IANA-originated 
errors in the LSR during 2006, and I'm sure the rest of us agree with 
Mark that we want to avoid this.

It might be noted that the jv/jw problem in ISO 639 went unnoticed for 
several years, greatly increasing the likelihood that implementers would 
use the wrong code element.  Right now there are quite a few people 
watching the updates to the LSR, which should prevent any errors from 
lingering for long.  But there's no way to guarantee that this situation 
will continue.

---

From: John Cowan <[email-masked]>
Date: Sun, 8 Jul 2007 22:44:37 -0400

> time describing the exact steps than we do.

AFAIK none of those registries are machine-processable, however;
they are meant to be read by human implementers.

-- 
John Cowan  <[email-masked]>  http://ccil.org/~cowan
Micropayment advocates mistakenly believe that efficient allocation of
resources is the purpose of markets.  Efficiency is a byproduct of market
systems, not their goal.  The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources.  --Clay Shirkey

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 8 Jul 2007 21:39:13 -0700

Hi -

As a technical contributor...

> From: "John Cowan" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, July 08, 2007 7:44 PM
> Subject: Re: [Ltru] Re: Solving the UTF-8 problem
...
> they are meant to be read by human implementers.
...

Though not necessarily specified as machine-processable, some
have long been used by some development tools as though they were.
For example, http://www.iana.org/assignments/enterprise-numbers,
simply due to the infeasibility of processing its content by hand, has
been treated as machine readable, even though the documentation
of the format (which has evolved over the years) is just some comments
in the file itself.

Ltru has gone to unusual lengths to formalize both processes and
formats.

Randy