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.

   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.

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.

         +----------------------------------------+-------------+
         | 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

   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.

   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.

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

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

   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.

   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.

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

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.

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.

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.

   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.

   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                    |

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

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.

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.

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

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

   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.

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