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: "Rosen, Brian" <[email-masked]>
Date: Tue, 24 Jun 2003 10:37:37 -0400

Was the salutation to your message a comment on the quality of
the discourse on this list?  ;)  

Good thought.  Interacts with conferencing (mass invite to a conference).
You don't want to have to have a complex interaction prior to sending
a list of recipients.  Smells like a kind of forking behavior, but 
clearly different (not all the same AOR).  Obviously creates multiple
dialogs if/when multiple responses are received.  The proxy can't be
the origination point; it's not a UA.  All the responses are going to
be forwarded to the UA.  The only way around that is B2BUA behavior.
Is that a better, or a worse idea?

Gotta think through what this means for Message Sessions.  You want the
proxy to replicate each message, but you don't really want to repeat
the list of recipients.  Does that argue for B2BUA more strongly?

With a B2BUA approach you send the message to the exploder.  It
sends individual messages to recipients, and handles all the dialogs.
That reminds me of a buddy list subscription without the prearranged 
buddy list.

Brian

> -----Original Message-----
> From: Mills, Duncan, D, CND Tech Dev, VF UK
> [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2003 9:42 AM
> To: [email-masked]
> Subject: [Simple] Sending 1 to n MESSAGEs
> 
> 
> 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.
> 
> 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

---

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

Dear CLEVER people (of the SIMPLE WG) ;-)

Brian- yes, my thought was to allow a B2BUA function to fork the MESSAGE request.  This way, the user doesn't have to pre-configure the recipient list, but perhaps they do have to pre-configure the address of their MESSAGING server (the B2BUA). When I say pre-configure, I'm sure there are more dynamic ways to get the B2BUA address to the UA.

I must admit, I am coming at this from the 3GPP perspective and so a SIP AS (acting in B2BUA mode) would seem to do the trick.  However, it would require- I believe- some extensions to SIP.

However, 3GPP radio interface constraints aside, I think it would be a shame to design SIP messaging without the ability to fork a message to n recipients, in the same way you can with e-mail.

Thanks for your initial thoughts- I'd be interested in progressing this issue, if you and others feel it worthwhile...

Cheers,

Duncan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 24 June 2003 15:38
To: Mills, Duncan, D, CND Tech Dev, VF UK; [email-masked]
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Brian

---

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

Cheers,

Duncan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 24 June 2003 15:38
To: Mills, Duncan, D, CND Tech Dev, VF UK; [email-masked]
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Brian

---

From: Chris Harris <[email-masked]>
Date: Tue, 24 Jun 2003 11:06:23 -0400

Duncan,

One possibility for this ad-hoc group messaging is to address the message to
a message exploder application, and to use other custom headers for the list
of actual recipients (say a list of X-Recipient: headers) that the exploder
understands. Once the exploder accepts the message it would presumably send
a 202 response to the sender and be responsible for the delivery of the
messages to the recipients.

Regards,
Chris Harris 

> Sent: Tuesday, June 24, 2003 10:55 AM
> To: Rosen, Brian; [email-masked]
> Brian- yes, my thought was to allow a B2BUA function to fork 
> the MESSAGE request.  This way, the user doesn't have to 
> pre-configure the recipient list, but perhaps they do have to 
> pre-configure the address of their MESSAGING server (the 
> B2BUA). When I say pre-configure, I'm sure there are more 
> dynamic ways to get the B2BUA address to the UA.
> 
> I must admit, I am coming at this from the 3GPP perspective 
> and so a SIP AS (acting in B2BUA mode) would seem to do the 
> trick.  However, it would require- I believe- some extensions to SIP.
> 
> However, 3GPP radio interface constraints aside, I think it 
> would be a shame to design SIP messaging without the ability 
> to fork a message to n recipients, in the same way you can 
> with e-mail.
> 
> Thanks for your initial thoughts- I'd be interested in 
> progressing this issue, if you and others feel it worthwhile...
> 
> Cheers,
> 
> Duncan
> 
>

---

From: Chris Harris <[email-masked]>
Date: Tue, 24 Jun 2003 11:06:23 -0400

Duncan,

Regards,
Chris Harris

---

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

Chris,

Thanks for your thoughts.  I agree, that a custome header of some sort would help.  I'd probably want to standardise that header with an RFC though- what are thoughts on this?

Duncan

-----Original Message-----
From: Chris Harris [mailto:[email-masked]]
Sent: 24 June 2003 16:06
To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; [email-masked]
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Duncan,

Regards,
Chris Harris

---

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

Chris,

Duncan

-----Original Message-----
From: Chris Harris [mailto:[email-masked]]
Sent: 24 June 2003 16:06
To: Mills, Duncan, D, CND Tech Dev, VF UK; Rosen, Brian; [email-masked]
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Duncan,

Regards,
Chris Harris

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Jun 2003 16:20:12 +0100

Chris,

	Wouldn't this be an expensive way of including a list of X-recipients (message size)?

Chris B.

>Sent: 24 June 2003 16:13
>To: Chris Harris; Rosen, Brian; [email-masked]
>Thanks for your thoughts.  I agree, that a custome header of some sort
>would help.  I'd probably want to standardise that header with an RFC
>though- what are thoughts on this?
>
>Duncan
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Jun 2003 16:20:12 +0100

Chris,

Chris B.

---

From: Chris Harris <[email-masked]>
Date: Tue, 24 Jun 2003 11:24:11 -0400

Chris B,

I would assume that such a header would use comma separated values to save
space e.g.

X-Recipient: sip:[email-masked], sip:[email-masked]

Chris H

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2003 11:20 AM
> To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian;
> [email-masked]
> >One possibility for this ad-hoc group messaging is to 
> address the message
> >to
> >a message exploder application, and to use other custom 
> headers for the
> >list

---

From: Chris Harris <[email-masked]>
Date: Tue, 24 Jun 2003 11:24:11 -0400

Chris B,

Chris H

---

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

Chris,

For the sake of a few extra addresses in the MESSAGE headers, for a 1000 byte MESSAGE request destined for 8 recipients, we can go from (for example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each recipient address requires 100 bytes).

I know which I'd prefer...

Duncan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: 24 June 2003 16:20
To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian;
[email-masked]

Chris,

Chris B.

---

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

Chris,

Duncan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: 24 June 2003 16:20
To: Mills, Duncan, D, CND Tech Dev, VF UK; Chris Harris; Rosen, Brian;
[email-masked]

Chris,

Chris B.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Jun 2003 16:38:38 +0100

Duncan,

	I totally agree, I'm not saying that the latter is an option.  I was just thinking of scale e.g. you want to 'explode' to say 80 people. I guess your exploder would be able to group Sip URL's for this purpose e.g. sip:[email-masked] which has been configured to fork to 80 contact addresses.

Chris.

>Sent: 24 June 2003 16:27
>To: Chris Boulton; [email-masked]
>For the sake of a few extra addresses in the MESSAGE headers, for a 1000
>byte MESSAGE request destined for 8 recipients, we can go from (for
>example) 8 * 1000 bytes to 1 * 1800 bytes (and that assumes each recipient
>address requires 100 bytes).
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Jun 2003 16:38:38 +0100

Duncan,

Chris.

---

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

Chris,

Yes, I think there are two cases here:

1.) The ability to 'explode' MESSAGES to a 'distribution list'

2.) The ability to send the same MESSAGE to several people NOT on a pre-configured distribution list (as Brian already pointed out, it would be complex to expect users to have to log onto a server in the network to set up a list every time)

I believe that 1.) can already be overcome in the way that you describe.  Basically, in this case, the user DOES have to set up the distribution list (a resource-URI) and send one MESSAGE to that list.

I am trying to solve case 2.)

Duncan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: 24 June 2003 16:39
To: Mills, Duncan, D, CND Tech Dev, VF UK; [email-masked]
Subject: RE: [Simple] Sending 1 to n MESSAGEs

Duncan,

Chris.

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Wed, 25 Jun 2003 12:49:30 +0100

Hi,

Ok, this seems like a good time to try to summarise the discussions so far- whilst the US is asleep in bed ;-) ! (I'll regret that)

1.) I believe 1:n instant messaging can be achieved by setting up a distribution list and giving it a resource-URI.

QUESTION: Do we need to update 'draft-ietf-simple-event-list-04' to include some messaging procedures, as currently it only seems to consider presence?

2.) Is it enough to solve 1.) ?  Do we need to alter/extend SIP to allow a MESSAGE to be sent to more than one recipient without the need to set up a recipient list on a server?  I have heard several good arguments for allowing a MESSAGE to be addressed towards several recipients without pre-configuring a list:

 - Reducing the number of messages (particularly in wireless systems)
 - Reducing the time it takes the user to send such a message
 - More like e-mail

There are also some issues related to any solution to 2.) that need to be thought through:

 - Do recipients need to see who else received the message?
 - Do we need the sender to receive delivery confirmations?

I'd like to encourage people to add to the two lists above (arguments for doing something & open issues) in order that I can perhaps work on some requirements.  Discussing solutions at this stage is perhaps premature...

Best Regards,

Duncan

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: 25 June 2003 09:10
To: Mills, Duncan, D, CND Tech Dev, VF UK
Cc: [email-masked]
Subject: Re: [Simple] Sending 1 to n MESSAGEs

Inline

> 1.) The ability to 'explode' MESSAGES to a 'distribution list'

I would say that this issue is solve with a resource list. I don't expect 
resource lists to be related to presence only. But taking a look at 
draft-ietf-simple-event-list-04 I see that it is considering only the 
presence case.

Does the WG think that there is space for generalization of the resource 
list, so that it is possible to use it not only for presence, but also for 
Instant Messaging?

> 2.) The ability to send the same MESSAGE to several people NOT on a pre-configured distribution list (as Brian already pointed out, it would be complex to expect users to have to log onto a server…

I believe SMTP and the Internet Message Format provides this capability, 
although SIP does not provide it today (probably because of the initial 
usage of SIP to establish point-to-point sessions).

But I believe that when we apply SIP for Instant Messaging there is a valid 
  use case that is worth investigating.

My first thought on a possible solution would be to relax the requirement 
of having a single To header field value, and a server providing the rest 
of the functionality. Nothing new, just following RFC 2822. Of course, we 
get the problem of how to populate the Request-URI...

> I am trying to solve case 2.)

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Wed, 25 Jun 2003 12:49:30 +0100

Hi,

Best Regards,

Duncan

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: 25 June 2003 09:10
To: Mills, Duncan, D, CND Tech Dev, VF UK
Cc: [email-masked]
Subject: Re: [Simple] Sending 1 to n MESSAGEs

Inline

/Miguel

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Wed, 25 Jun 2003 09:45:16 +0100

Hi,

Best Regards,

Duncan

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: 25 June 2003 09:10
To: Mills, Duncan, D, CND Tech Dev, VF UK
Cc: [email-masked]
Subject: Re: [Simple] Sending 1 to n MESSAGEs

Inline

/Miguel

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Wed, 25 Jun 2003 09:45:16 +0100

Hi,

Best Regards,

Duncan

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: 25 June 2003 09:10
To: Mills, Duncan, D, CND Tech Dev, VF UK
Cc: [email-masked]
Subject: Re: [Simple] Sending 1 to n MESSAGEs

Inline

/Miguel

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Jun 2003 18:16:34 -0500

So, you mean you want to have a *session* that clients can be
invited to and leave?

http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-00.tx
t

And you want the ability to have multiparty IMs in that session?

Cool. I'll see you at the XCON bof.

/a

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, June 25, 2003 14:56
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF
UK; [email-masked]

At 08:38 AM 6/25/2003 +0300, Cnaan Oded wrote:

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.

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: Adam Roach <[email-masked]>
Date: Wed, 25 Jun 2003 18:10:38 -0500

Paul Kyzivat [mailto:[email-masked]] writes:

> It should at least be technically possible to do the explosion in a 
> proxy rather than a B2BUA. If you address the message to an exploder, 
> and include the actual list of intended recipients as another header, 
> the exploder can act as a proxy, forking the message to each of the 
> intended recipients.
> 
> Done this way, the sender will receive a response from each 
> recipient...

Sorry, but no. Double-check proxy handling of forked messages
in 3261. For non-INVITE messages, you will receive only one
response (except in extremely rare and spectacular failure
scenarios). Even for INVITE messages, you'll receive more than
one response only in the case of certain race conditions (and
even then, you'll only get 200-class responses, possibly
preceded by a single 600-class response).

[Yes, I'm not counting provisionals]

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Jun 2003 18:16:34 -0500

/a

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, June 25, 2003 14:56
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF
UK; [email-masked]

Mike

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Jun 2003 19:01:21 -0500

Duncan Mills writes:

> 1.) I believe 1:n instant messaging can be achieved by 
> setting up a distribution list and giving it a resource-URI.
> 
> QUESTION: Do we need to update 
> 'draft-ietf-simple-event-list-04' to include some messaging 
> procedures, as currently it only seems to consider presence?

I think the problems are completely separable.

Keep in mind that the URI that you subscribe to with the
event-list extension semantically represents a group of
resources. If the server that allows you to subscribe to
an event-list can *also* receive MESSAGEs sent to that URI
and explode them to all the resources on the list, that's
something that it's perfectly okay to do.

If it wants to accept INVITEs sent to that URI and set up
a centrally controlled multiparty session, that's also
something that's perfectly fine, and kind of spiffy.

But that kind of binding really needs to remain an implementation
decision. I don't think we gain anything by having a standards
document -- even a BCP -- that describes such a property.

Bottom line: you can come up with fairly reasonable semantics
for just about any SIP request sent to a group resource
URI (and, in many cases, you can come up with several
useful semantics for the same method). Holding up event-lists
until we define this sort of thing for all existing methods
would not be realistic. And, even if we decided to do
so, the event-list document will be outdated as soon as a
new method is defined.

> 2.) Is it enough to solve 1.) ?  Do we need to alter/extend 
> SIP to allow a MESSAGE to be sent to more than one recipient 
> without the need to set up a recipient list on a server?  I 
> have heard several good arguments for allowing a MESSAGE to 
> be addressed towards several recipients without 
> pre-configuring a list:
> 

As Dean points out, the *protocol* can semantically:

 1) upload the list membership,

    PUT http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1
    Content-Type:application/foo+xml

    <?xml version="1.0" encoding="UTF-8"?>
    <list>
      <member>sip:[email-masked]</member>
      <member>sip:[email-masked]</member>
      <member>sip:[email-masked]</member>
    </list>

 2) send the message,

    MESSAGE sip:[email-masked] SIP/2.0
    <etc>

 3) and optionally destroy the list.
    DELETE http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1

...all without the user ever being aware of what's going on.
The experience is the *same* as e-mail: the user types in a
list of recipients and a message, and the message is sent to
those recipients.

>  - More like e-mail

The primary fallacy in comparing MESSAGEs to e-mail is that
e-mail necessarily uses SMTP servers that perform the explosion
that we're talking about. With SIMPLE, signaling can go directly
from one party to the other.

>  - Do recipients need to see who else received the message?

The answer to this will be "yes," "no," and "we need ACLs,"
depending on who in this working group decides to answer.

>  - Do we need the sender to receive delivery confirmations?

Message receipt confirmation is something that's been on our
list of things to do for some time now. The charter addresses
this as, "Included might be new mechanisms for message
confirmation delivery".

I think this probably is completely separable from the multiple
recipients problem.

As a related issue, you'll need to address the situation in which
an IM is sent to a group, and one such member is offline. Imagine
that this offline member has a message store that will play back
missed messages when he comes back online (cf. current SMS usage).
If the online recipients decide to respond to the message in such
a way that the response is sent to all the original recipients,
and a rather lengthy conversation ensues, the offline user is in
for an annoying torrent of messages -- probably stale -- when he
finally comes back online.

It's been brought up already, but I feel it is important enough
to reiterate: once you start doing *group* messaging, you *really*
want ways to invite users into the group session, and for them
to have the ability to accept or decline, and to leave once they
are no longer interested in the conversation. (In fact, I would
argue that this is one of the most glaring shortcomings of current
e-mail systems; how many times have you seen an e-mail begging,
"please remove my e-mail address from this discussion!"?) 

This points squarely at the use of MESSAGE sessions instead of
pager-mode messages. I would argue that any of the other models
proposed in this thread go so far in emulating e-mail as to repeat
its most annoying flaws.

/a

---

From: Cnaan Oded <[email-masked]>
Date: Thu, 26 Jun 2003 09:50:39 +0300

Mike,

Session based messaging is equivalent to a chat room (where users can join
and leave the room) and I was refering to the pager mode which is
sessionless.

My comment was that even when outside a session, the sender should be able
to choose between 2 modes, conversation (To list included) or 1:m (Only
sender included). This can be in a form of an indication to the distribution
server whether to include the list or not as part of the B2BUA behavior.

Oded

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, June 25, 2003 10:56 PM
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF
UK; [email-masked]

Mike

---

From: Goix Walter <[email-masked]>
Date: Thu, 26 Jun 2003 09:08:29 +0200

inline

> Sent: Thursday, June 26, 2003 8:36 AM
> To: Adam Roach
> Cc: 'Mills, Duncan, D, CND Tech Dev, VF UK'; [email-masked]
> Adam Roach wrote:
> Sure, the problems are separable, but they share a few similarities.
> 
> > 
> > Keep in mind that the URI that you subscribe to with the event-list 
> > extension semantically represents a group of resources. If 
> the server 
> > that allows you to subscribe to an event-list can *also* receive 
> > MESSAGEs sent to that URI and explode them to all the 
> resources on the 
> > list, that's something that it's perfectly okay to do.
> > 
> 
> That was exactly the similarity I found. You want to send a 
> MESSAGE to a 
> collection of receivers, identified by a list. That list 
> represents a group 
> that you may use also for presence purposes.
> 
> > a centrally controlled multiparty session, that's also something 
> > that's perfectly fine, and kind of spiffy.
> 
> That is not the intention... although you could do it.
> 
> > 
> I agree that a standards document or BCP is not the right way to move 
> forward. My initial proposal was to consider if a 
> generalization of the 
> event list would pay off.
> 
> > 
> > Bottom line: you can come up with fairly reasonable 
> semantics for just 
> > about any SIP request sent to a group resource URI (and, in many 
> > cases, you can come up with several useful semantics for the same 
> > method). Holding up event-lists until we define this sort 
> of thing for 
> > all existing methods would not be realistic. And, even if 
> we decided 
> > to do so, the event-list document will be outdated as soon as a
> > new method is defined.
> > 
> > 
> While the mechanism that Dean proposes works, it provides 
> some important 
> drawbacks: it introduces a new significant delay to setup the 
> list, so 
> Instant Messaging becomes more like ... Not-so-instant 
> Messaging. Further 
> more, it introduces new requirements in terms of bandwith to 
> setup and 
> delete this list.
> 
> 
> > 
> >     DELETE 
> http://xcap.example.com/s/im/users/12145551212/t1 HTTP/1.1
> > 
> > ...all without the user ever being aware of what's going on. The 
> > experience is the *same* as e-mail: the user types in a list of 
> > recipients and a message, and the message is sent to those 
> recipients.
> 
> I disagree with the "experience is the same as e-mail". In 
> e-mail or MMS 
> the user types the list of receives, press the buttom, and 
> the message is 
> sent. With the "XCAP mechanism on the fly", the user will 
> press the buttom, 
> does the XCAP operations (that will use some valuable time), 
> and finally, 
> if no error to setup the list, the message will be sent. Then 
> the process 
> continues to delete the list (something that may or may not 
> run in the 
> background). To me the user experience is not the same as e-mail.

Apart from the user 'experience' consideration which may be a bit
different, creating a destination list may be really convenient to save
bandwidth, and for the sender to configure centralized personal lists
that he can reuse across terminals, potentially giving the ability to
each member of the list to add/remove itself.
It may be interesting to investigate whether we want that list to be
known only by the sender (like a personal list that just helps the
exploder to fork IMs) or published to all recipients to simplify
reply-all functionalities.
Having such a list accessible to all original destinations may give each
of them the ability to remove itself from the list whenever he wants. In
any case, this would lead to ACLs and inter-domain issues.

Apart from HTTP, couldn't we use a REGISTER kind of list creation where
the sender enters a contact for each recipient and defines an expiration
date that may be refreshed. Based on policies (for example only allowed
to original contacts), this would give the ability in a SIP way for any
recipient to remove itself from the list at any time? That's probably
more for a 'single time' use while the HTTP solution may be better to
save lists persistently, but it doesn't require any specific
infrastructure.

As a side-effect the creation of temporary lists may create a virtual
chat room and I think we would really prefer session-based messaging for
that.
> 
> > 
> > 
> >> - More like e-mail
> > 
> > 
> > The primary fallacy in comparing MESSAGEs to e-mail is that e-mail 
> > necessarily uses SMTP servers that perform the explosion that we're 
> > talking about. With SIMPLE, signaling can go directly from 
> one party 
> > to the other.
> 
> Agree here. One of the requirements of a possible solution is 
> that the 
> MESSAGE has to visit an entity that provides the exploding 
> capabilities... 
> nothing new, exactly like in the event list.
> 
> > 
> > 
> depending 
> > on who in this working group decides to answer.
> 
> My take on this is that this is a sender option. Doesn't it 
> work like this 
> in e-mail with To, Cc and Bcc fields?

I totally agree. That should be a requirement. We may create a new
header for the 'multiple' To:, (like Too: ;-) ) that lists all primary
recipients to the MESSAGE and keep the To: as the exploder address or
the resource list address.
> Same as before. At the senders discretion.
> 
> > 
> > 
> > Message receipt confirmation is something that's been on 
> our list of 
> > things to do for some time now. The charter addresses this as, 
> > "Included might be new mechanisms for message confirmation 
> delivery".
> > 
> I agree here. The delivery confirmation is an issue not 
> related to the 1 to 
> n MESSAGEs problem.

I agree that the "mechanisms" for confirmation delivery itself should be
considered separately, but don't you think we should also give here the
requirement for the sender to be able to ask for delivery confirmation
in the MESSAGE itself as well, no matter the notification happens, or do
we need an explicit subscription? That subscription would allow to get
notified each time the user receives a message, but we probably would
need more complicated stuff such as other policies and filters.
A new Event type could be interesting to get notified and probably
simplier with no SUBSCRIBE and on a per-message basis, although it may
be interesting to configure it per recipient...
> 
> > 
> > 
> > As a related issue, you'll need to address the situation in 
> which an 
> > IM is sent to a group, and one such member is offline. Imagine that 
> > this offline member has a message store that will play back missed 
> > messages when he comes back online (cf. current SMS usage). If the 
> > online recipients decide to respond to the message in such 
> a way that 
> > the response is sent to all the original recipients, and a rather 
> > lengthy conversation ensues, the offline user is in for an annoying 
> > torrent of messages -- probably stale -- when he finally comes back 
> > online.
> 
> This issue is orthogonal to the 1 to n MESSAGE problem. You 
> can have to the 
> same problem today with regular IM systems.

Yeah, that probably depends on the way IM is handled for that recipient.
He may use a store-and-forward server typically for this use (like
e-mail and SMS) even if the message is stale (until the SAF server has
some policy to remove Expired MESSAGEs just like SMS) and have the
ability to disable the offline storage whenever he doesn't need it (or
based on trickier policies). In this case he'll just loose all IMs when
he's offline but that's the way IM usually works. I don't think we can
give more flexibility than this and users are quite used to these
mechanisms already.
> 
> > 
> > It's been brought up already, but I feel it is important enough to 
> > reiterate: once you start doing *group* messaging, you 
> *really* want 
> > ways to invite users into the group session, and for them 
> to have the 
> > ability to accept or decline, and to leave once they are no longer 
> > interested in the conversation. (In fact, I would argue 
> that this is 
> > one of the most glaring shortcomings of current e-mail systems; how 
> > many times have you seen an e-mail begging, "please remove 
> my e-mail 
> > address from this discussion!"?)

Ok, but group messaging is not only a message conference or a chat room,
even if these have there advantages to people to join and leave freely
or get invited. Group messaging in pager-mode also has its importance
and is well used in many communities. A sender may want to page some
friends and only get a single answer from each of them, not start an IM
session. I see the discussion here more related to this topic.
> > proposed in this thread go so far in emulating e-mail as to 
> repeat its 
> > most annoying flaws.
> > 
> > /a
> 
> /Miguel
> -- 

Walter
________________________
Laurent-Walter Goix
Telecom Italia S.p.A.
Telecom Italia Lab - StarSIP
Services Innovation - Intelligent Services and Platforms (SI/P)
Via Reiss Romoli 274
I-10148 Torino (Italy)
Tel. +39 011 228 5046
Fax +39 011 228 5069
E-mail mailto:[email-masked]
________________________
Visit us @ http://starsip.telecomitalialab.com

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to [email-masked]. Thank you
====================================================================

---

From: Goix Walter <[email-masked]>
Date: Thu, 26 Jun 2003 09:08:29 +0200

inline

Walter
________________________
Laurent-Walter Goix
Telecom Italia S.p.A.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 26 Jun 2003 09:35:00 +0100

Adam,
	Totally agree - message sessions are certainly the preferred
solution.  For those who insist on pager mode messaging (e.g. For SMS
style service replication) will have to overcome the associated problems
you mention (only one response) which can only realistically be achieved
by a B2BUA.

Chris.

>From: Adam Roach [mailto:[email-masked]]
>Sent: 26 June 2003 01:01
>To: 'Mills, Duncan, D, CND Tech Dev, VF UK'; [email-masked]
>Cc: Miguel A. Garcia

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 26 Jun 2003 09:35:00 +0100

Adam,

Chris.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 26 Jun 2003 10:14:35 -0400

>finally comes back online.

Maybe this is a philosophical point, but shouldn't there be a distinction 
between IM and email?  Or, put another way shouldn't IM be instant.  By 
definition, it they aren't online, they can't IM.  If someone is off-line, 
and you still want to send, use email.

Using sessions for messages probably prevents such stale-ness.  Perhaps, 
even without the session, a low value Expires header should be Recommended 
for group cases, rather than just a MAY.

Mike

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 26 Jun 2003 15:41:42 +0100

<<see comments>>
 
-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: 26 June 2003 15:15
To: Adam Roach
Cc: 'Mills, Duncan, D, CND Tech Dev, VF UK'; [email-masked]; Miguel A.
Garcia

Maybe this is a philosophical point, but shouldn't there be a
distinction between IM and email?  Or, put another way shouldn't IM be
instant.  By definition, it they aren't online, they can't IM.  If
someone is off-line, and you still want to send, use email.

Using sessions for messages probably prevents such stale-ness.  Perhaps,
even without the session, a low value Expires header should be
Recommended for group cases, rather than just a MAY.
 
[Chris Boulton] I agree.  And even if you had some device that collected
messages for you while you are not available to receive, shouldn't it be
local policy to reject with an appropriate SIP response or store the
message, configured by the user. 

Mike

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 26 Jun 2003 15:41:42 +0100

<<see comments>>
 
-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: 26 June 2003 15:15
To: Adam Roach
Cc: 'Mills, Duncan, D, CND Tech Dev, VF UK'; [email-masked]; Miguel A.
Garcia

 

Mike

---

From: Cnaan Oded <[email-masked]>
Date: Thu, 26 Jun 2003 18:03:38 +0300

Michael,

I accept your N:N and 1:N comment.

I believe that having it as a client policy will not prevent spam by clients
that don't obey this rule. I would rather have the client recieve only the
sender to make sure spam is prevented.

Oded

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, June 26, 2003 5:25 PM
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF
UK; [email-masked]

Oded,

Perhaps, we should be calling the mode where the list reaches the N
recipients N:N mode, whereas if only the sender (and a forking server) know
the full list, it is 1:N.  But, to be safe, it might be good to define
behavior such that if the list header with this mode indicator did reach all
on the list, they should be precluded automatically from doing a reply-all.

Mike

---

From: Cnaan Oded <[email-masked]>
Date: Thu, 26 Jun 2003 18:03:38 +0300

Michael,

Oded

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, June 26, 2003 5:25 PM
To: Cnaan Oded
Cc: 'Jonathan Rosenberg'; Dean Willis; Mills, Duncan, D, CND Tech Dev, VF
UK; [email-masked]

Oded,

Mike

---

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

Inline

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

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