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

From: Mike Hammer <[email-masked]>
Date: Thu, 17 Jun 2004 11:46:48 -0400

That would seem to suggest that only a yes/no for the report failure 
request is needed, not the partial setting, and this is merely behavior 
(suppress responses) specified on seeing a "yes" setting.

Second, you say responses are sent to SEND requests only if 
"report-failure=no".  Does that apply to just endpoints, just relays, or to 
all devices?

Mike

At 06:14 PM 6/17/2004 +0300, [email-masked] wrote:
>I don't understand what is so complicated about this (perhaps Ben 
>complicated the text too much. You might feel better when you see the text 
>that will be in the draft). The guts of the proposal is: No responses are 
>sent to SEND requests unless a negative DSN is requested by the sender.
>
>Regards,
>Hisham
>
> > -----Original Message-----
> > From: ext Mike Hammer [mailto:[email-masked]]
> > Sent: 17.June.2004 17:32
> > To: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Simple] MSRP: delivery reports and transaction responses
> >
> >
> > Chris,
> >
> > If the extra indication is not needed, then there would be no
> > need for
> > three states in the flag that affects both reports and
> > responses.  As Paul
> > suggested, it depends on how you name the third flag and
> > define its usage.
> >
> > I think if you would define the success and failure flags
> > strictly in terms
> > of how and when reports are sent or suppressed, then ask what
> > is missing,
> > you would likely find that the final ingredient is to
> > suppress or encourage
> > transaction responses by a particular device type at some
> > points in the
> > flow.  You could then define that 3rd flag to do that more specific
> > function.  That should be a rather simple exercise to try, so
> > why not do it?
> >
> > Mike
> >
> >
> > At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote:
> > >I'm with Hisham on this - I think a third flag would just confuse the
> > >process.  It has been identified that transaction responses are only
> > >really needed in one DSN request state (negative=true) - why have a
> > >third flag to convey this?
> > >
> > >Chris.
> > >
> > >
> > > >
> > > >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
> > >
> > >
> > >This message has been scanned for viruses by MailControl -
> > >www.mailcontrol.com
> >
> >

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 17 Jun 2004 10:50:45 -0500

> (suppress responses) specified on seeing a "yes" setting.

The "partial" setting was added because some wanted a mode where 
transaction responses did not occur, but devices were still allowed to 
send failure reports if they discovered the failure through some other 
mechanism.

> "report-failure=no".  Does that apply to just endpoints, just relays, or 
> to all devices?
> 

Uhm, that should be that responses are only sent to SEND requests if 
report-failures=true. It applies to all devices.

>> complicated the text too much. You might feel better when you see the 
>> text that will be in the draft). The guts of the proposal is: No 
>> responses are sent to SEND requests unless a negative DSN is requested 
>> by the sender.
>>
>> Regards,
>> Hisham
>>

---

From: Mike Hammer <[email-masked]>
Date: Thu, 17 Jun 2004 12:39:05 -0400

Drilling down just a little bit further inline.

>send failure reports if they discovered the failure through some other 

So the partial applies only to negative-DSN sending, not to response 
sending.  (this is the schizophrenic part)  This is where a 
"Neg-DSN-possible-override" flag would be the third flag.

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.

>report-failures=true. It applies to all devices.

My bad, tried to put positive spin on requirement, seemed like too many 
negatives in one sentence.

So to summarize:
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).

Mike

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jun 2004 17:12:56 -0500

Mike Hammer wrote:
> 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.

> 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

---

From: Mike Hammer <[email-masked]>
Date: Thu, 17 Jun 2004 19:20:33 -0400

>of thousands of users, and they don't want negative responses

Sounds like you would want to suppress successful responses too, but that 
is not an option for what is proposed.

>report-failures | Send Response? | Send report on failure?

That clarifies one non-stated aspect, thanks.
Time to wait for the official language to come out.

Mike

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Jun 2004 18:51:12 -0500

Mike Hammer wrote:

>> ...people envision doing things like sending
> 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

---

From: Mike Hammer <[email-masked]>
Date: Fri, 18 Jun 2004 09:44:23 -0400

At 06:51 PM 6/17/2004 -0500, Adam Roach wrote:
>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