*Action Items*
Carry Over
[AI] {Steve Carmody} will report back to the WG about the Sympa/Shibboleth discussions to date.

New
[AI] {Jill} will supplement the domain model diagram to better illuminate potential middleware connection points.
[AI] {John-Paul and Jim} will examine the domain model diagram for consistent terminology.
[AI] {Paul} will e-mail link to Notre Dame’s mailing list policy to the group.
[AI] {Jill} will solicit the list for other university mailing list policies.
[AI] {SteveO} will post the Notre Dame mail list policy link the WG’s web page.

*Attendees*
Jill Gemmill, University of Alabama at Birmingham (Chair)
John-Paul Robinson, University of Alabama at Birmingham
Paul Russell, Notre Dame
Jeff Eaton, Carnegie Mellon University
Steve Olshansky, Internet2

*Discussion*

The group will support several sessions at this year’s Fall I2MM. For more detail, please see http://events.internet2.edu/2004/fall-mm/. Highlights follow:

The group will hold a workshop with Sympa developers on Sunday, September 26 from 1:00PM 5:00PM.

The group will hold an E-Mail Security BoF, jointly hosted by Salsa, on Sunday, September 26 from 7:00PM - 9:00PM.

The group will hold a panel discussion on Wednesday, September 29 from 1:00PM 2:30PM, jointly hosted by the Integrated Infrastructure for Instant Messaging (I2IM) working group. The panel discussion, entitled
Middleware Enabled Collaborative Applications, will include a discussion about the NMI grant and related MACE-MList and I2IM efforts.

The surveys will be sent out September 15. This date was selected to allow respondents time to get past the crunch of the start of the semester.

Domain Model Discussion
The domain model diagram was developed to illuminate areas of middleware integration for mailing list software. The group discussed supplementing the document to better illuminate the middleware enabled areas. The group also decided to modify the document to incorporate consistent terminology for all sections of the diagram. The group discussed defining rules within LDAP or a central information repository to define middleware collaboration points without adding detail to the domain model diagram. In general, applications that are middleware enabled should also be able to run without the middleware connections. E.g. it is possible to configure a list or service to use an enterprise directory as a default source for authentication rules. Subscribers on the list that are not a part of the enterprise directory could be processed using the application’s internal rule set. This requires further definition of where data stores are located and which applications use the data stores.

The group would like to understand the impacts if mailing list software is directory enabled? Or, database enabled? For example, at Notre Dame the college of business has many lists to reach faculty and students. And, they have a number of staff members who are authorized to post to the college of business lists. Any subscriber to the college of business editor’s list can post to any college of business’ lists. However, this still requires management of the editor’s list. If a list could be configured to verify that an individual is a member of the college of business staff, then the necessities of the editor’s list maintenance and configuration statements could be eliminated. As discussed on earlier calls, this is what MACE-MList proposes to address with authn rules. The group would also like to understand how the fact that most authentication rules are internal to mailing list products affects the management of subscribers and rules external to the mailing list software?

The next call is Wednesday, September 15, 2004 at 12:00PM ET.