Subject: Re: [Simple] MSRP Report Model

From: Ben Campbell <[email-masked]>
Date: Thu, 16 Mar 2006 18:33:36 -0600

Sorry for the late response. I somehow failed to notice your email  
until now. Comments inline:

On Feb 2, 2006, at 10:59 PM, [email-masked] wrote:

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

TCP was specified mainly for congestion management reasons.  The IESG  
has been discouraging the use of non-congestion-controlled transport  
protocols except for some very specific applications for some time now.

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

The consensus was the value of such negotiation did not warrant the  
additional complexity. Yes, I know that seems laughable considering  
the complexity we put into other areas of MSRP--but the features  
introducing the other complexities had people championing them, and  
this did not.

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

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