Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Julian Mehnle <[e-mail]>]

-----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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf