Return to text.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / report-2

Annotation of 43BSDReno/contrib/isode-beta/doc/whitepages/report-2/text.tex, revision 1.1

1.1     ! root        1: % -*- LaTeX -*-
        !             2: 
        !             3: \newpage
        !             4: \section       {Introduction}
        !             5: In July of {\oldstyle 1989},
        !             6: NYSERNet started a pilot project offering a White Pages service using OSI
        !             7: technology.
        !             8: Since that time,
        !             9: NYSERNet and PSI have been extending and evaluating the service in response to
        !            10: experience gained during the operation of the pilot.
        !            11: 
        !            12: The service is interesting in three respects:
        !            13: it is a large,
        !            14: distributed information service involving administration by multiple
        !            15: organizations;
        !            16: it is the first production-quality field test of the OSI Directory (X.500);
        !            17: and,
        !            18: it is the first large scale production application of OSI technology on top of
        !            19: the popular Internet (TCP/IP) suite of protocols.
        !            20: 
        !            21: The purpose of this document is to describe the ``refinements'' made to the
        !            22: base X.500 Recommendations in order to produce a workable system.
        !            23: It must be {\bf stressed\/} that none of these refinements are contrary to
        !            24: either the spirit or letter of the X.500 protocols.
        !            25: Rather,
        !            26: if one begins with the assumption that one has a conformant X.500
        !            27: implementation,
        !            28: then these refinements consist of fleshing out the ``for further study'' and
        !            29: ``local matter'' clauses of the X.500 Recommendations.
        !            30: Further,
        !            31: one should note that a system implementing these refinements will still be
        !            32: able to interwork,
        !            33: albeit with less functionality,
        !            34: with conformant X.500 implementations that do not implement these refinements.
        !            35: 
        !            36: For the remainder of this note,
        !            37: the reader is assumed to have a basic understanding of X.500 technology.
        !            38: 
        !            39: The purpose in presenting this information is to advance understanding of
        !            40: these grey areas by describing operational experiences in offering a Public
        !            41: Directory Service using X.500.
        !            42: Having stated what this note is about,
        !            43: it is also appropriate to state what this note is not about:
        !            44: this note is not meant to provide any implementation-specific information.
        !            45: That is,
        !            46: this note considers only the externally visible aspects of a Directory Service
        !            47: which incorporates these refinements.
        !            48: As such,
        !            49: these refinements should be applicable to {\bf any\/} conformant X.500
        !            50: implementation.
        !            51: 
        !            52: This note begins by reviewing the need for a White Pages Service and presents
        !            53: a basic model for offering such a service using the X.500 protocols.
        !            54: Next,
        !            55: a brief overview of the technology used to realize this service is presented.
        !            56: Following this,
        !            57: this note is divided into two major sections:
        !            58: first,
        !            59: issues relating to the Directory System
        !            60: (e.g., refinements in the operation of a DSA or use of the DSP)
        !            61: are discussed;
        !            62: second,
        !            63: issues relating to a Directory User
        !            64: (e.g., refinements in the operation of a DUA or use of the DAP)
        !            65: are considered.
        !            66: 
        !            67: \newpage
        !            68: \subsection    {For Further Reading}
        !            69: There is very little ``new'' information presented in this note.
        !            70: Rather,
        !            71: it is a compilation of several sources,
        !            72: organized to focus on the refinements necessary to produce a workable system
        !            73: using X.500 technology.
        !            74: Interested readers might wish to consult:
        !            75: \begin{itemize}
        !            76: \item  \cite{WPP.Intro},
        !            77:        for an introduction to the NYSERNet/PSI White Pages Pilot Project;
        !            78: 
        !            79: \item  \cite{WPP.Report-1},
        !            80:        for the latest status report (as of this writing);
        !            81: 
        !            82: \item  \cite{WPP.User,WPP.XWP},
        !            83:        for information on user interfaces;
        !            84: 
        !            85: \item  \cite{WPP.Admin},
        !            86:        for information on administering a DMD within the pilot
        !            87:        (i.e., a PRDMD);
        !            88: 
        !            89: \item  \cite{QUIPU.Manual}
        !            90:        for programmatic information on the underlying X.500 implementation.
        !            91: \end{itemize}
        !            92: All of these documents (and many others) were consulted when this note was
        !            93: written.
        !            94: 
        !            95: \newpage
        !            96: \subsection    {Managing Infrastructural Information}
        !            97: A natural function of computer networks is to form the {\em infrastructure\/}
        !            98: between the users they interconnect.
        !            99: For example,
        !           100: the electronic mail service offered by computer networks provides a means for
        !           101: users to collaborate towards some common goal.
        !           102: In the simplest cases,
        !           103: this collaboration may be solely for the dissemination of information.
        !           104: In other cases,
        !           105: two users may work on joint research project,
        !           106: using electronic mail as their primary means of communication.
        !           107: 
        !           108: Most network services are based on the implicit assumption that each user can
        !           109: supply {\em infrastructural information} to 
        !           110: facilitate information transfers through the network.
        !           111: For example,
        !           112: electronic mail services expect that an originator can supply 
        !           113: addressing information 
        !           114: for all the intended recipients.
        !           115: It is not necessarily the task of electronic mail, per se,
        !           116: to provide this infrastructural information to the user.
        !           117: 
        !           118: This model works fine in small environments,
        !           119: particularly those where infrastructural information is not difficult to 
        !           120: obtain and remember.
        !           121: However,
        !           122: the model does not scale well.
        !           123: Consider the case when the membership of a network consists of hundreds of
        !           124: thousands of users belonging to thousands of organizations.
        !           125: It is no longer reasonable for a single user to provide this information,
        !           126: except in very limited circumstances.
        !           127: Further,
        !           128: it is likely that some of the information changes frequently,
        !           129: due to personnel and other resource movement.
        !           130: The goal of a {\em white pages\/} service is to 
        !           131: provide the necessary information, and to mask the complexity of the
        !           132: infrastructural information.
        !           133: 
        !           134: \subsection    {A Public Directory Service}
        !           135: In our context,
        !           136: a public directory service allows a user to ascertain information
        !           137: about a person whose name is (approximately) known.
        !           138: In providing such a service using technology based on the X.500
        !           139: Recommendations,
        !           140: it is necessary to view this somewhat more concretely.
        !           141: 
        !           142: In particular,
        !           143: we assume that the information on a person is represented as an entry in the
        !           144: OSI Directory.
        !           145: As such,
        !           146: the ``handle'' associated with each person is a Directory Distinguished Name
        !           147: (DN).
        !           148: However,
        !           149: we further assume that a user need not know the value of this name.
        !           150: Rather,
        !           151: the user provides commonly known naming information about a person,
        !           152: and the user interface to the Directory somehow determines the correct DN,
        !           153: and then presents publically readable information from the entry associated
        !           154: with that DN.
        !           155: 
        !           156: In the NYSERNet/PSI White Pages Pilot Project,
        !           157: this first step is assumed to be an iterative process:
        !           158: first,
        !           159: ``areas'' of the Directory likely to contain the entry are identified,
        !           160: usually by searching;
        !           161: and,
        !           162: second,
        !           163: in each of those areas,
        !           164: a search for the entry is initiated.
        !           165: In a business context,
        !           166: the area corresponds to an organizational object in the Directory.
        !           167: In contrast,
        !           168: for a personal context,
        !           169: the area might correspond to a locality.
        !           170: In the pilot project,
        !           171: only the organizational case has been extensively used.
        !           172: Nonetheless,
        !           173: experience with the pilot software indicates that the search model is
        !           174: sufficiently general to support either context.
        !           175: 
        !           176: \subsection    {An Implementation}
        !           177: To implement a White Pages service using the OSI Directory,
        !           178: three things are needed:
        !           179: \begin{itemize}
        !           180: \item  an OSI infrastructure,
        !           181:        this is provided by the ISODE,
        !           182:        an openly available implementation of the upper-layers of OSI;
        !           183: 
        !           184: \item  an implementation of the OSI Directory,
        !           185:        this is provided by the ISODE implementation of the Directory,
        !           186:        QUIPU;
        !           187:        and,
        !           188: 
        !           189: \item  a White Pages abstraction,
        !           190:        provided by an administrative discipline along with at least one user
        !           191:        interface through which the service is accessed.
        !           192: \end{itemize}
        !           193: It is important to distinguish between the White Pages {\em service\/} and the
        !           194: OSI Directory {\em technology} as defined in
        !           195: \cite{ISO.Directory,CCITT.Directory}.
        !           196: The White Pages abstraction is provided both by a focused use of the
        !           197: underlying OSI Directory technology
        !           198: and by special user interfaces.
        !           199: Of course,
        !           200: many might view the sole focus of the OSI Directory is to provide a white
        !           201: pages service.
        !           202: As such,
        !           203: the abstraction can be seen simply as the administrative and operational
        !           204: agreements necessary to use X.500.
        !           205: 
        !           206: The ISODE (pronounced {\em I-SO-D-E\/}),
        !           207: or {\em ISO Development Environment}, is a collection of library
        !           208: routines and programs that implements an extensive set of OSI upper-layer
        !           209: services\cite{Open.Book}.%
        !           210: \footnote{It is an unfortunate historical coincidence that the first three
        !           211: letters of the ISODE are ``ISO''.
        !           212: This is not an acronym for the International Organization for Standardization,
        !           213: but rather three letters which,
        !           214: when pronounced in English,
        !           215: produce a pleasing sound.}
        !           216: In brief,
        !           217: the ISODE implementation of the upper-layers of OSI is interesting in four
        !           218: respects:
        !           219: it provides extensive automatic tools for the development of OSI applications;
        !           220: it supports OSI applications on top of both OSI and TCP/IP-based networks;
        !           221: it provides a novel approach to the problems of OSI coexistence
        !           222: and transition;
        !           223: and,
        !           224: it is openly available (non-proprietary).
        !           225: 
        !           226: The ISODE implementation of the OSI Directory,
        !           227: QUIPU\cite{QUIPU.Directory},
        !           228: was donated by University College London.
        !           229: QUIPU was originally developed as a part of the INCA
        !           230: (Integrated Network Architecture) project
        !           231: (under the auspices of the ESPRIT initiative of the EEC).
        !           232: The Inca of Peru did not have writing.
        !           233: Instead,
        !           234: they stored information on strings,
        !           235: carefully knotted in a specific manner with colored thread,
        !           236: and attached to a larger rope.
        !           237: Such a device was known as a {\em Quipu\/}
        !           238: (pronounced {\em kwip-ooo}).
        !           239: The encoding was obscure,
        !           240: and could only be read by selected trained people:
        !           241: the {\em Quipucamayocs}.
        !           242: The Quipu was a key component of Inca society,
        !           243: as it contained information about property and locations throughout
        !           244: the extensive Inca empire.
        !           245: 
        !           246: QUIPU is a complete implementation of the OSI Directory,
        !           247: based on the {\oldstyle 1988\/} CCITT recommendations\cite{CCITT.Directory}
        !           248: and ISO standards\cite{ISO.Directory}.
        !           249: As with the entire ISODE,
        !           250: QUIPU is coded in the {\em C\/} programming language\cite{C.Language} and runs
        !           251: on the \unix/ operating system.
        !           252: 
        !           253: The QUIPU Directory User Agent (DUA) supports a {\em C\/} language procedural
        !           254: interface to access the full Directory Access Service.
        !           255: The interface is relatively straight-forward,
        !           256: mapping ``programmer-friendly'' procedure calls to the formal service.
        !           257: Code to manipulate ASN.1 structures is automatically generated using
        !           258: facilities provided by the ISODE. 
        !           259: 
        !           260: The DUA interface can be used directly at the programmatic level,
        !           261: or exported from a interface process called \verb"dish"~---~the DIrectory
        !           262: SHell.
        !           263: 
        !           264: The QUIPU Directory System Agent (DSA) is memory-based:
        !           265: it uses the native \unix/ file-system to provide stable-storage between
        !           266: reboots, but otherwise maintains all data in program memory.
        !           267: As might be expected,
        !           268: providing that the DSA avoids paging,
        !           269: execution of the lookup and search facilities of the Directory can be realized
        !           270: in a timely fashion.
        !           271: Naturally, when an update operation occurs,
        !           272: the copy on disk is updated and a journal entry written before the update is
        !           273: acknowledged.
        !           274: The disk copy is stored in a textual format to facilitate examination.
        !           275: As this copy is read only once~---~when the DSA starts,
        !           276: typically when \unix/ goes multi-user~---~the cost of such a strategy is
        !           277: believed to be relatively small if properly implemented and tuned.
        !           278: 
        !           279: The DSA supports both Directory distributed operations (DSA-DSA) and the
        !           280: Directory Abstract Service (DUA-DSA),
        !           281: along with the full range of standard Directory object classes and attributes
        !           282: types.
        !           283: Further,
        !           284: a large number of other attribute types have been defined,
        !           285: both to facilitate experimentation and support the White Pages service.
        !           286: Most notably these attribute types were necessary to support automatic use of
        !           287: replication of information in the Directory.
        !           288: 
        !           289: Having now briefly introduced the implementation used in the pilot project,
        !           290: we now describe the refinements which were necessary to offer a working system.
        !           291: 
        !           292: \newpage
        !           293: \section       {Directory System Issues}
        !           294: The system-related refinements used in the pilot project are all artifacts of
        !           295: the QUIPU design\cite{QUIPU.Design}.
        !           296: These are best described in terms of the object classes and associated
        !           297: attribute types which are manipulated by a QUIPU DSA.
        !           298: However,
        !           299: before these are introduced it is necessary to discuss two topics:
        !           300: the textual convention used for writing DNs,
        !           301: and how the DSAs navigate the DIT.
        !           302: 
        !           303: \subsection    {Writing Distinguished Names}
        !           304: Although the textual notation used to write DNs should be unimportant.
        !           305: For expository (and local) purposes it is important to have a concise notation.
        !           306: 
        !           307: A Distinguished Name is written as an ordered series of RDNs separated by
        !           308: an \verb"`@'"-sign with the most significant RDN appearing at the left;
        !           309: e.g.,
        !           310: \begin{quote}\small\begin{verbatim}
        !           311: c=US@o=NYSERNet Inc.
        !           312: \end{verbatim}\end{quote}
        !           313: refers to an entry with an RDN of \verb"o=NYSERNet Inc."
        !           314: whose parent has an RDN of \verb"c=US".
        !           315: In turn,
        !           316: this parent entry is an immediate child of the root.
        !           317: To avoid any potential ambiguity,
        !           318: one usually prefixes a \verb"`@'"-sign to a string when referring to a fully
        !           319: qualified Distinguished Name;
        !           320: e.g.,
        !           321: \begin{quote}\small\begin{verbatim}
        !           322: @c=US@o=NYSERNet Inc.
        !           323: \end{verbatim}\end{quote}
        !           324: always refers to the same entry regardless of context.
        !           325: Finally,
        !           326: if an RDN consists of multiple attributes,
        !           327: then these are separated by a \verb"`%'"-sign;
        !           328: e.g.,
        !           329: \begin{quote}\small\begin{verbatim}
        !           330: @l=North America@o=NYSERNet Inc.%l=US
        !           331: \end{verbatim}\end{quote}
        !           332: 
        !           333: Tables~\ref{attribute-std} and~\ref{attribute-new}
        !           334: on pages~\pageref{attribute-std} and~\pageref{attribute-new},
        !           335: respectively,
        !           336: list the attribute types commonly used in the pilot project,
        !           337: any abbreviations, and the syntax associated with each attribute's value.
        !           338: In the interests of brevity,
        !           339: the abbreviated form is used when writing DNs.
        !           340: 
        !           341: \subsection    {DIT Navigation}
        !           342: When a DUA requests some action from a DSA
        !           343: (e.g., to read an entry),
        !           344: the DSA may not have that information resident.
        !           345: In this case,
        !           346: the DSA has a choice:
        !           347: it may either contact another DSA which is ``closer'' to the information and
        !           348: propagate the request
        !           349: (i.e., {\em chaining\/}),
        !           350: or it may return information about this ``closer'' DSA to the DUA,
        !           351: and let the DUA re-issue its request (i.e., {\em referral\/}).
        !           352: Of course,
        !           353: when DSAs communicate between themselves,
        !           354: they may also chain or refer requests.
        !           355: 
        !           356: The key issue is to understand what the term ``resident'' means with respect
        !           357: to information held by a DSA.
        !           358: In order to improve performance,
        !           359: DSAs {\em employ\/} both replication and caching of information in the
        !           360: Directory.
        !           361: Hence,
        !           362: to explain residency of information,
        !           363: some additional terminology must be introduced.
        !           364: 
        !           365: \subsubsection {Entry Data Blocks}
        !           366: First,
        !           367: we think of the entire global Directory tree as consisting of discrete units
        !           368: of information termed {\em entry data blocks},
        !           369: or simply {\em blocks}.
        !           370: A block consists of a small portion of the tree:
        !           371: the immediate children of a particular node.
        !           372: Thus the phrase ``this DSA holds a copy of the block for \verb"c=US"'' means
        !           373: that the DSA in question has information about the {\em attributes\/} of 
        !           374: the nodes which exist immediately below the \verb"c=US" entry,
        !           375: such as
        !           376: \begin{quote}\small\begin{verbatim}
        !           377: c=US@o=NYSERNet Inc.
        !           378: \end{verbatim}\end{quote}
        !           379: The phrase does not imply that the DSA has any information, whatsoever,
        !           380: about {\em entries\/} beneath these immediately subordinate nodes,
        !           381: e.g.,
        !           382: \begin{quote}\small\begin{verbatim}
        !           383: c=US@o=NYSERNet Inc.@ou=Research and Development
        !           384: \end{verbatim}\end{quote}
        !           385: There are three kinds of blocks that a DSA might hold:
        !           386: \begin{itemize}
        !           387: \item  a {\em slave\/} copy refers to complete, authoritative information of
        !           388: a block:
        !           389: the DSA knows about all of the entries and all of the children of the node
        !           390: corresponding to that particular block.
        !           391: Slave copies are regularly updated by contacting an {\em upstream\/} DSA,
        !           392: and comparing timestamps associated with the two copies of the block.
        !           393: 
        !           394: \item  a {\em cache\/} copy refers to possibly partial information that a DSA
        !           395: has received during its execution lifetime:
        !           396: the DSA may know about some of the children and possibly some of their attributes.
        !           397: When a DSA chains a request for some information and the information returns
        !           398: through the DSA,
        !           399: that DSA may decide to cache that information for some short period of time
        !           400: (e.g., 30~minutes).
        !           401: 
        !           402: \item  the term {\em master\/} copy is self-evident.
        !           403: Only a single DSA may hold the master copy for any portion of the tree.
        !           404: \end{itemize}
        !           405: 
        !           406: With these terms now described,
        !           407: the {\em residency requirement\/} is simply enumerated as:
        !           408: \[\begin{tabular}{|r|l|}
        !           409: \hline
        !           410: \multicolumn{1}{|c|}{\bf Operation Requested}&
        !           411:                \multicolumn{1}{|c|}{\bf Copy Required for Residency}\\
        !           412: \hline
        !           413: read, compare& master, slave, or cache\\
        !           414: list, search&  master, or slave\\
        !           415: update&                master\\
        !           416: \hline
        !           417: \end{tabular}\]
        !           418: (Actually,
        !           419: a cached copy might be used to satisfy a list request,
        !           420: depending on the service controls used with the operation.)
        !           421: 
        !           422: Hence,
        !           423: while the pilot relies primarily on replication (slave blocks) to speed
        !           424: queries,
        !           425: updates still rely on a centralized entity (containing the master block) being
        !           426: available. 
        !           427: (This is the best compromise can be taken without making the system
        !           428: tremendously more complex,
        !           429: e.g.,
        !           430: introducing distributed database technology.)
        !           431: 
        !           432: Finally,
        !           433: note that the EDB approach is much coarser than a
        !           434: ``distributed entry'' capability.
        !           435: Although distributing across several DSAs the attribute and children
        !           436: information for a single entry may be administrative attractive,
        !           437: it is felt to be technically intractable at this time.
        !           438: 
        !           439: \subsubsection {Use of Presentation Address}
        !           440: Only within a single OSI community can homogeneous interworking be achieved.
        !           441: It is important to realize that the value of a white pages service increases
        !           442: as its scope increases.
        !           443: As such,
        !           444: it is important to appreciate that OSI applications are implemented on a wide
        !           445: range of end-to-end protocol combinations.
        !           446: Sadly,
        !           447: these are largely incompatible (e.g., TP4/CLNP and TP0/X.25).
        !           448: In order to provide homogeneous service to the user,
        !           449: the DSAs must be able to compare two OSI presentation addresses and determine
        !           450: if an association can be established directly between the two.
        !           451: This need arises in two cases.
        !           452: 
        !           453: First,
        !           454: a DSA wishes to perform an operation and realizes that it must either chain or
        !           455: refer.
        !           456: The DSA compares the presentation address of the application entity
        !           457: on whose behalf it is performing the operation,
        !           458: with the presentation address of a DSA which is closer to the information.
        !           459: If the two addresses belong to the same ``community''
        !           460: (i.e., are compatible),
        !           461: then the DSA knows that it is safe to return a referral.
        !           462: If not,
        !           463: then the DSA realizes that,
        !           464: barring service controls to the contrary,
        !           465: it should chain.
        !           466: 
        !           467: Second,
        !           468: a DSA might wish to contact other DSAs.
        !           469: In this case,
        !           470: the DSA sees if the presentation address of the other DSA is in one of the
        !           471: communities of the local end-system.
        !           472: If so,
        !           473: the DSA knows that it is possible to chain operations to that DSA.
        !           474: Otherwise,
        !           475: in the absence of transport-level bridging,
        !           476: the DSA knows that it can not reach the other DSA.
        !           477: 
        !           478: To further complicate matters,
        !           479: Directory service may be offered by application entities using non-standard
        !           480: end-to-end protocol combinations
        !           481: (e.g., RFC1006/TCP \cite{TSAP.on.TCP}).
        !           482: There must be a means whereby the addresses associated with such entities can
        !           483: be stored in the Directory and subsequently interpreted by entities with
        !           484: knowledge of these non-standard communities.
        !           485: A mechanism for achieving this is defined in \cite{Interim.Addresses}.
        !           486: 
        !           487: Finally,
        !           488: the textual notation used to write presentation addresses should be
        !           489: unimportant.
        !           490: For expository (and local) purposes it is important to have a concise notation.
        !           491: \cite{String.Addresses} defines such a notation.
        !           492: 
        !           493: \subsection    {Objects}
        !           494: The abstract syntax of the classes and attributes described in this note are
        !           495: largely taken from the THORN naming architecture\cite{thorn-na},
        !           496: which was developed in the RARE community.
        !           497: These are optional extensions to what is defined in the X.500 recommendations.
        !           498: 
        !           499: \subsubsection {Object Class: friendlyCountry}
        !           500: In order to provide more intuitive identification of sovereign nations,
        !           501: a new object class,
        !           502: subordinate to the \verb"country" class,
        !           503: has been added.
        !           504: This has but a single mandatory attribute:
        !           505: \begin{describe}
        !           506: \item[friendlyCountryName:]
        !           507:                        gives a user-friendly rendition of the
        !           508:                        country's name (hence the term \verb"friendlyCountry").
        !           509: \end{describe}
        !           510: 
        !           511: \subsubsection {Object Class: domainRelatedObject}
        !           512: In order to experiment with mappings from user's Internet mailboxes into DNs,
        !           513: a means for inverting the Internet Domain Name System (DNS) is needed.
        !           514: A new object class, \verb"domainRelatedObject", is used for this purpose.
        !           515: There is one mandatory attribute:
        !           516: \begin{describe}
        !           517: \item[associatedDomain:]
        !           518:                        identifies a portion of the DNS which is conceptually
        !           519:                        located at an entry of this class.
        !           520: \end{describe}
        !           521: 
        !           522: \subsubsection {Object Class: quipuObject}
        !           523: In order to provide access control to the Directory,
        !           524: an \verb"accessControlList" attribute type,
        !           525: consisting of zero or more positive-access rules,
        !           526: has been defined.
        !           527: This is a attribute type is mandatory of objects within the \verb"quipuObject"
        !           528: class.
        !           529: Further,
        !           530: all entries occuring in an EDB must be of this class.
        !           531: 
        !           532: In addition,
        !           533: there are two optional attribute types.
        !           534: These are maintained automatically by the DSA:
        !           535: \begin{describe}
        !           536: \item[lastModifiedBy:]
        !           537:                        identifies the Directory entity which last modified
        !           538:                        this entry.
        !           539: 
        !           540: \item[lastModifiedTime:]
        !           541:                        identifies the time at which this entry was last
        !           542:                        modified.
        !           543: \end{describe}
        !           544: 
        !           545: \subsubsection {Object Class: quipuNonLeafObject}
        !           546: In order to provide navigational information for DSAs,
        !           547: all non-leaf objects are within the \verb"quipuNonLeafObject".
        !           548: There is one mandatory attribute type:
        !           549: \begin{describe}
        !           550: \item[masterDSA:]
        !           551:                        identifies the Directory entity which is responsible
        !           552:                        for maintaining the MASTER EDB for the children of
        !           553:                        this entry.
        !           554: \end{describe}
        !           555: In addition,
        !           556: there are two optional attribute types:
        !           557: \begin{describe}
        !           558: \item[slaveDSA:]
        !           559:                        identifies DSA(s) which also have authoritative
        !           560:                        information on the immediate children of a non-leaf
        !           561:                        entry.
        !           562: 
        !           563: \item[treeStructure:]
        !           564:                        if present, lists those object classes which the
        !           565:                        immediate children are allowed to take.
        !           566: \end{describe}
        !           567: 
        !           568: \subsubsection {Object Class: quipuDSA}
        !           569: It is necessary to introduce an additional object class,
        !           570: \verb"quipuDSA",
        !           571: to identify those DSAs
        !           572: which implement these refinements.
        !           573: There are several mandatory attribute types:
        !           574: \begin{describe}
        !           575: \item[eDBinfo:]
        !           576:                        Indicates how the DSA participates when propagating
        !           577:                        authoritative EDB information.
        !           578:                        Each attribute lists the DN of a non-leaf entry,
        !           579:                        along with (optionally) the DN of the upstream DSA
        !           580:                        which provides the associated EDB to this DSA,
        !           581:                        and with (optionally) a list of DNs of downstream DSAs
        !           582:                        to which this DSA provides the associated EDB.
        !           583:                        (The dual of the \verb"masterDSA" and \verb"slaveDSA"
        !           584:                        attribute types.)
        !           585: 
        !           586: \item[userPassword:]
        !           587:                        a string containing a password used by the DSA to
        !           588:                        authenticate itself to other DSAs.
        !           589:                        This attribute is not used for DSP authentication
        !           590:                        as it introduces a livelock problem.
        !           591:                        (When strong authentication matures,
        !           592:                        DSP authentication will be used instead.)
        !           593: 
        !           594: \item[manager:]
        !           595:                        the DN of an entry corresponding to the ``super-user''
        !           596:                        for this DSA.
        !           597: 
        !           598: \item[quipuVersion:]
        !           599:                        a simple string relating the version of the software
        !           600:                        being run by this DSA.
        !           601: \end{describe}
        !           602: along with the \verb"acl" attribute.
        !           603: There is also an optional one:
        !           604: \begin{describe}
        !           605: \item[description:]
        !           606:                        a textual description of the DSA.
        !           607: \end{describe}
        !           608: along with the \verb"lastModifiedBy" and \verb"lastModifiedTime" attribute
        !           609: types.
        !           610: 
        !           611: A DSA which implements these refinements also has the value
        !           612: \verb"quipuDSP" for its \verb"supportedApplicationContext" attribute.
        !           613: In addition to offering all of the DSP services on this application context,
        !           614: there is an additional operation,
        !           615: \verb"getEDB",
        !           616: which is used by a downstream DSA to request EDB information from an upstream
        !           617: DSA,
        !           618: if that EDB information has changed.
        !           619: 
        !           620: When a \verb"quipuDSA" must contact another DSA,
        !           621: and several choices are available,
        !           622: it favors those DSAs of the \verb"quipuDSA" class.
        !           623: For example,
        !           624:  caching can not occur without an understanding of the access control
        !           625: policy being applied to an entry.
        !           626: 
        !           627: \subsection    {Naming DSAs}
        !           628: If a \verb"quipuDSA" does not have information resident to satisfy a request,
        !           629: it identifies,
        !           630: to its local knowledge,
        !           631: the furthest non-leaf entry along the path to the desired entry.
        !           632: The \verb"masterDSA" and \verb"slaveDSA" attributes of this entry are
        !           633: consulted to derive the DNs of DSAs which are more likely to be able to
        !           634: perform the desired operation.
        !           635: 
        !           636: Obviously,
        !           637: in order to resolve the \verb"presentationAddress" attribute of the entries
        !           638: corresponding to the closer DSAs,
        !           639: additional lookup in the Directory is needed.
        !           640: As such,
        !           641: a DSA should be at least one level-higher in the DIT than any EDB for which it
        !           642: holds authoritative information.
        !           643: 
        !           644: To see why this is so,
        !           645: consider a DSA named:
        !           646: \begin{quote}\small\begin{verbatim}
        !           647: c=US@o=NYSERNet Inc.@cn=losing
        !           648: \end{verbatim}\end{quote}
        !           649: which,
        !           650: according to the entry for
        !           651: \begin{quote}\small\begin{verbatim}
        !           652: c=US@o=NYSERNet Inc.
        !           653: \end{verbatim}\end{quote}
        !           654: is a \verb"masterDSA",
        !           655: and that there are no \verb"slaveDSA"s for that entry.
        !           656: Now suppose another DSA,
        !           657: called ``naive'',
        !           658: with knowledge only of \verb"c=US",
        !           659: wishes to satisfy a request for a (possibly distant) child of this
        !           660: organization.
        !           661: In order to satisfy the request,
        !           662: the ``naive'' DSA must know the address of the ``losing'' DSA,
        !           663: which can obviously not be determined.
        !           664: 
        !           665: \subsection    {DSA Management}
        !           666: In order to provide a management capability for these refinements,
        !           667: a new attribute type, \verb"control", is defined for use over the DAP.
        !           668: When a DUA is bound as the DSA's manager,
        !           669: it may issue the modify operation to add a value of type \verb"control".
        !           670: This is interpreted by the DSA rather than being applied to the DIT.
        !           671: 
        !           672: The operations of interest are:
        !           673: \begin{itemize}
        !           674: \item  abort DSA;
        !           675: 
        !           676: \item  restart DSA;
        !           677: 
        !           678: \item  refresh EDB from local stable-storage;
        !           679: 
        !           680: \item  rewrite EDB to local stable-storage;
        !           681: 
        !           682: \item  mark EDB as read-only (lock EDB);
        !           683: 
        !           684: \item  unlock EDB;
        !           685: 
        !           686: \item  initiate EDB update procedure from upstream DSA
        !           687:        (either for all EDBs or a particular EDB).
        !           688: \end{itemize}
        !           689: For example,
        !           690: if it is necessary to make a substantive change to an EDB for which the DAP is
        !           691: unappropriate,
        !           692: a DSA manager tells the DSA to lock the EDB,
        !           693: edits the EDB on local stable-storage,
        !           694: tells the DSA re-read the EDB from local stable-storage,
        !           695: and then tells the DSA to unlock the EDB.
        !           696: 
        !           697: Intead,
        !           698: if a DUA issues a read for the \verb"control" attribute of an entry,
        !           699: then the value returned consists of a string:
        !           700: \begin{quote}\scriptsize\begin{verbatim}
        !           701: %d Master entries (in %d EDBs), %d Slave entries (in %d EDBs), %d Cached entries
        !           702: \end{verbatim}\end{quote}
        !           703: giving some very basic information about the EDBs/entries resident in the DSA.
        !           704: 
        !           705: \newpage
        !           706: \section       {Directory User Issues}
        !           707: An important task in any pilot project is to objectively focus the scope of
        !           708: the project:
        !           709: projects with ill-defined goals tend to fail.
        !           710: In the context of the pilot project,
        !           711: an explicit decision was made to focus solely on data relating to persons and
        !           712: organizations.
        !           713: Thus, although the pilot project software supports the full range of Directory
        !           714: objects and attributes, the objects supported in the pilot project are limited
        !           715: to:
        !           716: \begin{quote}\small\begin{tabular}{l}
        !           717: organizations\\ organizational units\\ organizational roles (e.g., ``Chair of
        !           718: the Department'')\\ localities (for those individuals not belonging to an
        !           719: organization)\\ persons
        !           720: \end{tabular}\end{quote}
        !           721: In addition to supporting the appropriate attribute types for these objects,
        !           722: some additional attributes were defined.  For example, users can store a
        !           723: facsimile image of themselves as their \verb"photo" attribute.
        !           724: 
        !           725: The list of standard attribute types supported in the pilot is shown in
        !           726: Table~\ref{attribute-std}.
        !           727: Table~\ref{attribute-new} shows additional attribute types which have been
        !           728: defined for use with the pilot.
        !           729: \tagtable[tp]{INT-1}{Supported Standard Attribute Types}{attribute-std}
        !           730: \tagtable[tp]{INT-2}{Additional Attribute Types}{attribute-new}
        !           731: 
        !           732: \subsection    {Objects}
        !           733: In the pilot project,
        !           734: all of the objects described above are modeled by the standard the
        !           735: corresponding object class,
        !           736: with one exception.
        !           737: 
        !           738: \subsubsection {Object Class: pilotPerson}
        !           739: The \verb"pilotPerson" object class is used to refer to a person in the pilot
        !           740: project.
        !           741: An entry belonging to this class may have any of several additional attributes:
        !           742: \begin{describe}
        !           743: \item[favouriteDrink:]
        !           744:                        which is a string describing the user's favorite drink.
        !           745: 
        !           746: \item[homePhone:]
        !           747:                which is a string describing the phone number of the object
        !           748:                using the international notation; e.g., ``+1 518-283-8860''.
        !           749: 
        !           750: \item[homePostalAddress:]
        !           751:                        which describes how physical mail is addressed to the
        !           752:                        person's home.
        !           753: 
        !           754: \item[info:]
        !           755:                        which is additional, textual information about the
        !           756:                        person.
        !           757: 
        !           758: \item[mobileTelephoneNumber:]
        !           759:                        which is a string describing the user's mobile
        !           760:                        number (e.g., for a cellular phone).
        !           761: 
        !           762: \item[otherMailbox:]
        !           763:                        which is the user's computer mail address
        !           764:                        in various domains.
        !           765:                        The string syntax of this attribute's value is special:
        !           766: \begin{quote}\small\begin{verbatim}
        !           767: <domain> $ <mailbox>
        !           768: \end{verbatim}\end{quote}
        !           769:                        e.g., ``internet \$ [email protected]''.
        !           770: The current list of mail domains are:
        !           771: applelink, bitnet, compuserve, genie, internet, mcimail, nasamail,
        !           772: preferred, and uucp.
        !           773: 
        !           774: \item[pagerTelephoneNumber:]
        !           775:                        which is a string describing the user's pager number.
        !           776: 
        !           777: \item[photo:]
        !           778:                        which is a facsimile bitmap of the user's face.
        !           779: 
        !           780: \item[rfc822Mailbox:]
        !           781:                        which is the user's computer mail address in the
        !           782:                        Internet.
        !           783: 
        !           784: \item[roomNumber:]
        !           785:                        which is a string describing where the person resides
        !           786:                        at the location.
        !           787: 
        !           788: \item[secretary:]
        !           789:                        which is the Distinguished Name of the user's
        !           790:                        administrative support.
        !           791: 
        !           792: \item[userClass:]
        !           793:                        which describe's the user's classification; e.g.,
        !           794:                        ``staff''.
        !           795: 
        !           796: \item[userid:]
        !           797:                        which is the user's login name; e.g., ``mrose''.
        !           798: \end{describe}
        !           799: Thus,
        !           800: Table~\ref{pilot-person} shows all the attributes that might be associated
        !           801: with a person.
        !           802: \tagtable[tp]{INT-3}{Attribute Types for the pilotPerson Object Class}%
        !           803:        {pilot-person}
        !           804: 
        !           805: \subsubsection {Other Object Classes}
        !           806: For completeness sake,
        !           807: Tables~\ref{friendlyCountry-attributes}
        !           808: through~\ref{organizationalRole-attributes} starting on
        !           809: page~\pageref{friendlyCountry-attributes} list the attributes supported for
        !           810: the standard object classes in use by the pilot.
        !           811: \tagtable[tp]{INT-4}{Attribute Types for the friendlyCountry Object Class}%
        !           812:        {friendlyCountry-attributes}
        !           813: \tagtable[tp]{INT-5}{Attribute Types for the organization Object Class}%
        !           814:        {organization-attributes}
        !           815: \tagtable[tp]{INT-6}{Attribute Types for the organizationalUnit Object Class}%
        !           816:        {organizationalUnit-attributes}
        !           817: \tagtable[tp]{INT-7}{Attribute Types for the locality Object Class}%
        !           818:        {locality-attributes}
        !           819: \tagtable[tp]{INT-8}{Attribute Types for the alias Object Class}%
        !           820:        {alias-attributes}
        !           821: \tagtable[tp]{INT-9}{Attribute Types for the organizationalRole Object Class}%
        !           822:        {organizationalRole-attributes}
        !           823: 
        !           824: \subsection    {Naming}
        !           825: In the pilot project,
        !           826: the structure of the DIT is straight-forward:
        !           827: at the root,
        !           828: countries and country-level DSAs reside;
        !           829: in \verb"c=US",
        !           830: organizations and organizational-level DSAs reside.
        !           831: Beyond this,
        !           832: the administrators of the \verb"c=US" DMD are not concerned with how
        !           833: individual organizations are internally structured.
        !           834: 
        !           835: In addition to this simple structure,
        !           836: to aid searching in North America,
        !           837: there is also a top-level locality,
        !           838: \verb"l=North America",
        !           839: which contains aliases to all organizations in the \verb"c=US" and \verb"c=CA"
        !           840: DMDs,
        !           841: e.g.,
        !           842: \begin{quote}\small\begin{verbatim}
        !           843: @l=North America@o=NYSERNet Inc.%l=US
        !           844: \end{verbatim}\end{quote}
        !           845: which has an \verb"aliasedObjectName" attribute value of
        !           846: \begin{quote}\small\begin{verbatim}
        !           847: @c=US@o=NYSERNet Inc.
        !           848: \end{verbatim}\end{quote}
        !           849: 
        !           850: The tasks of the country-level DSAs
        !           851: (there are currently three for \verb"c=US")
        !           852: are:
        !           853: \begin{itemize}
        !           854: \item  provide authoritative information on the root and \verb"c=US"
        !           855:        for replication purposes to organizational-level DSAs;
        !           856:        and,
        !           857: 
        !           858: \item  act as a conduit for chaining to/from foreign DMDs.
        !           859: \end{itemize}
        !           860: The former task is to allow high replication of top-level information to speed
        !           861: searching.
        !           862: The latter task is to permit a means of harmonizing between different
        !           863: end-to-end protocol combinations.
        !           864: 
        !           865: The RDN for organizations is the full name.
        !           866: However,
        !           867: to aid searching,
        !           868: other name forms are allowed as attribute values.
        !           869: For example,
        !           870: the entry 
        !           871: \begin{quote}\small\begin{verbatim}
        !           872: @c=US@o=Performance Systems International
        !           873: \end{verbatim}\end{quote}
        !           874: might have an additional attribute value of ``PSI'' which is not used in its
        !           875: RDN.
        !           876: Because the Directory searches on the basis of attribute values and not RDNs,
        !           877: a user supplying a search string of ``PSI'' will find (at least) the right
        !           878: entry.
        !           879: 
        !           880: \subsection    {Searching}
        !           881: The single most important aspect of the user interface is to relate the naming
        !           882: architecture to a search algorithm.
        !           883: The interaction model is simple.
        !           884: The user provides the interface with:
        !           885: \begin{enumerate}
        !           886: \item  (optionally) the kind of object being looked for;
        !           887: 
        !           888: \item  naming information about where the object resides;
        !           889:        and,
        !           890: 
        !           891: \item  (optionally) qualifying information on the object.
        !           892: \end{enumerate}
        !           893: Based on the kind of object being looked for,
        !           894: the user interface constructs a ``basic'' filter:
        !           895: \[\begin{tabular}{|r|l|}
        !           896: \hline
        !           897: \multicolumn{1}{|c|}{\bf What}&
        !           898:                \multicolumn{1}{|c|}{\bf Basic Filter}\\
        !           899: \hline
        !           900: default&       \tt cn$\approx$X $\lor$ sn$\approx$X $\lor$ mail=X@*\\
        !           901: organization&  \tt o$\approx$X\\
        !           902: unit&          \tt ou$\approx$X\\
        !           903: role&          \tt cn$\approx$X\\
        !           904: locality&      \tt l$\approx$X\\
        !           905: person&                \tt sn$\approx$X $\lor$ mail=X@*\\
        !           906: (or) person&   \tt cn$\approx$X\\
        !           907: \hline
        !           908: \end{tabular}\]
        !           909: where ``$\approx$'' indicates either wildcard, imprecise, or exact matching,
        !           910: based on user-preference,
        !           911: and ``$=$'' indicates exact matching.
        !           912: If wildcarding is desired,
        !           913: but the user does not explicitly specify the substrings,
        !           914: the string ``\verb"*X*"'' is used.
        !           915: 
        !           916: After the basic filter is constructed,
        !           917: if the user supplied qualifying information on the object,
        !           918: an ``info'' filter is appended to the basic filter using logical-AND.
        !           919: \[\begin{tabular}{|r|l|}
        !           920: \hline
        !           921: \multicolumn{1}{|c|}{\bf What}&
        !           922:                \multicolumn{1}{|c|}{\bf Info Filter}\\
        !           923: \hline
        !           924: organization&  \tt businessCategory=X\\
        !           925: unit&          \tt businessCategory=X\\
        !           926: role&          \tt title=X\\
        !           927: person&                \tt title=X\\
        !           928: \hline
        !           929: \end{tabular}\]
        !           930: Next the depth of search must be determined:
        !           931: \[\begin{tabular}{|r|l|}
        !           932: \hline
        !           933: \multicolumn{1}{|c|}{\bf What}&
        !           934:                \multicolumn{1}{|c|}{\bf Depth}\\
        !           935: \hline
        !           936: default&       whole-subtree\\
        !           937: organization&  single-level\\
        !           938: unit&          whole-subtree\\
        !           939: role&          whole-subtree\\
        !           940: locality&      single-level\\
        !           941: person&                whole-subtree\\
        !           942: \hline
        !           943: \end{tabular}\]
        !           944: Finally,
        !           945: a search is performed with these service controls:
        !           946: \begin{quote}\small\begin{verbatim}
        !           947: -preferchaining
        !           948: -dontdereferencealias
        !           949: -notimelimit
        !           950: -nosizelimit
        !           951: -nosearchaliases
        !           952: -types rfc822Mailbox telephoneNumber aliasedObjectName
        !           953: -values
        !           954: \end{verbatim}\end{quote}
        !           955: The last two lines are probably somewhat cryptic.
        !           956: They indicate that for all matched entries,
        !           957: the DSA should return any values associated with those three attribute types.
        !           958: 
        !           959: The task of the user interface is simple:
        !           960: \begin{itemize}
        !           961: \item  if no matches are found,
        !           962:        it reports this to the user;
        !           963: 
        !           964: \item  if exactly one match is found,
        !           965:        then it reads this entry and displays its to the user;
        !           966:        otherwise,
        !           967: 
        !           968: \item  if more than one match is found,
        !           969:        the user interface displays each entry in a concise one-line format
        !           970:        containing either the mailbox or telephone number.
        !           971:        This aids the user in determining which entry might be the one
        !           972:        actually desired.
        !           973:        The user can then direct the interface to expand that particular entry.
        !           974: \end{itemize}
        !           975: If an entry is read,
        !           976: then the service controls are:
        !           977: \begin{quote}\small\begin{verbatim}
        !           978: -preferchaining
        !           979: -dontdereferencealias
        !           980: -notimelimit
        !           981: -nosizelimit
        !           982: \end{verbatim}\end{quote}
        !           983: 
        !           984: All that need be explained now is how the ``baseobject'' for the search is
        !           985: determined.
        !           986: Recall that the user might have supplied something called
        !           987: \begin{quote}
        !           988: ``naming information where the user resides''
        !           989: \end{quote}
        !           990: to the interface.
        !           991: For each kind of object,
        !           992: the user interface maintains a default area (DN) used for searching.
        !           993: These are set by the system administrator,
        !           994: e.g.,
        !           995: \[\begin{tabular}{|r|l|}
        !           996: \hline
        !           997: \multicolumn{1}{|c|}{\bf What}&
        !           998:                \multicolumn{1}{|c|}{\bf Base}\\
        !           999: \hline
        !          1000: default&       \tt @c=US@o=NYSERNet Inc.\\
        !          1001: organization&  \tt @l=North America\\
        !          1002: unit&          \tt @c=US@o=NYSERNet Inc.\\
        !          1003: role&          \tt @c=US@o=NYSERNet Inc.\\
        !          1004: locality&      \tt @c=US\\
        !          1005: person&                \tt @c=US@o=NYSERNet Inc.\\
        !          1006: \hline
        !          1007: \end{tabular}\]
        !          1008: in order to provide sensible searching.
        !          1009: The user may override this by supplying additional naming information.
        !          1010: 
        !          1011: So,
        !          1012: the user interface decides if the additional information was for an
        !          1013: organization, organizational unit, or locality,
        !          1014: constructs a basic filter, and performs a search.
        !          1015: \begin{itemize}
        !          1016: \item  if no matches are found,
        !          1017:        it reports this to the user;
        !          1018: 
        !          1019: \item  if exactly one match is found,
        !          1020:        then it uses that DN as the baseobject for the search;
        !          1021:        otherwise,
        !          1022: 
        !          1023: \item  if more than one match is found,
        !          1024:        the user interface displays each entry in a concise one-line format
        !          1025:        containing either the mailbox or telephone number.
        !          1026:        This aids the user in determining which entry might be the one
        !          1027:        actually desired.
        !          1028:        The user can then direct the interface to continue searching in the
        !          1029:        appropriate areas.
        !          1030: \end{itemize}
        !          1031: Note that prior to using one of these area entries as a baseobject,
        !          1032: the user interface sees if the search returned an \verb"aliasedObjectName"
        !          1033: attribute for the area.
        !          1034: If so,
        !          1035: then the value of this attribute is used for the baseobject.
        !          1036: This is used,
        !          1037: for example,
        !          1038: when the areas being searched are under \verb"l=North America".
        !          1039: 
        !          1040: \subsection    {Browsing}
        !          1041: To browse the White Pages,
        !          1042: a listing capability is needed.
        !          1043: Rather than use the Directory list operation,
        !          1044: it is usually more direct to perform a single-level search looking for any
        !          1045: entry which has
        !          1046: \begin{quote}\small\tt
        !          1047: objectClass$\neq$dSA
        !          1048: \end{quote}
        !          1049: 
        !          1050: \subsection    {Searching Revisited}
        !          1051: Actually,
        !          1052: there are a couple of additional searching capabilities provided by the White
        !          1053: Pages.
        !          1054: 
        !          1055: Although its use is discouraged
        !          1056: interfaces should be able to accept a DN as typed by a user for either naming
        !          1057: or area information.
        !          1058: 
        !          1059: If the naming information given by the user appears to be an Internet-style
        !          1060: mailbox,
        !          1061: then an entirely different search algorithm is used.
        !          1062: Suppose the user enters ``\verb"X"'' in the form:
        !          1063: \begin{quote}\small\begin{verbatim}
        !          1064: local@domain
        !          1065: \end{verbatim}\end{quote}
        !          1066: and either there is wildcarding present in \verb"domain",
        !          1067: or the user specifies area information.
        !          1068: In this case,
        !          1069: a search filter is constructed,
        !          1070: one of
        !          1071: \begin{quote}\small\begin{verbatim}
        !          1072: rfc822Mailbox=*@domain
        !          1073: \end{verbatim}\end{quote}
        !          1074: if no \verb"local" portion was given in ``\verb"X"'';
        !          1075: \begin{quote}\small\begin{verbatim}
        !          1076: rfc822Mailbox=local@*
        !          1077: \end{verbatim}\end{quote}
        !          1078: if no \verb"domain" portion was given in ``\verb"X"'';
        !          1079: or,
        !          1080: \begin{quote}\small\tt
        !          1081: rfc822Mailbox=X $\lor$ otherMailbox="internet \$ X"
        !          1082: \end{quote}
        !          1083: otherwise,
        !          1084: and a whole-subtree search is done.
        !          1085: 
        !          1086: Otherwise,
        !          1087: the user does not specify area information and there is no wildcarding present
        !          1088: in \verb"domain",
        !          1089: the user interface performs an special search to identify those areas likely
        !          1090: to contain the mailbox.
        !          1091: For each DN in the list of areas,
        !          1092: the interface uses that DN as a base object for a whole-subtree search using
        !          1093: the filter:
        !          1094: \begin{quote}\small\tt
        !          1095: rfc822Mailbox=X $\lor$ otherMailbox="internet \$ X"
        !          1096: \end{quote}
        !          1097: So,
        !          1098: how is this list of areas generated?
        !          1099: The user-interface repeatedly performs single-level searches looking for
        !          1100: entries which have an \verb"associatedDomain" value equal to the domain in
        !          1101: question.
        !          1102: If a match is not found,
        !          1103: then a sub-domain is stripped off,
        !          1104: and the search is tried again.
        !          1105: If one or matches are found,
        !          1106: the routine recurses and searching begins anew.
        !          1107: In this fashion,
        !          1108: the routine finds the deepest entries in the DIT associated information about
        !          1109: a (sub-)domain of the DNS.
        !          1110: 
        !          1111: \newpage
        !          1112: \section       {Acknowledgements}
        !          1113: The NYSERNet/PSI White Pages Pilot Project builds on the work of many others:
        !          1114: \begin{itemize}
        !          1115: \item  At the core,
        !          1116:        the ISODE provides the programmatic infrastructure for OSI
        !          1117:        applications.
        !          1118:        So many people have contributed to the ISODE that it is presumptuous
        !          1119:        to attempt to list them.
        !          1120: 
        !          1121: \item  The QUIPU directory from University College London,
        !          1122:        designed by Stephen E.~Kille and programmed primarily by
        !          1123:        Colin J.~Robbins, form the heart of the pilot's functionality.
        !          1124: 
        !          1125: \item  Although NYSERNet and PSI have devoted considerable resources to the
        !          1126:        hardening of QUIPU,
        !          1127:        it should be noted that UCL has been responsible for the vast majority
        !          1128:        of improvements and fixes.
        !          1129: 
        !          1130: \item  The white pages abstraction was designed primarily at NYSERNet with
        !          1131:        the help of several experts: Kille, Robbins, and Einar Stefferud.
        !          1132: 
        !          1133: \item  Geoffrey S.~Goodfellow was kind enough to be the alpha tester for the
        !          1134:        white pages abstraction.
        !          1135: 
        !          1136: \item  The white pages administrators have been patient as the software
        !          1137:        twitches.
        !          1138: 
        !          1139: \item  Finally,
        !          1140:        it should be noted that none of this would be possible if it
        !          1141:        weren't for the excellent end-to-end services provided by the Internet
        !          1142:        suite of protocols (namely the TCP and the IP).
        !          1143: \end{itemize}
        !          1144: 
        !          1145: \newpage
        !          1146: \section*      {Appendix: Differences from NIST OIW Agreements}
        !          1147: Although QUIPU attempts to be faithful to various Directory implementation
        !          1148: profiles,
        !          1149: it is not entirely successful.
        !          1150: QUIPU is believed to be aligned with with the NIST OIW Agreements on the
        !          1151: Directory,
        !          1152: with these exceptions:
        !          1153: \begin{itemize}
        !          1154: \item  QUIPU doesn't enforce the bounds constraints on attributes, filters or 
        !          1155: APDU size.
        !          1156: 
        !          1157: \item  QUIPU does not reject T.61 string formatting characters.
        !          1158: 
        !          1159: \item  QUIPU does not check to if the value of the \verb"countryName"
        !          1160: attribute is defined in ISO3166.
        !          1161: 
        !          1162: \item  If a DN is supplied with no password in an unprotected simple bind,
        !          1163: then QUIPU does not check to see if the DN exists.
        !          1164: 
        !          1165: \item  When comparing attribute of UTCtime syntax,
        !          1166: if the seconds field is omitted,
        !          1167: then QUIPU does not perform the match correctly.
        !          1168: (i.e.,
        !          1169: the seconds field in the attribute values should be ignored, but are not).
        !          1170: 
        !          1171: \item  QUIPU always supplies the optional Chaining argument \verb"originator"
        !          1172: even if the CommonArgument \verb"requestor" is used.
        !          1173: 
        !          1174: \item  QUIPU always supplies the optional Chaining argument \verb"target"
        !          1175: even if the base object in the DAP arguments is the same.
        !          1176: \end{itemize}

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.