Subject: Re: [Simple] MSRP Report Model

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Jan 2006 09:45:12 -0600

Hi,

The work group discussed this issue in detail some time ago. I offer  
the following to describe the result of that discussion. More inline:

On Jan 10, 2006, at 5:55 AM, [email-masked] wrote:

> Hi All,
>
> This is regarding MSRP Report Model. MSRP draft says receiver  MUST  
> send REPORT  (success/failure) depending upon the "Success-Report"  
> and "Failure-Report" header field values in the SEND request.  But  
> in case receiver does not want to generate the  reports, there  
> should be a  way /some ways of indicating the same (may be this was  
> already discussed earlier, but I am not aware of). There can be  
> many reasons  for the receiver not to generate REPORT for incoming  
> SEND request.

The issue is, if the sender requests success-reports, the sender is  
requesting reliable delivery of the message. This makes the REPORT  
effectively part of a end-to-end transaction. If the sender does not  
receive one in a reasonable period of time, it is likely to attempt  
to attempt to restart the session, resend the content, etc.

Furthermore, a positive delivery report does not indicate that the  
receiving human has actually seen the message. Only that the endpoint  
has received it. In this sense, you can think of a positive report to  
be akin to a SIP 200 OK response, which is certainly not optional.

>
> 1. Congestion on the receiver side

I don't think we need an exception for congestion--the endpoint may  
fail to live up to any aspect of the protocol when congested. We  
would need to put the same exception on everything else.

> 2. Service Provider may charge for per unit data transferred.

The REPORT request is typically small. Also MSRP will likely be used  
with presence, which will create quite a bit of traffic. Any  
additional cost for REPORT requests will probably fall into the noise.

>
> 3. Due to some security or privacy reason
>

Again, REPORT does not indicate the user has seen the message. It can  
be sent before rendering of the content. Furthermore, an MSRP session  
will only exist if negotiated with SIP or some other rendez-vous  
protocol. Once an endpoint has explicitly indicated its willingness  
to participate in an MSRP session, actually sending REPORT requests  
does not seem to leak any information that has not already been  
freely given.

>
> We MAY consider two solutions:
> 1. Negotiate Sending Reports during session setup and/or
>

The working group discussed this some time back, and chose not to  
include a negotiation mechanism.

> 2. Sender may be informed via transaction status messages  
> indicating  that receiver shall not generate the report.
>

There are cases where no such transaction status message occurs, so  
we cannot depend on this for negotiation.

Hope this helps!

Ben.

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

---

From: [email-masked]
Date: Fri, 3 Feb 2006 10:29:22 +0530

Hi,

There are some more doubts which are still not clear. More Inline

Regards,
Amit Kumar Goel
Infineon Technology,
Bangalore

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Campbell
Sent: Monday, January 23, 2006 9:15 PM
To: Goel Amitkumar (IFIN CSW WS)
Cc: [email-masked]
Subject: Re: [Simple] MSRP Report Model

Hi,

On Jan 10, 2006, at 5:55 AM, [email-masked] wrote:

> send REPORT  (success/failure) depending upon the "Success-Report" and

> "Failure-Report" header field values in the SEND request.  But in case

> receiver does not want to generate the  reports, there should be a  
> way /some ways of indicating the same (may be this was already 
> discussed earlier, but I am not aware of). There can be many reasons  
> for the receiver not to generate REPORT for incoming SEND request.

	
	<Amit Goel>

	This makes sense. If we have a mechanism to know about the
reliable delivery of
	message, ideally specification should not mandate the use of TCP
as the transport protocol.
	There should be option to use UDP and any other transport
protocol.
	This issue I raised sometime back also.

	</Amit Goel>

	<Amit Goel>
	
	Can you please let us know what were the points based on which
it was decided not to include this negotiation or the pointers to such
information shall be appreciated.

	</Amit Goel>

> 2. Sender may be informed via transaction status messages indicating
> that receiver shall not generate the report.
>

Hope this helps!

Ben.