In Section 8.2, you state that "a server may ignore those attributes
that it does not support". The IPP group decided at the San Diego
meeting that a server must reject a job if it contains an attribute
that it does not recognize or if it contains an attribute value that it does
not support. We wanted to make sure that a client would get what
what was requested with no surprises.
What do you think?
Bob Herriot
> From paulmo@microsoft.com Sun Jun 8 17:28:15 1997
> From: Paul Moore <paulmo@microsoft.com>
> To: "'Robert.Herriot@Eng.Sun.COM'" <Robert.Herriot@Eng>, ipp@pwg.org
> Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document
> Date: Sun, 8 Jun 1997 17:26:46 -0700
> X-Priority: 3
> X-Mailer: Internet Mail Service (5.0.1458.30)
> Content-Length: 2688
> X-Lines: 60
>
> By Reference:
> I do not think that all the issues of print by reference have been
> thought out yet. You are right that an attribute could be added, but
> this is fundamentally different from the existing print operation - I
> would make it a separate operation. A print server can ignore any
> attribute and still be able to print, this is not the case for a
> document URL attribute. I would have "PrintThis" and "PrintThat" as two
> distinct operations that a server may or may not implement.
>
> Attribute names:
> Whatever seems correct to the group.(I was merely advising against
> calling something 'Job&%Copies#*@')
>
> 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.
>
> SetOf:
> I remember the discussion - I was not sure what was agreed. I am neutral
> on the topic - whatever the consensus is, I will put in.
>
> > -----Original Message-----
> > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> > Sent: Friday, June 06, 1997 7:59 PM
> > To: Paul Moore; ipp@pwg.org
> > Subject: IPP>MOD PRO Comments on Microsofts IPP document
> >
> >
> > I have comments about a few parts which differ from the IPP documents.
> > I hope that we can resolve these differences to keep compatibility.
> >
> > Section 2.4. You state that you don't support print by reference, but
> > your Rationale suggests you would do it the same we have proposed,
> > namely
> > with a job attribute which contains the document URI. Am I missing
> > something? So, do you plan to support print by reference with a
> > client
> > supplied URI?
> >
> > Section 7.4. I would suggest that you look at the new wording for
> > defining the characters allowed for an attribute name. The document
> > should be posted by Monday. It limits names to the ASCII letters,
> > ASCII digits, ASCII hyphen and ASCII underscore.
> >
> > 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.
> >
> > Section 8 (Setof): We decided at the San Diego meeting that a set of
> > values would be represented by a sequence of attributes in which
> > all but the first attribute name would be of 0 length. Your
> > description
> > omits the statement about 0 length.
>