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

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:
> 
>  - Reducing the number of messages (particularly in wireless systems)
>  - Reducing the time it takes the user to send such a message

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.

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

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

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 26 Jun 2003 09:35:35 +0300

> I think the problems are completely separable.

Sure, the problems are separable, but they share a few similarities.

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

> something that's perfectly fine, and kind of spiffy.

That is not the intention... although you could do it.

> document -- even a BCP -- that describes such a property.

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.

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

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.

> list of recipients and a message, and the message is sent to

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.

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

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

Same as before. At the senders discretion.

> I think this probably is completely separable from the multiple

I agree here. The delivery confirmation is an issue not related to the 1 to 
n MESSAGEs problem.

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

> proposed in this thread go so far in emulating e-mail as to repeat

/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: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 26 Jun 2003 09:35:35 +0300

/Miguel