IPP Mail Archive: RE: IPP>MOD PRO Comments on Microsofts IPP document

RE: IPP>MOD PRO Comments on Microsofts IPP document

Robert Herriot (Robert.Herriot@Eng.Sun.COM)
Mon, 9 Jun 1997 17:11:35 -0700

> From paulmo@microsoft.com Mon Jun 9 16:49:30 1997
>
> I don't think having all values as text helps. Somebody said that they
> wanted to support structured types, a string does not do that. Also
> having things as text requires more specifications (are leading
> /trailing spaces allowed on a number for example?)

The IPP text representation doesn't have structured values, but it
does prescribe the representation for various types, such as integer,
date and text.

Issues like leading/trailing spaces are a lot easier to deal with than
having a client try to figure out whether to interpret the octets of an
unknown attribute as text or binary. I believe that we need to deal
with extensibility where a client may need to display attributes that
it doesn't understand.

Bob Herriot

>
> > -----Original Message-----
> > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> > Sent: Monday, June 09, 1997 3:32 PM
> > To: Robert.Herriot@Eng.Sun.COM; ipp@pwg.org; Paul Moore
> > Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document
> >
> > You said that you are neutral on the subject of a type byte. Does
> > that mean that if we have no type byte that you are willing to
> > have all values be represented by text? Currently, some of your
> > attributes are text and others are binary. That is a problem if
> > there is no type byte.
> >
> > It seems to me that having no type byte and having all values be
> > represented
> > by text is the simplest solution.
> >
> > Bob Herriot
> >
> > > From paulmo@microsoft.com Sun Jun 8 17:28:15 1997
> >
> > >
> > >
> > > Type byte:
> > > This was suggested to me already. I am neutral on the subject. I did
> > not
> > > make the change becuase it was not discussed in San Diego. There are
> > a
> > > few question I have on it which I would like to see discussed before
> > > finalising.
> > >
> > > >
> > > > Section 8. You define several different representations for
> > attribute
> > > > values: text, binary integers, binary boolean, binary keywords.
> > But
> > > > you don't include a field for value's type. This makes is hard
> > for
> > > > a client to know how to interpret and unknown attribute. I
> > think
> > > > the right solution is to keep the IPP solution where all values
> > are
> > > > text. Alternatively, we could all agree to add a one byte type
> > field
> > > > just before the value's length field.
> > > >
>