Date: Tue, 20 Jan 1998 19:35:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: louie@TransSys.COM (Louis A. Mamakos) Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG Subject: Re: Wide characters on tcp connections Message-ID: <199801201935.MAA27183@usr04.primenet.com> In-Reply-To: <199801200313.WAA20726@whizzo.TransSys.COM> from "Louis A. Mamakos" at Jan 19, 98 10:13:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The issue is one of stream synchronization. This is my main problem
> > with UTF over non-error-checked links. If you have an implicit value
> > boundry, then you are guaranteed a synchronized stream.
>
> Not applicable. TCP *is* an error checked link. Absent application
> implementation errors, you shouldn't get unscynchronized.
Uh, byte order?
> > Re: the FS example: a better example is to perhaps ask if a UNIX
> > FS has provisions for storing "wide characters" (or preferrably,
> > 16bit wchar_t values from ISO10646 aka Unicode) in *directory
> > entries* (the current answer is "no, namei is too stupid").
>
> Why is this a better example? It's not like we're trying to name
> transport endpoints with any sort of character strings; the issue
> is "awareness" of the underlying {transport,storage} mechansim.
>
> There's really no point in reimplementing a transport protocol given
> the literally thousands of man-hours of work by a lot of clever
> people over more than a decade to make TCP work well.
The question is "what is the network prepresentation of the byte values";
see the other part of this thread...
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801201935.MAA27183>