IPP>MOD PRO Comments on Microsofts IPP document

IPP>MOD PRO Comments on Microsofts IPP document

Robert Herriot Robert.Herriot at Eng.Sun.COM
Mon Jun 9 15:32:01 EDT 1997


I forgot to mention one other difference in your IPP document.  


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 at microsoft.com Sun Jun  8 17:28:15 1997
> From: Paul Moore <paulmo at microsoft.com>
> To: "'Robert.Herriot at Eng.Sun.COM'" <Robert.Herriot at Eng>, ipp at 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 at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
> > Sent:	Friday, June 06, 1997 7:59 PM
> > To:	Paul Moore; ipp at 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.
> 



More information about the Ipp mailing list