The issue is whether a server returns with a rejected job all of the
attributes that caused the rejection or just the first one encountered.
We left this choice to the implementation because it is easier for a
server to reject a job when it first finds an error than to accumulate
these errors and wait until the end to reject the job and return all
errors. Some people felt strongly that we should not require an
implementation to have the complexity of returning all. Clearly, a
client can get all of them through an iterative process.
We made this decision at the June 17th meeting.
> From rdebry at us.ibm.com Mon Jul 21 06:44:43 1997
>> Perhaps, I wasn't sufficiently clear. The 'unsupported attributes'
> output parameter contains a list of rejected attributes. The printer
> takes attributes with unsupported values and puts them into the
> response with no change. The printer takes attributes that are not
> supported and puts them into the response with their value set to
> "unsupported" which in the protocol is an "out-of-band" value that
> works for any type. A printer may put all such attributes in the
> response, or only some of them. In other words, a Printer can
> accumulate all unsupported attributes before it rejects the job or it
> can reject the job immediately after it finds the first bad attribute.
>> <RKD> The document certainly does not say this! Let me
> <RKD> be sure I understand. Lets say that two attributes
> <RKD> are sent, one which is supported but its value is
> <RKD> not, and one which is unsupported:
> <RKD> o finishing = saddle-stitch (unsupported value)
> <RKD> o number-up = two (unsupported attribute)
> <RKD> If I understand correctly, the response would contain
> <RKD> the following unsupported attributes:
> <RKD> o finishing = saddle-stitch
> <RKD> o number-up = unsupported
> <RKD> Right?
> <RKD> I don't agree with it being optional for the printer
> <RKD> to return only a partial list of unsupported attributes
> <RKD> as you suggest. How does the client know what's wrong
> <RKD> if the Printer does not have to send back accurate
> <RKD> error information? If everyone else agrees with
> <RKD> this being optional then it should be made clear in
> <RKD> the document ... currently I don't believe it makes
> <RKD> this clear at all. I read it as saying the entire list
> <RKD> is sent back.