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:msweet at apple.com]
Sent: Monday, September 16, 2013 10:24 AM
To: Manchala, Daniel
Cc: ipp at pwg.org; 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 <Daniel.Manchala at xerox.com<mailto:Daniel.Manchala at xerox.com>> 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.
>>>>>
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."
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130918/9841f39e/attachment.html>