Subject: [IPP] Lexmark has reviewed the IPP Transaction-Based Printing Extensions specification and has one comment

From: Barry Cavill <[email-masked]>
Date: Fri, 13 Sep 2013 09:13:53 -0400

"The actual methods of measurement and limit enforcement" are considered
out-of-scope for the specification, which is fine.   However, perhaps there
should be a job-state-reason to indicate that the user's job is rejected
for a measurement other than limit enforcement... for example, the user
isn't authorized for color printing, or for printing on photo paper, or
some similar scenario.

-- 
Barry Cavill
Lexmark International
Phone (859) 232-5613    Bldg 082-2   [email-masked]
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 16 Sep 2013 14:20:13 -0400

Barry,

Thanks for your feedback.  Response below.

On Sep 13, 2013, at 9:13 AM, Barry Cavill <[email-masked]> wrote:
> "The actual methods of measurement and limit enforcement" are considered out-of-scope for the specification, which is fine.   However, perhaps there should be a job-state-reason to indicate that the user's job is rejected for a measurement other than limit enforcement... for example, the user isn't authorized for color printing, or for printing on photo paper, or some similar scenario.   

In general, such things would be detected when the job is submitted, however since we *do* define "job-state-reasons" keywords for many of the client-error-xxx status codes, how about the following additions?

    Status Code                                      "job-state-reasons" Keyword
    -----------------------------------------------  ----------------------------------
    client-error-attributes-or-values-not-supported  'unsupported-attributes-or-values'
    client-error-conflicting-attributes              'conflicting-attributes'

Unfortunately, we don't have a place to store the actual unsupported attributes and values after the response, but at least the client would know there was a problem and the "job-state-message" attribute could provide a localized reason with specifics...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Barry Cavill <[email-masked]>
Date: Thu, 19 Sep 2013 09:11:05 -0400

That sounds reasonable to us.

On Mon, Sep 16, 2013 at 2:20 PM, Michael Sweet <[email-masked]> wrote:

> In general, such things would be detected when the job is submitted,
> however since we *do* define "job-state-reasons" keywords for many of the
> client-error-xxx status codes, how about the following additions?
>
> Unfortunately, we don't have a place to store the actual unsupported
> attributes and values after the response, but at least the client would
> know there was a problem and the "job-state-message" attribute could
> provide a localized reason with specifics...
>