*MACE-Dir Conference Call*
March 18, 2002

*Participants*

Keith Hazelton -- Wisconsin(chair)
Tom Barton -- Memphis
Rob Banz -- UMBC
Brendan Bellina -- Notre Dame
Todd Piket -- MTU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

eduOrgOffice

        Brendan responded to an action item by writing an e-mail (subj:
Proposal for eduOrgOffice and eduOrgOfficeLocal attached) which discussed 
the use of eduOrgOffice and how it could be made less anglo-centric. 
The group read through this e-mail section by section to consider the
improvements suggested.
        Everyone agreed at the top of the call that having an eduOrg
attribute is useful.  A discussion was also held about eduOrg and why it
was important to replace/evolve the currently used x.521 org and
orgUnit. The philosophy of never reappropriating or redefining an extant
attribute was reiterated.  Instead, as much of the prior definition is accepted 
as is still relevant and useful, and the rest of the definitions created are
done so only for the community choosing to use them for the additional
functionality they provide.
        There is already an attribute called labeledURI which
applications are more accustomed to using, but it is extremely poorly defined 
and cannot be renamed.  Implementing eduOrgOffice in this attribute would seem 
to be another appropriation of an existing attribute and violates the cardinal
rules of always typing and naming attributes well.  Additionally, it could 
collide with other uses of the same attribute name.
        The first discussion was to confirm the roles that eduOrgOffice
was supposed to fill.  The description of it reached by the group is that it
is a multivalued attribute providing blue-pages functionality for application 
and person consumers of data.  The individuals may be web-browsing and
desiring information about institutional offices, following hyperlinks.
The application could be a directory service, or an e-mail client which
would need to automatically parse the information.  These won't be
overly complex LDAP searches, nor will they necessarily be very clever clients.

Anglocentrism

        One of the primary concerns exhibited by Brendan and the group
was that the attributes were anglo-centric.  In order to make eduOrg more
globally applicable, it would be useful to not constrain the values of
the attribute to anglocentric variants; the group did agree, however, that
for standardization's sake, American names for the attributes were
appropriate. There may also be difficulties of imposing a more American
organizational structure onto the attribute, as well.  The group thought it 
might be wise to consult TERENA's directory group, TF-LSD, to solicit some 
advice and insights.
        The approach Brendan suggested to displaying local labels for
attributes is to create a separate attribute which contained the set of
proper names that should be assigned to attributes.  This would require
an intelligent application to be able to pick the values from one attribute
and discover the corresponding title from the other attribute, displaying 
these correctly.  While this might be difficult for these applications
and not terribly useful to the common web browser, an application such as
DoDHE could process this information in the background before returning
results.

Multiple Offices

        The other thing that the group wanted to allow is use of
multiple offices.  Many institutions may have multiple campuses, each with 
an individual campus police, while the registrar's office may span all
these branches.  There also may be multiple instances of one office, 
e.g. admissions for graduate school and a separate department for
undergraduate applicants.  This would mean that one search for campusPolice 
would return several matches even within one attribute, which could cause 
some applications to choke.  It's also important that the correct office be
found, which means that multiple results may also be a necessity.  The
fact that eduOrg is an auxiliary object class allows many of these scenarios
within the directory.
        Brendan proposed creating a tiered system to allow the population 
of the multi-campus scenario, utilizing the auxiliary nature of the
object class.  He demonstrated four examples of how this could be implemented
in the document distributed with his e-mail.  Searching would be fairly
effective in this scenario, as all indexes with the same label would be
returned, commensurate with design considerations.

Naming

        Each campus police, if there were multiple, would also have a
corresponding CN, which an intelligent application could return along
with the results.  Interestingly, however, the original x.521 org doesn't
contain a CN, leaving org or orgUnit as the only attributes which
contain any sort of descriptive information about the object.  Some 
institutions may already have objects for the individual offices, to 
which eduOrg information would point.
        Tom pointed out that departmental titles should never be embedded 
in DN's because titles are fairly subject to change.  One approach is to
use something completely meaningless and relatively immutable, such as a
giant alphanumeric string.  RI is very difficult to perform in directories, 
however, and must be performed as DN's are modified.  The group also
wanted to allow the full range of flat-and-bushy and tall-and-spiky directory
design styles, which means applications should not be designed with any
assumption of the spatial structure of the DIT.  All this taken together
makes it difficult to use DN's outside the domain, and the group
considered seriously advising against using them in interrealm scenarios.