Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-7-11 — UPnP Printer Device — Job Service v2
Printer Job Service v2 — Job Management, Eventing, Priority Scheduling, and Accounting
UPnP Printer Job Service v2 Architecture
ISO/IEC 29341-7-11 defines the Printer Job Service v2, a core component of the UPnP Printer Device v2 specification that provides standardized management of print jobs submitted to network printers. The Job Service complements the Basic Service (job submission) and Status Service (device monitoring) by offering fine-grained control over individual print jobs: job progress tracking, job cancellation, job priority management, and detailed job accounting information. The service is identified by the URN: schemas-upnp-org:service:PrinterJob:2.
The separation of print functionality into three distinct services — Basic, Status, and Job — follows the UPnP principle of service granularity, allowing devices to implement only the services they need. A simple printer might implement only Basic and Status services, while a production MFP (Multi-Function Printer) with advanced job management capabilities implements all three.
The Job Service maintains a job table (JobTable) containing an entry for each active, queued, and recently completed job. Each job entry includes a unique JobID assigned at submission time, the job’s current state (pending, processing, completed, canceled, aborted), priority level, submission time, processing time, page count, and client identification information. The service supports querying individual job details via GetJobInfo or enumerating all jobs via GetJobList. Jobs can be filtered by state (e.g., “show me all jobs in the processing state”) or by client ID (“show me all jobs submitted by client X”).
| Job State | Description | Can Cancel? | Can Pause? | Transition To |
|---|---|---|---|---|
| pending | Queued, not yet started | Yes | N/A | processing |
| processing | Actively being printed | Yes | Yes | completed, paused, canceled, aborted |
| paused | Printing suspended | Yes | N/A | processing, canceled |
| completed | Finished successfully | No | No | Terminal state |
| canceled | Stopped by user request | No | No | Terminal state |
| aborted | Failed due to error | No | No | Terminal state |
Job Management Actions and Eventing
The Job Service provides a rich set of management actions. GetJobList returns a filtered list of job entries based on state, client ID, or other criteria. GetJobInfo returns detailed information for a specific job including its current state, progress metrics (pages printed, bytes processed, estimated time remaining), and job attributes (document name, owner, submission timestamp, priority, and processing instructions). CancelJob requests termination of a specified job, with the service responsible for gracefully aborting the print stream and resetting the printer state. PauseJob and ResumeJob allow temporary suspension and continuation of active jobs — particularly useful for interrupting a long print run to process an urgent job.
The CancelJob action requires careful implementation on the printer side. Simply terminating the print stream mid-page can leave the printer in an inconsistent state with partial page data in the imaging pipeline. The Job Service specification recommends that the printer complete rendering the current page before canceling, then flush any partially received job data from the input buffer. For paused jobs, the service must maintain sufficient state information to resume from the exact interruption point.
Job eventing is a critical feature of the service. Through the UPnP eventing mechanism, control points can subscribe to JobState event notifications and receive real-time updates as jobs progress through their state machine. The service also provides aggregate eventing through the JobListChanged state variable, which fires whenever the job table is modified (job added, state changed, job removed). This enables print management consoles to maintain a synchronized view of the printer’s job queue without polling.
The Job Service v2 introduces enhanced job priority management compared to v1. Jobs can be assigned priority levels from 1 (highest) to 100 (lowest), with default priority 50. The service must process jobs in strict priority order, with round-robin scheduling among jobs at the same priority level. This allows enterprise print management systems to ensure that time-sensitive documents — such as shipping labels or patient wristbands — always print ahead of batch reports.
Job accounting is another important capability. The service tracks resource consumption for each completed job: paper sheets used (by size and type), toner coverage percentage, total processing time, and job submission-to-completion cycle time. This information is accessible through the GetJobAccounting action and can be exported for chargeback billing, departmental cost allocation, and environmental sustainability reporting. The service retains completed job accounting records in the job table based on a configurable retention policy (JobHistoryLimit) that specifies either maximum entry count or maximum retention duration.
Error Handling and Recovery
Robust error handling is essential for the Job Service. When a printer encounters an error during job processing (paper jam, toner empty, cover open), the affected job transitions to the “paused” state rather than immediately to “aborted,” giving the operator an opportunity to resolve the issue and resume printing. The JobServiceErrorStatus variable provides detailed error information correlated with the affected job ID. The service implements configurable retry policies for transient errors — for example, automatically retrying a job after a paper jam is cleared without requiring operator intervention.
A critical design consideration for the Job Service is handling of job data persistence across printer power cycles. The specification recommends that active job data be stored in non-volatile memory so that queued jobs survive unexpected power loss. Upon power restoration, the service should recover the job table, mark any interrupted jobs as “aborted” with an error code indicating power failure, and be ready to accept new submissions. Failure to implement proper persistence can result in lost print jobs and user dissatisfaction.
The service also defines inter-service coordination requirements with the Basic Service and Status Service. When the Basic Service submits a new job, it must notify the Job Service to create the corresponding job entry. When the Status Service detects a critical error that prevents printing, it must coordinate with the Job Service to pause affected jobs. The UPnP device specification mandates that all three services operate from a consistent state machine and share the same job table, ensuring that a job canceled through the Job Service is immediately reflected in the Basic Service’s job tracking and the Status Service’s queue size reporting.
Q: How does the Job Service handle multiple jobs submitted simultaneously?
A: The service serializes job submission through the Basic Service and assigns sequential JobIDs. All submitted jobs enter the “pending” state in the job table. The printer processes jobs in priority order, with round-robin scheduling for equal-priority jobs. The JobListChanged event notification fires after each job table modification, keeping all subscribed control points synchronized.
Q: Can the Job Service distinguish between different users?
A: Yes. Each job entry includes a JobOriginatingUserID field that identifies the user or application that submitted the job. This enables per-user job tracking, usage quota enforcement, and departmental billing. The field value is typically set by the Basic Service during job submission based on the authenticated user identity.
Q: What happens when a job is canceled mid-print?
A: The printer should complete rendering the current page, then discard all remaining job data. If the job was the only one printing, the printer transitions back to idle state. Other queued jobs remain unaffected. If a paused job is canceled, the printer discards any partially rendered pages and removes the job entirely from the job table.
Q: How long are completed jobs retained in the job table?
A: The retention period is configurable via the JobHistoryLimit state variable. Typical configurations retain completed job records for a minimum of 30 minutes (for immediate verification) up to several days (for detailed auditing). Once the retention limit is reached, the oldest completed job entries are automatically removed from the job table.
