-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
On Sun, Jan 21, 2007 at 07:34:08PM +0000, Julian Mehnle wrote:
http://www.openspf.org/RFC_4408/Compliance_Logo
Please send your comments!
The "simple version" has a black border. It's probably because I'm a
bit tired right now: When moving my eyes from one side of the screen
to the other side, this border appears to flash a bit.
I don't know if this is a good thing (an eye catcher!) or a bad thing.
I cannot observe this effect right now.
The 'S' in SPF and the 't' in compliant touch the edge.
I don't like this.
That was actually on purpose. I'd like to read more comments on this!
Apart from that: Nice logo! Erm... I ment:
Nice stamp of approval. Stamps... mail... get it?
Heh. ;-)
I'd also like to get some comments on the wording of the circular text ("*
Conforms to RFC 4408 * Passes 2007.01 test-suite release *"). Is it good?
(I think I need to expand the kerning a bit in the lower half.)
What about the blue color?
BTW, don't forget there's also the regular logo[1], which hasn't been
transitioned to its own "Logo" page on the new website yet. (However, I'm
working on that right now.)
The eventual license is supposed to be a restrictive one, i.e. the
council would probably have to confirm an implementation's compliance
(either by itself or through some delegate) and then grant a specific
license to the maker of the software to use the logo in association
with the software.
For an indefinite amount of time; until the software changes or until
the SPF council revokes the license.
Assuming there isn't a new test suite release... I think once the imple-
mentation passes the current test suite, they should be able to keep using
the logo even with new implementation releases -- until the implementation
is found to no longer pass the test suite. We don't want to tie up the
council or the implementation makers with continuously re-certifying new
implementation releases.
I agree that the council should be able to revoke the license under certain
reasonable (i.e. not arbitrary) terms.
These restrictions are necessary to guaranty the stamp is and stays
valuable. Both the software and the test suite can evolve.
Software manufacturers will have to get a new approval every time they
update their software (within reason?)
It would be difficult to get a clear and consistent definition for that, so
I think we might just as well go for the most practical definition: as
soon as someone discovers they don't pass the claimed test suite release
anymore, they lose the logo (after having been explicitly notified by us).
Or can someone come up with another definition of "every time they update
their software" that is clear and consistent?
Should a major bug be found in the test suite, software will have to be
retested using the new test suite.
Certainly.
Of course, any implementation that applies SPF (v1) records to the email
body is bogus and should not receive the approval, no matter what the
outcome of testing it against a test suite is. Such an implementation
is not 4408 compliant!
This is an important point. Note that an RFC 4406/7 compliant implemen-
tation wouldn't strictly violate RFC 4408 because the latter only says
"NOT RECOMMENDED" in 2.4/2. What do others think?
References:
1. http://old.openspf.org/protectedbyspf.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFs9itwL7PKlBZWjsRAuVNAKCQVwMDZVbPB2lD9zg7g2Pn715mfwCgiOQv
iLoMj4X61OLESW8xeTbJjIw=
=ANA+
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735