Subject: [Simple] Sending 1 to n MESSAGEs

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Tue, 24 Jun 2003 14:42:13 +0100

SIMPLE people,

I've just been thinking about how my e-mail works, and what I like best about it.  It is really easy to type a long message and then send it to a list of (more than one) people.  Better still, I don't have to have pre-configured that list of people.  I can just type in the addresses in the To: field and the mail will be sent to each address.

As far as I know, I can't do this with the SIP MESSAGE method.  Yes, I can create a resource URI in a server and send one MESSAGE request to that resource-URI, and the server may fork the MESSAGE to each URI in my pre-configured list.  But if I don't want to have to set up a new list of recipients each time I send a MESSAGE then I have to send the same MESSAGE several times.  Please correct me if I'm wrong.

Now... looking at this from a wireless operator perspective, I immediately see warning signs about my £6 billion radio interface ;-)  Currently, in GSM, if we want to send an SMS to more 'n' recipients, we have the same situation- either create a user group in the network or send the message 'n' times.  However, a SIP MESSAGE request is likely to be about ten times the size of an SMS.

Is this a problem?  If not, why not?  Maybe I'm missing some background/historical information?

If it is a problem, might it be possible to extend SIP in such a way as to state that the request-URI be set to the address of my SIP proxy server in my home network and then the To: field be filled with the list of intended recipients, with the server then being responsible for sending the MESSAGE to all the intended recipients?

Any comments/views?

Best Regards,

Duncan

Duncan Mills
Senior Engineer
Network Standards & Technical Audit
Technology Development (Network Systems)
Vodafone (UK) Ltd
Tel: +44 (0)1635 676074
Mob: +44 7867 900955
Fax: +44 (0)1635 234445
mailto:[email-masked]

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

---

From: Dean Willis <[email-masked]>
Date: 24 Jun 2003 13:37:05 -0500

Duncan pondered:
> I've just been thinking about how my e-mail works, and what I like
> best about it.  It is really easy to type a long message and then send
> it to a list of (more than one) people.  Better still, I don't have to
> have pre-configured that list of people.  I can just type in the
> addresses in the To: field and the mail will be sent to each address.

What if your application were to take care of the overhead of creating
and deleting the list for you? 

Scenario:

1) You enter multiple recpients in your GUI
2) The UA creates a recipient list on your messaging server witha
temprary name
3) The UA sends a message to the recipient list at the messaging server
4) When the list hasn't been used for a while, the UA or server deletes
it.

This is noce because it provides a chaching opportunity on dynamic lists
-- for example, if you send several messages to the same list, the list
of addresses has to be transferred only once over the "air interface".

The overhead of creating the list in a seperate server transaction is
slightly larger than that of including the entire list in the message
request (ala "X-recipient"). But not MUCH larger. . . so we gain an
advantage very quickly for repeat sends.

One could also envision a server-sidesystem that records these "dynamic
lists" and makes them available for re-use or server-side editing and
review. Perhaps it could work like the "recent calls" feature in a
phone, and the ten most recently used dynamic lists per device would be
available.

--
Dean

--
Dean

---

From: Dean Willis <[email-masked]>
Date: 24 Jun 2003 13:37:05 -0500

Scenario:

--
Dean

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jun 2003 17:35:12 -0400

inline.

> of addresses has to be transferred only once over the "air interface".

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.

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.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jun 2003 17:35:12 -0400

inline.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: 26 Jun 2003 13:23:38 -0500

On Tue, 2003-06-24 at 16:35, Jonathan Rosenberg wrote:

[...]

> with session mode) before delving into solutions.

I agree strongly that we not attempt any specification in this area
without agreeing on requirements first. I have had many offline
discussions on this very subject, both with co-workers and IETFers. None
have been particularly useful as there was no agreement on what
application we were trying to specify.

On another note, I notice that the more we add exploders and
store-and-forward relays, the more this starts looking like email.

---

From: Ben Campbell <[email-masked]>
Date: 26 Jun 2003 13:23:38 -0500

[...]