The upper layer can trivially ensure that the buffer contains X bytes
of data, where X is large enough to hold at least a two byte attribute
name and a two byte value length. Once the lengths are known then
the proper amount for values is easy to collect.
With an ASCII encoding the upper layer has to guess, or check for
proper terminators.
>buffers seems rather messy to me because the break can occur during any
>element. It sees like a good place to generate lots of occasional bugs.
Yes, except with binary it is not messy at all.
>putting a " " (space character) just after the last character in the
>buffer to stop the scan-for-space algorithm.
That would work, if you must scan.
>You also observed that with CRLF and a maximum line length, it is easy
>to ensure that a buffer has a full unit because functions, such as fgets
>read upto the next CRLF. Perhaps we need to revisit the solution that
Unless you have to interoperate with implementations that visually
checked (instead of looking at a sniffer hex dump) for "lines". Like
with HTTP servers today, even though the spec reads CRLF you still
find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't
be suprised to find some LFCR's out there).
> CR in a value is represented by =0C
> LF in a value is represented by =0A
> = in a value is represented by =3D
You will probably need to escape anything less than %x20 and perhaps
anything greater than %x7E.
In fact, instead of developing our own escape rules we should, as you
probably did, just pick one.
This is just so ugly, considering the purpose is for two computers to
talk to each other over a link that is 8-bit clean.
>Perhaps this pure textual solution is easier to program once you consider
>the buffer problem.
I don't find it so.
sdb
| Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |