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.
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."
-------------- next part --------------
An HTML attachment was scrubbed...