IPP Print Features

IPP Print Features

This document lists print features and how they are supported using IPP. Sections 1–10 cover features a Client directly exposes to, or that a Client exposes as an observable result for, an end user — a print-dialog option, a physical output difference, or an interactive device/status action. Section 11 covers a small set of supporting mechanisms this document also tracks — attributes that exist to serve administrators/fleet-management or to enforce access/transport security in the background, with no direct, independently-chosen presence in a typical print dialog. Protocol/negotiation mechanics that are purely plumbing (capability discovery, DNS-SD advertisement, Validate-Job semantics, constraint resolution, conformance signaling) are intentionally excluded from both — they're already covered by the IPP Implementor's Guide v2[ig] and aren't independent customer-visible features in their own right.

Each feature definition provides the following

• Description - A description of the feature
• Detection — How a Client discovers whether and to what extent a Printer supports the feature (IPP operations, attributes, values, and possibly associated resources).
• Client Preview — Whether and how a Client UI can render an accurate before-printing preview of the feature's effect.
• Job Submission / Job Ticket — The Job Template attribute(s) a Client includes in Job Creation requests to request that feature be enabled for the Job.
• Expected Result — The observable outcome at the Printer / Job level, including how it should be reflected back in Job Status or Printer Status attributes.

Each attribute name links to the specification that defines it; full citations are collected in References at the end of this document.

---

1. Media / Paper Handling

Paper size selection

• Detection: media-supported[rfc8011] - list of media keyword names, and/or media-col-database[jobext] - collection entries with media-size, media-size-name, source/type pairing, returned by Get-Printer-Attributes.
• Client Preview: Yes — canvas/page-boundary dimensions are known locally, so the client can render an accurate to-scale page preview without contacting the printer again.
• Job Submission / Job Ticket: media[rfc8011] (simple keyword, e.g. na_letter_8.5x11in) or media-col[jobext] with a media-size member collection (x-dimension, y-dimension).
• Expected Result: Printer renders output on the requested sheet size; if unsupported, printer should reject via Validate-Job or substitute the closest match and report the substitution in job-state-message / media-col-actual.

Custom paper size

• Detection: media-size-supported[rfc8011] expressed as a range (x-dimension/y-dimension min-max) rather than discrete values, or a custom_min/custom_max entry in media-supported.
• Client Preview: Yes — same as standard sizes, since dimensions are explicit numeric values the client controls directly.
• Job Submission / Job Ticket: media-col[jobext] with media-size set to explicit dimensions within the advertised range.
• Expected Result: Job accepted and printed at the exact custom dimensions; out-of-range values should cause Validate-Job/Print-Job to return client-error-attributes-or-values-not-supported with the offending attribute in the unsupported attributes group.

Paper source / tray selection

• Detection: media-source-supported[rfc8011] - list of tray keywords, e.g. tray-1, manual - and media-col-database[jobext] entries pairing source with supported media.
• Client Preview: No — tray choice has no visual effect on page content; at most a UI can show a text/icon label for the selected tray.
• Job Submission / Job Ticket: media-source[rfc8011] or media-col (media-source member).
• Expected Result: Printer feeds from the requested tray; if the tray is empty or mismatched with requested media, printer transitions to printer-state-reasons = media-needed and job enters processing-stopped.

Paper type

• Detection: media-type-supported[rfc8011] - e.g. stationery, photographic, cardstock.
• Client Preview: Partial — a client can only approximate the visual effect (e.g. a "glossy photo" swatch/texture hint); actual ink laydown/gloss behavior is not renderable on-screen.
• Job Submission / Job Ticket: media-type[rfc8011] or media-col (media-type member).
• Expected Result: Printer adjusts print engine settings (heat, speed, ink laydown) appropriate to the media type; mismatched type/tray content may trigger printer-state-reasons = media-type-mismatch (vendor extension) or output quality degradation with no protocol-level error.

Borderless printing

• Detection: media-col-database[jobext] entries where media-*-margin-supported[rfc8011] includes 0, or a media-bottom-margin / media-top-margin / media-left-margin / media-right-margin -supported range includes 0 for the requested size.
• Client Preview: Yes — margin values are known locally, so the client can render the page with/without border guides accurately.
• Job Submission / Job Ticket: media-col[jobext] with all four margin members set to 0.
• Expected Result: Printer prints full-bleed with no white border; if the printer cannot achieve zero margin for that media/size combination, request should be rejected with unsupported-attribute error rather than silently clipped.

Margins

• Detection: media-*-margin-supported[rfc8011] - four separate attributes: top, bottom, left, right - each a set or range of supported values in hundredths of millimeters.
• Client Preview: Yes — margin/imageable-area rectangles can be drawn directly over the page preview.
• Job Submission / Job Ticket: media-col[jobext] with media-*-margin members.
• Expected Result: Printer honors the requested non-printable-area offsets; job content outside the achievable imageable area is clipped and should be reflected via job-state-reasons = compression-error is not applicable here — instead vendors may report via job-state-message only, since IPP has no standard "content clipped" reason.

Overprint / bleed expansion

• Detection: media-overprint-supported[nodriver] boolean gate, plus media-overprint-distance-supported[nodriver] - a range, in hundredths of millimeters - and media-overprint-method-supported[nodriver] - values none, extend, scale.
• Client Preview: Yes — distance and method are both known locally, so the client can render the expanded Finished Page Image relative to the media's margins accurately (extend replicates edge pixel values outward; scale enlarges the whole Impression).
• Job Submission / Job Ticket: media-overprint[nodriver] collection with overprint-distance and overprint-method members.
• Expected Result: Printer expands each Finished Page Image beyond the selected media size's margins by the requested distance using the requested method, so that content still reaches the physical edge of the sheet despite feed/registration tolerance. This is distinct from Borderless printing: borderless requests zero margins outright, while overprint intentionally over-extends the imprinted area past whatever margins are in effect (zero or not) to cover registration error.

Output tray / bin selection

• Detection: output-bin-supported[rfc8011] - list of bin keywords, e.g. top, rear, face-down.
• Client Preview: No — affects physical output routing only, not page content.
• Job Submission / Job Ticket: output-bin[rfc8011].
• Expected Result: Finished sheets are routed to the specified physical bin; unsupported bin selection causes client-error-attributes-or-values-not-supported.

---

2. Page Layout & Orientation

Portrait / landscape orientation

• Detection: orientation-requested-supported[rfc8011] - values: portrait, landscape, reverse-landscape, reverse-portrait.
• Client Preview: Yes — a straightforward local rotation of the rendered page canvas.
• Job Submission / Job Ticket: orientation-requested[rfc8011].
• Expected Result: Rasterization/imaging pipeline rotates content accordingly before marking; combined with sides for duplex, printer must respect edge-binding semantics per orientation.

N-up (multiple logical pages per sheet)

• Detection: number-up-supported[rfc8011] - set of integers, typically 1,2,4,6,9,16.
• Client Preview: Yes — imposition math (scale + grid placement) is fully client-computable from the source page geometry.
• Job Submission / Job Ticket: number-up[rfc8011].
• Expected Result: Printer imposes N logical pages onto each physical sheet at reduced scale; job's job-media-sheets-completed will be lower than job-impressions-completed by the N-up factor.

N-up layout order

• Detection: number-up-layout-supported[jobext] - values like lrtb, tblr, rlbt, etc.
• Client Preview: Yes — same imposition preview as N-up, with cell ordering following the selected layout keyword.
• Job Submission / Job Ticket: number-up-layout[jobext].
• Expected Result: Logical page placement on the sheet follows the specified reading order; only meaningful when number-up > 1.

Page ranges

• Detection: page-ranges-supported[rfc8011] - boolean - indicates whether the printer honors range restriction at all.
• Client Preview: Yes — the client can filter/highlight the excluded pages in a thumbnail strip before submission.
• Job Submission / Job Ticket: page-ranges[rfc8011] (set of one or more lower-upper integer ranges).
• Expected Result: Only the specified page numbers are marked; job-impressions-completed should track only the printed subset, and page-ranges-supported = false should cause the printer to either reject the attribute or print the full document while ignoring it (per RFC 8011 unsupported-attribute handling rules).

Reverse / face-up-down page order

• Detection: output-bin-supported[rfc8011] entries distinguishing face-up vs. face-down bins, since IPP has no dedicated "reverse order" attribute. face-up/face-down in the bin keyword tells the Client which physical stacking behavior to expect, which in turn tells the Client whether it needs to send pages in forward or reverse order.
• Client Preview: No — the effect is on physical stack order, not on-screen page content.
• Job Submission / Job Ticket: output-bin[rfc8011] chosen to match the desired stacking order; on a streaming printer (one that can't spool and internally reorder the whole Job), a Client targeting a face-up bin MUST itself reorder the Document's pages before transmission — last page first — since whatever page prints last ends up on top of the face-up stack and needs to be the document's first page for correct reading order. This reordering is Client-side ("driver") logic; there is no IPP attribute that requests it directly.
• Expected Result: Physical sheet order in the output tray matches logical document order as viewed by the user — face-down delivery typically yields correct reading order with pages sent in the document's natural order, while face-up delivery requires the Client to have sent pages in reverse order for the same result.

Scaling / fit-to-page

• Detection: print-scaling-supported[jobext] - values: auto, auto-fit, fill, fit, none.
• Client Preview: Yes — the scaling transform against the chosen media size is directly renderable locally.
• Job Submission / Job Ticket: print-scaling[jobext].
• Expected Result: Document content is scaled to the target media dimensions per the selected mode; none requires content already sized to the media or it will clip.

Cover pages

• Detection: cover-back-supported / cover-front-supported[ppx] - collections describing available cover media/source - plus cover-sheet-info-supported[ppx].
• Client Preview: Partial — the client can show a placeholder cover sheet (blank or media swatch) in the page sequence, but not the actual pre-printed stock content, which lives on the printer side.
• Job Submission / Job Ticket: cover-back, cover-front[ppx] collections (each with e.g. cover-type, media-col).
• Expected Result: Printer inserts blank or pre-printed cover sheets from the specified source before/after the document body; job-media-sheets-completed includes the cover sheets.

---

3. Duplex / Sides

One-sided vs. two-sided printing

• Detection: sides-supported[rfc8011] - values: one-sided, two-sided-long-edge, two-sided-short-edge.
• Client Preview: Yes — a "book-style" flip preview showing front/back page pairing and binding edge can be rendered entirely client-side.
• Job Submission / Job Ticket: sides[rfc8011].
• Expected Result: Printer engages duplexer hardware for two-sided values; if sides-supported lacks duplex values (simplex-only device), requesting duplex must fail attribute validation rather than silently print simplex. job-media-sheets-completed reflects physical sheets, which is roughly half of job-impressions-completed for duplex jobs.

---

4. Color & Image Quality

Color vs. grayscale/monochrome

• Detection: print-color-mode-supported[nodriver] - values: auto, auto-monochrome, bi-level, color, highlight, monochrome, process-bi-level, process-monochrome.
• Client Preview: Yes — a grayscale/bi-level render of the source content is a reasonable local approximation, though exact printer halftoning/dither will differ from the on-screen simulation.
• Job Submission / Job Ticket: print-color-mode[nodriver].
• Expected Result: Marking engine uses full-color or black-only toner/ink path accordingly; job accounting attributes (job-accounting-sheets variants) may distinguish color vs. mono page counts for billing.

Custom / vendor-defined color modes & preview

• Detection: print-color-mode-supported[nodriver] MAY list unregistered (vendor- or site-defined) keywords in addition to the standard set, e.g. a manufacturer's proprietary "legacy color compatibility" mode or an administrator-deployed "blueprint output" mode; when it does, the Printer SHOULD also expose print-color-mode-icc-profiles[nodriver] - a collection listing a preview ICC profile (profile-uri member) for each such print-color-mode value - plus localized labels and tooltip help via the printer-strings-uri[nodriver] message catalog.
• Client Preview: Yes, for custom modes with a profile advertised — the client downloads the referenced ICC profile and can soft-proof the color transformation before submission; this profile is for preview only and is distinct from the profiles in printer-icc-profiles[nodriver], which support print-time color management.
• Job Submission / Job Ticket: print-color-mode[nodriver] set to the selected (possibly vendor-defined) keyword.
• Expected Result: Printer performs the color transformation associated with that custom mode; each collection in print-color-mode-icc-profiles MUST reference a unique print-color-mode value, so the client can look up the matching preview profile for whatever keyword the End User selects. A Client can also confirm this ahead of submission via Validate-Job: if the Printer supports printer-icc-profiles[nodriver], it MUST return profile-uri-actual[nodriver] in the response, naming exactly which ICC profile it will actually use for the submitted Job Template attributes — removing any guesswork about which profile among several candidates applies to this specific ticket.

Print quality

• Detection: print-quality-supported[rfc8011] - values: draft, normal, high.
• Client Preview: No — the perceptible difference comes from printer-side halftoning/pass count, which the client has no data to simulate accurately.
• Job Submission / Job Ticket: print-quality[rfc8011].
• Expected Result: Trade-off between speed and fidelity is applied (dither pattern, pass count); no separate status attribute confirms quality applied — verified only by visual/measured output.

Extensible print quality (named quality Presets)

• Detection: job-presets-supported[nodriver] entries carrying preset-category[nodriver] = print-quality. NODRIVER §4.9 introduces this specifically because the legacy print-quality[rfc8011] enum (draft/normal/high) "is not easily extensible": a Printer can advertise any number of named, quality-category Presets instead — e.g. a manufacturer's proprietary "X Magic" mode, or an administrator-deployed "Eco-Draft" mode with reduced toner usage for billing purposes. print-processing-attributes-supported[nodriver] separately lists which underlying Job/Document Template attributes (e.g. print-content-optimize, print-darkness, printer-resolution) a quality Preset may bundle, so a Client can group them coherently in its own UI.
• Client Preview: Partial — same as Presets generally: individual bundled attribute values can be previewed wherever the underlying attribute supports it (e.g. printer-resolution), but there's no dedicated rendering of "quality" itself beyond that.
• Job Submission / Job Ticket: Same mechanism as Presets — the Client copies the selected quality Preset's Job Template attributes into the ticket; the legacy print-quality attribute remains valid and continues to work in parallel for Clients that only implement the fixed 3-value enum.
• Expected Result: If a Printer offers any print-quality-category Presets, it MUST offer one for every value in print-quality-supported, so the extensible mechanism is strictly additive rather than a replacement with coverage gaps; the Printer then applies the bundled settings exactly as it would for an equivalent hand-built ticket. This lets a Printer expose quality levels that don't map onto draft/normal/high (e.g. "Eco-Draft", "Photo Best") without a Client needing a driver that already knows about them.

Resolution

• Detection: printer-resolution-supported[rfc8011] - set of resolution collections: cross-feed/feed direction values + units.
• Client Preview: No — screen DPI and print DPI are decoupled; a client cannot meaningfully show "this is what 600 vs 1200 dpi looks like" without printer-accurate rasterization.
• Job Submission / Job Ticket: printer-resolution[rfc8011].
• Expected Result: Rasterization occurs at the requested DPI; if the requested resolution is not in the supported set, printer should reject or clamp to nearest supported value and report actual value used only if the vendor implements job-actual attributes (non-standard).

Rendering intent

• Detection: print-rendering-intent-supported[nodriver] - values like absolute, auto, perceptual, relative - gated behind Printer support for printer-icc-profiles.
• Client Preview: Partial — a client with the printer's ICC profile and a color-managed rendering pipeline can soft-proof the intent reasonably well; without the profile, only a generic approximation is possible.
• Job Submission / Job Ticket: print-rendering-intent[nodriver].
• Expected Result: Color management engine applies the specified ICC rendering intent during color conversion; primarily affects photographic content with out-of-gamut colors.

---

5. Finishing

Stapling

• Detection: finishings-supported[rfc8011] including staple value keywords - e.g. staple-top-left, staple-dual-left - or finishings-col-database[fin] for combined finishing capability sets.
• Client Preview: Partial — a client can overlay a staple/staple-count icon at the correct corner/edge of the page thumbnail as a schematic indicator, but cannot render the physical staple itself.
• Job Submission / Job Ticket: finishings[rfc8011] (set of keyword values) or finishings-col[fin].
• Expected Result: Finisher unit staples output at the specified position/count; unsupported staple position on a document exceeding finisher sheet-count capacity should cause client-error-attributes-or-values-not-supported at Validate-Job time, not a silent skip.

Punching

• Detection: finishings-supported[rfc8011] punch keywords - e.g. punch-top-left, punch-dual-left - often paired with finishings-col-database[fin] entries scoped to specific media sizes.
• Client Preview: Partial — same as stapling, a schematic hole-position overlay is feasible; exact physical placement is printer-defined.
• Job Submission / Job Ticket: finishings / finishings-col[fin].
• Expected Result: Holes are punched at positions matching regional standard (2-hole/4-hole per locale); combination with incompatible media size should be rejected.

Folding

• Detection: finishings-supported fold keywords, plus folding-direction-supported and folding-offset-supported[fin] for fine control.
• Client Preview: Partial — a schematic fold-line overlay (diagram style) is achievable; a true physical fold simulation is not.
• Job Submission / Job Ticket: finishings (fold values) or finishings-col[fin] with folding-direction, folding-offset members.
• Expected Result: Sheets exit pre-folded (half-fold, tri-fold, etc.); offset/direction attributes only apply meaningfully when the base fold finishing is also selected.

Trimming

• Detection: finishings-supported trim keywords, trimming-reference-edge-supported, trimming-offset-supported, trimming-type-supported[fin].
• Client Preview: Partial — a client can draw the trim line/offset on the page preview as a guide overlay.
• Job Submission / Job Ticket: finishings-col[fin] with trimming-reference-edge, trimming-offset, trimming-type members.
• Expected Result: Output edges are cut per spec; typically used with booklet/saddle-stitch jobs to square the final edge.

Booklet making / saddle stitch

• Detection: finishings-supported bind/saddle-stitch keywords, or a bundled finishing-template-supported[fin] entry - e.g. booklet-maker.
• Client Preview: Yes for imposition (page reorder/rotate math is client-computable, same as N-up), partial for the physical fold/staple/trim result, which can only be shown schematically.
• Job Submission / Job Ticket: finishings or finishing-template[fin] (single keyword invoking a pre-defined bundle of imposition + fold + staple settings).
• Expected Result: Printer automatically applies correct page imposition (reordering/rotation) in addition to physical fold/staple/trim; client should NOT also set number-up/page-ranges manually when using a booklet finishing template, as behavior is undefined if they conflict.

Finishing templates

• Detection: finishing-template-supported[fin] - list of named finishing bundles. Note this is a FIN-specific mechanism scoped to finishings-col settings only; it is distinct from the general-purpose, any-attribute Presets mechanism (see Presets below).
• Client Preview: No, in general — since the template's expanded attribute set is printer-defined and not disclosed to the client ahead of Get-Printer-Attributes describing it in detail, preview fidelity depends entirely on how much the client already knows about that named template.
• Job Submission / Job Ticket: finishing-template[fin].
• Expected Result: Single attribute expands to a printer-defined combination of finishings-col settings; simplifies client logic at the cost of fine-grained control.

---

6. Job Management & Control

Copies

• Detection: copies-supported[rfc8011] - range, e.g. 1-99.
• Client Preview: No content-level preview needed beyond showing the requested count as text (the pages themselves are unchanged).
• Job Submission / Job Ticket: copies[rfc8011].
• Expected Result: Printer produces the requested count of the full document; job-impressions-completed accumulates across all copies, and job-media-sheets-completed scales with copies × sheets-per-set.

Collation

• Detection: sheet-collate-supported[rfc8011] - values: collated, uncollated - sometimes replaced/augmented by multiple-document-handling-supported[rfc8011] for multi-document jobs.
• Client Preview: Partial — a schematic "stack order" diagram (set-by-set vs. page-by-page) can illustrate the concept, though it is not a rendering of actual page content.
• Job Submission / Job Ticket: sheet-collate or multiple-document-handling[rfc8011].
• Expected Result: For copies > 1, output is either grouped as complete sets (collated) or grouped by page number across sets (uncollated); mismatch between requested collation and finisher capability (e.g. stapling requires collated) should fail validation.

Job priority

• Detection: job-priority-supported[rfc8011] - range, typically 1-100.
• Client Preview: No — has no visual/page-level manifestation.
• Job Submission / Job Ticket: job-priority[rfc8011].
• Expected Result: Scheduler orders pending jobs in the queue by priority value (higher = sooner); observable via relative ordering in Get-Jobs results, not a direct status attribute.

Job hold / scheduled release

• Detection: job-hold-until-supported[rfc8011] - keyword set, e.g. indefinite, day-time, evening, no-hold, or supports arbitrary date-time values.
• Client Preview: No — a scheduling/queue-state feature, not a page-rendering one.
• Job Submission / Job Ticket: job-hold-until[rfc8011] (keyword or date-time).
• Expected Result: Job enters job-state = pending-held with job-state-reasons = job-hold-until-specified, then transitions to pending/processing at the resolved time or upon explicit Release-Job.

Job error-handling behavior

• Detection: job-error-action-supported[nodriver] - keyword set: abort-job, cancel-job, continue-job, suspend-job - and job-error-action-default[nodriver] for the value used if the Client omits the attribute.
• Client Preview: No — a queue/processing policy with no visual manifestation.
• Job Submission / Job Ticket: job-error-action[nodriver].
• Expected Result: When the Printer hits a Job or Document processing error (e.g. missing resource, out-of-memory), it takes the requested action: abort-job stops and moves the Job to aborted (job-state-reasons includes aborted-by-system); cancel-job stops as if a Cancel-Job request had been received (job-canceled-by-user); continue-job skips to the next Document or completes the Job if it was the last one; suspend-job stops and moves the Job to processing-stopped as if Suspend-Current-Job had been received (job-suspended-by-user).

Presets (saved job attribute bundles)

• Detection: job-presets-supported[nodriver] - collection listing the Printer's named Presets. Each collection carries a REQUIRED preset-name member, a RECOMMENDED preset-category member (feature, print-quality, or site), and one or more Job Template attributes and values the Preset applies. Unlike Finishing templates, a Preset can bundle any Job Template attributes, not just finishings-col settings.
• Client Preview: Partial — the client can preview the individual Job Template attribute values contained in the Preset using whatever preview support exists for each underlying attribute (media, sides, print-quality, etc.); there is no dedicated preview for the Preset as a whole.
• Job Submission / Job Ticket: No dedicated submission attribute — the Client copies all Job Template attributes and values from the selected Preset directly into the Job Ticket (including member attributes the Client doesn't natively support) before submission.
• Expected Result: Printer processes the resulting Job Ticket exactly as it would an equivalent hand-built one; the copied attribute values MUST NOT conflict with one another per job-constraints-supported, and a Printer supporting a 'print-quality' Preset category MUST provide one such Preset for each value in print-quality-supported. See Extensible print quality for that category's specific role as a replacement for the non-extensible legacy print-quality enum.

---

7. Output & Delivery

Job sheets / banner pages

• Detection: job-sheets-supported[rfc8011] - keywords like none, standard, first-page - or job-sheets-col-supported[ppx] for richer bundle (media, info fields).
• Client Preview: Partial — a client can show a generic banner-page placeholder in the page sequence, but the actual printer-generated content (job/user metadata layout) is not known client-side.
• Job Submission / Job Ticket: job-sheets[rfc8011] or job-sheets-col[ppx].
• Expected Result: A banner/separator page identifying the job/user is printed at the start (and/or end) of output; counted separately from document content in job-media-sheets-completed if the printer implements the distinction.

Separator sheets between documents

• Detection: separator-sheets-supported boolean plus separator-sheets-type-supported[ppx] - values: none, slip-sheets, start-sheet, end-sheet, both-sheets.
• Client Preview: Yes for placement (client knows document boundaries and can insert placeholder sheets at the right points in a thumbnail strip); the sheet's own content (if marked) is printer-defined.
• Job Submission / Job Ticket: separator-sheets[ppx] collection with separator-sheets-type member.
• Expected Result: For multi-document jobs, blank/marked separator sheets are inserted between constituent documents in the output stack.

---

8. Release Printing & Document Security

PIN Printing (Legacy Push Release Printing)

• Detection: job-password-supported[epx] - Printer Description attribute indicating support - and job-password-encryption-supported[epx]
  • Printer Description attribute listing supported hash schemes, e.g. none.
• Client Preview: N/A — security/workflow feature with no visual page impact.
• Job Submission / Job Ticket: job-password[epx] operation attribute (encoded per the job-password-encryption[epx] operation attribute), supplied on a Job Creation operation or Validate-Job.
• Expected Result: Job is accepted and spooled but held (job-state-reasons = job-password-wait in some implementations) until the correct PIN is entered at the device UI/panel, at which point processing proceeds.

Push Job Release (PIN-protected)

• Detection: job-release-supported[epx] - Printer Description attribute listing the job-password release method. Legacy PIN Printing is now a sub-case of this larger feature framework.
• Client Preview: N/A — security/workflow feature with no visual page impact.
• Job Submission / Job Ticket: job-password[epx] operation attribute (encoded per the job-password-encryption[epx] operation attribute), supplied on a Job Creation operation or Validate-Job.
• Expected Result: Job is accepted and spooled but held (job-state-reasons = job-password-wait in some implementations) until the correct PIN is entered at the device UI/panel, at which point processing proceeds.

Pull Job Release (pull printing)

• Detection: TBD (Printer Description attribute needed to indicate that the Printer is an Infrastructure Printer).
• Client Preview: N/A — security/workflow feature with no visual page impact.
• Job Submission / Job Ticket: job-password[epx] operation attribute (encoded per the job-password-encryption[epx] operation attribute), supplied on a Job Creation operation or Validate-Job.
• Expected Result: Job is accepted and spooled but held (job-state-reasons = job-password-wait in some implementations) until the correct PIN is entered at the device UI/panel, at which point processing proceeds.

Printing password-protected documents

• Detection: document-password-supported[nodriver] - integer giving the maximum accepted password length; REQUIRED if the Printer lists application/pdf in document-format-supported. Distinct from the job-password[epx] release-printing PIN above: this password unlocks the submitted document's own content-level protection (e.g. an encrypted PDF), not the Printer's release queue.
• Client Preview: N/A — a Client's own document renderer may show a preview once it has the password locally, but there is no IPP-level preview mechanism for a locked document's contents.
• Job Submission / Job Ticket: document-password[nodriver] operation attribute (unencrypted passphrase, OAuth token, or similar) supplied with Print-Job, Print-URI, Send-Document, or Send-URI; Client and Printer MUST negotiate TLS before this attribute is sent or accepted.
• Expected Result: Printer uses the supplied value to unlock the protected document before processing. A missing or incorrect password returns client-error-document-password-error[nodriver] (0x418) and adds document-password-error to job-state-reasons/document-state-reasons[nodriver]; a password that unlocks the document but doesn't grant print permission returns client-error-document-permission-error[nodriver] (0x419) with reason keyword document-permission-error. Detected embedded security issues (virus, trojan, other malicious content) return client-error-document-security-error[nodriver] (0x41A) with reason document-security-error, and unprintable content (file size, format version, complexity) returns client-error-document-unprintable-error[nodriver] (0x41B) with reason document-unprintable-error; for these last two, implementation or site policy decides whether the Printer aborts the whole Job or prints the unaffected Documents and marks the Job completed-with-errors.

Job Account

• Detection: job-account-id-supported, job-account-type-supported, job-accounting-user-id-supported[jobext] - booleans indicating the Printer will record/enforce these. This is the informal Job-to-account/user association mechanism only — distinct from the broader "Job Accounting" question of what happens to that data once recorded (see note below).
• Client Preview: No — metadata-only feature, though a client can usefully show an estimated cost/page-count summary derived from other already-previewable attributes (copies, sides, color mode).
• Job Submission / Job Ticket: job-account-id, job-account-type, job-accounting-user-id[jobext].
• Expected Result: Printer associates the job with the supplied account/type/user (e.g. a cost-center code typed at the device or print dialog) for reporting/billing; may reject the job with client-error-not-authorized if the account is invalid/over quota (implementation-specific, not standardized in core IPP).
• Note — gap: Beyond this association, IPP's actual "Job Accounting" story (the Job Description attributes — job-accounting-sheets[jobext] and similar — that a Printer creates/maintains for a completed Job, and for how long) is thinner than the feature name suggests. There's no attribute we're aware of governing how long a Printer must retain a Job's accounting data before it becomes unretrievable, and no attribute reporting per-colorant quantity consumed by a Job (only page/sheet counts) — both look like real gaps worth raising with PWG rather than documented, testable behavior today.

---

9. Status & Job Control

Printer status

• Detection: N/A (baseline) — read via Get-Printer-Attributes: printer-state (values: idle, processing, stopped) and printer-state-reasons[rfc8011] - e.g. media-jam, toner-low, door-open.
• Client Preview: N/A — status display, not an output preview.
• Job Submission / Job Ticket: N/A — read-only.
• Expected Result: State reflects real-time device condition; clients should poll or subscribe rather than assume state is static across a session.

Supply levels

• Detection: printer-supply-supported boolean gate; actual values in printer-supply (collection per consumable: type, level, unit), printer-supply-description[epx].
• Client Preview: N/A — status display only.
• Job Submission / Job Ticket: N/A — read-only.
• Expected Result: Level values update periodically; low/empty conditions typically also surface via corresponding printer-state-reasons (e.g. marker-supply-low, marker-supply-empty).

Tray/bin status detail

• Detection: printer-input-tray[nodriver] / printer-output-tray[nodriver]
  • 1setOf structured key/value strings, one per tray, encoding level, maxcapacity, mediafeed/mediaxfeed dimensions, name, status, type, and (where the Printer can sense it) mediacolor, medianame, mediatype, mediaweight. Cardinality matches media-source-supported[jobext] - the i-th tray status corresponds to the i-th tray keyword.
• Client Preview: No — status display, not an output preview.
• Job Submission / Job Ticket: N/A — read-only.
• Expected Result: Client can show live per-tray fill level and currently-loaded media (e.g. "Tray 2: 45% full, Letter Plain") beyond the static capability lists in media-source-supported / media-col-database[jobext]; a tray reported empty or jammed should also be reflected in the corresponding printer-state-reasons.

Identify this printer

• Detection: identify-actions-supported[nodriver] - keywords display, flash, sound, speak; a Printer that is a Physical Device MUST implement the Identify-Printer[nodriver] operation.
• Client Preview: N/A — a physical/audible action at the device, not a print-output preview.
• Job Submission / Job Ticket: N/A — not a Job operation. Client issues Identify-Printer[nodriver] directly, optionally supplying identify-actions[nodriver] (a subset of the supported actions) and a message for the display/speak actions.
• Expected Result: Printer performs the requested identification — flashing lights, sounding, or displaying/speaking a message on its console — so the End User can confirm which physical device they're interacting with; the Printer MAY reject the request if it isn't from an authenticated user.

Cancel Job

• Detection: No -supported gate — always available per RFC 8011[rfc8011]; effective scope constrained by operations-supported including Cancel-Job.
• Client Preview: N/A — post-submission control action, not a pre-print feature.
• Job Submission / Job Ticket: Cancel-Job[rfc8011] operation (references job-id/job-uri).
• Expected Result: job-state transitions to canceled; any in-progress marking stops as soon as practical, with job-state-reasons including job-canceled-by-user or job-canceled-by-operator.

Job status monitoring

• Detection: N/A (baseline operation) — client polls Get-Job-Attributes[rfc8011].
• Client Preview: N/A — post-submission status, not a preview concern.
• Job Submission / Job Ticket: Not a submission-time feature; read via job-state, job-state-reasons, job-state-message, job-impressions-completed, job-media-sheets-completed[rfc8011].
• Expected Result: Attribute values update in near-real-time as the job progresses through pending → processing → completed/aborted/canceled.

Job resubmission / restart

• Detection: operations-supported includes Restart-Job[jobext]; not universally implemented.
• Client Preview: N/A — reuses the original submission's already-known preview, no new preview step involved.
• Job Submission / Job Ticket: Restart-Job[jobext] operation on a completed/aborted job that the printer has retained (subject to job-hold-until / multiple-operation-time-out retention policy).
• Expected Result: A new processing pass begins using the originally submitted document data; only viable while the printer still has the job document retained (job-state-reasons = processing-to-stop-point vs. purged).

Suspend / resume

• Detection: operations-supported includes Suspend-Current-Job / Resume-Job[jobext].
• Client Preview: N/A — post-submission control action.
• Job Submission / Job Ticket: Respective operation[jobext] invoked against the active job.
• Expected Result: job-state = processing-stopped with job-state-reasons = job-suspended while suspended; resumes marking from (implementation-defined) point on Resume-Job.

---

10. Printer Discovery & Selection (IPP Everywhere-specific)

Select printer by geo-location

• Detection: printer-geo-location[nodriver] - a geo: URI, or the unknown out-of-band value if the location hasn't been configured.
• Client Preview: N/A — a discovery/selection aid, not a print-output feature.
• Job Submission / Job Ticket: N/A — a read-only discovery attribute for the common case; if the Printer supports changing it, it MUST list printer-geo-location in printer-settable-attributes-supported[rfc3380], and the Client uses Set-Printer-Attributes[rfc3380] to set it — a Printer-level configuration action, not a per-job one.
• Expected Result: Client can sort, filter, or display candidate printers by physical proximity (e.g. nearest first) before submission; a Printer with no configured location reports unknown rather than a misleading default.

Filter printers by kind

• Detection: printer-kind[nodriver] - standard keywords (document, photo, label, envelope, disc, postcard, receipt, roll, large-format) or site-/vendor-defined name values - together with ipp-features-supported[nodriver], which lists coarser IPP extension-feature flags (document-object, page-overrides, production, subscription-object); NODRIVER groups these two attributes together as the mechanism for a Printer to "declare support for high-level features and capabilities" that a Client can filter discovery results on. Before any IPP round trip, the same filtering can also be driven by the DNS-SD/mDNS TXT record's kind key - a comma-separated list mirroring the printer-kind keyword values, advertised alongside the Printer's other discovery TXT fields[ippeve]; this specific key isn't defined in NODRIVER itself and hasn't been verified against a locally available copy of the Bonjour Printing Specification / IPP Everywhere, so treat the exact key name as indicative rather than normative.
• Client Preview: N/A — a discovery/selection aid, not a print-output feature.
• Job Submission / Job Ticket: N/A — a read-only discovery attribute (client-settable the same way as printer-geo-location above, if listed in printer-settable-attributes-supported[rfc3380]).
• Expected Result: Client can show only printers matching the task at hand (e.g. hide plain document printers when the End User is printing a photo or a shipping label) without inspecting low-level media/finishing attributes to infer capability itself; when filtering from DNS-SD browse results alone, the Client can narrow the list before ever issuing Get-Printer-Attributes.

Printer resident icons

• Detection: printer-icons[nodriver] - REQUIRED if supported; https/http URIs to RGBA PNG images, in 48x48, 128x128, and/or 512x512 pixel squares, depicting the physical printer.
• Client Preview: N/A — a printer-selection affordance, not a print-output preview.
• Job Submission / Job Ticket: N/A.
• Expected Result: Client renders the Printer's own icon in a printer-picker UI instead of a generic placeholder; all listed images MUST share the same visual perspective, and if the Printer supplies only one image it MUST be 128x128.

---

11. Invisible / Facilitator Features

These attributes exist to support administrators, fleet-management tooling, or background access/transport security — not as a directly-chosen print-dialog option or an independently observable print-time behavior. They're tracked here for completeness (and because some, like Access control or Encryption in transit, still gate whether a print attempt succeeds at all) but are lower priority for end-user functional testing than Sections 1–10.

Media weight / thickness

• Detection: media-col-database[jobext] entries include media-weight-metric alongside size/type/source.
• Client Preview: No — purely a physical/engine setting with no rendering surface.
• Job Submission / Job Ticket: media-col[jobext] (media-weight-metric member), generally bundled with media-type since weight is rarely set independently.
• Expected Result: Printer selects appropriate fuser/feed path settings; no dedicated top-level *-supported attribute exists, so support is inferred from media-col-database entries only — in practice this shows up, if at all, as an admin-configured site-specific media type in a management console rather than a Client-facing control.

Storing Presets to the Printer

• Detection: printer-settable-attributes-supported[rfc3380] includes job-presets-supported as one of its values, indicating the Printer allows a Client to add or update Presets remotely via Set-Printer-Attributes[rfc3380]; if job-presets-supported is absent from this list, the Printer's Presets are read-only from the Client's perspective (e.g. manufacturer- or administrator-deployed only, per the use cases in [nodriver]). This sits between a print-dialog feature and a management/administration action, since it changes what every Client sees, not just the one making the change.
• Client Preview: No — this is a management action on the Printer object itself, not a Job; any preview of the resulting Preset's effect is the same partial, per-attribute preview described under Presets.
• Job Submission / Job Ticket: N/A — not a Job Template attribute at all. Instead, the Client issues a Set-Printer-Attributes[rfc3380] request supplying the complete desired job-presets-supported value (per RFC 3380, a 1setOf attribute's supplied values replace the attribute's entire prior value, so the Client MUST include existing Presets it wants to keep alongside the new/changed one).
• Expected Result: If every supplied collection validates — the attribute is listed in printer-settable-attributes-supported, and none of its Job Template attribute/value combinations conflict per job-constraints-supported[nodriver] — the Printer atomically replaces its job-presets-supported value, and the new/updated Preset becomes visible to all Clients on their next Get-Printer-Attributes. Otherwise the Printer MUST reject the entire request (no partial update) with the appropriate client error, e.g. client-error-attributes-not-settable if job-presets-supported isn't Client-settable, or a conflicting-attributes error if a supplied Preset's values are mutually exclusive.

Access control (who can print)

• Detection: requesting-user-name-allowed / requesting-user-name-denied[rfc8011] - Printer Description ACL attributes - and uri-authentication-supported[rfc8011] - e.g. basic, digest, certificate, negotiate. requesting-user-uri-supported[nodriver] (Printers MUST supply true) and requesting-user-uri-schemes-supported[nodriver] (e.g. mailto, urn) indicate the Printer also accepts a stable per-user identity URI alongside the plain requesting-user-name.
• Client Preview: N/A — access control, not a page/output feature.
• Job Submission / Job Ticket: requesting-user-name[rfc8011] operation attribute, authenticated per the negotiated HTTP/TLS auth scheme, optionally supplemented by requesting-user-uri[nodriver] - a URI (e.g. a urn: UUID or mailto: address) that uniquely identifies the requesting user, since requesting-user-name values are often not unique (e.g. multiple "John Doe"s).
• Expected Result: Requests from disallowed users are rejected with client-error-not-authorized; allowed users proceed normally. The Printer sets job-originating-user-uri[nodriver] (or notify-subscriber-user-uri[nodriver] for a subscription) to the most authenticated URI it can obtain from its own authentication service, falling back to the Client-supplied requesting-user-uri only when no authenticated URI is available.

Encryption in transit

• Detection: uri-security-supported[rfc8011] - values: none, tls - printer-uri-supported listing ipps:// endpoints.
• Client Preview: N/A — transport-layer concern, not a print-output feature.
• Job Submission / Job Ticket: N/A — negotiated at transport layer (TLS handshake), not via a Job Template attribute.
• Expected Result: All IPP operation traffic for the job is encrypted; a printer requiring TLS should reject plaintext ipp:// connections at the transport level before any IPP semantics are evaluated.

Firmware/version reporting

• Detection: printer-firmware-name[nodriver] - 1setOf name, one per firmware component - gates parallel, same-cardinality arrays printer-firmware-version[nodriver], printer-firmware-string-version[nodriver], and printer-firmware-patches[nodriver], indexed together (the i-th value of each describes the same component).
• Client Preview: N/A — device information display only, though it can reasonably share UI space with Supply levels in a printer status app or print dialog.
• Job Submission / Job Ticket: N/A — read-only.
• Expected Result: Client or administrator can display or log the exact firmware component names, versions, and applied patches for support and fleet-management purposes; has no protocol-level effect on Job processing. The forthcoming IPP Firmware Update Extensions v1.0 is expected to add the operations/attributes needed for a Client to actually check for, describe, and install new firmware — this entry covers reporting only, not that update workflow.

Event notifications (subscriptions)

• Detection: notify-events-supported, notify-pull-method-supported, notify-schemes-supported[rfc3995].
• Client Preview: N/A — asynchronous status mechanism, not a preview concern.
• Job Submission / Job Ticket: Create-Printer-Subscription / Create-Job-Subscription[rfc3995] with notify-events (e.g. job-completed, printer-state-changed) and a delivery method (notify-recipient-uri or polling via Get-Notifications).
• Expected Result: Subscribing client receives (or can poll for) event notifications matching the requested event set until the subscription expires (notify-lease-duration) or is canceled. This is the transport underneath status displays like Printer status and Job status monitoring; those entries cover what the End User actually sees, this one covers how the Client gets told about it asynchronously instead of only by polling.

---

References

[rfc8011] RFC 8011, Internet Printing Protocol/1.1: Model and Semantics — https://www.rfc-editor.org/info/rfc8011/

[rfc3380] RFC 3380, Internet Printing Protocol (IPP): Job and Printer Set Operations — https://www.rfc-editor.org/info/rfc3380/

[fin] PWG 5100.1-2022, IPP Finishings 3.0 (FIN) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippfinishings30-20220527-5100.1.pdf

[ppx] PWG 5100.3-2023, IPP Production Printing Extensions v2.0 (PPX) — https://ftp.pwg.org/pub/pwg/candidates/cs-ippppx20-20230131-5100.3.pdf

[docobject] PWG 5100.5-2019, IPP Document Object v1.1 (DOCOBJECT) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippdocobject12-20240517-5100.5.pdf

[jobext] PWG 5100.7-2023, IPP Job Extensions v2.1 (JOBEXT) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippjobext21-20230210-5100.7.pdf

[epx] PWG 5100.11-2024, IPP Enterprise Printing Extensions v2.0 (EPX) — https://ftp.pwg.org/pub/pwg/candidates/cs-ippepx20-20240315-5100.11.pdf

[nodriver] PWG 5100.13-2023, IPP Driver Replacement Extensions v2.0 (NODRIVER) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippnodriver20-20230301-5100.13.pdf

[ippeve] PWG 5100.14-2020, IPP Everywhere v1.1 - https://ftp.pwg.org/pub/pwg/candidates/cs-ippeve11-20200515-5100.14.pdf

[infra] PWG 5100.18-2025, IPP Shared Infrastructure Extensions v1.1 (INFRA) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra11-20250502-5100.18.pdf

[ig] PWG 5100.19-2015, IPP Implementor's Guide v2.0 (IG) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf

[selfcert] PWG 5100.20-2020, IPP Everywhere™ Printer Self-Certification Manual v1.1 (SELFCERT) - https://ftp.pwg.org/pub/pwg/candidates/cs-ippeveselfcert11-20200515-5100.20.pdf

[rfc3995] RFC 3995, Internet Printing Protocol (IPP): Event Notifications and Subscriptions — https://www.rfc-editor.org/info/rfc3995/