Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8011

Internet Printing Protocol/1.1: Model and Semantics

Pages: 221
Internet Standard: 92
Errata
Obsoletes:  291133813382
Part 10 of 12 – Pages 166 to 188
First   Prev   Next

Top   ToC   RFC8011 - Page 166   prevText

6. Conformance

This section describes conformance issues and requirements. This document introduces model entities such as objects, operations, attributes, attribute syntaxes, and attribute values. The following sections describe the conformance requirements that apply to these model entities.

6.1. Client Conformance Requirements

This section describes the conformance requirements for a Client (see Section 3.1), whether it be: 1. contained within software controlled by an End User, e.g., activated by the "Print" menu item in an application that sends IPP requests, or 2. the print server component that sends IPP requests to either an Output Device or another "downstream" print server. A conforming Client supports all REQUIRED operations as defined in this document. For each attribute included in an operation request, a conforming Client MUST supply a value whose type and value syntax conforms to the requirements specified in Sections 4 and 5 of this document. A conforming Client MAY supply any Standards Track extensions and/or vendor extensions in an operation request, as long as the extensions meet the requirements in Section 7.
Top   ToC   RFC8011 - Page 167
   While this document does not define conformance requirements for the
   user interfaces provided by IPP Clients or their applications, best
   practices for user interfaces are defined in [PWG5100.19].

   A Client MUST be able to accept any of the attribute syntaxes defined
   in Section 5.1, including their full range, that can be returned to
   it in a response from a Printer.  In particular, for each attribute
   that the Client supports whose attribute syntax is 'text', the Client
   MUST accept and process both the 'textWithoutLanguage' and
   'textWithLanguage' forms.  Similarly, for each attribute that the
   Client supports whose attribute syntax is 'name', the Client MUST
   accept and process both the 'nameWithoutLanguage' and
   'nameWithLanguage' forms.  For presentation purposes, truncation of
   long attribute values is not recommended.  A recommended approach
   would be for the Client implementation to allow the user to scroll
   through long attribute values.

   A response MAY contain attribute groups, attributes, attribute
   syntaxes, values, and status-code values that the Client does not
   expect.  Therefore, a Client implementation MUST gracefully handle
   such responses and not refuse to interoperate with a conforming
   Printer that is returning Standards Track extensions or vendor
   extensions, including attribute groups, attributes, attribute
   syntaxes, attribute values, status-code values, and out-of-band
   attribute values that conform to Section 7.  Clients can choose to
   ignore any parameters, attribute groups, attributes, attribute
   syntaxes, or values that they do not understand.

   While a Client is sending data to a Printer, it SHOULD do its best to
   prevent a channel from being closed by a lower layer when the channel
   is blocked (i.e., flow-controlled off) for whatever reason, e.g.,
   'out of paper' or 'Job ahead hasn't freed up enough memory'.
   However, the layer that launched the print submission (e.g., an
   End User) MAY close the channel in order to cancel the Job.  When a
   Client closes a channel, a Printer MAY print all or part of the
   received portion of the Document.  See the Encoding and Transport
   document [RFC8010] for more details.

   A Client MUST support Client Authentication as defined in [RFC8010].
   A Client SHOULD support Operation Privacy and Server Authentication
   as defined in [RFC8010].  See also Section 9 of this document.
Top   ToC   RFC8011 - Page 168

6.2. IPP Object Conformance Requirements

This section specifies the conformance requirements for conforming implementations of IPP objects (see Section 3). These requirements apply to an IPP object whether it is: 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).

6.2.1. Objects

Conforming implementations MUST implement all of the model objects as defined in this document in the indicated sections: Section 3.1 - Printer Object Section 3.2 - Job Object

6.2.2. Operations

Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this document in the indicated sections. Table 20 lists the operations for a Printer, while Table 21 lists the operations for a Job.
Top   ToC   RFC8011 - Page 169
         +----------------------------------------+-------------+
         | Operation                              | Conformance |
         +----------------------------------------+-------------+
         | Print-Job (Section 4.2.1)              | REQUIRED    |
         +----------------------------------------+-------------+
         | Print-URI (Section 4.2.2)              | OPTIONAL    |
         +----------------------------------------+-------------+
         | Validate-Job (Section 4.2.3)           | REQUIRED    |
         +----------------------------------------+-------------+
         | Create-Job (Section 4.2.4)             | RECOMMENDED |
         +----------------------------------------+-------------+
         | Get-Printer-Attributes (Section 4.2.5) | REQUIRED    |
         +----------------------------------------+-------------+
         | Get-Jobs (Section 4.2.6)               | REQUIRED    |
         +----------------------------------------+-------------+
         | Pause-Printer (Section 4.2.7)          | OPTIONAL    |
         +----------------------------------------+-------------+
         | Resume-Printer (Section 4.2.8)         | OPTIONAL    |
         +----------------------------------------+-------------+
         | Purge-Jobs (Section 4.2.9)             | SHOULD NOT  |
         +----------------------------------------+-------------+

         Table 20: Conformance Requirements for Printer Operations

           +------------------------------------+-------------+
           | Operation                          | Conformance |
           +------------------------------------+-------------+
           | Send-Document (Section 4.3.1)      | RECOMMENDED |
           +------------------------------------+-------------+
           | Send-URI (Section 4.3.2)           | RECOMMENDED |
           +------------------------------------+-------------+
           | Cancel-Job (Section 4.3.3)         | REQUIRED    |
           +------------------------------------+-------------+
           | Get-Job-Attributes (Section 4.3.4) | REQUIRED    |
           +------------------------------------+-------------+
           | Hold-Job (Section 4.3.5)           | OPTIONAL    |
           +------------------------------------+-------------+
           | Release-Job (Section 4.3.6)        | OPTIONAL    |
           +------------------------------------+-------------+
           | Restart-Job (Section 4.3.7)        | SHOULD NOT  |
           +------------------------------------+-------------+

           Table 21: Conformance Requirements for Job Operations
Top   ToC   RFC8011 - Page 170
   Conforming IPP objects MUST support all REQUIRED operation attributes
   and all values of such attributes if so indicated in the description.
   Conforming IPP objects MUST ignore all unsupported or unknown
   operation attributes or Operation Attributes groups received in a
   request but MUST reject a request that contains a supported operation
   attribute that contains an unsupported value.

   Conforming IPP objects MAY return operation responses that contain
   attribute groups, attribute names, attribute syntaxes, attribute
   values, and status-code values that are extensions to this
   specification.  The additional attribute groups MAY occur in any
   order.

   The following section on object attributes specifies the support
   required for object attributes.

6.2.3. IPP Object Attributes

Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this document in the indicated sections. If an object supports an attribute, it MUST support only those values specified in this document or through the extension mechanism described in Section 6.2.5. It MAY support any non-empty subset of these values. That is, it MUST support at least one of the specified values and at most all of them.

6.2.4. Versions

IPP/1.1 Clients MUST meet the conformance requirements for Clients specified in this document and [RFC8010]. IPP/1.1 Clients MUST be capable of sending requests containing a "version-number" parameter with a value of '1.1'. IPP/1.1 Printer and Job objects MUST meet the conformance requirements for IPP objects specified in this document and [RFC8010]. IPP/1.1 objects MUST accept requests containing a "version-number" parameter with a '1.1' value or reject the request if the operation is not supported.
Top   ToC   RFC8011 - Page 171
   It is beyond the scope of this specification to mandate conformance
   with other IPP versions.  However, IPP was deliberately designed to
   make supporting different versions easy.  IPP/1.1 Printer
   implementations MUST:

   o  decode and process any well-formed IPP/1.1 request, and

   o  respond appropriately with a response containing the same
      "version-number" parameter value used by the Client in the
      request.

   IPP/1.1 Client implementations MUST:

   o  decode and process any well-formed IPP/1.1 response.

   IPP Clients SHOULD try supplying alternate version numbers if they
   receive a 'server-error-version-not-supported' error in a response.

6.2.5. Extensions

A conforming IPP object MAY support Standards Track extensions and vendor extensions, as long as the extensions meet the requirements specified in Section 7. For each attribute included in an operation response, a conforming IPP object MUST return a value whose type and value syntax conforms to the requirements specified in Sections 4 and 5 of this document.

6.2.6. Attribute Syntaxes

An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 5.1, including their full range, in any operation in which a Client can supply attributes or the Administrator can configure attributes (by means outside the scope of this IPP/1.1 document). In particular, for each attribute that the IPP object supports whose attribute syntax is 'text', the IPP object MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the IPP object supports whose attribute syntax is 'name', the IPP object MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. Furthermore, an IPP object MUST return attributes to the Client in operation responses that conform to the syntaxes specified in Section 5.1, including their full range if supplied previously by a Client.
Top   ToC   RFC8011 - Page 172

6.2.7. Security

An IPP Printer implementation SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC8010]. A Printer implementation MAY allow an Administrator to configure the Printer so that all, some, or none of the users are authenticated. See also Section 9 of this document. An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in [RFC8010]. A Printer implementation MAY allow an Administrator to configure the degree of support for Operation Privacy and Server Authentication. See also Section 9 of this document. Security MUST NOT be compromised when a Client supplies a lower "version-number" parameter in a request. For example, if a Printer conforming to IPP/1.1 accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request.

6.3. Charset and Natural Language Requirements

All Clients and IPP objects MUST support the 'utf-8' charset as defined in Section 5.1.8. IPP objects MUST be able to accept any Client request that correctly uses the "attributes-natural-language" operation attribute or the Natural Language Override mechanism on any individual attribute whether or not the natural language is supported by the IPP object. If an IPP object supports a natural language, then it MUST be able to translate (perhaps by table lookup) all generated 'text' or 'name' attribute values into one of the supported languages (see Section 4.1.4).
Top   ToC   RFC8011 - Page 173

7. IANA Considerations

This section describes the procedures for defining Standards Track and vendor extensions to this document. This affects the following subregistries of the IANA IPP registry: 1. Objects 2. Attributes 3. Keyword Attribute Values 4. Enum Attribute Values 5. Attribute Group Tags 6. Out-of-Band Attribute Value Tags 7. Attribute Syntaxes 8. Operations 9. Status-Code Values Extensions registered for use with IPP are OPTIONAL for Client and IPP object conformance to the IPP/1.1 Model and Semantics document (this document). These extension procedures are aligned with the guidelines as set forth in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. Appendix A describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in Appendix A. The IPP/1.1 Model and Semantics document can also be extended by an appropriate Standards Track document that specifies any of the above extensions. The IANA policy (using terms defined in [RFC5226]) for all extensions is Specification Required, Expert Review, or First Come First Served as documented in the following subsections. Registrations submitted to IANA are forwarded to the IPP Designated Expert(s) who reviews the proposal on a mailing list that the Designated Expert(s) keeps for this purpose. Initially, that list is the mailing list used by the PWG IPP WG: ipp@pwg.org
Top   ToC   RFC8011 - Page 174
   The IPP Designated Expert(s) is appointed by the IESG Area Director
   responsible for IPP, according to [RFC5226].

   In addition, the IANA-PRINTER-MIB [RFC3805] has been updated to
   reference this document; the current version is available from
   <http://www.iana.org>.

7.1. Object Extensions

The IANA policy (using terms defined in [RFC5226]) for object extensions was formerly Expert Review; this document changes the policy to Specification Required.

7.2. Attribute Extensibility

Since attribute names are type2 keywords (see Section 5.1.4), the IANA policy (using terms defined in [RFC5226]) for attribute extensions is Expert Review. For vendor attribute extensions, implementors SHOULD use keywords with a suitable distinguishing prefix such as 'smiNNN-' where NNN is an SMI Private Enterprise Number (PEN) [IANA-PEN]. For example, if the company Example Corp. had obtained the SMI PEN 32473, then a vendor attribute 'foo' would be 'smi32473-foo'. Note: Prior versions of this document recommended using a fully qualified domain name [RFC1035] as the prefix (e.g., 'example.com-foo'), and many IPP implementations have also used reversed domain names (e.g., 'com.example-foo'). Domain names have proven problematic due to the length of some domain names, parallel use of country-specific domain names (e.g., 'example.co.jp-foo'), and changes in ownership of domain names. If a new Printer attribute is defined and its values can be affected by a specific Document format, its specification needs to contain the following sentence: "The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" attribute supplied (see Section 4.2.5.1) of the IPP/1.1 Model and Semantics document." If the specification does not, then its value in the Get-Printer-Attributes response MUST NOT depend on the "document-format" attribute supplied in the request.
Top   ToC   RFC8011 - Page 175
   When a new Job Template attribute is registered, the value of the
   Printer attributes MAY vary with "document-format" supplied in the
   request without the specification having to indicate so.

7.3. Keyword Extensibility

The IANA policy (using terms defined in [RFC5226]) for type1 keyword extensions is Specification Required. The IANA policy for type2 keyword extensions is Expert Review. The IANA policy for vendor keyword extensions is First Come First Served. Only attributes using the type1 and type2 keyword syntax can be registered in the IANA IPP registry. Note: The type1 or type2 prefix on the basic attribute syntax is provided only to communicate the IANA policy required for registration and is not represented in IPP messages. Both type1 and type2 'keyword' values are represented using the same 'keyword' value tag. For type1 and type2 keywords, the proposer includes the name of the keyword in the registration proposal, and the name is part of the technical review. For vendor keyword extensions, implementors SHOULD either: a. follow attribute-specific guidance such as the guidance defined in [PWG5101.1], or b. use keywords with a suitable distinguishing prefix, such as 'smiNNN-' where NNN is an SMI Private Enterprise Number (PEN) [IANA-PEN]. For example, if the company Example Corp. had obtained the SMI PEN 32473, then a vendor keyword 'foo' would be 'smi32473-foo'. Note: Prior versions of this document recommended using a fully qualified domain name [RFC1035] as the prefix (e.g., 'example.com-foo'), and many IPP implementations have also used reversed domain names (e.g., 'com.example-foo'). Domain names have proven problematic due to the length of some domain names, parallel use of country-specific domain names (e.g., 'example.co.jp-foo'), and changes in ownership of domain names. When a type2 keyword extension is approved, the IPP Designated Expert(s) becomes the point of contact for any future maintenance that might be required for that registration.
Top   ToC   RFC8011 - Page 176

7.4. Enum Extensibility

The IANA policy (using terms defined in [RFC5226]) for type1 enum extensions is Specification Required. The IANA policy for type2 enum extensions is Expert Review. The IANA policy for vendor enum extensions is First Come First Served. Only attributes using the type1 and type2 enum syntax can be registered in the IANA IPP registry. Note: The type1 or type2 prefix on the basic attribute syntax is provided only to communicate the IANA policy required for registration and is not represented in IPP messages. Both type1 and type2 enum values are represented using the same enum value tag. For vendor enum extensions, implementors MUST use values in the reserved integer range, which is 0x40000000 to 0x7fffffff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. When a type1 or type2 enum extension is approved, the IPP Designated Expert(s), in consultation with IANA, assigns the next available enum number for each enum value. When a type2 enum extension is approved, the IPP Designated Expert(s) becomes the point of contact for any future maintenance that might be required for that registration.

7.5. Attribute Group Extensibility

The IANA policy (using terms defined in [RFC5226]) for attribute group extensions was formerly Expert Review; this document changes the policy to Specification Required. For attribute groups, the IPP Designated Expert(s), in consultation with IANA, assigns the next attribute group tag code in the appropriate range as specified in [RFC8010].

7.6. Out-of-Band Attribute Value Extensibility

The IANA policy (using terms defined in [RFC5226]) for out-of-band attribute value extensions was formerly Expert Review; this document changes the policy to Specification Required. For out-of-band attribute value tags, the IPP Designated Expert(s), in consultation with IANA, assigns the next out-of-band attribute value tag code in the appropriate range as specified in [RFC8010].
Top   ToC   RFC8011 - Page 177

7.7. Attribute Syntax Extensibility

The IANA policy (using terms defined in [RFC5226]) for attribute syntax extensions was formerly Expert Review; this document changes the policy to Specification Required. The IANA policy for vendor attribute syntax extensions (tags 0x40000000 to 0x7fffffff) is First Come First Served. Only attribute syntaxes in the range of 0x00000000 to 0x3fffffff can be registered in the IANA IPP registry. For vendor attribute syntax extensions, implementors MUST use values in the reserved integer range, which is 0x40000000 to 0x7fffffff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered attribute syntaxes, the IPP Designated Expert(s), in consultation with IANA, assigns the next attribute syntax tag in the appropriate range as specified in [RFC8010].

7.8. Operation Extensibility

The IANA policy (using terms defined in [RFC5226]) for operation extensions is Expert Review. The IANA policy for vendor operation extensions (values 0x4000 to 0x7fff) is First Come First Served. Only operation codes in the range of 0x0000 to 0x3fff can be registered in the IANA IPP registry. For vendor operation extensions, implementors MUST use values in the reserved integer range, which is 0x4000 to 0x7fff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered operation extensions, the IPP Designated Expert(s), in consultation with IANA, assigns the next "operation-id" code as specified in Section 5.4.15.
Top   ToC   RFC8011 - Page 178

7.9. Status-Code Extensibility

The IANA policy (using terms defined in [RFC5226]) for status-code extensions is Expert Review. The IANA policy for vendor status-code extensions (codes 0x0n80 to 0x0nff, for n = 0 to 5) is First Come First Served. Only status-code values in the range of 0x0n00 to 0x0n7f can be registered in the IANA IPP registry. The status-code values are allocated in ranges as specified in Appendix B for each status-code class: "informational" - Request received, continuing process "successful" - The action was successfully received, understood, and accepted "redirection" - Further action is taken in order to complete the request "client-error" - The request contains bad syntax or cannot be fulfilled "server-error" - The IPP object failed to fulfill an apparently valid request For vendor operation status-code extensions, implementors MUST use the top of each range (0x0n80 to 0x0nff) as specified in Appendix B. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered operation status-code values, the IPP Designated Expert(s), in consultation with IANA, assigns the next status-code in the appropriate class range as specified in Appendix B.
Top   ToC   RFC8011 - Page 179

8. Internationalization Considerations

Some of the attributes have values that are text strings and names that are intended for human understanding rather than machine understanding (see the 'text' and 'name' attribute syntaxes in Sections 5.1.2 and 5.1.3). In each operation request, the Client o identifies the charset and natural language of the request that affects each supplied 'text' and 'name' attribute value, and o requests the charset and natural language for attributes returned by the IPP object in operation responses (as described in Section 4.1.4.1). In addition, the Client MAY separately and individually identify the Natural Language Override of a supplied 'text' or 'name' attribute using the 'textWithLanguage' and 'nameWithLanguage' techniques described in Sections 5.1.2.2 and 5.1.3.2, respectively. All IPP objects MUST support the UTF-8 [RFC3629] charset in all 'text' and 'name' attributes supported. If an IPP object supports more than the UTF-8 charset, the object MUST convert between them in order to return the requested charset to the Client according to Section 4.1.4.2. If an IPP object supports more than one natural language, the object SHOULD return 'text' and 'name' values in the natural language requested where those values are generated by the Printer (see Section 4.1.4.1). For Printers that support multiple charsets and/or multiple natural languages in 'text' and 'name' attributes, different Jobs might have been submitted in differing charsets and/or natural languages. All responses MUST be returned in the charset requested by the Client. However, the Get-Jobs operation uses the 'textWithLanguage' and 'nameWithLanguage' mechanisms to identify the differing natural languages with each Job attribute returned. The Printer also has configured charset and natural language attributes. The Client can query the Printer to determine the list of charsets and natural languages supported by the Printer and what the Printer's configured values are. See the "charset-configured", "charset-supported", "natural-language-configured", and "generated-natural-language-supported" Printer Description attributes for more details.
Top   ToC   RFC8011 - Page 180
   The "charset-supported" attribute identifies the supported charsets.
   If a charset is supported, the IPP object MUST be capable of
   converting to and from that charset into any other supported charset.
   In many cases, an IPP object will support only one charset, and it
   MUST be the UTF-8 charset.

   The "charset-configured" attribute identifies the one supported
   charset that is the native charset, given the current configuration
   of the IPP object (Administrator defined).

   The "generated-natural-language-supported" attribute identifies the
   set of supported natural languages for generated messages; it is not
   related to the set of natural languages that MUST be accepted for
   Client-supplied 'text' and 'name' attributes.  For Client-supplied
   'text' and 'name' attributes, an IPP object MUST accept ALL supplied
   natural languages.  For example, if a Client supplies a Job name that
   is in 'fr-ca' but the Printer only generates 'en-us', the Printer
   object MUST still accept the Job name value.

   The "natural-language-configured" attribute identifies the one
   supported natural language for generated messages that is the native
   natural language, given the current configuration of the IPP object
   (Administrator defined).

   Attributes of types 'text' and 'name' are populated from different
   sources.  These attributes can be categorized into the following
   groups (depending on the source of the attribute):

   1.  Some attributes are supplied by the Client (e.g., the
       Client-supplied "job-name", "document-name", and
       "requesting-user-name" operation attributes along with the
       corresponding Job's "job-name" and "job-originating-user-name"
       attributes).  The IPP object MUST accept these attributes in any
       natural language no matter what the set of supported languages
       for generated messages.

   2.  Some attributes are supplied by the Administrator (e.g., the
       Printer's "printer-name" and "printer-location" attributes).
       These can also be in any natural language.  If the natural
       language for these attributes is different than what a Client
       requests, then they MUST be reported using the Natural Language
       Override mechanism.
Top   ToC   RFC8011 - Page 181
   3.  Some attributes are supplied by the device manufacturer (e.g.,
       the Printer's "printer-make-and-model" attribute).  These can
       also be in any natural language.  If the natural language for
       these attributes is different than what a Client requests, then
       they MUST be reported using the Natural Language Override
       mechanism.

   4.  Some attributes are supplied by the Operator (e.g., the Job's
       "job-message-from-operator" attribute).  These can also be in any
       natural language.  If the natural language for these attributes
       is different than what a Client requests, then they MUST be
       reported using the Natural Language Override mechanism.

   5.  Some attributes are generated by the IPP object (e.g., the Job's
       "job-state-message" attribute, the Printer's
       "printer-state-message" attribute, and the "status-message"
       operation attribute).  These attributes can only be in one of the
       "generated-natural-language-supported" natural languages.  If a
       Client requests some natural language for these attributes other
       than one of the supported values, the IPP object SHOULD respond
       using the value of the "natural-language-configured" attribute
       (using the Natural Language Override mechanism if needed).

   The 'text' and 'name' attributes specified in this version of this
   document (additional ones will be registered according to the
   procedures in Section 7) are shown in Table 22.

   +-----------------------------------+-------------------------------+
   | Attributes                        | Source                        |
   +-----------------------------------+-------------------------------+
   | Operation Attributes:             |                               |
   |                                   |                               |
   | job-name (name)                   | Client                        |
   | document-name (name)              | Client                        |
   | requesting-user-name (name)       | Client                        |
   | status-message (text)             | Job or Printer                |
   | detailed-status-message (text)    | Job or Printer (note 1)       |
   | document-access-error (text)      | Job or Printer (note 1)       |
   |                                   |                               |
   | Job Template Attributes:          |                               |
   |                                   |                               |
   | job-hold-until (keyword | name)   | Client matches Administrator- |
   |                                   | configured                    |
   | job-hold-until-default (keyword | | Client matches Administrator- |
   | name)                             | configured                    |
   | job-hold-until-supported (keyword | Client matches Administrator- |
   | | name)                           | configured                    |
Top   ToC   RFC8011 - Page 182
   | job-sheets (keyword | name)       | Client matches Administrator- |
   |                                   | configured                    |
   | job-sheets-default (keyword |     | Client matches Administrator- |
   | name)                             | configured                    |
   | job-sheets-supported (keyword |   | Client matches Administrator- |
   | name)                             | configured                    |
   | media (keyword | name)            | Client matches Administrator- |
   |                                   | configured                    |
   | media-default (keyword | name)    | Client matches Administrator- |
   |                                   | configured                    |
   | media-supported (keyword | name)  | Client matches Administrator- |
   |                                   | configured                    |
   | media-ready (keyword | name)      | Client matches Administrator- |
   |                                   | configured                    |
   |                                   |                               |
   | Job Description Attributes:       |                               |
   |                                   |                               |
   | job-name (name)                   | Client or Printer             |
   | job-originating-user-name (name)  | Printer                       |
   | job-state-message (text)          | Job or Printer                |
   | output-device-assigned            | Administrator                 |
   | (name(127))                       |                               |
   | job-message-from-operator         | Operator                      |
   | (text(127))                       |                               |
   | job-detailed-status-messages      | Job or Printer (note 1)       |
   | (1setOf text)                     |                               |
   | job-document-access-errors        | Job or Printer (note 1)       |
   | (1setOf text)                     |                               |
   |                                   |                               |
   | Printer Description Attributes:   |                               |
   |                                   |                               |
   | printer-name (name(127))          | Administrator                 |
   | printer-location (text(127))      | Administrator                 |
   | printer-info (text(127))          | Administrator                 |
   | printer-make-and-model            | Administrator or manufacturer |
   | (text(127))                       |                               |
   | printer-state-message (text)      | Printer                       |
   | printer-message-from-operator     | Operator                      |
   | (text(127))                       |                               |
   +-----------------------------------+-------------------------------+

                  Table 22: 'text' and 'name' Attributes

   Note 1: Neither the Printer nor the Client localizes these message
   attributes, since they are intended for use by the Administrator or
   other experienced technical persons.
Top   ToC   RFC8011 - Page 183

9. Security Considerations

It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given small business over a private LAN with physical security, the risks of exposing Document data can be low enough that the business will choose not to use encryption on that data. However, if the connection between the Client and the IPP object is over a public network, the Client can protect the content of the information during transmission through the network with encryption. Furthermore, the value of the information being printed can vary from one IPP environment to the next. Printing payroll checks, for example, would have a different value than printing public information from a file. There is also the possibility of denial-of- service attacks, but denial-of-service attacks against printing resources are not well understood, and there are no published precedents regarding this scenario. Once the authenticated identity of the requester has been supplied to the IPP object, the object uses that identity to enforce any authorization policy that might be in place. For example, one site's policy might be that only the Job owner is allowed to cancel a Job. The details and mechanisms to set up a particular access control policy are not part of this document and are typically established via some other type of administrative or access control framework. However, there are operation status-code values that allow an IPP server to return information back to a Client about any potential access control violations for an IPP object. During a Job Creation request, the Client's identity is recorded in the Job object in an implementation-defined attribute. This information can be used to verify a Client's identity for subsequent operations on that Job object in order to enforce any access control policy that might be in effect. See Section 9.3 below for more details. This and other information stored in the Job object can also be considered personal or sensitive in nature and can be filtered out as part of a configured privacy policy (Section 9.4). Since the security levels or the specific threats that an Administrator can be concerned with cannot be anticipated, IPP implementations MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong to very weak, or to none at all, and corresponding security mechanisms will be required.
Top   ToC   RFC8011 - Page 184

9.1. Security Scenarios

The following sections describe specific security attacks for IPP environments. Where examples are provided, they are illustrative of the environment and not an exhaustive set.

9.1.1. Client and Server in the Same Security Domain

This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared workgroup Printers, or where batch applications print their output on large production Printers. Although the identity of the user has been authenticated and can be trusted in this environment, a user might want to protect the content of a Document against such attacks as eavesdropping, replaying, or tampering by using a secure transport such as TLS [RFC5246].

9.1.2. Client and Server in Different Security Domains

Examples of this environment include printing a Document created by the Client on a publicly available Printer, such as at a commercial print shop, or printing a Document remotely on a business associate's Printer. This latter operation is functionally equivalent to sending the Document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment, authentication of the Printer is required as well as protection against unauthorized use of print resources. Since the Document crosses security domains, protection against eavesdropping and Document tampering is also required. It will also be important in this environment to protect Printers against "spamming" and malicious Document content -- authentication and Document data pre-scanning can be used to minimize those threats.

9.1.3. Print by Reference

When the Document is not stored on the Client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the Document instead of the actual Document itself -- see Sections 4.2.2 and 4.3.2. Standard methods currently do not exist for remote entities to "assume" the credentials of a Client for forwarding requests to a third party. It is anticipated that print by reference will be used to access "public" Documents. Note that sophisticated methods for authenticating "proxies" are beyond the scope of this IPP/1.1 document. Because Printers typically process Jobs serially, print by reference is not seen as a serious denial-of- service threat to the referenced servers.
Top   ToC   RFC8011 - Page 185

9.2. URIs in Operation, Job, and Printer Attributes

The "printer-uri-supported" attribute contains the Printer's URI(s). Its companion attribute, "uri-security-supported", identifies the security mechanism used for each URI listed in the "printer-uri-supported" attribute. For each Printer operation request, a Client MUST supply only one URI in the "printer-uri" operation attribute. In other words, even though the Printer supports more than one URI, the Client only interacts with the Printer using one of its URIs. This duality is not needed for Job objects, since Printers will act as the "factory" for Job objects and a given Printer will, depending on the Printer's security configuration, generate the correct URI for new Job objects.

9.3. URIs for Each Authentication Mechanism

Each URI has an authentication mechanism associated with it. If the URI is the "i-th" element of "printer-uri-supported", then the authentication mechanism is the "i-th" element of "uri-authentication-supported". For a list of possible authentication mechanisms, see Section 5.4.2. The Printer uses an authentication mechanism to determine the name of the user performing an operation. This user is called the "authenticated user". The credibility of authentication depends on the mechanism that the Printer uses to obtain the user's name. When the authentication mechanism is 'none', all authenticated users are 'anonymous'. During Job Creation requests, the Printer initializes the value of the "job-originating-user-name" attribute (see Section 5.3.6) to be the authenticated user. The authenticated user in this case is called the "Job owner". If an implementation can be configured to support more than one authentication mechanism (see Section 5.4.2), then it MUST implement rules for determining equality of authenticated user names that have been authenticated via different authentication mechanisms. One possible policy is that identical names that are authenticated via different mechanisms are different. For example, a user can cancel his Job only if he uses the same authentication mechanism for both Cancel-Job and Print-Job. Another policy is that identical names that are authenticated via different mechanisms are the same if the authentication mechanism for the later operation is not less strong than the authentication mechanism for the earlier Job Creation operation. For example, a user can cancel his Job only if he uses the same or stronger authentication mechanism for Cancel-Job and Print-Job. With this second policy, a Job submitted via
Top   ToC   RFC8011 - Page 186
   'requesting-user-name' authentication could be canceled via 'digest'
   authentication.  With the first policy, the Job could not be canceled
   in this way.

   A Client is able to determine the authentication mechanism used to
   create a Job.  It is the "i-th" value of the Printer's
   "uri-authentication-supported" attribute (see Section 5.4.2),
   where "i" is the index of the element of the Printer's
   "printer-uri-supported" attribute (see Section 5.4.1) equal to the
   Job's "job-printer-uri" attribute (see Section 5.3.3).

9.4. Restricted Queries

In many IPP operations, a Client supplies a list of attributes to be returned in the response. For security reasons, an IPP object can be configured not to return all attributes (or all values) that a Client requests. The Job attributes returned MAY depend on whether the requesting user is the same as the user that submitted the Job. The IPP object MAY even return none of the requested attributes. In such cases, the status returned is the same as if the object had returned all requested attributes. The Client cannot tell by such a response whether the requested attribute was present or absent in the object.

9.5. Operations Performed by Operators and Administrators

For the three Printer operations Pause-Printer, Resume-Printer, and Purge-Jobs (see Sections 4.2.7, 4.2.8, and 4.2.9), the requesting user is intended to be an Operator or Administrator of the Printer (see Section 1). Otherwise, the IPP Printer MUST reject the operation and return 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate. For operations on Jobs, the requesting user is intended to be the Job owner or can be an Operator or Administrator of the Printer. The means for authorizing an Operator or Administrator of the Printer are not specified in this document.

9.6. Queries on Jobs Submitted Using Non-IPP Protocols

If the device that an IPP Printer is representing is able to accept Jobs using other Job submission protocols in addition to IPP, such an implementation SHOULD at least allow such "foreign" Jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. Such an implementation MAY support all of the same IPP Job attributes as for IPP Jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign Job that is supported for IPP Jobs but not for foreign Jobs.
Top   ToC   RFC8011 - Page 187
   IPP Printers SHOULD also generate "job-id" and "job-uri" values for
   such foreign Jobs, if possible, so that they can be targets of other
   IPP operations, such as Get-Job-Attributes and Cancel-Job.  Such an
   implementation also needs to deal with the problem of authentication
   of such foreign Jobs.  One approach would be to treat all such
   foreign Jobs as belonging to users other than the user of the IPP
   Client.  Another approach would be for the foreign Job to belong to
   'anonymous' -- then only authenticated Operators or Administrators of
   the IPP Printer could query the foreign Jobs with an IPP request.
   Alternatively, if the security policy is to allow users to query
   other users' Jobs, then the foreign Jobs would also be visible to an
   End User IPP Client using Get-Jobs and Get-Job-Attributes.

10. Changes since RFC 2911

The following changes have been made since RFC 2911: o Errata ID 364: Fixed range of "redirection" status-code values (to 0x03xx). o Errata ID 694: Fixed range of vendor status-code values (0x0n80 to 0x0nff). o Errata ID 3072: Reworded multiple-document-handling definition, since it also applies to Jobs with a single Document and is the only interoperable way to request uncollated copies. o Errata ID 3365: Fixed bad 'nameWithLanguage' maximum length by referencing the 'nameWithoutLanguage' section (i.e., Section 5.1.3.1). o Errata ID 4173: Fixed range of vendor operation codes (0x4000 to 0x7fff). o Updated obsoleted RFC references. o Changed the IPP/1.1 Implementor's Guide reference to RFC 3196. o Updated Create-Job, Send-Document, and Send-URI to RECOMMENDED. o Incorporated 'collection' attribute content from RFC 3382. o Obsoleted all attributes and values defined in RFC 3381, as they do not interact well with the "finishings" attribute and have never been widely implemented. o Deprecated the Purge-Jobs and Restart-Job operations, which destroy accounting information.
Top   ToC   RFC8011 - Page 188
   o  Dropped type3 registration procedures.

   o  Changed the vendor attribute and keyword naming recommendations to
      use SMI Private Enterprise Numbers ("smiNNN-foo") instead of
      domain names.

   o  Split READ-ONLY Job Description and Printer Description attributes
      into Job Status and Printer Status attributes to match the current
      IANA IPP registry organization.

   o  Referenced all IETF and PWG IPP standards.

   o  Updated OPTIONAL operations, attributes, and values to RECOMMENDED
      for consistency with IPP 2.0, IPP Everywhere, and the IPP
      Implementor's Guide v2.0.

   o  Removed the appendix on media names.  Readers are directed to
      "PWG Media Standardized Names 2.0 (MSN2)" [PWG5101.1].



(page 188 continued on part 11)

Next Section