| Who was it that said "The nice thing about standards is that there are so many to choose from"?
Anyone who's ever read an RFC, or worse yet, tried to follow one when implementing a "standard" knows what I mean...
I'm in a Network Programming course, and we have to implement clients and servers for finger, DNS (caching), integrated WINS-dns, and whatever other protocol spawned from the committee mind of the IETF. It's a neat class, but trying to implement standards is like nailing jello to a wall. It's a neat trick if you can get it to work, and keep on working for any length of time.
Don't get me wrong, I'm all for the wonderful anarchy that is the IETF, but a few guidelines for writing RFC's wouldn't hurt:
- Specify all of your protocol as completely as possible, do not leave out something "trivial", like the token compression scheme for DNS names.
- If part of your RFC is ambiguous, rewrite it, or add more detail. Brevity is the soul of wit, but you'll be at your wit's end when you try to figure out whether the /W option to finger is supposed to be upper or lower case and the RFC is mute on the subject.
- If your protocol doesn't play well with others, and returns inconsistent results, or fails to return anything for a given situation when it really should (e.g., is the DNS server ignoring me, or is it still working, or is it non-authoritative?), consider adding a return type to cover your ass.
- I'm sure there's more, but I'm tired...
</rant> | 
