> -If the protocol is going to be read by a program then the encodings are
> just 'magic numbers' regardless of text or binary. We could choose the
> number '42' to mean 'copies' or we could choose numbers 'COPIES' to mean
> copies just so long as we (the implementors) all agree.
>
One of the things that is affected by this choice is the extension
mechanism. Suppose I want to try out a new feature. I'll do it
privately, and then I want to register it and make it public. If
I just pick a number, '43', I'm likely to hit someone else's number.
So maybe I'll use a number out of the private extension space, e.g.,
'123451'. But then when I change from 'private extension' to
'public', I have to go back and recompile all my test code.
With strings, I can pick a string that isn't used by anyone now,
and most likely won't have to change it by the time I register it.
This sounds pretty sloppy, but it's mainly what's done now for
many protocols and it's much more robust than numbers.
The protocol strings aren't human-language, they're just close enough to
language to believe that they're extensible in a more distributed
fashion.
In addition, the debugging and testing aspects shouldn't be ignored;
it's useful to be able to write a test program in a scripting language
or even to telnet to port 80 at a host and just type "GET url HTTP/1.0"
without having to count bytes.
Larry
--
http://www.parc.xerox.com/masinter