[IPP] IPP use best practices - a call for feedback

[IPP] IPP use best practices - a call for feedback

Ira McDonald blueroofmusic at gmail.com
Sun Nov 25 18:14:01 UTC 2012


Hi Smith,

Thanks for this good start on IPP best practices.

BTW - your plaintext resend lost section 1 w/ the explanation
of the ranking codes, adding a bit of confusion.  It would be
a good idea to post a plaintext version in the directory:

ftp://ftp.pwg.org/pub/pwg/ipp/whitepaper
- (informal documents, before a project has been chartered)

I didn't schedule discussion of this document for tomorrow's
joint IPP/Cloud meeting, because we already probably have
too much content (Pete's Cloud Print operations, review of
both Cloud and IPP slides for F2F).  I suggest that we could
spend some time on this during the IPP session at the F2F.

My initial high-level response is that we should try to align
the recommendations w/ the new reality of IPP Everywhere
(e.g., the characterization of Bonjour as local subnet only
conflicts w/ the mandatory support for DNS-SD in the IPP
Everywhere spec).

Generally, I think we need to recommend best practices for
*future* IPP printers and clients.

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
Temporary Cabin *** 2012 only *** 906-494-2523



On Tue, Nov 20, 2012 at 6:13 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:

> My apologies - I always forget that this reflector will downsample to
> plain text, and I had cut-and-pasted HTML in to my original posting.  Below
> is a plain text rendering.
>
> Smith
>
>
>
> On 2012-11-20, at 3:13 PM, "Kennedy, Smith (Wireless Architect)" <
> smith.kennedy at hp.com>
>  wrote:
>
> > Greetings,
> >
> > I had an action item from two conference calls ago to post to the
> reflector on the subject of IPP protocol "best practices", to enumerate
> options for how IPP can be used in order to satisfy all or a core set of
> use cases.  The goal we discussed was to come to consensus and then publish
> the consensus so that the best practices can be adopted as widely as
> possible, to help encourage a high quality user experience and best
> performance.
> >
> > All of the IPP specifications describe what can be done with IPP, but we
> all know that is broad, and with the exception of RFC 3196, nothing has
> been done to examine how best to use the toolset available via IPP.  As
> well all know, just because something *can* be done doesn't mean it
> *should* be done.  Guidance on how to best use IPP would benefit the IPP
> user community as a whole.
> >
> > I included the descriptions I have been working on below in-line so that
> feedback could be provided directly via email rather than by editing a
> document.  If there are suggestions on how to best review these (perhaps
> one per email thread), let me know and I will re-factor / re-post.
> >
> > Cheers,
> > Smith
> >
> > /**
> >    Smith Kennedy
> >    Hewlett-Packard Co.
> >    smith.kennedy at hp.com<mailto:smith.kennedy at hp.com>
> > */
> >
>
> ---------------------------------------------------------------------
>
> 2. Use Case Descriptions
>
> ---------------------------------------------------------------------
>
>
> 2.1. Create a relationship with a particular printer
>
> ------------
>
> You can’t print to a printer if you cannot establish a connection to
> it. Historically, connecting to a printer to establish a
> "relationship" with it meant identifying a printer and then creating
> a persistent local records and resources for that printer
> relationship with your system’s print spooler. This was called a
> "print queue", and it involved binding drivers to create the
> relationships needed to communicate at the different levels, and then
> keeping record of that set of relationships so that it could be
> re-used at a later time. The set of printers or other devices the
> user’s system might encounter was relatively small and fairly static.
>
> More recent re-thinking of this relationship between client and
> printer has resulted in more "dynamic" relationship creation, where
> universal drivers can interrogate a device hosting a print service
> using a standardized protocol solution stack, and using that
> dynamically ascertain and update print service attributes. In this
> paradigm, a "persistent" print service record is more like a Web
> browser bookmark.
>
> Both paradigms still require a method of identifying the target
> devices. That can be done using dynamic service discovery protocols
> where the services respond to discovery requests, or explicitly by
> name (host name or raw IPv4/IPv6 address).
>
> 2.1.1. Discover and select a printer via a discovery protocol
>
> Discovery protocols are used to identify instances of print services
> or printers by searching the network for service types or device
> types. This helps the user by making it so that they don’t need to do
> a physical survey of devices' addresses.
>
> Regardless of the actual discovery protocol used, the APIs driving
> the protocols generally can be used in either a synchronous or
> asynchronous fashion. Unfortunately, many legacy software systems (as
> well as developers) are accustomed to the synchronous model, which is
> easily identified by the presence of a "refresh button". The
> synchronous model is not as user friendly as the asynchronous model,
> but it is somewhat easier to write programs in a synchronous way than
> an asynchronous way.
>
> Options
>
>   * MEH:
>
>       o Perform network discovery with a synchronous API
>
>           # Show progress bar
>           # Discovery.Start()
>           # sleep(X) where X
>           # Discovery.Stop()
>       o Present the results of the discovery
>       o "Refresh" button restarts process
>
>           # Why this is bad:
>
>               * list can be stale
>               * it isn’t "live"
>               * "Reset" button is unnecessary and is a crutch
>       o User selects a printer and presses "Continue" or equivalent
>   * BETTER:
>
>       o Perform network discovery with an asynchronous API
>
>           # Show List UI widget
>           # Discovery.Start() with a callback
>           # callback is called when discovery responses (add or
>             remove) are received
>       o User selects a printer and presses "Continue" or equivalent
>
>           # Discovery.Stop()
>
> 2.1.2. Select a printer via user providing a DNS hostname or raw IPv4
> / IPv6 address
>
> In some cases a discovery protocol is either not adequate or
> unnecessary. Examples of when this use case is encountered include
> pre-published names or addresses, and also situations where the
> target device is not on the local link. (DNS-SD and WS-Discovery are
> generally used for link-local discovery, though wide-area variants as
> well as LDAP systems may also be used, but are frequently not for
> various reasons.)
>
> For each of these options below, the assumption is that the client
> has received an address string, and wishes to connect to the
>
> Options
>
>   * BAD:
>
>       o Let each printer model make up its own path, and depend on
>         some other protocol to get the resource path
>
>           # IPP has no defined standard mechanism to enumerate the
>             Printer objects' resource paths
>   * MEH:
>
>       o IPP Get-Printer-Attributes with printer-uri set to a URI that
>         was manually entered by the user
>
>           # "ipp" URI scheme could be used to encode the hostname and
>             the resource path
>           # Having the user enter the URI exposes too many details to
>             the user, including the detail about the fact that IPP is
>             actually beiing used. Users need not be aware of which
>             print protocol is being used.
>   * GOOD:
>
>       o IPP Get-Printer-Attributes with printer-uri set to a
>         well-known Printer resource path
>
>           # "/ipp/print"
>   * BETTER:
>
>       o IPP Get-Printer-Attributes with printer-uri set to "/"
>       o examine the "printer-uri-supported" attribute; use the first
>         URI in the list
>       o IPP Get-Printer-Attributes with printer-uri set to first URI
>   * BEST:
>
>       o IPP Get-Printers operation
>
>           # YET TO BE DEFINED - COMING WITH SYSTEM CONTROL SERVICE
>           # Is this really going to be better?
>
>
> 2.2. Get printer options to populate a print dialog (activity between
> doing "File→Print" and presenting the print dialog UI)
>
> ------------
>
> Once a printer has been identified, it is necessary for the print
> system to understand the capabilities that the printer device’s print
> service provides. This includes what print job payload formats can be
> consumed by the print service, the available options and default
> choices, and so forth. It also includes other information about the
> device itself, such as its location.
>
> Options:
>
>   * SAD:
>
>       o Depend on a-priori knowledge about a particular model as a
>         way of listing options for the model of device identified as
>         the target
>
>           # Model specific print drivers fall in this bucket
>   * MEH:
>
>       o IPP Get-Printer-Attributes Operation
>
>           # request includes no printer attributes; only operation
>             attributes
>           # reply will contain the job template attributes for all
>             PDLs
>       o Client guesses at what attributes may work or not work for a
>         given PDL, or uses a-priori knowledge
>   * BETTER:
>
>       o IPP Get-Printer-Attributes Operation
>
>           # any specific attributes?
>       o Process results; decide on a PDL
>       o IPP Get-Printer-Attributes Operation
>
>           # request includes the document-format attribute with value
>             specifying the chosen PDL
>           # reply will contain the job template attributes
>             appropriately filtered ("colored") for that particular
>             document-format
>
>
> 2.3. Check constraints between presented options
>
> ------------
>
> Printer features and options are presented typically in a print
> dialog. Some of these have states that have relationships with other
> options' states, where one cannot be in a particular state if another
> one is too. These are known as constraints, and they must be
> calculated any time the state of a control changes state. There are
> various ways that this can be done.
>
> Options:
>
>   * BAD:
>
>       o IPP Validate-Job
>
>           # Every time a control is changed, the client sends IPP
>             Validate-Job with attribute values corresponding to
>             current state of controls
>   * MEH:
>
>       o IPP Validate-Job
>
>           # when "Print" button is pressed, confirms the job creation
>             / submission will succeed (authentication, etc.)
>           # client depends on this operation to perform constraints
>             validation printer-side
>   * BETTER:
>
>       o IPP Get-Printer-Attributes
>
>           # device implements job-constraits-supported
>           # device implements job-resolvers-supported
>       o <Local processing of constraints>
>       o IPP Validate-Job
>
>           # when "Print" button is pressed, confirms the job creation
>             / submission will succeed (authentication, etc.)
>           # constraints validation already handled client-side
>
>
> 2.4. Submitting a Print Job
>
> ------------
>
> Once the user has decided on options, the print job is generated and
> ultimately made available to the printer in some fashion. There are
> several different ways that this may occur.
>
> 2.4.1. Submitting a print job "by value"
>
> This is the classical way that a print job is sent from the client to
> the print service: a job is created, and the job information and job
> payload content are sent by the client to the print service.
>
> Options:
>
>   * MEH:
>
>       o IPP Print-Job
>
>           # no pre-flighting
>           # the printer may reject it but only after it has been
>             transmitted in whole or in part.
>           # better to check ticket and content types first.
>   * GOOD:
>
>       o IPP Validate-Job
>
>           # pre-flights the job by validating the job attributes and
>             document type
>       o IPP Print-Job
>
>           # creates the job and sends the payload in one operation
>           # however, the Job object’s URI isn’t usually known until
>             the job transmission is complete
>           # doesn’t work well with flow-controlled (low-end) printers
>   * BETTER:
>
>       o IPP Validate-Job
>
>           # pre-flights the job by validating the job attributes and
>             document type
>       o IPP Create-Job
>
>           # returns immediately with the job URI for monitoring and
>             ticket processing status
>           # if there is a problem then Create-Job may fail the same
>             as Validate-Job would, but may not, which is why we do a
>             Validate-Job first (so that there isn’t a zombie job
>             there)
>       o IPP Send-Document
>
>           # payload transmission is de-coupled from the creation of
>             the job
>           # multiple documents can be sent to build up a compound job
>           # means that the client doesn’t have to be prepared for an
>             early HTTP response
>           # allows the job URI to be learned before job payload is
>             sent
>           # MUST check to see if value of
>             "multiple-document-jobs-supported" is "true", to see if
>             it is OK to do multiple Send-Document operations to the
>             same Job object.
>
> 2.4.2. Submitting a print job "by reference"
>
> This is a slightly different way that a print job is sent from the
> client to the print service: a job is created and made available for
> retrieval by the print service, and when the print job the job
> information and job payload content are sent by the client to the
> print service.
>
> Options:
>
>   * MEH:
>
>       o IPP Print-URI
>
>           # no pre-flighting
>           # the printer may reject it but only after it has been
>             transmitted in whole or in part.
>           # better to check ticket and content types first.
>   * GOOD:
>
>       o IPP Validate-Job
>
>           # pre-flights the job by validating the job attributes and
>             document type
>       o IPP Print-URI
>
>           # creates the job and sends a URL to where the payload can
>             be retrieved in one operation
>           # print service retrieves the payload file itself
>           # however, the Job object’s URI isn’t usually known until
>             the job transmission is complete
>           # doesn’t work well with flow-controlled (low-end) printers
>   * BETTER:
>
>       o IPP Validate-Job
>
>           # pre-flights the job by validating the job attributes and
>             document type
>       o IPP Create-Job
>
>           # returns immediately with the job URI for monitoring and
>             ticket processing status
>           # if there is a problem then Create-Job will fail the same
>             as Validate-Job would
>       o IPP Send-URI
>
>           # payload URI transmission is de-coupled from the creation
>             of the job
>           # means that the client doesn’t have to be prepared for an
>             early HTTP response
>           # allows the job URI to be learned before job payload is
>             sent
>
>
> 2.5. Monitoring print job status
>
> ------------
>
> While the print job is being processed, users may wish to know
> whether it is proceeding successfully, or whether there are
> conditions that they need to handle that are preventing processing
> from proceeding, such as a media jam, open covers, marking agents
> depleted, and so forth.
>
> Options:
>
>   * MEH:
>
>       o IPP Get-Printer-Attributes
>
>           # monitor the value of the printer-state attribute
>           # polling (lame)
>   * GOOD:
>
>       o IPP Get-Job-Attributes
>
>           # targets the specific job status
>           # may be more precise
>           # (need to see if job attributes will show printer issues
>             (top cover open, etc.) that block a job as well)
>           # polling (lame)
>   * BETTER:
>
>       o IPP Create-Job-Subscriptions
>
>           # asynchronous / long running queries for notifications
>             that don’t require polling
>
>
> 2.6. Canceling a print job
>
> ------------
>
> It may be that the user wants to terminate a job before it has been
> fully processed, for whatever reason. There are things that must be
> done to ensure that the state of the Job object has been decisively
> cleaned up by the client if the client is responsible for canceling
> the job. Clients leaving broken Job objects on the Print service is
> bad behavior.
>
> There is also a dependency between the options below and how the job
> was submitted. If Print-Job is used, but the document payload is not
> completely transmitted, then is a Job object even created? Is this
> true in all cases? Alternately, if Create-Job / Send-Document is
> used, and the Cancel-Job is sent during the Send-Document operation
> submission, then
>
> Options:
>
>   * BAD:
>
>       o Client stop sending data and close the connection
>
>           # Problem: The IPP Job Object may have been created and
>             still exist, and be in an indeterminate state. It should
>             be explicitly cleaned up by the client for best
>             performance and correctness.
>           # Question: Are there any realistic or theoretical
>             conditions under which a Print-Job operation does NOT
>             create a Job object?
>   * MEH:
>
>       o Client stops sending chunks but doesn’t close the connection
>         because it is expecting an IPP operation reply.
>       o IPP Cancel-Job operation request for the job via a second
>         connection, which for some printers could result in a PDL
>         interpreter hang because the last chunk sent didn’t stop on a
>         "statement" boundary
>
>           # But if the client stops with a zero length chunk then the
>             IPP stack will know that transport is complete
>           # Need to define a "magic chunk" that operates kind of like
>             an in-band inline Cancel-Job operation, to tell the PDL
>             interpreter that no more job payload chunks?
>   * GOOD:
>
>       o IPP Cancel-Job
>       o Client stops sending chunks and closes the connection
>   * BETTER:
>
>       o ???
>
>
> 2.7. Getting printer supplies status
>
> ------------
>
> Some administrative tasks, like checking consumables levels, are
> presented to end users in some cases, such as during print job status
> or in print dialogs. This is useful to end users and should be
> supported.
>
> Options:
>
>   * MEH:
>
>       o Don’t use IPP but use some proprietary protocol or
>         platform-specific extension to IPP
>
>           # The point is to use only IPP extensions based on open
>             standards (i.e. PWG standard) and this violates that core
>             principle
>   * GOOD:
>
>       o IPP Get-Printer-Attributes
>
>           # printer must implement JPS3 "printer-supply" attribute
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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/20121125/b3aea070/attachment-0001.html>


More information about the ipp mailing list