Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 15:14:26 +0200

Hi Brian,

I keep this on the mailing list, hope you do not mind.

On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote:

> Hi Adrian,
> 
> I looked at your site for the API, and had some comments.
> 
> My concern is that the API you developed is a series of wrappers around a lot of complexity in SIP/SIMPLE, and xcap, etc.  That explains the 15kloc of code!  

Indeed. In XMPP, this so called wrapper is defined well enough in the core specification that can be interpreted in the same way by any client or server implementor. SIMPLE lacks this. 

> Not sure why folks are talking about an addr-book and SIP/SIMPLE (or an rls for that matter) in the same breath.  They are NOT the same thing.  If you want to understand why, look at OMA Converged Address Book 1.1 for the reasons why that is the case.

From the perspective of both the UI developer and the end-user, they are 100% the same thing. From a standards perspective they are not, and here is the cause of the problem.

> If we go 'way back' to the days when Rosenberg was involved in SIP/SIMPLE and xcap, the idea was to have an ability to manipulate a (~20 member or smaller) buddy list.  Most people now have networks (contact-lists of 100 people or more).  And the 'social meshing' expands our potential connections well beyond this.  One reason that the watcher scale issue would be exacerbated sooner than later (as pointed out by Houri, et al in his inter-domain scaling analysis on PRS).
> 
> Xcap and indeed (XDM) have gone way beyond that now.  However, the complexity remains.
> 
> What I don't see in the API is a model or approach - based on typical consumption patterns. 
> 
> Presence Access Layer made several assumptions:
>  - a presence aware service knows what indicators they need to fulfill functions (the rest is irrelevant)
>  - each watcher has (per SIMPLE) a view of presence; based on the view the presentity 'permits' the user to see (via presence rules)
>  - that view X the presence aware service = presence context (contextually oriented presence) 
> 
> That model simplifies the interface and strips out the details from a client.  

This model does not simplify but is the very cause of complexity, is the root cause of ending up building clients that do not interoperate with each other under the same account.

> Interop is bandied about a lot, but what isn't clear is whether we are talking 'on the wire interop' or 'coded interop' (I.e. I am coding to an interface that is identical whether I am using an underlying X or Y).  Fill in the blanks on X and Y (X can be XMPP, Y the other flavor).  

By interoperability, I  mean that developer A can develop a SIMPLE client that can be interchanged with a SIMPLE device developed by B. The address book and presence rules should work with both clients same as today I can use several XMPP clients from different vendors  and all work fine with the same contacts list. For example I have an Android mobile device from one vendor and a MacOSX client from another vendor and on XMPP this works. I cannot use them both for my account with SIMPLE as they will both write different data according to their interpretation of SIMPLE standards. The server implementor will also have yet another way of interpreting the data. This triangle cannot be reproduced with any combination of SIMPLE implementations but it can with XMPP.

> I don't view a presence conveyance as an addr-book.  You need a dedicated API - OMA was developing one on Converged Address Book 1.0.  You know the saying - to a carpenter everything is a 'hammer and nail problem'!

I studied OMA years ago and dropped it, as several assumptions made have nothing to do with real world and how the Internet works, is a interpretation that (could have) served closed silo-style Telco infrastructures, and not end-points from public Internet.  Not to mention the complexity of OMA on top of an already complex foundation.

> If that doesn't suit - then to me a RESTful approach may be the way to go.

What do you have in mind, can you give an example?

> 
> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work solution.  Not sure what that will achieve.
> 
> BR/Brian.
> Sent from my BlackBerry device on the Rogers Wireless Network
> 
> -----Original Message-----
> From: Adrian Georgescu <[email-masked]>
> Date: Mon, 15 Oct 2012 15:46:14 
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it
> an 	IETF failure?
> 
> 
> 
> 
> On Oct 15, 2012, at 2:57 PM, Brian McColgan wrote:
> 
> 
> My analysis indicates RLMI doesn't scale, but you/AG allude to an interop issue with buddy lists.  Can you be more specific and outline the issue?
> 
> 
> 
> More specific. In SIP SIMPLE client Presence API we defined Group, Contact and Policy classes each of them with add/delete/update methods and eight notifications in total to manage the address book. Subscribing to Presence for a contact and granting access to our own presence information are booleans that can be set for each contact.  To achieve this simplicity, we had to write about 15K lines of code in a high level programing language.
> 
> 
> We do not have an IETF definition of such address book API, that any programmer would understand, what we have instead are a number of XML payloads, several event packages and xcap applications. Glueing all of them is  up to the developers and they end up in different places as you have heard already from several developers. Secondly, without being able to control the behavior of the server side, there is little chance a generic SIMPLE client would work with any SIMPLE server as the assumption are different and the incapability of the server to support same features used by the client will render the client useless. We could only do this because we were able to develop at the same time both the presence client and presence agent side (OpenSIPS and OpenXCAP). 
> 
> 
> XMPP has this approach where and both server and clients can implement the same addressbook api without running into any interoperability issues.
> 
> 
> Adrian
> 
> 
> 
> 
> 
> 
> In IMS, they are using pre-defined (i.e. Well known) buddy lists - e.g. "rcs" for the list of RCS-capable users. But I don't think this is what you are referring to.
> 
> BR/Brian.
> 
>>  Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?
>>  From: [email-masked] <mailto:[email-masked]> 
>>  Date: Mon, 15 Oct 2012 08:50:32 +0200
>>  CC: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
>>  To: [email-masked] <mailto:[email-masked]> 
>>  
>>  
>>  14 okt 2012 kl. 23:48 skrev "Brian McColgan " <[email-masked] <mailto:[email-masked]> >:
>>  
>>  > Good luck with that Adrian. As I said 'IETF' doesn't get it.
>>  
>>  Which takes us back to my original issue - can we get IETF to fix SIMPLE?
>>  
>>  /O
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Oct 2012 08:31:22 -0600

> On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote:

<snip/>

>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE 
>> inter-work solution.  Not sure what that will achieve.

I don't know whether the IETF is plowing toward an interwork solution.
All I know is that vendors and service providers who deploy
SIMPLE-based systems often want to enable their users to communicate
with users of XMPP-based systems (share presence, chat one-to-one,
join chatrooms). If we define protocol mappings, such gateways will be
easier to build and will work in more consistent ways. That seems like
a good thing.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 17 Oct 2012 17:26:05 +0200

On Oct 17, 2012, at 4:31 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Can't +1 this enough.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Mary Barnes <[email-masked]>
Date: Wed, 17 Oct 2012 10:26:45 -0500

> easier to build and will work in more consistent ways. That seems like
[MB] I totally agree! [/MB]

>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlB+wToACgkQNL8k5A2w/vx1yACcDvKRP2BYGbejcKaASJOATguH
> hncAoOW4PFwPX1AMvd8NM+cjofprjuH9
> =xkZl
> -----END PGP SIGNATURE-----
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Oct 2012 17:42:22 +0200

> easier to build and will work in more consistent ways. That seems like

Hi Peter, I think this thread is not about SIMPLE/XMPP
interoperability (which is good) but about SIMPLE/SIMPLE
interoperability.

With the current IETF SIMPLE specs is just impossible that two SIP
vendors that build generic SIP devices will interoperate for sharing a
simple addressbook by using a generic SIMPLE/XCAP server made by any
other vendor. And this is just because the RFC's don't define the
exact format of the XML files to use, so each vendor follows its own
interpretation. Said that, there is also no way for storing info other
than "dislplay-name" and "uri" per buddy so we DO NOT have a
"addressbook" in SIMPLE/XCAP, at least not in the IETF documents (and
I don't think that I should follow OMA/3GPP specs designed for telco
networks if I code a generic and open source SIP client for the open
Internet).

So, before attempting to interoperate with XMPP I think SIP should be
able to interoperate with itself in a generic IP network (out of
walled gardens in which vendors have full control over servers and
clients, and can design their required extra layers on top of the IETF
specs to complete the puzzle).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Oct 2012 10:48:21 -0500

> interoperability (which is good) but about SIMPLE/SIMPLE

It looks to me that the thread has forked into both discussions. Perhaps people could adjust their subject lines?

Thanks!

Ben.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Oct 2012 20:22:36 +0200

>> 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

---

From: Mary Barnes <[email-masked]>
Date: Wed, 17 Oct 2012 13:56:12 -0500

I agree it's silliness that SIMPLE implementations have interop issues
right now.  I think the SIP-XMPP is further along that SIMPLE-SIMPLE.  I
think that's because XMPP was done before SIMPLE - it's a matter of a
market decisions -i.e, jabber was available way before SIMPLE.  However, it
now seems that there are some deployments (e.g., Hannes' emergency services
scenario) that require SIMPLE-SIMPLE. I think we might be able to learn
from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for
the lowest common denominator situations.  I think the starting point for
the latter is to identify the current set of interop issues and determine
whether it's due to gaps in the specs or implementation decisions (as Olle
suggested at the beginning of this thread).

Mary.

On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson <[email-masked]> wrote:

> >> 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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 21:12:49 +0200

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Oct 2012 21:47:06 +0200

17 okt 2012 kl. 20:56 skrev Mary Barnes <[email-masked]>:

> I agree it's silliness that SIMPLE implementations have interop issues right now.  I think the SIP-XMPP is further along that SIMPLE-SIMPLE.  I think that's because XMPP was done before SIMPLE - it's a matter of a market decisions -i.e, jabber was available way before SIMPLE.  However, it now seems that there are some deployments (e.g., Hannes' emergency services scenario) that require SIMPLE-SIMPLE. I think we might be able to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for the lowest common denominator situations.  I think the starting point for the latter is to identify the current set of interop issues and determine whether it's due to gaps in the specs or implementation decisions (as Olle suggested at the beginning of this thread).
> 

Mary,
Thanks for your response. While it feels strange to suggest a focus on SIMPLE-to-SIMPLE interoperability, something that should have been there before, I think that's exactly what we need. 

All others following this list:

Please add your thoughts, possibly details (like Iñaki, Saul and Adrian have done) in mail to this mailing list. With that information, we can try to put together a document on "Issues in SIMPLE-SIMPLE interoperability" that can be the platform for continued work to solve issues. Pour it out to the mail archives!

Maybe we should try to define "SIMPLE" here. What I meant in the start of this discussion was a plaform using SIP "presence" event package, using XCAP for buddy lists and presence rules. (I might have missed something, so please add).  I would add that we should limit the definition to documents published by the IETF as RFCs in order to stay in focus. If there are things clearly missing in the RFCs, point this out clearly.

If you've missed the previous detailed postings in this thread, they're available in the mail archive for you to catch up.

Let's go.

/O

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 22:01:25 +0200

With.

2.

On Oct 17, 2012, at 9:59 PM, Roy, Radhika R CIV (US) wrote:

> Folks:
> 
> I do not know which scenarios for SIMPLE-XMPP interworking are taken into
> account:
> 
> 1. SIMPLE-XMPP without integration with audio and/or video?
> 
> 2. SIP/SIMPLE-XMPP with integration with audio and/or video?
> 
> Scenario 1 may be considered for an historical reason because XMPP came
> first.
> 
> Scenario 2 will not be useful from practical point of view because SIP for
> audio/video is firmly established in the market place and addition of
> SIMPLE/Chat/IM does not cost anything. Interworking GW is unacceptable from
> scalability and security point of view.
> 
> BR/Radhika
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Olle E. Johansson
> Sent: Wednesday, October 17, 2012 3:47 PM
> To: Mary Barnes
> Cc: Adrian Georgescu; [email-masked]
> Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability
> 
> 
> 	I agree it's silliness that SIMPLE implementations have interop
> issues right now.  I think the SIP-XMPP is further along that SIMPLE-SIMPLE.
> I think that's because XMPP was done before SIMPLE - it's a matter of a
> scenario) that require SIMPLE-SIMPLE. I think we might be able to learn from
> the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for the
> lowest common denominator situations.  I think the starting point for the
> latter is to identify the current set of interop issues and determine
> Thanks for your response. While it feels strange to suggest a focus on
> SIMPLE-to-SIMPLE interoperability, something that should have been there
> before, I think that's exactly what we need. 
> 
> Please add your thoughts, possibly details (like Iñaki, Saul and Adrian have
> done) in mail to this mailing list. With that information, we can try to put
> together a document on "Issues in SIMPLE-SIMPLE interoperability" that can
> be the platform for continued work to solve issues. Pour it out to the mail
> archives!
> 
> Maybe we should try to define "SIMPLE" here. What I meant in the start of
> this discussion was a plaform using SIP "presence" event package, using XCAP
> for buddy lists and presence rules. (I might have missed something, so
> please add).  I would add that we should limit the definition to documents
> published by the IETF as RFCs in order to stay in focus. If there are things
> clearly missing in the RFCs, point this out clearly.
> 
> If you've missed the previous detailed postings in this thread, they're
> available in the mail archive for you to catch up.
> 
> Let's go.
> 
> /O
> 
> 
> 
> 	Mary. 
> 	
> 	
> 		>> 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
> <blockedhttps://www.ietf.org/mailman/listinfo/simple> 
> 		
> 
> 
>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 22:07:52 +0200

To augment the reasoning for being practical.

RTP media path uses ICE, which impose little to no burden on the SIP/XMPP gateway itself, the TURN servers of each domain are carrying the load burden in the worst case scenario when end-points cannot find a more direct media path.

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 16:15:16 -0400

On 10/17/12 3:47 PM, Olle E. Johansson wrote:

> Please add your thoughts, possibly details (like Iñaki, Saul and Adrian
> have done) in mail to this mailing list. With that information, we can
> try to put together a document on "Issues in SIMPLE-SIMPLE
> interoperability" that can be the platform for continued work to solve
> issues. Pour it out to the mail archives!

ISTM that SIMPLE has two clearly separate parts: presence and IM.
The interop issues for the two are very different. I think most of the 
issues are wrt presence. This applies to both simple-simple and simple-xmpp.

The one point where there is commonality is around the URIs - sip: vs. 
xmpp:.

For instance, for simple-xmpp interop for ecrit, I think only the IM 
part is critical, and that should be the easier part.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 22:29:48 +0200

Hi Paul,

You are analyzing things in terms of one to one dialogs.

This is a bit wrong, and don't take this personally.

Presence requires a multiple set of dialogs between each end-point and the Presence Agent and between themselves on a logical level.

You are right that the interop issue are very different but your juxtaposed the actors.

Presence is the most complicated part of it all, it involves at least twelve of such dialogs when I do a napkin drawing. Which is at least one order of magnitude more complicated then doing a MSRP file transfer or an RTP video session.
 
Adrian

On Oct 17, 2012, at 10:15 PM, Paul Kyzivat wrote:

> The interop issues for the two are very different. I think most of the issues are wrt presence. This applies to both simple-simple and simple-xmpp.
> 
> The one point where there is commonality is around the URIs - sip: vs. xmpp:.
> 
> For instance, for simple-xmpp interop for ecrit, I think only the IM part is critical, and that should be the easier part.
> 
> 	Thanks,
> 	Paul
>

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Wed, 17 Oct 2012 19:59:09 +0000

Folks:

BR/Radhika

-----Original Message-----

Mary,

Let's go.

/O

	Mary. 

	On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson <[email-masked]>
wrote:

		

		/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 16:29:47 -0400

On 10/17/12 2:56 PM, Mary Barnes wrote:
> market decisions -i.e, jabber was available way before SIMPLE.  However,
> it now seems that there are some deployments (e.g., Hannes' emergency
> services scenario) that require SIMPLE-SIMPLE. I think we might be able
> to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE
> to work for the lowest common denominator situations.  I think the
> starting point for the latter is to identify the current set of interop
> issues and determine whether it's due to gaps in the specs or
> implementation decisions (as Olle suggested at the beginning of this
> thread).

I pretty much agree with Mary.
I suspect the primary reason for simple-simple interop problems is lack 
of a sufficient number of implementations motivated to make interop 
work. (But I say that without data, so I'll be happy to be corrected on 
this.) It would surprise me if it had all magically interoperated 
without difficulty without anyone finding and reporting problems, and 
some work to sort them out. And I haven't heard of that, except for the 
most recent discussion.

Perhaps this is because XMPP took a large part of the market, and the 
pieces it didn't get, that went with simple, are mostly walled gardens. 
(Maybe just a single walled garden.)

Personally I never cared very much about the details of the simple 
presence and IM. What mattered to me was that there be a unified 
addressing and session setup mechanism that could mix and match IM with 
audio and video. If we could have used XMPP as a sip media stream I 
would have been happy. And if we could have used XMPP presence with sip 
AORs that would have been ok too.

	Thanks,
	Paul

> Mary.
>
> On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     17 okt 2012 kl. 15:14 skrev Adrian Georgescu <[email-masked]
>     <mailto:[email-masked]>>:
>
>     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
>     [email-masked] <mailto:[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 22:42:45 +0200

On Oct 17, 2012, at 10:29 PM, Paul Kyzivat wrote:

> I suspect the primary reason for simple-simple interop problems is lack of a sufficient number of implementations motivated to make interop work.

Your suspicion is the negation of everything hat was written and said on this list in the last couple of days.

People making open source implementation for these SIMPLE standards and submitting feedback to this list lack motivation?

How can you write such a careless thing?

> (But I say that without data, so I'll be happy to be corrected on this.) It would surprise me if it had all magically interoperated without difficulty without anyone finding and reporting problems, and some work to sort them out. And I haven't heard of that, except for the most recent discussion.
> 
> Perhaps this is because XMPP took a large part of the market, and the pieces it didn't get, that went with simple, are mostly walled gardens. (Maybe just a single walled garden.)
> 
> Personally I never cared very much about the details of the simple presence and IM.

Well, if you do not care, why do you dare debate people who do care?
 
> What mattered to me was that there be a unified addressing and session setup mechanism that could mix and match IM with audio and video. If we could have used XMPP as a sip media stream I would have been happy. And if we could have used XMPP presence with sip AORs that would have been ok too.

As you do not care, please stay out of this discussion and let people who do care,  discuss it. 

Stop interfering with things you do not care about when others spend their time writing software code for it.

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 16:48:00 -0400

> You are analyzing things in terms of one to one dialogs.

Yes for IM, no for presence. I fully realize that the topology that must 
be maintained for presence is different, and more complex.

> Presence is the most complicated part of it all, it involves at least twelve of such dialogs when I do a napkin drawing. Which is at least one order of magnitude more complicated then doing a MSRP…

I don't know where you get the number 12. It seems obvious that the 
number will vary based on the buddy graph, the the partitioning of the 
principals among servers. No doubt it will turn out to be 12 in *some* 
case, but I don't see how that tells us anything.

Nevertheless it can be complex. The whole scaling analysis thing 
demonstrated that. The potential to give different authorization to each 
of your buddies makes it very difficult to come up with a scalable design.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 23:04:59 +0200

On Oct 17, 2012, at 10:48 PM, Paul Kyzivat wrote:

> Yes for IM, no for presence. I fully realize that the topology that must be maintained for presence is different, and more complex.
> 
> I don't know where you get the number 12. It seems obvious that the number will vary based on the buddy graph, the the partitioning of the principals among servers. No doubt it will turn out to be 12 in *some* case, but I don't see how that tells us anything.
> 
> Nevertheless it can be complex. The whole scaling analysis thing demonstrated that. The potential to give different authorization to each of your buddies makes it very difficult to come up with a scalable design.

Again, can we forget about scalability for a second.  Is a different topic.

The issue is the interoperability for presence flows between two clients from two different vendors on the same account on the same server.

The people concerned, myself included,  want to find a solution for how to make two SIP clients work under the same SIP account for presence. 

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 17:02:51 -0400

> How can you write such a careless thing?

This discussion comes after many years during which XMPP worked out its 
interop issues, and there was little discussion of interop issues with 
simple.

It is good that now there seems to be a critical mass to address the issue.

> Well, if you do not care, why do you dare debate people who do care?

IMO it would have been better if we had found a way to converge simple 
and xmpp long ago. But we didn't, and now we have both. And we get the 
issues that arise from that.

I am not debating you about the problems.

> Stop interfering with things you do not care about when others spend their time writing software code for it.

In what way have I "interfered"? I'm interested in seeing that the 
problems are identified and addressed.

At the end of the day, I just want to be able to put anybody into my 
buddy list, regardless of what protocol they use, and be able to 
establish sessions with them that can use any combination of voice, 
video, and IM that seems useful at the time.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 23:22:34 +0200

>> I don't know where you get the number 12.

On my napkin I have:

Each SIP client maintains at a minimum:

1. SIP Publication for each own state
2. SIP Subscription for presence.winfo event
3. SIP Subscription for presence  event for rls
4. SIP Subscription for xcap-diff event
5. HTTP Connection for XCAP document rls-services
6. HTTP Connection for XCAP document resource-lists
7. HTTP Connection for XCAP document pres-rules
8. HTTP Connection for XCAP document pres-content icon document
9. HTTP Connection for retrieval of the icon published by the remote contact

Two clients then need in total at least eighteen dialogs to maintain end-to-end presence signaling.

I was wrong, there are not 12 but 18 dialogs.

Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 17 Oct 2012 23:31:03 +0200

> At the end of the day, I just want to be able to put anybody into my buddy list, regardless of what protocol they use, and be able to establish sessions with them that can use any combination of voice, video, and IM that seems useful at the time.

Hi Paul!

This sounds like a great goal.

As you say, putting anyone in a buddy list that just works when one tries to communicate would be a great achieving of this WG.

This requires the concept of a buddy list., which is really the missing part. I called it address-book, you called it buddy list and is really the same thing. 

Could we converge on this idea of having to define this buddy list/address book part of SIMPLE?

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Oct 2012 23:41:13 +0200

> I do not know which scenarios for SIMPLE-XMPP interworking are taken into

Hi, the subject of this thread is "Focusing on SIMPLE-SIMPLE
interoperability". It seems that things are to wrong in this area that
is so easy for people to move the discussion to SIMPLE-XMPP
interoperability.

Please, let's focus on the real topic: SIMPLE-SIMPLE interoperability.
My opinion (again):

With the IETF specs SIMPLE-SIMPLE interoperability is not possible
since there are missing specs, the existing ones are too complex and
ambiguous and the ammount of lines of code to implement something that
still is incomplete are too much (15K of lines of code in a high level
language as Python).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 18:13:24 -0400

> I was wrong, there are not 12 but 18 dialogs.

OK. Now I understand what you meant.
And yes, it is an impressive and depressing, list.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 18:29:25 -0400

> Could we converge on this idea of having to define this buddy list/address book part of SIMPLE?

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. There are lots of other organizations that will have 
opinions on that and perhaps think it is within their scope rather than 
ours. (And they are probably right.)

To have any success it will be necessary to figure out how to scope this 
down. Perhaps an abstract model that can be mapped onto a variety of 
things. Or else find a model already defined someplace else that we can 
just reference.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 00:51:22 +0200

2012/10/18 Paul Kyzivat <[email-masked]>:
> There are lots of things I keep in an address book that have nothing to do
> with my presence buddy list.
>
> 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-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Oct 2012 00:53:02 +0200

Hi Paul,

In a client UI, one can aggregate contacts from different data sources. The UI may make the look uniform (like showing them on same groups or not) but the contacts and groups have different properties given by their original maker.

The goal is define one schema pertinent to SIMPLE where one can make a list of URIs with their type and organize them in groups. Each contacts can be subscribed to and a policy can be expressed for each contact.  In a SIP client I can render today a contacts list consisting of:

SIMPLE Contacts
MacOSX Addresbook
Google Contacts
Bonjour Contacts

These groups are all disjunct with regards to their capabilities and properties. In SIMPLE case I want to be able to be able to use multimedia sessions and subscribe to presence information published by those contacts, the other contacts are used for audio calls or chat sessions and no presence.  That works just fine with my implementation.  What I cannot do, is to use another SIMPLE client that implements the same functionality for the SIMPLE Contacts part so that same list can be see the same way from a mobile device for example. 

This is the missing part of SIMPLE, in order to use the standards to write a client in the same way by multiple vendors we need a common definition for to to write and read same contacts list with their properties. I cannot highlight this enough. People end up talking about anything else like scalability XMPP etc, when the real problem is the lack of interoperability of clients under the same account. 

Adrian

On Oct 18, 2012, at 12:29 AM, Paul Kyzivat wrote:

> 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. There are lots of other organizations that will have opinions on that and perhaps think it is within their scope rather than ours. (And they are probably right.)
> 
> To have any success it will be necessary to figure out how to scope this down. Perhaps an abstract model that can be mapped onto a variety of things. Or else find a model already defined someplace else that we can just reference.
> 
> 	Thanks,
> 	Paul
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 15:33:40 +0200

> Messenger, XMPP, etc... You manage a buddylist, not an addressbook.

Every single business customer I have talked with wants to integrate the presence into the
address book or LDAP directory lookups. That's an API issue, but it means that we have to be able
to have an API that queries for the presence of an object.

Doesn't mean that we replace the address bok, we need points of integration.

Note also that XMPP supports VCARDs in their buddy lists for managing extra attributes, like a photograph.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2012 12:43:57 -0400

There is a lot in here, and you guys are closer to it than I am, so 
mostly I am going to try to stand back and watch you talk it out.

I will observe that some things are, or can be, UI issues or API issues 
rather than protocol issues. For better or worse IETF doesn't do UI and 
API. So it's important to draw the lines carefully. Or establish a 
partnership with another SDO that does those things, like W3C, as is 
going on with RTCWEB/WEBRTC.

	Thanks,
	Paul

---

From: Brian McColgan <[email-masked]>
Date: Thu, 18 Oct 2012 12:51:52 -0400

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-masked]
> Date: Wed, 17 Oct 2012 21:12:49 +0200
> To: [email-masked]; [email-masked]
> Subject: [Simple] SIP SIMPLE end-point addressbook application
> 
> Hi Olle,
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 20:01:31 +0200

18 okt 2012 kl. 18:43 skrev Paul Kyzivat <[email-masked]>:

> There is a lot in here, and you guys are closer to it than I am, so mostly I am going to try to stand back and watch you talk it out.
Feel free to participate. You have years of experience in this too :-)

> 
> I will observe that some things are, or can be, UI issues or API issues rather than protocol issues. For better or worse IETF doesn't do UI and API. So it's important to draw the lines carefully. Or establish a partnership with another SDO that does those things, like W3C, as is going on with RTCWEB/WEBRTC.
Absolutely. But the requirement to be able to integrate with a UI may affect the protocol solution. 

XMPP has this problem. The XMPP server is not aware of the presence, it just routes stanzas. Without caching stanzas or doing something else, it is just not possible to create an API into the server and get the presence of a particular JID. In SIP the server aggregates the presence and is aware of it, so we can send SUBSCRIBE with expire:0 and query for presence. Thus, we can integrate into an address book more easily from a SIP presence server.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2012 14:36:40 -0400

> Feel free to participate. You have years of experience in this too :-)

I said I would "try" to stand back and watch.
It is unlikely that I will actually remain silent. :-)

> XMPP has this problem. The XMPP server is not aware of the presence, it just routes stanzas. Without caching stanzas or doing something else, it is just not possible to create an API into the serve…

Part of the solution could be enhancements to XMPP.
(I say that from the comfortable position of knowing nothing about XMPP.)

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Oct 2012 12:42:18 -0600

On 10/18/12 12:01 PM, Olle E. Johansson wrote:
>> I will observe that some things are, or can be, UI issues or API 
>> issues rather than protocol issues. For better or worse IETF 
>> doesn't do UI and API. So it's important to draw the lines 
>> carefully. Or establish a partnership with another SDO that does 
>> those things, like W3C, as is going on with RTCWEB/WEBRTC.
> 
> XMPP has this problem. The XMPP server is not aware of the
> presence, it just routes stanzas. Without caching stanzas or doing
> something else, it is just not possible to create an API into the
> server and get the presence of a particular JID.

Olle, that statement has no basis in reality. Every XMPP server
implementation on the planet is aware of the presence state for each
Jabber ID under its control.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 20:56:03 +0200

> Jabber ID under its control.

Right, in fact the XMPP server decides which user resource to route a
XMPP message based on its priority, am I right? (well, unless Gtalk
that uses its own "XMPP"...).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Oct 2012 13:01:26 -0600

On 10/18/12 12:56 PM, Iñaki Baz Castillo wrote:
>> implementation on the planet is aware of the presence state for
>> each Jabber ID under its control.
> 
> Right, in fact the XMPP server decides which user resource to route
> a XMPP message based on its priority, am I right? (well, unless
> Gtalk that uses its own "XMPP"...).

The Google Talk service sends messages to all XMPP resources; this is
allowed by RFC 6120 and RFC 6121 but is not the traditional approach.

The primary reason why an XMPP server needs to be aware of the
presence state of the accounts registered at the service is so that it
can respond to presence probes. RFC 6121 describes this in great detail.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 21:14:37 +0200

> can respond to presence probes. RFC 6121 describes this in great detail.

Thanks a lot for the clarification.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 24 Oct 2012 18:47:22 +0200

> Jabber ID under its control.

Thanks for the feedback. THat feature was not very stable when I 
implemented large scale XMPP a few years ago. Can I change the
state in the server as well nowadays?

/O