![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to text.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / report-2|
Return to text.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / report-2 |
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.