Subject: Re: Unsolicited Success MDN

From: Graham Klyne <[email-masked]>
Date: Mon, 18 Oct 1999 10:32:44 +0100

At 08:25 18/10/99 +0900, Hiroshi Tamura wrote:

>Simple-mode I-fax device(RFC2305) does not issue
>"Disposition-Notification-To" header.
>
>If simple-mode I-fax device receives MDN response,
>although it does not request(normally, it doesn't have
>the capability to request MDN),
>irrespective of whether it is positive or negative,
>it can not understand what's happened.
>Because it cannot understand the format of MDN.

I think this is another important point -- an unsolicited MDN
acknowledgment could be perceived as an "administrative non-message".

Unsolicited negative acknowledgements, by virtue of being relatively rare
(one hopes :-), and allowing that there is information contained that can
be rendered by the receiving party, I think would probably be OK.

#g

------------
Graham Klyne
([email-masked])

---

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 18 Oct 1999 10:18:52 -0700

If the sender did not request the MDN, and therefore did not generate a
message ID to tied the response to the original message, how can an
automated device connect the unsolicited MDN to the original message?
Vivian

> -----Original Message-----
> From: Graham Klyne [mailto:[email-masked]]
> Sent: 18 October, 1999 2:33 AM
> To: Hiroshi Tamura
> Cc: [email-masked]
> Subject: Re: Unsolicited Success MDN
> 
>

---

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 18 Oct 1999 20:03:00 -0700

> >It will be nice if all clients generated the Message_ID  regardless if
there
> >was the expectation of some response, then the positive MDN response will
> >have more value.
> 
> Well ...is this a Standards issue or a Implementation issue?  
> I vote for incorporation into the standard.  This goes to the core of 
> the receipt issue which has always been difficult in S&F and has caused us
all 
> considerable pain and grief.

On 2nd thought, if the client who sends the message does not expect a
response (i.e. does not request an MDN) what would it do with the Message_ID
that it might be required to generate? It probably has not use for it, and
might as well just print, display or ignore any Success MDN received. So
maybe there is really no problem.

Vivian

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Oct 1999 11:59:43 +0100

At 16:32 18/10/99 -0500, Richard Shockey wrote:

>If I recall correctly  ... If a Message_ID is generated by the client then 
>each successive SMTP hop will not alter that ID... it just that if there is 
>NO ID available .. one will then be inserted at the first hop. Correct?

I'm not sure... that sounds to me rather like the message submission
protocol (RFC 2476).

While on this topic, I'll also not that MDN says that the sender SHOULD
include a Message-ID if requesting an MDN.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Oct 1999 11:59:46 +0100

At 18:01 18/10/99 -0700, Cancio, Vivian wrote:

>A positive MDN should have the same restrictions as the negative MDN, in
>that it should be optional (sending one can be turned off, just as
>responding to an MDN request is optional).

I understand that ALL MDNs are optional -- positive and negative.  The only
difference here I can see is that it might be OK to send an unsolicited
negative MDN.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Oct 1999 11:59:48 +0100

>maybe there is really no problem.

I think this is a good point:  the puroose of a message-ID is to facilitate
automagical correlation of responses to original messages.  If the sender
does not intend to do that then maybe the message-ID is not so important.

Of course, there may be other uses (e.g. keying message archives, etc.)...

#g

------------
Graham Klyne
([email-masked])

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Tue, 19 Oct 1999 11:21:11 -0700

[McIntyre, Lloyd]  I believe that there are good fax application reasons to
at least support weakening of the restriction to SHOULD NOT.
---snip--- 
> That being said, I have no problem with replacing the MUST NOT with a
> SHOULD
> NOT. Nevertheless, extreme care needs to be exercised when sending
> unsolicited
> receipts. 
 ---snip--- 
[McIntyre, Lloyd]  I also see proliferation of message-id as a plus to the
application space.
---snip---  
> I'm all for message-id being generated whenever possible -- I would not
> have
> any problem with a SHOULD generate always and MUST generate when
> requesting
> an MDN or DSN.
---snip---  
> 				Ned

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Oct 1999 20:56:23 +0100

At 10:14 19/10/99 -0700, Ned Freed wrote:
[...]
>Actually, the damage done may be more substantial than this. In
particular, if
>users are inundated with receipts they did not request, they may well act to
>prevent the reception of *all* receipts. In fact I've seen this go as far as
>demands to disable automatic receipt generation entirely -- demands that
>ultimately were not only met, but occasioned the replacement of software that
>generated receipts willy-nilly with software where receipts were more
>controllable.
>
>That being said, I have no problem with replacing the MUST NOT with a SHOULD
unsolicited
>receipts. Like it or not, we live in a world where unsolicited messages as  a
>whole have acheived an astonishingly bad reputation, and the situation now is
>one that all too often fails to discriminate between legitimate and
>illegitimate use. Heck, we even have problems where we're flamed for sending
>out responses that were specifically and directly requested, but where the
user
>then forgot about the request...

If we could trust that implementers would interpret SHOULD NOT as a very
strong requirement, then maybe.

But... It is not clear to me what useful purpose would be served by sending
a positive MDN to a party who has not requested it (and therefore is
presumably not able to interpret it).

>I'm all for message-id being generated whenever possible -- I would not have
>any problem with a SHOULD generate always and MUST generate when requesting
>an MDN or DSN.

That has logic for me.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Oct 1999 20:56:19 +0100

At 09:06 19/10/99 -0700, Dave Crocker wrote:
[...]
>Detailed counter-responses:
>
>At 10:31 AM 10/16/1999 , Graham Klyne wrote:
>>(a) Section 2.1: "MDNs SHOULD NOT be sent automatically if the address in
>>the Disposition-Notification-To header differs from the address in the
>>Return-path header ...".  I would take from this a strong implication that
>>"MDNs SHOULD NOT be sent automatically if there is NO
>>Disposition-Notification-To header".
>
>On the other hand, the absence of the header would usually mean using the 
>Return-path header, thereby making them the same.  At any rate, unsolicited 
>NEGATIVE MDNs are permitted, so this "problem" has to be dealt with anyhow.

I would say that a null address (i.e. no 'disposition-notification-to:') is
not equal to any non-null address (return-path value).

>>(b) Section 3: "A message disposition notification MUST NOT itself request
>>an MDN".  This implies to be a real concern about creating message loops.
>>
>>I think the concern here is the possibility for creating a message loop:
>
>This rule here, BY ITSELF, prevents loops. Don't ever send an MDN for an 
>MDN.  Period.

It doesn't if you are allowing unsolicited MDN's to be sent.  The
prohibition noted  is with respect to MDN *requests*.

Your rule, as stated ("Don't ever send an MDN for an MDN") would work IF
you can trust it to be implemented reliably.

In my opinion it would be easier to mess up the implementation of "send MDN
unless message is an MDN" than it would to mess up "send MDN only if an MDN
has been requested".  This is, of course, just an opinion.

>At 02:32 AM 10/18/1999 , Graham Klyne wrote:
>The status of an MDN confirmation as an administrative non-message (or not) 
>is not affected at all by whether it was solicited.  Hence the non-message 
>rule is not an argument for (or against) sending unsolicited MDNs.

Not quite:  if solicited, i think it is reasonable to assume that the
receiver of the MDN will know how to filter it.

>Since we allow the sending of unsolicited NEGATIVE MDNs, we already must 
>solve this problem.  Sending an unsolicited positive MDN does not create a 
>new problem.

The point I tried to make earlier was that this is (presumably) relatively
rare compared with a positive MDN.  If it's not then maybe we need to worry
about more fundamental aspects of this system :-)

(When large enough, a quantitative difference can be a qualitative
difference.)

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Wed, 20 Oct 1999 10:59:04 +0100

At 17:04 19/10/99 PDT, Larry Masinter wrote:

I agree with all you said.

>... why not
>just use the MDN request like it was designed? Otherwise we'd be stuck
>with something like
>
>  if-you-insist-disposition-notification-to: <addr>

I chuckled when I first read this, but then I thought some more ...

Maybe there is a desire to indicate that the sender *can* interpret MDNs
without actually *requesting* that an MDN be sent -- i.e. leaving the
choice of MDN transmission entirely up to the receipient.

Well, this is actually already the case when an MDN is requested.  But
there is a sort-of presumtpion that an MDN will be sent unless the
recipient has a reason to withhold it.

I am thinking that this "sort-of presumption" could be modified by a
disposition option rather than a new header:

  disposition-notification-to: <...>
  disposition-notification-option: discretionary-response=optional,xxx

The idea being to indicate that an MDN need not be sent unless the
recipient has something useful to say.

BTW, I have a question about MDN requests:  RFC 2298, section 2.2, syntax
definition indicates that the dispostion option parameter value is
mandatory, even when there is no useful value to include.  Hence the ",xxx"
in my example above.  Is this really the intent and current usage of MDN
options?  I'd like to be able to suggest:

  disposition-notification-option: discretionary-response=optional

#g

------------
Graham Klyne
([email-masked])

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 20 Oct 1999 17:42:41 -0700

[McIntyre, Lloyd]  ---snip--- 

> recipient has something useful to say.
[McIntyre, Lloyd]  such as I have capabilities revision.