Skip to content

IPP Print Features

Jump to bottom
Smith Kennedy edited this page Aug 27, 2026 · 3 revisions

IPP Print Features

This document lists common user-facing print features and how they are supported using IPP. 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 is footnoted 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.

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.

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.

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.
  • 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 desired stacking order.
  • 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 without manual re-sorting).

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[^jobext] - values: color, monochrome, auto, auto-monochrome, bi-level.
  • 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[^jobext].
  • 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.

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.

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 (bundled presets)

  • Detection: finishing-template-supported[^fin] - list of named presets.
  • 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.

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. Security, Accounting & Authorization

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.

Job accounting / cost tracking

  • Detection: job-account-id-supported, job-account-type-supported, job-accounting-user-id-supported[^jobext] - booleans indicating the printer will record/enforce these.
  • 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-sheets[^jobext] (collection).
  • Expected Result: Printer associates the job with the supplied account 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).

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.
  • 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.
  • Expected Result: Requests from disallowed users are rejected with client-error-not-authorized; allowed users proceed normally.

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.

9. Notifications & Status

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).

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.

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. Driverless Discovery & Capability Negotiation (IPP Everywhere-specific)

Capability discovery

  • Detection: Get-Printer-Attributes[^rfc8011] with no/empty requested-attributes (or explicit list) returns the full set of *-supported/*-default pairs describing the device's capabilities.
  • Client Preview: N/A — this is the data source that enables preview for other features, not itself a previewable feature.
  • Job Submission / Job Ticket: N/A — this operation IS the detection mechanism other features depend on.
  • Expected Result: Client builds a capability model entirely from returned attributes with no vendor driver; any Job Template attribute the client later submits should have been advertised as supported first.

DNS-SD advertisement

  • Detection: mDNS/DNS-SD TXT record fields (e.g. rp, adminurl, pdl, note, UUID)[^ippeve] mirror a subset of IPP attributes (document-format-supported, printer-uuid) for pre-connection discovery without an IPP round-trip.
  • Client Preview: N/A — discovery mechanism, not a print-output feature.
  • Job Submission / Job Ticket: N/A — advertisement is printer-initiated.
  • Expected Result: Client can shortlist candidate printers via DNS-SD/Bonjour browsing before issuing any IPP request; TXT record values must stay consistent with what Get-Printer-Attributes subsequently reports.

Job ticket validation

  • Detection: N/A — exercised directly.
  • Client Preview: No — Validate-Job deliberately omits document data, so it validates the attribute combination, not visual output; it complements (but does not itself produce) a rendered preview.
  • Job Submission / Job Ticket: Validate-Job[^rfc8011] operation with the full candidate set of Job Template attributes, without transmitting document data.
  • Expected Result: Printer returns success (ticket is fully supported in combination) or a list of unsupported/conflicting attributes in the unsupported-attributes group, letting the client correct the ticket before spooling real data.

Constraint resolution between attributes

  • Detection: job-constraints-supported and job-resolvers-supported[^nodriver] describe attribute combinations that are mutually exclusive or require resolution, and named resolver profiles.
  • Client Preview: No — a logic/validation layer; any visual effect it produces is only through whichever underlying feature (media, finishing, etc.) ends up selected after resolution.
  • Job Submission / Job Ticket: job-resolvers-col[^nodriver] referencing a resolver name for the detected conflict, or the client pre-resolves the conflicting attributes itself before submission.
  • Expected Result: Printer either applies the named resolver automatically or rejects the ticket with the specific conflicting attributes identified, avoiding ambiguous/undefined combinations (e.g. staple finishing on a media size too small for the stapler).

IPP Everywhere conformance signaling

  • Detection: ipp-features-supported[^nodriver] includes the keyword ipp-everywhere; combined with mandatory baseline attributes (e.g. document-format-supported including image/pwg-raster or image/urf, media-col-database) required for certification[^ippeve].
  • Client Preview: N/A — conformance metadata, not a print-output feature.
  • Job Submission / Job Ticket: N/A — informational/self-declaration by the printer.
  • Expected Result: Client can trust that the mandatory-to-implement IPP Everywhere attribute/operation baseline is present without needing printer-specific fallback logic.

References

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

[^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/

The IPP Sample Software implements IPP Everywhere™, IPP 3D, and many other IPP standards and extensions.

Clone this wiki locally