Once the desired printer has been located and installed, the end-user
   wants to print to that printer from normal applications using
   standard methods.  These normal applications include such programs as
   word processors, spreadsheets, data-base applications, WEB browsers,
   production printing applications, etc.  Additionally, the end-user
   may want to print a file already existing on the end-user's computer
   -- "simple push".  In addition to printing from an application and
   simple push, the end-user needs to have the ability to submit a print
   job by reference.  Printing by reference is defined to mean as
   submitting a job by providing a reference to an existing document.
   The reference, a URI, will be resolved before the actual print
   process occurs.  Submitting a job by reference relieves the user from
   downloading the document from the remote server and then sending it
   via IPP to the printer.  This saves both time and network bandwidth.

   Some means shall be provided to determine if the format of a job
   matches the capability of the printer.  This can be done by one of
   the following (all of which are outside of scope of the IPP
   protocol):

      - the end-user selects the correct printer driver
      - the printer automatically selects the proper interpreter
      - the end-user uses some other manual procedure.

   A standard action shall be defined should the job's requirements not
   match the capabilities of the printer.

   Because the end-user does not want to know the details of the
   underlying printing process, the protocol must support job-to-printer
   capability matching (all implementations are not necessarily required
   to implement this function.)  This matching capability requires
   knowing both the printer's capabilities and attributes and those
   capabilities and attributes required by the job.  Actions taken when
   a print job requires capabilities or attributes that are not
   available on the printer vary and can include but are not limited to:

   - rejecting the print job
   - redirecting the print job to another printer (Not in V1.0)
   - printing the job, accepting differences in the appearance

   Print jobs will also be submitted by background or batch applications
   without human intervention.

   End-users need the ability to set certain print job parameters at the
   time the job is submitted.  These parameters include but are not
   limited to:




 
RFC 2567             Internet Printing Design Goals           April 1999


   - number of copies
   - single or two sided printing
   - finishing
   - job priority

3.1.5. Viewing the status of a submitted print job.

   After a job has been submitted to a printer, the end-user needs a way
   to view the status of that job (i.e. job waiting, job printing, job
   done) and to determine where the job is in the print queue.

   In addition to the need to inquire about the status of a print job,
   automatic notification of the completion of that job is also
   required.

   Notification means are not defined by the protocol but the protocol
   must provide a means of enabling and disabling the notification.

3.1.6. Canceling a Print Job

   While a job is waiting to be printed or has been started but not yet
   completed, the original creator/submitter of the print job (i.e. the
   end-user) shall be able to cancel the job entirely (job is waiting)
   or the remaining portion of it (job is printing.)  Altering the print
   job itself is not a V1.0 design goal.

3.2. OPERATOR (NOT REQUIRED FOR V1.0)

   An operator of a printer accepting jobs through the Internet is one
   of the roles in which humans act.  The operator has the
   responsibility of monitoring the status of the printer as well as
   managing and controlling the jobs at the device.  These
   responsibilities include but are not limited to the replenishing of
   supplies (ink, toner, paper, etc.), the clearing of minor errors
   (paper jams, etc.) and the re-prioritization of end-user jobs.
   Operator wants and needs will not be addressed by V1.0 of the
   protocol.

   The wants and needs of the operator include all those of the end-user
   but may include additional privileges.  For example, an operator may
   be able to view all print jobs on a printer while the end-user might
   only be able to see his own jobs.

3.2.1. Alerting.

   One of the required operator functions is having the ability to