Subject: RE: [Simple] MSRP: delivery reports and transaction responses

From: Eric Burger <[email-masked]>
Date: Thu, 1 Jul 2004 11:39:32 -0400

I would offer that DSN report generation is a matter of local policy.  If I
were a privacy advocate on the IESG, REQUIRING DSN reporting would be a
no-no.  I would make the MUST a SHOULD.

> -----Original Message-----
> From: Orit Levin [mailto:[email-masked]]
> Sent: Friday, June 18, 2004 11:58 AM
> To: Mike Hammer; Adam Roach
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ben Campbell; [email-masked]
> Subject: RE: [Simple] MSRP: delivery reports and transaction responses
> 
> 
> Positive transaction responses are generated "if and only if" the
> negative-report flag is set to TRUE.
> 
> Positive transaction response is a "tool" for generating Negative
> Reports only.
> 
> It is the means for letting know the previous hop whether the SEND has
> been definitely successfully delivered to the next hop. Otherwise, if
> the positive response doesn't arrive (and the negative 
> response doesn't
> arrive either) after a certain period of time (e.g. after the local
> transaction timer expires) the MSRP entity MUST generate the negative
> DSN report.
> 
> The local transaction timer is maintained for a SEND with
> negative-report flag set to "Yes" only.
> 
> Orit.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Mike Hammer
> Sent: Friday, June 18, 2004 6:44 AM
> To: Adam Roach
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ben Campbell; [email-masked]
> Subject: Re: [Simple] MSRP: delivery reports and transaction responses
> 
> At 06:51 PM 6/17/2004 -0500, Adam Roach wrote:
> >Mike Hammer wrote:
> >
> >>At 05:12 PM 6/17/2004 -0500, Adam Roach wrote:
> >>
> >>>...people envision doing things like sending
> >>>administrative messages (e.g. "The IM system will be down from
> >>>5:00 to 7:00 pm for maintenance") to thousands or even hundreds
> >>>of thousands of users, and they don't want negative responses
> >>>for the ones that fail.
> >>
> >>
> >>Sounds like you would want to suppress successful responses too, but
> that 
> >>is not an option for what is proposed.
> >
> >Ummm... yes it is. Setting "report-failure" to "false" 
> guarantees that
> you 
> >don't get any negative reports, and that you don't get any 
> transaction 
> >responses (positive or negative).
> >
> >/a
> 
> Now, you've totally confused me.  My understanding was that the 
> report-failure flag governed the behavior of the negative reports and 
> negative responses, while the report-success flag governed 
> the positive 
> reports, but only for the endpoints and not for the positive 
> responses; 
> where the sending of the positive transaction response was 
> not governed
> by 
> either flag.
> 
> This is why I have decided to withdraw until I see the official 
> description.  The answers from this email thread have gotten me closer
> to 
> understanding, but have not been completely consistent.
> 
> Mike
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Eric Burger <[email-masked]>
Date: Sun, 18 Jul 2004 02:32:49 -0400

In theory, the DSN only says that the message got to the recipient's device.

The DSN is something designed for Relays, not User Agents, to emit.

What gets confusing is the User Agent Server is also a Relay, "forwarding"
the message to the user.

In reality, the MDN does not *guarantee* any other information, as well.
Privacy considerations require the blocking of MDN's by the recipient.

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, July 01, 2004 11:54 AM
> To: Eric Burger
> Cc: Adam Roach; [email-masked]; [email-masked]
> One area I am not sure we are communicating:
> 
> The "positive" report says _nothing_ about whether the user 
> has seen the 
> message. It merely confirms that the message was received by the 
> terminating device in the path.
> 
> Does that still make it mirror a MDN?
> 
> Eric Burger wrote:
> 
> > Do I look blue in the face yet???
> > 
> > The reason for all of this bizarre flag / indicator 
> interaction is we are
> > STILL trying to squeeze two different report notifications into one.
> > 
> > Let's look at the requirements.
> > 
> > #1: There is a need for positive acknowledgement, by 
> sender's request, that
> > a message was delivered.  This is an end-to-end issue, 
> mirroring the MDN.
> > Note that local policy or security policy means the 
> recipient MUST be able
> > to deny the sender's request for acknowledgement.
> > 
> > #2: There is a need, by sender's request, for notification 
> of transport
> > failure.  This occurs when a relay can't send the message 
> on, or is queuing
> > it for later delivery.  This is a transport network 
> (hop-by-hop) issue,
> > mirroring the DSN.
> > 
> > Is there any reason not to have these two things separate, 
> orthogonal
> > requests?
> > 
> > Instead of nine-element matrixes with incompatible states, 
> we end up with:
> > 
> > MDN Requested, tell me only failures or tell me failure/success
> > DSN Requested, tell me only failures
> > 
> > Experience with SMTP says, MUST NOT have every hop report 
> positive DSN's.
> > Positive DSN's have no value, other than exposing the relay 
> network to
> > potentially bad people.  The thing of value is that the end 
> user got the
> > message (MDN).
> > 
> > Do I need to do _more_ text?
> > 
> > 
> > 
> >>From: Adam Roach [mailto:[email-masked]]
> >>Sent: Thursday, June 17, 2004 6:13 PM
> >>To: Mike Hammer
> >>>Would it not be possible to use just two binary flags and 
> >>
> >>just make the 
> >>
> >>>behavior of the receiving node a "Should not send DSN, MUST 
> >>
> >>not send 
> >>
> >>>response" with the sending node having a "MAY discard 
> >>
> >>received DSN" or 
> >>
> >>>is this a limited BW case for the sender?  I would think 
> >>
> >>that a relay 
> >>
> >>>for BW-limited sender could also discard before a BW-limited link.
> >>
> >>The problem is that people envision doing things like sending
> >>>report-success=true     send response?, send Pos-DSN report
> >>>report-success=false    send response?, no Pos-DSN report
> >>>report-failures=true    send response,  send Neg-DSN report
> >>>report-failures=false   no response,    no report
> >>>report-failures=partial no response,    may send report
> >>>applies to all devices.
> >>>
> >>>I'm still missing some details (? above).
> >>
> >>The "Report Success" flag never, ever, ever has an impact
> >>on whether transaction responses are sent. In fact, relays
> >>never need to even consider the value of the "Report Success"
> >>flag. It is processed by endpoints only.
> >>
> >>report-failures | Send Response? | Send report on failure?
> >>----------------+----------------+------------------------
> >>true            | MUST           | MUST
> >>false           | MUST NOT       | MUST NOT
> >>partial         | MUST NOT       | MAY
> >>
> >>/a
> >>