Fun times with RFCs -- was Re: Wireless Masochism
mike at halcrow.us
Fri Jul 8 10:34:26 MDT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 481 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050708/61387f97/attachment.bin
More information about the PLUG