5.2.7 Security

   An IPP Printer implementation SHOULD contain support for Client
   Authentication as defined in the IPP/1.1 Encoding and Transport
   document [RFC2910].  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 8 of this document.

   An IPP Printer implementation SHOULD contain support for Operation
   Privacy and Server Authentication as defined in the IPP/1.1 Encoding
   and Transport document [RFC2910].  A Printer implementation MAY allow
   an administrator to configure the degree of support for Operation
   Privacy and Server Authentication.  See also section 8 of this
   document.

   Security MUST NOT be compromised when a client supplies a lower
   "version-number" parameter in a request.  For example, if an IPP/1.1
   conforming Printer object accepts version '1.0' requests and is
   configured to enforce Digest Authentication, it MUST do the same for
   a version '1.0' request.

5.3 Charset and Natural Language Requirements

   All clients and IPP objects MUST support the 'utf-8' charset as
   defined in section 4.1.7.

   IPP objects MUST be able to accept any client request which 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
   3.1.4).  That is, the IPP object that supports a natural language
   NEED NOT be a general purpose translator of any arbitrary 'text' or
   'name' value supplied by the client into that natural language.
   However, the object MUST be able to translate (automatically
   generate) any of its own attribute values and messages into that
   natural language.

6. IANA Considerations

   This section describes the procedures for defining semantics for the
   following IETF standards track extensions and vendor extensions to
   the IPP/1.1 Model and Semantics document:

      1. keyword attribute values
      2. enum attribute values

      3. attributes
      4. attribute syntaxes
      5. operations
      6. attribute groups
      7. status codes
      8. out-of-band attribute values

   Extensions registered for use with IPP/1.1 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 by the IESG [IANA-CON].  Section 11 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 Section 11.  The IPP/1.1 Model and
   Semantics document may also be extended by an appropriate RFC that
   specifies any of the above extensions.

6.1 Typed 'keyword' and 'enum' Extensions

   IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3
   and 4.1.4).  This document uses prefixes to the 'keyword' and 'enum'
   basic attribute syntax type in order to communicate extra information
   to the reader through its name. This extra information is not
   represented in the protocol because it is unimportant to a client or
   Printer object.  The list below describes the prefixes and their
   meaning.

      "type1":  This IPP specification document must be revised (or
         another IETF standards track document which augments this
         document) to add a new keyword or a new enum.  No vendor
         defined keywords or enums are allowed.

      "type2":  Implementers can, at any time, add new keyword or enum
         values by proposing the complete specification to IANA:

         iana@iana.org

         IANA will forward the registration proposal to the IPP
         Designated Expert who will review the proposal with a mailing
         list that the Designated Expert keeps for this purpose.
         Initially, that list will be the mailing list used by the IPP
         WG:

            ipp@pwg.org

         even after the IPP WG is disbanded as permitted by [IANA-CON].

         The IPP Designated Expert is appointed by the IESG Area
         Director responsible for IPP, according to [IANA-CON].

         When a type2 keyword or enum is approved, the IPP Designated
         Expert becomes the point of contact for any future maintenance
         that might be required for that registration.

      "type3":  Implementers can, at any time, add new keyword and enum
         values by submitting the complete specification to IANA as for
         type2 who will forward the proposal to the IPP Designated
         Expert.  While no additional technical review is required, the
         IPP Designated Expert may, at his/her discretion, forward the
         proposal to the same mailing list as for type2 registrations
         for advice and comment.

         When a type3 keyword or enum is approved by the IPP Designated
         Expert, the original proposer becomes the point of contact for
         any future maintenance that might be required for that
         registration.

   For type2 and type3 keywords, the proposer includes the name of the
   keyword in the registration proposal and the name is part of the
   technical review.

   After type2 and type3 enums specifications are approved, the IPP
   Designated Expert in consultation with IANA assigns the next
   available enum number for each enum value.

   IANA will publish approved type2 and type3 keyword and enum
   attributes value registration specifications in:

      ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt

   where xxx is the attribute name that specifies the initial values and
   yyy.txt is a descriptive file name that contains one or more enums or
   keywords approved at the same time.  For example, if several
   additional enums for stapling are approved for use with the
   "finishings" attribute (and "finishings-default" and "finishings-
   supported" attributes), IANA will publish the additional values in
   the file:

      ftp.isi.edu/iana/assignments/ipp/attribute-
      values/finishings/stapling.txt

   Note: Some attributes are defined to be: 'type3 keywords' | 'name'
   which allows for attribute values to be extended by a site
   administrator with administrator defined names.  Such names are not
   registered with IANA.

   By definition, each of the three types above assert some sort of
   registry or review process in order for extensions to be considered
   valid.  Each higher numbered level (1, 2, 3) tends to be decreasingly
   less stringent than the previous level.   Therefore, any typeN value
   MAY be registered using a process for some typeM where M is less than
   N, however such registration is NOT REQUIRED.  For example, a type3
   value MAY be registered in a type 1 manner (by being included in a
   future version of an IPP specification), however, it is NOT REQUIRED.

   This document defines keyword and enum values for all of the above
   types, including type3 keywords.

   For vendor keyword extensions, implementers SHOULD use keywords with
   a suitable distinguishing prefix, such as "xxx-" where xxx follows
   the syntax rules for keywords (see section 4.1.3) and is the
   (lowercase) fully qualified company name registered with IANA for use
   in domain names [RFC1035].  For example, if the company XYZ Corp. had
   obtained the domain name "XYZ.com", then a vendor keyword 'abc' would
   be: 'xyz.com-abc'.

   Note: RFC 1035 [RFC1035] indicates that while upper and lower case
   letters are allowed in domain names, no significance is attached to
   the case.  That is, two names with the same spelling but different
   case are to be treated as if identical.  Also, the labels in a domain
   name must follow the rules for ARPANET host names:  They must start
   with a letter, end with a letter or digit, and have as interior
   characters only letters, digits, and hyphen.  Labels must be 63
   characters or less.  Labels are separated by the "." character.

   For vendor enum extensions, implementers MUST use values in the
   reserved integer range which is 2**30 to 2**31-1.

6.2 Attribute Extensibility

   Attribute names (see section 4.1.3) are type2 keywords.  Therefore,
   new attributes may be registered and have the same status as
   attributes in this document by following the type2 extension rules.
   For vendor attribute extensions, implementers SHOULD use keywords
   with a suitable distinguishing prefix as described in Section 6.1.

   IANA will publish approved attribute registration specifications as
   separate files:

      ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt

   where "xxx-yyy" is the new attribute name.

   If a new Printer object 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 3.2.5.1)."

   If the specification does not, then its value in the Get-Printer-
   Attributes response MUST NOT depend on the "document-format" 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.

6.3 Attribute Syntax Extensibility

   Attribute syntaxes (see section 4.1) are like type2 enums.
   Therefore, new attribute syntaxes may be registered and have the same
   status as attribute syntaxes in this document by following the type2
   extension rules described in Section 6.1.  The initial set of value
   codes that identify each of the attribute syntaxes have been assigned
   in the "Encoding and Transport" document [RFC2910], including a
   designated range for vendor extension.

   For attribute syntaxes, the IPP Designated Expert in consultation
   with IANA assigns the next attribute syntax code in the appropriate
   range as specified in [RFC2910].  IANA will publish approved
   attribute syntax registration specifications as separate files:

      ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt

   where 'xxx-yyy' is the new attribute syntax name.

6.4 Operation Extensibility

   Operations (see section 3) may also be registered following the type2
   procedures described in Section 6.1, though major new operations will
   usually be done by a new standards track RFC that augments this
   document.  For vendor operation extensions, implementers MUST use the
   range for the "operation-id" in requests specified in Section 4.4.15
   "operations-supported" Printer attribute.

   For operations, the IPP Designated Expert in consultation with IANA
   assigns the next operation-id code as specified in Section 4.4.15.
   IANA will publish approved operation registration specifications as
   separate files:

      ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt

   where "Xxx-Yyy" is the new operation name.

6.5 Attribute Group Extensibility

   Attribute groups (see section 3.1.3) passed in requests and responses
   may be registered following the type2 procedures described in Section
   6.1.  The initial set of attribute group tags have been assigned in
   the "Encoding and Transport" document [RFC2910], including a
   designated range for vendor extension.

   For attribute groups, the IPP Designated Expert in consultation with
   IANA assigns the next attribute group tag code in the appropriate
   range as specified in [RFC2910].  IANA will publish approved
   attribute group registration specifications as separate files:

      ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
      tag.txt

   where 'xxx-yyy-tag' is the new attribute group tag name.

6.6 Status Code Extensibility

   Operation status codes (see section 3.1.6.1) may also be registered
   following the type2 procedures described in Section 6.1.  The values
   for status codes are allocated in ranges as specified in Section 14
   for each status code class:

      "informational" - Request received, continuing process
      "successful" - The action was successfully received, understood, and
         accepted
      "redirection" - Further action must be 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, implementers MUST use
   the top of each range as specified in Section 13.

   For operation status codes, the IPP Designated Expert in consultation
   with IANA assigns the next status code in the appropriate class range
   as specified in Section 13.  IANA will publish approved status code
   registration specifications as separate files:

      ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt

   where "xxx-yyy" is the new operation status code keyword.

6.7 Out-of-band Attribute Value Extensibility

   Out-of-band attribute values (see the beginning of section 4.1)
   passed in requests and responses may be registered following the
   type2 procedures described in Section 6.1.  The initial set of out-
   of-band attribute value tags have been assigned in the "Encoding and
   Transport" document [RFC2910].

   For out-of-band attribute value tags, the IPP Designated Expert in
   consultation with IANA assigns the next out-of-band attribute value
   tag code in the appropriate range as specified in [RFC2910].  IANA
   will publish approved out-of-band attribute value tags registration
   specifications as separate files:

      ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-
      tags/xxx-yyy-tag.txt

   where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.

6.8 Registration of MIME types/sub-types for document-formats

   The "document-format" attribute's syntax is 'mimeMediaType'.  This
   means that valid values are Internet Media Types (see Section 4.1.9).
   RFC 2045 [RFC2045] defines the syntax for valid Internet media types.
   IANA is the registry for all Internet media types.

6.9 Registration of charsets for use in 'charset' attribute values

   The "attributes-charset" attribute's syntax is 'charset'.  This means
   that valid values are charsets names.  When a charset in the IANA
   registry has more than one name (alias), the name labeled as
   "(preferred MIME name)", if present, MUST be used (see Section
   4.1.7).  IANA is the registry for charsets following the procedures
   of [RFC2278].

7. Internationalization Considerations

   Some of the attributes have values that are text strings and names
   which are intended for human understanding rather than machine
   understanding (see the 'text' and 'name' attribute syntaxes in
   Sections 4.1.1 and 4.1.2).

   In each operation request, the client

      - identifies the charset and natural language of the request which
        affects each supplied 'text' and 'name' attribute value, and

      - requests the charset and natural language for attributes
        returned by the IPP object in operation responses (as described
        in Section 3.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' technique
   described section 4.1.1.2 and 4.1.2.2 respectively.

   All IPP objects MUST support the UTF-8 [RFC2279] 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 3.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 3.1.4.1).

   For Printers that support multiple charsets and/or multiple natural
   languages in 'text' and 'name' attributes, different jobs may 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' mechanism to identify the differing natural
   languages with each job attribute returned.

   The Printer object also has configured charset and natural language
   attributes.   The client can query the Printer object to determine
   the list of charsets and natural languages supported by the Printer
   object and what the Printer object'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" attributed 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 which 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.  Just because a Printer object is currently
   configured to support 'en-us' natural language does not mean that the
   Printer object should reject a job if the client supplies a job name
   that is in 'fr-ca'.

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

   Attributes of type 'text' and 'name' are populated from different
   sources.  These attributes can be categorized into 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
         object'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 system administrator (e.g.,
         the Printer object's "printer-name" and "printer-location"
         attributes).  These too can 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 object's "printer-make-and-model" attribute).
         These too can 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
         object's "job-message-from-operator" attribute). These too can
         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
         object's "job-state-message" attribute, the Printer object'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 6) are:

                    Attributes                            Source

   Operation Attributes:
        job-name (name)                         client
        document-name (name)                    client
        requesting-user-name (name)             client
        status-message (text)                   Job or Printer object
        detailed-status-message (text)          Job or Printer object -
                                                see rule 1
        document-access-error (text)            Job or Printer object -
                                                see rule 1

   Job Template Attributes:
        job-hold-until (keyword | name)         client matches
                                                administrator-configured
        job-hold-until-default (keyword | name) client matches
                                                administrator-configured
        job-hold-until-supported (keyword |     client matches
        name)                                   administrator-configured
        job-sheets (keyword | name)             client matches
                                                administrator-configured
        job-sheets-default (keyword | name)     client matches
                                                administrator-configured
        job-sheets-supported (keyword | name)   client matches
                                                administrator-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 object
        job-originating-user-name (name)        Printer object
        job-state-message (text)                Job or Printer object
        output-device-assigned (name(127))      administrator
        job-message-from-operator (text(127))   operator

        job-detailed-status-messages (1setOf    Job or Printer object -
        text)                                   see rule 1
        job-document-access-errors (1setOf      Job or Printer object -
        text)                                   see rule 1

   Printer Description Attributes:
        printer-name (name(127))                administrator
        printer-location (text(127))            administrator
        printer-info (text(127))                administrator
        printer-make-and-model (text(127))      administrator or
                                                manufacturer
        printer-state-message (text)            Printer object
        printer-message-from-operator           operator
        (text(127))

   Rule 1 - Neither the Printer nor the client localizes these message
   attributes, since they are intended for use by the system
   administrator or other experienced technical persons.

8. 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
   corporation over a private network, the risks of exposing document
   data may be low enough that the corporation 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 may
   wish to protect the content of the information during transmission
   through the network with encryption.

   Furthermore, the value of the information being printed may 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 possibly of denial-of-
   service attacks, but denial-of-service attacks against printing
   resources are not well understood and there is 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 IPP/1.1, and must be established via some
   other type of administrative or access control framework.  However,
   there are operation status codes that allow an IPP server to return
   information back to a client about any potential access control
   violations for an IPP object.

   During a create operation, 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 8.3 below for more details.

   Since the security levels or the specific threats that an IPP system
   administrator may be concerned with cannot be anticipated, IPP 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, to none
   at all, and corresponding security mechanisms will be required.

8.1 Security Scenarios

   The following sections describe specific security attacks for IPP
   environments.  Where examples are provided they should be considered
   illustrative of the environment and not an exhaustive set. Not all of
   these environments will necessarily be addressed in initial
   implementations of IPP.

8.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 work-group printers, or where batch applications print
   their output on large production printers. Although the identity of
   the user may be trusted in this environment, a user might want to
   protect the content of a document against such attacks as
   eavesdropping, replaying or tampering.

8.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 are also
   required. It will also be important in this environment to protect
   Printers against "spamming" and malicious document content.

8.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 3.2.2 and 3.3.2). Standard methods currently do not exist
   for remote entities to "assume" the credentials of a client for
   forwarding requests to a 3rd party. It is anticipated that Print-By-
   Reference will be used to access "public" documents and that
   sophisticated methods for authenticating "proxies" is not specified
   in this document.

8.2 URIs in Operation, Job, and Printer attributes

   The "printer-uri-supported" attribute contains the Printer object'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 object using one if its URIs.  This duality is not needed for
   Job objects, since the Printer objects is the factory for Job
   objects, and the Printer object will generate the correct URI for new
   Job objects depending on the Printer object's security configuration.

8.3 URIs for each authentication mechanisms

   Each URI has an authentication mechanism associated with it. If the
   URI is the i'th element of "printer-uri-supported", then
   authentication mechanism is the "i th" element of "uri-
   authentication-supported". For a list of possible authentication
   mechanisms, see section 4.4.2.

   The Printer object 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 operations, the Printer initializes the value of
   the "job-originating-user-name" attribute (see section 4.3.6) to be
   the authenticated user. The authenticated user is this case is called
   the "job owner".

   If an implementation can be configured to support more than one
   authentication mechanism (see section 4.4.2), then it MUST implement
   rules for determining equality of authenticated user names which 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 mechanism 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 4.4.2), where i is
   the index of the element of the Printer's "printer-uri-supported"
   attribute (see section 4.4.1) equal to the job's "job-printer-uri"
   attribute (see section 4.3.3).

8.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 may 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 on the object.

8.5 Operations performed by operators and system administrators

   For the three printer operations Pause-Printer, Resume-Printer, and
   Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user
   is intended to be an operator or administrator of the Printer object
   (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 may be an operator or administrator of the Printer object.
   The means for authorizing an operator or administrator of the Printer
   object are not specified in this document.

8.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, it is
   RECOMMENDED that such an implementation at least allow such "foreign"
   jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
   'unknown'.  Such an implementation NEED NOT 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.

   It is further RECOMMENDED, that the IPP Printer generate "job-id" and
   "job-uri" values for such "foreign jobs", if possible, so that they
   may 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'.  Only if the IPP client has
   been authenticated as an operator or administrator of the IPP Printer
   object, could the foreign jobs be queried by 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.

9. References

   [ASME-Y14.1M] Metric Drawing Sheet Size and Format, ASME Y14.1M-1995.
                 This standard defines metric sheet sizes and formats
                 for engineering drawings.

   [ASCII]       Coded Character Set - 7-bit American Standard Code for
                 Information Interchange (ASCII), ANSI X3.4-1986. This
                 standard is the specification of the US-ASCII charset.

   [BCP-11]      Bradner S. and R. Hovey, "The Organizations Involved in
                 the IETF Standards Process", BCP 11, RFC 2028, October
                 1996.

   [HTPP]        J. Barnett, K. Carter, R. DeBry,  "Initial Draft -
                 Hypertext Printing Protocol - HTPP/1.0", October 1996,
              ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz

   [IANA-CON]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 2434, October 1998.

   [IANA-CS]     IANA Registry of Coded Character Sets:
                 ftp://ftp.isi.edu/in-notes/iana/assignments/character-
                 sets

   [IANA-MT]     IANA Registry of Media Types:  ftp://ftp.isi.edu/in-
                 notes/iana/assignments/media-types/

   [IPP-IIG]     Hastings, T., Manros, C., Kugler, C., Holst, H., and P.
                 Zehler, "Internet Printing Protocol/1.1:  draft-ietf-
                 ipp-implementers-guide-v11-01.txt, work in progress,
                 May 30, 2000.

   [ISO10646-1]  ISO/IEC 10646-1:1993, "Information technology --
                 Universal Multiple-Octet Coded Character Set (UCS) -
                 Part 1: Architecture and Basic Multilingual Plane,
                 JTC1/SC2."

   [ISO8859-1]   ISO/IEC 8859-1:1987, "Information technology -- 8-bit
                 One-Byte Coded Character Set - Part 1: Latin Alphabet
                 Nr 1", 1987, JTC1/SC2.

   [ISO10175]    ISO/IEC 10175 Document Printing Application (DPA), June
                 1996.

   [LDPA]        T. Hastings,  S. Isaacson,  M. MacKay, C. Manros, D.
                 Taylor, P. Zehler,  "LDPA - Lightweight Document
                 Printing Application", October 1996,
              ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz

   [P1387.4]     Kirk, M. (editor), POSIX System Administration - Part
                 4:  Printing Interfaces, POSIX 1387.4 D8, 1994.

   [PSIS]        Herriot, R. (editor), X/Open A Printing System
                 Interoperability Specification (PSIS), August 1995.

   [PWG]         Printer Working Group, http://www.pwg.org.

   [RFC1035]     Mockapetris, P., "Domain Names - Implementation and
                 Specification", STD 13, RFC 1035, November 1987.

   [RFC1179]     McLaughlin, L., "Line Printer Daemon Protocol", RFC
                 1179, August 1990.

   [RFC1759]     Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
                 Gyllenskog, "Printer MIB", RFC 1759, March 1995.

   [RFC1766]     Alvestrand, H., "Tags for the Identification of
                 Languages", RFC 1766, March 1995.

   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
                 Specification version 1.3 ", RFC 1951, May 1996.

   [RFC1952]     Deutsch, P., "GZIP file format specification version
                 4.3", RFC 1952, May 1996.

   [RFC1977]     Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
                 August 1996.

   [RFC2026]     Bradner, S., "The Internet Standards Process --
                 Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC2045]     Freed, N. and  N. Borenstein, ", Multipurpose Internet
                 Mail Extensions (MIME) Part One: Format of Internet
                 Message Bodies", RFC 2045, November 1996.

   [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
                 Mail Extensions (MIME) Part Two: Media Types", RFC
                 2046, November 1996.

   [RFC2048]     Freed, N., Klensin, J. and J. Postel, "Multipurpose
                 Internet Mail Extension (MIME) Part Four: Registration
                 Procedures", RFC 2048, November 1996.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2228]     Horowitz, M. and S. Lunt, "FTP Security Extensions",
                 RFC 2228, October 1997.

   [RFC2246]     Dierks, T. and C. Allen, "The TLS Protocol Version
                 1.0", RFC 2246, January 1999.

   [RFC2277]     Alvestrand, H., "IETF Policy on Character Sets and
                 Languages" BCP 18, RFC 2277, January 1998.

   [RFC2278]     Freed, N. and J. Postel: "IANA CharSet Registration
                 Procedures", BCP 19, RFC 2278, January 1998.

   [RFC2279]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", RFC 2279, January 1998.

   [RFC2316]     Bellovin, S., "Report of the IAB Security Architecture
                 Workshop", RFC 2316, April 1998.

   [RFC2396]     Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
                 Resource Identifiers (URI): Generic Syntax", RFC 2396,
                 August 1998.

   [RFC2565]     Herriot, R., Butler, S., Moore, P. and R. Turner,
                 "Internet Printing Protocol/1.0: Encoding and
                 Transport", RFC 2565, April 1999.

   [RFC2566]     deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
                 P. Powell, "Internet Printing Protocol/1.0: Model and
                 Semantics", RFC 2566, April 1999.

   [RFC2567]     Wright, D., "Design Goals for an Internet Printing
                 Protocol", RFC 2567, April 1999.

   [RFC2568]     Zilles, S., "Rationale for the Structure and Model and
                 Protocol for the Internet Printing Protocol", RFC 2568,
                 April 1999.

   [RFC2569]     Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
                 "Mapping between LPD and IPP Protocols", RFC 2569,
                 April 1999.

   [RFC2579]     McCloghrie, K., Perkins, D. and J. Schoenwaelder,
                 "Textual Conventions for SMIv2", STD 58, RFC 2579,
                 April 1999.

   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
                 Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]     Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
                 S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
                 Authentication:  Basic and Digest Access
                 Authentication", RFC 2617, June 1999.

   [RFC2639]     Hastings, T. and C. Manros, "Internet Printing
                 Protocol/1.0: Encoding and Transport", RFC 2639, July
                 1999.

   [RFC2910]     Herriot, R., Butler, S., Moore, P., Turner, R. and J.
                 Wenn, "Internet Printing Protocol/1.1: Encoding and
                 Transport", RFC 2910, September 2000.

   [SSL]         Netscape, The SSL Protocol, Version 3, (Text version
                 3.02), November 1996.

   [SWP]         P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
                 SWP/1.0", May 7, 1997,
                 ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf

10. Authors' Addresses

   Scott A. Isaacson, Editor
   Novell, Inc.
   122 E 1700 S
   Provo, UT   84606

   Phone: 801-861-7366
   Fax:   801-861-2517
   EMail: sisaacson@novell.com


   Tom Hastings
   Xerox Corporation
   737 Hawaii St.  ESAE 231
   El Segundo, CA   90245

   Phone: 310-333-6413
   Fax:   310-333-5514
   EMail: hastings@cp10.es.xerox.com


   Robert Herriot
   Xerox Corp.
   3400 Hill View Ave, Building 1
   Palo Alto, CA 94304

   Phone: 650-813-7696
   Fax:  650-813-6860
   EMail: robert.herriot@pahv.xerox.com


   Roger deBry
   Utah Valley State College
   Orem, UT 84058

   Phone: (801) 222-8000
   EMail: debryro@uvsc.edu

   Patrick Powell
   Astart Technologies
   9475 Chesapeake Dr., Suite D
   San Diego, CA  95123

   Phone: (619) 874-6543
   Fax:   (619) 279-8424
   EMail: papowell@astart.com

   IPP Web Page:  http://www.pwg.org/ipp/
   IPP Mailing List:  ipp@pwg.org

   To subscribe to the ipp mailing list, send the following email:
      1) send it to majordomo@pwg.org
      2) leave the subject line blank
      3) put the following two lines in the message body:
            subscribe ipp
            end

   Implementers of this specification document are encouraged to join
   IPP Mailing List in order to participate in any discussions of
   clarification issues and review of registration proposals for
   additional attributes and values.

   Other Participants:

   Chuck Adams - Tektronix             Shivaun Albright - HP
   Stefan Andersson - Axis             Jeff Barnett - IBM
   Ron Bergman - Hitachi Koki Imaging  Dennis Carney - IBM
   Systems
   Keith Carter - IBM                  Angelo Caruso - Xerox
   Rajesh Chawla - TR Computing        Nancy Chen - Okidata
   Solutions
   Josh Cohen - Microsoft              Jeff Copeland - QMS
   Andy Davidson - Tektronix           Roger deBry - IBM
   Maulik Desai - Auco                 Mabry Dozier - QMS
   Lee Farrell - Canon Information     Satoshi Fujitami - Ricoh
   Systems
   Steve Gebert - IBM                  Sue Gleeson - Digital
   Charles Gordon - Osicom             Brian Grimshaw - Apple
   Jerry Hadsell - IBM                 Richard Hart - Digital
   Tom Hastings - Xerox                Henrik Holst - I-data
   Stephen Holmstead                   Zhi-Hong Huang - Zenographics
   Scott Isaacson - Novell             Babek Jahromi - Microsoft
   Swen Johnson - Xerox                David Kellerman - Northlake
                                       Software
   Robert Kline - TrueSpectra          Charles Kong - Panasonic
   Carl Kugler - IBM                   Dave Kuntz - Hewlett-Packard

   Takami Kurono - Brother             Rick Landau - Digital
   Scott Lawrence - Agranot Systems    Greg LeClair - Epson
   Dwight Lewis - Lexmark              Harry Lewis - IBM
   Tony Liao - Vivid Image             Roy Lomicka - Digital
   Pete Loya - HP                      Ray Lutz - Cognisys
   Mike MacKay - Novell, Inc.          David Manchala - Xerox
   Carl-Uno Manros - Xerox             Jay Martin - Underscore
   Stan McConnell - Xerox              Larry Masinter - Xerox
   Sandra Matts - Hewlett Packard      Peter Michalek - Shinesoft
   Ira McDonald - High North Inc.      Mike Moldovan - G3 Nova
   Tetsuya Morita - Ricoh              Yuichi Niwa - Ricoh
   Pat Nogay - IBM                     Ron Norton - Printronics
   Hugo Parra, Novell                  Bob Pentecost - Hewlett-Packard
   Patrick Powell - Astart             Jeff Rackowitz - Intermec
   Technologies
   Eric Random - Peerless              Rob Rhoads - Intel
   Xavier Riley - Xerox                Gary Roberts - Ricoh
   David Roach - Unisys                Stuart Rowley - Kyocera
   Yuji Sasaki - Japan Computer        Richard Schneider - Epson
   Industry
   Kris Schoff - HP                    Katsuaki Sekiguchi - Canon
   Bob Setterbo - Adobe                Gail Songer - Peerless
   Hideki Tanaka - Cannon              Devon Taylor - Novell
   Mike Timperman - Lexmark            Atsushi Uchino - Epson
   Shigeru Ueda - Canon                Bob Von Andel - Allegro Software
   William Wagner - NetSilicon/DPI     Jim Walker - DAZEL
   Chris Wellens - Interworking Labs   Trevor Wells - Hewlett Packard
   Craig Whittle - Sharp Labs          Rob Whittle - Novell, Inc.
   Jasper Wong - Xionics               Don Wright - Lexmark
   Michael Wu - Heidelberg Digital     Rick Yardumian - Xerox
   Michael Yeung - Toshiba             Lloyd Young - Lexmark
   Atsushi Yuki - Kyocera              Peter Zehler - Xerox
   William Zhang- Canon Information    Frank Zhao - Panasonic
   Systems
   Steve Zilles - Adobe                Rob Zirnstein - Canon Information
                                       Systems

11. Formats for IPP Registration Proposals

   In order to propose an IPP extension for registration, the proposer
   must submit an application to IANA by email to "iana@iana.org" or by
   filling out the appropriate form on the IANA web pages
   (http://www.iana.org).  This section specifies the required
   information and the formats for proposing registrations of extensions
   to IPP as provided in Section 6 for:

      1. type2 'keyword' attribute values
      2. type3 'keyword' attribute values
      3. type2 'enum' attribute values
      4. type3 'enum' attribute values
      5. attributes
      6. attribute syntaxes
      7. operations
      8. status codes
      9. out-of-band attribute values

11.1 Type2 keyword attribute values registration,

   Type of registration:  type2 keyword attribute value
   Name of attribute to which this keyword specification is to be added:
   Proposed keyword name of this keyword value:
   Specification of this keyword value (follow the style of IPP Model
   Section 4.1.2.3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type2 keywords, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.2 Type3 keyword attribute values registration

   Type of registration:  type3 keyword attribute value
   Name of attribute to which this keyword specification is to be added:
   Proposed keyword name of this keyword value:
   Specification of this keyword value (follow the style of IPP Model
   Section 4.1.2.3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type3 keywords, the proposer will be the point of contact
   for the approved registration specification, if any maintenance of
   the registration specification is needed.

11.3 Type2 enum attribute values registration

   Type of registration:  type2 enum attribute value
   Name of attribute to which this enum specification is to be added:
   Keyword symbolic name of this enum value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):

   Specification of this enum value (follow the style of IPP Model
   Section 4.1.4):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type2 enums, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.4 Type3 enum attribute values registration

   Type of registration:  type3 enum attribute value
   Name of attribute to which this enum specification is to be added:
   Keyword symbolic name of this enum value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Specification of this enum value (follow the style of IPP Model
   Section 4.1.4):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type3 enums, the proposer will be the point of contact for
   the approved registration specification, if any maintenance of the
   registration specification is needed.

11.5 Attribute registration

   Type of registration:  attribute
   Proposed keyword name of this attribute:
   Types of attribute (Operation, Job Template, Job Description, Printer
   Description):
   Operations to be used with if the attribute is an operation attribute:
   Object (Job, Printer, etc. if bound to an object):
   Attribute syntax(es) (include 1setOf and range as in Section 4.2):
   If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
   If this is a Printer attribute, MAY the value returned depend on
   "document-format" (See Section 6.2):
   If this is a Job Template attribute, how does its specification depend
   on the value of the "multiple-document-handling" attribute:
   Specification of this attribute (follow the style of IPP Model Section
   4.2):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For attributes, the IPP Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.6 Attribute Syntax registration

   Type of registration:  attribute syntax
   Proposed name of this attribute syntax:
   Type of attribute syntax (integer, octetString, character-string,  see
   [RFC2910]):
   Numeric tag according to [RFC2910] (to be assigned by the IPP
   Designated Expert in consultation with IANA):
   Specification of this attribute (follow the style of IPP Model Section
   4.1):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For attribute syntaxes, the IPP Designated Expert will be the
   point of contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.7 Operation registration

   Type of registration:  operation
   Proposed name of this operation:
   Numeric operation-id value according to section 4.4.15 (to be assigned
   by the IPP Designated Expert in consultation with IANA):
   Object Target (Job, Printer, etc. that operation is upon):
   Specification of this operation (follow the style of IPP Model Section
   3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For operations, the IPP Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.8 Attribute Group registration

   Type of registration:  attribute group
   Proposed name of this attribute group:
   Numeric tag according to [RFC2910] (to be assigned by the IPP
   Designated Expert in consultation with IANA):
   Operation requests and group number for each operation in which the
   attribute group occurs:

   Operation responses and group number for each operation in which the
   attribute group occurs:
   Specification of this attribute group (follow the style of IPP Model
   Section 3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For attribute groups, the IPP Designated Expert will be the
   point of contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.9 Status code registration

   Type of registration:  status code
   Keyword symbolic name of this status code value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Operations that this status code may be used with:
   Specification of this status code (follow the style of IPP Model
   Section 13 APPENDIX B:  Status Codes and Suggested Status Code
   Messages):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For status codes, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.10 Out-of-band Attribute Value registration

   Type of registration:  out-of-band attribute value
   Proposed name of this out-of-band attribute value:
   Numeric tag according to [RFC2910] (to be assigned by the IPP Designated
   Expert in consultation with IANA):
   Operations that this out-of-band attribute value may be used with:
   Attributes that this out-of-band attribute value may be used with:
   Specification of this out-of-band attribute value (follow the style of
   the beginning of IPP Model Section 4.1):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For out-of-band attribute values, the IPP Designated Expert
   will be the point of contact for the approved registration
   specification, if any maintenance of the registration specification
   is needed.