Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-7-2 — UPnP Printer Device — Basic Service v2
Printer Basic Service v2 — Job Submission, Data Transfer Protocol, and Job Ticket Templates
UPnP Printer Basic Service v2 Overview
ISO/IEC 29341-7-2 specifies the Printer Basic Service v2, the foundational service of the UPnP Printer Device v2 architecture responsible for print job submission. As the entry point for client applications to send documents to a network printer, the Basic Service defines the CreateJob action that accepts print data, job ticket parameters, and document processing instructions, returning a JobID that can be used with the Job Service for subsequent job management. The service is identified by the URN: schemas-upnp-org:service:PrinterBasic:2.
The Basic Service v2 uses a pull-based model for data transfer: after the client invokes CreateJob, it uploads the print data to a URL provided by the service using standard HTTP PUT or POST. This decouples job submission from data transfer, enabling asynchronous workflows where the client can submit a job and transfer the data independently.
The CreateJob action accepts a JobTicket parameter — a structured XML document that describes the processing requirements for the print job. The job ticket specifies document format (application/pdf, image/tiff, text/plain, etc.), media size, media type (plain paper, glossy, transparency, envelopes), resolution, duplex mode (one-sided, two-sided, booklet), color mode (monochrome, grayscale, color), stapling/finishing options, page orientation, input tray selection, output bin selection, and document name. The service validates the job ticket against printer capabilities and returns a detailed error response if any requested capability is not supported by the printer.
| JobTicket Parameter | Type | Example Values | Mandatory |
|---|---|---|---|
| DocumentFormat | string (MIME) | application/pdf, image/jpeg, text/plain | Yes |
| CopyCount | ui2 | 1–9999 | Yes |
| MediaSize | string | iso-a4, na-letter, iso-a3, jis-b5 | No |
| MediaType | string | plain, glossy, transparency, envelopes | No |
| Resolution | string | 600dpi, 1200dpi, 2400dpi | No |
| Duplex | string | one-sided, two-sided-long-edge, two-sided-short-edge | No |
| ColorMode | string | monochrome, grayscale, color | No |
| JobPriority | ui1 | 1–100 (default 50) | No |
Data Transfer and Job Submission Protocol
The Basic Service v2 implements a two-phase job submission protocol. In Phase 1, the client invokes CreateJob with the job ticket parameters. The printer validates the ticket, reserves resources for the job (disk space for spooling, memory for rendering), and returns a job submission response containing the JobID, a DataSinkURL (the URL for uploading print data), and the estimated maximum data size. In Phase 2, the client uploads the print data to the DataSinkURL using HTTP PUT or POST with Content-Type matching the DocumentFormat specified in the job ticket. The printer acknowledges receipt and begins processing the job through its rendering pipeline.
Clients should honor Capabilities.MaxDataSize returned by the printer. Attempting to upload a print job exceeding this limit will result in an HTTP 413 Payload Too Large error from the printer. For large print jobs (e.g., high-resolution photo prints or CAD drawings with hundreds of pages), clients should either reduce resolution, split the job into multiple smaller submissions, or negotiate with the printer for large-job handling.
The service also defines the GetCapabilities action, which returns a comprehensive description of the printer’s supported features and constraints. This includes supported document formats, media sizes (standard and custom), media types, resolution ranges (minimum, maximum, step), duplex modes, color capabilities (bits per pixel, color spaces supported), finishing options (stapling positions, hole-punch patterns, folding styles), input tray configuration (number of trays, capacities, supported media per tray), output bin configuration, and device-specific constraints such as maximum job size and maximum page count. The capabilities document is structured as an XML schema that control points can parse to dynamically generate print dialogs that only show supported options.
The GetCapabilities action is particularly powerful for mobile printing applications, where the client device has no prior knowledge of the printer’s features. By querying capabilities before presenting print options, a mobile print client can dynamically construct a user interface that adapts to the specific printer — showing duplex options only if the printer supports them, disabling staples if no stapler is installed, and selecting the default paper size based on the printer’s configuration rather than assuming letter or A4.
The Basic Service v2 also introduces support for print job templates — predefined job ticket profiles stored on the printer that clients can reference by name instead of specifying every parameter individually. The printer can store multiple templates (e.g., “Quick Draft,” “High Quality Photo,” “Binder Ready”), each with a complete set of processing instructions. A client invokes CreateJobFromTemplate specifying the template name and optionally overriding individual parameters. This simplifies the submission protocol for clients that do not need fine-grained control over every print parameter and enables IT administrators to define standardized print policies centrally.
Security, Authentication, and Error Handling
Security considerations for the Basic Service v2 include job submission authentication, data integrity verification, and print data confidentiality. The service supports access control lists that restrict which clients can submit jobs. Data integrity is ensured through optional Content-MD5 headers that allow the printer to verify that the received print data matches the submitted content. For confidentiality, the service supports HTTPS URLs for DataSinkURL when the printer is configured with a TLS certificate, encrypting print data in transit. The specification also defines minimum authentication requirements for administrative actions such as modifying printer capabilities or clearing the job queue.
When the Basic Service v2 is deployed without TLS encryption, print data — including potentially sensitive documents such as payroll reports, legal contracts, or medical records — is transmitted in cleartext over the network. In enterprise environments where printers are on the same network segment as client workstations, this creates a significant data leakage risk. Network segmentation, VLAN isolation for printers, and mandatory TLS for print services are strongly recommended security practices.
The error handling model of the Basic Service v2 distinguishes between job-level errors and service-level errors. Job-level errors (e.g., invalid document format, unsupported media size, job too large) are returned as structured error responses from CreateJob, allowing the client to adjust parameters and retry. Service-level errors (e.g., printer offline, disk full, fatal hardware error) are communicated through the Status Service’s ErrorStatus variable and evented to subscribed control points. The Basic Service itself does not queue jobs when the printer is offline — it returns a service-level error, and the client is responsible for retrying later. This design ensures that the print submission protocol remains simple and that queuing logic is centralized in the client or print server rather than distributed across printers.
Q: What document formats does the Basic Service v2 typically support?
A: The minimum required formats are application/pdf and image/tiff. Most implementations also support image/jpeg, text/plain, application/postscript, and application/vnd.hp-PCL. The GetCapabilities action returns the complete list of supported formats for a specific printer. The service does not perform format conversion — the client must ensure the document format is supported.
Q: How does the two-phase submission protocol handle network interruptions?
A: The CreateJob action reserves a job slot with a time-limited DataSinkURL (typically valid for 5-30 minutes, configurable via the DataSinkTimeout state variable). If the data upload is interrupted, the client can resume using HTTP Range headers if the printer supports partial uploads. If the timeout expires before data is fully received, the printer releases the reservation and cancels the job. The client must then submit a new CreateJob request.
Q: Can the Basic Service v2 handle encrypted print data?
A: The service itself does not define print data encryption — it relies on transport-layer security (HTTPS with TLS) for data-in-transit encryption. For data-at-rest encryption on the printer’s spool storage, that is a printer implementation concern outside the scope of the UPnP service specification.
Q: What is the role of job ticket templates in the Basic Service v2?
A: Job ticket templates allow IT administrators to predefine standard print configurations — for example, a “Draft” template with 300dpi monochrome simplex printing, or a “Presentation” template with 1200dpi color duplex printing. Users select the template by name rather than configuring every parameter, simplifying the print experience and enforcing organizational print policies.
