*MACE-Dir Conference Call Minutes*
April 1, 2002

*Participants*

Keith Hazelton -- Wisconsin (chair)
Rob Banz -- UMBC
Tom Barton -- Memphis
Renee Frost -- Michigan/Internet2
Michael Gettes -- Georgetown
Mike Grady -- Illinois
Ken Klingenstein -- Colorado/Internet2
Todd Piket -- MTU
Ellen Vaughan -- Internet2
Bruce Vincent -- Stanford
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

eduPerson 1.5

        The call opened by looking at the reposted draft of eduPersonRDN. 
The group noted initially that this draft contains definitions, notes, and
examples, which are not exactly the sort of things which would be part of
an official spec.  There may be a reincorporation of some of the text into
an existing MACE-DIR document or a new document.  Tom suggested a quick
change to the second paragraph of the 'notes' section to clarify that the
attribute is intended to make the DN portable, not that eduPersonRDN values
should be chosen such that DN's are globally unique.
        Tom also pointed out that a DN being unique didn't necessarily 
imply portability, and the converse is not necessarily true as well.  Some
further confusions were cleared up about whether there could be alias
names for attributes at the DN level.  Aliases need the same OID, however;
eduPersonRDN comes with an OID, and the local attribute doesn't necessarily
have one.  Even if some workaround were figured to the need to have the
same OID, there would be several other difficulties which would make
this unfeasible.  No document or official recommendation has been issued by
MACE-Dir on what DN syntax has to be; the group preliminarily suggested
IA5, but nothing further was discussed.  Michael explicitly didn't want to
limit "how people can abuse this" because several possibilities existed for
the misapplication of rules which could be handy in some implementational 
situations, permitted by the current lack of strict specification.
        With the basic changes suggested by the group, eduPersonRDN was
officially accepted into the v1.5 revision of eduPerson.

URNs

        A desire was expressed to better specify how the hypothetical URN:MACE
naming authority might work.  Explicit discussion of when and when not
users of eduPerson or other Internet2 developments should go to MACE for
some sort of registration is lacking from current documents.  One point
Keith made is that not all URN namespaces have to be formal; there are ways
to form URN's in informal ways without prior registration.
        A much more tricky question is that of precisely whom MACE would 
issue URN space to.  Relatively straightforward are the member schools of
Internet2, but the group didn't know whether it would be appropriate to
issue URNs to corporate members of Internet2.  Higher educational
institutions that are not members of Internet2 also are an important
consideration.  No decisions were reached on these topics, but the group
did recommend generating a companion guide document to the draft itself
which would state the nature of the namespace, who would apply, and would
answer those questions relevant to the application and use of the namespace.

LDAP Recipe v2

        Michael mined through the e-mails, minutes, and similar comments which
regarded information for the next revision of the LDAP recipe.  The bullet
changes and logic behind them are listed below:

-- Tom contributed some suggestions about mail routing, indicating that a
specification in the document of how Georgetown and/or Memphis do mail
routing based on the directory would be relevant and helpful.  This must
be considered in terms of protecting sensitive or well-known attributes
because there may be "future implications."

-- Michael thought addition of eduPersonOrgUnitDN information about
displaying and browsing information in terms of the original intended
purpose of orgUnit and orgUnitDN would be useful.

-- Art Vandenberg of Georgia Tech elaborated on Novell eDir specific
information.

-- While there was some consideration of adding text with recommendations
on indexing, Michael wasn't certain what could be said there.

-- eduPersonRDN now needs to be mentioned and explained in the recipe.

-- Todd sent in information regarding the use of displayName, which
Michael thought he may have already added.  Todd also sent information 
to MACE-Dir about adding displayName as defined in iNetOrgPerson with
appropriate text and so on.

-- The group suggested adding something about how to synchronize an
enterprise directory with an Active Directory, and Michael offered to
put in a short paragraph pointing to MIT's Pismere project.

-- Some discussion of groups was warranted.  An exceptional, comprehensive
document about groups in directories has already been developed by the
MACE-Dir working group, but the group conceded that this document is
extremely advanced and foundational in nature, rather than the more
implementation-oriented LDAP recipe.  Michael offered to add a discussion
of the basics for the sake of initial implementation with a pointer to the
Best Practices in Directory Groups document if a deployer desired much
more information.

        Discussion continued about implementation-specific issues for the
LDAP recipe, considering several tough issues.  The eduPerson LDIF that 
has been provided to date has been based on the LDAP v3 specifications.
OpenLDAP is not quite up to par with this revision of the standard, and the
LDIF needs some tweaking before it can be parsed by that application.
There are also other directory services which will have finicky 
interpretations of LDIFs and may require precise rewriting. The 
group didn't want the document or the group itself to become a repository for
LDIF fragments for various obscure implementations, preferring to stick
principally to implementing in LDAPv3 and allowing others to customize
as necessary.  However, it saw some importance in providing ready materials
for various implementations to help distribute eduPerson to a wider
audience more easily.  Michael said he would be more than happy to add a
link to a contrib directory in the recipe itself, while keeping the recipe
itself relatively evangelized.  Internet2 would then maintain this
directory independently of the recipe.  The group resolved to follow this
path, and Michael will update the document with the appropriate URL once
Internet2 designates one.
        Mentioning of the proprietary Metamerge was another contentious
issue, since Metamerge provides a very useful set of functionality and it is
offered free to higher ed.  There are other NMI audiences such as
government labs for whom this would not be applicable, and this issue is
complicated as the LDAP Recipe pre-dates the NMI.  Although Metamerge has
been solidifying its relationship with Internet2, there are other corporate
sponsors with competing products and the group didn't want to advocate
any individually.