From owner-freebsd-hackers  Tue Jan 20 13:27:29 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA07123
          for hackers-outgoing; Tue, 20 Jan 1998 13:27:29 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07099
          for <hackers@FreeBSD.ORG>; Tue, 20 Jan 1998 13:27:11 -0800 (PST)
          (envelope-from tlambert@usr06.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id OAA17312;
	Tue, 20 Jan 1998 14:27:10 -0700 (MST)
Received: from usr06.primenet.com(206.165.6.206)
 via SMTP by smtp01.primenet.com, id smtpd017279; Tue Jan 20 14:27:03 1998
Received: (from tlambert@localhost)
	by usr06.primenet.com (8.8.5/8.8.5) id OAA27796;
	Tue, 20 Jan 1998 14:27:01 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199801202127.OAA27796@usr06.primenet.com>
Subject: Re: Wide characters on tcp connections
To: daniel_sobral@voga.com.br
Date: Tue, 20 Jan 1998 21:27:01 +0000 (GMT)
Cc: louie@TransSys.COM, hackers@FreeBSD.ORG
In-Reply-To: <83256592.0040388D.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Jan 20, 98 08:43:10 am
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

> As far as my question goes, that was not the issue. The issue is the
> existance, or not, standards for transporting wide characters over TCP, in
> a higher layer.

If a wchar_t is correctly interpreted as a 16 bit value, then I think
the answer is "yes".

For wchar_t data sent raw, I would say it should be htons/ntohs'ed.

For wchar_t data sent via SMB, I would say Intel byte order

For wchar_t data sent via RPC, I would say XDR (htons/ntohs'ed).

For wchar_t data sent via DCE/RPC, I would say "source host byte order
with byte order indication"... in other words, exactly what DCE/RPC
does for any short or long value.

FWIW, Unicode supports two code points for use in determining byte
order ("normal order" vs. "inverted order") and assumes 16 bits;
AFAIK, ISO10636 did not extend this in the compatability space to
account for the additional 32 bit word order possibilities.  This
is a good reason to treat wchar_t as a 16 bit value.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.