IPP> PRO - A value-type field for the Protocol Spec

IPP> PRO - A value-type field for the Protocol Spec

IPP> PRO - A value-type field for the Protocol Spec

Tom Hastings hastings at cp10.es.xerox.com
Fri Jun 6 14:08:46 EDT 1997

At 15:43 06/05/97 PDT, Robert Herriot wrote:
>> From szilles at Adobe.COM Wed Jun  4 19:31:54 1997
>> It is proposed that there be a registry of value types. The first two
>> entries in that registry would be (zero is reserved)
>> 1: Unicode string in UTF8 encoding (as specified in the draft)
>> 2: list of values (here the length of the value field determines how
>>    many values are present. The length, however, is not the number of
>>    value, but the number of bytes consumed by the values.

I think that we should assign data type codes to each of the
current IPP Model data type keywrods and then add just one more data
type keyword: attributeSet to the Model and assign it a code as well.

>Do you think that we should specify the encoding of a list of values?
>For example, it could be zero or more nested values, that is:
>    value-type value-length value

No, lets keep our current agreements on encoding a single multiple-valued
attribute, using the zero-length attribute-name approach.  We need to
build on the agreements we've reach, rather than keep changing them.

>Also, are you  suggesting that we define some other types, such as integer
>or date, even if these are represented as a Unicode string in UTF-8.

I suggest that we don't add redundant represenetations.  Lets have only
one way to encode each data type.  

We might want to encode the current Model octetString data type as binary
only, but the rest should remain in UTF-8.  Having the data type code
would let us have a binary representation, but only for the very few
data types where there isn't a good UTF-8 representation.

We could also choose to encode the current Model dateTime data type
as binary, using some existing standard.  That might help with the
localization of dates and times and the time zone problem.  However,
if there is a standard for the representation of dates and time
in printable form, including time zones, I suggest that we stick
with printable dateTime.  Lets avoid binary in the procotol as much as possible
and use binary only when there isn't a simple and useful UTF-8 representation.

BTW - the dateTime data type needs to cite such a standard in either
the Model document or at least the protocol document.  I perfer the Model

>Bob Herriot

More information about the Ipp mailing list