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

[Eric Burger <eburger at brooktrout.com>]

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.

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell at dynamicsoft.com]
> Sent: Thursday, July 01, 2004 11:54 AM
> To: Eric Burger
> Cc: Adam Roach; cboulton at ubiquity.com; simple at ietf.org
> Subject: Re: [Simple] MSRP: delivery reports and transaction responses
> 
> 
> 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?
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Adam Roach [mailto:adam at dynamicsoft.com]
> >>Sent: Thursday, June 17, 2004 6:13 PM
> >>To: Mike Hammer
> >>Cc: pkyzivat at cisco.com; hisham.khartabil at nokia.com;
> >>cboulton at ubiquity.com; Ben Campbell; simple at ietf.org
> >>Subject: Re: [Simple] MSRP: delivery reports and 
> transaction responses
> >>
> >>
> >>Mike Hammer wrote:
> >>
> >>>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
> >>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.
> >>
> >>
> >>>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
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>Simple at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/simple
> >>
> 

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple