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

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Jun 2004 14:16:36 -0500

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

---

From: Mike Hammer <[email-masked]>
Date: Wed, 16 Jun 2004 18:48:07 -0400

Ben,

It seems like you could simplify things further if you de-coupled the 
reports from the responses described in your last 4 paragraphs.  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.

Mike

At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote:
>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.
>
>-----------------------
>
>(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.
>
>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.
>
>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.
>
>"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.
>
>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.
>
>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.)
>
>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 
>defined timeout period has expired before receiving a 200 OK response, it 
>MUST act as if it had received an appropriate error response.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Jun 2004 17:51:40 -0500

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:

> 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.

>> 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 
>> 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.
>>
>> 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.)
>>
>> 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.
>>

---

From: Mike Hammer <[email-masked]>
Date: Wed, 16 Jun 2004 19:17:24 -0400

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:
>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,
>>>may not notice the error until they are informed by the downstream network.)
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jun 2004 20:06:56 -0400

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:
> 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 
> flags instead of two.  The suggestions were to help confirm for myself 
> that I had read your intent correctly.
> 
> Mike
> 
> 
>> 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,
>> 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.)
>>>> 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.
>>>>
>>>> -----------------------
>>>>
>>>> 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 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>

---

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

Paul Kyzivat wrote:

> 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.

I think such an approach is a bad idea.

It's good protocol design to make things that are semantically 
nonsensical syntactically impossible to express. Separating out a 
"responses" flag will just obscure the fact that twiddling this flag 
over here with a name unrelated to negative DSNs has a fairly radical 
effect on the nature of the negative DSNs you might receive.

Although the wording of the description could use some tightening, I 
strongly support leaving the mechanism that is being described as Ben 
proposed.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2004 14:44:13 -0400

Adam Roach wrote:
> nonsensical syntactically impossible to express.

Well, I agree with you on that. But it is a principle that is violated 
quite regularly in sip, with many constraints being expressed in the 
text rather than the syntax. Its a tradeoff vs other goals.

And the flip side of that is to carefully define the semantics of 
everything that it is possible to specify semantically.

 > Separating out a

True.

> strongly support leaving the mechanism that is being described as Ben 

If the syntax and/or description can be made less obscure I have no problem.

I was baffled by true/partial/false, and the description left me still 
scratching my head. I *thought* I understood it, but wasn't certain.

	Paul

---

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

At 12:20 PM 6/17/2004 -0500, Adam Roach wrote:
>It's good protocol design to make things that are semantically nonsensical 
>syntactically impossible to express.

True, but the definitions of the 3 flags could be made such that there are 
no non-sensical meanings.

>Separating out a "responses" flag will just obscure the fact that 
>twiddling this flag over here with a name unrelated to negative DSNs has a 
>fairly radical effect on the nature of the negative DSNs you might receive.
>strongly support leaving the mechanism that is being described as Ben proposed.
>
>/a

It is still unclear to me from the sender's viewpoint the difference 
between Report-failure:yes and partial.  Either he will accept DNS or he 
won't, unless there are really two types of DNS, in which case they should 
be distinguished.

Another alternative, if you are going for minimum numbers of flags would 
have been to define it as:  default send only Pos-Res, except when this is 
received:

Report: 1*( Pos-DNS [","] / Neg-DNS [","] / Neg-Res [","] )

Or, for two flags:

Report-DNS:   1*( success [","] / fail )
Suppress-Res: 1*( true / false ) ; absent = false

However, this may be water under the bridge.

Mike

---

From: Ben Campbell <[email-masked]>
Date: Thu, 17 Jun 2004 14:07:24 -0500

Mike Hammer wrote:

>>> declared illegal. (And if anyone uses a nonsense combination they 
>>> will get what they deserve.) And with three flags, they would all be 
>>> binary.
>>
>>
> True, but the definitions of the 3 flags could be made such that there 
> are no non-sensical meanings.
> 
>> twiddling this flag over here with a name unrelated to negative DSNs 
>> has a fairly radical effect on the nature of the negative DSNs you 
>> might receive.
> won't, unless there are really two types of DNS, in which case they 
> should be distinguished.

Report-failure=true means the sender insists on getting failure reports 
if a failure occures. Partial means that is does not forbid the sending 
of failure reports. False means it forbids the sending of failure reports.

> have been to define it as:  default send only Pos-Res, except when this 
> is received:
>

---

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

Ben,

I think I've teased this enough to understand it, but still need to nail 
down one detail.  Could you confirm my understanding below:

Failure responses are tied to the report-failure flag, true means they are 
sent, false means they are not, in all cases by all devices.

Success responses are not tied to the report-success flag, they are 
reported at all times by all devices.

Final note, then I'll be quiet:  Since response behavior is implicit, i.e. 
embedded in the *report* flags, and not explicitly signaled, any need to 
de-couple and change the response behavior in the future will have backward 
compatibility problems.

Thanks for your patience for one who was not in Boston,
Mike

At 02:07 PM 6/17/2004 -0500, Ben Campbell wrote:
>>>twiddling this flag over here with a name unrelated to negative DSNs has 
>>>a fairly radical effect on the nature of the negative DSNs you might receive.
>Report-failure=true means the sender insists on getting failure reports if 
>a failure occures. Partial means that is does not forbid the sending of 
>failure reports. False means it forbids the sending of failure reports.
>
>
>