IEC 29341-19-10: UPnP PrintBasic Service — Technical Specification

IEC 29341-19-10 | UPnP Printer Service | PrintBasic Service Template

Understanding the PrintBasic Service Specification

IEC 29341-19-10 defines the PrintBasic service in detail — the fundamental service template required by all UPnP Printers. Unlike the device-level standard (IEC 29341-19-1) which describes the overall printer device, this service-level standard focuses entirely on the service interface: its actions, state variables, eventing model, and data type definitions. The PrintBasic service is designed for simplicity and reliability. It exposes a minimal but complete set of operations that allow any UPnP control point to submit print jobs, monitor their progress, and handle error conditions without needing printer-specific drivers.

The PrintBasic service uses a single-instance model: there is exactly one PrintBasic service per Printer device. If a physical printer has multiple output trays or finishing options, these are managed through vendor-specific extensions rather than additional service instances.

Service State Variables and Eventing

The PrintBasic service defines a comprehensive set of state variables that reflect the real-time condition of the printer and its jobs. Key variables include PrinterStatus (an enumerated UI4: 0=Idle, 1=Printing, 2=Paused, 3=Error, 4=Offline), JobStatus (0=Pending, 1=Processing, 2=Completed, 3=Cancelled, 4=Aborted), JobId (UI4, auto-incremented), JobName (A_ARG_TYPE_String), and ErrorDescription (A_ARG_TYPE_String providing human-readable error text). All key state variables are evented — changes trigger GENA notifications to all subscribed control points, enabling real-time UI updates without polling.

State Variable Data Type Evented Description
PrinterStatus UI4 Yes Current operational state of the printer
JobStatus UI4 Yes Status of the most recently submitted job
JobId UI4 Yes Identifier of the active or last job
JobName string No Friendly name for the submitted job
ErrorDescription string Yes Detailed error text when PrinterStatus=3
The JobStatus variable reflects the status of the job referenced by JobId, which is always the most recently submitted job. To track multiple jobs independently, the control point must store its own mapping of JobId values and poll GetJobStatus for each, as the evented state variable only covers the current job.

Data Modelling for Print Jobs

The Print action accepts a Document parameter of type bin.base64 (defined in XML Schema Part 2) and a MIMEType parameter of type string. The service definition in IEC 29341-19-10 specifies that the Document must contain the complete print data in a single SOAP request — there is no chunked or streaming mode at the service level. This has implications for memory management: the printer must buffer the entire decoded document before processing. For implementation, engineers should pre-allocate a fixed buffer based on the maximum job size advertised in the device description, and reject oversize documents at the service layer with a clear error code before any memory pressure occurs.

A well-designed control point should query GetPrinterStatus before submitting a job. If the printer is in “Error” or “Offline” state, submitting a job will fail and waste bandwidth. Performing a pre-submission status check reduces network chatter and improves user experience.
The bin.base64 encoding expands binary data by approximately 33%. For a 50 MB print job, the SOAP payload reaches roughly 67 MB before HTTP headers. Ensure your SOAP processor has adequate memory headroom, and configure the web server’s max request size limit accordingly to avoid silent truncation of large jobs.

Engineering Design Insights

When implementing the PrintBasic service, pay attention to the concurrency model. The standard does not mandate thread safety for concurrent Print invocations, but a production-grade implementation must serialise access to the job queue. Use a mutex or lock around the state variable block that encompasses JobId, JobName, and JobStatus to ensure consistent reads and writes. Additionally, the CancelJob action must handle the race condition where a job completes between the arrival of the cancel request and the processing of the cancellation — a robust implementation checks job completion state before and after the cancellation signal.

Frequently Asked Questions

Q1: Can PrintBasic service handle multiple page formats in a single job?
No, each Print action accepts one document with a single MIME type. For mixed-content jobs, the control point must split the content into separate Print calls or embed multi-part content within a single container format such as PDF.
Q2: What happens if a control point disconnects during printing?
The PrintBasic service continues processing the job independently. The job runs to completion or failure regardless of the control point connection state. The control point can reconnect and subscribe to events to re-establish monitoring.
Q3: Does the service define timeout values for printing?
The standard does not prescribe specific timeout values. Implementations should define a reasonable job timeout (e.g., 30 minutes for typical documents) and expose this through the device description or a vendor extension.
Q4: How does the service handle character encoding in job names?
The JobName state variable and associated arguments use UTF-8 encoding. Control points should encode job names in UTF-8, and service implementations must handle multi-byte characters correctly when storing and displaying job names.

Leave a Reply

Your email address will not be published. Required fields are marked *