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

From: [email-masked]
Date: Thu, 17 Jun 2004 11:24:40 +0300

I don't like the idea of having a 3rd flag. The flags are clearly for the sender to indicate the desire to receive DSNs or not. The transactional responses are a consequence of that choice. We should not mix that with transactional response flags. Also I don't believe it is a good idea to give the sender the ability to control when responses are sent, especially when they are useless and don't give any extra information to the sender nor to the relays, but instead cause useless traffic to flow in the network.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Paul Kyzivat
> Sent: 17.June.2004 03:07
> To: Mike Hammer
> Cc: Ben Campbell; Simple WG
> Subject: Re: [Simple] MSRP: delivery reports and transaction responses
> 
> 
> When I read the proposal I had a similar reaction to what Mike had. I 
> was going to comment but decided it was good enough so I 
> would leave it 
> be. But since Mike was troubled by the same thing I will support him:
> 
> It would be clearer if there were three flags rather than 
> two, with the 
> the third explicitly controlling the sending of responses. This does 
> permit some nonsense combinations, but they can be simply declared 
> illegal. (And if anyone uses a nonsense combination they will 
> get what 
> they deserve.) And with three flags, they would all be binary.
> 
> 	Paul
> 
> Mike Hammer wrote:
> > The use of the terms sender and recipient could be 
> endpoints or relays, 
> > depending on whether you are talking hop-by-hop or 
> end-to-end.  So, I am 
> > a bit fuzzy until some more precise language is provided.  
> Otherwise, I 
> > am guessing as to exactly what you intended.  Your fist paragraph 
> > indicates that reports are endpoint only, and thus omits 
> any discussion 
> > of relays.  But, then the report failure flag includes 
> relay behavior 
> > reactions.  Thus, my uncertainty and guessing.
> > 
> > However, either way, the overall behavior could be the same 
> using three 
> > flags instead of two.  The suggestions were to help confirm 
> for myself 
> > that I had read your intent correctly.
> > 
> > Mike
> > 
> > 
> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote:
> > 
> >> First, just to make sure things are clear, this was not 
> proposed draft 
> >> verbiage, it was just a quick descripiton of the approach. 
> Not only 
> >> will the draft language be more precise, we will be splitting the 
> >> endpoint vs. relay behavior between the appropriate drafts.
> >>
> >> Further comments inline:
> >>
> >> Mike Hammer wrote:
> >>
> >>> Ben,
> >>> It seems like you could simplify things further if you 
> de-coupled the 
> >>> reports from the responses described in your last 4 paragraphs.
> >>
> >>
> >> Do you mean decouple the behavior, or decouple the 
> descriptions? If 
> >> the first, please let me know what you have in mind.
> >>
> >> This
> >>
> >>> would also help support the clarity you seek in the first 
> paragraph 
> >>> and enable some symmetry in having only binary flags.  (Having a 
> >>> 'tricky' part is the first clue to complexity.)
> >>> It would also help if you define the behavior upon 
> receiving the SEND 
> >>> with each flag for each device type (senders, endpoints, relays, 
> >>> gateways, recipients -- a non-redundant set would help 
> readability).
> >>> Lumping two flags or device types in one sentence makes 
> parsing more 
> >>> difficult.
> >>
> >>
> >> The drafts will do that.
> >>
> >>> Mike
> >>>
> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote:
> >>>
> >>>> In Boston, we had a proposal for a comprimise solution 
> on handling 
> >>>> delivery reports and transaction responses. The primary 
> contributors 
> >>>> have had a number of discussions, and came up with some details. 
> >>>> This does not address questions of DSN format, nor does it talk 
> >>>> about DSN reports that occur after a session has 
> ended--those will 
> >>>> be shortly forthcoming. This note only addresses when to 
> send DSN 
> >>>> reports and transaction responses, and the relationship 
> between them.
> >>>>
> >>>> -----------------------
> >>>>
> >>>> First, a clarification of terms. When we use the term "delivery 
> >>>> report" (or "reports" for short), we mean a report sent 
> back to the 
> >>>> sender to tell it the delivery status. This is different than 
> >>>> "transaction responses" (or "responses" for short).  Transaction 
> >>>> responses to SEND requests are strictly hop-by-hop, 
> while delivery 
> >>>> reports are generally end-to-end, or middle-to-end if 
> the reporting 
> >>>> device is a relay.
> >>>>
> >>>> The sender requests delivery reports on a message by 
> message basis. 
> >>>> This is done in an MSRP header in a SEND request. That 
> header has 
> >>>> two distinct flags. One indicates the desire to get 
> failure reports, 
> >>>> and the other indicates the desire to get success reports. The 
> >>>> sender can set any combination of these flags.
> >>>>
> >>>> The success report request flag can have values of true 
> or false. If 
> >>>> the flag is true, then the receiving endpoint MUST send back a 
> >>>> success report when it successfully receives a message. 
> This does 
> >>>> not say anything about the message disposition after 
> reception, only 
> >>>> that is was successfully received. If this flag is false, the 
> >>>> receiving endpoint MUST NOT send success reports. 
> Success reports 
> >>>> are strictly end-to-end, that is, Relays _never_ send 
> success reports.
> >>>>
> >>>> The failure report request flag can have three values: 
> True, False, 
> >>>> and "partial". If this flag is false, then both the receiving 
> >>>> endpoint and any relays MUST NOT send failure reports. If it is 
> >>>> "partial", then the receiving device and any relay 
> SHOULD send an 
> >>>> error report if it detects a "fatal" error; that is, an 
> error which 
> >>>> prevents delivery of the message.
> >>>>
> >>>> Now, here is the tricky part: None of the conditions 
> described so 
> >>>> far involve the use of transaction responses to SEND 
> requests. If 
> >>>> the failure report request flag is any value other than 
> True, then 
> >>>> MSRP devices SHOULD NOT send transaction responses for 
> the request. 
> >>>> Furthermore, devices MUST NOT "expect" transaction responses, 
> >>>> although they should not freak out if they get one.
> >>>>
> >>>> If the failure report request flag is True, then the 
> recipient, and 
> >>>> any relays, MUST send send a transaction response. If any device 
> >>>> detects an error which prevents delivery, it SHOULD send 
> a failure 
> >>>> transaction response back to the previous hop. If it is 
> unable to 
> >>>> immediately detect the error, it MAY send a 200 OK response, 
> >>>> followed by a failure _report_ when the error is 
> detected. (This is 
> >>>> mainly for gateway devices, which may not notice the error until 
> >>>> they are informed by the downstream network.)
> >>>>
> >>>> If any relay receives a failure transaction response to a SEND 
> >>>> request where failure reports are requested, that device 
> MUST send a 
> >>>> failure report. If the sending device receives a failure 
> transaction 
> >>>> response, it acts the same as if it had received a 
> failure report 
> >>>> with the same information. Furthermore, if any such device 
> >>>> determines that delivery to the next hop has failed 
> because either a 
> >>>> transport error or a locally defined timeout period has expired 
> >>>> before receiving a 200 OK response, it MUST act as if it had 
> >>>> received an appropriate error response.
> >>>>
> >>>> _______________________________________________
> >>>> 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
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2004 09:06:00 -0400

I don't feel strongly about this, so I won't argue very hard.

As described, I found the interaction between the flags and the 
mechanisms of when to send reports and when to send responses to be 
quite obscure. Adding another flag is one way to resolve that. 
Potentially it could also be resolved by the way things are named and 
described.

In any case, the end result is quite pleasing, though it offers options 
that it would seemingly be insane to use.

	Paul