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

On 10/18/12 2:01 PM, Olle E. Johansson wrote:
>
> 18 okt 2012 kl. 18:43 skrev Paul Kyzivat <[email protected]>:
>
>> 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 said I would "try" to stand back and watch.
It is unlikely that I will actually remain silent. :-)

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

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

	Thanks,
	Paul

> /O
>>
>> 	Thanks,
>> 	Paul
>>
>> On 10/17/12 6:53 PM, Adrian Georgescu wrote:
>>> 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:
>>>
>>>> On 10/17/12 5:31 PM, Adrian Georgescu wrote:
>>>>>> 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?
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>