If indeed this is the agreement, then I believe that the model document
needs to be fixed. In section 3.1.2.2 it clearly says that if there is an
error, a SET of unsupported attributes is returned. While one could
interpret this to mean the SET may contain just one attribute, I
I interpreted it to mean the entire set must be returned. I hope there
aren't too many more gotcha's like this one - - it could kill
interoperability.
By the way, I think returning just the first unsupported attribute
is extremely unfriendly and not the right answer.
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 07/22/97 07:25
AM ---------------------------
Robert.Herriot @ Eng.Sun.COM
07/21/97 08:20 PM
Please respond to Robert.Herriot at Eng.Sun.COM @ internet
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet
cc:
Subject: Re: IPP> Review of Model Document - unsupported job template
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.
Bob Herriot
> 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>
> <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>
> <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.
>>>>>