-----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----- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf