Minutes, Reported by Ned Freed: The purpose of this effort is to standardize a mechanism for routing local mail using LDAP. Currently there is no standard schema for this purpose. Hans Lachman presented an overview of how Netscape does this (draft-lachman-ldap-mail-routing-03.txt). Additional attributes are added to a user's LDAP entry. mailRecipient is the object class, the single-valued mail attribute gives the user's address and the single-valued mailHost attribute gives the host the mail is to be routed to. The multi-valued mailAlternateAddress can be used to specify additional addresses the user uses to receive mail. mailRoutingAddress optionally gives a new address the mailrouting process changes the envelope recipient address to. This last attribute was added to deal with situations where some agents demand some peculiar sort of envelope recipient address. Daryl Huff presented an overview of how Sun does this. inetMailRouting is the name of their object class. mail is the user's email address attribute and mailHost is the host name of the user's mail server. Both of these are required. An optional attribute, rfc822MailAlias gives alternate addresses the user uses to receive mail (same as mailAlternateAddress in Netscape's scheme). There is no equivalent of mailRoutingAddress in the Sun scheme. This is all used in conjunction with the inetOrgPerson object class for users and groupOfUniqueNames for aliases and distribution lists, neither of which are being considered in this BOF. Jeff Hodges presented the approach used at Stanford. Given "local-part@domain", the lookup is done on "local-part". A very complex naming scheme is used. The attribute looked up is seasSunetId. On a match, the attribute mailDrop gives the new address to route the mail to. Uses the mail attribute to advertise the email address. Chris Newman asserted that the goal here should be to come up with a single, standardized mail routing mechanism. A hum-poll of the room indicated strong support for this. Jeff Hodges asserted that mail routing should be independent of the mail attribute. Bob Morgan noted that their design at Stanford is being changed to accommodate multiple ids. A suggestion was made that whatever system that is adopted be capable of handling multiple advertised addresses and that these addresses not be limited to RFC822. Ned Freed disagreed strongly with the latter part of this. Further discussion ensued, at which point Chris Newman claimed that this sufficed to identify a rat-hole and that how to advertise a user's address be placed out of scope. Daryl Huff agreed that the scope should be limited in this way. John Beck conducted a straw poll: Should the scope initially be kept narrow and focused on local routing only, with possible expansion to other topics later, or should it be wide to begin with? There was a clear consensus that the former is the right approach. Another poll: Should this go to a design team or should we go for a WG now? There was no consensus on this point. It was then suggested that the design team be tried first, and if that fails... A final poll: Is anyone interested in working on a general inbox schema? If there are lots of people interested they didn't appear to be in the room...