spf-discuss
[Top] [All Lists]

Re: Scope macro, alternative syntaxes, and use cases

2004-07-07 08:37:52
On Tue, 2004-07-06 at 10:03, wayne wrote:
In <000701c46326$bc0185e0$01030101(_at_)pamho(_dot_)net> "Roger Moser" 
<roger_moser_spf(_at_)greenmail(_dot_)ch> writes:

Mark Lentczner wrote:

Several alternative syntaxes have been proposed that would make such a
thing simpler, and fit in only one record.  Indeed, we thought of some
too.  We rejected them because, for better or worse, SPF is actually
deployed and we are wary of changes to the syntax that will break
existing parsers.  Success has its downsides!

Using modifiers does not change the syntax and will not break existing
parsers.

Nothing in the current SPF draft says that modifiers can be position
dependant, and there are a couple of references to how they should be
placed at the end.  (e.g., the are position independant.)

Both the M:S:Q and libspf2 (aka libspf-alt) implemenations throw all
the modifiers into a seperate bin and only look for them when needed.
Allowing position dependant modifiers would require some changes.
Also, Hector Santos mentioned on the MARID list that his software
(which is out in the field) is based off an earlier SPF draft that
*required* modifiers to be at the end.

So, using position dependant modifiers is not a problem-free option.

Whats wrong with change?  libSPF (aka would the Real libSPF please stand
up, please stand up) parses by tokenizing from left to right, and we're
fast because we don't have to pre-parse to validate since thats easily
facilitated during our initial read.  It would be trivial to add
position dependant macros to libSPF -- in fact, it seems to me it would
be trivial to add it to MSQ and the library masquerading under someone
else's name, with modifiers in a bin or not.

I like Seth's idea and I think he raises some valid points.  Since some
underhanded individual was kind enough to kick the SPF1 spec off the
table (hmmmmm?) and the farce that is SPF2 is well, just that a farce, I
think we would be kicking our selves down the road if we were not to
take advantage of this opportunity, regardless of who brought it up.  

I am close to your stance (Wayne) that it really is high time that we
locked things down, but Seth is right when he states that what we have
just isn't good enough yet, and since the cook is still in the kitchen,
the bartender still behind the bar, I think we should order up!

Cheers,

James

-- 
James Couzens,
Programmer
-----------------------------------------------------------------
XML is WRONG, and here it doesn't BELONG.
Neither in SPF, nor inside of DNS,
its fat and its bloated and so I express:
JSON - "The FAT FREE alternative to XML"
http://www.crockford.com/JSON/xml.html
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money!  http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

Attachment: signature.asc
Description: This is a digitally signed message part