Re: Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?

2012/10/18 Paul Kyzivat <[email protected]>:
> ISTM that a buddy list can be considered as a subset of an address book.
> There are lots of things I keep in an address book that have nothing to do
> with my presence buddy list.
>
> Setting out to define a complete address book seems like a dangerous
> slippery slope.

I agree with this.

  buddylist != addressbook

A buddylist is a list of entries with:
- key: uri
- value: attributes for the uri related to subscription/authorization.

An addressbook is a list of entries with:
- key: anything, i.e. full name or an ID.
- value: like vCARD data or whatever.


We should keep both separated. Take a look to MSN, Skype, Yahoo
Messenger, XMPP, etc... You manage a buddylist, not an addressbook.

Now take a look to your iPhone or Android: you manage an addressbook,
and the addressbook inspects the buddylist of installed apps for
merging/integrating different "contacts" into one.


The problem of SIMPLE is that is the RFCs don't even specify a
buddylist but a "resource-list" that IS NOT a buddylist because:

- A resource-list document is structured in "groups" that contains
URIs, so a URI could exist in more than a "group" and each group
"could" have different meanings (or not), and a "group" can include a
"link" to other groups that also include links to other groups, etc,
etc. That's unmanageable for a client application that just wants to
render buddies and their properties.


In the other side, an addressbook is an extra layer over the
buddylist. For example:

- The buddylist contains buddies definitions.
- A buddy includes an attribute "addressbook_id".
- A buddy also includes other attributes related to SIP presence,
authorization, etc (no display-name or home location here).
- The addressbook has "id" as key and something like a vCARD as value.

So you can have a single contact in your adressbook with id=5 and two
or five associated buddies in the buddylist (all those buddies with
addressbook_id=55).

The client application should of course manage both "documents" (the
buddylist and the addressbook) all together, but IMHO this is a
terribly EASY task in comparison with managing the XCAP documents as
defined by SIMPLE, right?


Regards.



-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple