Action Items New
[AI] {Jim} will inform the group via the list of updates to the domain model incorporating Sympa developers’ comments.
[AI] {Jim and John-Paul} will discuss local-interfacepreference storing of attributes.

Carry Over
[AI] {Jill} will send out a survey reminder to increase the number of respondents for the mail list manager survey.
[AI] {SteveO} will gain a better understanding of Sympa documentation and translation requests and coordinate follow up w/ Renee and Jill.
[AI] {Jill} will send the URL for the workshop presentation to the list when available.
[AI] {Jill} will send an invitation to Sympa workshop attendees to join Internet2 and MList if they are not already members. This invitation will also include information about the hied-emailadmin list.
[AI] {Jim} and {John-Paul} will discuss the object and domain model intersection points.
[AI] {Anyone} having suggestions for follow up to the I2MM, please send them to the list.
[AI] {Jill} will develop VO survey distribution list.
[AI] {Jill} will follow up with NSF and DOE for possible VO survey candidates.

Attendees
John-Paul Robinson, UAB (stand-in chair)
Jim Phelps, University of Wisconsin – Madison
Paul Russell, University of Notre Dame
Terrie Clark, Internet2
Renee Frost, Internet2
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2

Sympa developers’ comments on the domain model will be incorporated into the model. And, subsequently, the updated model will be incorporated into Sympa technical documentation. It was discussed that while the MACE-MList WG’s final deliverables will be non-application specific, Sympa developers can provide input about Sympa’s feature sets.

The 3D model describes how the WG’s models function together. The group agreed that it is useful to document the purpose and function of each of the WG’s models. Similarly, it is useful to discuss and document how the models connect with each other. By providing generic functionality in each model, the WG seeks to assist system developers and designers with finding areas of mailing list software application functionality that can exist externally, without a local implementation inside the software. For example, a user database is not necessarily defined within a mailing list software application, but the mailing list software application could be designed in such a way as to utilize a user database either within the application or external to it.

It was discussed that the authentication component of the models should be separated from authorization and account components. An account is often defined as a username and password. Subsequently, the username and password are considered almost interchangeable inside the system. Middleware as developed within Internet2 provides, among other things, the ability to use an external authorization system so that all of the internal system components trust the external authorization. Mailing list software seeks to identify users inside a mailing list as a different function than providing user authentication. An external authentication is implied in the domain model. Changes will be made to the domain model to clarify an external authentication.

An identify-user function or a user identification process can be included in mailing list software. In addition to these two elements, the account can store user preferences. This would include a set of preference attributes about a user that the mailing list is authoritative for, and that is potentially meaningless outside of the mailing list system. It might be useful to provision those user preference attributes across multiple applications through middleware. Preferences can be global and application specific. Perhaps a mailing list diagram showing local preferences stored with external facing interfaces would be useful? The application then becomes authoritative in terms of inward and outward-facing interfaces for certain attributes. These attributes then become useful for more than one application. And, it is desirable to access those attributes uniformly.

This method of attribute and preference management is similar to Carnegie Mellon’s Application Configuration Access Protocol (ACAP). For more information please see http://asg.web.cmu.edu/acap/. ACAP is intended to be a technology for storing user preferences on a central server beyond a Windows’ domain. For more information on the Cyrus IMAP Aggregator and ACAP please see http://asg.web.cmu.edu/cyrus/ag.html.

The WG seeks to provide a set of guidelines for system designers to use thus enabling them to design an application that system integrators can easily adopt with the ability to de-install a non-performing application without reengineering interfaces for the replacement application.

The next call is Wednesday, November 10, 2004 at 12:00PM ET.