-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pekka Savola wrote:
There seem to be three options going forward:
1) make no changes to the spec. The spec (assumably) documents the
existing behaviour, even if it is conflicting.
2) make the spec to disallow that. The implementations are not
changed. The spec no longer documents the existing behaviour, and
the conflicts continue, but those who implement the spec aren't
allowed to say it's compliant (but no one is enforcing this in
any case, so....).
3) make the spec to disallow that. Someone convinces the
implementors to change their running code, and all the code is
actually changed.
Basically the IESG decided that accurate documentation of the running
code is more important than documenting something that does not exist,
and maybe never will exist.
As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was
submitted for experimental status, there was no "running code" that
actually interpreted "v=spf1" as "spf2.0/mfrom,pra". So what running code
was being documented when draft-lyon-senderid-core-00 was submitted?
Or does the fact that such running code has been created _since_ the draft
was submitted justify the treatment of that draft as "documenting running
code"? I hope that's not what you mean.
Julian.
References:
1. http://www.xyzzy.claranet.de/home/test/senderid-appeal.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDmYCpwL7PKlBZWjsRAtdOAKCFVUJ4mS47puF+ynoSiWDjFupdtQCgmpC0
NtY5lp+teMIiPiknQVUjTd0=
=YVek
-----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