In <00a401c5798a$c6d36e40$6401a8c0(_at_)hdev1> "Hector Santos"
<spf-discuss(_at_)winserver(_dot_)com> writes:
Concerns:
[snip]
In my review of teh senderid-core I-D, I found these concerns:
* senderid is trademarked by someone in the UK
* Many sections of the senderid-core spec are very similar to sections
in the spf-classic spec. This causes the following problems:
* It isn't clear what is different between these two specs
* It isn't clear if the differences are intentional, or why they are
different.
* There are various changes in semantics between SenderID and
SPF-classic, making a system that implements both much more
complicated than you might initially guess.
* The changes in semantics are not restricted to interpretation of
SPF2.0 records, so SPFv1 records referenced by SPFv2 records cause
SPFv1 records to be interpreted by the new/conflicting semantics.
* The combined senderid-core, senderid-pra and senderid-submitter
drafts come in around 2k lines. spf-classic is 3k lines. So, the
SenderID spec is almost twice as big as SPF, and all to just add the
PRA scope.
* The current senderid drafts make references to stuff that is bogus,
and it will have to either change semantics of senderid during the
"RFC Editor review" pahse. For example, senderid-core talks about
needing to do zone cuts and references sections in spf-classic that
are not correct.
Either senderid is going to have to change semantics, and thus run
through the IESG again, or senderid is going to end up being a very
broken spec. (Or, at least that is my interpretation of what the
RFC editor requires if "technical problems" are found.)
* A great deal of work has gone into making spf-classic-02 to be as
compatible as possible with previous SPF specifications. The
SenderID specs, however, have had their semantics change from the
MARID days and may well need to change some more. SenderID is "in
flux", while SPF-classic is as stable as we can make it.
-wayne