rfc2910.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,598 行 · 第 1/5 页

   [RFC2911]. They MUST be encoded in a special position and they MUST
   NOT appear as operation attributes.  These parameters are described
   in the subsections below.

3.4.1 Version-number

   The "version-number" field MUST consist of a major and minor
   version-number, each of which MUST be represented by a SIGNED-BYTE.
   The major version-number MUST be the first byte of the encoding and
   the minor version-number MUST be the second byte of the encoding. The
   protocol described in this document MUST have a major version-number
   of 1 (0x01) and a minor version-number of 1 (0x01).  The ABNF for
   these two bytes MUST be %x01.01.

3.4.2 Operation-id

   The "operation-id" field MUST contain an operation-id value defined
   in the model document. The value MUST be encoded as a SIGNED-SHORT
   and it MUST be in the third and fourth bytes of the encoding of an
   operation request.

3.4.3 Status-code

   The "status-code" field MUST contain a status-code value defined in
   the model document. The value MUST be encoded as a SIGNED-SHORT and
   it MUST be in the third and fourth bytes of the encoding of an
   operation response.






Herriot, et al.             Standards Track                    [Page 12]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   The status-code is an operation attribute in the model document. In
   the protocol, the status-code is in a special position, outside of
   the operation attributes.

   If an IPP status-code is returned, then the HTTP Status-Code MUST be
   200 (successful-ok). With any other HTTP Status-Code value, the HTTP
   response MUST NOT contain an IPP message-body, and thus no IPP
   status-code is returned.

3.4.4 Request-id

   The "request-id" field MUST contain a request-id value as defined in
   the model document. The value MUST be encoded as a SIGNED-INTEGER and
   it MUST be in the fifth through eighth bytes of the encoding.

3.5 Tags

   There are two kinds of tags:

      -  delimiter tags: delimit major sections of the protocol, namely
         attributes and data
      -  value tags: specify the type of each attribute value

3.5.1 Delimiter Tags

   The following table specifies the values for the delimiter tags:

   Tag Value (Hex)    Meaning

   0x00               reserved for definition in a future IETF
                      standards track document
   0x01               "operation-attributes-tag"
   0x02               "job-attributes-tag"
   0x03               "end-of-attributes-tag"
   0x04               "printer-attributes-tag"
   0x05               "unsupported-attributes-tag"
   0x06-0x0f          reserved for future delimiters in IETF
                      standards track documents

   When a "begin-attribute-group-tag" field occurs in the protocol, it
   means that zero or more following attributes up to the next delimiter
   tag MUST be attributes belonging to the attribute group specified by
   the value of the "begin-attribute-group-tag". For example, if the
   value of "begin-attribute-group-tag" is 0x01, the following
   attributes MUST be members of the Operations Attributes group.






Herriot, et al.             Standards Track                    [Page 13]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in
   an operation.  It MUST be the last "delimiter-tag". If the operation
   has a document-content group, the document data in that group MUST
   follow the "end-of-attributes-tag".

   The order and presence of "attribute-group" fields (whose beginning
   is marked by the "begin-attribute-group-tag" subfield) for each
   operation request and each operation response MUST be that defined in
   the model document. For further details, see section 3.7 "(Attribute)
   Name" and 13 "Appendix A: Protocol Examples".

   A Printer MUST treat a "delimiter-tag" (values from 0x00 through
   0x0F) differently from a "value-tag" (values from 0x10 through 0xFF)
   so that the Printer knows that there is an entire attribute group
   that it doesn't understand as opposed to a single value that it
   doesn't understand.

3.5.2 Value Tags

   The remaining tables show values for the "value-tag" field, which is
   the first octet of an attribute. The "value-tag" field specifies the
   type of the value of the attribute.

   The following table specifies the "out-of-band" values for the
   "value-tag" field.

   Tag Value (Hex)  Meaning

   0x10             unsupported
   0x11             reserved for 'default' for definition in a future
                    IETF standards track document
   0x12             unknown
   0x13             no-value
   0x14-0x1F        reserved for "out-of-band" values in future IETF
                    standards track documents.

   The following table specifies the integer values for the "value-tag"
   field:

   Tag Value (Hex)   Meaning

   0x20              reserved for definition in a future IETF
                     standards track document
   0x21              integer
   0x22              boolean
   0x23              enum
   0x24-0x2F         reserved for integer types for definition in
                     future IETF standards track documents



Herriot, et al.             Standards Track                    [Page 14]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   NOTE: 0x20 is reserved for "generic integer" if it should ever be
   needed.

   The following table specifies the octetString values for the "value-
   tag" field:

   Tag Value (Hex)   Meaning

   0x30              octetString with an  unspecified format
   0x31              dateTime
   0x32              resolution
   0x33              rangeOfInteger
   0x34              reserved for definition in a future IETF
                     standards track document
   0x35              textWithLanguage
   0x36              nameWithLanguage
   0x37-0x3F         reserved for octetString type definitions in
                     future IETF standards track documents

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

   Tag Value (Hex)   Meaning

   0x40              reserved for definition in a future IETF
                     standards track document
   0x41              textWithoutLanguage
   0x42              nameWithoutLanguage
   0x43              reserved for definition in a future IETF
                     standards track document
   0x44              keyword
   0x45              uri
   0x46              uriScheme
   0x47              charset
   0x48              naturalLanguage
   0x49              mimeMediaType
   0x4A-0x5F         reserved for character string type definitions
                     in future IETF standards track documents

   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 type definitions in IETF
   standards track documents.



Herriot, et al.             Standards Track                    [Page 15]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   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.  Values from 0x00 to
   0x37777777 are reserved for definition in future IETF standard track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

3.6 Name-Length

   The "name-length" field MUST consist of a SIGNED-SHORT. This field
   MUST specify the number of octets in the immediately following "name"
   field.  The value of this field excludes the two bytes of the "name-
   length" field. For example, if the "name" field contains "sides", the
   value of this field is 5.

   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 attribute encoded in the nearest preceding
   "attribute-with-one-value" field. Within an attribute group, if two
   or more attributes have the same name, the attribute group is mal-
   formed (see [RFC2911] section 3.1.3). The zero-length name is the
   only mechanism for multi-valued attributes.

3.7 (Attribute) Name

   The "name" field MUST contain the name of an attribute. The model
   document [RFC2911] specifies such names.

3.8 Value Length

   The "value-length" field MUST consist of a SIGNED-SHORT. This field
   MUST specify the number of octets in the immediately following
   "value" field.  The value of this field excludes the two bytes of the
   "value-length" field. For example, if the "value" field contains the
   keyword (text) value 'one-sided', the value of this field is 9.

   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.





Herriot, et al.             Standards Track                    [Page 16]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   For "out-of-band" "value-tag" fields defined in this document, such
   as "unsupported", the "value-length" MUST be 0 and the "value" empty;
   the "value" has no meaning when the "value-tag" has one of these
   "out-of-band" values. For future "out-of-band" "value-tag" fields,
   the same rule holds unless the definition explicitly states that the
   "value-length" MAY be non-zero and the "value" non-empty.

3.9 (Attribute) Value

   The syntax types (specified by the "value-tag" field) and most of the
   details of the representation of attribute values 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.
                        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



Herriot, et al.             Standards Track                    [Page 17]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


  Syntax of Attribute   Encoding
  Value