attachment

<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.