rfc2639.txt

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


RFC 2639              IPP/1.0: Implementer's Guide             July 1999


                           Printer Operations

                         Requests                        Responses

      Operation          Print-   Pri  Crea Get-    Get-  All
      Attributes         Job,     nt-  te-  Printer Jobs  Opera-
                         Vali-    URI  Job  Attri-        tions
                         date-Job (O)  (O)  butes

      Operation attributes-OPTIONAL to be supplied by the sender

      status-message                                         O

      compression           O     O

      document-format       R     R           O

      document-name         O     O

      document-natural-     O     O
      language

      ipp-attribute-        R     R    R
      fidelity

      job-impressions       O     O    O

      job-k-octets          O     O    O

      job-media-sheets      O     O    O

      limit                                           R

      message

      my-jobs                                         R

      requested-                               R      R
      attributes

      which-jobs                                      R

      *  "job-id" is REQUIRED only if used together with
      "printer-uri" to identify the target job; otherwise, "job-
      uri" is REQUIRED.






Hastings & Manros            Informational                      [Page 7]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999


      Table 2.  Summary of operation attributes for Job operations


                         Requests                         Responses

      Operation          Send-    Send-  Cancel  Get-     All
      Attributes         Document URI    -Job    Job-     Opera-
                         (O)      (O)            Attri-   tions
                                                 butes

      Operation parameters--REQUIRED to be supplied by the sender

      operation-id          R       R      R       R

      status-code                                          R

      request-id            R       R      R       R       R

      version-number        R       R      R       R       R

      Operation attributes-REQUIRED to be supplied by the sender

      attributes-           R       R      R       R       R
      charset

      attributes-           R       R      R       R       R
      natural-language

      document-uri                   R

      job-id*               R       R      R       R

      job-uri*              R       R      R       R

      last-document         R       R

      printer-uri           R       R      R       R

      Operation attributes-RECOMMENDED to be supplied by the
      sender

      job-name

      requesting-user-      R       R      R       R
      name






Hastings & Manros            Informational                      [Page 8]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999


                             Job Operations

                           Requests                      Responses

     Operation Attributes  Send-    Send-   Cance Get-    All
                           Document URI     l-Job Job-    Opera-
                           (O)      (O)           Attri-  tions
                                                  butes

     Operation attributes.OPTIONAL to be supplied by the sender

     status-message                                       O

     compression               O       O

     document-format           R       R

     document-name             O       O

     document-natural-         O       O
     language

     ipp-attribute-
     fidelity

     job-impressions

     job-k-octets

     job-media-sheets

     limit

     message                                   O

     my-jobs

     requested-attributes                             R

     which-jobs

     *  "job-id" is REQUIRED only if used together with "printer-
     uri" to identify the target job; otherwise, "job-uri" is
     REQUIRED.







Hastings & Manros            Informational                      [Page 9]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999


2.2 Suggested Operation Processing Steps for IPP Objects

   This section suggests the steps and error checks that an IPP object
   MAY perform when processing requests and returning responses.  An IPP
   object MAY perform some or all of the error checks.  However, some
   implementations MAY choose to be more forgiving than the error checks
   shown here, in order to be able to accept requests from non-
   conforming clients.  Not performing all of these error checks is a
   so-called "forgiving" implementation.  On the other hand, clients
   that successfully submit requests to IPP objects that do perform all
   the error checks will be more likely to be able to interoperate with
   other IPP object implementations.  Thus an implementer of an IPP
   object needs to decide whether to be a "forgiving" or a "strict"
   implementation.  Therefore, the error status codes returned may
   differ between implementations.   Consequentially, client SHOULD NOT
   expect exactly the error code processing described in this section.

   When an IPP object receives a request, the IPP object either accepts
   or rejects the request. In order to determine whether or not to
   accept or reject the request, the IPP object SHOULD execute the
   following steps.  The order of the steps may be rearranged and/or
   combined, including making one or multiple passes over the request.

   A client MUST supply requests that would pass all of the error checks
   indicated here in order to be a conforming client.  Therefore, a
   client SHOULD supply requests that are conforming, in order to avoid
   being rejected by some IPP object implementations and/or risking
   different semantics by different implementations of forgiving
   implementations.  For example, a forgiving implementation that
   accepts multiple occurrences of the same attribute, rather than
   rejecting the request might use the first occurrences, while another
   might use the last occurrence.  Thus such a non-conforming client
   would get different results from the two forgiving implementations.

   In the following, processing continues step by step until a "RETURNS
   the xxx status code ." statement is encountered.  Error returns are
   indicated by the verb: "REJECTS".  Since clients have difficulty
   getting the status code before sending all of the document data in a
   Print-Job request, clients SHOULD use the Validate-Job operation
   before sending large documents to be printed, in order to validate
   whether the IPP Printer will accept the job or not.

   It is assumed that security authentication and authorization has
   already taken place at a lower layer.







Hastings & Manros            Informational                     [Page 10]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999


2.2.1 Suggested Operation Processing Steps for all Operations

   This section is intended to apply to all operations.  The next
   section contains the additional steps for the Print-Job, Validate-
   Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
   that create jobs, adds documents, and validates jobs.

2.2.1.1   Validate version number

   Every request and every response contains the "version-number"
   attribute.  The value of this attribute is the major and minor
   version number of the syntax and semantics that the client and IPP
   object is using, respectively.  The "version-number" attribute
   remains in a fixed position across all future versions so that all
   clients and IPP object that support future versions can determine
   which version is being used.  The IPP object checks to see if the
   major version number supplied in the request is supported.  If not,
   the Printer object REJECTS the request and RETURNS the 'server-
   error-version-not-supported' status code in the response.  The IPP
   object returns in the "version-number" response attribute the major
   and minor version for the error response.  Thus the client can learn
   at least one major and minor version that the IPP object supports.
   The IPP object is encouraged to return the closest version number to
   the one supplied by the client.

   The checking of the minor version number is implementation dependent,
   however if the client supplied minor version is explicitly supported,
   the IPP object MUST respond using that identical minor version
   number.  If the requested minor version is not supported (the
   requested minor version is either higher or lower) than a supported
   minor version, the IPP object SHOULD return the closest supported
   minor version.

2.2.1.2   Validate operation identifier

   The Printer object checks to see if the "operation-id" attribute
   supplied by the client is supported as indicated in the Printer
   object's "operations-supported" attribute.  If not, the Printer
   REJECTS the request and returns the 'server-error-operation-not-
   supported' status code in the response.

2.2.1.3   Validate the request identifier

   The Printer object SHOULD NOT check to see if the "request-id"
   attribute supplied by the client is in range: between 1 and 2**31 - 1
   (inclusive), but copies all 32 bits.





Hastings & Manros            Informational                     [Page 11]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999


   Note: The "version-number",  "operation-id", and the "request-id"
   parameters are in fixed octet positions in the IPP/1.0 encoding.  The
   "version-number" parameter will be the same fixed octet position in
   all versions of the protocol.  These fields are validated before
   proceeding with the rest of the validation.

2.2.1.4   Validate attribute group and attribute presence and order

   The order of the following validation steps depends on
   implementation.

2.2.1.4.1 Validate the presence and order of attribute groups

   Client requests and IPP object responses contain attribute groups
   that Section 3 requires to be present and in a specified order.  An
   IPP object verifies that the attribute groups are present and in the
   correct order in requests supplied by clients (attribute groups
   without an * in the following tables).

   If an IPP object receives a request with (1) required attribute
   groups missing, or (2) the attributes groups are out of order, or (3)
   the groups are repeated, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' status code.  For example, it
   is an error for the Job Template Attributes group to occur before the
   Operation Attributes group, for the Operation Attributes group to be
   omitted, or for an attribute group to occur more than once, except in
   the Get-Jobs response.

   Since this kind of attribute group error is most likely to be an
   error detected by a client developer rather than by a customer, the
   IPP object NEED NOT return an indication of which attribute group was
   in error in either the Unsupported Attributes group or the Status
   Message.  Also, the IPP object NEED NOT find all attribute group
   errors before returning this error.

2.2.1.4.2 Ignore unknown attribute groups in the expected position

   Future attribute groups may be added to the specification at the end
   of requests just before the Document Content and at the end of
   response, except for the Get-Jobs response, where it maybe there or
   before the first job attributes returned.  If an IPP object receives
   an unknown attribute group in these positions, it ignores the entire
   group, rather than returning an error, since that group may be a new
   group in a later minor version of the protocol that can be ignored.
   (If the new attribute group cannot be ignored without confusing the
   client, the major version number would have been increased in the





Hastings & Manros            Informational                     [Page 12]

RFC 2639              IPP/1.0: Implementer's Guide             July 1999