Splitting off another further different topic.
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Sunday, April 11, 2004 6:35 AM
To: IETF MXCOMP
Subject: Re: Microsoft submitting Caller ID as draft RFC
[snip]
5. Extensibility: [sniped]
I agree that extensibility is important.
SPF allows extensibility via modifiers, I think that that
most of the other LMAP proposals either have, or could have,
similar extensibility.
If I understand section 6.1 of the SPF spec correctly, an SPF receiver
must abort evaluation if any unrecognized mechanisms are encountered.
This means in practice a sending domain loses the protection of it's SPF
record whenever it adds a new mechanism unless the receiving domain
understands that new mechanism. This is a significant barrier to the
adoption of any new mechanisms that might be introduced. In effect
sending domains have to wait until substantially all receiving domains
have upgraded their software to support the new mechanism -- and how
would they know this? -- until they add the new mechanism to their SPF
record.
Pragmatically speaking, this means that no new SPF mechanisms will be
successfully introduced ever. I'm curious why this approach was taken.
[list of examples]
All of these can be done via SPF modifiers.
How does SPF deal with possible naming collisions of modifiers? The XML
approach is to use versioned namespace prefixes. This allows new
elements or attributes to be added by either a central coordinating
authority, e.g. IETF, or by individual organizations or groups
coordinating on an ad hoc basis. This is all standard XML usage.