Subject: Re: IPP> PRO - A value-type field for the Protocol Spec proposal

From: Tom Hastings <[email-masked]>
Date: Fri, 6 Jun 1997 11:08:46 PDT

At 15:43 06/05/97 PDT, Robert Herriot wrote:
>
>> From [email-masked] 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
document.

>Bob Herriot

---

From: Randy Turner <[email-masked]>
Date: Fri, 06 Jun 1997 11:38:32 -0700

Prior to the San Diego meeting, I proposed using ASN.1 as a way to
specify the protocol. This was
to prevent us from having to "re-invent" the wheel with regards to our
protocol specification. The nice
thing about ASN.1 (and its companion BER) is that extensibility is
easily achieved and with more
flexibility than what has been proposed so far. I think Larry Masinter
brought up the fact that ASN.1
might be a better approach, and if extensibility and clarity of
specification is what is driving these
recent discussions, then I'm curious why we are striving so hard to
reinvent another way to do this.

Randy

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 09 Jun 1997 10:47:07 -0400

>>>>> "TH" == Tom Hastings <[email-masked]> writes:

TH> We could also choose to encode the current Model dateTime data type
TH> as binary, using some existing standard.  That might help with the
TH> localization of dates and times and the time zone problem.  However,
TH> if there is a standard for the representation of dates and time
TH> in printable form, including time zones, I suggest that we stick
TH> with printable dateTime.

  There is a very good ISO spec for representing date/time: ISO 8601;
  there is a page about it at:

    http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/