From owner-freebsd-hackers Mon Jan 19 19:14:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21748 for hackers-outgoing; Mon, 19 Jan 1998 19:14:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21720 for ; Mon, 19 Jan 1998 19:13:47 -0800 (PST) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id WAA20726; Mon, 19 Jan 1998 22:13:03 -0500 (EST) Message-Id: <199801200313.WAA20726@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Terry Lambert cc: daniel_sobral@voga.com.br, hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: Wide characters on tcp connections References: <199801191937.MAA05333@usr08.primenet.com> In-reply-to: Your message of "Mon, 19 Jan 1998 19:37:06 GMT." <199801191937.MAA05333@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jan 1998 22:13:02 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > > This is similar to asking if the UNIX filesystem has provisions > > > for storing "wide characters in files"; the FS doesn't care > > > what's inside it's files. > > > > Though that's technically right, one might feel the need for a standard if > > the files he writes are going to be read by other people's programs. Of > > course TCP, by itself, provides all support you need to send the > > characters, but ignoring the practical problems would be akin to keeping to > > IP (vs TCP or UDP) because that's all you _really_ need... > > 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. > 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. louie