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.