rfc2639.txt

RFC 的详细文档！

      IF NOT in the Printer object's "compression-supported" attribute,
         copy the attribute and the unsupported value to the Unsupported
         Attributes response group and REJECT/RETURN 'client-error-
         attributes-or-values-not-supported'.


   job-k-octets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.
      IF NOT in the range of the Printer object's "job-k-octets-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   job-impressions (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.




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


      IF NOT in the range of the Printer object's "job-impressions-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   job-media-sheets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.
      IF NOT in the range of the Printer object's "job-media-sheets-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   message (text(127))

      IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 127 octets,
      REJECT/RETURN 'client-error-request-value-too-long'.


   unknown or unsupported attribute

      IF the attribute syntax supplied by the client is supported but
         the length is not legal for that attribute syntax,
         REJECT/RETURN 'client-error-request-value-too-long'.
      ELSE copy the attribute and value to the Unsupported Attributes
         response group and change the attribute value to the "out-of-
         band" 'unsupported' value, but otherwise ignore the attribute.

      Note: Future Operation attributes may be added to the protocol
      specification that may occur anywhere in the specified group.
      When the operation is otherwise successful, the IPP object returns
      the 'successful-ok-ignored-or-substituted-attributes' status code.
      Ignoring unsupported Operation attributes in all operations is
      analogous to the handling of unsupported Job Template attributes
      in the create and Validate-Job operations when the client supplies
      the "ipp-attribute-fidelity" Operation attribute with the 'false'
      value.  This last rule is so that we can add OPTIONAL Operation
      attributes to future versions of IPP so that older clients can
      inter-work with new IPP objects and newer clients can inter-work
      with older IPP objects.  (If the new attribute cannot be ignored
      without performing unexpectedly, the major version number would



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


      have been increased in the protocol document and in the request).
      This rule for Operation attributes is independent of the value of
      the "ipp-attribute-fidelity" attribute.   For example, if an IPP
      object doesn't support the OPTIONAL "job-k-octets" attribute', the
      IPP object treats "job-k-octets" as an unknown attribute and only
      checks the length for the 'integer' attribute syntax supplied by
      the client.  If it is not four octets, the IPP object REJECTS the
      request and RETURNS the 'client-error-bad-request' status code,
      else the IPP object copies the attribute to the Unsupported
      Attribute response group, setting the value to the "out-of-band" '
      unsupported' value, but otherwise ignores the attribute.

2.2.2 Suggested Additional Processing Steps for Operations that
      Create/Validate Jobs and Add Documents

   This section in combination with the previous section recommends the
   processing steps for the Print-Job, Validate-Job, Print-URI, Create-
   Job, Send-Document, and Send-URI operations that IPP objects SHOULD
   use.  These are the operations that create jobs, validate a Print-Job
   request, and add documents to a job.

2.2.2.1   Default "ipp-attribute-fidelity" if not supplied

   The Printer object checks to see if the client supplied an "ipp-
   attribute-fidelity" Operation attribute.  If the attribute is not
   supplied by the client, the IPP object assumes that the value is
   'false'.

2.2.2.2   Check that the Printer object is accepting jobs

   If the value of the Printer object's "printer-is-accepting-jobs" is
   'false', the Printer object REJECTS the request and RETURNS the
   'server-error-not-accepting-jobs' status code.

2.2.2.3   Validate the values of the Job Template attributes

   An IPP object validates the values of all Job Template attribute
   supplied by the client.  The IPP object performs the analogous
   syntactic validation checks of each Job Template attribute value that
   it performs for Operation attributes (see Section 2.2.1.5.):

      a)that the length of each value is correct for the attribute
        syntax tag supplied by the client according to [RFC2566] Section
        4.1.

      b)that the attribute syntax tag is correct for that attribute
        according to [RFC2566] Sections 4.2 to 4.4.




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


      c)that multiple values are supplied only for multi-valued
        attributes, i.e., that are 1setOf  X according to [RFC2566]
        Sections 4.2 to 4.4.

   As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP
   object REJECTS the request and RETURNS the 'client-error-bad-request'
   or 'client-error-request-value-too-long' status code as appropriate,
   independent of the value of the "ipp-attribute-fidelity".  Since such
   an error is most likely to be an error detected by a client
   developer, rather than by an end-user, the IPP object NEED NOT return
   an indication of which attribute had the error in either the
   Unsupported Attributes Group or the Status Message.  The description
   for each of these syntactic checks is explicitly expressed in the
   first IF statement in the following table.

   Each Job Template attribute MUST occur no more than once.  If an IPP
   Printer receives a create request with multiple occurrences of a Job
   Template attribute, it MAY:

      1.reject the operation and return the 'client-error-bad syntax'
        error status code

      2.accept the operation and use the first occurrence of the
        attribute

      3.accept the operation and use the last occurrence of the
        attribute

   depending on implementation.  Therefore, clients MUST NOT supply
   multiple occurrences of the same Job Template attribute in the Job
   Attributes group in the request.

2.2.3 Algorithm for job validation

   The process of validating a Job-Template attribute "xxx" against a
   Printer attribute "xxx-supported" can use the following validation
   algorithm (see section 3.2.1.2 in [RFC2566]).

   To validate the value U of Job-Template attribute "xxx" against the
   value V of Printer "xxx-supported", perform the following algorithm:

      1.If U is multi-valued, validate each value X of U by performing
        the algorithm in Table 3 with each value X. Each validation is
        separate from the standpoint of returning unsupported values.

        Example: If U is "finishings" that the client supplies with
        'staple', 'bind' values, then X takes on the successive values:
        'staple', then 'bind'



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


      2.If V is multi-valued, validate X against each Z of V by
        performing the algorithm in Table 3 with each value Z.  If a
        value Z validates, the validation for the attribute value X
        succeeds. If it fails, the algorithm is applied to the next
        value Z of V. If there are no more values Z of V, validation
        fails.

        Example: If V is "sides-supported" with values: 'one-sided',
        'two-sided-long', and 'two-sided-short', then Z takes on the
        successive values: 'one-sided', 'two-sided-long', and
        'two-sided-short'.  If the client supplies "sides" with 'two-
        sided-long', the first comparison fails ('one-sided' is not
        equal to 'two-sided-long'), the second comparison succeeds
        ('two-sided-long' is equal to 'two-sided-long"), and the third
        comparison ('two-sided-short' with 'two-sided-long') is not even
        performed.

      3.If both U and V are single-valued, let X be U and Z be V and use
        the validation rules in Table 3.

            Table 3 - Rules for validating single values X against Z

     attribute    attribute       validated if:
     syntax of X  syntax of Z

     integer      rangeOfInteger  X is within the range of
                                   Z

     uri          uriScheme       the uri scheme in X is
                                   equal to Z

     any          boolean         the value of Z is TRUE

     any          any             X and Z are of the same
                                   type and are equal.

   If the value of the Printer object's "xxx-supported" attribute is '
   no-value' (because the system administrator hasn't configured a
   value), the check always fails.  If the check fails, the IPP object
   copies the attribute to the Unsupported Attributes response group
   with its unsupported value.  If the attribute contains more than one
   value, each value is checked and each unsupported value is separately
   copied, while supported values are not copied.  If an IPP object
   doesn't recognize/support a Job Template attribute, i.e., there is no
   corresponding Printer object "xxx-supported" attribute, the IPP
   object treats the attribute as an unknown or unsupported attribute
   (see the last row in the table below).




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


   If some Job Template attributes are supported for some document
   formats and not for others or the values are different for different
   document formats, the IPP object SHOULD take that into account in
   this validation using the value of the "document-format" supplied by
   the client (or defaulted to the value of the Printer's "document-
   format-default" attribute, if not supplied by the client).  For
   example, if "number-up" is supported for the 'text/plain' document
   format, but not for the 'application/postscript' document format, the
   check SHOULD (though it NEED NOT) depend on the value of the
   "document-format" operation attribute.  See "document-format" in
   [RFC2566] section 3.2.1.1 and 3.2.5.1.

   Note: whether the request is accepted or rejected is determined by
   the value of the "ipp-attribute-fidelity" attribute in a subsequent
   step, so that all Job Template attribute supplied are examined and
   all unsupported attributes and/or values are copied to the
   Unsupported Attributes response group.

   job-priority (integer(1:100))

      IF NOT a single 'integer' value with a length equal to 4 octets,
         REJECT/RETURN 'client-error-bad-request'.
      IF NOT supplied by the client, use the value of the Printer
         object's "job-priority-default" attribute at job submission
         time.
      IF NOT in the range 1 to 100, inclusive, copy the attribute and
         the unsupported value to the Unsupported Attributes response
         group.
      Map the value to the nearest supported value in the range 1:100 as
         specified by the number of discrete values indicated by the
         value of the Printer's "job-priority-supported" attribute.  See
         the formula in [RFC2566] Section 4.2.1.

   job-hold-until (type3 keyword | name)

      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
         error-bad-request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NOT supplied by the client, use the value of the Printer
         object's "job-hold-until" attribute at job submission time.
      IF NOT in the Printer object's "job-hold-until-supported"
         attribute, copy the attribute and the unsupported value to the
         Unsupported Attributes response group.







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


   job-sheets (type3 keyword | name)

      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
         error-bad-request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NOT in the Printer object's "job-sheets-supported" attribute,
         copy the attribute and the unsupported value to the Unsupported
         Attributes response group.

   multiple-document-handling (type2 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NOT in the P