A lot of debate lately has been around syntax: XML or SPF-syntax? I think it's pretty clear that the vast majority of us don't want XML, but there are some important points being brought up by the pro-XML faction.
Personally, I think XML debate isn't really about syntax, but about extensibility. The XML *syntax* by its very definition is extensible. In general, *semantics* based on the XML syntax ignore unknown tokens, parameters, and blocks. However, if you took the most recent SPF RFC (2004-04) and did a drop-in replacement of the SPF-syntax with an equivalent XML syntax, SPF still would not be extensible. It would just be ugly and cumbersome.
Why? Because of SPF *semantics*:
>3.2 SPF Directive Evaluation
> There are two types of directives: mechanisms and modifiers. A given
> mechanism type may always appear multiple times in a record.
> Modifiers may be constrained to appear at most once per record,
> depending on the definition of the modifier. Unknown mechanisms
> cause processing to abort with the result "unknown". Unknown
> modifiers are ignored by clients.
> ...
>4.2 "include"
> ...
> This mechanism matches when the inner, included query result returns
> a pass, and doesn't match when the result is fail, softfail, or
> neutral. However, if the new query returns none, error, or unknown,
> then processing of the entire SPF query stops immediately and
> returns the error result.
> ...
I'm sure there are plenty of other sections I could quote, but this gives you the general idea. Aborting all processing on errors/unknowns kills extensibility.
SPF is basically designed with a "frozen" mentality. This makes it stable, easy to understand and implement, and uniformly practiced, but requires a new version (v=spf2 instead of v=spf1) to add new features, and is less flexible about dealing with ambiguous error situations. (Modifiers could be used to work around this, but it would be a hack.)
If we want SPF to be extensible, we don't need XML, we need to change the semantics of SPF to deal with and trap unrecognized mechanisms and errors.
Greg Connor recently went into great lengths about this, but it was generally ignored during all the recent CID hoopla. I suggest everyone re-read his posting:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0275.html
Including better error handling would also allow Lars Dybdahl to have his include's work the way he wants:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0081.html
(follow the threads that include the subject "Recursion limit of 20 include/redirects total")
I would like to add that I am fairly ambivalent about the whole extensibility issue. SPF works fine for me the way it is, and will for the foreseeable future, but I can see how some people feel like it is important.
A hidden problem with extensibility is the fact that non-uniform practices can emerge and multiple competing mechanisms might fight for dominance. With a frozen spec, things are a lot more predictable because new mechanisms are released uniformly with new versions.
Michael R. Brumm
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Personally, I think XML debate isn't really about syntax, but about extensibility. The XML *syntax* by its very definition is extensible. In general, *semantics* based on the XML syntax ignore unknown tokens, parameters, and blocks. However, if you took the most recent SPF RFC (2004-04) and did a drop-in replacement of the SPF-syntax with an equivalent XML syntax, SPF still would not be extensible. It would just be ugly and cumbersome.
Why? Because of SPF *semantics*:
>3.2 SPF Directive Evaluation
> There are two types of directives: mechanisms and modifiers. A given
> mechanism type may always appear multiple times in a record.
> Modifiers may be constrained to appear at most once per record,
> depending on the definition of the modifier. Unknown mechanisms
> cause processing to abort with the result "unknown". Unknown
> modifiers are ignored by clients.
> ...
>4.2 "include"
> ...
> This mechanism matches when the inner, included query result returns
> a pass, and doesn't match when the result is fail, softfail, or
> neutral. However, if the new query returns none, error, or unknown,
> then processing of the entire SPF query stops immediately and
> returns the error result.
> ...
I'm sure there are plenty of other sections I could quote, but this gives you the general idea. Aborting all processing on errors/unknowns kills extensibility.
SPF is basically designed with a "frozen" mentality. This makes it stable, easy to understand and implement, and uniformly practiced, but requires a new version (v=spf2 instead of v=spf1) to add new features, and is less flexible about dealing with ambiguous error situations. (Modifiers could be used to work around this, but it would be a hack.)
If we want SPF to be extensible, we don't need XML, we need to change the semantics of SPF to deal with and trap unrecognized mechanisms and errors.
Greg Connor recently went into great lengths about this, but it was generally ignored during all the recent CID hoopla. I suggest everyone re-read his posting:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0275.html
Including better error handling would also allow Lars Dybdahl to have his include's work the way he wants:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0081.html
(follow the threads that include the subject "Recursion limit of 20 include/redirects total")
I would like to add that I am fairly ambivalent about the whole extensibility issue. SPF works fine for me the way it is, and will for the foreseeable future, but I can see how some people feel like it is important.
A hidden problem with extensibility is the fact that non-uniform practices can emerge and multiple competing mechanisms might fight for dominance. With a frozen spec, things are a lot more predictable because new mechanisms are released uniformly with new versions.
Michael R. Brumm
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com