Mark Shewmaker wrote:
if we just waited two years, the problem will go away on its
own, if we're reading the implications in the wording of the
previous appeal correctly.
At least two IFs, if we read it correctly + if we manage to get
a PS in 2007. As an IAB ruling about this issue it would be
one IF less.
that's just looking at the technical aspects, as if we can
safely assume there are no other political forces going on
that could cause the issue of how the drafts could be
elevated to proposed standard to become moot.
As long as Mr. Hardie is in the IESG he cannot be in the IAB,
that won't change before 2007, enough said.
So to me the main question is whether having that conflict
remain throughout the two-year experimental stage would be
harmful to SPF,
If Doug posts his visions on the ASRG list I can refute them:
<http://permalink.gmane.org/gmane.ietf.asrg/11286>
Wayne often did this in many (from my POV obscure) places like
Circle-ID (sp?) or Andy's blog, but "we" can't be everywhere.
FUD about SPF is in the commercial (= political) interests of
many parties. Funny, but Redmond would be probably not at all
interested in FUD about SPF (as long as they believe in PRA).
for which standard is the RFC (experimental) blessing more
important?
Pointing to a RfC number is important, because the blurb about
"approved draft waiting for its number" is something that only
IETF-insiders accept as good enough. And only IETF-insiders
are guaranteed to know that "experimental" isn't much at all.
it might mean Microsoft could put SenderID functionality in
a newer version of exchange as default behavior and point to
an (experimental) RFC allowing it, and the conflict--thus
opening a can of worms, as SenderID has inherent problems of
its own in addition to the problems related to the re-use
conflict between SPF and SenderID.
They could - I don't see why they should be forced to wait for
the number of an approved experimental RfC.
###Begin conspiracy alert
[...]
we've all been assuming that Microsoft truely wants SenderID
to succeed. I think we should at least consider the opposite
from time to time,
The third E in EEE, yes. But that would be rather odd, unless
they have a product in mind that's not PRA (like say DKIM).
In that case, they would have a reason to try to slow down
SPF deployment. One way of doing that would be to confuse
the market with a competing, inferior solution.
The standard question about conspiracy theories: Could it be
also explained by mere (here technical) stupidity ? IMHO they
are not really our "enemy", they just want all those thousands
of published v=spf1 policies for PRA, and don't care about the
technical issues,..
some rationale for otherwise seemingly pointless behavior.
...anything is possible, and there are some "real" SPF enemies,
but I wouldn't start in Redmond in an attempt to find them.
Some of the "SPF enemies" are rather nice guys, you could find
them on some IETF lists... ;-) And we DID want a "last call".
Bye, Frank
P.S.: One ring to find them, one ring to bind them... <eg>
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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