*Attendees*
Brendan Bellina, Notre Dame
Chris Williams, U. Buffalo
John Paul Robinson, UAB
Peter St. Andre, Jabber Software Foundation
Mike Grady, UIUC
Steve Olshansky, Internet2
Jeanette Fielden, Internet2
Ben Teitelbaum, Internet2

*Discussion*
There is a Real Time Communications Summit scheduled for the Internet2 Spring Member Meeting. The intent is to foster communication between the various real time communication initiatives at Internet2. The I2IM, VidMid VC, VoIP, and Presence and Integrated Communications (PIC) working groups will all be involved. The Spring Meeting is in Washington D.C. April 19th – 21st 2004. More information is available at: http://events.internet2.edu/2004/spring-mm/

XMPP update
Peter indicated that the Core and IM drafts have been approved as proposed standards by the IETF. Functionality was split into core and IM since the core is used for real time systems monitoring etc. in addition to being used for IM. This should help with adoption since the standards will now be stable. There is also work happening on security features such as improving Kerberos authentication mechanisms etc. There are some ancillary drafts to improve interoperability between XMPP based systems and SIP/SIMPLE based systems.

John Paul asked if it made sense to transition to Jabberd 2 at this time. Peter felt it was worthwhile to do since Jabberd 2 is more compliant with security issues and database integration than Jabberd 1.

Use Cases
In the pseudonymous use case Brendan has merged case seven into case one. Rewriting case one raised some concerns about what information the IM systems would need to know. If the target said there were several rules by which they let different people contact them what happens if a person meets a criteria for more than rule? For example, students from four classes are allowed to contact a professor and a student is in more than one class. The professor would not know which class they were from, just that they were allowed to contact him, i.e. he would not know which rule they matched that allowed the contact. There might be some need for the initiator’s client to indicate what kind of role the person is taking and pass some information about what rule was matched that allowed the connection.

This is analogous to what happens in the web environment. A visitor could be anonymous, member of the site, or member of an affiliated site. It’s also similar to logging into a UNIX box under different accounts to have different privileges. Being able to determine what role the visitor is acting under may require effort on part of the user. Either the student identifies the class/role or there may be some intelligence needed in the client that distinguishes where connections come from though it’s not clear how to determine how to pass that information along and know what the rules are that are being used. In general the cases can be thought of as a set of requirements.

Please mail thoughts, comments, and ideas about the use cases to the list since the more discussion generated the more robust the cases become.