> From SISAACSON at novell.com Thu May 22 08:45:15 1997
>> > 18.104.22.168 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.
> > 22.214.171.124 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.
> > 126.96.36.199 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.