Thanks for the feedback. My responses inline as KC>>.
Keith
1) Is this really necessary, especially if the returned attributes indicate
which are unsupported. This is a case of half-full versus half-empty.
> 4.4.2.2 successful-attribute-ignored (IPP)
KC>> I agree since this can only now occur if an IPP application
KC>> specifies an unimplemented attribute on a Get-Attributes or
KC>> Get-Jobs operation in which case the application will check
KC>> the values and see a value of "unsupported" for the
KC>> unimplemented attributes. Good catch.
2) I'm not sure if this is a useful error, or even likely to happen.
>
> 4.4.4.5 server-error-printer-error (IPP)
>
> A printer error, such as a paper jam, occurs while the IPP Printer
> processes a Print-Job or Send-Data operation. The response shall contain
> the Job Status with the specific error and should contain a Message
> describing the error. An IPP application should check the Job Status
> in the response for the specific error.
KC>> This can only occur if an IPP Printer does not spool. I believe
KC>> this is a supported configuration. If this status code
KC>> is overkill for IPP 1.0, then let's remove it.
3) 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.
>
> 4.4.4.6 server-error-write-fault (IPP)
>
> A write error, such as a memory overflow (i.e. the document data
> exceeds the memory of the Printer) or a disk full condition, occurs
> while the IPP Printer processes a Print-Job or Send-Data operation.
KC>> Again, this is most likely to occur on an IPP Printer that does
KC>> not spool and the client times out. If this status is overkill,
KC>> for IPP 1.0 let's remove it.
4) 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.
>
> 4.4.4.7 server-error-too-many-documents-in-job (IPP)
>
KC>> I agree. Good catch.