Re: So here it is one year later...

In <[email protected]> Andrew Newton <[email protected]> writes:

> On Jan 28, 2005, at 2:20 PM, wayne wrote:
>
>> The problem is not that draft-schlitt-spf-00
>> changed things back, but that the IETF, via the MARID WG, allowed it
>> to change in the first place.
>
> This statement strikes me as particularly offensive.  If the intent
> was to have the IETF simply rubber-stamp SPF, making that clear up
> front would have saved us all a lot of time.

MARID never adopted/considered SPF.  When, at the interim meeting,
MARID assigned authors to create proposals, it was to create SenderID
with the use of the PRA.  At that point, all compatibility with
SPF-classic was basically thrown out the window.  Eventually, enough
people decided there were enough incompatibilities that it was decided
at the ietf-60(?) session that SenderID should use new records.  For
some strange reason, the IETF is now considering the SenderID drafts
that still use the same records.  Go figure.

I know of no one who asked or assumed that the IETF would rubber-stamp
SPF.  I did say, several times, that adopting an existing system would
be a much better idea than trying to create something from scratch.
Both DMP and RMX, for example, would have been a better choices than
SenderID because both had more testing done on them.  If MARID had
chosen to adopt either DMP or RMX, that would have been fine with me.


Now, back to message I was replying to, Doug talked about the
SPF-classic spec of draft-lentczner-spf-00.  Like all SPF specs, it
was never adopted by MARID.  The problem here is that Mark took the
drafts developed during MARID and tried to back-port them to be
SPF-classic drafts.  The advantage of doing this is that a great deal
of wordsmithing, in particular work done by Mark, had gone into the
MARID drafts and they were much better language wise.  Unfortunately,
they had the many semantic/algorithmic changes that the MARID group
made during the development of SenderID.

draft-schlitt-spf-classic-00 is an attempt to use the much better
language of the MARID drafts, but to restore functionality to match
what the install base of SPF systems is.  This draft also has removed
several features that are unused in the wild, and has more strict
error handling/checking added.


So, not rubber-stamping SPF wasn't a problem.  Creating a new spec
that changed the semantics of SPF records was.


-wayne