[IPP] Comments and Idea for paid printing

[IPP] Comments and Idea for paid printing

[IPP] Comments and Idea for paid printing

Ira McDonald blueroofmusic at gmail.com
Fri Jun 21 15:17:26 UTC 2013


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/blueroofmusic
http://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>


More information about the ipp mailing list