rfc2910.txt
来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,598 行 · 第 1/5 页
TXT
1,598 行
operation request and response whether the "data" field is present or absent.3.1.2 Attribute Group Each "attribute-group" field is encoded as follows: ----------------------------------------------- | begin-attribute-group-tag | 1 byte ---------------------------------------------------------- | attribute | p bytes |- 0 or more ----------------------------------------------------------Herriot, et al. Standards Track [Page 6] RFC 2910 IPP/1.1: Encoding and Transport September 2000 The "begin-attribute-group-tag" field marks the beginning of an "attribute-group" field and its value identifies the type of attribute group, e.g. Operations Attributes group versus a Job Attributes group. The "begin-attribute-group-tag" field also marks the end of the previous attribute group except for the "begin- attribute-group-tag" field in the first "attribute-group" field of a request or response. The "begin-attribute-group-tag" field acts as an "attribute-group" terminator because an "attribute-group" field cannot nest inside another "attribute-group" field. An "attribute-group" field contains zero or more "attribute" fields. Note, the values of the "begin-attribute-group-tag" field and the "end-of-attributes-tag" field are called "delimiter-tags".3.1.3 Attribute An "attribute" field is encoded as follows: ----------------------------------------------- | attribute-with-one-value | q bytes ---------------------------------------------------------- | additional-value | r bytes |- 0 or more ---------------------------------------------------------- When an attribute is single valued (e.g. "copies" with value of 10) or multi-valued with one value (e.g. "sides-supported" with just the value 'one-sided') it is encoded with just an "attribute-with-one- value" field. When an attribute is multi-valued with n values (e.g. "sides-supported" with the values 'one-sided' and 'two-sided-long- edge'), it is encoded with an "attribute-with-one-value" field followed by n-1 "additional-value" fields.3.1.4 Picture of the Encoding of an Attribute-with-one-value Each "attribute-with-one-value" field is encoded as follows: ----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is u) | 2 bytes ----------------------------------------------- | name | u bytes ----------------------------------------------- | value-length (value is v) | 2 bytes ----------------------------------------------- | value | v bytes -----------------------------------------------Herriot, et al. Standards Track [Page 7] RFC 2910 IPP/1.1: Encoding and Transport September 2000 An "attribute-with-one-value" field is encoded with five subfields: The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'. The "name-length" field specifies the length of the "name" field in bytes, e.g. u in the above diagram or 15 for the name "sides- supported". The "name" field contains the textual name of the attribute, e.g. "sides-supported". The "value-length" field specifies the length of the "value" field in bytes, e.g. v in the above diagram or 9 for the (keyword) value 'one-sided'. The "value" field contains the value of the attribute, e.g. the textual value 'one-sided'.3.1.5 Additional-value Each "additional-value" field is encoded as follows: ----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is 0x0000) | 2 bytes ----------------------------------------------- | value-length (value is w) | 2 bytes ----------------------------------------------- | value | w bytes ----------------------------------------------- An "additional-value" is encoded with four subfields: The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'. The "name-length" field has the value of 0 in order to signify that it is an "additional-value". The value of the "name-length" field distinguishes an "additional-value" field ("name-length" is 0) from an "attribute-with-one-value" field ("name-length" is not 0). The "value-length" field specifies the length of the "value" field in bytes, e.g. w in the above diagram or 19 for the (keyword) value 'two-sided-long-edge'.Herriot, et al. Standards Track [Page 8] RFC 2910 IPP/1.1: Encoding and Transport September 2000 The "value" field contains the value of the attribute, e.g. the textual value 'two-sided-long-edge'.3.1.6 Alternative Picture of the Encoding of a Request Or a Response From the standpoint of a parser that performs an action based on a "tag" value, the encoding consists of: ----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | tag (delimiter-tag or value-tag) | 1 byte | ----------------------------------------------- |-0 or more | empty or rest of attribute | x bytes | ----------------------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | y bytes - optional ----------------------------------------------- The following show what fields the parser would expect after each type of "tag": - "begin-attribute-group-tag": expect zero or more "attribute" fields - "value-tag": expect the remainder of an "attribute-with-one- value" or an "additional-value". - "end-of-attributes-tag": expect that "attribute" fields are complete and there is optional "data"3.2 Syntax of Encoding The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be case sensitive. For example 'a' means lower case 'a' and not upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as '%x' values which show their range of values. ipp-message = ipp-request / ipp-response ipp-request = version-number operation-id request-id *attribute-group end-of-attributes-tag data ipp-response = version-number status-code request-id *attribute-group end-of-attributes-tag dataHerriot, et al. Standards Track [Page 9] RFC 2910 IPP/1.1: Encoding and Transport September 2000 attribute-group = begin-attribute-group-tag *attribute version-number = major-version-number minor-version-number major-version-number = SIGNED-BYTE minor-version-number = SIGNED-BYTE operation-id = SIGNED-SHORT ; mapping from model defined below status-code = SIGNED-SHORT ; mapping from model defined below request-id = SIGNED-INTEGER ; whose value is > 0 attribute = attribute-with-one-value *additional-value attribute-with-one-value = value-tag name-length name value-length value additional-value = value-tag zero-name-length value-length value name-length = SIGNED-SHORT ; number of octets of 'name' name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) value-length = SIGNED-SHORT ; number of octets of 'value' value = OCTET-STRING data = OCTET-STRING zero-name-length = %x00.00 ; name-length of 0 value-tag = %x10-FF ;see section 3.7.2 begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1 end-of-attributes-tag = %x03 ; tag of 3 ; see section 3.7.1 SIGNED-BYTE = BYTE SIGNED-SHORT = 2BYTE SIGNED-INTEGER = 4BYTE DIGIT = %x30-39 ; "0" to "9" LALPHA = %x61-7A ; "a" to "z" BYTE = %x00-FF OCTET-STRING = *BYTE The syntax below defines additional terms that are referenced in this document. This syntax provides an alternate grouping of the delimiter tags. delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1 end-of-attributes-tag delimiter-tag = %x00-0F ; see section 3.7.1 begin-attribute-group-tag = %x00 / operation-attributes-tag / job-attributes-tag / printer-attributes-tag / unsupported-attributes-tag / %x06-0F operation-attributes-tag = %x01 ; tag of 1Herriot, et al. Standards Track [Page 10] RFC 2910 IPP/1.1: Encoding and Transport September 2000 job-attributes-tag = %x02 ; tag of 2 printer-attributes-tag = %x04 ; tag of 4 unsupported-attributes-tag = %x05 ; tag of 53.3 Attribute-group Each "attribute-group" field MUST be encoded with the "begin- attribute-group-tag" field followed by zero or more "attribute" sub- fields. The table below maps the model document group name to value of the "begin-attribute-group-tag" field: Model Document Group "begin-attribute-group-tag" field values Operation Attributes "operations-attributes-tag" Job Template Attributes "job-attributes-tag" Job Object Attributes "job-attributes-tag" Unsupported Attributes "unsupported-attributes-tag" Requested Attributes "job-attributes-tag" (Get-Job-Attributes) Requested Attributes "printer-attributes-tag" (Get-Printer-Attributes) Document Content in a special position as described above For each operation request and response, the model document prescribes the required and optional attribute groups, along with their order. Within each attribute group, the model document prescribes the required and optional attributes, along with their order. When the Model document requires an attribute group in a request or response and the attribute group contains zero attributes, a request or response SHOULD encode the attribute group with the "begin- attribute-group-tag" field followed by zero "attribute" fields. For example, if the client requests a single unsupported attribute with the Get-Printer-Attributes operation, the Printer MUST return no "attribute" fields, and it SHOULD return a "begin-attribute-group- tag" field for the Printer Attributes Group. The Unsupported Attributes group is not such an example. According to the model document, the Unsupported Attributes Group SHOULD be present only if the unsupported attributes group contains at least one attribute. A receiver of a request MUST be able to process the following as equivalent empty attribute groups:Herriot, et al. Standards Track [Page 11] RFC 2910 IPP/1.1: Encoding and Transport September 2000 a) A "begin-attribute-group-tag" field with zero following "attribute" fields. b) An expected but missing "begin-attribute-group-tag" field. When the Model document requires a sequence of an unknown number of attribute groups, each of the same type, the encoding MUST contain one "begin-attribute-group-tag" field for each attribute group even when an "attribute-group" field contains zero "attribute" sub-fields. For example, for the Get-Jobs operation may return zero attributes for some jobs and not others. The "begin-attribute-group-tag" field followed by zero "attribute" fields tells the recipient that there is a job in queue for which no information is available except that it is in the queue.3.4 Required Parameters Some operation elements are called parameters in the model document⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?