nobody at xyzzy
Mar 19, 2008, 2:58 AM
Post #5 of 5
(419 views)
Permalink
|
Stuart D. Gathman wrote:
> An official evaluation of experience with the "experimental" RFC.
Yes...
> Neither really requires a council at this point, however.
...I somehow doubt that the relevant IETF area directors would be
impressed by a "hat on" statement on behalf of the SPF Council ;-)
It could be nice to pull this as a kind of joke, or to send mails
in the form of a "liaison statement", but in practice I think the
IETF procedures are interesting enough, trying to make them more
interesting on the side of the SPF community likely won't help.
After all this list now is an IETF "other list", JFTR for those
who missed it, posters here are a part of the IETF community, as
far as that means something from their POV (and for me it means
a lot).
As far as "dispute resolutions" go, I tested this with an old SPF
Council, Julian tested it with the IAB for "us", in both cases
the effect was to get an answer to a question, and not exactly
the answer we hoped for.
IMO more important, has anybody here read ID.ellermann-spf-eai ?
Do you like the technical detail where I propose to deprecate
spf2.0/mfrom, spf2.0/mfrom,pra, and spf2.0/pra,mfrom in favour
of using v=spf1 and spf2.0/pra explicitly with a SHOULD ?
One thing a draft desperately needs before even thinking about
a "publication request" is reviews and contributions. Did you
see that ID.kucherawy-sender-auth-header has SPF as v=spf1 vs.
PRA as SenderID as clear as possible, and no "mfrom" nonsense ?
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
|
