views:

44

answers:

3

I am writing technical documentation for a little protocol used internally on a GSM network. This protocol use pattern [id1] + [byte[] data1], [id2] + [byte[] data2], etc in a continuous stream of byte.

The point is that for various reason (future expandability and backward compatibility) some fields are not used. The value of this fields are choice of who implement the protocol (and at the moment the default value come from the language/framework used to implement the protocol, i.e. the default value for byte array elements).

Now the question. It is useful in some way to impose a default value for unused fields?

A: 

The advantage, if any, would lie in future versions of the protocol where the fields are used. A default "bad" value would let the receiver determine that an older version of the protocol is being used.

Pesto
A: 

In general, I'll say "yes". Having specified default and fill values allows you to make changes to your protocol in the future that are based on the existing fill values. If you cannot depend on what bytes are on the wire now, then there is no good way to enforce a structure on those bytes in the future. Not to mention, it is generally a bad idea to allow "implementation dependent values" leak into a binary specification. This is how I ended up with 8-byte padding and Intel-ordered IP addresses in "on the wire" structures.

D.Shawley
A: 

It is generally a good idea to specify the value of unused fields as follows: - The sender MUST set the field to zero - The receiver MUST ignore the field

That way, at some future point in time you can choose to use the field for some new feature. When you do so, all you have to do for backward compatibility is to define value 0 of the field to mean "the old behavior prior to the introduction of the new feature.

(Actually, it is also a good idea to introduce some form of capability announcement which allows to one side to discover whether or not the other side supports the feature, in other words whether the other side will be able to understand non-zero values for the field.)

Cayle Spandon