Fun times with RFCs -- was Re: Wireless Masochism
C. Ed Felt
edfelt at gmail.com
Sat Jul 9 14:37:09 MDT 2005
There is no way I would have been able to build all the billing systems
and troubleshoot hardware/proxies for my VoIP company without the SIP RFC.
Michael Halcrow wrote:
>On Tue, Jul 05, 2005 at 03:56:32PM -0600, Michael L Torrie wrote:
>>On Tue, 2005-07-05 at 15:48 -0600, Gabriel Gunderson wrote:
>>>On Tue, 2005-07-05 at 15:40 -0600, Mitch Anderson wrote:
>>>>RFC 2136 explains it fully
>>>This is bad. We have gone from "RTFM (Read The Fine Manual)" to
>>>"RTRFC (Read The RFC)".
>>Having spent many hours reading the RFCs defining the LDAPv3 wire
>>protocol, and then implementing C code to speak the said protocol, I
>>can say that RFCs are actually not that hard to read and do contain
>>a wealth of information.
>I second that. A good RFC is accurate, concise, and clear -- and the
>majority of RFC's are good. I followed RFC 2440 closely when
>Of course, I had to deviate from the RFC in order to accommodate
>random access patterns in a POSIX filesystem, but the underlying file
>formats are not that far from what can be understood by existing tools
>like GnuPG. This will make it significantly easier to write userspace
>tools to enable userspace-only access to the encrypted files.
>Whenever you want to understand a protocol, format, or process, you
>just can't beat an RFC. And I tend to recommend sticking to RFC's as
>closely as possible whenever you develop new technology; the issues
>represented in RFC's have been thoroughly investigated by a lot of
>people are are probably smarter and more experienced than you are.
> Michael A. Halcrow
> Security Software Engineer, IBM Linux Technology Center
>GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769
>Why isn't there some cheap and easy way to prove how much she means
>| This has been a P.L.U.G. mailing. |
>| Don't Fear the Penguin. |
>| IRC: #utah at irc.freenode.net |
More information about the PLUG