*Attendees*
Michael Gettes, Duke
Klaas Wierenga, SURFnet
Chris Williams, U. Buffalo
Derrick Brashear, CMU
Todd Piket, Michigan Tech
John Paul Robinson, UAB
Dean Lane, Rice
Charles Reeves UT-HSCH
Mike Grady, U. Illinois
Ann West, Educause/Internet2
Tom Barton, U. Chicago
Scott Cantor, OSU
Seth Vidal, Duke
Peter St Andre, JSF
Renee Shuey, Penn State
Jon Siegle, Penn State
Diego Lopez, RedIRIS
Jose Manuel Macias, RedIRIS
Jeanette Fielden, Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2

*Discussion*
Campus updates
RedIRIS in Spain is running Jabber with 500 users. They are using it for internal communication and work groups. Once you have access to list server you also have access to the IM server and are authenticated to both the same way. They want to build a mesh between different institutions of the services.

UAB has no campus wide deployment of IM. Use is a hodge-podge of IM clients.

CMU is still using Zephyr. They have inter-org trust relationships set up with other organizations on campuses that run zephyr as well as with MIT and Stockholm University.

The IETF is in last call for the main XMPP Internet Draft. The comment period ends on the 9th of October.

The intent of the I2IM working group is to deal with the larger issues of enabling interaction between messaging and the application environment. Jabber/XMPP is being considered first because it's in the open software space. The intent is to address commercial products as well.

Jabber was created to have a client that used XML, was extensible and has some semantics around the packets. There are three kinds of packets. One is the message packet, which is a push mechanism to get information out to people or to other entities. That could be a content syndication engine etc. The second is the presence packet that provided information about an entity's presence on the network. The third type of packet is IQ, info query, a request response medium similar to http. All of these are pure XML so they are extensible. Jabber is extensible so people have been using it for new things, and it has a very easy way to define new protocols.
[AI] Peter will write up the IM architecture he's envisioning and Diego will do the same for comparison purposes.

One benefit of developing a national IM infrastructure is information sharing between campuses around things like viruses, worms etc. Information capture could be real time and perhaps help authorities to track it down quicker. Currently every tool uses a different approach to message structure, storage etc. A lot of the web-based tools ignore those message-based structures. A more unified approach would be helpful. In a way all applications can be viewed as a different facet of messaging. Storing a file, video conferencing, writing code in a group setting etc. Messaging becomes a hammer with everything else as a nail.

The key concerns and issues are: authorization, access control, trust fabric, authentication, and application integration. How do you define a group, what rights they have, and how do you propagate information about group membership? Jabber has just started working on how people can find each other and form communities of interest. It's part of the IQ – resource discovery area.

The challenge of this space is how to integrate infrastructure and instant messaging. The intent is not to solve all the problems identified but to ensure that what is created provided interfaces to the infrastructure that will allow others to tie back in and solve these problems. For example Shib is web oriented. The attribute authority (AA) is not. The AA could be more general purpose and provide attributes to applications other than Shibboleth.

The intent is to keep the scope centered around the basic authentication case. The first case could be how authenticated interaction is handled. How could different domains interoperate? What would happen where one domain has unauthenticated IRC and the other is authenticated? Is truly anonymous IM supported or only pseudo-anonymous IM, where identity is obscured but can be retrieved by system administrators?

Renee Shuey pointed out that it goes beyond Shibboleth and relates to different types of federations. Each federation could have different polices about anonymity based on their needs.

It ought to be possible to crosswalk between applications without having to share a common protocol, or technical specifications. It should also be possible to have a federated identity that works between the user's university and a service provider across a wide range of applications. There are many areas that will need authenticated identity such as financial services, defense, medical, etc.

The key is how to tap into what is already in existence and leverage the work of the Internet2 middleware space in a way that doesn't preclude federations with different mechanisms. Building on the work done by Internet2 middleware in the directory arena to get campuses standardize practices at the directory level would enable us to inter-operate. What are the things that we may need to add to that work that will allow us to better integrate the directory for IM?

The I2IM session at the Internet2 Fall Member Meeting is on Monday October 13th at 08:15 a.m. EST. The discussion will focus on possible use cases for development.