In <42936CBD(_dot_)3697(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
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.
Andy said "I will consult with the PTB to verify this." (PTB ==
"Powers That Be"?) He then came back with their ruling. So, this
does not appear to be a decision made by the WG chair.
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:
It might be a good idea to just ask. I confess that I haven't asked
since early January.
* 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 ?
There isn't a spf2.0/mfrom document either. When the senderid-core
I-D referenced the senderid-protocol and senderid-mfrom I-Ds, this
wasn't much of a problem, but now that it references spf-classic,
there is potential for confusion.
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.
Well, I guess all SPFv2 records should be affected, not just 2.0.
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>
I was pointing out problems that the IESG should know about before they
finish the current, ongoing voting to approve publication of these
drafts. Yes, it is perfectly understandable, but that doesn't mean
it doesn't need to be fixed before publication.
-wayne