While I agree that in principle lengths should be unsigned, the reason that
we picked to make them signed, was because some programming languages on
some platforms have problems with unsigned when the full unsigned integer
range is used. The compares don't work. So we opted to effectively give up
half the range and make the data type of the length field be a SIGNED SHORT
(16-bit) INTEGER.
Remember our old AD's saying: In theory there is no difference between
theory and practice, but in practice there is.
Tom
P.S. The folks who insisted on a binary format at the pivotal IPP San Diego
meeting when we made this decision will remain nameless :-)
-----Original Message-----
From: pmoore at netreon.com [mailto:pmoore at netreon.com]
Sent: Monday, January 29, 2001 13:24
To: Carl Kugler
Cc: Michael Sweet; Mike Bartman; ipp at pwg.org; ifx at pwg.org
Subject: Re: IFX> Re: IPP> New data types
gosh - you are right - the length is signed - thats not right - lengths
should
be unsigned.
"Carl Kugler" <kugler at us.ibm.com> on 01/29/2001 01:08:29 PM
To: Michael Sweet <mike at easysw.com>
cc: Paul Moore/AUCO/US at AUCO, Mike Bartman <bartman at process.com>,
ipp at pwg.org,
ifx at pwg.org
Subject: Re: IFX> Re: IPP> New data types
Since the length field is SIGNED-SHORT (2BYTE). I think it probably only
goes up to 32,767.
-Carl
Michael Sweet <mike at easysw.com>@pwg.org on 01/29/2001 01:17:24 PM
Sent by: owner-ifx at pwg.org
To: pmoore at netreon.com
cc: Mike Bartman <bartman at process.com>, ipp at pwg.org, ifx at pwg.org
Subject: IFX> Re: IPP> New data types
pmoore at netreon.com wrote:
>> I had had similar thoughts (I was imagining Text, BigText (16-bit)
> and HugeText (32-bit))
> ...
Except that the length field in the current IPP encoding only
supports values up to 65535 octets in length...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com