Subject: Re: Discard vs. DSN

From: Gregory Sereda <[email-masked]>
Date: Tue, 23 Mar 1999 16:09:57 -0500

At 12:31 PM 3/23/99 -0800, Ned Freed wrote:
>Exactly right. In my experience being able to ignore messages is one of most
>commonly requested features, if not *the* most requested feature, for filters
>to be able to do. 
>
>This is why I'm strongly opposed to making it optional.

I agree that discard MUST NOT generate a NDN.  The needed functionality
is an automated way to press the delete button.  There was no failure
to delivery, only the user's decision to delete it, automated via
a sieve script.

The problem arises if an implementation cannot implement discard
without generating a NDN.  Do we say:

	- The implemenation is not sieve compatible?
	- Or give some wiggle room and say discard is optional?
	- Or say discard SHOULD NOT generate NDN?

My preference would be stronger than SHOULD NOT but not quite
MUST NOT.  I guess that means stating the discard SHOULD NOT
generate a NDN.  Perhaps, with text stressing that the usefulness
of discard is greatly disminished by implementations that generate
a NDNs.  The developer should try very hard to implement discard
correctly.

I think there is still value in a sieve implementation that
cannot implement discard without a NDN, but users of the
implementation would just have to live with its limitations.

Greg

---

From: Matthew Wall <[email-masked]>
Date: Tue, 23 Mar 1999 16:33:31 -0500

--On Tue, Mar 23, 1999 4:09 PM -0500 the entity known as Gregory Sereda
<[email-masked]> wrote:

> generate a NDN. 

To which Matthew Wall offers this response on Tue, 23 Mar 1999 16:27:56
-0500:

according to the logic of [KEYWORDS], this seems like the solomonic
compromise, short of splitting the baby in two. We'd probably want to add a
line or two in the document explaining the circumstances under which it
might be good to generate (as Greg suggests), with appropriately poisonous
adjectives to otherwise discourage it. 

But Discard must be mandatory; it's fundamentally useful.

I agree with the model, fwiw, of 'discard' as an automated delete button.

- mw

---

From: Tim Showalter <[email-masked]>
Date: 23 Mar 1999 16:52:12 -0500

> Date: Tue, 23 Mar 1999 16:09:57 -0500
> From: Gregory Sereda <[email-masked]>

> a NDNs.  The developer should try very hard to implement discard

Perhaps we need to consider adding REALLY to the KEYWORDS document
(REALLY REALLY SHOULD NOT).

Wonder if that can be written up for next Thursday...

> implementation would just have to live with its limitations.

I would rather have discard be optional than this.  If discard is
equivalent to reject, it is not discard anymore.  Having two meanings
for discard is as bad as two meanings for fileinto.

-- 
Tim Showalter <[email-masked]>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Mar 1999 15:56:40 -0600

On 3/23/99 at 4:09 PM -0500, Gregory Sereda wrote:

>I agree that discard MUST NOT generate a NDN.

So do I. I think more strongly than other people.

>without generating a NDN.

Then it hasn't implemented discard; it has implemented reject. As far 
as my reading of the draft goes, reject = discard + DSN and discard = 
fileinto "/dev/null". The inability to implement discard without DSN 
is a failure to implement properly.

Randy, maybe you can explain why your implementation can't implement 
either reject - DSN or fileinto "/dev/null". I would like to prevent 
DSNs with discards at all costs.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Tue, 23 Mar 1999 14:10:36 -0800 (PST)

> Then it hasn't implemented discard; it has implemented reject.

I agree emphatically; thanks for the consise statement.

We seem to be stuck between the following two mutually exclusive positions:

1) Discard is a vital service, and MUST be supported even if it cannot be
   supported correctly.

	or:

2) A Discard MUST NOT generate a DSN; if the implementation has no way to
   silently dispose of a message, than it does not support Discard.

I'm voting for #2. To me it makes no sense for the semantics of discard to
vary in different implementations, no matter how well documented. If I try to
give a SIEVE script to an implementation that always generates a DSN, I *want*
'discard' to return a syntax error.

<csg>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Mar 1999 14:43:46 -0800

At 3:56 PM -0600 3/23/99, Pete Resnick wrote:

>Then it hasn't implemented discard; it has implemented reject. As 
>far as my reading of the draft goes, reject = discard + DSN and 
>discard =

I was reading 'reject' as delete & generate DSN with user-specified 
text.  If honoring the user-specified text is optional, then the only 
difference between 'reject' and 'discard' is indeed that 'discard' 
does not generate a DSN.

>DSNs with discards at all costs.

I didn't say my implementation couldn't.  I said in one environment 
in which my implementation runs this is difficult.  In this 
particular environment, my Sieve implementation operates as a 
delivery-time plug-in.  If the plug-in tells the mail system not to 
deliver the message, it generates a standard DSN.  This means I can't 
add the user-supplied text to the DSN, or avoid the DSN generation 
(unless the script causes delivery into a server 'trash' mailbox, 
which is what I do in my own personal script, which filters all my 
mail).

So which is it that I haven't implemented: 'discard' or 'reject'?  I 
was assuming I had implemented 'discard' and not 'reject', but 
perhaps it is the other way around.

If the consensus is  that this particular implementation and 
environment combination just isn't Sieve compliant, I can live with 
that.  I don't know how common or uncommon the constraints of this 
environment are.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 24 Mar 1999 21:59:28 -0500

> implementation would just have to live with its limitations.

If discard generates NDN, I think it's a broken implementation. My
feeling is that it should be a STRONG MUST NOT generate NDN.

	Tony Hansen
	[email-masked]