Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

From: Michael Sweet <[email-masked]>
Date: Tue, 03 Sep 2013 08:10:00 -0400

Daniel,

Thank you for your comments.  My initial responses are inline below...

On Aug 30, 2013, at 1:27 AM, Manchala, Daniel <[email-masked]> wrote:
> 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”). 

No objection, although we need a proper keyword value.  'account-info-conflicting'?

> Likewise, add a new associated status-code to section 8.2 "client-error-account-information-incompatible" (or something of that nature).

In this case I'd prefer to keep using client-error-conflicting-attributes and have the printer return the job-account-id and job-accounting-user-id attributes in the unsupported attributes group.

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

We've very specifically avoided currency or payment identifiers since a) many members, including Xerox, have indicated that payment processing is done separately from the printer and b) we have no facility in IPP to express currency values or other complex, fractional types.

What would be the purpose of adding this when the printer-charge-info and printer-charge-info-uri values provide localized resources that can be displayed by the Client? Since the Client never has to have knowledge of how transactions are processed (just whether the printer needs transactional information), and since job-account-id will not (or at least SHOULD NOT) be a credit card number or other direct payment identifier, I don't see the point in telling the Client anything other than "I need a job-account-id from the user."

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

No objection to adding this.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Tue, 03 Sep 2013 08:57:50 -0400

Daniel,

Thank you for the additional comments.  My initial responses are inline below, but as a general comment I think we don't need to mirror every IPP attribute in the SM - some things are a side-effect of the protocol or of targeting specific markets/use cases.

On Aug 30, 2013, at 12:57 PM, Manchala, Daniel <[email-masked]> wrote:
> 
> 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.

In actual implementation, the existing attribute (with multiple queries) was too inefficient.  This attribute has been widely implemented in IPP printers since 2010.

My preference is to reject this request.

> 2)      “pdf-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.

In actual implementation, the existing attribute (with multiple queries) was too inefficient.  This attribute has been widely implemented in IPP printers since 2010.

My preference is to reject this request.

(For reference, a Client might need to determine supported file formats and sizes in order to determine which format to send to the Printer.  And certain file formats such as PWG Raster generally are streamed on both the Client and Printer so the job-k-octets-supported value is MAX vs. some smaller value for PDF or JPEG)

> 3)      “pdf-versions-supported” should be dropped in favor of the existing “document-format-details-supported” (“document-format” and “document-format-version” members).

"document-format-version" is localized text, "document-format-details-supported" is a list of member attributes supported by the "document-format-details" attribute, and "document-format-version-supported" is a list of all of the localized version strings that are supported for all formats that is optionally filtered by document-format when you do a Get-Printer-Attributes request.

Since there is no way to register localized text values, filtering those values with multiple Get-Printer-Attributes requests is inefficient, and this attribute is supported by most IPP+PDF printers since 2010, my preference is to reject this request.

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

These attributes have been widely implemented since 2010.  And as I've noted before doing multiple Get-Printer-Attributes requests is really inefficient.

My preference is to reject this request.

> 5)      “printer-dns-sd-name” should be applicable to any service.  The name should be changed to “dns-sd-name”.

With a few exceptions, we prefix all Printer Description attributes that are not associated with Job/Document Template attributes with "printer-".  And since DNS-SD is a *service* discovery protocol, not a device discovery protocol, I don't think dropping the "printer-" prefix or using an alternate prefix like "device-" makes sense.  And FWIW CUPS has implemented "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 IIRC).

> Scaling should not be print specific.

IPP = Internet Printing Protocol, so we are necessarily focused on printing. And as has been done in the past, SM can (and probably should) map print-scaling to ScalingMode (or whatever), just as print-quality is mapped to Quality, printer-resolution => Resolution, etc.

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

FWIW, CUPS previously supported two other attributes for scaling in the past - "scaling" (scale to a percentage of the media size) and "natural-scaling" (scale to a percentage of the document size).  This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations and implementation issues.  (BTW, we only ever supported symmetric scaling: scaling-width == scaling-height)

I *can* see the use case for copy - copy this hardcopy document and enlarge to 200% - but for print the 99% use case is "enlarge this document/image to fit/fill these (media) dimensions".   In many cases there are no (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no meaning.  However, you can always say "fit/fill the document data on the requested media".

Also, the current Scaling group in SM is not part of the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (under <service>DocumentProcessing).

My preference is to reject this request.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Tue, 10 Sep 2013 03:44:19 +0000

Michael,

Some more comments on IPP Transaction Based Printing Extensions:

Section 8.1 job-state-reasons, it would be good to specify that 'account-authorization-failed' also means invalid job-accounting-user-id and/or 'job-account-id' were not valid.  Right now it says:

'account-authorization-failed': The "job-authorization-uri" attribute was not supplied
the value supplied is not valid, or the value supplied has expired.

The same is true for section 8.2 Status Codes.  client-error-account-authorization-failed (0x41F) should also refer to invalid job-accounting-user-id and job-account-id were supplied.  Right now it says:

client-error-account-authorization-failed (0x41F); The print job creation request is
missing the "job-authorization-uri" operation attribute, the supplied value is not valid,
or the value supplied has expired.

Xerox is ok with adding the keyword to  "job-state-reason" = 'account-info-conflicting' in Section 8.1 and 'client-error-conflicting-attributes' to Section 8.2.

Thanks,
Daniel.

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, September 03, 2013 5:10 AM
To: Manchala, Daniel
Cc: [email-masked]; Ira Mcdonald; Paul Tykodi
Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

Daniel,

On Aug 30, 2013, at 1:27 AM, Manchala, Daniel <[email-masked]<mailto:[email-masked]>> wrote:
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").

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

---

From: "Manchala, Daniel" <[email-masked]>
Date: Fri, 13 Sep 2013 01:33:55 +0000

I think I must have missed my point by including payment schemes (keywords like 'visa' or 'paypal') into "job-account-type". It was my attempt to generalize the scenario.

Here is what I meant: Xerox has been using some accounting systems for several years that used "job-account-id" and a "job-account-group-id" or "job-account-general-id" to charge it to a specific group or a general account. The purpose of the request to add "job-account-type" by which a user can select or specify either 'general' or 'group' or 'none', for proper accounting purposes.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Fri, 13 Sep 2013 20:45:59 +0000

Michael,

The Semantic Model defines Scaling thus:

Scaling (complex) {
                ScalingHeight (range of int)
                ScalingWeight (range of int)
                AutoScaleMode (keyword) //values of 'auto, 'fit', 'auto-fit', 'fill' and 'none'; SM to change replace boolean with keyword.
                }

Why don't we translate this into IPP as follows?:

print-scaling(collection) {
                scaling-height(integer(1:100)) //expressed as a percentage.
                scaling-width(integer(1:100))
                auto-scale-mode(type2 keyword) //values of 'auto', 'auto-fit', 'fit', 'fill' and 'none'
                }

Thanks,
Daniel.

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"

---

From: Michael Sweet <[email-masked]>
Date: Fri, 13 Sep 2013 21:01:13 -0400

Daniel,

The "print-scaling" attribute, as defined in the IPP Transaction-Based Printing Extensions, is already implemented in shipping IPP printers and CUPS since v1.6.

*If* we wanted percent scaling (which I do not support), we'd need to define a print-scaling-col attribute or something (a different name).  However, since SM Scaling is not part of Print (it is specifically used for hardcopy documents) I don't think we need to tie IPP to it. And I think we will have a hard time agreeing on what the percentages are based on - remember CUPS tried both percent-of-output-media and percent-of-input-document and neither worked well.

On Sep 13, 2013, at 4:45 PM, Manchala, Daniel <[email-masked]> wrote:

>                 AutoScaleMode (keyword) //values of ‘auto, ‘fit’, ‘auto-fit’, ‘fill’ and ‘none’; SM to change replace boolean with keyword.
>                 }
>  
> Why don’t we translate this into IPP as follows?:
>  
>                 auto-scale-mode(type2 keyword) //values of ‘auto’, ‘auto-fit’, ‘fit’, ‘fill’ and ‘none’
>                 }
>  
>  
> Thanks,
> Daniel.
>  
>  
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

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

Daniel,

On Sep 12, 2013, at 9:33 PM, Manchala, Daniel <[email-masked]> wrote:
> I think I must have missed my point by including payment schemes (keywords like ‘visa’ or ‘paypal’) into “job-account-type”. It was my attempt to generalize the scenario.

If the purpose is to provide the user interface with something other than a generic "Account ID" label, then the printer-strings-uri attribute is already able to do that.

If you actually want to support different types of account numbers and expose that choice to the client (which can supply 1 of N different account ID types), then *maybe* we could add OPTIONAL job-account-type (type3 keyword | name(MAX)), job-account-type-default (type3 keyword | name(MAX)), and job-account-type-supported (1setOf (type3 keyword | name(MAX))) attributes. But I can't see us including trademarked names as keywords, nor would I like to have a generic "credit-card" keyword since "job-account-id" by itself is insufficient to authorize credit card transactions.

Having implemented a couple credit card processing systems over the years for my prior business, I know we would need a lot more attributes and a lot of security language to conform to the current PCI security standards council requirements. And those standards change over time and vary subtly between countries.

Here in Canada, for example, "chip" cards are common and require entry of a PIN or passcode during credit card processing, and there are special rules for ongoing service charges. In the US, few cards use security chips and instead merchants collect 3 or 4 digit security codes (CVC/CVV) to use in conjunction with the card number, expiration date, and card holder name, and there are specific rules for their use that are slightly different than in Canada.

> Here is what I meant: Xerox has been using some accounting systems for several years that used “job-account-id” and a “job-account-group-id” or “job-account-general-id” to charge it to a specific group or a general account. The purpose of the request to add “job-account-type” by which a user can select or specify either ‘general’ or ‘group’ or ‘none’, for proper accounting purposes.

I would have no objection to adding job-account-type-xxx as I have outlined above with the keyword values 'none', 'general', and 'group'.  Vendors can provide their own keywords or (localized) name values for credit cards if they choose, but we won't standardize those keywords because of the reasons I have outlined above.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Wed, 18 Sep 2013 00:05:18 +0000

Michael,

Thank you for your quick feedback.  Your suggestion to add the following OPTIONAL attributes is appreciated by Xerox:

job-account-type(type3 keyword | name(MAX))
job-account-type-default(type3 keyword | name(MAX))
job-account-type-supported(1setOf (type3 keyword | name(MAX))

with some of the keywords like: 'none', 'general' and 'group'.

Vendors may wish to supply their own keywords for credit cards if they choose to, but PWG will not standardize them.

Daniel.

From: Michael Sweet [mailto:[email-masked]]
Sent: Monday, September 16, 2013 10:24 AM
To: Manchala, Daniel
Cc: [email-masked]; Ira McDonald; Paul Tykodi
Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

Daniel,

On Sep 12, 2013, at 9:33 PM, Manchala, Daniel <[email-masked]<mailto:[email-masked]>> wrote:
I think I must have missed my point by including payment schemes (keywords like 'visa' or 'paypal') into "job-account-type". It was my attempt to generalize the scenario.