Re: Discussion needed - Server based SIP-Contact List

Hi,

I totally agree with Matthew concerning the contact-list
transfer. FTP wouldn't
be a good choice at all and wasn't really meant for that,
whereas LDAP seems the
most obvious choice and probably the easiest to implement.
What's more, we could
add support for central directory services afterwards. This
way telephone
directories could be queried to find & contact people
which aren't in the
contact list.

Sympho: About the privacy concerns, using LDAP would
enable us to
take advantage quite easily of TLS (ex-SSL, using
StartTlsRequest) to secure the
transfer on the network. But if I understand correctly, what
you're talking
about is avoiding to have private data leak out of a
third-party server. I guess
that we could find a way to send the contact-list already
crypted to the server,
but I don't know if it's really worth the pain (and it
probably wouldn't be 100%
secure). Anyway, as you suggested, somebody could always
host his own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho <symphorien.wanko-tchuenteulp.u-strasbg.fr>:

> Hi Thomas,
>
> Thomas Hofer a écrit :
> > Hi!
> >
> > One idea we have is a centrally stored contact
list for sip. I miss this
> > feature in sipcommunicator now, but I would
develop it as a plugin. I think
> > about exporting the contact list into xml (as it
is stored locally) and
> > upload it to an ftp-server, and download it on
startup.
> >
> > Has anyone thought about such a feature and
probably thought about some
> > reqirements?
> >
> >
> Yep, I have tought about it sometimes ago, and I think
it will be great
> to have such a feature.
> The main "problem" I see is privacy 
concerns.
>
> When someone has an account on some server, it is
obvious that this
> server stores its personal data.
> But what about storing them elsewhere ? If the user can
have a "trusty
> server" it is OK.
>
> Regards.
> > Yours, thomas
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> > For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> >
> >
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi,
I haven't worked with Google Base before but I feel a couple
of
problems with it:
  * some people don't like trusting their stuff to Google.
And that
includes SIP contacts.
  * from what I could grasp in a 20 seconds scan of the
Google Base
pages, all the data in there is publicly searchable which
might add
further privacy concerns.
I would go for LDAP as Matthew suggestes as it's best fit
for such
purpose and in extremis someone can run it's own server :P
(I know, it
has already been said)

All the best,
Mihai

On 8/28/07, D. Lazreg <dlazregyahoo.fr> wrote:
> Hi,
>
> Google database could be another solution.
> Check out API and you see !
>
> Dennis
>
>
>
>
> Chris <sipcomcyberspace7.net> a écrit :
> Hi,
>
> I totally agree with Matthew concerning the
contact-list transfer. FTP
> wouldn't
> be a good choice at all and wasn't really meant for
that, whereas LDAP seems
> the
> most obvious choice and probably the easiest to
implement. What's more, we
> could
> add support for central directory services afterwards.
This way telephone
> directories could be queried to find & contact
people which aren't in the
> contact list.
>
> Sympho: About the privacy concerns, using LDAP would
enable us to
> take advantage quite easily of TLS (ex-SSL, using
StartTlsRequest) to secure
> the
> transfer on the network. But if I understand correctly,
what you're talking
> about is avoiding to have private data leak out of a
third-party server. I
> guess
> that we could find a way to send the contact-list
already crypted to the
> server,
> but I don't know if it's really worth the pain (and it
probably wouldn't be
> 100%
> secure). Anyway, as you suggested, somebody could
always host his own LDAP
> server if his contact list is so sensitive ;).
>
> Cheers,
> Chris.
>
> Selon Sympho :
>
> > Hi Thomas,
> >
> > Thomas Hofer a écrit :
> > > Hi!
> > >
> > > One idea we have is a centrally stored
contact list for sip. I miss this
> > > feature in sipcommunicator now, but I would
develop it as a plugin. I
> think
> > > about exporting the contact list into xml (as
it is stored locally) and
> > > upload it to an ftp-server, and download it
on startup.
> > >
> > > Has anyone thought about such a feature and
probably thought about some
> > > reqirements?
> > >
> > >
> > Yep, I have tought about it sometimes ago, and I
think it will be great
> > to have such a feature.
> > The main "problem" I see is privacy
concerns.
> >
> > When someone has an account on some server, it is
obvious that this
> > server stores its personal data.
> > But what about storing them elsewhere ? If the
user can have a "trusty
> > server" it is OK.
> >
> > Regards.
> > > Yours, thomas

Hi everyone,

I agree with what Matthew said about LDAP being the perfect
solution.

However, I think that an eventual implementation of a
file-based  
server storage agent (working over FTP/SFTP/HTTP/...) can
also be  
useful. I'm saying "agent" because I think that
the same concept may  
be reused - one may wish to have server stored message
history,  
photos, etc. Of course, there are many issues that have to
be  
resolved, like encrypting everything that goes to the
server, etc. I  
think of a service that receives a URL (like
ftp://freestorage....../ 
scaccounts/) and downloads all information relative to the
current  
user from that location. Furthermore, if at some point
someone tells  
the same service - "hey, I'd really appreciate if you
can keep the  
file 'sip-communicator/specialsettings.xml'", the
service would  
handle the request by itself (uploading the encrypted file
with  
eventually adding some metainformation, ... AND doing this
each time  
the file changes).

So, just to summarize - having a purely file-based approach
would  
bring in some great flexibility (once implemented for FTP it
would be  
relatively easy to add support for other protocols, with the
only  
difference being the protocol-specific code) BUT is not a
very clean  
solution (i.e. to achieve a true asynchronous contact list
loading  
one has to download the file + parse the XML).


In all cases I don't think that this is going to be the
major  
problem. LDAP is certainly going to provide some nice
querying  
abilities and a "true" asynchronous data loading
(and is THE way to  
do this thing), but it's not going to address the main issue
-  
merging the incoming Metacontacts.

In my view there are two approaches to this problem (which
do not  
depend on the underlaying server storing mechanism) :

1) (SYNC) Download the data BEFORE any other service is
launched (or  
just tell all other services to wait quietly and do nothing)
and then  
merge the local information with the server-side
information. After  
the data is merged, all services are told to resume their
execution.
This solution may significantly increase the load time of
the  
application (the client will have to wait for a connection
timeout if  
for example the remote server is down), which I think is
going to  
seriously degrade the user experience. Additionally, I think
that  
there will always be some cases in which one would have to
perform  
asynchronous contact merging (thus falling in the second
category).

2) (ASYNC) Download the data in parallel to other services
that are  
being loaded. That means merging Metacontacts on the fly.
In my opinion this is a case that should be addressed.
Currently SC  
merges the locally contained contact information with
incoming  
protocol specific server-stored contacts, but I don't know
if the  
same mechanism is going to work right away when Metacontacts
are  
going to start flying in. Can anyone tell the rules upon
which  
contacts are currently merged and if this is going to work
for  
Metacontacts?


The best thing would be to allow users to store their data
on  
different kinds of servers but given the limited resources
we have I  
would also go with the LDAP solution.

Regards,
Alex



Le 28 août 07 à 15:52, Chris a écrit :

> Hi,
>
> I totally agree with Matthew concerning the
contact-list transfer.  
> FTP wouldn't
> be a good choice at all and wasn't really meant for
that, whereas  
> LDAP seems the
> most obvious choice and probably the easiest to
implement. What's  
> more, we could
> add support for central directory services afterwards.
This way  
> telephone
> directories could be queried to find & contact
people which aren't  
> in the
> contact list.
>
> Sympho: About the privacy concerns, using LDAP would
enable us to
> take advantage quite easily of TLS (ex-SSL, using
StartTlsRequest)  
> to secure the
> transfer on the network. But if I understand correctly,
what you're  
> talking
> about is avoiding to have private data leak out of a
third-party  
> server. I guess
> that we could find a way to send the contact-list
already crypted  
> to the server,
> but I don't know if it's really worth the pain (and it
probably  
> wouldn't be 100%
> secure). Anyway, as you suggested, somebody could
always host his  
> own LDAP
> server if his contact list is so sensitive ;).
>
> Cheers,
> Chris.
>
> Selon Sympho <symphorien.wanko-tchuenteulp.u-strasbg.fr>:
>
>> Hi Thomas,
>>
>> Thomas Hofer a écrit :
>>> Hi!
>>>
>>> One idea we have is a centrally stored contact
list for sip. I  
>>> miss this
>>> feature in sipcommunicator now, but I would
develop it as a  
>>> plugin. I think
>>> about exporting the contact list into xml (as
it is stored  
>>> locally) and
>>> upload it to an ftp-server, and download it on
startup.
>>>
>>> Has anyone thought about such a feature and
probably thought  
>>> about some
>>> reqirements?
>>>
>>>
>> Yep, I have tought about it sometimes ago, and I
think it will be  
>> great
>> to have such a feature.
>> The main "problem" I see is privacy 
concerns.
>>
>> When someone has an account on some server, it is
obvious that this
>> server stores its personal data.
>> But what about storing them elsewhere ? If the user
can have a  
>> "trusty
>> server" it is OK.
>>
>> Regards.
>>> Yours, thomas
>>>
>>>
------------------------------------------------------------
-------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribesip- 
>>> communicator.dev.java.net
>>> For additional commands, e-mail: dev-helpsip- 
>>> communicator.dev.java.net
>>>
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip- 
>> communicator.dev.java.net
>>
>>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net