[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Let's go forward with IDNA and UTF-8



--On 01-05-26 12.09 +0200 Dan <Dan.Oscarsson@trab.se> wrote:

> Or do those favoring IDNA not think UTF-8 is at all acceptable?
> Or do those favoring UTF-8 not accept ACE to be used for backward
> compatibility?

Whether UTF-8 can be used in protocols or not have very much to do with the
ability for a client and server to be able to signal the use of this
character set instead of what is in use today (explicitly or implicitly
specified).

This depends on each and every protocol if this is possible or not, and if
the signalling fails (i.e. client announces UTF-8 and server says "foo?")
what then should the client do?

We have in the SMTP world some experience with Quoted Printable as you say
Dan, where the ESMTP extension for 8bitmime is used, and as most (I claim)
servers can handle 8bit message bodies today AND that signalling works we
don't see as much Quoted-Printable now as we did some 5 years ago. And IF
the quoted printable reach the client, most clients know how to decode it.


Yes, I am one of the persons which think we definitly need an ACE encoding
for the reasons above. We can not add negotiations in all protocols, and we
can not change the middleboxes (application layer firwalls and proxies)
which many times are upgraded the least amount of times, and server
software which the enduser doesn't have control over.

So, an encoding which is non-destructable which makes it clear that all
information which the sender send comes to the recipient regardless of
protocol is a good thing.

        paf