*Attendees*
Michael Gettes, Duke
Rob Carter, Duke
Seth Vidal, Duke
Dean Lane, Rice
Bob Morgan, U. Washington
Steve Carmody, Brown
Chris Williams, U Buffalo
Renee Shuey, Penn State
Jonathan Siegle, Penn State
Tom Barton, U. Chicago
Samir Chatterjee, CGU
Mike Grady, U Illinois
Mark Poepping, CMU
Peter St. Andre, Jabber
Klaas Wierenga SURFnet
Mark Poepping, CMU
Susan Minai-Azary, MIT
Ann West, Educause
Renee Frost, Internet2
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussion*

Intellectual property: Everyone should read and understand the IPR policy. The policy can be viewed at: http://members.internet2.edu/intellectualproperty.html. By participating in the calls or on the list you are agreeing to the policy.

The I2IM Charter is posted at http://middleware.internet2.edu/i2im. Please look it over and forward any questions to the list.

While Jabber is the starting point for the I2IM group the intent is not for the group to be focused solely on Jabber. Interoperability with other IM environments is desirable as well. More general language can be added to embrace additional IM environments. Susan asked if encryption will be part of the IM work and suggested it be incorporated into the charter if it is.

Samir raised the issue of presence not being mentioned and a good definition of IM and presence would be beneficial. It was suggested that RFC 2779 has a definition of presence and IM and would serve as a good reference since the IETF working groups use it.

The I2IM work springs from the Internet2 middleware initiative. The concern is how does it plug into an enterprise, and not to deal with the myriad of issues that are specific to the instant messaging arena. Presence may have enterprise integration issues and the concentration would be on that and not how to solve the presence issue, which others are working on. Most of the focus will be on figuring out how universities can be cross compatible and strongly authenticated in the instant messaging realm. How do we make connections within existing structures?

Klaas asked what the relationship was between I2Im and the Presence and Integrated Communications (PIC) working group. Does something similar as well based on SIP and SIMPLE. PIC has a larger application scope including voicemail, calendaring, etc.

Peter provided an overview of Jabber's evolution. Jabber started in 98/99 as an open source project. The Jabber foundation was started in 2001 to codify the wire protocol that had been developed. Last year they began to take that work to the IETF. Peter is the primary author of the specification that has been presented to the Extensible Messaging and Presence Protocol (XMPP) working group. (www.ietf.org/html.charters/xmpp-charter.html). Jabber/XMPP is a XML streaming technology where you can stream elements from one entity to another. Clients can connect to servers, servers to each other, you can have components that could be 3rd party that any server or client could connect to. The basic architecture is similar to e-mail. Servers can connect to each other and pass messages, presence, etc. back and forth to do request response services similar to http. It has progressed quickly within the IETF with some tweaking for security and internationalization. Two main documents will be submitted for last call very soon and should be in RFC status by the end of the year. Jabberd 2 is a rewrite of the existing server and implements all of the IETF specifications.
[AI] All, send links to list or Steve Olshansky for consideration for the I2IM website links section.
[AI] Peter will work with Steve on appropriate docs to link to on the Jabber site and IETF, and introductory/summary materials.

Samir discussed the work that has been done in the SIP group. They started with the IMPP working group requirements documents, which merged into three approaches to IM: Application X-change (APX), Presence and Instant Messaging (PIM), and SIMPLE/SIP. SIMPLE has become a major force because of 3G wireless.
[AI] Samir provide a couple of paragraphs of chronological history of SIMPLE/SIP and how IETF things evolved.

Klaas is not very familiar with PIC but will check with Egon Verharen to see if he can write a couple of paragraphs on PIC. His understanding is that you should use XMPP for presence-like things, and SIP for ongoing multimedia use. Samir has received e-mail from the PIC working group that SIP Jabber gateway at Indiana is up and running.
[AI] Klaas will see if Egon would be willing to write a couple of paragraphs on SURFnet and PIC.

Does XMPP equal Jabber or vice versa? The basic idea of XMPP is the same as the Jabber protocol. You can look at what developed in Jabber community as 0.9 and the XMPP work as the 1.0 and is backward compatible. Changes made in the IETF address end-to-end encryption and authentication. The differences are documented in the Internet drafts that will be in last call soon. The Jabberd 2 server is very compliant the Internet drafts.

Interoperability is a major motivation for Jabber. It's a bit of hack because many protocols aren't openly published and change often. There are people working on XMPP to SIP/SIMPLE gateways and a demonstration will be up soon on http://XMPP.org.

Given the XMPP work, what is required between university A and university B to trust each other? From an inter-domain perspective XMPP can do authentication between domains though not as granular as Shibboleth. There is an unpublished technology, called PublishSubscribe that can send updates whenever there are data check-ins on a sub node. It would be nice to have more granular controls over who can see that data. There is a subscription model but tying it into Shibboleth or SAML would be good. Another example would be multi-user chat rooms with ongoing discussions on research topics where you want to limit access. It would be interesting to use SHIB/SAML to control access in addition to membership. This could be integrated into XMPP rather easily.

Use cases will be important. Particularly with respect to authorization there is a lot of different uses and definitions so it will be important to nail down specifics on what goes where and how it gets there. Use cases will determine the requirements that will have to be met in integrating them into the Jabberd 2 server.

The authentication method could be abstracted since SASL is used and there are many different SASL authentication methods. What does it take to turn Jabber on and integrate it with existing authentication? SASL is not yet widely deployed with respect to the IETF. The main implementation is in beta. There may be work needed to add support for new SASL authentication mechanisms to Jabberd 2.

Campus use of IM today:
Rather than duplicating a Jabber cookbook building a knowledge base of shared learning and experiences around how to integrate Jabber with existing infrastructure would be desirable.
[AI] All, submit possible use cases to the mailing list.
[AI] Steve and Michael will write up a couple of questions people can use to frame their use cases.

Penn State: Jabber 1.4 running using Kerberos. Some student use. Another product called Angel in use that provides asynchronous communications as well. Faculty and staff use but it is not overly subscribed.
MIT – Zephyr was popular when Athena was popular. Use is declining over time. Never adopted by university business community. Students use AOL, MSN, etc.
Chicago – Jabber 1.4 is up using LDAP.
Illinois: Have no IM deployment as a campus service.
CMU: Zephyr that is supported by many administrative processes. Otherwise, it's IM anarchy (AOL, MSN, YAHOO, etc).
Duke: Testing Jabberd 1.42 server running on Linux, which authenticates to the central Kerberos servers. IT staff only. Zephyr deployment at central level used mostly by IT staff, some student use, otherwise it's IM anarchy.
Rice: SSL enabled Jabberd 1.42. Mainly being used only by IT people. Toying with opening it up for all of campus. Otherwise IM use is AOL, Yahoo, and MSN.
SURFNet: Testing with Jabber to do a combination of Jabber and SIP conferencing. Have a client developed where you meet each other on a web page and start up a video or phone conference.

There is Jabber Zephyr client work alike called JWGC. It lets people go to a Jabber system using a zephyr like client.

Calls will be at this time every other Friday. Next call is Friday September 27th.
List mail is archived and can be accessed by list subscribers through the interface at archives.internet2.edu

Next call will discuss use cases based on what people send to the list. Volunteers to help write uses cases are solicited.

There is a birds of a feather (BoF) discussion scheduled on Monday October 13, 2003 from 8:30 – 10:00 EST in Indianapolis. This is the day before the full meeting begins. Details at: http://events.internet2.edu/2003/fall-mm/index.html.