This document specifies the additional enum values 'fold', 'trim', 'bale', 'booklet-maker', 'jog-offset', 'bind-left', 'bind-top', 'bind-right', and 'bind-bottom' for the IPP "finishings" Job Template attribute for use with the Internet Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and Internet Printing Protocol/1.1 (IPP) [RFC2911, RFC2910]. This attribute permits the client to specify additional finishing options, including values that include a specification of a coordinate system for the placement of finishings operation with respect to the corners and edges of portrait and landscape documents.

This document defines an extension to the Internet Printing Protocol/1.0 (IPP/1.0) [RFC2566, RFC2565] & IPP/1.1 [RFC2911, RFC2910] for the OPTIONAL "output-bin" (type2 keyword | name(MAX)) Job Template attribute. This attribute allows the client to specify in which output bin a job is to be placed and to query the Printer's default and supported output bins.

NOTE: THIS SPECIFICATION IS A "TRAIL USE" STANDARD. FUTURE VERSIONS OF THIS SPECIFICATION WILL DRAW ON IMPLEMENTATION EXPERIENCE AND MAY INTRODUCE INCOMPATIBLE CHANGES.

This document defines an extension to the Internet Printing Protocol (IPP) (RFC2911, RFC2910) for the OPTIONAL "-actual" set of Job Description attributes that correspond to Job Template attributes defined in IPP. These "-actual" attributes allow the client to determine the true results of a print job regardless of what was specified in the Create-Job or Print-Job operation.

This document defines the new IPP Printer attributes "printer-alert" and "printer-alert-description" plus extensions to the IPP Printer attribute "printer-state-reasons" (defined in RFC 2911) and to the IANA Printer MIB textual convention "PrtAlertCodeTC" (originally published in RFC 3805) as follows:

(a) A standard encoding of all of the machine-readable columnar objects in the 'prtAlertTable' defined in IETF Printer MIB v2 (RFC 3805) into substrings of values of the new IPP Printer "printer-alert" attribute defined in this document.

(b) A standard encoding of the localized 'prtAlertDescription' columnar object in the 'prtAlertTable' defined in IETF Printer MIB v2 (RFC 3805) into values of the new IPP Printer "printer-alert-description" attribute defined in this document.

(c) A standard mapping between the device errors and warnings in the 'PrtAlertCodeTC' textual convention defined in IANA Printer MIB and existing or new values (as needed) of the IPP Printer "printer-state-reasons" attribute defined in IPP/1.1.

(d) A standard mapping between the finishing subunit types in the 'FinDeviceTypeTC' textual convention defined in IANA Finisher MIB (originally published in RFC 3806) and new specific values of the 'PrtAlertCodeTC' textual convention defined in IANA Printer MIB and new values of the IPP Printer "printer-state-reasons" attribute defined in IPP/1.1, for high fidelity support of finishing alerts.

Since the release of IPP/1.1 (RFC 2910 and RFC 2911), numerous extensions to the IPP protocol have been published as IETF RFCs or PWG Candidate Standards.  Many IPP developers are not aware of the existence of the many of these extensions, and there is no published document that references all of the extension specifications.  As a consequence, only some of the extensions have been implemented.

This specification combines most of the previous IPP IETF or PWG IPP extensions into either a new base IPP/2.0 conformance level or a new extended IPP/2.1 conformance level. No new IPP functionality, beyond that defined in the previous IPP extensions, is specified in this document.

Implementation of this specification will allow printing applications to easily determine the capabilities of an IPP Printer without the need for extensive queries to the IPP Printer.

In traditional printing environments, clients rely on font downloads when they are not sure a given character is embedded in the printer. As printing moves to small clients, downloading may not be an option and clients have a need to know what characters are available in a given device.  

There are many published named character repertoires, and a small client will not know about them all.  

To improve operability, this document defines semantics and naming conventions, to allow a printer to advertise what repertoires it supports.

The primary target of this document is printing using document formats based on XML or HTML (for example, XHTML-Print).  It will be less applicable to traditional PDLs (PCL, PostScript, etc.) because they tend to have very format-specific mechanisms for managing character repertoires.

HTML 4 is a powerful language for authoring Web content, but its design does not take into consideration issues pertinent to printers, including the implementation cost (in power, memory, etc.) of the full feature set. Printers have relatively limited resources that cannot generally afford to implement the full feature set of HTML 4.

Because there are many ways to subset HTML, there are many almost identical subsets defined by organizations and companies. Without a common base set of features, developing print applications for a wide range of printers is difficult.

XHTML-Print's targeted usage is for printing in environments where it is not feasible or desirable to install a printer-specific driver and where some variability in the formatting of the output is acceptable.

The document type definition for XHTML-Print is implemented based on the XHTML modules defined in the W3C's Modularization of XHTML.

This specification defines a subset of the Cascading Style Sheets Level 2 specification with additions from the proposed features of Paged Media Properties for Cascading Style Sheets Level 3, to provide a strong basis for rich printing results without a detailed understanding of each individual printer's characteristics.

It also defines an extension set that provides stronger layout control for the printing of mixed text and images, tables and image collections.

This document specifies an application of PDF (Portable Document Format) that has two important properties: First, it is an "image"-based format, and proper rendering of the document is represented by (binary or color) images. Second, the format is suitable for incremental generation and thus it is a "streaming" format. The subset is called "PDF/is", for "PDF Image-Streamable".

The Print Service Interface is the set of interfaces and methods that enable a Client, such as a Printer, Mobile Device, Web Portal, or Service, to create a Print Job on a Print Service. The Print Service may be used to resolve and access the information to be printed.

This document is a high level overview of the Semantic Model defined by the PWG. This document briefly describes the semantic elements defined in various PWG documents and PWG documents submitted to the IETF. The Semantic Model also incorporates additions made by other groups addressing print systems. With every semantic element included a reference is provided to the document and section that details the semantic definition.

The Semantic Model contains a high level description of the Actions that operate on the objects and attributes in the model. This document does not describe the mapping of the semantics onto a specific protocol or network environment.

This document defines the usage counters for an Imaging System, such as a network spooler, a printer or a multifunction device, and the services such a system offers. This document does not describe mapping of these semantics to XML Schema, MIB or any protocol. Such mappings may be provided in separate documents.

This specification defines the abstract Web-based Imaging Management Service (WIMS) protocol. This specification defines five operations initiated by a WIMS Agent (embedded in services or devices), largely in support of Schedule-oriented remote management: RegisterForManagement (Agent allows management by an identified WIMS Manager); and UnregisterForManagement (cancel Agent association with a given WIMS Manager); GetSchedule (request a Schedule of planned actions); SendReports (send normal operational message); and SendAlerts (send warning or error exception message). This specification also defines four operations initiated by a WIMS Manager to support more conventional local management: BeginManagement (Manager requests ability to manage an identified Agent); EndManagement (Manager cancels association with Agent); SetSchedule (send a Schedule of planned actions with their timetables); ExecuteAction (execute the single identified action). This specification also defines sets of monitoring, management and administration actions that can be included within a Schedule. Transport bindings for the WIMS protocol are identified in the appendix.

Abstract

This document defines the PWG Imaging System State and Counter (ISC) MIB v2.0 that supports monitoring of system-, service-, and subunit-level state and counters on imaging devices (dedicated systems) and imaging servers (multipurpose systems). The ISC MIB can be used for fleet management, enterprise billing, field service, and other applications. The ISC MIB is entirely freestanding, but it also facilitates use of the IETF Host Resources MIB [RFC1514] [RFC2790] and IETF Printer MIB [RFC1759] [RFC3805] for imaging device and imaging server monitoring. The ISC MIB was developed by the PWG's Web-based Imaging Management Service (WIMS) project and is based on the PWG Imaging System Counters specification [PWG5106.1].

This document defines the PWG Printer Port Monitor (PPM) MIB v1.0 that supports printer status monitoring, automatic installation of device drivers, and other printing applications. The PPM MIB is entirely free-standing, but it also facilitates use of the IETF Host Resources MIB (RFC1514 / RFC2790) and IETF Printer MIB (RFC1759 / RFC3805) for printer status monitoring.

Network print devices have evolved to support additional multifunction services, in particular Scan Service. When network Scanners are installed in local office or enterprise networks, they need remote service, device, and job management capabilities so that administrators, operators, and End Users can monitor their health and status.  In addition, such network Scanners need remote request for job creation capabilties so that operators ane End Users can create Scan Jobs without depending entirely on local console interfaces.  This document defines and semantic model for service, device, and job management and request for job creation for these network Scanners.