IrDA OBEX protocol weirdness

Besides the slightly odd way of describing packets as consisting only of headers, and that the body is in fact one of the headers and not something that is “headed”, I’ve noticed a thing that perhaps isn’t an issue when implementing the protocol in a function-oriented language, but which is indeed an issue for object-oriented implementations.

Responses are equivalent to requests, in that they consist of a response code (which is called opcode for requests) followed by a 16-bit packet length and zero or more headers. The answer to any request is normally SUCCESS, or CONTINUE if you transfer an object larger than the maximum packet size.

The first thing you do is to establish a session, which is done by sending a CONNECT package and the response for this request is, if successful, SUCCESS. However, this isn’t a regular packet—besides the response code, length and headers, there’s an OBEX protocol version number, eight flag bits and a 16-bit value representing the maximum packet size the entity on the other end can handle.

So, this means that if your program is supposed to “guess” which object to create from the stream of data received: the class of the object would be different depending on context! If you have sent a CONNECT packet, you must expect a special SUCCESS packet, with data that appears where the headers should be, but doesn’t follow the header format of header identifier-header value.

In my opinion, making the packet classes aware of the context where they are used is TOTALLY unacceptable. You could solve this with some ugly workaround—for example by creating a header that have no correlation with the protocol specification, with an identifier of 0×10, which actually represents the version number 1.0 and a 24-bit value (flags and maximum packet size). But I don’t like doing things like that.