Presence and IntComm WG

["Ben Chinowsky" <>]

*Done* (see text below)

[ACTION] (11/8) Deke will draft a "why you should deploy PIC.edu" document.


*Still to do, or in process*

[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) Deke and Mark will prepare a simple demo of pseudonymity in
Jabber chatrooms, for a PIC call this fall.

[ACTION] (7/12) Jonathan will recruit Tom Uram to join a PIC call.

=====


The Presence and Integrated Commuinications Working Group (PIC-WG)
invites you to participate in a project intended to

(1) make campus IM deployments easier,
(2) make interoperability among Internet2 member IM services easier,
(3) make experimentation with advanced presence possible,
(4) enable eventual inclusion of advanced communications services
and advanced presence.

As a first step, PIC-WG is distributing a "package" that includes a
jabber IM&P (instant messaging and presence) server with which members
of our working group have had positive experiences.  To help get you
started quickly and easily, we are also including a basic cookbook on
getting it up and running and some guidance on the readily available
clients that users on common operating systems can use to access the
service. Based on our initial experience, this is a low cost and low
overhead undertaking that can bring real value for communications on
your campus, giving you a controlled alternative to commodity services
like AIM, Yahoo Messenger, and Google Talk at the server side, while
still preserving access to those services in many cases from the
client side.

** Identity Assurance.
A local IM service such as this one can use your local campus
namespace rather than the almost-random namespace in use on commodity
IM services.  It also can likely be configured to use your campus
authentication systems, as it has at Penn and MIT.  Together, these
steps provide Identity Assurance (allows users to be easily and
reliably identifed) for your local users in a way not possible with
commodity IM services.

** Dataflow Security.
IM streams are sent through your campus network to your
locally-operated server, providing data security and privacy that is
not available through commodity IM services. Instant messages move
only between your IM clients and the locally operated IM servers. This
means that the data associated with IM for two local users need never
be stored and handled by a third party server. Additionally, data (not
merely the password) can be encrypted.

** @domain.EDU Addressing.
IM users on other Jabber servers outside your institution (such as
other PIC.edu servers, Google Talk, and other jabber servers) will be
able to communicate with you and your local users using an address of
the simple format made popular by SIP.edu. That is 
.

** IM Clients
There are many IM clients which support the Jabber protocol. Rather
than specifying particular clients, we have elected to make
information about a range of clients available so that you can make
locally appropriate choices.