-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
Julian Mehnle <julian(_at_)mehnle(_dot_)net> writes:
We should examine the wording of that IESG note...
| [snip] Participants publishing SPF experiment DNS records should
| consider the advice given in section 3.4 of RFC XXXX (draft-lyon-
| senderid-core) and may wish to publish both v=spf1 and v=spf2.0
| records to avoid the conflict.
Did anyone notice that they said "v=spf2.0"? Oh my. Is that the best they
could come up with after almost four months since the appeal was filed?
After all, none the IESG notes accounts for the fact that "the SPF
experiment" was there _way_before_ "the Sender ID experiment" was.
Also I don't think the SPF RFC referring to the Sender ID RFC
("section 3.4 of RFC XXXX") is appropriate.
From the IESG's point of view, this is the only appropriate solution.
They are approving both SPF and SenderID, and so a note needs to be
made in the SPF spec about the conflict.
I already said that I can see the value of such a note. But you missed my
point. The note tries very hard to be "vendor neutral", without noticing
that such a kind of neutrality isn't actually appropriate here. I had
explicitly made it a point of my appeal that Sender ID had never tried to
interfere with "v=spf1" records _until_ after MARID was dissolved and the
IESG asked for individual submissions from Microsoft and us:
| It is also worth noting that at the time the MARID WG was closed, the
| then-current Sender ID specification draft-ietf-marid-protocol-03 did not
| include the re-use of "v=spf1" records for PRA checking. This was only
| introduced in the individual submission draft-lyon-senderid-core-00 in
| October 2004. Also did Microsoft's record generation wizards generate
| only "v=spf2.0/pra" records until the end of October, when they began
| generating only "v=spf1" records.
But the IESG chose to ignore that fact.
And finally, should we consider letting the SPF spec be formalized by
some other, more serious standards body, such as the Open Group? (I
think there was an offer by them to publish the SPF spec.)
I highly doubt that any other standards body is going to be more
vendor neutral.
See above for my view on "vendor neutrality" in this particular case.
Besides, I doubt that Microsoft is going to seek standardization of Sender
ID through some other standardization body. (It just wouldn't be of much
use to them, just as _not_ having a standards track RFC doesn't really
hurt them.) So "vendor neutrality" wouldn't be an issue for us.
For what it is worth, I will not approve of an appeal to the IAB.
That doesn't stop people from filing appeals, but I see very little
chance of anything positive happening from it and I think it will just
waste more time.
It's not as if we required an RFC number anytime soon to achieve
significant adoption. Remember that we managed to get where we are now
even _without_ an RFC number.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDmDu/wL7PKlBZWjsRAg+pAKCVSFLAiwoGsG04XMwOk587gk6dhACgvpMo
F31CGOrSD6Qi9Ai055c5KHQ=
=ZLOj
-----END PGP SIGNATURE-----
-------
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