Re: Troubles with UTF-8

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

 



----- Original Message -----
From: "Masataka Ohta" <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx>
To: "Tom.Petch" <sisyphus@xxxxxxxxxxxxxx>
Cc: "Ned Freed" <ned.freed@xxxxxxxxxxx>; "ietf" <ietf@xxxxxxxx>
Sent: Wednesday, December 28, 2005 2:05 PM
Subject: Re: Troubles with UTF-8


> Tom.Petch wrote:
>
> > The Unicode data I am thinking of may have come from an upper layer protocol
and
> > needs to be passed transparently (as with an error or hello message,
identity
> > even); it may or may not already be NUL-terminated (ever had that security
> > foul-up where some userid/password are entered/stored NUL-terminated and
some
> > are not?) - hence I see the need to terminate the string in some other way,
or
> > to escape or in some other way transfer encode (parts of) the string.  I
looked
> > at existing RFC, found many different approaches, all viable but none that
> > really said to me 'this is good engineering, this is best practice'.  Hence,
> > floating the issue to see if there were any better ones out there. I think
not,
> > which is of itself worth knowing.
>
> You can do nothing.
>
> That problem is that Unicode is stateful with complex and
> indefinitely long term states, which is a lot worse than
> properly profiled ISO 2022 such as that of RFC1468, which
> is the character encoding most widely used for Japanese.
>
> Unicode is not even finite state, which means some pattern
> matching and normalization problems are hard or insolvable.
>
> OTOH, if you start from scratch, you can have encoding with
> a lot shorter term and finite states.
>
> Masataka Ohta
>
You've lost me here.  I don't understand the use of state in the context of
Unicode (perhaps because I have just been reading about stateless serverside TLS
resumption:-).  I suspect that in the context of transporting
param = value
with value being supplied by an upper layer protocol in UTF-8 then it is not a
concern.  There is always base64 or quoted-printable:-(

Tom Petch


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]