Presence and IntComm WG

["Ben Chinowsky" <>]

*Action Items as of December 6*

[ACTION] (11/29) Deke will see if Peter can provide materials for the PIC.edu
cookbook.
[ACTION] (11/8) Mark and Jorj at Penn will work with Dennis and Greg at MIT to
create a short document describing how to get Openfire running with a basic
configuration for PIC.edu.
[ACTION] (11/8) Tim will recruit someone to create the PIC.edu client table.
[ACTION] (11/1) Tim will ask SIP.edu participants for their insights on how to
proceed with PIC.edu, and in particular how to handle user generation and
management.
[ACTION] (11/1) Tim will put the draft PIC.edu project objectives on the wiki
and invite people to start contributing there.
[ACTION] (10/4) Peter will find out if Horizon Wimba can interoperate with 
other
XMPP services, in particular whether it can do server-to-server federation.
[ACTION] (7/12) Mark will prepare a simple demo of anonymous and non-anonymous
versions of moderated and unmoderated Jabber chatrooms, for a PIC call in 
early
2008.

*Attendees*

Deke Kassabian (acting chair) - Penn
Mark Sirota - Penn
Jorj Bauer- Penn
Neal McBurnett - Internet2
Ben Chinowsky (scribe) - Internet2

*Discussion*

Deke cited http://mit.edu/sip/sip.edu/ as a model for the PIC.edu cookbook. 
Mark
noted that he's sent Dennis some server-configuration materials from Penn, but
hasn't heard back yet.

Mark gave an overview of the various room types and user roles in Jabber, and
how these interact. Rooms and roles are documented in great detail in
http://www.xmpp.org/extensions/xep-0045.html. Although how and when user
identifiers should be displayed is well defined by the protocol, not all 
clients
behave properly; this is one reason for the "documenting many and recommending
few" approach the group has agreed to take to clients.

The initial version of PIC.edu will recommend that people use non-anonymous
rooms by default; Mark noted that this runs counter to the expectations of the
typical Jabber user. As Deke put it, we will be recommending a deployment that
makes identity assurance a possibility and anonymity an option. The initial
version will not support multiple levels of pseudonymity, but this may be
supported in future versions.