Subject: Re: IPP> Review of Model Document - unsupported job template

From: Roger K Debry <[email-masked]>
Date: Fri, 18 Jul 1997 17:19:32 -0400

> From [email-masked] Fri Jul 18 08:58:03 1997
>
>
> 1) When the job is rejected, shouldn't the error code say something
> like 'client-error-attribute-value-unsupported'? Otherwise it is not
> clear that the attribute itself is supported, but the supplied value is not.

We have one status-code for both 'attribute not supported' and 'attribute value
not supported' because a job could be rejected because both problems exist.
The collection of unsupported attributes returned specify that it is
the attribute that is unsupported by returning the attribute in the
response with a value of "unsupported".

<RKD> So how do you know it is the value that is unsupported?

---

From: [email-masked] (Robert Herriot)
Date: Fri, 18 Jul 1997 14:50:18 -0700

> From [email-masked] Fri Jul 18 14:33:31 1997
> 
  _________________________________
> response with a value of "unsupported".
                            ______________
> <RKD> So how do you know it is the value that is unsupported?

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.

---

From: Roger K Debry <[email-masked]>
Date: Mon, 21 Jul 1997 09:33:01 -0400

<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.

---

From: [email-masked] (Robert Herriot)
Date: Mon, 21 Jul 1997 14:26:38 -0700

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 [email-masked] Mon Jul 21 06:44:43 1997
>

---

From: Roger K Debry <[email-masked]>
Date: Tue, 22 Jul 1997 09:42:33 -0400

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: [email-masked]
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 [email-masked] @ internet

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet
cc:
Subject: Re: IPP> Review of Model Document - unsupported job template

Bob Herriot

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 22 Jul 1997 09:12:51 -0600

>>> Roger K Debry <[email-masked]> 07/21 7:33 AM >>>

Yes, this is what I understand.  I will try to fix the model document
language.

<RKD>
<RKD> as you suggest. 

The model document should say that if the Printer rejects the Job for
one or more unsupported attribute or value, then it MUST return at least
one of them in the 'unsupported attributes' output parameter.  It is not
optional to not return anything at all in addition to  the error code.
However, the notion of returning ALL unsupported attributes (if there are
more
than one) might be too burdensome for all implementations.  The model
document needs to say something like " the Printer SHOULD return all
unsupported attributes and values but if it is unable to do so, the Printer
MUST return at least one if there are more than one",

<RKD> How does the client know what's wrong

Thanks for the critical reading and feedback.

Scott