Hallam-Baker, Phillip [pbaker(_at_)verisign(_dot_)com] wrote:
The on change is the description of the version string which is wrong.
At present it says it relates to the spf version. It should say the
version of the spf policy syntax.
The reason for this is that we are likely to define new features for
spf at some time that mean it makes sense to talk about a 2.0 or 3.0
version with a whole lotta extra features. We want to have the option
of doing that without loosing backwards compatibility.
Hallam-Baker, Phillip [pbaker(_at_)verisign(_dot_)com] wrote:
How many protocols have you designed. I have worked on HTTP,
XKMS, SAML, WS-Security, WS-SecureConversation, about 6 others.
You are saying that "v=spf1" should designate the *syntax version* only. You
claim having worked on HTTP and other protocol specifications. Still, HTTP and
almost every other protocol *do* clearly state the *protocol (AKA semantics)
version* that is required to interpret the data at hand.
HTTP says "GET / HTTP/1.1". XML states the syntax version ('<?xml
version="1.0"?>') *and* the protocol version ('<!DOCTYPE ...>'). Even SMTP
explicitly states the semantics it supports, by declining the "EHLO" (as
opposed to "HELO") command with a "500 command not recognized" response if
necessary, or by listing the supported service extensions as a response to the
"EHLO" command, without ever bringing the other end into a situation where it
might have to make sense of undefined commands or parameters.
Not specifying the *protocol version* in SPF records would be a massive
mistake, as it would imply the need to cope with undefined or unclearly defined
semantics. "v=spf..." should primarily and explicitly designate the protocol
version, and implicitly the syntax version.
Expecting SPF *protocol version 1* clients to be able to operate on the same
"v=spf1" records as *protocol version 8* clients do is simply wrong. Not
because the grammar (what you call the syntax) will change -- it probably
won't! --, but because of undefined semantics. We couldn't even slightly
change (AKA fix) the semantics of any of the existing mechanisms without
renaming them!
Please define "extensibility" in the scope of SPF.
The ability to add directives. In particular the ability to add
directives of the type:
+domainkeys:_params accredit=class3.verisign.com
I don't think we want that kind of extensibility. Not particularly because
DomainKeys is bad, evil, or out-of-scope-for-SPF (maybe it is, maybe it isn't).
But because *protocol version 1* clients would have no clue how to interpret
that, and thus would have to do some non-educated guessing.
The RFC should explicitly forbid SPF clients to interpret/evaluate any
non-standard extensions, i.e. any unspecified (for the SPF protocol version
being used) mechanisms must be treated as errors. New SPF mechanisms must be
approved by a central authority, like an SPF working group, the SPF mailing
list, or even just Meng, and then be specified in a specific new protocol
version of SPF. Then domain owners may publish new records, and SPF clients
may start evaluating these.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)���v¼����ߴ� �1I�-�Fqx(_dot_)com