Some additional comments from Xerox:
IPP Attributes should be document format independent. Existing semantics should be used when they exist or corrected when additional semantics are required.
1) “jpeg-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.
a. Note that IPP attribute coloring can be used to obtain document format specific values when required.
2) “pdf-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.
3) “pdf-versions-supported” should be dropped in favor of the existing “document-format-details-supported” (“document-format” and “document-format-version” members).
4) “jpeg-x-dimension-supported” and “jpeg-y-dimension-supported” should apply to any image format. The names should be changed to “max-image-x-dimension-supported” and “max-image -x-dimension-supported”.
5) “printer-dns-sd-name” should be applicable to any service. The name should be changed to “dns-sd-name”.
Scaling should not be print specific. The PWG Semantic Model already defined a collection for scaling (i.e., “scaling”). Apparently we didn’t quite get it right. The current definition allows for explicit scaling (i.e., “scaling-height” and “scaling-width”) or a boolean for “auto-scaling”. The explicit scaling member should be kept. The Boolean “auto-scaling” should be deprecating and an attribute with a unique name (e.g., “auto-scale-mode”) should replace it with the semantics defined for “print-scaling”
Daniel.
________________________________
From: ipp-bounces at pwg.org [ipp-bounces at pwg.org] on behalf of Manchala, Daniel [Daniel.Manchala at xerox.com]
Sent: Thursday, August 29, 2013 10:27 PM
To: ipp at pwg.org; blueroofmusic at gmail.com; ptykodi at tykodi.com; msweet at apple.com
Subject: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments
Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has the following comments.
Xerox would like to add a new "job-state-reason" to section 8.1 “job-state-reasons (1setOf type2 keyword)”: “incompatible account-information”. This account (“job-account-id”) is not associated with the user (“job-accounting-user-id”).
Likewise, add a new associated status-code to section 8.2 "client-error-account-information-incompatible" (or something of that nature).
Add an attribute: “job-account-type (type2 keyword | name(MAX))<Job Template>” along with “job-account-type-supported(1setOf type2 keyword | 1setOf name(MAX))<Printer>” and “job-account-type-default(type2 keyword | name(MAX))<Printer>”. The keywords initially can start with ‘none’, ‘general’, ‘group’ or ‘visa-card’, ‘master-card’, ‘paypal’,’bit-coin’, ‘micro-mint’, ‘cash’, ‘credit-account’, etc., . The preference is to use keywords as it aids in the internationalization.
Add the conformance requirement in IPP: Transaction Based Printing, as an addendum to PWG 5100.3-2001 IPP:Production Printing Attributes – Set 1, Section 7 as follows:
If the Printer supports “job-accounting-user-id” then the Printer MUST support “job-account-id”.
If the Printer supports “job-account-id” then the Printer MUST support “job-account-type”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130830/15fed053/attachment.html>