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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Jun 2002 22:25:12 -0400

Folks,

Myself and Markus Isomaki have submitted an Internet Draft that is a 
first cut at requirements for management of buddy list and authorization 
list functions (this is also a new item on our charter). Until it 
appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt

In addition to the baseline requirements for these functions, the draft 
also proposes a model for unifying these problems. This is also a first 
cut; comments and criticisms and welcome.

My aim is to determine if there is consensus to adopt this as the 
starting point for our work item on this topic.

Thanks!

-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: "vishal" <[email-masked]>
Date: Wed, 26 Jun 2002 11:52:26 +0530

Dr Jonathon,
   I think following requirements can also be added to this draft
section 2.2

1. Server SHOULD be able to contact other servers in case buddy list
   not found in local storage.
2. server should be able to accept requests coming directly from client
  or via intermediate entity like proxy (if it includes authetication
  info).
3. server should be able to route response over same route as request i.e
   support for record-route.
4.  MUST have Multicast capability at server i.e UDP support .In case buddy
list  shared by many user ,modified by one user then server SHOULD be able
to synchronize cache of
clients.
5. Server SHOULD be able to limit maximum number of users sharing buddy
   list.
6. Server SHOULD be able to specify maximum buddy list nesting(list within
list) level.

section 2.2 REQ 8: A buddy list should be considered deleted when all the
owners of buddy list have deleted it. Deleted buddy list should not be
accessible after deletion

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

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 26, 2002 7:55 AM
Subject: [Simple] new I-D on data requirements

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

---

From: Costa Requena <[email-masked]>
Date: Wed, 26 Jun 2002 16:20:55 +0300 (EET DST)

Hi Vishal,

>    not found in local storage.

Are you proposing some recursive mechanism in case the buddy list contain a 
nested buddy list? It could be OK if the nested buddy list is within the 
same domain but it could have some security flaws when fetching the buddy list 
from other serves/domain. I think it should be stated that nested buddy list 
should contain FQDN within the local domain.

> list  shared by many user ,modified by one user then server SHOULD be

Correct me if I'm wrong but is the idea to share the same buddy list by multiple 
users? I think that each presentity has its own buddy list, despite he/she can 
use different list to perform the buddy list functionality. The same buddy list 
can be used from different termianls but still the owner or presentity  is the 
same.

BR
Jose

---

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

>    not found in local storage.

Let me make sure I understand. I want to manipulate the list 
sip:[email-masked]. So, I contact the server for example.com. It 
realizes that it doesn't own domain.com, so it forwards the control 
requests to domain.com. Is that what you want?

If so, it sounds like a basic proxy function, as provided by both SIP 
and HTTP as well. If thats what you mean, I am OK with that.

>   or via intermediate entity like proxy (if it includes authetication

Is this not the same as 1.?

>    support for record-route.

Are you talking about the requests to manipulate the buddy list? There 
is no notion of session here - this is a transactional/RPC type of 
protocol. Record-routing makes no sense for transactional mechanisms. 
Thats why you can't record-route OPTIONS in SIP. If you are asking for 
the response to follow the same path as the request, thats part of the 
definition of proxying.

> list  shared by many user ,modified by one user then server SHOULD be

I agree with the existence of multiple clients. Thats already captured 
in REQ 12. However, cache synchronization (which is also a requirement) 
is not the same as multicast, and I would personally rather shoot myself 
in the head than try to develop a distributed cache synchronization 
protocol using multicast. Regardless, this document is about 
requirements, not implementation, and I believe the requirement for 
multiple cached copies, each of which can be manipulated, is already 
captured in REQ 11 and REQ 12.

> 5. Server SHOULD be able to limit maximum number of users sharing buddy

What does it mean to "share" in this context? Share meaning "number of 
simultaneously cached copies?" Share meaning "number of subscriptions to 
the list"?

> 6. Server SHOULD be able to specify maximum buddy list nesting(list

Since the a list within a list may not be local, there is no way for a 
server to even know what the depth is, since the tree is effectively 
distributed across the servers that own the various lists. From the 
perspective of a server, each list is of depth one - it contains entries 
that are subscribed to, period.

> accessible after deletion

You have a different model in mind than is currently specified in the 
document. I think you view there as being a list that is replicated once 
for each "owner" that accesses the list. When an owner modifies their 
replicated instance, that change is copied across all other instances. 
However, when deleted, only their instance is deleted. The list would 
still continue to exist for others.

I don't really see the benefit in this model, as opposed to the current 
model, where there is just one list.

>    to all online users after checking their status.

This is outside the scope of this document. This document is about 
manipulating the list. As Petri has pointed out, you are asking for a 
mass invitation function, which is covered in his conferencing 
requirements document.

-Jonathan R.

---

From: "vishal" <[email-masked]>
Date: Thu, 27 Jun 2002 18:33:54 +0530

Hi,
  please find my comments below
regards, vishal

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: vishal <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 26, 2002 8:20 PM
Subject: Re: [Simple] new I-D on data requirements

> and HTTP as well. If thats what you mean, I am OK with that.

yes , I mean buddy list server(BLS) MUST be able to forward incoming
requests to appropriate BLS .(As i understood BLS is separate component than
proxy so BLS SHOULD also support this feature).

> the response to follow the same path as the request, thats part of the
    (no comment)
> simultaneously cached copies?" Share meaning "number of subscriptions to
     I mean "number of subscriptions to the list ".

> that are subscribed to, period.
  yes I agree... if the list is not local then this info can not be
maintained but
 this is useful info.
> model, where there is just one list.

Different instances mean ,server will track number of users sharing this
list and their association with user(s).As soon as somebody deletes list
,his association will be deleted and number of instance will be decremented
.No need to maintain separate copy of list.This list will not "visible" to
the user who deleted .Similarly if new user wants to associate itself then
just
adjust number of instance and association ,no need to create list. (I
apologise for discussing implementation issues here...)