Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2911

Internet Printing Protocol/1.1: Model and Semantics

Pages: 224
Obsoletes:  2566
Obsoleted by:  8011
Updated by:  33803382399639957472
Part 7 of 9 – Pages 148 to 172
First   Prev   Next

ToP   noToC   RFC2911 - Page 148   prevText

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
ToP   noToC   RFC2911 - Page 149
      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].
ToP   noToC   RFC2911 - Page 150
         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.
ToP   noToC   RFC2911 - Page 151
   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.
ToP   noToC   RFC2911 - Page 152
   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:
ToP   noToC   RFC2911 - Page 153
      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
ToP   noToC   RFC2911 - Page 154
   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
ToP   noToC   RFC2911 - Page 155
      - 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
ToP   noToC   RFC2911 - Page 156
   '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
ToP   noToC   RFC2911 - Page 157
         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
ToP   noToC   RFC2911 - Page 158
        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.
ToP   noToC   RFC2911 - Page 159
   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.
ToP   noToC   RFC2911 - Page 160

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".
ToP   noToC   RFC2911 - Page 161
   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
ToP   noToC   RFC2911 - Page 162
   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
ToP   noToC   RFC2911 - Page 163
   [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.
ToP   noToC   RFC2911 - Page 164
   [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.
ToP   noToC   RFC2911 - Page 165
   [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.
ToP   noToC   RFC2911 - Page 166
   [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
ToP   noToC   RFC2911 - Page 167
   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
ToP   noToC   RFC2911 - Page 168
   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:
ToP   noToC   RFC2911 - Page 169
      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):
ToP   noToC   RFC2911 - Page 170
   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:
ToP   noToC   RFC2911 - Page 171
   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:
ToP   noToC   RFC2911 - Page 172
   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.


(next page on part 8)

Next Section