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
document.
>
>Bob Herriot
>
>