Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3998

Internet Printing Protocol (IPP): Job and Printer Administrative Operations

Pages: 46
Proposed Standard
Errata
Part 2 of 3 – Pages 16 to 38
First   Prev   Next

Top   ToC   RFC3998 - Page 16   prevText

4. Definition of the Job Operations

All Job operations are directed at Job objects. A client MUST always supply some means to identify the Job object in order to select the correct target of the operation. That job identification MAY either be a single Job URI or a combination of a Printer URI and a Job ID. The IPP object implementation MUST support both forms of identification for every job. The Job Operations defined in this document are summarized in Table 4. Table 4. Job Operation Operation-Id Assignments Operation Name Operation-Id Brief description -------------------------------------------------------------------- Reprocess-Job 0x2C Creates a copy of a completed target job with a new Job ID and processes it. Cancel-Current- 0x2D Cancels the current job on the target Job Printer or the specified job if it is the current job.
Top   ToC   RFC3998 - Page 17
   Suspend-            0x2E      Suspends the current processing job on
   Current-Job                   the target Printer or the specified
                                 job if it is the current job, allowing
                                 other jobs to be processed instead.

   Resume-Job          0x2F      Resumes the suspended target job.

   Promote-Job         0x30      Promotes the pending target job to be
                                 next after the current job(s) complete.

   Schedule-Job-       0x31      Schedules the target job immediately
   After                         after the specified job, all other
                                 scheduling factors being equal.

4.1. Reprocess-Job Operation

This OPTIONAL operation is a create job operation that allows a client to re-process a copy of a job that had been retained in the queue after processing was completed, canceled, or aborted (see [RFC2911], section 4.3.7.2). This operation is the same as the Restart-Job operation (see [RFC2911], section 3.3.7), except that the Printer creates a new job that is a copy of the target job and the target job is unchanged. New values are assigned to the "job-uri" and "job-id" attributes. The new job's Job Description attributes that track job progress, such as "job-impressions-completed", "job- media-sheets-completed", and "job-k-octets-processed", are initialized to 0, as with any create job operation. The target job moves to the Job History after a suitable period, independent of whether one or more Reprocess-Job operations have been performed upon it. If the Set-Job-Attributes operation is supported, then the "job- hold-until" operation attribute MUST be supported with at least the 'indefinite' value, so that a client can modify the new job before it is scheduled for processing by using the Set-Job-Attributes operation. After modifying the job, the client can release the job for processing by using the Release-Job operation specifying the newly assigned "job-uri" or "job-id" for the new job.

4.2. Cancel-Current-Job Operation

This OPTIONAL operation allows a client to cancel the current job on the target Printer or the specified job if it is the current job on the Printer. See [RFC2911], section 3.3.3, for the semantics of canceling a job. Since a Job might already be marking by the time a Cancel-Current-Job is received, some media sheet pages might print before the job is actually terminated.
Top   ToC   RFC3998 - Page 18
   If the client does not supply a "job-id" operation attribute, the
   Printer MUST accept the request and cancel the current job if there
   is a current job in the 'processing' or 'processing-stopped' state;
   otherwise, it MUST reject the request and return the 'client-error-
   not-possible' status code.  If more than one job is in the
   'processing' or 'processing-stopped' state, the one that is marking
   is canceled, and the others are unaffected.

   Warning:  On a shared printer, there is a race condition.  Between
   the time when a user issues this operation and the time of its
   acceptance, the current job might change to a different job.  If the
   user or operator is authenticated to cancel the new job, the wrong
   job is canceled.  To prevent this race from canceling the wrong job,
   the client MAY supply the "job-id" operation attribute, which is
   checked against the current job's job-id.  If the job identified by
   the "job-id" attribute is not the current job on the Printer (i.e.,
   is not in the 'processing' or 'processing-stopped' state), the
   Printer MUST reject this operation and return the 'client-error-not-
   possible' status code.  Otherwise, the Printer cancels the specified
   job.

   Access Rights: The authenticated user (see [RFC2911], section 8.3)
   performing this operation must either be the job owner (as determined
   in the Job Creation operation) or an operator or administrator of the
   Printer object (see [RFC2911], sections 1 and 8.5).

   The Cancel-Current-Job Request and Cancel-Current-Job Response have
   the same attribute groups and attributes as does the Resume-Printer
   operation (see [RFC2911], section 3.2.8), including the new "job-
   message-from-operator" operation attribute (see section 6), with the
   addition of the following Group 1 Operation attribute in the request:

   "job-id" (integer(1:MAX)):
      The client OPTIONALLY supplies this Operation attribute to verify
      that the identified job is still the current job on the target
      Printer object.  The IPP object MUST support this operation
      attribute if it supports this operation.

4.3. Suspend and Resume Job Operations

This section defines the Suspend-Current-Job and Resume-Job operations. These operations allow an operator or user to suspend a job while it is processing, allowing other jobs to be processed, and to resume the suspended job at a later point without losing any of the output.
Top   ToC   RFC3998 - Page 19
   If either of these operations is supported, both MUST be supported.

   The Hold-Job and Release-Job operations ([RFC2911], section 3.3.5)
   are for holding and releasing held jobs, not suspending and resuming
   suspended jobs.

4.3.1. Suspend-Current-Job Operation

This OPTIONAL operation allows a client to stop the current job on the target Printer or the specified job if it is the current job on the Printer, to allow other jobs to be processed instead. The Printer moves the current job or the target job to the 'processing- stopped' state and sets the 'job-suspended' value (see section 9.1) in the job's "job-state-reasons" attribute and processes other jobs. If the client does not supply a "job-id" operation attribute, the Printer MUST accept the request and suspend the current job if there is a current job in the 'processing' or 'processing-stopped' state. Otherwise, it MUST reject the request and return the 'client-error- not-possible' status code. If more than one job is in the 'processing' or 'processing-stopped' state, all of them are suspended. Warning: On a shared printer, there is a race condition. Between the time when a user issues this operation and the time of its acceptance, the current job might change to a different job. If the user or operator is authenticated to suspend the new job, the wrong job is suspended. To prevent this race from pausing the wrong job, the client MAY supply the "job-id" operation attribute, which is checked against the current job's job-id. If the job identified by the "job-id" attribute is not the current job on the Printer (i.e., is not in the 'processing' or 'processing-stopped' state), the Printer MUST reject this operation and return the 'client-error-not- possible' status code. Otherwise, the Printer suspends the specified job and processed other jobs. The Printer MUST reject a Suspend-Current-Job request (and return the 'client-error-not-possible') for a job that has been suspended, i.e., for a job in the 'processing-stopped' state, with the 'job-suspended' value in its "job-state-reasons" attribute. Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be either the job owner (as determined in the Job Creation operation) or an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
Top   ToC   RFC3998 - Page 20
   The Suspend-Current-Job Request and Suspend-Current-Job Response have
   the same attribute groups and attributes as does the Pause-Printer
   operation (see [RFC2911], section 3.2.8 ), including the new "job-
   message-from-operator" operation attribute (see section 6), with the
   addition of the following Group 1 Operation attribute in the request:

   "job-id" (integer(1:MAX)):
      The client OPTIONALLY supplies this Operation attribute to verify
      that the identified job is still the current job on the target
      Printer object.  The IPP object MUST support this operation
      attribute if it supports this operation.

4.3.2. Resume-Job Operation

This OPTIONAL operation allows a client to resume the target job at the point where it was suspended. The Printer moves the target job to the 'pending' state and removes the 'job-suspended' value from the job's "job-state-reasons" attribute. If the target job is not in the 'processing-stopped' state, with the 'job-suspended' value in the job's "job-state-reasons" attribute, the Printer MUST reject the request and return the 'client-error-not- possible' status code, since the job was not suspended. Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be either the job owner (as determined in the Job Creation operation) or an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). The Resume-Job Request and Resume-Job Response have the same attribute groups and attributes as the Release-Job operation (see [RFC2911], section 3.3.6), including the new "job-message-from- operator" operation attribute (see section 6).

4.4. Job Scheduling Operations

This section defines jobs that allow an operator to control the scheduling of jobs.

4.4.1. Promote-Job Operation

This OPTIONAL operation allows a client to make the pending target job be processed next after the current job completes. This operation is especially useful in a production printing environment where the operator is involved in job scheduling.
Top   ToC   RFC3998 - Page 21
   If the target job is in the 'pending' state, this operation does not
   change the job's state but causes the job to be processed after the
   current job(s) complete.  If the target job is not in the 'pending'
   state, the Printer MUST reject the request and return the 'client-
   error-not-possible' status code.

   If the Printer implements the "job-priority" Job Template attribute
   (see [RFC2911], section 4.2.1), the Printer sets the job's "job-
   priority" to the highest value supported (so that the job will print
   before any of the other pending jobs).  The Printer returns the
   target job immediately after the current job(s) in a Get-Jobs
   response (see [RFC2911], section 3.2.6) for the 'not-completed' jobs.

   When the current job is completed, canceled, suspended (see section
   4.3.1), or aborted, the target of this operation is processed next.

   If a client issues this request (again) before the target of the
   operation of the original request started processing, the target of
   this new request is processed first.

   IPP is specified not to require queues for job scheduling, as there
   are other implementation techniques for scheduling multiple jobs,
   such as re-evaluating a criteria function for each job on a
   scheduling cycle.  However, if an implementation does implement
   queues for jobs, then the Promote-Job operation puts the specified
   job at the front of the queue.  A subsequent Promote-Job operation
   prior to the processing of the first job puts that specified job at
   the front of the queue, so that it is "in front" of the previously
   promoted job.

   Access Rights: The authenticated user (see [RFC2911], section 8.3)
   performing this operation must be an operator or administrator of the
   Printer object (see [RFC2911], sections 1 and 8.5).

   The Promote-Job Request and Promote-Job Response have the same
   attribute groups and attributes as does the Cancel-Job operation (see
   [RFC2911], section 3.3.3), including the new "job-message-from-
   operator" operation attribute (see section 6).

4.4.2. Schedule-Job-After Operation

This OPTIONAL operation allows a client to request that the Printer schedule the target job so that it will be processed immediately after the specified predecessor job, all other scheduling factors being equal. This operation is specially useful in a production printing environment where the operator is involved in job scheduling.
Top   ToC   RFC3998 - Page 22
   If the target job is in the 'pending' state, this operation does not
   change the job's state but causes the job to be processed after the
   preceding job completes.  The preceding job can be in the target
   'pending', 'processing', or 'processing-stopped' state.  If the
   target job is not in the 'pending' state, or if the predecessor job
   is not in the 'pending', 'processing', or 'processing-stopped' state,
   the Printer MUST reject the request, and it returns the 'client-
   error-not-possible' status code, as the job cannot have its position
   changed.

   If the Printer implements the "job-priority" Job Template attribute
   (see [RFC2911], section 4.2.1), the Printer sets the job's "job-
   priority" to that of the predecessor job (so that the job will print
   after the predecessor job).  The Printer returns the target job
   immediately after the predecessor in a Get-Jobs response (see
   [RFC2911], section 3.2.6) for the 'not-completed' jobs.

   When the predecessor job completes processing or is canceled or
   aborted while processing, the target of this operation is processed
   next.

   If the client does not supply a predecessor job, this operation has
   the same semantics as Promote-Job (see section 4.4).

   IPP is specified not to require queues for job scheduling, as there
   are other implementation techniques for scheduling multiple jobs,
   such as re-evaluating a criteria function for each job on a
   scheduling cycle.  However, if an implementation does implement
   queues for jobs, then the Schedule-Job-After operation puts the
   specified job immediately after the specified job in the queue.  A
   subsequent Schedule-Job-After operation specifying the same job will
   cause its target job to be placed after that job, even though it is
   between the first target job and the specified job.  For example,
   suppose the job queue consisted of jobs A, B, C, D, and E, in that
   order.  A Schedule-Job-After with job E as the target and B as the
   specified job would result in the following queue:  A, B, E, C, D.  A
   subsequent Schedule-Job-After with Job D as the target and B as the
   specified job would result in the following queue:  A, B, D, E, C.

   In other words, the link between the two jobs in a Schedule-Job-After
   operation is not retained; i.e., there is no attribute on either job
   that points to the other job as a result of this operation.

   Access Rights: The authenticated user (see [RFC2911], section 8.3)
   performing this operation must be an operator or administrator of the
   Printer object (see [RFC2911], sections 1 and 8.5).
Top   ToC   RFC3998 - Page 23
   The Schedule-Job-After Request have the same attribute groups and
   attributes as does the Cancel-Job operation (see [RFC2911], section
   3.3.3), plus the new "job-message-from-operator" operation attribute
   (see section 6).  In addition, the following operation attribute is
   defined:

   "predecessor-job-id":
      The client OPTIONALLY supplies this attribute.  The Printer MUST
      support it, if it supports this operation.  This attribute
      specifies the job after which the target job is to be processed.
      If the client omits this attribute, the Printer MUST process the
      target job next, i.e., after the current job, if there is one.

   The Schedule-Job-After Response has the same attribute groups,
   attributes, and status codes as does the Cancel-Job operation (see
   [RFC2911], section 3.3.3).  The following status codes have
   particular meaning for this operation:

   'client-error-not-possible' - The target job was not in the 'pending'
   state, or the predecessor job was not in the 'pending', 'processing',
   or 'processing-stopped' state.

   'client-error-not-found' - Either the target job or the predecessor
   job was not found.

5. Additional Status Codes

This section defines new status codes used by the operations defined in this document.

5.1. 'server-error-printer-is-deactivated' (0x050A)

The Printer has been deactivated by the Deactivate-Printer operation and is only accepting the Activate-Printer (see section 3.5.1), Get- Job-Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get- Xxxx operations. An operator can perform the Activate-Printer operation to allow the Printer to accept other operations.

6. Use of Operation Attributes That Are Messages from the Operator

This section summarizes the usage of the "printer-message-from- operator" and "job-message-from-operator" operation attributes [RFC3380] that set the corresponding Printer and Job Description attributes (see [RFC2911] for the definition of these). These operation attributes are defined for most of the Printer and Job operations that operators are likely to perform, respectively, so that operators can indicate the reasons for their actions.
Top   ToC   RFC3998 - Page 24
   Table 5 shows the operation attributes defined for use with the
   Printer Operations.

   Table 5.  Operation Attribute Support for Printer Operations

      Operation Attribute                 A      B
      ---------------------------------------------
      attributes-charset                 REQ    REQ
      attributes-natural-language        REQ    REQ
      printer-uri                        REQ    REQ
      requesting-user-name               REQ    REQ
      printer-message-from-operator      Note   OPT

      Legend:
      A: Get-Printer-Attributes, Set-Printer-Attributes
      B: All other Printer administrative operations, including, but
         not limited to, Pause-Printer, Pause-Printer-After-Current-
         Job, Resume-Printer, Hold-New-Jobs, Release-Held-New-Jobs,
         Purge-Jobs, Enable-Print, Disable-Printer, Restart-
         Printer, Shutdown-Printer, and Startup-Printer.
    REQ: REQUIRED for a Printer to support.
    OPT: OPTIONAL for a Printer to support; the Printer ignores the
         attribute if it is not supported.
   Note: According to [RFC3380], the Client MUST NOT supply the
         "printer-message-from-operator" operation attribute in a
         Get-Printer-Attributes or Set-Printer-Attributes operation;
         the Printer MUST ignore this operation attribute in these
         two operations.  Instead, when it is used by an
         operator, the client MUST supply the
         "printer-message-from-operator" as (one of the) explicit
         attributes being set on the Printer object with the
         Set-Printer-Attributes operation.
Top   ToC   RFC3998 - Page 25
   Table 6 shows the operation attributes defined for use with the Job
   operations.

   Table 6.  Operation Attribute Support for Job Operations

      Operation Attribute                 A     B     C     F
      ---------------------------------------------------------
      attributes-charset                 REQ   REQ   REQ   REQ
      attributes-natural-language        REQ   REQ   REQ   REQ
      printer-uri                        REQ   REQ   REQ   REQ
      job-uri                            REQ         REQ   REQ
      job-id                             REQ   REQ   REQ   REQ
      requesting-user-name               REQ   REQ   REQ   REQ
      job-message-from-operator          OPT   OPT   OPT   Note
      message**                          OPT   OPT   OPT   n/a
      job-hold-until                     n/a   n/a   OPT*  n/a

      Legend:
      A: Cancel-Job, Resume-Job, Restart-Job, Promote-Job, Schedule-Job-
         After
      B: Cancel-Current-Job, Suspend-Current-Job
      C: Hold-Job, Release-Job, Reprocess-Job
      F: Get-Job-Attributes, Set-Job-Attributes

    REQ; REQUIRED for a Printer to support.
    OPT: OPTIONAL for a Printer to support; the Printer ignores the
         attribute if it is supplied, but not supported.
    n/a: not applicable for use with the operation; the Printer ignores
         the attribute.
   Note: According to [RFC3380], the Client MUST NOT supply the "job-
         message-from-operator" operation attribute in a Get-Job-
         Attributes or Set-Job-Attributes operation; the Printer MUST
         ignore this operation attribute in these two operations.
         Instead, when used by an operator, the client MUST supply the
         "job-message-from-operator" as (one of the) explicit attributes
         being set on the Job object with the Set-Job-Attributes
         operation.
      *: The Printer MUST support the "job-hold-until" operation
         attribute if it supports the "job-hold-until" Job Template
         attribute.  For the Reprocess-Job operation, the client can
         hold the job and then modify the job before releasing it to
         be processed.
     **: In [RFC2911], the "message" operation attribute is defined to
         contain a message to the operator, but [RFC2911] does not
         define a Job Description attribute to store the message.
Top   ToC   RFC3998 - Page 26

7. New Printer Description Attributes

The following new Printer Description attributes are needed to support the new operations defined in this document and the concepts of Printer Fan-Out (see section 10).

7.1. subordinate-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports Subordinate Printers (see section 10) and contains the URIs of the immediate Subordinate Printer object(s) associated with this Printer object. Each Non-Leaf Printer object MUST support this Printer Description attribute. A Leaf Printer object either does not support the "subordinate-printers-supported" attribute or does so with the 'no-value' out-of-band value (see [RFC2911], section 4.1), depending on the implementation. The precise format of the Subordinate Printer URIs is implementation dependent (see section 10.4). If the Printer object does not have an associated Output Device, the Printer MAY automatically copy the value of the Subordinate Printer object's "printer-name" attribute to the Job object's "output- device-assigned" attribute (see [RFC2911], section 4.3.13). The "output-device-assigned" Job attribute identifies the Output Device to which the Printer object has assigned a job; for example, when a single Printer object is supporting Device Fan-Out or Printer Fan- Out.

7.2. parent-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports Subordinate Printers (see section 10) and contains the URI of the Non-Leaf printer object(s) for which this Printer object is the immediate Subordinate; i.e., this Printer's immediate "parent" or "parents". Each Subordinate Printer object MUST support this Printer Description attribute. A Printer that has no parents either does not support the "parent-printers-supported" attribute or does so with the 'no-value' out-of-band value (see [RFC2911], section 4.1), depending on the implementation.

8. Additional Values for the "printer-state-reasons" Printer Description Attribute

This section defines additional values for the "printer-state- reasons" Printer Description attribute.
Top   ToC   RFC3998 - Page 27

8.1. 'hold-new-jobs' Value

'hold-new-jobs': The operator has issued the Hold-New-Jobs operation (see section 3.3.1) or other means, but the output-device(s) are taking an appreciable time to stop. Later, when all output has stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer- state-reasons" attribute. This value MUST be supported if the Hold-New-Jobs operation is supported and the implementation takes significant time to pause a device in certain circumstances.

8.2. 'deactivated' Value

'deactivated': A client has issued a Deactivate-Printer operation for the Printer object (see section 3.4.1), and the Printer is in the process of becoming deactivated or has become deactivated. The Printer MUST reject all requests except for Activate-Printer, queries (Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so that partial job submission can be completed; see section 3.1.1), and then return the 'server-error-service-unavailable' status code.

9. Additional Values for the "job-state-reasons" Job Description Attribute

This section defines additional values for the "job-state-reasons" Job Description attribute.

9.1. 'job-suspended' Value

'job-suspended': While job processing has been suspended by the Suspend-Current-Job operation, other jobs can be processed on the Printer. The Job can be resumed with the Resume-Job operation, which removes this value.

10. Use of the Printer Object to Represent IPP Printer Fan-Out and IPP Printer Fan-In

This section defines how the Printer object MAY be used to represent IPP Printer Fan-Out and IPP Printer Fan-In. In Fan-Out, an IPP Printer is used to represent other IPP Printer objects. In Fan-In, several IPP Printer objects are used to represent another IPP Printer object.
Top   ToC   RFC3998 - Page 28

10.1. IPP Printer Fan-Out

The IPP/1.1 Model and Semantics introduces the semantic concept of an IPP Printer object that represents more than one Output Device (see [RFC2911], section 2.1). This concept is called "Output Device Fan- Out". However, with Fan-Out there was no way to represent the individual states of the Output Devices or to perform operations on a specific Output Device. This document generalizes the semantics of the Printer object to represent Subordinate Fan-Out Output Devices such as IPP Printer objects. This concept is called "Printer object Fan-Out". A Printer object that has a Subordinate Printer object is called a Non-Leaf Printer object. Thus, a Non-Leaf Printer object supports one or more Subordinate Printer objects in order to represent Printer object Fan-Out. A Printer object that does not have any Subordinate Printer objects is called a Leaf Printer object. Each Non-Leaf Printer object submits jobs to its immediate Subordinate Printers and otherwise controls the Subordinate Printers by using IPP or other protocols. Whether pending jobs are kept in the Non-Leaf Printer until a Subordinate Printer can accept them or are kept in the Subordinate Printers depends on implementation and/or configuration policy. Furthermore, a Subordinate Printer object MAY, in turn, have Subordinate Printer objects. Thus a Printer object can be both a Non-Leaf Printer and a Subordinate Printer. A Subordinate Printer object MUST be a conforming Printer object, so it MUST support all of the REQUIRED [RFC2911] operations and attributes. However, with access control, the Subordinate Printer MAY be configured so that end-user clients are not permitted to perform any operations (or just Get-Printer-Attributes) while one or more Non-Leaf Printer object(s) are permitted to perform any operation.

10.2. IPP Printer Fan-In

The IPP/1.1 Model and Semantics did not preclude the semantic concept of multiple IPP Printer objects that represent a single Output Device (see [RFC2911], section 2.1). However, there was no way for the client to determine whether there was a Fan-In configuration; nor was there a way to perform operations on the Subordinate device. This specification generalizes the semantics of the Printer object to allow several Non-Leaf IPP Printer objects to represent a single Subordinate Printer object. Thus a Non-Leaf Printer object MAY share a Subordinate Printer object with one or more other Non-Leaf Printer objects in order to represent IPP Printer Fan-In. As with Fan-Out (see section 10.1), when a Printer object is a Non- Leaf Printer, it MUST NOT have an associated Output Device. As with
Top   ToC   RFC3998 - Page 29
   Fan-Out, a Leaf Printer object has one or more associated Output
   Devices.  As with Fan-Out, the Non-Leaf Printer objects submit jobs
   to their Subordinate Printer objects and otherwise control the
   Subordinate Printer.  As with Fan-Out, whether pending jobs are kept
   in the Non-Leaf Printers until the Subordinate Printer can accept
   them or are kept in the Subordinate Printer depends on the
   implementation and/or configuration policy.

10.3. Printer Object Attributes Used to Represent Printer Fan-Out and Printer Fan-In

The following Printer Description attributes are defined to represent the relationship between Printer object(s) and their Subordinate Printer object(s): 1. "subordinate-printers-supported" (1setOf uri) - Contains the URI of the immediate Subordinate Printer object(s). 2. "parent-printers-supported (1setOf uri) - Contains the URI of the Non-Leaf printer object(s) for which this Printer object is the immediate Subordinate; i.e., this Printer's immediate "parent" or "parents".

10.4. Subordinate Printer URI

Each Subordinate Printer object has a URI used as the target of each operation on the Subordinate Printer. The means to configure URIs for Subordinate Printer objects is implementation-dependent, as are all URIs. However, there are two distinct approaches: a. When the implementation seeks to make sure that no operation on a Subordinate Printer object "sneaks by" the parent Printer object (or that no Subordinate Printer is fronting for a device that is not networked), the host part of the URI specifies the host of the parent Printer. Then the parent Printer object can easily reflect the state of the Subordinate Printer objects in the parent's Printer object state and state reasons as the operation passes "through" the parent Printer object. b. When the Subordinate Printer is networked and the implementation allows operations to go directly to the Subordinate Printer (with proper access control) without knowledge of the parent Printer object, the host part of the URI is different from the host part of the parent Printer object. In this a case, the parent Printer object MAY keep its "printer-state" and "printer-state-reasons" up to date, either by polling the Subordinate Printer object or by subscribing to events with the Subordinate Printer object (see [RFC3995] for
Top   ToC   RFC3998 - Page 30
         means to subscribe to event notification when the Subordinate
         Printer object supports IPP notification).  Alternatively, the
         parent Printer MAY wait until its "printer-state" and
         "printer-state-reasons" attributes are queried and then query
         all its Subordinate Printers in order to return the correct
         values.

10.5. Printer Object Attributes Used to Represent Output Device Fan-Out

Only Leaf IPP Printer objects are allowed to have one or more associated Output Devices. Each Leaf Printer object MAY support the "output-devices-supported" (1setOf name(127)) to indicate the user- friendly name(s) of the Output Device(s) that the Leaf Printer object represents. It is RECOMMENDED that each Leaf Printer object have only one associated Output Device, so that the individual Output Devices can be represented completely and controlled completely by clients. In other words, the Leaf Printer's "output-devices- supported" attribute SHOULD have only one value. Non-Leaf Printer MUST NOT have associated Output Devices. However, a Non-Leaf Printer SHOULD support an "output-devices-supported" (1setOf name(127)) Printer Description attribute that contains all the values of its immediate Subordinate Printers. As these Subordinate Printers MAY be Leaf or Non-Leaf, the same rules apply to them. Thus any Non-Leaf Printer SHOULD have an "output-devices-supported" (1setOf name(127)) attribute that contains all the values of the Output Devices associated with Leaf Printers of its complete sub-tree. When a configuration of Printers and Output Devices is added, moved, or changed, there can be moments when the tree structure is not consistent; i.e., times when a Non-Leaf Printer's "subordinate- printers-supported" does not agree with the Subordinate Printer's "parent-printers-supported". Therefore, the operator SHOULD first Deactivate all Printers being configured in this way, update all pointer attributes, and then reactivate them. A useful client tool would validate a tree structure before Activating the Printers involved.

10.6. Figures to Show All Possible Configurations

Figures 1, 2, and 3 are taken from [RFC2911] to show the configurations possible with IPP/1.0 and IPP/1.1 where all Printer objects are Leaf Printer objects. The remaining figures show additional configurations using Non-Leaf and Leaf Printer objects.
Top   ToC   RFC3998 - Page 31
   Legend:

   ----> indicates a network protocol with the direction of its requests

   ##### indicates a Printer object that is either
         embedded in an Output Device, or
         hosted in a server.
         The Printer object might or might not be capable
         of queuing/spooling.

   any   indicates any network protocol or direct
         connect, including IPP.

                                                  Output Device
                                                +---------------+
                                                |  ###########  |
    O   +--------+                              |  # (Leaf)  #  |
   /|\  | client |------------IPP-----------------># Printer #  |
   / \  +--------+                              |  # Object  #  |
                                                |  ###########  |
                                                +---------------+

                   Figure 1.  Embedded Printer Object


                             ###########          Output Device
    O   +--------+           # (Leaf)  #        +---------------+
   /|\  | client |---IPP----># Printer #---any->|               |
   / \  +--------+           # object  #        |               |
                             ###########        +---------------+

                   Figure 2.  Hosted Printer Object


                                                +---------------+
                                                |               |
                                             +->| Output Device |
                             ########### any/   |               |
    O   +--------+           # (Leaf)  #   /    +---------------+
   /|\  | client |---IPP----># Printer #--*
   / \  +--------+           # Object  #   \    +---------------+
                             ########### any\   |               |
                                             +->| Output Device |
                                                |               |
                                                +---------------+

                   Figure 3.  Output Device Fan-Out
Top   ToC   RFC3998 - Page 32
                             ###########           ###########
    O   +--------+           # Non-Leaf#           # subord. #
   /|\  | client |---IPP----># Printer #---IPP----># Printer #
   / \  +--------+           # object  #           # object  #
                             ###########           ###########

   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
   through 6, or can be a Leaf Printer, as in Figures 1 through 3.

                   Figure 4.  Chained IPP Printer Objects


                   +------IPP--------------------->###########
                  /                           +---># subord. #
                 /                           /     # Printer #
                /            ###########   IPP     # object  #
    O   +--------+           # Non-Leaf#   /       ###########
   /|\  | client |---IPP----># Printer #--*
   / \  +--------+           # object  #   \
                \            ###########   IPP     ###########
                 \                           \     # subord. #
                  \                           +---># Printer #
                   +------IPP---------------------># object  #
                                                   ###########

   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
   through 6, or can be a Leaf Printer, as in Figures 1 through 3.

                   Figure 5.  IPP Printer Object Fan-Out
Top   ToC   RFC3998 - Page 33
                             ###########
                             # Non-Leaf#
                        +---># Printer #-+
                       /     # object  #  \
                     IPP     ###########   \       ###########
    O   +--------+   /                      +-IPP-># subord. #
   /|\  | client |--+-----------IPP---------------># Printer #
   / \  +--------+   \                      +-IPP-># object  #
                     IPP     ###########   /       ###########
                       \     # Non-Leaf#  /
                        +---># Printer #-+
                             # object  #
                             ###########

   The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
   through 6, or can be a Leaf Printer, as in Figures 1 through 3.

                    Figure 6.  IPP Printer Object Fan-In

10.7. Forwarding Requests

This section describes the forwarding of Job and Printer requests to Subordinate Printer objects.

10.7.1. Forwarding Requests that Affect Printer Objects

In Printer Fan-Out, Printer Fan-In, and Chained Printers, the Non- Leaf IPP Printer object MUST NOT forward the operations that affect Printer objects to its Subordinate Printer objects. If a client seeks to explicitly target a Subordinate Printer, the client MUST specify the URI of the Subordinate Printer. The client can determine the URI of any Subordinate Printers by querying the Printer's "subordinate-printers-supported (1setOf uri) attribute (see section 7.1). Table 7 lists the operations that affect Printer objects and the forwarding behavior that a Non-Leaf Printer MUST exhibit to its immediate Subordinate Printers. Operations that affect jobs have a different forwarding rule (see section 10.7.2 and Table 8):
Top   ToC   RFC3998 - Page 34
   Table 7.  Forwarding Operations that Affect Printer Objects

      Printer Operation     Non-Leaf Printer Action
     ---------------------------------------------------------------
    Printer Operations:

      Enable-Printer      MUST NOT forward to any of its Subordinate
                          Printers
      Disable-Printer     MUST NOT forward to any of its Subordinate
                          Printers
      Hold-New-Jobs       MUST NOT forward to any of its Subordinate
                          Printers
      Release-Held-New-   MUST NOT forward to any of its Subordinate
      Jobs                Printers
      Deactivate-Printer  MUST NOT forward to any of its Subordinate
                          Printers
      Activate-Printer    MUST NOT forward to any of its Subordinate
                          Printers
      Restart-Printer     MUST NOT forward to any of its Subordinate
                          Printers
      Shutdown-Printer    MUST NOT forward to any of its Subordinate
                          Printers
      Startup-Printer     MUST NOT forward to any of its Subordinate
                          Printers

    IPP/1.1 Printer       See [RFC2911]
    Operations:

      Get-Printer-        MUST NOT forward to any of its Subordinate
      Attributes          Printers
      Pause-Printer       MUST NOT forward to any of its Subordinate
                          Printers
      Resume-Printer      MUST NOT forward to any of its Subordinate
                          Printers

    Set Operations:       See [RFC3380]

      Set-Printer-        MUST NOT forward to any of its Subordinate
      Attributes          Printers
Top   ToC   RFC3998 - Page 35

10.7.2. Forwarding Requests that Affect Jobs

Unlike Printer Operations that only affect Printer objects (see section 10.7.1), a Non-Leaf Printer object MUST forward operations that directly affect jobs to the appropriate Job object(s) in one or more of its immediate Subordinate Printer objects. Forwarding is REQUIRED since the purpose of this Job operation is to affect the indicated job, which may have been forwarded itself. This forwarding MAY be immediate or queued, depending on the operation and the implementation. For example, a Non-Leaf Printer object MAY queue/spool jobs, feeding a job at a time to its Subordinate Printer(s), or MAY forward jobs immediately to one of its Subordinate Printers. In either case, the Non-Leaf Printer object forwards Job Creation operations to one of its Subordinate Printers. Only the time of forwarding of the Job Creation operations depends on whether the policy is to queue/spool jobs in the Non-Leaf Printer or the Subordinate Printer. When a Non-Leaf Printer object creates a Job object in its Subordinate Printer, whether that Non-Leaf Printer object keeps a fully formed Job object or just keeps a mapping from the "job-ids" that it assigned to those assigned by its Subordinate Printer object is IMPLEMENTATION-DEPENDENT. In either case, the Non-Leaf Printer MUST be able to accept and carry out future Job operations that specify the "job-id" that the Non-Leaf Printer assigned and returned to the job submitting client. Table 8 lists the operations that directly affect jobs and the forwarding behavior that a Non-Leaf Printer MUST exhibit to its Subordinate Printers.
Top   ToC   RFC3998 - Page 36
   Table 8.  Forwarding Operations that Affect Jobs Objects

      Operation         Non-Leaf Printer action
    ---------------------------------------------------------------
    Job operations:

      Reprocess-Job     MUST forward to the appropriate Job in one of
                        its Subordinate Printers
      Cancel-Current-   MUST NOT forward
      Job
      Resume-Job        MUST forward to the appropriate Job in one of
                        its Subordinate Printers
      Promote-Job       MUST forward to the appropriate Job in one of
                        its Subordinate Printers

    IPP/1.1 Printer
    operations:

      Print-Job         MUST forward immediately or queue to the
                        appropriate Subordinate Printer
      Print-URI         MUST forward immediately or queue to the
                        appropriate Subordinate Printer
      Validate-Job      MUST forward to the appropriate Subordinate
                        Printer
      Create-Job        MUST forward immediately or queue to the
                        appropriate Subordinate Printer
      Get-Jobs          MUST forward to all its Subordinate Printers
      Purge-Jobs        MUST forward to all its Subordinate Printers

    IPP/1.1 Job
    operations:

      Send-Document     MUST forward immediately or queue to the
                        appropriate Job in one of its Subordinate
                        Printers
      Send-URI          MUST forward immediately or queue to the
                        appropriate Job in one of its Subordinate
                        Printers
      Cancel-Job        MUST forward to the appropriate Job in one of
                        its Subordinate Printers
      Get-Job-          MUST forward to the appropriate Job in one of
      Attributes        its Subordinate Printers if the Non-Leaf
                        Printer doesn't know the complete status of the
                        Job object
      Hold-Job          MUST forward to the appropriate Job in one of
                        its Subordinate Printers
      Release-Job       MUST forward to the appropriate Job in one of
                        its Subordinate Printers
Top   ToC   RFC3998 - Page 37
      Restart-Job       MUST forward to the appropriate Job in one of
                        its Subordinate Printers

    IPP Set operations: See [RFC3380]

      Set-Job-          MUST forward to the appropriate Job in one of
      Attributes        its Subordinate Printers

   When a Printer receives a request that REQUIRES forwarding, it does
   so on a "best efforts basis" and returns a response to its client
   without waiting for responses from any of its Subordinate Printers.
   Such forwarded requests could fail.

10.8. Additional Attributes to Help with Fan-Out

The following operation and Job Description attributes are defined to help represent Job relationships for Fan-Out and forwarding of jobs.

10.8.1. output-device-assigned (name(127)) Job Description Attribute - from [RFC2911]

[RFC2911] defines "output-device-assigned" as follows: "This attribute identifies the Output Device to which the Printer object has assigned this job. If an Output Device implements an embedded Printer object, the Printer object NEED NOT set this attribute. If a print server implements a Printer object, the value MAY be empty (zero-length string) or not returned until the Printer object assigns an Output Device to the job. This attribute is particularly useful when a single Printer object supports multiple devices (so called "Device Fan-Out" see [RFC2911] section 2.1)." See also section 10.1 in this specification.

10.8.2. original-requesting-user-name (name(MAX)) Operation and Job Description Attribute

The operation attribute containing the user name of the original user; i.e., corresponding to the "requesting-user-name" operation attribute (see [RFC2911], section 3.2.1.1) that the original client supplied to the first Printer object. The Printer copies the "original-requesting-user-name" operation attribute to the corresponding Job Description attribute.
Top   ToC   RFC3998 - Page 38

10.8.3. requesting-user-name (name(MAX)) Operation Attribute - Additional Semantics

The IPP/1.1 "requesting-user-name" operation attribute (see [RFC2911] section 3.2.1.1) is updated by each client to be itself on each hop; i.e., the "requesting-user-name" represents the client forwarding the request, not the original client.

10.8.4. job-originating-user-name (name(MAX)) Job Description Attribute - Additional Semantics

The "job-originating-user-name" Job Description attribute (see [RFC2911], section 4.3.6) remains as the authenticated original user, not the parent Printer's authenticated host, and is forwarded by each client without changing the value.


(page 38 continued on part 3)

Next Section