*Attendees*
Jeff King, Wave Three Software
Jill Gemmill, UAB
Tyler Johnson, UNC-CH
Art Vandenberg, GSU
Samir Chatterjee, CGU
Nadim El-Khoury, UNC-CH
Tom Barton, U. Chicago
Lisa Hogeboom, Internet2
Tarun Abhichandani, GCU
Steve Olshansky, Internet2
Jeanette Fielden, Internet2
Ken Klingenstein, Internet2

*Discussion*
Certificates for H.323: The overall goal is a profile that can be used by many applications, not just H.323, and a consistent location for the cert though for some platforms there may not be a standard place to put them. There's a place in H.350 for certificate storage for H.323 and SIP. It needs to be decided if certs will be stored in LDAP or in local host. Keith Hazelton and Michael Gettes might be able to answer the question of whether the attribute in H.350 that holds the certificates can act as a pointer to a certificate store and if it can be refined to point to a specific certificate within the store.

Jeff shared that H.350 issues of endpoint configuration and mass deployment seem to resonate with a lot of enterprises they're talking to. Authentication hasn’t been as big an issue as endpoint configuration and populating directories. As an architecture emerges that uses certs, Wave Three Software is willing to approach what needs to be implemented from an endpoint perspective.

There is a single attribute for authorization included in H.350. The attribute is not intended to scale to be a fine-grained highly deployed authorization mechanism. It is sized for existing call server deployments for SIP and H.323. It will be demonstrated for H.323 at the fall member meeting. There will also be an attribute in LDAP that is centrally managed and authoritative. The call processing will happen based on how that attribute is set. The plan is to demonstrate a completely self-configuring H.323 endpoint that configures itself out of the directory. The sample code will be made available for people to work with.

Is the federation we're building for Shib and web services the same we would build for desktop videoconferencing? Videoconferencing has more of the behavioral patterns of e-mail than web services. Whatever the federated model for videoconferencing it will need to authenticate. In terms of authorization there should be some rules that say this is a visitor, doesn't belong to a federation, and how deal with it. People connecting to a conference may or may not have a federation affiliation and will still need to connect. The FOO site http://middleware.internet2.edu/foo/ has links to recent discussions on federation. There is also a pointer to a Liberty paper on trust models, which talks about three models, including community based trust. Ken suggested a possible fourth model, a community of communities, should be considered as well.

Jabber, a business oriented instant messaging (IM) platform, has developed an enterprise and federated version. There is great interest in examining the code to help identify if a generalization of federations can work for IM. How IM and presence are dealt with in an inter-realm way is important and needs to be addressed in the research and education community.

H.350 Next Steps
The latest documents will be posted to the VidMid VC website. The next version of the document will be in Mid-July when the standard becomes official. There have been discussions within Vide.net about distribution. Once H.350 is ratified, the LDIF files will be distributed. A cookbook to discuss the architecture is being created but won't include the actual documents themselves. As the cookbook is created the drafts will be removed from the VidMid-VC website. The full text document will be available through the ITU website. The exact date of the cookbook is not yet set.

After the ITU ratification, an informational RFC will be submitted to the IETF to let them know the architecture is available in the ITU. The relevant SIP portions of the document will be published in the RFC.

Internet2 Track sessions: Tyler has proposed several track sessions. -- several presentations could work together to form a mini track.
1. Demonstration of directory enabled products and prototypes, H.323 and SIP endpoints, proxies, gatekeepers and directories. Including how schools can use some of the free tools available.
2. Discussion of existing security models, shortcomings and future directions.
3. Video middleware cookbook section geared out helping campuses start to implement this at their own sites. (Same cookbook as earlier).

The next NMI release is set to be in October. If you are proposing a submission, please submit it as soon as possible. Jill suggested and it was unanimously agreed that the cookbook discussed earlier in the call would be a good submission for the white paper section. The best reviewers would be people trying to implement it. Contact SteveO if you are interested in submitting something.

Samir shared that they started testing the Radvision MCU at UNC-CH last Friday. They were able to do a conference between two MSN clients. They then tried to connect with a call simulator, a generic SIP client supplied by DynamicSoft. They tried it two ways, inviting the client from the conference interface and the reverse. From the client to conference, they connected but there is no communication, so the thought is the generic call simulator expects something in return. They will document what was done and generate a report. They will keep working on the testing and sharing updates via e-mail.

Wave Three Software has released the first version of their multi-point server last week. Let Jeff know if you want to see a demo of it.

Presence:
How does the concept of presence fit into our environment and what issues, questions and scenarios does it create? This crosses e-mail, instant messaging and videoconferencing. Examples:
1. When somebody is listed in the directory and wants to note that for the next six hours they will be at a certain IP address or conference room.
2. They just want to pop onto the network and let a presence functionality in the network somehow know: "you are you and to direct any incoming communications your way." How do you directory enable that and make sure that the presence server detects you and knows it's you?

The dominant protocol seems to be SIMPLE. It is difficult to identify which RFC was exactly SIMPLE. SIMPLE is not a new protocol but an extension of SIP.

Jill shared that they were already using some IM clients where the authentication is tied into the enterprise. It's open source, and some run on Linux, some on PC's.

Of critical importance is a common vocabulary around the concept of presence.

Next call is June 30, 2003.

[AI] Samir will prepare a short write up of SIMPLE and which RFC's apply.
[AI] Jill will check to see if there is a write up on open source code being used for IM clients where authentication is tied into the enterprise.
[AI] Steve will follow up with Renee about a possible BoF on presence at the fall member meeting.
[AI] Samir will send a link to a document about presence vocabularies written by Jonathon Rosenberg to the list.