[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

Manchala, Daniel Daniel.Manchala at xerox.com
Fri Aug 30 16:57:50 UTC 2013


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”




More information about the sm3 mailing list