OBEX and ISO8583

OBEX is a nice little protocol and reminds me a bit of a massively simplified version of ISO8583. It’s a pity about the warts on Connect…

The OBEX spec defines objects (messages) in terms of a fixed opCode, followed by a 2 byte length indicator followed by optional headers (fields). Each header identifier indicates both the type of header and the way that the length of the header is encoded. Everything in a message is a header - there’s a ‘body’ header for sending data…

So it’s all quite easy to parse. You start at the front of your byte buffer, pull off the opCode, grab the 2 byte length and you know if you have the whole packet. Then you start chomping your way through the headers, reading the single header identifier which tells you a) the type of the next header and b) how to work out how big it is.

So a PUT might look like this: 0x02 0x04 0x22 [headers]

The 0x02 is the PUT opCode. The 0x04 0x22 is the length of the packet and from then on it’s all headers…

Except Connect is different.

Connect looks like this: 0x80 0x00 0x07 *0x10 0x00 0x20 0x00* [headers].

0x80 is the opCode, the packet is 7 bytes long and then…

We have 4 bytes of extra stuff, we’ll call them warts, before the headers can start. The extra stuff is used to negotiate the connection, the first byte is the OBEX version number, the second is a ‘must be zero’ flag byte, the last two are a request for a max packet size. Why aren’t these pieces of information just headers like everything else? Suddenly we’ve gone from a nice, uniform, easy to parse, no special case, protocol to a situation where ‘if the first byte’s 0x80 then’…

And this for a saving of, say, 2 bytes. If all of the connection info were stored in a single header then we’d have 1 additional byte for the header identifier and another byte for the length. I don’t think it was worth the saving for the added code complexity.

I know it’s not a great deal of added complexity, but it’s enough and it’s unnecessary. It looks like someone who wasn’t in on the design of the spec from day one decided they needed some extra stuff in the connect packet and just shoved it in… Given that Connect is ‘optional’ and devices should work without having had a Connect sent it looks like the whole concept of the Connect packet was a late addition… This is how a design starts to decay.

A pity.