Technical Gaps in IPP / Mopria Specifications for Thermal POS & Label Receipt Printers

[qazedcww2]

We are developing and maintaining printer drivers for POS (Point of Sale) thermal receipt and label printers. We would like to open a discussion regarding the specific architectural, firmware, and hardware connection gaps between the current Mopria/IPP standard specifications and our thermal POS printers.
We have identified the following critical hardware and protocol-level gaps that make Mopria/IPP compliance architecturally impossible for our device category:

1. Hardware Micro-controller (MCU) and Firmware Constraints

   • Gap:** Compliant IPP/Mopria devices must host a fully functional TCP/IP stack, SSL/TLS security protocols, and an HTTP/HTTPS responder.
   • Issue: Our legacy thermal POS printers are built on low-power, cost-optimized embedded micro-controllers (MCUs) with extremely limited RAM and ROM. These embedded systems do not have the hardware capability or memory capacity to run a TCP/IP network stack or host an HTTP server. It is physically impossible to support an IPP responder at the firmware level on these hardware platforms.

2. Legacy Transport Interfaces (RS-232 Serial and USB Bulk-Only Transport)

   • Gap: Mopria/IPP Everywhere is designed for network-connected (Ethernet/Wi-Fi) printers or specific high-performance IPP-over-USB (IPP-USB) class interfaces.
   • Issue: Our devices connect to POS terminals via legacy RS-232 serial interfaces or raw USB Bulk endpoints (Printer Class 7-1-2). Serial interfaces lack a network layer to carry IPP traffic, and the low-cost USB controller chips in our printers do not support the USB descriptors required for IPP-over-USB.

3. Dynamic Page Cutting (Continuous Media Roll Control)

   • Gap: POS receipt printing relies on continuous paper rolls where page length is completely dynamic (content-driven). Standard IPP attributes require predefined media sizes (Media Box).
   • Issue: There is no standard IPP attribute that handles "dynamic cut-to-content" cleanly without adding trailing margins or cutting in the middle of a receipt. Current IPP finishing templates do not map to hardware-level micro-commands required for POS paper cutting (Partial Cut vs. Full Cut vs. Tear-bar feeding) which are traditionally handled by GDI DevMode configurations.

4. Peripheral Cash Drawer Control (RJ11 / DK Port)]

   • Gap: Thermal POS printers act as hardware hubs to control peripheral devices like cash drawers or kitchen bells connected via the RJ11 Drawer Kick (DK) port.
   • Issue: POS software triggers these actions at specific timings (e.g., popping the cash drawer before printing). IPP/Mopria has no native attributes or template extensions to send out-of-band electrical signals or peripheral commands (e.g., ESC/POS ESC p sequence) to the drawer kick port.

5. Real-time, Low-latency Status Monitoring (Near-End Sensors)

   • Gap: In high-speed retail environments, POS software must query detailed, real-time hardware status (e.g., Paper Near-End sensor, Platen Roller Open, Cutter Jam) prior to printing to prevent half-printed receipts.
   • Issue: Standard IPP status query using printer-state-reasons (e.g., media-empty) is asynchronous and has high latency due to HTTP/Network overhead. It lacks the millisecond-level hardware register polling support provided by proprietary kernel/user-mode drivers.

We would appreciate feedback from the community and PSA ecosystem on how these hardware-specific and connection-level constraints are addressed, or if legacy V3/V4 drivers remain the only viable solution for this class of devices.

[michaelrsweet]

Please see the current draft of the IPP Label and Receipt Printing Extensions v1.1 (LABEL) registration in the Printer Working Group.

WRT your points:

1. There are plenty of low-cost Wi-Fi microcontroller solutions that could be used to extend existing label printers. A Raspberry Pi Zero W can easily host an IPP service, and I'm quite certain you could squeeze things onto a Pico.
2. RS-232 thermal printers are legacy products. Most implement the USB printer class and one or more pseudo-standard printer languages.
3. IPP has long supported roll media and variable/custom-length pages and what is referred to as "banner printing". The referenced PWG registration explains how an IPP implementation can optimize roll usage based on the document content, specifically by using the "imposition-template" attribute with any of the 'banner' keyword values. Similarly, IPP has long supported media cutting via both the 'trim' enum values for the "finishings" attribute and the "trimming" member attribute in "finishings-col" (which provides explicit control over the cut location and type).
4. The referenced PWG registration adds a new IPP operation to control these signals.
5. IPP also provides notifications to allow for asynchronous delivery of status information, but honestly you are NOT getting status information that quickly over RS-232 or USB anyways. Moreover, it is the responsibility of the IPP Printer to manage this status interface and any print jobs, NOT the client application.

In short, CUPS and IPP are concerned with standardizing printing and NOT with continuing support for legacy interfaces and methodologies. The IPP model (getting close to 30 years old now) successfully abstracts hardware differences so that client applications can communicate with and use any kind of printer.