Pull Printing and Follow-Me Printing

History

The core mechanism behind pull printing — holding a job in a queue and releasing it later — predates the modern cloud framing and is standardized within the Internet Printing Protocol (IPP) itself. The Hold-Job and Release-Job operations and the job-hold-until attribute (including the indefinite value) were defined in RFC 2911 (IPP/1.1) in September 2000. Printer-wide holding, via the Hold-New-Jobs and Release-Held-New-Jobs operations, was added in RFC 3998 in March 2005.

The productized "release at any device" pattern is commonly associated with Ringdale's FollowMe product; Ringdale dates its print-roaming technology to 1997, though this is a vendor claim rather than an independent standards record, and "FollowMe" is a registered trademark of Ringdale UK Ltd and Ringdale, Inc. Through the 2000s and 2010s, third-party print-management software built pull printing on top of Windows print servers and CUPS. The model later shifted toward cloud spooling, reflected in standards for infrastructure/cloud-held jobs (the PWG's IPP Shared Infrastructure Extensions) and in Microsoft's cloud-native implementation, Universal Print anywhere.

Architecture

A pull-printing system defines several logical roles, regardless of vendor:

• Client / print driver — produces the job in a page description language (PDL) and submits it to a shared logical queue rather than to a device.
• Spooling / hold service — stores the held job and its metadata (owner identity, timestamps, options). In the PWG model this is the Infrastructure Printer; on Windows it is the print server or the Universal Print cloud service; on Linux and macOS it is the CUPS scheduler holding the job.
• Identity / authentication layer — maps a credential presented at a device (badge, PIN, biometric, or mobile login) to a directory identity.
• Release mechanism at the device — embedded terminal software on the multifunction printer (MFP), a separate release station, or a web/mobile release interface.
• Output device / proxy — the physical printer; where the printer is not natively cloud-aware, a proxy pulls jobs from the spooler on its behalf.

The PWG's IPP Shared Infrastructure Extensions (PWG 5100.18, "INFRA") define this explicitly as a three-party model. An IPP Client submits to an Infrastructure Printer described as "a Spooling Service that manages Jobs and Documents on behalf of the Proxy," which can also "augment the capabilities of the Output Device" by providing document conversion, imposition, and other services. An IPP Proxy running near or on the Output Device fetches the queued work; the reference ippproxy(8) implementation in the PWG ippsample project states that it "conforms to PWG Candidate Standard 5100.18: IPP Shared Infrastructure Extensions (INFRA)."

How it works

1. Submit. The user prints to one shared pull-print queue. The job is accepted and marked held rather than dispatched. 2. Hold. The spooler retains the job with the owner's identity attached. In IPP terms the job may carry job-hold-until = indefinite; RFC 2911 defines that value as "the job is held indefinitely, until a client performs a Release-Job." In Universal Print, the printer share has an "Enable holding jobs until secure release" toggle so jobs are held securely in the cloud. 3. Authenticate. At any enrolled device, the user presents a credential. Universal Print expresses supported methods through the IPP attribute job-release-action-supported, with values including owner-authorized-badge, owner-authorized-biometrics, and owner-authorized-username-password; QR-code release via the Microsoft 365 mobile app is always available. 4. Enumerate and release. The device or proxy queries the spooler for that user's fetchable jobs and releases the selected job(s). In base IPP this corresponds to Release-Job; in the infrastructure/cloud flow it is a fetch-and-acknowledge sequence. 5. Print and report. The device images the document and the final state is reported back so users and administrators can see the outcome.

Data flow

In the cloud/infrastructure-held model documented by Microsoft for Universal Print anywhere, the data takes the following path:

1. The client submits to a pull-print printer; the job is held for secure release in the spooler. No device is notified and nothing is downloaded yet. 2. The user badges or scans at a device, and the identity layer maps the credential to the user's identity, expressed as requesting-user-uri: mailto:{userUPN}. 3. The device or proxy calls Get-Jobs with which-jobs=fetchable, my-jobs=true, and requesting-user-uri to list that user's held jobs. 4. Fetch-Job returns the selected job's attributes and Fetch-Document downloads the print-ready payload. 5. Acknowledge-Job releases the job to the device. 6. The proxy forwards the payload to the printer, and Update-Job-Status reports the final job state (completed, aborted, or canceled).

Traditional server-held variants differ mainly in where the spool lives and when it moves. A central-store configuration keeps the job on the central spooler until release, while a local-download configuration pre-stages the job to a release station before the user asks for it. Held spool files may be encrypted at rest; PaperCut, for example, documents encryption of held spool files as a product feature.

Operating system integration

• Windows (on-premises): Pull printing is built on the Windows print spooler and print server. Release and authentication are typically supplied by third-party print-management software layered on shared queues; the operating system provides the spooler, queue, and driver plumbing.
• Windows / Microsoft 365 (cloud): Universal Print is Microsoft's cloud print service, and Universal Print anywhere is its native pull-print layer. It is server-less for the customer (no on-premises print server is needed for Universal-Print-ready printers) and is configured in the Universal Print portal via Pull-print printers and Member Printers, with holding controlled at the printer-share level.
• Linux / Unix (CUPS): The CUPS scheduler natively supports holding via job-hold-until (indefinite), the Hold-New-Jobs IPP operation, and the CLI equivalents cupsdisable --hold (holds remaining jobs) and cupsenable --release (releases pending jobs). Held jobs can be moved with CUPS-Move-Job. Full walk-up authentication and cross-device roaming are generally added by print-management software on top of these primitives.
• macOS: Uses CUPS as its printing subsystem, so the same CUPS hold and release primitives apply beneath vendor solutions.

Relationship to standards

• IETF RFC 2911 (IPP/1.1) defines Hold-Job, Release-Job, and the job-hold-until attribute with the indefinite value — the primitive that makes a queue hold until released.
• IETF RFC 3998 adds the printer-scope Hold-New-Jobs and Release-Held-New-Jobs operations, routing new jobs to a held state.
• PWG 5100.18 (INFRA, IPP Shared Infrastructure Extensions) was first published as a Candidate Standard on 2015-06-19 and defines the Infrastructure Printer, IPP Proxy, and Output Device roles plus the fetch and acknowledge operations that let a device pull queued jobs. Version 1.1, designated PWG 5100.18-2025 and dated 2025-05-02, was subsequently approved.
• Mopria Cloud Specification. Microsoft's Universal Print OEM badge-release integration states it is built on the Secure Release framework specified in Mopria Cloud Specification v1.2, and its cloud-to-cloud partner integration references v1.1 (§5.1.2, Cloud Topography) and v1.2 (§5.1.6, Secure Release). The specification is published by the Mopria Alliance.
• Vendor IPP extensions. Universal Print adds attributes such as smi311-universal-print-anywhere-enabled, set via the Update-Output-Device-Attributes operation, to let a printer declare pull-print participation.

Relationship to technologies

• Authentication and credential technologies: proximity badges and smart cards, PIN pads, biometric (fingerprint) readers, and mobile authentication via QR-code scan or app login. Microsoft notes that Universal Print badge release may work with an organization's existing badge system.
• Directory and identity: enterprise directory identity ties the physical credential to the job owner; Universal Print uses Microsoft Entra ID identities expressed as a user principal name (UPN).
• Page description and transfer formats: generic pull printing carries ordinary print jobs in PDLs and raster formats such as PostScript, PCL, PDF, PWG Raster (image/pwg-raster), and Apple Raster (image/urf). Where the standards model applies, the Infrastructure Printer can transcode between formats; the exact format set supported by any given cloud service is defined by that service.
• Encryption: held spool files can be encrypted at rest, and Universal Print holds jobs securely in the cloud pending release.

Relationship to manufacturers

Microsoft provides the cloud spooling and release platform (Universal Print anywhere) and publishes the IPP infrastructure extensions that OEMs implement.

Printer OEMs implement walk-up authentication and release in device firmware or terminal software. Microsoft documents published badge-release integrations from HP (HP Authentication Suite), Konica Minolta (listed as "coming soon"), and Datasec, and notes that support can extend to biometrics and NFC where the printer supports them. Badge release requires OEM enablement, is surfaced through a "Pull-print Supported" marker, and is not supported for printers managed by the Universal Print connector.

Independent print-management vendors — including PaperCut, YSoft SAFEQ, Ringdale FollowMe, PrinterOn/eprintit, Equitrac, and uniFLOW — provide cross-vendor pull printing over mixed fleets, either on-premises or by integrating with a cloud platform as a partner. A partner cloud can act as an IPP Proxy on behalf of the printers it manages.

Modern relevance

Pull printing remains a core enterprise print-security and cost-control mechanism and is a primary justification for cloud print platforms. It reduces abandoned or forgotten printouts left in output trays, enforces authenticated release of sensitive documents, and lets users retrieve a single job at whichever device is nearest.

Cloud-native pull printing addresses a specific scaling problem: routing an entire tenant to one shared virtual queue can hit per-queue throughput and concurrency limits, so purpose-built pull-print infrastructure is used to absorb high, concentrated job volume without throttling. The model is also central to hybrid-work and zero-trust print strategies, where removing on-premises print servers while preserving secure release is an explicit goal.

Common misconceptions

• "Pull printing means the printer stores the job." Usually the job is held on a server or in the cloud, not on the device; the device only fetches it at release. Some local-download configurations pre-stage a job to a release station, but that is a deployment choice, not the definition.
• "Follow-me printing is a single proprietary product." "FollowMe" is a Ringdale trademark, "Find-Me" is PaperCut's term, and "Secure Release Anywhere" is PrinterOn/eprintit's term, but the underlying pull-printing pattern is generic and standardized through IPP hold/release and the PWG infrastructure extensions.
• "Holding a job is the same as pausing or disabling the queue." Holding is per-job (job-hold-until = indefinite) or via Hold-New-Jobs, and is distinct from disabling a queue — though CUPS conveniently exposes hold through cupsdisable --hold.
• "Authentication and release are the same step." Authentication maps a credential to an identity; release (Release-Job or Acknowledge-Job) is the separate action that actually schedules the job.
• "Pull printing eliminates the print driver or PDL." The client still produces a normal job in a PDL; only the dispatch timing and destination change.
• "Badge and QR-code release are interchangeable everywhere." In Universal Print, QR-code release is always available, but badge and biometric release are hardware-dependent and must be OEM-enabled.

Timeline

1. 1997

   Ringdale dates its FollowMe print-roaming technology to this year (vendor claim).

2. September 2000

   RFC 2911 (IPP/1.1) defines Hold-Job, Release-Job, and the job-hold-until attribute with the indefinite value.

3. March 2005

   RFC 3998 adds Hold-New-Jobs and Release-Held-New-Jobs.

4. 2015-06-19

   PWG Candidate Standard 5100.18 (IPP Shared Infrastructure Extensions, INFRA) is published, defining the Infrastructure Printer, IPP Proxy, and Output Device roles.

5. 2025

   PWG 5100.18-2025 (INFRA v1.1), dated 2025-05-02, is approved.

6. 2025–2026

   Microsoft makes pull print (Universal Print anywhere) available, with secure release via QR code and OEM badge/biometric release built on the Mopria Cloud Specification.