rfc2565.txt

RFC 的详细文档！

      Tag Value (Hex)  Meaning

      0x30             octetString with an  unspecified format
      0x31             dateTime
      0x32             resolution
      0x33             rangeOfInteger
      0x34             reserved for collection (in the future)
      0x35             textWithLanguage
      0x36             nameWithLanguage
      0x37-0x3F        reserved for future octetString types

   The following table specifies the character-string values for the
   value-tag:

      Tag Value (Hex)  Meaning

      0x40             reserved
      0x41             textWithoutLanguage
      0x42             nameWithoutLanguage
      0x43             reserved
      0x44             keyword
      0x45             uri
      0x46             uriScheme
      0x47             charset
      0x48             naturalLanguage






Herriot, et al.               Experimental                     [Page 12]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


      Tag Value (Hex)  Meaning

      0x49             mimeMediaType
      0x4A-0x5F        reserved for future character string types

   NOTE: 0x40 is reserved for "generic character-string" if it should
   ever be needed.

   NOTE:  an attribute value always has a type, which is explicitly
   specified by its tag; one such tag value is "nameWithoutLanguage".
   An attribute's name has an implicit type, which is keyword.

   The values 0x60-0xFF are reserved for future types. There are no
   values allocated for private extensions. A new type MUST be
   registered via the type 2 registration process [RFC2566].

   The tag 0x7F is reserved for extending types beyond the 255 values
   available with a single byte. A tag value of 0x7F MUST signify that
   the first 4 bytes of the value field are interpreted as the tag
   value.  Note, this future extension doesn't affect parsers that  are
   unaware of this special tag. The tag is like any other unknown tag,
   and the value length specifies the length of a value which contains a
   value that the parser treats atomically.  All these 4 byte tag values
   are currently unallocated except that the values 0x40000000-
   0x7FFFFFFF are reserved for experimental use.

3.8 Name-Length

   The name-length field MUST consist of a SIGNED-SHORT. This field MUST
   specify the number of octets in the name field which follows the
   name-length field, excluding the two bytes of the name-length field.

   If a name-length field has a value of zero, the following name field
   MUST be empty, and the following value MUST be treated as an
   additional value for the preceding attribute. Within an attribute-
   sequence, if two attributes have the same name, the first occurrence
   MUST be ignored. The zero-length name is the only mechanism for
   multi-valued attributes.

3.9 (Attribute) Name

   Some operation elements are called parameters in the model document
   [RFC2566]. They MUST be encoded in a special position and they MUST
   NOT appear as an operation attributes.  These parameters are:

      - "version-number": The parameter  named "version-number" in the
        IPP model document MUST become the "version-number" field in the
        operation layer request or response.



Herriot, et al.               Experimental                     [Page 13]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


      - "operation-id": The parameter named "operation-id" in the IPP
        model document MUST become the "operation-id" field in the
        operation layer request.
      - "status-code": The parameter named "status-code" in the IPP
        model document MUST become the "status-code" field in the
        operation layer response.
      - "request-id": The parameter named "request-id" in the IPP model
        document MUST become the "request-id" field in the operation
        layer request or response.

   All Printer and Job objects are identified by a Uniform Resource
   Identifier (URI) [RFC2396] so that they can be persistently and
   unambiguously referenced.  The notion of a URI is a useful concept,
   however, until the notion of URI is more stable (i.e.,  defined more
   completely and deployed more widely), it is expected that the URIs
   used for IPP objects will actually be URLs [RFC1738]  [RFC1808].
   Since every URL is a specialized form of a URI, even though the more
   generic term URI is used throughout the rest of this document, its
   usage is intended to cover the more specific notion of URL as well.

   Some operation elements are encoded twice, once as the request-URI on
   the HTTP Request-Line and a second time as a REQUIRED operation
   attribute in the application/ipp entity.  These attributes are the
   target URI for the operation:

      - "printer-uri": When the target is a printer and the transport is
        HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined
        in each operation in the IPP model document MUST be an operation
        attribute called "printer-uri" and it MUST also be specified
        outside of  the operation layer as the request-URI on the
        Request-Line at the HTTP level.
      - "job-uri": When the target is a job and the transport is HTTP or
        HTTPS (for SSL3), the target job-uri of each operation in the
        IPP model document MUST be an operation attribute called "job-
        uri" and it MUST also be specified outside of  the operation
        layer as the request-URI on the Request-Line at the HTTP level.

   Note: The target URI is included twice in an operation referencing
   the same IPP object, but the two URIs NEED NOT be literally
   identical. One can be a relative URI and the other can be an absolute
   URI.  HTTP/1.1 allows clients to generate and send a relative URI
   rather than an absolute URI.  A relative URI identifies a resource
   with the scope of the HTTP server, but does not include scheme, host
   or port.  The following statements characterize how URLs should be
   used in the mapping of IPP onto HTTP/1.1:






Herriot, et al.               Experimental                     [Page 14]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


      1. Although potentially redundant, a client MUST supply the target
         of the operation both as an operation attribute and as a URI at
         the HTTP layer.  The rationale for this decision is to maintain
         a consistent set of rules for mapping application/ipp to
         possibly many communication layers, even where URLs are not
         used as the addressing mechanism in the transport layer.
      2. Even though these two URLs might not be literally identical
         (one being relative and the other being absolute), they MUST
         both reference the same IPP object.
      3. The URI in the HTTP layer is either relative or absolute and is
         used by the HTTP server to route the HTTP request to the
         correct resource relative to that HTTP server.  The HTTP server
         need not be aware of the URI within the operation request.
      4. Once the HTTP server resource begins to process the HTTP
         request, it might get the reference to the appropriate IPP
         Printer object from either the HTTP URI (using to the context
         of the HTTP server for relative URLs) or from the URI within
         the operation request; the choice is up to the implementation.
      5. HTTP URIs can be relative or absolute, but the target URI in
         the operation MUST be an absolute URI.

   The model document arranges the remaining attributes into groups for
   each operation request and response. Each such group MUST be
   represented in the protocol by an xxx-attribute-sequence preceded by
   the appropriate xxx-attributes-tag (See the table below and section 9
   "Appendix A:  Protocol Examples"). In addition, the order of these
   xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST
   be the same as in the model document, but the order of attributes
   within each xxx-attribute-sequence MUST be unspecified. The table
   below maps the model document group name to xxx-attributes-sequence:

   Model Document Group           xxx-attributes-sequence

   Operation Attributes           operations-attributes-sequence
   Job Template Attributes        job-attributes-sequence
   Job Object Attributes          job-attributes-sequence
   Unsupported Attributes         unsupported-attributes-sequence
   Requested Attributes           job-attributes-sequence
   Get-Job-Attributes)
   Requested Attributes           printer-attributes-sequence
   Get-Printer-Attributes)
   Document Content               in a special position as described
                                  above

   If an operation contains attributes from more than one job object
   (e.g.  Get-Jobs response), the attributes from each job object MUST
   be in a separate job-attribute-sequence, such that the attributes




Herriot, et al.               Experimental                     [Page 15]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   from the ith job object are in the ith job-attribute-sequence. See
   Section 9 "Appendix A: Protocol Examples" for table showing the
   application of the rules above.

3.10 Value Length

   Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
   specify the number of octets in the value which follows this length,
   exclusive of the two bytes specifying the length.

   For any of the types represented by binary signed integers, the
   sender MUST encode the value in exactly four octets.

   For any of the types represented by character-strings, the sender
   MUST encode the value with all the characters of the string and
   without any padding characters.

   If a value-tag contains an "out-of-band" value, such as
   "unsupported", the value-length MUST be 0 and the value empty. The
   value has no meaning when the value-tag has an "out-of-band" value.
   If a client receives a response with a nonzero value-length in this
   case, it MUST ignore the value field. If a printer receives a request
   with a nonzero value-length in this case, it MUST reject the request.

3.11 (Attribute) Value

   The syntax types and most of the details of their representation are
   defined in the IPP model document. The table below augments the
   information in the model document, and defines the syntax types from
   the model document in terms of the 5 basic types defined in section 3
   "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING,
   LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and
   OCTET-STRING.

Syntax of Attribute  Encoding
Value

textWithoutLanguage, LOCALIZED-STRING.
nameWithoutLanguage

textWithLanguage     OCTET_STRING consisting of 4 fields:
                       a) a SIGNED-SHORT which is the number of octets
                          in the following field
                       b) a value of type natural-language,
                       c) a SIGNED-SHORT which is the number of octets
                          in the following field,
                       d) a value of type textWithoutLanguage.




Herriot, et al.               Experimental                     [Page 16]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


                      The length of a textWithLanguage value MUST be 4
                      + the value of field a + the value of field c.

nameWithLanguage     OCTET_STRING consisting of 4 fields:
                       a) a SIGNED-SHORT which is the number of octets
                          in the following field
                       b) a value of type natural-language,
                       c) a SIGNED-SHORT which is the number of octets
                          in the following field
                       d) a value of type nameWithoutLanguage.

                      The length of a nameWithLanguage value MUST be 4
                      + the value of field a + the value of field c.

charset,             US-ASCII-STRING.
naturalLanguage,
mimeMediaType,
keyword, uri, and
uriScheme

boolean              SIGNED-BYTE  where 0x00 is 'false' and 0x01 is
                      'true'.

Syntax of Attribute  Encoding
Value


integer and enum     a SIGNED-INTEGER.

dateTime             OCTET-STRING consisting of eleven octets whose
                      contents are defined by "DateAndTime" in RFC
                      2579 [RFC2579].

resolution           OCTET_STRING consisting of nine octets of  2
                      SIGNED-INTEGERs followed by a SIGNED-BYTE. The
                      first SIGNED-INTEGER contains the value of cross
                      feed direction resolution. The second SIGNED-
                      INTEGER contains the value of feed direction
                      resolution. The SIGNED-BYTE contains the units
                      value.

rangeOfInteger       Eight octets consisting of 2 SIGNED-INTEGERs.
                      The first SIGNED-INTEGER contains the lower
                      bound and the second SIGNED-INTEGER contains the
                      upper  bound.






Herriot, et al.               Experimental                     [Page 17]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


1setOf  X            Encoding according to the rules for an attribute
                      with more than 1 value.  Each value X is encoded
                      according to the rules for encoding its type.

octetString          OCTET-STRING