rfc2566.txt

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

   other data associated with each operation.

   The IPP/1.0 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)

   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)

   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.





deBry, et al.                 Experimental                     [Page 19]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   The encoding and transport document [RFC2565] 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.13).  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



deBry, et al.                 Experimental                     [Page 20]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


       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 section 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.  Section 15 gives 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.

   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.

   Each attribute specification includes the attribute's name followed
   by the name of its attribute syntax(es) in parenthesizes.  In
   addition, each 'integer' attribute is followed by the allowed range
   in parentheses, (m:n), for values of that attribute.  Each 'text' or
   'name' attribute is followed by the maximum size in octets in
   parentheses, (size), for values of that attribute. For more details
   on attribute syntax notation, see the descriptions of these
   attributes syntaxes in section 4.1.



deBry, et al.                 Experimental                     [Page 21]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   Note: Document data included in the operation is not strictly an
   attribute, but it is treated as a special attribute group for
   ordering purposes.  The only operations that support supplying the
   document data within an operation request are Print-Job and Send-
   Document.  There are no operation responses that include document
   data.

   Note: Some operations are REQUIRED for IPP objects to support; the
   others are OPTIONAL (see section 5.2.2).  Therefore, before using an
   OPTIONAL operation, a client SHOULD first use the REQUIRED Get-
   Printer-Attributes operation to query the Printer's "operations-
   supported" attribute in order to determine which OPTIONAL Printer and
   Job operations are actually supported.  The client SHOULD NOT use an
   OPTIONAL operation that is not supported.  When an IPP object
   receives a request to perform an operation it does not support, it
   returns the 'server-error-operation-not-supported' status code (see
   section 13.1.5.2).  An IPP object is non-conformant if it does not
   support a REQUIRED operation.

3.1.4 Character Set and Natural Language Operation Attributes

   Some Job and Printer attributes have values that are text strings and
   names intended for human understanding rather than machine
   understanding (see the 'text' and 'name' attribute syntax
   descriptions in section 4.1).  The following sections describe two
   special Operation Attributes called "attributes-charset" and
   "attributes-natural-language".  These attributes are always part of
   the Operation Attributes group.  For most attribute groups, the order
   of the attributes within the group is not important.  However, for
   these two attributes within the Operation Attributes group, the order
   is critical.  The "attributes-charset" attribute MUST be the first
   attribute in the group and the "attributes-natural-language"
   attribute MUST be the second attribute in the group.  In other words,
   these attributes MUST be supplied in every IPP request and response,
   they MUST come first in the group, and MUST come in the specified
   order.  For job creation operations, the IPP Printer implementation
   saves these two attributes with the new Job object as Job Description
   attributes.  For the sake of brevity in this document, these
   operation attribute descriptions are not repeated with every
   operation request and response, but have a reference back to this
   section instead.

3.1.4.1 Request Operation Attributes

   The client MUST supply and the Printer object MUST support the
   following REQUIRED operation attributes in every IPP/1.0 operation
   request:




deBry, et al.                 Experimental                     [Page 22]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


     "attributes-charset" (charset):
        This operation attribute identifies the charset (coded character
        set and encoding method) used by any 'text' and 'name'
        attributes that the client is supplying in this request.  It
        also identifies the charset that the Printer object MUST use (if
        supported) for all 'text' and 'name' attributes and status
        messages that the Printer object returns in the response to this
        request. See Sections 4.1.1 and 4.1.2 for the specification of
        the 'text' and 'name' attribute syntaxes.

        All clients and IPP objects MUST support the 'utf-8' charset
        [RFC2279] and MAY support additional charsets provided that they
        are registered with IANA [IANA-CS].  If the Printer object does
        not support the client supplied charset value, the Printer
        object MUST reject the request, set the "attributes-charset" to
        'utf-8' in the response, and return the 'client-error-charset-
        not-supported' status code and any 'text' or 'name' attributes
        using the 'utf-8' charset.  The Printer object MUST indicate the
        charset(s) supported as the values of the "charset-supported"
        Printer attribute (see Section 4.4.15), so that the client can
        query to determine which charset(s) are supported.

        Note to client implementers: Since IPP objects are only required
        to support the 'utf-8' charset, in order to maximize
        interoperability with multiple IPP object implementations, a
        client may want to supply 'utf-8' in the "attributes-charset"
        operation attribute, even though the client is only passing and
        able to present a simpler charset, such as US-ASCII or ISO-
        8859-1.  Then the client will have to filter out (or charset
        convert) those characters that are returned in the response that
        it cannot present to its user.  On the other hand, if both the