On 6/2/10 10:10 AM, Scott Kitterman wrote:
"Dave CROCKER"<dhc(_at_)dcrocker(_dot_)net> wrote:
On 6/2/2010 8:08 AM, Al Iverson wrote:
Agree. "Discard" and "silently discard" mean the same thing, in my
opinion. Though, I am guilty of using the phrase "silently discard."
Maybe in an attempt to be slightly over-specific.
I do not recall seeing a dictionary or technical definition of "discard" that
says anything at all about whether the discarder says anything at all.
Taken on its own and without further technical specifications 'discard' does
not
direct, imply or request that the action be silent or noisy, and if noisy who
gets to hear it.
IIRC, this is by design since there was no consensus around what exactly to
do. Personally, I tend to favor not having messages silently vanish.
The initial intent was to assert signing domain's policies rather than
attempting any receiver recommendations. In this vein, a better an
alternative to "discardable" could have been
"no-third-party-services-used" such as N3PS. The "discardable"
assertion did not emerge directly from the list. John explained
"discardable" as his response to phished domain's concerns of being
flooded with NDNs. ADSP did not produce a flood, as seen by the
phisher's reactions of avoiding exact matches.
Rather than asserting author domain signing policies, ADSP could be
changed into offering receiver recommendations, which "discardable"
attempts. Perhaps "all" could change to "non-deliverable". However,
could this result in bounces, in addition to rejections. After all, not
all receivers evaluate DKIM prior to acceptance. Should these
recommendation be "rejectable" and remain silent about accepted
messages? To avoid this quagmire, the WG concluded that ADSP was to
state the domain's signing policy. Clearly, "discardable" represents a
clear departure. Will "discardable" ultimately prove helpful? It has
already caused many to ignore handling for "all", since "all" lacks the
concise instruction offered by "discardable". It seems "discardable" is
in danger of ensuring an unproductive outcome for ADSP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html