Re: SIP SIMPLE end-point addressbook application

Comments:

  - Tight binding of presence service/conveyance and an AB is poor design and counters the KISS pattern (http://www.objectmentor.com/resources/articles/srp.pdf)
    - A presence capable AB is fine, but presence conveyance should equally serve other communication/services as well (translation: don't mix these together)
        - a corollary to this is an AB does not need to be presence capable (it can and would benefit from this - but it should be a MAY not a SHOULD or MUST/SHALL)
    - If the AB can't be designed in such a way as to 'plug replace' pres-info publication/conveyance (regardless of protocol/transports) then the model is wrong 
        - BTW - pres-rules has nothing to do with an AB it is a generic policy mechanism for deciding who see's what (when a candidate observer comes calling)
 
 - Overlap of work already taken place in OMA 
    - given we are now in the all-IP era - I would strongly recommend (those with an open mind) re-investigate at least in Converged Address Book 1.0
        - a CAB API Enabler is also being developed (RESTful) from the work in CAB 1.0
    - enhancements have also been made in CAB 1.1 for social-networking, including discovery of mutual contacts (a useful enhancement)
    - support in 1.1 also includes connecting to 3rd-party platforms (e.g. import/export of non-CAB) 
    - CAB also has a single single data-model/schema and mappings from vCARD described

Further comments:
 - Discussion between PaulK and Adrian (re: dialogues) isn't interoperability - that is orchestration (i.e. managing dialogues to complete one or more aggregate functions)
    - if ALL exchanges (on the wire) follow conformant aspects of the respective RFC, then by extension they are interoperable (at the RFC level)
    - The combine of conformant call-flows (from the respective RFCs) to me is more in the scope of a service Enabler (something OMA deals with) - not a component RFC
       - Why does IETF want to reinvent work (Converged Address Book) already carried out in OMA?  
 
Thoughts to ponder. 



> From: [email protected]
> Date: Wed, 17 Oct 2012 21:12:49 +0200
> To: [email protected]; [email protected]
> Subject: [Simple] SIP SIMPLE end-point addressbook application
> 
> Hi Olle,
> 
> I changed the original subject, as we all like success stories rather than failures.
> 
> For Blink in particular, we developed a simple (pardon the over abused word) to use AddressBook schema where one can store Contacts with multiple URIs of different types and arbitrary attribute-value pairs that the User Agent may need to store per contact plus a way to Group them together. To subscribe for presence to a contact and provide a policy one can set boolean values that any developer not familiar with the SIP protocol mechanics should be able to use. Information that is proprietary to end-points made by a vendor can be stored, atomically and in a way that does not collide with the desires of other vendors.
> 
> The schema is documented here:
> 
> http://sipsimpleclient.com/projects/sipsimpleclient/repository/entry/sipsimple/payloads/xml-schemas/addressbook.xsd
> 
> An actual implementation in Python is available here;
> 
> http://sipsimpleclient.com/projects/sipsimpleclient/repository/changes/sipsimple/payloads/addressbook.py
> 
> To eliminate the complexity and eliminate the non-atomicity of having to use several XCAP documents like rls-services, resource-lists and pres-rules for storing these information. 
> 
> I propose to define, part of a further standardization effort of SIMPLE or another IETF WG that is chartered for this purpose, the SIP SIMPLE end-point addressbook application, an application that can be used both by end-points and the Presence Agent for obtaining the policy for subscribing to one's presence.
> 
> This way, we can achieve two goals closely related to SIMPLE charter:
> 
> 1. Any SIP end-point developer can develop its own SIMPLE implementation perfectly inter-operable with any other SIMPLE end-point and compatible at the same time with the server side, the presence agent.
> 2. As interest with XMPP is on the rise, we can now capture all gateway features that will make the interoperability with XMPP 100% defined and proven by open source implementations
> 
> For those who do not adhere or care about such high-level API, they may continue to use at their discretion the low-level building blocks already in place as nothing will change on-the-wire between domains or within the same domain as far as SIP signaling is concerned.
> 
> Shall these goals be considered a desirable outcome for SIMPLE, in the old tradition of good ideas backed not just be empty words but by open source implementations, there might be a chance to turn SIMPLE into a success story.
> 
> Feedback is welcome.
> 
> Adrian
> 
> On Oct 17, 2012, at 8:22 PM, Olle E. Johansson wrote:
> 
> > 
> > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu <[email protected]>:
> > 
> >>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work solution. Not sure what that will achieve.
> > 
> > That's fine, but a separate project. If the only way we can get interoperability between SIMPLE implentations is using XMPP between them, that feels like a stupid solution to me. I do want to be able to use SIMPLE to communicate with other SIMPLE implementations. I want to be able to use one SIMPLE client from one vendor on my smartphone and share the address book/buddy list and presence ruleset with my other SIMPLE client on the desktop.
> > 
> > That's what customers expect. And that's not where we are today with the IETF specs, and if I parse right, maybe not with the inclusion of the 3rd party OMA specs.
> > 
> > /O
> > _______________________________________________
> > Simple mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple