Presence and IntComm WG

[Steve Blair <>]

Peter Saint-Andre wrote:

> Will, Rodger (R.) wrote:
>
> > PIC Participants: Please review the following wiki page to learn 
> > about and comment on the proposal to create a project that will 
> > provide a software stack for presence and realtime communications 
> > based on the XMPP standard.  
>
>
> The documents seem more SIP/SIMPLE-centric to me. A few examples:
>
> - "discuss techniques for adding rich presence (such as calendar and 
> location tracking), federation, identity and privacy capabilities, 
> and/or other standards-based protocols (such as SIMPLE) when feasible"
>
> FWIW, XMPP has native federation, many rich presence extensions, and a 
> robust publish-subscribe technology for delivering those extensions as 
> defined at http://www.xmpp.org/extensions/xep-0060.html (core spec) 
> and http://www.xmpp.org/extensions/xep-0163.html (simplified "Personal 
> Eventing Protocol" profile).
I read this to mean techniques for adding rich presence to our pic-ser 
package. Did I misunderstand the purpose of this sentence? However we 
add rich presence I would really like to see the group tackle this one  
in either  an I2 demo or a packaged release for campuses.

> - "Presence updates via SUBSCRIBE/NOTIFY for clients that don't 
> implement PUBLISH"
Yeah I think that statement is not only left over from SIMPLE work but 
also a little dated as far as the RFCs go. It would probably be more 
accurate to talk about how the update happens and what architectural 
models we may support (peer-to-peer, presence agent, etc). A presence 
agent discussion is most likely the place we would discuss methods for 
updating presence state.

> FWIW, XMPP has only one way to do presence updates, via the 
> <presence/> XML "stanza". See RFC 3921 for details.
>
> - "Group chat, such as Message Session Relay Protocol"
>
> FWIW, in XMPP we have a groupchat protocol called Multi-User Chat, 
> which is stable (the core of it has been in use since 2000), widely 
> implemented and deployed (e.g. it's the only group chat technology 
> that has been approved by DISA for use in military applications), and 
> does just about everything IRC does except with a stronger security 
> model. See http://www.xmpp.org/extensions/xep-0045.html for details.

So this is a great start. From a PIC or pic-ser package perspective we 
may want to discuss what we want in a group chat feature/protocol. After 
that we would be better able to determine which protocols let us 
accomplish of goals.

> > Please provide any and all comments to the list.  Thanks.

> > _https://wiki.internet2.edu/confluence/display/picwg/pic.edu+Draft+Proposal_ 
>
>
>
> I find the focus on commercial vendors puzzling. There is so much 
> open-source code that implements XMPP and its extensions that folks 
> here could quite easily put together a complete suite of server(s), 
> clients, and add-on components to do everything you want. Plus you 
> could have students contributing code back to the relevant projects, 
> enabling them to gain experience with the open-source community and 
> enabling your organizations to improve those offerings. I don't know 
> the state of open-source SIP/TURN/STUN/etc. implementations as well, 
> but I do know that such code exists (e.g., the OpenSER server). Why 
> pay some commercial vendor when you can build this stuff for free? Not 
> that I'm opposed to commercial vendors, mind you, but it seems 
> unnecessary here and contrary to the spirit of experimentation that 
> our universities might want to foster.
>
> Peter