wayne wrote:
Ted's insistence that the SPF-classic I-D I'm working is a
MARID I-D
That's nonsense, there are no more "MARID I-Ds" after MARID
was closed. A closed WG cannot produce drafts.
The CSV folks kept draft-ietf-marid-* as document titles, and
Dave explained this confusion on the general IETF list.
it was decided that the risks to the ISOC and IETF standards
publishing process was too great and therefore the term
should not be used.
Harry, Jim, and Meng are not bound by former decisions of a
closed WG, the same is true for say Meng, Wayne, and William.
I would be shocked if the DEA set up to review these I-Ds
wasn't aware of this issue.
I would be shocked by finding out who this "DEA dir" is, it's
already the stuff for _substantiated_ "conspiracy" theories:
<http://www.circleid.com/article/905_0_1_0_C>
The former ASRG cochair doesn't strike me as phantast.
* There is no support for the HELO identity checking in
SPF2.0 records like there is in v=spf1 records. There
is no mention of why this option is not allowed.
Maybe because there's yet no sp2.0/helo document ?
In section 3.3 of senderid-core makes creates the concept of
"positional modifiers", something that SPFv1 lacks. However,
this change in semantics is not restricted to only spf2.0
records.
What other records should it affect, spf2.1 ? Certainly not
v=spf1, this idea is unfortunately incompatible with v=spf1.
In section 3.4 of senderid-core says that SPFv1 records
SHOULD be interpreted as equivalent to "spf2.0/mfrom,pra"
This is wrong since v=spf1 was never designed with the PRA
scope in mind, causing incorrect results and damaging the
deployment of SPFv1.
Yes, this will never fly. It would go to the IAB, to the
press, to the general list, and then I'd start to examine all
legal options. Admittedly I hope I won't be alone with this.
Section 4.4 of senderid-core still makes references to zone
cuts in spf-classic, but zone cuts have been removed from
spf-classic.
In theory after these drafts. OTOH Meng was at the Council
meeting where you decided this unanimously. Again OTOH maybe
they didn't know how long it will take to update draft -00,
and that's perfectly understandable, isn't it ? <eg>
neither draft-lentczner-spf-00 nor the
draft-schlitt-spf-classic-01 I-Ds were written with the
intent that they would be used by the draft-ietf-marid-*
They are perfectly entitled to do it anyway if they like these
drafts as base for their stuff. They only can't use PRA on any
v=spf1 policy. Of course they should get the differences
right.
Bye, Frank