I have developed a protocol for a Client-Server application and developed it in conjunction with another developer. The client application at this moment is written for the mobile phone.
The protocol uses comma separated fields with start and end deliminators. Because some of our fields are free form ASCII text we are byte stuffing the fields so that special characters can be handled within and not mess up our data parsing.
The problem is that one field has been byte stuffed when it shouldn't have been. The field in question was to represent coordinates i.e.
<rest of data packet>, <lat>,<lng>,....
where
<lat>: Latitude coordiantes i.e. -37.6543
<lng>: Longtitude i.e. 90.8993
However what we I recieved on the server was the byte stuffed character for a comma appearing in the dot field i.e. -37^-6543. This in turn caused the server to ignore the packet and not record the details.
Reason: When I mentioned this to the phone developer he said it was because the character settings on the phone meant that the user had changed the dot to a comma. It was his belief that we should handle this on the server. However I'm not sure. I have a thought that clients should follow the protocol as in theory there could be different clients connecting and the server doesn't want to have special cases littered in it's code base?
Question: So some options I see are (and I'm not sure how to approach this):
- Get all clients to send the data as per for the protocol spec and keep the data format black and white so to speak
- Have the server handle a variety of options in this case
- In conjunction with 2 adjust the protocol document so that data is more flexible in some cases and the server is responsible for handling the different cases