Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02

[Ned Freed <[e-mail]>]

Having thought about this a bit more, it occurs to me that a common thread that
underlies at least some of the discussion here isn't the need to provide deep
background on the general workings of sieve, but rather that correct use of
this extension depends on an understanding of the inherently asynchronous
nature of email. In particular, you cannot depend on a message from a list
arriving before or after an individual copy, and you cannot depend on alerts
from multiple sources arriving in a particular order.

Arnt pointed out the list/individual copy issue earlier, and Robert's example
where some alerts have critical information attached and others don't touches
on the latter issue. And generally it would be easy for users to mistakenly
assume that they can depend on message ordering.

As a rule I object to reiterating or summarizing technical material in other
specifications, mostly because it tends to lose something in the translation.
But this is, AFAIK, a new issue: We've defined mechanisms like vacation before
that maintain state across messages, but this is the first sieve mechanisms
that exposes such a mechanism directly to the end user.

My suggestion would be to add an example of how *not* to use duplicate. The
obvious one would be a usage that attempts to block individual cc's of
list mail. (Such an example can be found in the earlier discussion.)

Beyond that, I'm still at a loss as to what, if anything, needs to be added.

				Ned