Subject: RE: [Simple] Sending 1 to n MESSAGEs

From: Cnaan Oded <[email-masked]>
Date: Wed, 25 Jun 2003 08:38:49 +0300

Inline

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2003 12:35 AM
> To: Dean Willis
> Cc: Mills, Duncan, D, CND Tech Dev, VF UK; [email-masked]
> Subject: Re: [Simple] Sending 1 to n MESSAGEs
> 
> 
> It depends. Do you want the recipients to know who else received the 
> message? Email works this way. If so, each recipient now 
> needs to pull 
> the list from the server too. That introduces requirements 
> for ACLs on 
> the list (members can pull them), and potentially for inter-domain 
> access to those lists, in the cases where members are in other 
> domains. Thus, if you send to N recipients, thats N+1 transactions on 
> the list - one to set it, N to fetch it.  So, the extra overhead is 
> multiplied N+1 times.
> 

Right. Besides that, instant messaging is all about the immediacy of message
delivery and this extra transaction doesn't serve this purpose. You would
probably use an HTTP connection to set up the group, and, especially on
mobile networks, this can take some time.

Another issue to consider is the multi-recipient message behavior. With
email, the list of recipients is sent to everybody (except for Bcc) so that
a 'reply-to-all' is allowed. However, this causes a spam problem as people
cannot remove themselves from these lists and will continue to receive
messages as long as someone replies to the message.

We can think of two modes of operation suitable for IM: (1) conversation -
where the mesage includes the recipients list and replies go to the entire
list (To, CC like) or (2) 1:many messaging - where the message includes only
the sender and replies are sent only to him (Bcc like).

> Another interesting issue with group messaging is delivery 
> confirmation. The 202 sent by the server, as suggested by 
> Chris, works 
> great to know that the exploder received the message. Do we have 
> requirements that the sender can find out if the message was 
> delivered 
> to each recipient?
> 
> IMHO, if we want to proceed here, we need to write some concrete 
> requirements on what the desired service is, and therefore be certain 
> that its different from what we can already do (i.e., conferencing 
> with session mode) before delving into solutions.
> 

I agree that a delivery report mechanism should be separate from SIP
acknowledgements. A user may not require a delivery report on each message
he sends (like with SMS and Email) and in the usual case may suffice with
having the proxy indicate that the message has been received and handled
(202).

> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 25 Jun 2003 15:55:49 -0400

At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote:
>email, the list of recipients is sent to everybody (except for Bcc) so 
>that a 'reply-to-all' is allowed. However, this causes a spam problem as 
>people cannot remove themselves from these lists and will continue to 
>receive messages as long as someone replies to the message.

Should such multi-recipient MESSAGEs be sent within a session to which a 
recipient could say BYE, future messages to the rejected session get 
silently discarded?

Or, seems like you would need to have an anti-dote header 
(X-Recipient-Remove-Me:) and a corresponding "Reply-All-Remove-Me" GUI 
button, that upon receipt could be handled without presentation by each 
recipient to trim the list.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Wed, 25 Jun 2003 15:55:49 -0400

Mike

---

From: Dean Willis <[email-masked]>
Date: 26 Jun 2003 11:27:24 -0500

Cnaan said:
> Right. Besides that, instant messaging is all about the immediacy of
> message delivery and this extra transaction doesn't serve this
> purpose. You would probably use an HTTP connection to set up the
> group, and, especially on mobile networks, this can take some time.

Well, it requires about 5 packets the first time the list is used
(pluswhatever data the list itself requires), and none after that.
Sending the entire list in every request might be more or less
efficient, depending on how large the list is and how frequently it is
used.

For example, envision an IM to 50,000 subscribers. The INVITE alone
might be 400kB in size (which is somewhat problematic all by itself).
Now fragment that over UDP, and you've got an intractable mess. Repeat
for the resulting 550,000 "replies to all". Ooh, let's not go there.

So, I think as Jonathan said, we need to look at this from a perspective
of requirements.

And we need to remember -- this is IM, NOT email.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: 26 Jun 2003 11:27:24 -0500

--
Dean