attachment-0001
<div dir="ltr"><div>Hi Mike,<br><br></div><div>I like taking "Paid" out of the title of this spec - you're right about the wider scope.<br><br></div><div>Cheers,<br></div><div>- Ira<br><br></div></div><div class="gmail_extra">
<br clear="all"><div>Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>
<div></div><div></div><div></div><div></div></div>
<br><br><div class="gmail_quote">On Thu, Jun 20, 2013 at 4:15 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Glen,<div><br><div><div class="im"><div>On Jun 10, 2013, at 5:47 PM, "Petrie, Glen" <<a href="mailto:glen.petrie@eitc.epson.com" target="_blank">glen.petrie@eitc.epson.com</a>> wrote:</div>
<blockquote type="cite">
<div>
<p><font>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><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><div class="im"><blockquote type="cite"><div><p><font>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><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>
<div class="im"><blockquote type="cite"><div><p><font>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><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" target="_blank">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>
<div class="im"><blockquote type="cite"><div><p><font> 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><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>
<div class="im"><blockquote type="cite"><div><p><font>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></div>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><div class="im"><blockquote type="cite"><div><p><font>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><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><div class="im"><blockquote type="cite">
<div><p><font>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><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>
<div class="im"><blockquote type="cite"><div><p><font>
(Mike I assume specification are written to American English notation so 100.000 should be 100,000?)<br></font></p></div></blockquote></div><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 style="border-collapse:separate;font-family:'Andale Mono';border-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><div style="word-wrap:break-word">
_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><div class="im"><br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div></div>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></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.