Hi Mike,
I like taking "Paid" out of the title of this spec - you're right about the
wider scope.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Thu, Jun 20, 2013 at 4:15 PM, Michael Sweet <msweet at apple.com> wrote:
> Glen,
>> On Jun 10, 2013, at 5:47 PM, "Petrie, Glen" <glen.petrie at eitc.epson.com>
> wrote:
>> Hello
>> As with the IPP FaxOut, I have unable to review the IPP Paid Printing
> document until now.
>> Overall, I was concerned that "Extension for Paid Printing" is being
> extended through 'finishings" while the concept of "paid-printing" is a
> business or commerce notion and not a finishing step.
>> Well, no. While I did dump some additional finishing values in there
> since they are generally needed when specifying print intent to a
> third-party print service, they aren't the focus and I have no problem
> pulling those out and introducing them with the additions for the
> finishings-col attribute.
>> The core meat of the spec is in defining a simple transactional model for
> printing. The transactions may be for money, for internal
> accounting/metrics, for output tracking. Perhaps the name should be "IPP
> Transactional Printing Extensions", but we aren't just talking
> print-for-cash here. The rest is supporting material to ensure that common
> use cases can be satisfied.
>> While I need to study the document in more detail; how does the current
> paid-printing model support a print job where a set of differently priced
> transform service are needed.
>> The extensions don't expose the itemized pricing, but rather address a
> more general "I want to print X, here are my credentials, please
> pre-approve me". As in prior trips down this path, we are avoiding any
> notion of describing currency, pricing, or billing, but instead are
> focusing on the transaction itself: how can a client say "I want to do the
> following work", get back an authorization for that work (generally tied to
> the supplied job ticket and document format in some way, e.g., a hash), and
> then submit a job and documents associated with that authorization?
>> Having recently reviewed the PrintTalk specification of JDF; this is an
> interesting model to explore for PWG (independent of just IPP)
> "paid-prinitng" for several reason. Instead of modifying/extending JDF,
> PrintTalk wraps JDF in a business transaction or commerce transaction.
> With it's relatively simple set API calls it supports very complex set of
> operations ranging from Quoting, Notations, etc.; again with out
> modification to the print job JDF. PrintTalk can itemize items and provide
> a quote for each item. And, finally, PrintTalk is already widely used and
> deployed.
>> This is interesting for a number of reasons; first, until you mentioned it
> I had never heard of PrintTalk - if it is widely implemented and supported,
> there is very little mention of it online (I see a bunch of press releases
> in 2003 and 2004, and possibly one company - PrintTalk Ltd) and nobody
> (that I can find) selling or developing PrintTalk-based solutions. I also
> found this article:
>>http://www.piworld.com/article/in-search-printtalk-jdf-mcilroy-18362/1>> I'm happy to be wrong here, but so far I'm not sold on PrintTalk.
>> But moreover, in looking at the specification it is far beyond the scope
> of anything we have ever wanted to do, collectively, for paid printing
> services. It deals with currencies and itemized costs. It passes around
> credit card information and other payment information. And it looks to be a
> fairly complicated service of its own separate from the actual print
> service.
>> That said, the basics of the RFQ/Quote and PurchaseOrder/Invoice pairs
> match the model outlined in the IPP Paid Printing Extensions, and in fact
> an IPP Printer *could* very easily map the IPP Job Ticket, user, and
> authorization information to PrintTalk transactions. But that would be an
> implementation detail that I would not want to enforce in this document.
>> PWG could create a version of PrintTalk, called IppPrintTalk (or
> PrintTalkIpp or PrintTalkPwg) by simply replacing JDF with PWG (or IPP) in
> the existing PrintTalk specification. Now IPP stays the same while
> extending an existing "paid printing" API and implementations which could
> be applied to any PWG model (Cloud?)
>> Except that we don't have the data types for currencies, don't have the
> security model for handling credit cards, and IMHO don't want to limit
> ourselves to the cash-based reprographic work order process that PrintTalk
> appears to be based on.
>> Other comments on the specification itself
>> The attribute "printer-charge-info-uri" is not defined in this document
> (perhaps somewhere else). But my concern that a discussion about how a
> User is associated with a paid (payment) service is out-of-scope.
>> printer-charge-info-uri was defined in JPS3. It and printer-charge-info
> tell the Client that the Printer is not "free" (for some value or
> definition of "free").
>> As for not associating a User with a payment service, that is what the
> job-authorization-uri is for. It identifies the pairing of the user to a
> job ticket and document (format). The Client gets an authorization URI by
> sending a Validate-Job operation (RFQ in PrintTalk), whose response (the
> Quote in PrintTalk) contains the authorization URI (Authorization in
> PrintTalk). The Client then sends a job creation request
> (Create-Job/Print-Job/Print-URI) with the authorization (PurchaseOrder in
> PrintTalk), and the transaction information (charges) is recorded in the
> Job's job-charge-info and other Job Description attributes (the Invoice in
> PrintTalk).
>> Section 4.2 PIN/Passcode Printing
> Section 4.3 Release Printing
> I believe these sections are out-of-scope for paid-printing since
> there is not "payment" requirement for these types of printing
> functionalities.
>> PIN printing is often enforced by an organization's infrastructure, and
> metrics are collected as jobs are released at the printer using the PIN.
> This allows for correct departmental billing of services (no billing if
> nobody enters the PIN at the printer...)
>> Similarly, release printing may involve different costs depending on which
> printer is used at print time. Again, existing solutions collect metrics
> and perform billing at time-of-print.
>> Both may or may not be combined with a transaction identifier (the
> job-authorization-uri) but are still considered transactions and often
> involve some form of payment.
>> Section 4.5 Job Review
> I believe this section is out-of-scope for paid-printing. "Job
> Review" could be applied to any print scenario and not specific relevance
> to paid-printing. In fact, if a User submits a print job for (100,000
> copies) and payment is confirmed; then print the 100,000 copies.
>> This section came out of WG discussions (that you were present at) of
> likely things that a Printer or authorization service might do before
> providing an authorization URI or printing a Job. While it certainly is
> not limited to paid or transactional printing, Job Review *is* IMHO
> specifically relevant to it (companies have been sued for facilitating the
> mistakes made by their customers) and we have never held ourselves to a
> standard of "must be only needed for the specific use cases or title of the
> document".
>> (Mike I assume specification are written to American English notation so
> 100.000 should be 100,000?)
>> Looks like a comma in my copy of the document, but I can just remove it
> (100000) or use words for a really big value ("print one million copies of
> a brochure") for clarity.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130621/e815f63e/attachment-0001.html>