Subject: [Simple] new I-D on data requirements

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 26 Jun 2002 10:12:49 -0400 (EDT)

Vishal,

> section 4.3 (protocol requirements)
>
> 1. Support for conference invitation to multiple users .Command can be
>   sent to buddy list server with buddy list name .Server MUST resolve
>   buddy list to buddy(s) and send INVITE message (or route through
> intermediate entity)
>   to all online users after checking their status.
>
> regards, vishal

This was not conferencing requirements draft.
Anyway, conf-reqs draft includes this mass-invitation 
requirement (as well as many other requirements listed also
in the buddylist reqs draft).

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jun 2002 10:52:19 -0400

> in the buddylist reqs draft).

Indeed, many of the functions here are needed for conferencing as well. 
This was the reason for my attempt to provide a generalized model at the 
end. It was my hope that this generalized model would support the data 
manipulation for conferencing as well. Certainly, conferencing has many 
other requirements that are beyond the scope of data manipulation, but 
some aspects are certainly in scope.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "jose" <[email-masked]>
Date: Wed, 26 Jun 2002 19:39:02 +0300

Hi,

Some comments!

> some aspects are certainly in scope.

Certainly, conferencing have many other requirements but probably the
proposed generic model would fit just as a piece within the conferencing
machinery.
(probably into the membership control).

Petri what do you think?
BR
Jose

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 26 Jun 2002 15:20:26 -0400 (EDT)

> (probably into the membership control).

I guess it is too early to speculate on that.
(well, it is always possible to speculate)

First we have to create and agree on the requirements
for all use cases (data/conference/group manipulation)
and then to analyse whether general create/add/delete etc
solution can be utilized for all of them.

It might be useful to have one common data manipulation
solution, and then a lot of extensions for specific use
cases. On the other hand, it may turn out that the
benefit of having one solution for a couple of
create/add/delete functions is relative small
if the real problems are elsewhere, and this
minor issue enforces the use of same mechanism 
for extensions as well (e.g. XML, SOAP, ACAP, whatever
mechanism). Moreover, it may require too many compromises
if we have to interpret for each command that "if this
is conference, then do this, if this is a buddylist then do that".
Buddylist and conference semantics are very close, 
but still different. 

General solution may also restrict the specific use cases too much. 
For example, buddylist requirements say that it must be possible 
to authorize only specific users to manipulate the list. 
What if conferencing scenario would like
to separate between delete and update operations ?
(this was just an example)

The danger is that the general solution always have to enable
the most complex and feature-rich solution thus combining
the worst of every use case. If own dedicated solution is 
developed for each use, it may be simpler and more effective.

But as said earlier, we have to wait for the requirements.