Subject: Re: Progressive reports [Was Re: [Simple] IMDN Issue 4: Disposition Notification Types]

From: "Ranjan Rajeev-RRANJAN1" <[email-masked]>
Date: Tue, 22 Aug 2006 22:06:48 -0400

Hi Hisham, Garcia,
 
First of all I will like to introduce my self as I am responding on this
reflector for the first time. 
 
While reviewing this email thread I am thinking about the implications
of enabling the "in-progress" state and generating multiple "processing"
IMDNs. I have few questions regarding your proposed changes:
 
As I understand, according to your suggested proposal to enable progress
report in a MSRP centralized conference, following will happen:
1. all the reporting UAS need to enable the "In-processing" state and
send the "Processing" IMDN at frequent periodic Interval to the MSRP
conferencing server.
2. The MSRP conferencing server also need to enable the "In-processing"
state, collect frequent periodic "Processing" IMDN's from all the
reporting UAS, collate all the results and generate "processing" IMDN at
frequent regular Interval to the Sender.
 
Questions:
1. According to the current "draft-burger-simple-imdn-03" the reporting
UAS sends only one disposition IMDN per file transfer, this seems quite
reasonable. If IMDN's are enabled for progress report the number of
IMDN's generated will be huge. I am wondering what will be the
implication on the performance of the end points, the conferencing
server, and the network while handling these IMDN's? 
 
2. With Progress reports enabled, A reporting UAS is supposed to send
frequent periodic IMDNs. The MSRP conferencing server may not be able to
ignore any IMDN and need to process all the received IMDNs. In this
situation it will be quite difficult for the MSRP conferencing server or
the sender to counter the "Denial of Service attack". Does this elevates
the security concerns? 
 
Shall appreciate your response.
 
Regards,
 
Rajeev Ranjan
Network Advanced Technology
Motorola Inc, Arlington Heights, USA
 
Hisham Khartabil wrote: 

	Miguel,

	After a discussion on the mailing list about IMDN types, I added
the "processing" IMDN type to my working copy of the draft (that I am
now finalising for submission). This "processing" IMDN type has 2
states: "processed" and "stored". I guess you would need something like
"in-progress" as a state.
	
	In my working copy, the text forbids endpoints from generating
"processing" IMDNs, but if we add the state you suggest, I can relax
that restriction for "in-progress" state.

	Comments? (by Miguel and others :)

	Hisham

	On Aug 21, 2006, at 12:46 PM, Miguel Garcia wrote:

		Hi:

		I recently got into a discussion of a related use case,
I believe this is being under discussion in the OMA PoC WG. Imagine you
are in an MSRP centralized conference, and you are sending a (large)
file to to the roster through an MSRP switch. The sender would like to
receive end-to-end progress reports of the file transfer for each
individual participant.
		
		I've heard of a few proposals to enable this use case,
but in my opinion, the simplest one is to reuse IMDN to provide
progressive positive reports. So that would add a third type of report
to IMDN to the existing two. So, the current ones are positive-delivery
and negative-delivery. I think a third one, progressive-delivery would
be nice to have, and will solve this requirement.

		Do people have any thoughts?

		/Miguel

		Hisham Khartabil wrote: 

			In the draft, we have 2: delivered and read.
There has been suggestions to add a least 2 more, namely processed and
stored.
			Stored is sent by a store-and-forward server to
indicate that an IM has been stored.
			Processed is sent by intermediaries to indicate
that the IM has been processed (like a 202).
			I personally am against those additions.
			The sender of the IM is the one that requests
any type of IMDN. So, through the UI, the user has to answer all the
following questions for every IM:
			- Do I want to know if the IM is delivered
			- Do I want to know if the IM has failed
			- Do I want to know if the IM is read
			and the new states you are asking for:
			- Do I want to know if the IM is processed
			- Do I want to know if the IM is stored
			Of course these can be global settings, but
still, too many.
			when sending a SIP MESSAGE request, you will get
the transactional response 202 if the MESSAGE has been processed. I
don't see the need for IMDN to indicate so. I also don't see why a user
would want to know if a message is stored or not. In any case, isn't
this the same as processed?
			Hisham
			_______________________________________________
			Simple mailing list
			Simple at ietf.org
			https://www1.ietf.org/mailman/listinfo/simple 

		--
		Miguel A. Garcia           tel:+358-50-4804586
		sip:miguel.garcia at neonsite.net
		Nokia Research Center      Helsinki, Finland

--
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia at neonsite.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple

________________________________

*	References: 

	*	[Simple] IMDN Issue 4: Disposition Notification Types
<http://www1.ietf.org/mail-archive/web/simple/current/msg06743.html>  

		*	From: Hisham Khartabil

	*	Progressive reports [Was Re: [Simple] IMDN Issue 4:
Disposition Notification Types]
<http://www1.ietf.org/mail-archive/web/simple/current/msg06766.html>  

		*	From: Miguel Garcia

	*	Re: Progressive reports [Was Re: [Simple] IMDN Issue 4:
Disposition Notification Types]
<http://www1.ietf.org/mail-archive/web/simple/current/msg06768.html>  

		*	From: Hisham Khartabil

*	Prev by Date: Progressive reports [Was Re: [Simple] IMDN Issue
4: Disposition Notification Types]
<http://www1.ietf.org/mail-archive/web/simple/current/msg06766.html>  
*	Next by Date: Re: Progressive reports [Was Re: [Simple] IMDN
Issue 4: Disposition Notification Types]
<http://www1.ietf.org/mail-archive/web/simple/current/msg06768.html>  
*	Previous by thread: Re: Progressive reports [Was Re: [Simple]
IMDN Issue 4: Disposition Notification Types]
<http://www1.ietf.org/mail-archive/web/simple/current/msg06768.html>  
*	Next by thread: RE: [Simple] IMDN Issue 4: Disposition
Notification Types
<http://www1.ietf.org/mail-archive/web/simple/current/msg06745.html>  
*	Index(es): 

	*	Date
<http://www1.ietf.org/mail-archive/web/simple/current/maillist.html#0676
7>  
	*	Thread
<http://www1.ietf.org/mail-archive/web/simple/current/threads.html#06767

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 31 Aug 2006 15:17:00 +0300

Ranjan:

First, the discussion will flow a bit faster if you copy me directly in 
e-mails you expect me to response, otherwise you need to wait until I 
catch up with this mailing list (as it is happening).

Now, some inline comments. See below.

> send the "Processing" IMDN at frequent periodic Interval to the MSRP 

Well, I disagree here. You don't need ALL the endpoints to generate 
progressive IMDNs. In fact, generation of progressive reports, like any 
other IMDN, is subject to a policy at the endpoint that generates the 
IMDN. Such policy may dictate not sending IMDNs, or sending some classes 
only, or sending all. The conference MSRP switch will have to aggregate 
them while they are received (if any is received).

But other than that, I don't see if there is a problem. You want 
progressive reports, right? So the endpoints have to send them.

> frequent regular Interval to the Sender.

True

> server, and the network while handling these IMDN's?

So, don't send/disable progressive reports. If you want detailed 
information, endpoints have to submit that detailed information, in 
whatever protocol format you want. If think that is not according to the 
local policy, the the policy in the MSRP switch has to disable 
progressive reporting.

> the sender to counter the "Denial of Service attack". Does this elevates 

NO, I don't think so. The MSRP switch has the capability of disabling 
any kind of reports the policy says. If a malicious user would like to 
insert those report, first it should discover the MSRP URL, including 
the session ID, and if it has done it and fake the TCP connection. TLS 
would solve this problem. Further more, if this malicious user would 
manage to be able to insert IMDNs to the MSRP switch, why would it limit 
to sending IMDNs? It would be inserting malicious IMs. Once again, TLS 
solves this issue, IMHO.

BR,

         Miguel
>     After a discussion on the mailing list about IMDN types, I added the
>     "processing" IMDN type to my working copy of the draft (that I am
>     states: "processed" and "stored". I guess you would need something
>     like "in-progress" as a state.
> 
>         I recently got into a discussion of a related use case, I
>         believe this is being under discussion in the OMA PoC WG.
>         Imagine you are in an MSRP centralized conference, and you are
>         sending a (large) file to to the roster through an MSRP switch.
>         The sender would like to receive end-to-end progress reports of
>         the file transfer for each individual participant.
> 
>         I've heard of a few proposals to enable this use case, but in my
>         opinion, the simplest one is to reuse IMDN to provide
>         progressive positive reports. So that would add a third type of
>         report to IMDN to the existing two. So, the current ones are
>         positive-delivery and negative-delivery. I think a third one,
>         progressive-delivery would be nice to have, and will solve this
>         requirement.
> 
>             In the draft, we have 2: delivered and read. There has been
>             suggestions to add a least 2 more, namely processed and stored.
>             Stored is sent by a store-and-forward server to indicate
>             that an IM has been stored.
>             Processed is sent by intermediaries to indicate that the IM
>             has been processed (like a 202).
>             The sender of the IM is the one that requests any type of
>             IMDN. So, through the UI, the user has to answer all the
>             Of course these can be global settings, but still, too many.
>             when sending a SIP MESSAGE request, you will get the
>             transactional response 202 if the MESSAGE has been
>             processed. I don't see the need for IMDN to indicate so. I
>             also don't see why a user would want to know if a message is
>             stored or not. In any case, isn't this the same as processed?
>             Hisham
> ------------------------------------------------------------------------
> 
>     * *References*:
>           o *[Simple] IMDN Issue 4: Disposition Notification Types
>             <msg06743.html>*
>                 + /From:/ Hisham Khartabil
>           o *Progressive reports [Was Re: [Simple] IMDN Issue 4:
>             Disposition Notification Types] <msg06766.html>*
>                 + /From:/ Miguel Garcia
>           o *Re: Progressive reports [Was Re: [Simple] IMDN Issue 4:
>             Disposition Notification Types] <msg06768.html>*
>                 + /From:/ Hisham Khartabil
> 
>     * Prev by Date: *Progressive reports [Was Re: [Simple] IMDN Issue 4:
>       Disposition Notification Types] <msg06766.html>*
>     * Next by Date: *Re: Progressive reports [Was Re: [Simple] IMDN
>       Issue 4: Disposition Notification Types] <msg06768.html>*
>     * Previous by thread: *Re: Progressive reports [Was Re: [Simple]
>       IMDN Issue 4: Disposition Notification Types] <msg06768.html>*
>     * Next by thread: *RE: [Simple] IMDN Issue 4: Disposition
>       Notification Types <msg06745.html>*
>     * Index(es):
>           o *Date* <maillist.html#06767>
>           o *Thread* <threads.html#06767> 
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland