From owner-freebsd-hackers Tue Jan 20 11:35:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27996 for hackers-outgoing; Tue, 20 Jan 1998 11:35:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27985 for ; Tue, 20 Jan 1998 11:35:34 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA25144; Tue, 20 Jan 1998 12:35:34 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd025070; Tue Jan 20 12:35:25 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA27183; Tue, 20 Jan 1998 12:35:21 -0700 (MST) From: Terry Lambert Message-Id: <199801201935.MAA27183@usr04.primenet.com> Subject: Re: Wide characters on tcp connections To: louie@TransSys.COM (Louis A. Mamakos) Date: Tue, 20 Jan 1998 19:35:21 +0000 (GMT) Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG In-Reply-To: <199801200313.WAA20726@whizzo.TransSys.COM> from "Louis A. Mamakos" at Jan 19, 98 10:13:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > 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.