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.

Regards,
Damon Sauer

On Dec 17, 2007 1:00 PM, Michael Thomas <[EMAIL PROTECTED]> wrote:
>
> Jim Fenton wrote:
> > Michael Thomas wrote:
> >> Dave Crocker wrote:
> >>>
> >>> Jon Callas wrote:
> >>>>> Dave Crocker wrote:
> >>>>>> With the use of language like "suspicious", SSP is making value
> >>>>>> judgement on messages that do not satisfy SSP's criteria, even
> >>>>>> though those message well might be entirely legitimate.
> >>> ...
> >>>> How about something like "SSP Exception"? Metaphorically, it works
> >>>> well with the programming use of the word exception.
> >>>
> >>> Folks,
> >>>
> >>> In the hope of trying to close some of the "easy" Issues, would folks
> >>> comment on this specific proposal, or otherwise post comments seeking
> >>> closure of the Issue?
> >> My suggestion is to just to take the exception/violation reason. For
> >> example, "all-exception", "strict-exception", "nxdomain-exception"
> >> and the like. A single word even if it's value-neutral gives the wrong
> >> impression that all exceptions/violations/suspicion should be given
> >> the same weight. Just saying what it is that went wrong doesn't
> >> do that.
> >
> > +0.5
> >
> > Agree that a name change is in order, and that we need more than a
> > binary 1/0 result.
> >
> > But "exception" makes it sound like a kernel panic or something.  Hector
> > had some alternative interpretations of "exception" too.  My
> > suggestion:  "non-compliant"/"compliant".
>
>    My original suggestion was "violation" which still works with nxdomain
>    and other states. I could live with exception though.
>
>                 Mike
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to