Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8011

Internet Printing Protocol/1.1: Model and Semantics

Pages: 221
Internet Standard: 92
Errata
Obsoletes:  291133813382
Part 2 of 12 – Pages 15 to 29
First   Prev   Next

Top   ToC   RFC8011 - Page 15   prevText

2. Conventions Used in This Document

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The key word "DEPRECATED" in this document refers to an operation, attribute, or value that SHOULD NOT be used or supported in new implementations.

2.2. Printing Terminology

Client: Initiator of outgoing IPP session requests and sender of outgoing IPP operation requests (Hypertext Transfer Protocol (HTTP/1.1) user agent, as defined in [RFC7230]). Document: An object created and managed by a Printer that contains description, processing, and status information. A Document object can have attached data and is bound to a single Job [PWG5100.5]. 'ipp' URI: An IPP URI as defined in [RFC3510]. 'ipps' URI: An IPP URI as defined in [RFC7472]. Job: An object created and managed by a Printer that contains description, processing, and status information. The Job also contains zero or more Document objects. Logical Device: A print server, software service, or gateway that processes Jobs and either forwards or stores the processed Job or uses one or more Physical Devices to render output. Output Device: A single Logical or Physical Device. Physical Device: A hardware implementation of an endpoint device, e.g., a marking engine, a fax modem, etc. Printer: Listener for incoming IPP session requests and receiver of incoming IPP operation requests (HTTP/1.1 server, as defined in [RFC7230]) that represents one or more Physical Devices or a Logical Device.
Top   ToC   RFC8011 - Page 16

2.3. Model Terminology

2.3.1. Administrator

An End User who is also authorized to manage all aspects of an Output Device or Printer, including creating the Printer instances and controlling the authorization of other End Users and Operators [RFC2567].

2.3.2. Attributes

An attribute is an item of information that is associated with an instance of an IPP object (Printer, Job, etc.). An attribute consists of an attribute name and one or more attribute values. Each attribute has a specific attribute syntax. All object attributes are defined in Section 5, and all operation attributes are defined in Section 4. Job Template attributes are described in Section 5.2. The Client optionally supplies Job Template attributes in a Job Creation request (operation requests that create Job objects). The Printer object has associated attributes that define supported and default values for the Printer.
2.3.2.1. Attribute Group Name
Related attributes are grouped into named groups. The name of the group is a keyword. The group name can be used in place of naming all the attributes in the group explicitly. Attribute groups are defined in Section 4.
2.3.2.2. Attribute Name
Each attribute is uniquely identified in this document by its attribute name. An attribute name is a keyword. The keyword attribute name is given in the section title in this document that describes that attribute. In running text in this document, attribute names are indicated inside double quotation marks (") where the quotation marks are not part of the keyword itself.
2.3.2.3. Attribute Syntax
Each attribute is defined using an explicit syntax type. In this document, each syntax type is defined as a keyword with specific meaning. The "Encoding and Transport" document [RFC8010] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in Section 5.1.
Top   ToC   RFC8011 - Page 17
2.3.2.4. Attribute Value
Each attribute has one or more values. Attribute values are represented in the syntax type specified for that attribute. In running text in this document, attribute values are indicated inside single quotation marks ('), whether their attribute syntax is keyword, integer, text, etc. where the quotation marks are not part of the value itself.

2.3.3. End User

An End User is a person or software process that is authorized to perform basic printing functions, including finding/locating a Printer, creating a local instance of a Printer, viewing Printer status, viewing Printer capabilities, submitting a Print Job, viewing Print Job status, and altering the attributes of a Print Job [RFC2567].

2.3.4. Impression

An Impression is the content imposed upon one side of a Media Sheet by a marking engine, independent of the number of times that the sheet side passes any marker. An Impression contains one or more Input Pages that are imposed (scaled, translated, and/or rotated) during processing of the Document data.

2.3.5. Input Page

An Input Page is a page according to the definition of "pages" in the language used to express the Document data.

2.3.6. Job Creation Operation

A Job Creation operation is any operation that causes the creation of a Job object, e.g., the Create-Job, Print-Job, and Print-URI operations defined in this document.

2.3.7. Keyword

Keywords are used within this document as identifiers of semantic entities within the abstract model (see Section 5.1.4). Attribute names, some attribute values, attribute syntaxes, and attribute group names are represented as keywords.
Top   ToC   RFC8011 - Page 18

2.3.8. Media Sheet

A Media Sheet is a single instance of a medium, whether printing on one or both sides of the medium. Media Sheets also include sections of roll media.

2.3.9. Operator

An Operator is an End User that also has special rights on the Output Device or Printer. The Operator typically monitors the status of the Printer and also manages and controls the Jobs at the Output Device [RFC2567]. The Operator is allowed to query and control the Printer, Jobs, and Documents based on site policy.

2.3.10. Set

A Set is a logical boundary between the delivered Media Sheets of a printed Job. For example, in the case of a ten-page single Document with collated pages and a request for 50 copies, each of the 50 printed copies of the Document constitutes a Set. If the pages were uncollated, then 50 copies of each of the individual pages within the Document would represent each Set. Finishing processes operate on Sets.

2.3.11. Support of Attributes

By definition, a Printer supports an attribute only if that Printer accepts it in a request or responds with the corresponding attribute populated with some value(s) in a response to a query for that attribute. A Printer supports an attribute value if the value is one of the Printer's "supported values" attributes. The device behind a Printer can exhibit a behavior that corresponds to some IPP attribute, but if the Printer, when queried for that attribute, doesn't respond with the attribute, then as far as IPP is concerned, that implementation does not support that feature. If the Printer's "xxx-supported" attribute is not populated with a particular value (even if that value is a legal value for that attribute), then that Printer does not support that particular value. A conforming implementation supports all REQUIRED attributes. However, even for REQUIRED attributes, conformance to IPP does not mandate that all implementations support all possible values representing all possible Job processing behaviors and features. For example, if a given instance of a Printer supports only certain Document formats, then that Printer responds with the "document-format-supported" attribute populated with a set of values, or possibly only one value, taken from the entire set of possible values defined for that attribute. This limited set of values
Top   ToC   RFC8011 - Page 19
   represents the Printer's set of supported Document formats.
   Supporting an attribute and some set of values for that attribute
   enables IPP End Users to be aware of and make use of those features
   associated with that attribute and those values.  If an
   implementation chooses to not support an attribute or some specific
   value, then IPP End Users would have no ability to make use of that
   feature within the context of IPP itself.  However, due to existing
   practice and legacy systems that are not IPP aware, there might be
   some other mechanism outside the scope of IPP to control or request
   the "unsupported" feature (such as embedded instructions within the
   Document data itself).

   For example, consider the following for the "finishings-supported"
   attribute.

   1)  If a Printer is not physically capable of stapling, the
       "finishings-supported" attribute MUST NOT be populated with the
       value of 'staple'.

   2)  A Printer is physically capable of stapling; however, an
       implementation chooses not to support stapling in the IPP
       "finishings" attribute.  In this case, 'staple' MUST NOT be a
       value in the "finishings-supported" Printer Description
       attribute.  Without support for the value 'staple', an IPP
       End User would have no means within the protocol itself to
       request that a Job be stapled.  However, an existing Document
       data formatter might be able to request that the Document be
       stapled directly with an embedded instruction within the Document
       data.  In this case, the IPP implementation does not "support"
       stapling; however, the End User is still able to have some
       control over the stapling of the completed Job.

   3)  A Printer is physically capable of stapling, and an
       implementation chooses to support stapling in the IPP
       "finishings" attribute.  In this case, 'staple' MUST be a value
       in the "finishings-supported" Printer attribute.  Doing so
       enables End Users to be aware of and make use of the stapling
       feature using IPP attributes.

   Even though support for Job Template attributes by a Printer is
   OPTIONAL in IPP/1.1, Printers whose associated device(s) is capable
   of realizing any feature or function that corresponds to an IPP
   attribute and some associated value SHOULD support that IPP attribute
   and value.
Top   ToC   RFC8011 - Page 20
   The set of values in any of the supported value attributes is set
   (populated) by some administrative process or automatic sensing
   mechanism that is outside the scope of this document.  For
   administrative policy and control reasons, an Administrator can
   choose to make only a subset of possible values visible to the
   End User.  In this case, the real Output Device behind the IPP
   Printer abstraction can be capable of a certain feature; however, an
   Administrator is specifying that access to that feature not be
   exposed to the End User through IPP.  Also, since a Printer can
   represent a logical print device (not just a Physical Device), the
   actual process for supporting a value is undefined and left up to the
   implementation.  However, if a Printer supports a value, some manual
   human action might be needed to realize the semantic action
   associated with the value, but no End User action is required.

   For example, if one of the values in the "finishings-supported"
   attribute is 'staple', the actual process might be an automatic
   staple action by a Physical Device controlled by some command sent to
   the device.  Or, the actual process of stapling might be a manual
   action by an Operator at an Operator-attended Printer.

   For another example of how supported attributes function, consider an
   Administrator who desires to control all Print Jobs so that no Job
   sheets are printed in order to conserve paper.  To force no Job
   sheets, the Administrator sets the only supported value for the
   "job-sheets-supported" attribute to 'none'.  In this case, if a
   Client requests anything except 'none', the Job Creation request is
   rejected or the "job-sheets" value is ignored (depending on the value
   of "ipp-attribute-fidelity").  To force the use of Job start/end
   sheets on all Jobs, the Administrator does not include the value
   'none' in the "job-sheets-supported" attribute.  In this case, if a
   Client requests 'none', the Job Creation request is rejected or the
   "job-sheets" value is ignored (again depending on the value of
   "ipp-attribute-fidelity").

   Job Template attributes will typically have corresponding
   "xxx-supported" and "xxx-default" Printer Description attributes that
   contain the supported and default values for the attribute.  For
   capabilities that are not associated with a Job, the convention is to
   have an "xxx-supported" Printer Description attribute that lists the
   supported values and an "xxx-configured" Printer Description
   attribute that contains the value being used by the Printer.  For
   example, the "charset-supported" Printer Description attribute
   (Section 5.4.18) lists the supported character sets for the Printer
   while the "charset-configured" Printer Description attribute
   (Section 5.4.17) specifies the character set being used by the
   Printer.
Top   ToC   RFC8011 - Page 21

2.3.12. Terminating State

The final state for a Job or other object is called its Terminating State. For example, the 'aborted', 'canceled', and 'completed' Job states are Terminating States.

2.4. Abbreviations

ABNF: Augmented Backus-Naur Form [RFC5234] ASCII: American Standard Code for Information Interchange [RFC20] HTTP: Hypertext Transfer Protocol [RFC7230] HTTPS: HTTP over TLS [RFC2818] IANA: Internet Assigned Numbers Authority IEEE: Institute of Electrical and Electronics Engineers IESG: Internet Engineering Steering Group IPP: Internet Printing Protocol (this document, [RFC8010], and [PWG5100.12]) ISTO: IEEE Industry Standards and Technology Organization LPD: Line Printer Daemon Protocol [RFC1179] PWG: IEEE-ISTO Printer Working Group RFC: Request for Comments TCP: Transmission Control Protocol [RFC793] TLS: Transport Layer Security [RFC5246] URI: Uniform Resource Identifier [RFC3986] URL: Uniform Resource Locator [RFC3986] UTF-8: Unicode Transformation Format - 8-bit [RFC3629]
Top   ToC   RFC8011 - Page 22

3. IPP Objects

This document defines IPP objects of types Printer and Job. Each type of object models relevant aspects of a real-world entity such as a real Printer or real Print Job. Each object type is defined as a set of possible attributes that can be supported by instances of that object type. For each object (instance), the actual set of supported attributes and values describe a specific implementation. The object's attributes and values describe its state, capabilities, realizable features, Job processing functions, and default behaviors and characteristics. For example, the Printer object type is defined as a set of attributes that each Printer object potentially supports. In the same manner, the Job object type is defined as a set of attributes that are potentially supported by each Job object. Each attribute included in the set of attributes defining an object type is labeled as: o "REQUIRED": each object MUST support the attribute. o "RECOMMENDED": each object SHOULD support the attribute. o "OPTIONAL": each object MAY support the attribute. Some definitions of attribute values indicate that an object MUST or SHOULD support the value; otherwise, support of the value is OPTIONAL. However, if an implementation supports an attribute, it MUST support at least one of the possible values for that attribute.

3.1. Printer Object

The major component of the IPP Model is the Printer object. A Printer object implements the server side of the IPP/1.1 protocol. Using the protocol, End Users can query the attributes of the Printer object and submit Print Jobs to the Printer object. The actual implementation components behind the Printer abstraction can take on different forms and different configurations. However, the model abstraction allows the details of the configuration of real components to remain opaque to the End User. Section 4 describes each of the Printer operations in detail.
Top   ToC   RFC8011 - Page 23
   The capabilities and state of a Printer object are described by its
   attributes.  Printer attributes are divided into two groups:

   o  "job-template" attributes: These attributes describe supported Job
      processing capabilities and defaults for the Printer object (see
      Section 5.2)

   o  "printer-description" attributes: These attributes describe the
      Printer's identification, state, location, references to other
      sources of information about the Printer object, etc. (see
      Section 5.4)

   Since a Printer object is an abstraction of a generic Document Output
   Device and print service provider, a Printer object could be used to
   represent any real or virtual device with semantics consistent with
   the Printer object, such as a fax device, an imager, or even a CD
   writer.

   Some examples of configurations supporting a Printer object include:

   1.  An Output Device with no spooling capabilities

   2.  An Output Device with a built-in spooler

   3.  A print server supporting IPP with one or more associated Output
       Devices

       3a.  The associated Output Devices are or are not capable of
            spooling Jobs

       3b.  The associated Output Devices possibly support IPP

   Figure 2 shows some examples of how Printers can be realized on top
   of various distributed printing configurations.  The embedded case
   below represents configurations 1 and 2 above.  The "hosted Printer"
   and "fan out" items represent configurations 3a and 3b, respectively.

   In this document, the term "Client" refers to a software entity that
   sends IPP operation requests to an IPP Printer and accepts IPP
   operation responses.  A Client MAY be:

   1.  contained within software controlled by an End User, e.g.,
       activated by the "Print" menu item in an application, or

   2.  the print server component that sends IPP requests to either an
       Output Device or another "downstream" print server.
Top   ToC   RFC8011 - Page 24
   The term "IPP Printer" is a network entity that accepts IPP operation
   requests and returns IPP operation responses.  As such, an IPP
   Printer object MAY be:

   1.  an (embedded) device component that accepts IPP requests and
       controls the device, or

   2.  a component of a print server that accepts IPP requests (where
       the print server controls one or more networked devices using IPP
       or other protocols).

   Legend:

   ##### indicates a Printer object that is
         either embedded in an Output Device or
         hosted in a server.  The Printer object
         might or might not be capable of queuing/spooling.

   any   indicates any network protocol or direct
         connect, including IPP

   embedded Printer:
                                             Output Device
                                           +---------------+
    O   +--------+                         |  ###########  |
   /|\  | Client |------------IPP------------># Printer #  |
   / \  +--------+                         |  # Object  #  |
                                           |  ###########  |
                                           +---------------+
   hosted Printer:
                                           +---------------+
    O   +--------+        ###########      |               |
   /|\  | Client |--IPP--># Printer #-any->| Output Device |
   / \  +--------+        # Object  #      |               |
                          ###########      +---------------+
                                            +---------------+
   fan out:                                 |               |
                                        +-->| Output Device |
                                    any/    |               |
    O   +--------+      ###########   /     +---------------+
   /|\  | Client |-IPP-># Printer #--*
   / \  +--------+      # Object  #   \     +---------------+
                        ########### any\    |               |
                                        +-->| Output Device |
                                            |               |
                                            +---------------+

                 Figure 2: IPP Printer Object Architecture
Top   ToC   RFC8011 - Page 25

3.2. Job Object

A Job object is used to model a Print Job. A Job object contains zero or more Documents. The information required to create a Job object is sent in a Job Creation request from the End User via an IPP Client to the Printer. The Printer validates the Job Creation request, and if the Printer accepts the request, the Printer creates the new Job object. Section 4 describes each of the Job operations in detail. The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows: o "job-template" attributes: These attributes can be supplied by the Client or End User and include Job processing instructions that are intended to override any Printer defaults and/or instructions embedded within the Document data (see Section 5.2) o "job-description" attributes: These attributes describe the Job's identification, state, size, etc. The Client supplies some of these attributes, and the Printer generates others (see Section 5.3) An implementation MUST support at least one Document per Job object. An implementation MAY support multiple Documents per Job object. A Document is either: o a stream of Document data in a format supported by the Printer (typically a Page Description Language -- PDL), or o a reference to such a stream of Document data. All Job processing instructions are modeled as Job object attributes. These attributes are called "Job Template attributes", and they apply equally to all Documents within a Job object.

3.3. Object Relationships

IPP objects have relationships that are maintained persistently along with the persistent storage of the object attributes. A Printer object can represent either one or more physical Output Devices or a Logical Device that "processes" Jobs but never actually uses a physical Output Device to put marks on paper. Examples of Logical Devices include a web page publisher or a gateway into an online Document archive or repository. A Printer contains zero or more Job objects.
Top   ToC   RFC8011 - Page 26
   A Job object is contained by exactly one Printer; however, the
   identical Document data associated with a Job could be sent to either
   the same or a different Printer.  In this case, a second Job object
   would be created that would be almost identical to the first Job;
   however, it would have new (different) Job object identifiers (see
   Section 3.4).

   A Job either is empty (before any Documents have been added) or
   contains one or more Documents.  If the contained Document is a
   stream of Document data, that stream can be contained in only one
   Document.  However, there can be identical copies of the stream in
   other Documents in the same or different Jobs.  If the contained
   Document is just a reference to a stream of Document data, other
   Documents (in the same or different Job(s)) contain the same
   reference.

3.4. Object Identity

All IPP objects (Printers, Jobs, etc.) are identified by a Uniform Resource Identifier (URI) [RFC3986] so that they can be persistently and unambiguously referenced. Since every URL is a specialized form of a URI, even though the more generic term "URI" is used throughout the rest of this document, its usage is intended to cover the more specific notion of "URL" as well. An Administrator configures Printers to either support or not support authentication and/or message privacy using Transport Layer Security (TLS) [RFC5246]; the mechanism for security configuration is outside the scope of this document. In some situations, both types of connections (both authenticated and unauthenticated) can be established using a single communication channel that has some sort of negotiation mechanism. In other situations, multiple communication channels are used, one for each type of security configuration. Section 9 provides a full description of all security considerations and configurations. If a Printer supports more than one communication channel, some or all of those channels might support and/or require different security mechanisms. In such cases, an Administrator could expose the simultaneous support for these multiple communication channels as multiple URIs for a single Printer where each URI represents one of the communication channels to the Printer. To support this flexibility, the IPP Printer object type defines a multi-valued identification attribute called the "printer-uri-supported" attribute that MUST contain at least one URI. The "printer-uri-supported" attribute has two companion attributes, the "uri-security-supported" attribute and the "uri-authentication-supported" attribute. Both have the same cardinality as "printer-uri-supported". The purpose of
Top   ToC   RFC8011 - Page 27
   the "uri-security-supported" attribute is to indicate the security
   mechanisms (if any) used for each URI listed in
   "printer-uri-supported".  The purpose of the
   "uri-authentication-supported" attribute is to indicate the
   authentication mechanisms (if any) used for each URI listed in
   "printer-uri-supported".  These three attributes are fully described
   in Sections 5.4.1, 5.4.2, and 5.4.3.

   When a Job is submitted to the Printer via a Job Creation request,
   the Client supplies only a single Printer URI.  The Client-supplied
   Printer URI MUST be one of the values in the "printer-uri-supported"
   Printer attribute.

   IPP/1.1 does not specify how the Client obtains the Client-supplied
   URI, but it is RECOMMENDED that a Printer be registered as an entry
   in a directory service.  End Users and programs can then interrogate
   the directory, searching for Printers.  Appendix D defines a generic
   schema for Printer object entries in the directory service and
   describes how the entry acts as a bridge to the actual IPP Printer.
   The entry in the directory that represents the IPP Printer includes
   the possibly many URIs for that Printer as values in one of its
   attributes.

   When a Client submits a Job Creation request to the Printer, the
   Printer validates the request and creates a new Job object.  The
   Printer assigns the new Job a numeric identifier that is stored in
   the "job-id" Job attribute and a URI that is stored in the "job-uri"
   Job attribute.  Both the numeric identifier and URI can then be used
   by Clients as the target for subsequent Job operations; the numeric
   identifier is preferred.  The Printer generates the Job numeric
   identifier and URI based on its configured security policy and the
   URI used by the Client in the Job Creation request.

   For example, consider a Printer that supports both a communication
   channel secured by the use of TLS (using HTTP over TLS with an
   "https" schemed URI) and another open communication channel that is
   not secured with TLS (using a simple "http" schemed URI).  If a
   Client submits a Job using the secure URI, the Printer assigns the
   new Job a secure URI as well.  If a Client were to submit a Job using
   the open-channel URI, the Printer might assign the new Job an
   open-channel URI.  Clients SHOULD use the "printer-uri" and "job-id"
   attributes to target a Job to avoid any ambiguity about the security
   of the communication channel.

   In addition, the Printer also populates the Job's "job-printer-uri"
   attribute.  This is a reference back to the Printer that created the
   Job.  If a Client only has access to a Job's "job-uri" identifier,
   the Client can query the Job's "job-printer-uri" attribute in order
Top   ToC   RFC8011 - Page 28
   to determine which Printer created the Job.  If the Printer supports
   more than one URI, the Printer picks the one URI supplied by the
   Client when creating the Job to build the value for and to populate
   the Job's "job-printer-uri" attribute.

   In addition to identifiers, IPP objects have names -- "printer-name"
   for Printers and "job-name" for Jobs.  An object name is not
   guaranteed to be unique across all instances of all objects.  A
   Printer's name is chosen and set by an Administrator through some
   mechanism outside the scope of this document.  A Job's name can be
   chosen and supplied by the Client submitting the Job.  If the Client
   does not supply a Job name, the Printer generates a name for the new
   Job.  In all cases, the name only has local meaning.

   To summarize:

   o  Each Printer is identified by one or more URIs.  The Printer's
      "printer-uri-supported" attribute contains the URI(s).

   o  The Printer's "uri-security-supported" attribute identifies the
      communication channel security protocols that have been configured
      for the various Printer URIs (e.g., 'tls' or 'none').

   o  The Printer's "uri-authentication-supported" attribute identifies
      the authentication mechanisms that have been configured for the
      various Printer URIs (e.g., 'digest', 'none', etc.).

   o  Each Job is identified by a numeric identifier, which is a 32-bit
      positive integer.  The Job's "job-id" attribute contains the
      Job ID.  The Job ID is only unique within the context of the
      Printer that created the Job.

   o  Each Job is also identified by a URI.  The Job's "job-uri"
      attribute contains the URI, although its use by Clients is
      DEPRECATED.

   o  Each Job has a "job-printer-uri" attribute, which contains the URI
      of the Printer that was used to create the Job.  This attribute is
      used to determine the Printer that created a Job when given only
      the URI for the Job.  This linkage is necessary to determine the
      languages, charsets, and operations that are supported on that Job
      (the basis for such support comes from the creating Printer).

   o  Each Printer has a name, which is not necessarily unique.  The
      Administrator chooses and sets this name through some mechanism
      outside the scope of this IPP/1.1 document.  The Printer's
      "printer-name" attribute contains the name.
Top   ToC   RFC8011 - Page 29
   o  Each Job has a name, which is not necessarily unique.  The Client
      optionally supplies this name in the Job Creation request.  If the
      Client does not supply this name, the Printer generates a name for
      the Job.  The Job's "job-name" attribute contains the name.



(page 29 continued on part 3)

Next Section