2. OBEX Object Model
The object model addresses（解决了） the question of how objects are represented by OBEX. The model must deal with both the object being transferred and information about the object. It does this by putting the pieces together in a sequence（序列） of headers. A header is an entity that describes some aspect（方面） of the object, such as name, length, descriptive（描述性） text, or the object body itself. For instance, headers for the file jumar.txt might contain the name, a type identifier of “text”, a description saying “How to use jumars to grow better tomatoes”, the file length, and the file itself
对象模型，解决了OBEX如何描述object的问题。对象模型必须处理要发送对象的本身和对象的相关信息。它是通过将各个部分组合成一个标题（header）序列来实现的。一个header可以描述object的许多方面，比如名字，长度，描述性文本，还有object本身自己。比如文件jumar.txt的headers，可以包括它的名字，类型标识text，一个而简单描述，文件的长度，和它自身。
2.1 OBEX Headers
Headers have the general form:
- <HI, the header ID>
- <HV, the header value>
HI, the header ID, is an unsigned（无符号） one-byte quantity that identifies what the header contains and how it is formatted. HV consists of one or more bytes in the format and meaning specified by HI. All headers are optional（可选的） - depending（根据） on the type of device and the nature（性质） of the transaction（传输）, you may use all of the headers, some, or none at all. IDs make headers parseable（可解析的） and order independent（顺序无关的）, and allow unrecognized（无法解析的） headers to be skipped easily. Unrecognized headers should be skipped by the receiving device.
HI是无符号单字节的，负责标识出header里包含什么和它的格式。HV包含一个或者多个字节，HV的格式和含义由HI指定。所以的头都是可选的，根据设备的类型和传输的性质。你可以使用所以头，也可以使用一些，也可以不使用任何头。IDs 让头的可解析和顺序无关的，并可以轻松忽略无法解析的头。接收端的设备会忽略无法解析的头。
OBEX defines a set of headers that are used quite frequently and therefore benefit（好处） from a compact
representation（标识）. It also provides a mechanism（机制） to use any HTTP header, as well as user defined headers.This small set will serve the needs of file transfer on PCs as well as the needs of many other devices, while facilitating a clean mapping to HTTP when OBEX is used as a compact final hop in a web communication.
OBEX定义了一些常用的头。它也提供了一种机制，去使用HTTP的头，也可以使用用户定义的头。这些常用的头用于在PC间或别的设备间进行文件传输，同时当OBEX是WEB通信的最后一跳的时候，促进了映射到HTTP。
The low order 6 bits of the header identifier(HI) are used to indicate the meaning of the header, while the
upper 2 bits are used to indicate the header encoding. This encoding provides a way to interpret（解释）
unrecognized headers just well（以便） enough to discard them cleanly. The length prefixed header encodings send the length in network byte order（网络字节序), and the length includes the 3 bytes of the identifier and length. For Unicode text, the length field (immediately following the header ID) includes the 2 bytes of the null terminator (0x00, 0x00). Therefore the length of the string ”Jumar” would be 12 bytes; 5 visible characters plus the null terminator, each two bytes in length.
The 2 high order bits of HI have the following meanings
| Bits 8 and 7 of HI | Interpretation |
|---|---|
| 00 (0X00) | null terminated Unicode text, length prefixed with 2 byte unsigned integer 以空结尾的Unicode文本，长度以2字节无符号整数为前缀 |
| 01 (0X40) | byte sequence, length prefixed with 2 byte unsigned integer字节序列，长度前缀为2字节无符号整数 |
| 10 (0X80) | 1 byte quantity |
| 11 (0XC0) | 4 byte quantity – transmitted in network byte order (high byte first) |
The Header identifiers are:
| HI - identifier | Header name | Description |
|---|---|---|
| 0xC0 | Count | Number of objects (used by Connect) |
| 0x01 | Name | name of the object (often a file name) |
| 0x42 | Type | type of object - e.g. text, html, binary, manufacturer specific |
| 0xC3 | Length | the length of the object in bytes |
| 0x44 0xC4 | Time | date/time stamp – ISO 8601 version - preferred; date/time stamp – 4 byte version (for compatibility only) |
| 0x05 | Description | text description of the object |
| 0x46 | Target | name of service that operation is targeted to |
| 0x47 | HTTP | an HTTP 1.x header |
| 0x48 0x49 | Body;End of Body | a chunk of the object body.the final chunk of the object body |
| 0x4A | Who | identifies the OBEX application, used to tell if talking to a peer |
| 0xCB | Connection Id | an identifier used for OBEX connection multiplexing(多路复用) |
| 0x4C | App. Parameters | extended application request & response information |
| 0x4D | Auth. Challenge | authentication digest-challenge 身份认证摘要 |
| 0x4E | Auth. Response | authentication digest-response |
| 0xCF | Creator ID | indicates the creator of an object |
| 0x50 | WAN UUID | uniquely identifies the network client (OBEX server) |
| 0x51 | Object Class | OBEX Object class of object |
| 0x52 | Session-Parameters | Parameters used in session commands/responses |
| 0x93 | Session-Sequence-Number | Sequence number used in each OBEX packet for reliability（可靠性) |
| 0x14 to 0x2F | Reserved(保留) for future use | this range includes all combinations of the upper 2 bits |
| 0x30 to 0x3F | User defined | this range includes all combinations of the upper 2 bits |
All allowable headers and formats thereof are listed by this table. Applications must not change the upper
bits on OBEX defined headers and expect anyone else to recognize（认识） them. Note that the header
identifiers are numbered in order, starting with zero. The high order bits which specify the encoding
obscure（混淆） this linear sequence of header numbering.
上表列出了所有合法的头。应用程序不能更改OBEX定义的头的高位，并希望其他人能够识别它们。注意，HI是按顺序编号的，从零开始。由于高2个位是标识encoding的，所有会混淆头的排序。
Certain（某些） headers like Body are expected to be present（出现） repeatedly（重复地）, however headers like Name and Time do not necessarily（必然地） make sense（合理） when sent multiple times. The behavior by the recipient（接收方） of multiple（多个） non-Body headers is not defined by the protocol.
某些body的header是可以出现多次的，然而非body的header出现多次就必然不合理了。OBEX协议并没有定义接收方需要处理多个非body的header的行为。
All Unicode headers are encoded using UTF-16 format with the bytes sent in network order.
所有的unicode header使用UTF-16编码格式，并用网络字节序发送。
Header descriptions
2.2.1 Count
Count is a four byte unsigned integer to indicate the number of objects involved in the operation.
Count是4个字节的无符号整数，用于指定操作里涉及到的object数量。
2.2.2 Name
Name is a null terminated Unicode text string describing the name of the object.
Example: JUMAR.TXT
名称是以空结尾的Unicode文本字符串，用于描述对象.示例: JUMAR.TXT文件
Though the Name header is very useful for operations like file transfer, it is optional - the receiving
application may know what to do with the object based on context, Type, or other factors. If the object is
being sent to a general purpose device such as a PC or PDA, this will normally be used as the filename
of the received object, so act accordingly（相应地）. Receivers that interpret this header as a file name must be prepared to handle Names that are not legitimate（合法的） filenames on their system. In some cases an empty Name header is used to specify a particular behavior（特定行为）; see the GET and SETPATH Operations. An empty Name header is defined as a Name header of length 3 (one byte opcode + two byte length).
虽然Name 头对传输很有用，但是它是可选的，接收方的程序能够根据object的上下文，类型和其他别的因素知道如何去处理。如果对象被发送到诸如PC或PDA的通用设备，则通常将其用作接收对象的文件名，因此相应地采取行动。将此头解释为文件名的接收者必须准备好处理其系统上不合法的文件名。在某些情况下，空名称头用于指定特定行为；请参阅GET和SETPATH操作。空名称头定义为长度为3（一字节操作码+两字节长度）的名称头。
2.2.3 Type
Type is a byte sequence consisting of null terminated ASCII text describing the type of the object, such
as text, binary, or vCard. Type is used by the receiving side to aid in intelligent（智能的） handling of the object. This header corresponds to（相当于） the content-type header in HTTP.
类型是一个字节序列，由以空结尾的ASCII文本组成，该文本描述对象的类型，如文本、二进制或vCard。类型由接收方用于帮助智能处理对象。此头对应于HTTP中的内容类型头（content-type）。
Whenever possible（只要可能）, OBEX (like HTTP) uses IANA registered media types to promote （促进）interoperability（互操作性）based on open standards（公开标准）. When a registered type is used, the HTTP canonical（规范的） form for the object body must also be used. In other words（换句话说）, if you say a thing is of type “text/html”, it must meet all（满足） the rules for representing（代表） items of type “text/html”. OBEX follows（遵循） RFC 1521 which defines the media type format and handles Type header values are case insensitive（不区分大小写） values. See the following URL for a list of MIME defined media types: http://www.isi.edu/in-notes/iana/assignments/media-types.
只要可能，OBEX就使用IANA标准里的媒体类型，以促进互操作性。当使用一个注册的规范的类型时，则body也必须是响应的，也就是说，你如果使用的类型是text/html，则body则必须满足text/html的所有要求。OBEX遵循RFC1521，RFC1521定义了类型的格式和类型的值，不区分大小写。
If no Type is specified, the assumed（假设） type is binary, and it is up to（由） the receiving software to deal with it as best it can. This may involve（涉及到） simply storing it without modification of any kind under the stated（规定的） name, and/or trying to recognize it by the extension on the name（文件的扩展名）. For instance, a Microsoft Word file could be sent with no type, and the receiving software, seeing the .doc suffix could choose to interpret（解析） it as a Word file.
如果未指定类型，则假定类型为二进制，并由接收软件尽可能处理。这可能涉及到简单地将其存储在所述名称下而不进行任何修改，和/或试图通过名称上的扩展来识别它。例如，一个Microsoft Word文件可以不带类型地发送，而接收软件看到.doc后缀就可以选择将其解释为Word文件。
Though the Type header is very useful for transfer of non-file object types, it is optional - the receiving
application may know what to do with the object based on context, name, or other factors.
尽管类型头对于非文件对象类型的传输非常有用，但它是可选的——接收应用程序可能知道如何根据上下文、名称或其他因素处理对象。
2.2.4 Length
Length is a four byte unsigned integer quantity giving the total length in bytes of the object. If the Length
is known in advance（提前知道）, this header should be used. This allows the receiver to quickly terminate transfers requiring（需要） too much space, and also makes progress reporting easier.
Length是一个四字节无符号整数量，以字节为单位给出对象的总长度。如果提前知道长度，则应使用此标题。
If a single object exceeds（超过） 4 gigabytes - 1 in length, its size cannot be represented（识别） by this header. Instead an HTTP content-length header should be used, which is ASCII encoded decimal and can represent arbitrarily（任意大的） large values. However, implementations that cannot handle such large objects are not required to recognize the HTTP header.
如果单个对象的长度超过4GB-1，则此头无法表示其大小。相反，应该使用HTTP内容长度头，它是ASCII编码的十进制，可以表示任意大的值。但是，不能处理如此大对象的实现不需要识别HTTP头。
The Length header is optional, because in some cases, the length is not known in advance, and the
End-of-Body header will signal（通知） when the end of the object is reached.
长度头是可选的，因为在某些情况下，长度事先不知道，当到达对象的结尾时，End-of-Body header就是结尾的标志。
2.2.5 Time
Time is a byte sequence that gives the object’s UTC date/time of last modification in ISO 8601 format.
Local times should be represented in the format YYYYMMDDTHHMMSS and UTC time in the format
YYYYMMDDTHHMMSSZ. The letter “T” delimits（划界） the date from the time. UTC time is identified by
concatenating a “Z” to the end of the sequence. When possible UTC times should be used. This header
is encoded as a US-ASCII string. The Date/Time header is optional
时间header是一个字节，它给出了对象在ISO 8601中最后修改的UTC日期/时间格式.本地时间应以yyyymmddthhmms格式表示，UTC时间应以yyyymmddthhmmsz格式表示。字母“T”从时间中划出日期。UTC时间通过将“Z”连接到序列的末尾来标识。当使用UTC时间，此头编码为US-ASCII字符串。日期/时间标题是可选的。
Note: One notable OBEX application was released before the standard became final, and uses an
unsigned 4 byte integer giving the date/time of the object’s last modification in seconds since January 1，1970 Implementers may wish to accept or send both formats for backward compatibility（向后兼容）, but it is not required. The preferred（首选的） ISO 8601 format and this format can be distinguished（区分） by the high two bits of the Header Identifier—ISO 8601 uses the text HI encoding 0x44, while this one uses the 4 byte integer HI encoding 0xC4
注意：一个值得注意的OBEX应用程序是在标准成为最终版本之前发布的，它使用一个无符号的4字节整数，给出自1970年1月1日以来对象最后一次修改的日期/时间（以秒为单位），实现者可能希望接受或发送这两种格式以实现向后兼容性，但这不是必需的。首选的ISO 8601格式和此格式可以通过头标识符的高位两位来区分iso8601使用文本HI编码0x44，而此格式使用4字节整数HI编码0xC4
2.2.6 Description
Description is a null terminated Unicode text string used to provide additional（附加） description of the object or operation. The Description header is optional. The Description header is not limited to describing
objects. For example, it may accompany（陪同） a response code to provide additional information about the response.
描述是以空结尾的Unicode文本字符串，用于提供对象或操作的附加描述。说明标题是可选的。描述头不限于描述对象。例如，它可以与响应代码一起提供有关响应的附加信息。
2.2.7 Target
Target is a byte sequence that identifies the intended（预期的） target of the operation. On the receiving end（在接收端）, object name and type information provide one way of performing dispatching（分发） - this header offers an alternate（另一种） way of directing（导航） an operation to the intended recipient.
Target是一个字节序列，用于标识预期目标的操作。在接收端，可以根据对象的名称和类型信息，来决定如何处理。—Target头提供了另一种方法，告诉接收方如何去处理
The Target headers most common use, is when sent in an OBEX CONNECT packet to initiate（发起） a directed connection to an OBEX server (see section 4.6). A list of well-known Target header values is contained in the appendix（附录） of this specification（规范）. The Target header is commonly used in conjunction（连同） with the Who and Connection Id headers when establishing a directed connection.
Target头的最常见用法就是，当发送一个 OBEX CONNECT packet去连接某个OBEX server时使用。一些Target头的常用值在此规范的附录里。Target头经常和Who头，Connection Id 头一起使用，去完成连接的建立。
When used with the PUT operation, it allows for behavior analogous（类似于） to the HTTP POST operation. Wherein（其中） the Target specifies the service that should process the object contained in the PUT request.
当与PUT操作一起使用时，它允许类似于HTTP POST操作的行为。其中，Target指定由哪个service来处理此PUT请求。
The sending device must provide this header in a form meaningful（有意义的） to the destination device. If this header is received but not recognized, it is up to the implementation to decide whether to accept or reject（拒绝） the accompanying（伴随着的） object. When used, the Target header must be the first header in the operation.
发送方设备必须提供Target头，而且Target的信息必须对接收方有意义（接收方能够识别）。如果此头被接收到了，但是对方无法识别，则由对方的具体实现逻辑来决定是接收伴随过来的object还是决绝。一旦使用此头，必须是所有头里的第一个。
To work effectively in a broad application environment it is necessary that the Target header identify a
universally unique service or client. It is recommended that 128-bit UUID’s be used to fulfill this
requirement. Since the Target header is a binary header type, values are compared in a case sensitive
manner. Therefore, care must be taken to maintain the proper case when using ASCII values.
要在广泛的应用程序环境中有效地工作，target头必须标识一个普遍唯一的server或client。建议使用128位UUID来满足此要求。由于目标头是二进制头类型，因此将以区分大小写的方式比较值。因此，在使用ASCII值时必须注意保持正确的大小写。
It is illegal（非法的） to send a Connection Id and a Target header in the same request. It is legal（合法的） to send both headers in a response, as discussed in section 3.3.1.6.
在同一请求中既发送连接Id头也发送Target头是非法的。如第3.3.1.6节所述，在响应中发送两个头是合法的。
2.2.8 HTTP
HTTP is a byte sequence containing an HTTP 1.x header. This can be used to include many advanced（高级的）features already defined in HTTP without re-inventing（重新发明） the wheel. HTTP terminates lines using CRLF, which will be preserved（保存） in this header so it can be passed directly to standard HTTP parsing routines. This header is optional.
HTTP是一个包含HTTP 1.x头的字节序列。这可以用来包括许多已经在HTTP中定义的高级特性，而无需重新发明轮子。HTTP使用CRLF终止行，CRLF将保留在此头中，以便可以直接传递给标准HTTP解析例行程序。这个标题是可选的。
2.2.9 Body, End-of-Body
The body of an object (the contents of a file being transferred, for instance) is sent in one or more Body
headers. A “chunked”（分块） encoding helps make abort handling（终止处理） easier, allows for operations to be interleaved（交叉）, and handles situations where the length is not known in advance, as with（如同） process generated data and on-the-fly（飞行中的） encoding.
对象的主体（例如，正在传输的文件的内容）以一个或多个Body头发送。“分块”编码有助于简化中止处理，允许交叉操作，并处理事先不知道长度的情况，如处理刚生成的数据和动态编码。
A Body header consists of the HI (identifying it as an object body), a two byte header length, and all or
part of the contents of the object itself.
Body头包括HI，2个字节的Body头的长度，和所有或部分的body主体。
A distinct HI value (End-of-Body) is used to identify the last chunk（块） of the object body. In some cases, the object body data is generated on the fly（动态生成的） and the end cannot be anticipated（预料）, so it is legal to send a zero length End-of-Body header. The End-of-Body header signals（通知） the end of an object, and must be the final header of any type associated（相关的） with that object.
一个特殊的HI值（Body的结尾）用于标识对象体的最后一个块。在某些情况下，对象正文数据是动态生成的，并且无法预期结尾，因此发送一个长度为零的正文结尾头是合法的。正文结尾头表示对象的结尾，并且必须是与该对象关联的任何类型的最后一个头。
2.2.10 Who
Who is a length prefixed byte sequence used so that peer applications may identify each other, typically（通常）to allow special additional capabilities unique to that application or class of device to come into play（come into play开始发挥作用）.
Who是一个长度前缀字节序列，用于对等应用程序可以相互标识，通常是为了允许该应用程序或设备类别特有的特殊附加功能发挥作用。
The Who header is typically used in an OBEX CONNECT response packet to indicate the UUID of the
service which has accepted the directed connection. The value of the Who header matches the value of
the Target header sent in the CONNECT command.
Who报头通常用于OBEX连接响应包中，以指示已接受定向连接的服务的UUID。Who头的值与CONNECT命令中发送的目标头的值匹配。
To work effectively in a broad application environment it is necessary that the Who header identify a
universally unique service or client. It is recommended that 128-bit UUID’s be used to fulfill this
requirement.
为了在广泛的应用程序环境中有效地工作，who header必须标识一个普遍唯一的服务或客户机。建议使用128位UUID来满足此要求。
2.2.11 Connection Identifier
Connection Id is a 4-byte value that tells the recipient of the request which OBEX connection this
request belongs to. The Connection Id header is optional. When in use, the Connection Id header must
be the first header in the request.
连接Id是一个4字节的值，它告诉请求的接收者这个请求属于哪个OBEX连接。连接Id头是可选的。使用时，连接Id头必须是请求中的第一个头。
When it is desirable（想要） to provide concurrent（并发） access to multiple OBEX services over the same TinyTP connection, the Connection Id is used to differentiate between multiple clients. This is often the case
when multiple services are accessed via the default OBEX server. The server can identify the need for a
connection to be assigned（分配）, by the presence（存在） of a Target header in the OBEX CONNECT packet. The connection identifier is returned to the client in the OBEX CONNECT response packet. This connection identifier must be unique so that services can be uniquely identified. Once a logical OBEX Connection has been established, all further（后面的） client requests to that service must include the Connection Id header. Only the first packet in the request needs to contain the Connection Id header. As a result, only one request can be processed at a time.
当需要通过同一TinyTP连接提供对多个OBEX服务的并发访问时，连接Id用于区分多个客户端。当通过默认的OBEX服务器访问多个service时，默认的OBEX服务器可以通过在OBEX CONNECT包中的Target header来识别出要访问的目标service。连接标识符在OBEX CONNECT响应包中返回给客户端。此连接标识符必须是唯一的，以便可以唯一地标识出此service。一旦建立了逻辑OBEX连接，对该服务的所有其他客户端请求都必须包含连接Id头。只有请求中的第一个数据包需要包含连接Id头。因此，一次只能处理一个请求。
If a Connection Id header is received with an invalid（无效的） connection identifier, it is recommended that the operation be rejected with the response code (0xD3) “Service Unavailable”. Since not（因为不是） all servers will parse this header, there is no guarantee（保证） that this response code will be returned in all such cases. For convenience the connection identifier value 0xFFFFFFFF is reserved（保留） and is considered（被认为） invalid.
如果接收到带有无效连接标识符的连接Id头，建议使用响应代码（0xD3）“服务不可用”拒绝该操作。由于并非所有服务器都将解析此头，因此无法保证在所有此类情况下都会返回此响应代码。为了方便起见，连接标识符值0xFFFFFFFF被保留，并被视为无效。
It does not make sense（合乎常理的） to send a Connection Id header in an OBEX CONNECT operation and is therefore（因此） forbidden（禁止）. It is optional to send a Connection Id header in an OBEX ABORT operation, as（正如）discussed in section 3.3.5. It is also illegal（非法的） to send a Connection Id and a Target header in the same request.
在OBEX连接操作中发送连接Id头是没有意义的，因此是禁止的。在OBEX中止操作中发送连接Id头是可选的，如第3.3.5节所述。在同一请求中发送连接Id和目标头也是非法的。
2.2.12 Application Request-Response Parameters
The Application Parameters header is used by applications (and protocols) layered above OBEX to
convey（传递出） additional information in a request or response packet. In a request, this header conveys request parameters or modifiers. In a response, it is used in cases where the simple pass/fail status returned by OBEX is insufficient（不够的）. In order to support an unbounded（无限的） set of values, from integer values to whole structures (used in RPC style requests) .the Application Parameter header is based on the OBEX Byte-Sequence Header format.
应用参数报头由位于OBEX之上的应用程序（和协议）使用，以在请求或响应包中传送附加信息。在请求中，此头传递请求参数或修饰符。在响应中，它用于r如果OBEX只返回的简单成功或者失败的状态是不够的。为了支持响应里可以表示出无限的值，比如从整数值到整个结构体（用于RPC样式的请求），所以，应用程序参数头要基于OBEX字节序列头格式。
A Tag-Length-Value encoding scheme（方案） is used to support a variety（多样的） of request/response types and levels. An application parameters header may contain more than one tag-length-value triplet（三元组）. The header format is shown below:
Tag-Length-Value encoding 方案用于支持多样的请求/响应类型和级别。一个application parameters header可以包含超过一个的三元组。具体格式如下：
| Parameter Triplet 1 | Parameter Triplet 2 | Parameter Triplet . . . |
|---|---|---|
| Tag1 Length Value | Tag2 Length Value | Tag Length Value |
The tag and length fields are each one byte in length. The value field can be from zero to n bytes long.
The value n is constrained（限制） by the maximum size of an OBEX header, the length field maximum of 255 bytes and the size of other TLV-triplets encoded in the header.
tag和length是各一个字节。value可以是0到n个字节。n的最大值由OBEX header限定，n的最大值是255字节。
TAG values are defined by the applications or upper protocol layer that uses them and only need to be
unique within the scope of the application or protocol layer.
tag的值由使用它们的application或者上层的协议定义，只需要在application或上层协议里保持唯一即可。
2.2.13 Authenticate Challenge
The Authenticate Challenge（身份验证） header is used by both clients and servers to initiate the authentication of the remote device. This header carries the digest-challenge string（电子摘要字符串）. See the Authentication chapter for a detailed explanation（解释） of the authentication procedure.
发起连接的时候，client和server都使用 Authenticate Challenge header，这个头里有电子摘要字符串。
A Tag-Length-Value encoding scheme（方案） is used to support the variety of options available for
authentication（认证）. An Authenticate Challenge header may contain more than one tag-length-value triplet（三元组）. The header format is shown below:
Tag-Length-Value 被用于各种各样的认证操作。一个Authenticate Challenge头可以包含一个或多个Tag-Length-Value三元组。头的格式如下：
| Authentication Triplet 1 | Authentication Triplet 1 | Authentication Triplet . . . |
|---|---|---|
| Tag1 Length Value | Tag2 Length Value | Tag Length Value |
The tag and length fields are each one byte in length. The value field can be from zero to n bytes long.
The value n is constrained by the maximum size of an OBEX header, the length field maximum of 255
bytes and the size of other TLV-triplets encoded in the header.
tag和length是各一个字节。value可以是0到n个字节。n的最大值由OBEX header限定，n的最大值是255字节。
2.2.14 Authenticate Response
The Authenticate Response header is used by both clients and servers to respond to an authentication
request. This header carries the digest-response string. See the Authentication chapter for a detailed
explanation of the authentication procedure.
client和server在响应authentication request的使用，都使用Authenticate Response header，这个头里有电子摘要字符串。
A Tag-Length-Value encoding scheme is used to support the variety of options available for
authentication. An Authenticate Response header may contain more than one tag-length-value triplet.
The tag format is the same as that defined for the Authenticate Challenge header shown above.
Tag-Length-Value 被用于各种各样的认证操作。一个Authenticate Challenge头可以包含一个或多个Tag-Length-Value三元组。格式和 Authenticate Challenge一样。
2.2.15 Creator ID
The Creator ID header is a 4-byte unsigned integer value that identifies the creator of the object. The
Creator ID can be used by the receiving side to aid in（帮助） intelligent handling of the object.
creator id header是4字节无符号整数，用于标识出object是由谁创建的。一般接收端会使用creator id，根据creator id来做一些特殊的处理。
2.2.16 WAN UUID
The WAN UUID header is for use（供使用） when layering（分层） OBEX over stateless networks where the roles of network client and server are opposite to（与。。。相反） those of OBEX client and server (such as in WAP). In such an environment, the network client (the mobile device) is also the OBEX server. Here, the WAN UUID is used to provide state because the network client is only recognized by the server for one
request/response pair at a time. The WAN UUID header is a 16 byte UUID that uniquely identifies the
network client (OBEX server) to the network server. The network server provides the UUID to the OBEX
server in an OBEX Connect request packet. The OBEX Server then sends the header to the network
server in all future OBEX responses. The header type is byte-sequence (0x20).
当OBEX层构建在 stateless network上面的时候，WAN UUID header会被使用。这时client和server的概念，和OBEX的client和server正相反（比如在WAP环境里）。在这样的环境里，network client（移动设备）也是OBEX server。WAN UUID header里可以包含状态信息，这个状态信息供client/server使用。在一次request/response中，network client只会被server识别一次。所以这个状态信息，就可以提供额外的信息。 WAN UUID header占16字节。UUID用来标识network client。network server提供UUID给OBEX server在一次OBEX 连接请求里。然后OBEX server再和network server通信时，就会在相应里包含network server给的UUID。heaer type是字节序（0x20).
2.2.17 Object Class
The Object Class header is used to reference(指向) the object class and properties. It is based on the byte
sequence header type. At its lowest level the Object Class header works similarly to the OBEX Type
header except that its namespace is that of OBEX not MIME. For sub-object level access, the header can
be detailed enough to express specific fields or subsets of the objects’ contents. The values used in
Object Class headers are limited in scope to the application or services that define them. However, the
sharing of Object Classes is encouraged.
Object Class header用于指向object class和properties。类型是字节序的。在最底层Object Class header的工作机制和OBEX Type header比较像，除了命名空间意外。一个是OBEX一个是MIME。对于子对象级访问，头可以足够详细，以表示对象内容的特定字段或子集。Object Class header里能够使用的值，仅限于定义它们的application或service。但是推荐使用共享的Object Classes
2.2.18 Session-Parameters
Session-Parameters is a byte sequence that is required for the CREATESESSION, CLOSESESSION,
SUSPENDSESSION, RESUMESESSION and SETTIMEOUT commands and the responses to these
commands. It contains a set of parameters, which are specific to the command in which the header is
used. If required, the Session-Parameters must be the first header in a SESSION command or
response. In addition（另外）, for SESSION commands only, the Session Opcode must be the first tag-lengthvalue triplet within the Session-Parameters header.
Session-Parameters是一个自己序列。包括了CREATESESSION, CLOSESESSION, SUSPENDSESSION, RESUMESESSION and SETTIMEOUT请求，和对这些请求的响应。它包含一组参数，在header里指定。如果有需要则Session-Parameters是在SESSION command or response里的第一个header。另外对于SESSION命令，Session Opcode，必须是在Session-Parameters header里的第一个TVL三元组。
A Tag-Length-Value encoding scheme is used to support a variety of parameters. A Session-
Parameters header may contain more than one tag-length-value triplet. The header format is shown
below:
Tag-Length-Value 被用于各种各样的认证操作。一个Session-Parameters头可以包含一个或多个Tag-Length-Value三元组。头的格式如下：
| Parameter Triplet 1 | Parameter Triplet 1 | Parameter Triplet . . . |
|---|---|---|
| Tag1 Length Value | Tag2 Length Value | Tag Length Value |
The tag and length fields are each one byte in length. The value field can be from zero to n bytes long.
The value n is constrained by the maximum size of an OBEX header, the length field maximum of 255
bytes and the size of other TLV-triplets encoded in the header.
tag和length是各一个字节。value可以是0到n个字节。n的最大值由OBEX header限定，n的最大值是255字节。
The following TAG values are defined.
| tag value | name | Meaning |
|---|---|---|
| 0x00 | Device | The device address of the device sending the header. If running over IrDA this is the 32-bit device address. For Bluetooth this is the 48-bit Bluetooth address. If Running over TCP/IP this is the IP address。发送header设备的设备地址。如果设备运行在IrDA上，则是32位的地址；如果运行在蓝牙上则是48位的地址；如果允许在TCP/IP上，则是IP地址。 |
| 0x01 | Nonce 临时数 | The nonce is a value provided by the device, which will be used in the creation of the session ID. This number must be unique for each session created by the device. One method for creating the nonce is to start with a random number then increment the value each time a new session is created. The Nonce should be at least 4 bytes and at most 16 bytes in size。nonce是一个由设备提供的临时数，此临时数用于创建session id。每个session对于的nonce必须是唯一的。创建nonce的一种办法是，以一个随机数作为开头，每当要创建新的session时，则把这个随机数加1.Nonce的大小必须在4个字节和16个字节之间。 |
| 0x02 | Session ID 会话id | Session ID. This is a 16-byte value, which is formed by taking the device address and nonce from the client and server and running the MD5 algorithm over the resulting string. The Session ID is created as follows: MD5(“Client Device Address” “Client Nonce” “Server Device Address” “Server Nonce”)。session id是一个16字节的串，它由client/server的nonce和地址，并通过MD5算法来计算得出。 |
| 0x03 | Next Sequence | This is a one-byte value sent by the server, which indicates the next sequence number expected when the session is resumed。它是由server发送的1个字节的数据。当session恢复时，需要知道Next Sequence。Next Sequence是由server发送出来的。 |
| 0x04 | Timeout | This is a 4-byte value that contains the number of seconds a session can be in suspend mode before it is considered（被认为） closed. The value of 0xffffffff indicates a timeout of infinity（无限的）. This is the default timeout. If a device does not send a timeout field then it can be assumed(假设) that the desired（渴望的） timeout is infinity. The timeout in affect（影响） is the smallest timeout sent by the client or server. Timeout是一个4个字节的秒数。它规定了session被关闭前可以暂停的秒数。它的值如果是0xffffffff的话，则表面timeout的秒数是无限的。这也是timeout的默认值。如果一个设备没有发送timeout字段，则默认是无限的。 |
| 0x05 | Session Opcode | The session opcode is a 1-byte value sent by the client to indicate the Session command that is to be performed. This tag-length-value is only sent in SESSION commands and must be the first tag in the Session-Parameters header. The session opcode definitions are defined in the bulleted（项目符号） list below。session opcode是一个字节，由client发送的，用于指示要执行的session command。tlv只有在session command里才会被发送，而且必须是在Session-Parameters header里的第一个tag。session opcode定义在下面。 |
| 0x06 - 0xff | Reserved 保留 |
Session Opcode Definitions:
• 0x00 Create Session
• 0x01 Close Session
• 0x02 Suspend Session
• 0x03 Resume Session
• 0x04 Set Timeout
• 0x05 – 0xFF Reserved
2.2.19 Session-Sequence-Number
Session-Sequence-Number is a 1-byte quantity containing the current sequence number. Even though
OBEX is a command/response protocol and only one outstanding（未清零的） command can exist at any given time,the counting capacity（计数器能力） of the sequence number is 256 using digits 0 – 255 (0xFF). At 255 the sequence number wraps around to（绕回到） 0. This adds（增加了） another level of verification（校验） that the correct session is being resumed. If the sequence number is invalid（非法的） then the session should be aborted. This procedure（过程） should be followed（遵循） both when the session is being resumed（恢复） and during an active session.
Session-Sequence-Number占一个字节，里面包含了当前sequence number。尽管OBEX是一个 request/response的协议，而且在任何一个给的的时间点只要一个还为处理的request，但是计数器是从0到255开始计数的。当到达255时，又会回到0.如果序列号无效，则应中止会话。在恢复会话时和活动会话期间都应遵循此过程。
When the session is first created the Session-Sequence-Number， number is set to 0. The first command
packet sent by the client after the session is established will contain a Session-Sequence-Number
header with value of 0. The response to this packet from the server contains the next packet number
expected. If the packet was received successfully then the value of the Session-Sequence-Number
header in the response would be 1.
当第一次创建session时，number被设置成0.在创建session连接后，由client发送的第一个command packet里会包含刚才的Session-Sequence-Number也就是0.由server发送的响应里也应该有下一个Session-Sequence-Number。如果client发送过来的packet被成功接收，则server发送的响应里的Session-Sequence-Number的值就是0+1=1.
The Session-Sequence-Number must be the first header. The OBEX specification indicates that the
Connection-ID header must be the first header so there appears（出现了） to be conflict（矛盾）. Since the new reliable（可靠的） session features（功能） sit below the standard OBEX parser, the reliable session could be considered a lower layer protocol. Thus, session information should be stripped off（剥离） before being sent up（向上发送） to the OBEX parser. The standard OBEX parser will not see the Session-Sequence-Number header and the Connection ID header will appear to be the first header when it exists.
Session-Sequence-Number headers are not used in Session commands or responses. Thus, session
numbers are not advanced when sending session commands/responses when a reliable session is
active.
前面说过，The Session-Sequence-Number必须是第一个header。但OBEX规范了也指出了Connection-id header必须第一个header，所以这里就出现了矛盾。由于可靠的session功能位于标准OBEX解析器之下，可靠sessio功能被认为是下次的协议。因此，发送到OBEX解析层之前，要把session信息拿掉。所以标准OBEX解析器就不会看到Session-Sequence-Number header，就达到了Connection ID header是第一个header的规范要求。Session commands or responses不会使用Sequence-Number header。因此session number没有被提前，当发送session commands/responses时。
2.2.20 User Defined Headers
User defined headers allow complete flexibility for the application developer. Observe the use of the high
order two bits to specify encoding, so that implementations can skip unrecognized headers. Obviously（显然）you cannot count on user defined headers being interpreted correctly except by strict peers of your
application. So exercise due care（谨慎对待：exercise due care） at connect time before relying on these - the Who header can be used
at connect time to identify strict peers.
用于自定义header，给开发人员提供了最大的灵活性。要注意当使用自定义header时，高2位需要设置，以便具体的实现程序可以忽略无法识别的header。出了在有同样具体实现的设别上，你不能指望自己定义的header会被正确的解释。在连接的时间点，需要谨慎，需要配合who header来指出对方也是同样的实现。
c/c++ 学习互助QQ群：877684253
本人微信：xiaoshitou5854
