Re: [IETF] Allocation of the new RR type for SPF

wayne wrote:

> Also, because many languages don't deal well with binary structures 
> (e.g. perl, python, etc.), SPF implementations in those languages 
> would actually be slightly more complicated.
I don't know about Perl, but Python has no problem with binary 
structures.  It parses both network and native C structures.  The basic 
paradigm is to 'unpack' the binary record into a Python tuple (which has 
an arbitrary tree structure), and then to 'pack' tuples into binary 
records.  Unpacking and repacking the entire record to change a bit 
might be considered inefficient by C standards - but it fits well with 
an interpreter (the [un]packing being done by native code).  Changing 
bit fields at arbitrary offets in bit arrays or char arrays is trivial 
also, and appropriate for fixed width layouts (e.g. C struct).
However, as someone else has mentioned, I'm not sure we want to make 
bind include an SPF parser.  Perhaps the binary form could be optional.  
The text form would start with 'v=spf1' or 'spf2.0', but the binary form 
would start with a non-ascii magic number.  Then, DNS servers could 
include an SPF parser or not.  That would put the burden on SPF clients 
to be able to parse the binary form if they want to use those records.  
I already have a bad feeling about that suggestion, but perhaps it will 
inspire a better one from someone else.