rfc2911.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   In addition to identifiers, Printer objects and Job objects have
   names ("printer-name" and "job-name").  An object name NEED NOT be
   unique across all instances of all objects. A Printer object's name
   is chosen and set by an administrator through some mechanism outside
   the scope of this IPP/1.1 document.  A Job object's name is
   optionally chosen and supplied by the IPP client submitting the job.
   If the client does not supply a Job object name, the Printer object
   generates a name for the new Job object.  In all cases, the name only
   has local meaning.

   To summarize:

      - Each Printer object is identified with one or more URIs.  The
        Printer's "printer-uri-supported" attribute contains the URI(s).
      - The Printer object's "uri-security-supported" attribute
        identifies the communication channel security protocols that may
        or may not have been configured for the various Printer object
        URIs (e.g., 'tls' or 'none').
      - The Printer object's "uri-authentication-supported" attribute
        identifies the authentication mechanisms that may or may not
        have been configured for the various Printer object URIs (e.g.,
        'digest' or 'none').
      - Each Job object is identified with a Job URI.  The Job's "job-
        uri" attribute contains the URI.
      - Each Job object is also identified with Job ID which is a 32-
        bit, positive integer.  The Job's "job-id" attribute contains
        the Job ID.  The Job ID is only unique within the context of the
        Printer object  which created the Job object.





Hastings, et al.            Standards Track                    [Page 19]

RFC 2911              IPP/1.1: Model and Semantics        September 2000


      - Each Job object has a "job-printer-uri" attribute which contains
        the URI of the Printer object that was used to create the Job
        object.  This attribute is used to determine the Printer object
        that created a Job object when given only the URI for the Job
        object.  This linkage is necessary to determine the languages,
        charsets, and operations which are supported on that Job (the
        basis for such support comes from the creating Printer object).
      - Each Printer object has a name (which is not necessarily
        unique).  The administrator chooses and sets this name through
        some mechanism outside the scope of this IPP/1.1 document.  The
        Printer object's "printer-name" attribute contains the name.
      - Each Job object has a name (which is not necessarily unique).
        The client optionally supplies this name in the create request.
        If the client does not supply this name, the Printer object
        generates a name for the Job object. The Job object's "job-name"
        attribute contains the name.

3. IPP Operations

   IPP objects support operations.  An operation consists of a request
   and a response.  When a client communicates with an IPP object, the
   client issues an operation request to the URI for that object.
   Operation requests and responses have parameters that identify the
   operation.  Operations also have attributes that affect the run-time
   characteristics of the operation (the intended target, localization
   information, etc.).  These operation-specific attributes are called
   operation attributes (as compared to object attributes such as
   Printer object attributes or Job object attributes).  Each request
   carries along with it any operation attributes, object attributes,
   and/or document data required to perform the operation.  Each request
   requires a response from the object.  Each response indicates success
   or failure of the operation with a status code as a response
   parameter.  The response contains any operation attributes, object
   attributes, and/or status messages generated during the execution of
   the operation request.

   This section describes the semantics of the IPP operations, both
   requests and responses, in terms of the parameters, attributes, and
   other data associated with each operation.












Hastings, et al.            Standards Track                    [Page 20]

RFC 2911              IPP/1.1: Model and Semantics        September 2000


   The IPP/1.1 Printer operations are:

     Print-Job (section 3.2.1)
     Print-URI (section 3.2.2)
     Validate-Job (section 3.2.3)
     Create-Job (section 3.2.4)
     Get-Printer-Attributes (section 3.2.5)
     Get-Jobs (section 3.2.6)
     Pause-Printer (section 3.3.5)
     Resume-Printer (section 3.3.6)
     Purge-Jobs (section 3.3.7)

   The Job operations are:

     Send-Document (section 3.3.1)
     Send-URI (section 3.3.2)
     Cancel-Job (section 3.3.3)
     Get-Job-Attributes (section 3.3.4)
     Hold-Job (section 3.3.5)
     Release-Job (section 3.3.6)
     Restart-Job (section 3.3.7)

   The Send-Document and Send-URI Job operations are used to add a new
   document to an existing multi-document Job object created using the
   Create-Job operation.

3.1 Common Semantics

   All IPP operations require some common parameters and operation
   attributes.  These common elements and their semantic characteristics
   are defined and described in more detail in the following sections.

3.1.1 Required Parameters

   Every operation request contains the following REQUIRED parameters:

      - a "version-number",
      - an "operation-id",
      - a "request-id", and
      - the attributes that are REQUIRED for that type of request.

   Every operation response contains the following REQUIRED parameters:

      - a "version-number",
      - a "status-code",
      - the "request-id" that was supplied in the corresponding request,
        and
      - the attributes that are REQUIRED for that type of response.



Hastings, et al.            Standards Track                    [Page 21]

RFC 2911              IPP/1.1: Model and Semantics        September 2000


   The "Encoding and Transport" document [RFC2910] defines special rules
   for the encoding of these parameters.  All other operation elements
   are represented using the more generic encoding rules for attributes
   and groups of attributes.

3.1.2 Operation IDs and Request IDs

   Each IPP operation request includes an identifying "operation-id"
   value.  Valid values are defined in the "operations-supported"
   Printer attribute section (see section 4.4.15).  The client specifies
   which operation is being requested by supplying the correct
   "operation-id" value.

   In addition, every invocation of an operation is identified by a
   "request-id" value. For each request, the client chooses the
   "request-id" which MUST be an integer (possibly unique depending on
   client requirements) in the range from 1 to 2**31 - 1 (inclusive).
   This "request-id" allows clients to manage multiple outstanding
   requests. The receiving IPP object copies all 32-bits of the client-
   supplied "request-id" attribute into the response so that the client
   can match the response with the correct outstanding request, even if
   the "request-id" is out of range.  If the request is terminated
   before the complete "request-id" is received, the IPP object rejects
   the request and returns a response with a "request-id" of 0.

   Note: In some cases, the transport protocol underneath IPP might be a
   connection oriented protocol that would make it impossible for a
   client to receive responses in any order other than the order in
   which the corresponding requests were sent.  In such cases, the
   "request-id" attribute would not be essential for correct protocol
   operation.  However, in other mappings, the operation responses can
   come back in any order.  In these cases, the "request-id" would be
   essential.

3.1.3 Attributes

   Operation requests and responses are both composed of groups of
   attributes and/or document data.  The attributes groups are:

      - Operation Attributes: These attributes are passed in the
        operation and affect the IPP object's behavior while processing
        the operation request and may affect other attributes or groups
        of attributes.  Some operation attributes describe the document
        data associated with the print job and are associated with new
        Job objects, however most operation attributes do not persist
        beyond the life of the operation.  The description of each
        operation attribute includes conformance statements indicating
        which operation attributes are REQUIRED and which are OPTIONAL



Hastings, et al.            Standards Track                    [Page 22]

RFC 2911              IPP/1.1: Model and Semantics        September 2000


        for an IPP object to support and which attributes a client MUST
        supply in a request and an IPP object MUST supply in a response.
      - Job Template Attributes: These attributes affect the processing
        of a job.  A client OPTIONALLY supplies Job Template Attributes
        in a create request, and the receiving object MUST be prepared
        to receive all supported attributes.  The Job object can later
        be queried to find out what Job Template attributes were
        originally requested in the create request, and such attributes
        are returned in the response as Job Object Attributes.  The
        Printer object can be queried about its Job Template attributes
        to find out what type of job processing capabilities are
        supported and/or what the default job processing behaviors are,
        though such attributes are returned in the response as Printer
        Object Attributes.  The "ipp-attribute-fidelity" operation
        attribute affects processing of all client-supplied Job Template
        attributes (see sections 3.2.1.2 and 15 for a full description
        of "ipp-attribute-fidelity" and its relationship to other
        attributes).
      - Job Object Attributes: These attributes are returned in response
        to a query operation directed at a Job object.
      - Printer Object Attributes: These attributes are returned in
        response to a query operation directed at a Printer object.
      - Unsupported Attributes: In a create request, the client supplies
        a set of Operation and Job Template attributes.  If any of these
        attributes or their values is unsupported by the Printer object,
        the Printer object returns the set of unsupported attributes in
        the response.  Sections 3.1.7, 3.2.1.2, and  15 give a full
        description of how Job Template attributes supplied by the
        client in a create request are processed by the Printer object
        and how unsupported attributes are returned to the client.
        Because of extensibility, any IPP object might receive a request
        that contains new or unknown attributes or values for which it
        has no support. In such cases, the IPP object processes what it
        can and returns the unsupported attributes in the response. The
        Unsupported Attribute group is defined for all operation
        responses for returning unsupported attributes that the client
        supplied in the request.

   Later in this section, each operation is formally defined by
   identifying the allowed and expected groups of attributes for each
   request and response.  The model identifies a specific order for each
   group in each request or response, but the attributes within each
   group may be in any order, unless specified otherwise.

   The attributes within a group MUST be unique; if an attribute with
   the same name occurs more than once, the group is mal-formed.
   Clients MUST NOT submit such malformed requests and Printers MUST NOT
   return such malformed responses.  If such a malformed request is



Hastings, et al.            Standards Trac