Should scanning capabilities be considered as part of (or alongside) this proposal?

[jlucaso1]

Context

The Web Printing API proposal provides an excellent foundation for direct printer interaction from web applications using IPP semantics. Given that many printers today are multifunction devices (MFDs) that also include scanning capabilities, it seems natural to ask whether scanning should be considered as part of this effort — either as an extension to this proposal or as a companion specification.

Existing Standards & Prior Art

The IPP ecosystem already defines scanning capabilities:

• PWG 5100.17-2014 — IPP Scan Service (PWG IPP page): Defines scan-specific operations and attributes within the IPP framework, including scan job submission, scanner capability discovery, and output routing via destination-uris.
• IANA IPP Registrations (iana.org/assignments/ipp-registrations): Already includes scan-related attributes such as output-attributes-actual (PWG5100.17) and destination-uris/destination-statuses (PWG5100.15) for scan-to-destination workflows.
• eSCL (AirScan): An HTTP-based scanning protocol widely adopted by modern MFDs, used by Apple AirScan and supported by SANE backends on Linux.
• Chrome documentScan API (Chrome Extensions reference): A ChromeOS extension API that already provides scanner discovery (getScannerList()), configuration (setOptions()), and scanning (startScan() / readScanData()) — demonstrating that browser-level scanner access is feasible.

Why This Matters

The same use cases that motivate the Web Printing API — especially remote/VDI environments — also apply to scanning. In a virtual desktop session, a user may need to scan a document using a local MFD and have the scanned image available on the remote side. Today, this requires vendor-specific plugins or native applications.

A Web Scanning API that follows the same architectural patterns as this proposal (IPP-based semantics, SecureContext, permission-gated access) could provide:

• Scanner discovery: Enumerate local scanners and their capabilities (resolution, color modes, document formats, input sources like flatbed vs. ADF)
• Scan job submission: Initiate scans with configurable parameters
• Scan data retrieval: Receive scanned output as Blob (PDF, JPEG, PNG)
• Job state monitoring: Track scan progress and handle errors (paper jam, cover open, etc.)

Potential API Shape (Sketch)

Following the same design principles as the Web Printing API:

[Exposed=Window, SecureContext]
interface Scanner {
  ScannerAttributes cachedAttributes();
  Promise<ScannerAttributes> fetchAttributes();
  Promise<ScanJob> submitScanJob(optional ScanJobTemplateAttributes options = {});
};

[Exposed=Window, SecureContext]
interface ScanJob {
  ScanJobAttributes attributes();
  attribute EventHandler onjobstatechange;
  Promise<Blob> getData();
  void cancel();
};

The permission model from this proposal (Flow B — per-device access grants) would map naturally to scanners as well.

Questions

1. Has scanning been discussed as a potential extension to this proposal?
2. Would it make sense to generalize the Printing interface into a broader device interaction surface that covers both printing and scanning for MFDs?
3. Or would a separate companion spec (e.g., "Web Scanning API") that shares the same IPP-based conventions be preferred?

References

• PWG 5100.17-2014 — IPP Scan Service
• IANA IPP Registrations
• Chrome documentScan Extension API
• WebHID API — similar permission model for hardware access
• Web Smart Card API — another device API with relevant security patterns