CURRENT_MEETING_REPORT_ Reported by David Lippke/UTEXAS LIST Minutes The Automated Internet Mailing List Services Working Group had two separate meetings, one on Wednesday morning and another the following morning. The second meeting was simply a continuation of the first and, consequently, these notes do not distinguish between the two. Further, the order of presentation here doesn't necessarily reflect the order of discussion at the meetings (where each topic was generally visited more than once). To start things off, we reviewed why the Working Group exists and what we are, and are not, trying to do. The view expressed was the following: We are here because dealing with Internet mail lists is painful for everyone involved --- users, list owners, and postmasters alike. Current Internet mailing list services generally lack fundamental features such as access control and standardized archive maintenance. In short, the Internet mailing list world is a very primitive one... and one which is in serious need of improvement. The Working Group exists to address this need. However, we are NOT here to create the ultimate group communication system. Although list-style group communication should eventually become part of an integrated group communication system, our goals are more focused and short term. The feeling is that we have to learn to walk before we can run. After establishing this, the group went on to discuss the agenda for the meetings. Two major potential directions were identified. Either we could define a baseline user interface or we could spend the time trying to develop a picture of the phase 2 list server world. The following list of pros and cons was reviewed: Reasons to define a baseline interface: 1. Damage control in the name of minimizing user confusion. Alternative view: we need to define the first few articles of a ``user's bill of rights'' (e.g., users have the right to receive confirmation of all transactions, users have the right to see whether or not they are subscribed to a given list, etc). 2. Enable implementors to begin work now. 1 3. We can define the baseline quickly (assumption). 4. It's a fail-safe strategy for the Working Group (i.e., recognize that there's a significant chance that the phase 2 work will fail. If so, the Working Group will have at least accomplished something). Reasons to NOT define a baseline interface: 1. Perhaps we would codify something that won't fit future models well. 2. Perhaps the subset we define now will be too limited to be useful. After some discussion, we decided to attempt a definition of the baseline's contents and use that process to learn more about the problem and to see if we hit any show stoppers (which would indicate that defining a baseline user interface at this time is not the proper thing to do). Thus, we began discussing a long list of functions and design issues. We rated each of the functions as ``in'' or ``out'' of the baseline interface and discussed each of the design issues long enough to develop views on how each should be treated. Each of these items is given separate treatment below, but to jump straight to the end, the final conclusion was that we were satisfied with our efforts to define a baseline user interface and that enough functionality was contained within it to warrant its publication. BASELINE COMPONENTS o INCLUDED: Subscribe/Unsubscribe capability Discussion: An obvious conclusion. Also concluded that any subscription policy was allowable (e.g., open, closed, by service area, etc), but that the user is always owed a confirmation, explanation, or denial. See more general comments in the ISSUES section. o INCLUDED: List parameter review capability Discussion: If users can see that a list exists, then they should be able to review its operational definition (e.g., see who the owner is, see what the subscription policy is, etc). Also, there was a general consensus expressed that a list's definition should include a ``keywords'' parameter which could be used as an aid in searching. The expression of the various parameters is not to be specified. o INCLUDED: List subscriber review capability 2 Discussion: If users can see that a list exists, then they should be able to obtain a list of its subscribers, UNLESS list policy dictates otherwise. In all cases, requesting users are owed either the list or an explanation of why they cannot retrieve it. o INCLUDED: List of lists capability Discussion: Users should be able to obtain a list of all lists a given list server knows about (and they're allowed to know exist). We agreed that list servers needed to somehow identify for what ``domain'' they spoke, but tabled the implementation details for discussion on the Working Group list. o INCLUDED: Various minor commands (HELP, POLICY, STOP, etc.) Discussion: We resolved that this wasn't worth spending time on and that the details should be worked out on the Working Group mailing list. o EXCLUDED: Per-user options Discussion: This was tabled as being too demanding of implementations and because we predicted that there would be no quick agreement on what a set of baseline options should be. After the initial conclusion, it was later countered that users had a fundamental right to conceal their membership on a list and that the implementation of this was not overly complex even with simple-minded sendmail alias implementations. The ensuing discussion revealed that while the Mailbase implementors currently allowed per-user concealment, they will soon remove that capability since their users had raised the opposite argument (i.e., that they had a right to see who they were talking to when they posted a message to a list). This counter-counterpoint showed that the issue was a debatable one. Since our razor was that if something was debatable, it was not baseline, we returned to our initial conclusion. o EXCLUDED: Archive Searching and Archive Retrieval Discussion: Although it was universally accepted that archival services are important, exploration of this topic revealed a number of sticky issues which we felt could be not quickly resolved. Difficulties ranged from problems related to the (previously agreed upon) need for program- interpretable list server responses to the quagmires of search method specification. Thus, the whole area of archive services was booted. The interim suggestion is that the output of a list parameter review mention how the archives are to be obtained. o EXCLUDED: File services Discussion: This died for reasons similar to those that killed the inclusion of archive services. o EXCLUDED (with proviso): Authentication Discussion: All cookie approaches do significant damage to the current pattern of user interaction. We have no experience with 3 these approaches nor have we spent time looking for alternatives. Consequently, the introduction of such a facility in the baseline was deemed a real bad idea. HOWEVER, the baseline definition will mandate that all list server transactions be logged for X (TBD) period of time in a way that allows listmasters to reverse transactions, should the need arise. Also, any transaction which affects a user (mail address) should result in a confirmation/informational message being sent to that user (mail address). The feeling was that this is similar to what goes on now and at least offers some degree of reactive protection. It was also noted that PEM does not address the question of whether or not a person can speak authoritatively for a given mail address (although it may diminish the exposure since one at least knows *who* caused the trouble). o EXCLUDED: Proxy Operations Discussion: Proxy operations are desirable, but we uncovered a complex set of problems and possible approaches once we dug into the issue. Also riding against their inclusion was the lack of solid authentication (these two issues seem to feed on each other ...). DESIGN ISSUES / PHILOSOPHIES o LISTSERV Compatibility The LISTSERV command set and interaction methods/patterns are the de facto standard. We should not be afraid to vary from that standard, but we should only do so when there is ample cause. o Where should mail commands be sent? Directly to the list server agent address for the most part, but mail to listname-request and listname-owner should do a reasonable thing (which, even on BITNET, could be simple aliases to the list owner). o How should the results of commands be returned? By default, they should be returned via the mechanism the commands were received. Command results should also be machine-interpretable. The intent was that we should define how this is done, but the issue was tabled for Working Group list discussions. In any case, the view is that both humans and GUI tools need to be able to make requests and understand the response(s). o General syntax rules Tabled for discussion on the list. o Channels and other provisions for upwards compatibility. Part of the above and likewise tabled. 4 o General note on command interaction Users are always owed a message confirming (directly or indirectly) the reception and disposition of their requests. o Identity of list servers A minor issue, but list servers should identify themselves (general type, version number, etc.) in some appropriate way during most transactions. (where ``appropriate'' and ``most'' is TBD on the list). o Header handling Although further debate is assured, the group came up with the following guidelines in regard to how list mail should be sent to subscribers. 1. Steps should be taken to ensure that rejections are never routed back to a list. 2. ``Sender:'' and SMTP return path should never be set to the list address. 3. Header trace information should not be stripped. 4. The list equivalent of a ``Received:'' line is needed (e.g., Exploded:). Resolved to work with the 822 Extensions folks on this. 5. Messages from a list should be unambiguously identifiable as coming from that list. Header extensions may be required for this as well. 6. ``Reply-To:'' should not be modified. 5 Attendees James Conklin conklin@bitnic.educom.edu Peter Deutsch peterd@cc.mcgillica Johnny Eriksson bygg@sunet.se Erik Fair fair@apple.com Jill Foster jill.foster@newcastle.ac.uk Ned Freed ned@innosoft.com James Galvin galvin@tis.com Neil Katin katin@eng.sun.com Darren Kinley kinley@crim.ca Mark Knopper mak@merit.edu Vincent Lau vincent.lau@eng.sun.com Eliot Lear lear@turbo.bio.net Louis Leon osll@emuvm1.cc.emory.edu David Lippke lippke@utdallas.edu Joseph Malcolm jmalcolm@sura.net Chris Myers chris@wugate.wustl.edu Mel Pleasant pleasant@hardees.rutgers.edu Jan Michael Rynning jmr@nada.kth.se Harri Salminen hks@funet.fi Larry Snodgrass snodgras@bitnic.educom.edu Gregory Vaudreuil gvaudre@nri.reston.va.us Chris Weider clw@merit.edu John Wobus jmwobus@suvm.acs.syr.edu Russ Wright wright@lbl.gov 6