Presence and IntComm WG

["Ben Chinowsky" <>]

*Action Items as of July 13*

(high priority)
[ACTION] (6/29) Mark will find out if jabberd 1.x supports roster push.
[ACTION] (6/29) Mark will try using Applescript to specify an arbitrary
presence doc to publish.
[ACTION] (6/15) Rodger will put discussion of if and how to fix PALS and
PALS-DEV on the agenda for a future call.
[ACTION] (6/15) Rodger will look into the status of Jingle for Gaim.
[ACTION] (5/18) Ben T. will post the calendar-integration code (written by his
2005 SoC student) on the Penn XMPP server; Mark will evaluate prospects for
modifying it to drive XMPP presence.
[ACTION] (5/4) Rodger will send the PIC WG a matrix of XMPP clients to try.
[ACTION] (5/4) Rodger will send notes to assorted mailing lists, asking for
input on PIC's XMPP plan.

(medium priority)
[ACTION] (5/11 - on hold for the summer) Ben T. will look for students active
in Place Lab to work with PIC.
[ACTION] (4/13) Rodger, Joe, Ben T., Steve, and Candace will continue testing
Gaim SIMPLE against pals.
[ACTION] (3/2) Joe will ask Jon Peterson to join a PIC call to talk about work
in IETF SIMPLE.
[ACTION] (1/12 - ongoing) Ben T., Candace, and Steve will continue with 
pals-dev
testing.
[ACTION] (1/5 - in progress) Rodger will look for carrier reps to present
perspectives on IMS.
[ACTION] (12/8 - in progress) Dennis will schedule Megan Pengelly to summarize
Columbia's PIC-SER experience on a future call.
[ACTION] (pre-12/8 - in progress) Candace will add a wiki document on strict 
vs.
loose routing.
[ACTION] (pre-12/8 - in progress) Rodger will try to reach his contact at
Barracuda Networks.
[ACTION] (pre-12/8 - in progress) Rodger will contact Erik Lagerway.
[ACTION] (pre-12/8 - in progress) Rodger and Joe will write up some use cases
for federations.
[ACTION] (pre-12/8) Rodger will try to organize a call with CounterPath.

(low priority)
[ACTION] (pre-12/8) Candace and Jamey will initiate an email discussion of 
their
proposal to modify the SER PA module so it can do presence via SUBSCRIBE and
NOTIFY, to accommodate clients that don't do PUBLISH.
[ACTION] (pre-12/8) Jamey will enable eyeBeam to use presence info to decide
whether messages should go straight to voicemail.
[ACTION] (pre-12/8) Jamey will update the interface requirements document.
[ACTION] (pre-12/8) People will research skiff-like offerings from various
companies:
- Dennis - Newbury
- Rodger - Airespace (now part of Cisco)
- Jeremy - Eckehau (via Walt Magnussen)
[ACTION] (pre-12/8) Ben T. will write a short document describing the 
motivation
for the paths-in-the-snow approach to PIC development.

*Attendees*

Rodger Will (chair) - Ford
Peter St. Andre - Jabber Software Foundation
Candace Holman - Harvard
John Stier - Stony Brook
Dennis Baron - MIT
Zahid Mahmoud - Columbia
Deke Kassabian - Penn
Neal McBurnett - Internet2
Ben Teitelbaum - Internet2
Ben Chinowsky (scribe) - Internet2

*Discussion*

Peter Saint-Andre joined the call to bring the group up to date on Jabber.
Peter has been involved with Jabber since 1999 and has written most of
the JEPs (http://www.jabber.org/jeps/).

The group discussed the publish/subscribe model for rich presence in Jabber.
JEP-0060 defines the protocol; JEP-0163 describes how to use it for personal
eventing. Candace noted the tutorial at
http://www.pubsub.com/docs/pubsub_xmpp_draft.html. Peter contrasted the
pubsub approach with the SIP/SIMPLE approach. In SIP/SIMPLE there is a
PIDF document that has all your presence info, and information you don't want
to share has to be filtered out per-recipient. With pubsub, everything is
atomic -- "little bits of XML that are never put into one big document" -- 
and you tell the server who gets to see which ones; they are never combined
into one large privacy-threatening document. Ben T. asked if presence
fuzzing would require a different document for each level of detail; Peter
replied that you could do it that way, but as pubsub has yet to be fully
implemented, no one has done this yet. The Wildfire server and the Psi client
seem to be closest to implementing pubsub.

Peter gave a quick Jingle status update. Google Talk uses Jingle 0.9; progress
toward 1.0 has been stalled for the last couple of months. Jingle uses a
pluggable model, so (for example) you can do your signaling with Asterisk. For
NAT traversal, Jingle uses ICE, which in turn uses STUN and TURN. Peter noted
that there is lots of interest in the Jabber community in using Jingle for
things other than voice, e.g. whiteboarding, shared editing, and distributed
musical performance.

JEP-0142 defines limited workgroup functionality for Jabber. While it doesn't
provide a way to aggregate information across identities (everything in the
Jabber world revolves around the individual identifier), it does provide a way
to address the "I need someone in this workgroup, I don't care who" use case,
e.g. for technical support. Peter noted that automated buddy lists have been
implemented in some of the commercial servers; he recommends using LDAP for
further implementations.

Finally Peter gave an overview of some of the open-source Jabber code bases.
The original jabberd code base was significantly rewritten for 1.4; work on 
1.5
is ongoing. jabberd2 is a separate code base, launched with the goal of making
the code easier to understand, but the key people have left and no one is
currently driving it forward. ejabberd is written in Erlang, which is obscure,
but because there are so few Erlang projects it attracts coders interested in
the language. Jabber.org uses ejabberd with about 200,000 users. Wildfire is
written in Java. Peter noted that Wildfire and ejabberd both have people
getting paid to work on them, so those are the open-source implementations
that he recommends.

Peter encouraged the group to contact him with any further questions. His
contact information is at http://www.jabber.org/people/stpeter.shtml, and
he has joined the PIC list.