Damon wrote:
Take your pick:
http://thesaurus.reference.com/browse/exception
I don't have a problem with "exception" in this case. I believe that
it describes what is happening accurately.
I think that will all depends on who is reading it.
To me, an exception is not an ordinary event that one expected. Since I
believe SSP is just validating the expected signing behavior as
described by the domain, it is either a TRUE or FALSE condition - no
exception.
Checking for NXDOMAIN is a safe result to check for. Checking to see if
its a given POLICY matches what is actually shown in the message, is a
safe result to check for. I don't see those as exceptions.
Now, if one can't make heads or tails of a SSP check, then maybe that
can be viewed as an exception - because something happen you didn't expect.
Here's the thing: The fact you and others had to look it up, means a
lot here. Most people are not going to be wanting to have their
dictionary or thesaurus around when they read these RFCs. The fact
there are a "take your pick" untold semantics for exception tells ya it
will probably cause one to scratch their head than now.
I say being "Specific is Terrific!"
As Frank suggested, PASS or FAIL is just as good. Most people don't
need a dictionary for that.
I suggested SSP Complete, maybe good if you understand 5016.
I also suggested negative/positive classification, and this has a
industry wide understanding and it is already in place for this type of
work. SMTP uses positive/negative response code and classifications
ideas. Spam Assassin already uses positive/negative classification as
well as other heuristic based systems. Odds are good you will find more
neural networks or fuzzy logic systems play a role, if not already.
Jim's non-compliant/compliant is also straight to the point. But not
sure it helps in laying the ground work to handling results.
While "exception" can work for me personal, I don't see it as a good
candidate for replacing suspicious. We might as will say "SSP Fault"
or "SSP Failure".
My pennies of course.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html