attachment-0001
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Glen,<div><br><div><div>On Jun 10, 2013, at 5:47 PM, "Petrie, Glen" <<a href="mailto:glen.petrie@eitc.epson.com">glen.petrie@eitc.epson.com</a>> wrote:</div><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="MS Exchange Server version 6.5.7638.1">
<title>Comments and Idea for paid printing</title>
<div>
<!-- Converted from text/plain format --><p><font size="2">Hello<br>
<br>
As with the IPP FaxOut, I have unable to review the IPP Paid Printing document until now.<br>
<br>
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.</font></p></div></blockquote><div dir="auto">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.</div><div><br></div>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.</div><div><blockquote type="cite"><div><p><font size="2">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. <br></font></p></div></blockquote><div>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?</div><blockquote type="cite"><div><p><font size="2">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.</font></p></div></blockquote><div>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:</div><div><br></div><div> <a href="http://www.piworld.com/article/in-search-printtalk-jdf-mcilroy-18362/1">http://www.piworld.com/article/in-search-printtalk-jdf-mcilroy-18362/1</a></div><div><br></div><div>I'm happy to be wrong here, but so far I'm not sold on PrintTalk.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><blockquote type="cite"><div><p><font size="2"> 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?)<br></font></p></div></blockquote><div>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.</div><blockquote type="cite"><div><p><font size="2">Other comments on the specification itself<br>
<br>
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.</font></p></div></blockquote>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").</div><div><br></div><div>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).</div><div><blockquote type="cite"><div><p><font size="2">Section 4.2 PIN/Passcode Printing<br>
Section 4.3 Release Printing<br>
I believe these sections are out-of-scope for paid-printing since there is not "payment" requirement for these types of printing functionalities.<br></font></p></div></blockquote><div>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...)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><blockquote type="cite"><div><p><font size="2">Section 4.5 Job Review<br>
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. </font></p></div></blockquote><div>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".</div><blockquote type="cite"><div><p><font size="2">
(Mike I assume specification are written to American English notation so 100.000 should be 100,000?)<br></font></p></div></blockquote><div>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.</div><div><br></div></div><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>