IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL

IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu May 22 18:28:12 EDT 1997


> From SISAACSON at novell.com Thu May 22 08:45:15 1997
> 
> Bob,
> 
> > 4.4.2.2 successful-attribute-ignored (IPP)
> >  Is this really necessary, especially if the returned attributes indicate
> >  which are unsupported.  This is a case of half-full versus half-empty.
> 
> I thought this was necessary since a Printer could implement the "should"
> best-effort case and simple ignore some attributes that were not supported. 
> It still prints, the printer is just trying to tell the client some possibly
> interesting info.


No, this was for GetAttributes and GetJobs which should report OK and
return unsupported attributes with a value of 'unsupported'.


In the case of print submission with "should-honor-attributes", the
server hopes it can honor, but it doesn't know what it will fail on.


> 
> > 
> > 4.4.4.6 server-error-write-fault (IPP)
> > 
> > I would expect the client to block on a write and that it wouldn't
> > clear until the server got enough space to write the data.
> 
> But there are cases where the Printer experiences a disk-full condition but
> still has enough buffer space to return a response packet.  I wouldn't get
> rid of it.


Maybe once we have the protocol better defined we will know whether this
is a possibility, but I would expect the printer wait for the disk-full
condition to go away. Then it would write the data and return a response
of success. If it returns this message instead, then the client has to
go into some recovery mode which makes the client more complicated.


> 
> 
> 
> > 
> > 4.4.4.7 server-error-too-many-documents-in-job (IPP)
> > 
> >  With the changes from last week where all Printers support PrintJob
> >  (1 document per job) and some support CreateJob/SendJobData (1 or
> >  more documents per job), this message isn't needed. The error
> >  server-error-operation-not-implemented handles this problem instead.
> > 
> 
> Is there a case where the Printer supports both Print-Job and
> Create-Job/Send-Job-Data but for some reason has an implementation limit of
> N documents per job?  It would be helpful to have this error code for that
> case.  We have no way (nor do I propose) to query the printer to find out
> how many multiple docs per job it supports.
> 


The PrintJob has a limit of one document. CreateJob/SendJobData should
have no job limit. It may have an octet-limit for an entire job.



More information about the Ipp mailing list