*Action Items*
[AI] {Jill} will send out links from the MACE-Mlist Group regarding their discussions on the architecture of middleware-application interactions, and how this might assist VidMid-VC in videoconferencing with federated security.

[AI] {Nadim} will send out information about a proposed design meeting to identify potential partners and future steps to take.

[AI] {Jill} will prepare a one-page summary directed towards RTC, which details available H.350 resources that could be deployed widely, and suggestions for packaging, in the effort to push out more information to Higher Education.

*Discussion*
If the Group is interested in pursuing the development of some example code supporting videoconferencing with federated security, what approaches should we be considering? It might be possible to review some of the MACE-Mlist WG work and assess a parallel course of action in terms of mapping of particular applications interacting with middleware. We would need people to look at our work and provide input about its usefulness. How might VidMid-VC work on implementation in a way that builds off existing architecture, and in such a way that it is successful and frames the Group's work for future developments?

We need to identify what we have to offer to product developers, and who might be interested in working with us. The earlier this is determined, the better it will be for the overall direction of the Group. In the past, the Group discussed defining a clear interface between the client and the authentication infrastructure. Once the infrastructure has been written, modifying a client would mean adding enough code to check the helper application and view the authentication status. This would make a strong argument with which to approach commercial partners. It would be useful to look at two very different applications using the authentication and authorization infrastructure. Problems associated with mailing lists are not taken care of via firewalls; instead they might reroute the port without completely blocking it. A filtering step is added, even outside of the application - for example, using anti-virus software or spam filters. This sort of filtering can provide the mailing list with recommendations about whether to authorize or not. [AI] {Jill} will send out links from the MACE-Mlist Group regarding their discussions on the architecture of middleware-application interactions, and how this might assist VidMid-VC in videoconferencing with federated security. The wiki for the MACE-Mlist can be found at: <http://webapp.lab.ac.uab.edu/wiki/mlist/>. Model diagrams can be found at: <http://webapp.lab.ac.uab.edu/wiki/mlist/index.php/OurModels>.

The Group decided to call a design meeting, with the intent to assess the scope of the problem, along with how much programmer time is needed, and who might be potential partners, etc. This information should be defined before we approach RTC, possibly at the I2 Spring Member Meeting. [AI] {Nadim} will send out information about a proposed design meeting to identify potential partners and future steps to take.

Is H.350 enough? It certainly has the capability to provide a great deal of resource discovery. Typically, H.350 defines multimedia contact information, which points to person objects. However, what happens if you try to reach other types of entities, such as conference rooms? This type of approach is not standardized well enough, but there is a possibility to do that within H.350. Another scenario might involve a hospital setting, where it would be useful to have the ability to search for a portable video device, such as a scope. You might be looking for the nearest doctor with videoconferencing ability, but there is no directory for such request. In terms of resource discovery, how do you go about this without a directory? These ideas could be further explored in the upcoming BoF. If we can come up with a good schema, it could be passed on as a recommendation to Universities. Perhaps the ideal resource discovery would be a dynamic self-organizing type, as opposed to the more formalized structure. This would raise the question of whether to use existing protocol, or it might necessitate creating our own protocol. The Strategic Advisory Group at UNC has prioritized Identity Management, and among other examples, this might argue using a more formal structure of H.350 and LDAP, etc.

People need to understand what resources they have available on hand, so they do not find themselves knocking on doors looking for available videoconferencing. Attributes of a lower level are more standardized - for example, probable information that is searched for a particular restaurant - hours, menu, pricing, etc. - but how are attributes searched and presented at a higher or global level? What kind of problems does this pose, and does it concern VidMid-VC? It may not be realistic to envision enough organized databases, and therefore we might need to implement with dynamic, self-registering capabilities in mind.

{Jill} and {Jason} are working on a special session for the deployment of H.350. The commercial sector has already worked from the Cookbook, but Universities have yet to follow suit. We need to keep it simple and provide something that can be easily downloaded and put into practice. Perhaps the current presentation of information is not visible enough; the average person setting up a conferencing system is only interested in running a client through an installation, which allows them to begin using the system once the installation is complete. How could this be set up in a way that does not require people to understand the internal security in its entirety? [AI] {Jill} will prepare a one-page summary directed towards RTC, which details available H.350 resources that could be deployed widely, and suggestions for packaging, in the effort to push out more information to Higher Education.

The next call will be Monday, March 21, 2005 at 11am ET.