Subject: [Simple] Requirements to SIMPLE components continuation

From: [email-masked]
Date: Fri, 22 Mar 2002 07:55:39 +0200

Hi,

It seems that work based on the proposals in the SIMPLE components draft is getting started within SIMPLE and SIPPING.

In addition to those mentioned in the draft and presentation, I would like to propose the following requirements:

- Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possible to send a private (i.e. only shown to the selected recipient, not the whole conference) message between two participants. It must be possible to correlate it somehow on the ongoing conference, so that it can be shown correctly on recipient's chat window, meaning that a completely separate one-shot message is not the right solution.

- Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. So, basically the presence doc. is formed based on who is asking for it, and there must be a way for the presentity to control this.

- Presence subscription filtering. This means that a Watcher should be able to presence to the changes in certain _part_ of the presence info. If other parts change, NOTIFYs are not generated.

Do these seem like reasonable requirements? Are there already solutions for these, or should they be included in the starting work?

Markus  
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Mar 2002 14:21:37 -0500

> - Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possibl…

I question this. Why should private side messages involve the conference as a whole at all? This seems to violate the notion of the conference. And, why would I trust that
a message delivered through a conference server will only been seen by my intended recipient? My willingness to trust this will probably vary depending upon how the
conference is implemented. (For instance if the moderator of the conference is not my intended recipient.)

I would prefer that the side conversations be entirely independent the shared conferencing components - via page-mode MESSAGE exchanges, or via a separate MESSAGE session.

(This doesn't prohibit the GUI tying these together, based on In-Reply-To headers or the like.)

> - Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. S…

This may be probematic because of scaling problems. If a separate view has to be computed for every watcher then it may not be possible to use use presence servers to
distribute presence state to the masses.

However, it might make sense to access-control the various presence attributes, so that only certain people are permitted to see detailed information while a larger set of
people may see more general information. This would fit in well with filtering - requests for too much detail might fail for some users, where they would succeed when using
a suitable filter. (Or else, the required filter could be automatically applied to avoid refusing the request.)