![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to dir-intro.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 / user|
Return to dir-intro.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / user |
1.1 root 1: % run this through LaTeX with the appropriate wrapper
2:
3: \section {The OSI Directory}
4: The OSI Directory is designed to provide
5: for the management of information objects.
6: The Directory's representation of an information object,
7: typically called an {\em entry},
8: contains information about a person, a place, an organization, etc.
9: Each entry consists of one or more attributes.
10:
11: Each attribute consists of a type,
12: indicating what kind of attribute it is,
13: and one or more values
14: (one of which is termed the {\em distinguished value\/}).
15: Attribute values are structured using a data definition language
16: called Abstract Syntax Notation One (ASN.1).
17: This structuring is important.
18: With structuring,
19: different programs using the Directory will interpret information in the same
20: way.
21: In addition,
22: the Directory will perform type-checking on the values in order
23: to keep things consistent.
24:
25: \subsection {Naming}
26: One of the attributes of an entry is particularly special:
27: it is referred to as the {\em Relative Distinguished Name\/} (RDN) of
28: the entry.
29: The RDN is formed by taking the name of the attribute and its
30: distinguished value.
31: For example,
32: if the attribute in question was called \verb"countryName" and it had
33: a distinguished value of \verb"US", then we might say that the RDN
34: for the entry was \verb"countryName=US".
35: Of course,
36: this is strictly a ``user-friendly'' notation:
37: the Directory uses a concise binary format for representing an RDN.
38: Fortunately,
39: the pilot project software allows simple textual strings to be used in their
40: place and converts back and forth accordingly.
41:
42: In the OSI Directory,
43: information is primarily organized according to a hierarchical tree
44: structure.
45: The top of the tree is termed the {\em root},
46: and has no explicit name.
47: To find the name of an object,
48: termed its {\em Distinguished Name\/} (DN),
49: one concatenates the RDNs found when traversing the tree by starting
50: at the root and proceeding directly to the object's entry.
51:
52: For purposes of discussion,
53: we write a Distinguished Name as an ordered series of RDNs separated by
54: an \verb"`@'"-sign with the most significant RDN appearing at the left;
55: e.g.,
56: \begin{quote}\small\begin{verbatim}
57: countryName=US@organizationName=NYSERNet Inc.
58: \end{verbatim}\end{quote}
59: refers to an entry with an RDN of \verb"organizationName=NYSERNet Inc."
60: whose parent has an RDN of \verb"countryName=US".
61: In turn,
62: this parent entry is an immediate child of the root.
63:
64: To avoid any potential ambiguity when using an interface to the Directory
65: such as \man fred(1c) or \man dish(1c),
66: one prefixes a \verb"`@'"-sign to a string when referring to a fully
67: qualified Distinguished Name;
68: e.g.,
69: \begin{quote}\small\begin{verbatim}
70: @countryName=US@organizationName=NYSERNet Inc.
71: \end{verbatim}\end{quote}
72: always refers to the same entry regardless of context.
73: Note that this is a convention only for interface programs such as these.
74:
75: As a rule,
76: unless searching,
77: text before the \verb"`='"-sign is not case sensitive,
78: neither is text after the \verb"`='"-sign.
79:
80: The Directory itself is distributed,
81: being composed of {\em Directory System Agents\/} (DSAs).
82: A group of DSAs under a common administration is responsible for a portion of
83: the tree,
84: termed a {\em Directory Management Domain\/} (DMD).
85: When a user wishes to access the Directory,
86: a {\em Directory User Agent\/} (DUA) is invoked.
87: This DUA contacts a DSA and issues requests.
88: The DSA may (or may not) have the information locally available.
89: If not,
90: a decision has to be made:
91: either the DSA can contact another DSA to get the information
92: (this is called {\em chaining\/}); or,
93: the DSA can tell the DUA to contact another DSA directly
94: (this is called {\em referral\/}).
95:
96: In short,
97: the DSAs provide mechanisms for traversing the tree and manipulating the
98: information contained therein.
99:
100: In the context of the pilot project,
101: each participating organization runs its own DMD for that organization.
102: This usually consists of a single DSA containing information on that
103: organization,
104: with some of this information being replicated on additional DSAs.
105:
106: \section {Ramifications on the White Pages Service}
107: In order to appreciate the ``feel'' of the white pages service,
108: it is instructive to compare the white pages to an existing facility.
109:
110: You might be familiar with an older facility called WHOIS.
111: This uses a centralized database to keep track of information on various
112: people, networks, hosts, and so on.
113: This facility has proven useful for many years.
114: Only recently,
115: with the explosive growth of the Internet,
116: has the WHOIS mechanism become unworkable.
117:
118: \subsection {Unique Identification of Users}
119: Each entry in the WHOIS database is identified by a unique key,
120: called a {\em handle}.
121: This is (typically) a short string such as \verb"MTR".
122: For a community many orders of magnitude larger than the current entries in
123: the WHOIS database,
124: a handle must contain some structure.
125: This makes it possible to delegate naming authority to different organizations
126: and thus de-centralize management of the white pages service.
127:
128: In the white pages service,
129: a Directory Distinguished Name is used to uniquely identify a person.
130: Thus,
131: while \verb"MTR" might be enough to identify someone named ``Marshall Rose''
132: in the WHOIS database,
133: the DN
134: \begin{quote}\small\begin{verbatim}
135: c=US
136: @o=Performance Systems International
137: @ou=Research and Development
138: @ou=Mountain View
139: @cn=Marshall Rose
140: \end{verbatim}\end{quote}
141: serves as the handle for the same person in the white pages service.
142: (That's progress for you!)
143:
144: Of course,
145: you don't {\em really\/} have to type all that information in.
146: The user interfaces provided with the pilot project allow you to manage very
147: short strings to refer to these DNs.
148: These interfaces also provide a means for incrementally building up a DN from
149: scratch.
150:
151: Actually,
152: the handle in the example above is probably a somewhat longer than the average.
153: In terms of the pilot project,
154: a handle probably looks closer to:
155: \begin{quote}\small\begin{verbatim}
156: c=US@o=Organization Name@ou=Unit Name@cn=FirstName LastName
157: \end{verbatim}\end{quote}
158: While this is still a far cry from a simple three or four letter acronym,
159: it is the price one pays for using a service designed to meet the needs of a
160: global (or galactic) population.
161:
162: \subsection {Searching the White Pages}
163: When the WHOIS database is searched,
164: {\em all\/} entries in the database are examined for a match.
165: Since the current size of the WHOIS database is estimated at roughly 70,000
166: entries,
167: this is an appropriate strategy.
168:
169: Unfortunately,
170: the potential size of the white pages is many orders of magnitude larger than
171: that of the WHOIS database.
172: As such,
173: the information contained in the white pages is distributed.
174: This makes management of the information a shared responsibility,
175: and has the potential to address organization-specific privacy concerns.
176:
177: Thus,
178: when the white pages service is invoked,
179: searches are performed relative to a particular {\em area}.
180: This is similar to the White Pages of the telephone system~---~there are
181: several white pages, one for each particular geographical area.
182: As such,
183: before you can find someone's entry in the white pages,
184: you have to already know the area in which they are listed.
185:
186: The default area is the portion of the Directory corresponding to your own
187: organization.
188: Of course,
189: if you specify a user's handle (a fully-qualified Distinguished Name),
190: this bypasses the default area and goes directly to the portion of
191: the Directory containing the desired entry.
192:
193: Usually,
194: when you are trying to find an entry,
195: you have only partial information.
196: For example,
197: you might know parts of the name of the organization and the person you're
198: looking for.
199: In this case,
200: it is natural to use an iterative process to find the information you desire.
201: You begin by finding the organization(s) likely to contain the entry,
202: you then initiate a search starting at that area.
203:
204: Having said that,
205: I'll let you in on a little secret:
206: in addition to people,
207: organizations and organizational units also have entries in the Directory.
208: As such,
209: searching an {\em area\/} is nothing more than starting a search at a
210: particular node at the tree.
211: Thus,
212: you might look for the organization starting at the \verb"@c=US" node.
213: In order to make searching easy,
214: the pilot project requires that all organizations be listed directly under
215: this node.
216: How the subtree is structured beyond that is an organization-specific matter,
217: although the pilot project provides various guidelines.
218:
219: Thus,
220: to find someone,
221: you look for the organization name in the \verb"@c=US" area.
222: This should give you back a single entry in the Directory,
223: perhaps two or three at the most.
224: You then look for that person in the area corresponding to that entry.
225: To make this easier,
226: the white pages user interface, \pgm{fred}, has a special command syntax
227: which directs it to find out the names of the likely organizations and then
228: search each one for the person you're looking for, automatically!
229:
230: Of course,
231: if you have the cycles and network bandwidth to burn,
232: in theory there is nothing to stop you from simply going to the top of the
233: tree and searching for the person.
234: However,
235: this is {\em very\/} resource-expensive,
236: particularly in terms of time.
237: Since time is probably the most valuable resource you have,
238: it is worth it to issue two commands which complete quickly,
239: rather than one command which may take hours.
240:
241: There are two user interfaces provided with the pilot software.
242: With the ``simple'' one,
243: you follow this two-step process.
244: With the ``complicated'' one,
245: you can form {\em arbitrarily\/} complex queries to the Directory.
246: Thus,
247: if you want to type just one command and don't mind typing a bit more,
248: you can still have an optimized search.
249: Both of these interfaces will be introduced in due course.
250:
251: \subsection {Structure of Information}
252: In addition to a handle,
253: an entry in the WHOIS database consists of a {\em type},
254: which indicates what kind of user is recorded by the entry
255: (e.g., a person);
256: and,
257: several {\em fields}, each containing a textual description.
258:
259: For example,
260: an entry for a person might look like:
261: \begin{quote}\small\begin{verbatim}
262: Rose, Marshall T. (MTR) [email protected]
263: PSI, Inc.
264: PSI California Office
265: POB 391776
266: Mountain View, CA 94039
267: (415) 961-3380
268: \end{verbatim}\end{quote}
269: The first line contains both the handle and all fields available for searching.
270: Here,
271: the handle is \verb"MTR",
272: and there are two fields available for searching:
273: a name and a mailbox.
274: The remainder of the entry is a textual annotation.
275:
276: Because the Directory must accommodate many kinds of access from various users
277: and programs.
278: It is important that the information contained therein be highly structured.
279: As noted earlier,
280: this allows universal understanding of the information,
281: and hence consistent interpretation.
282: Fortunately,
283: most of the information is represented by textual strings.
284:
285: It is important to remember however that all information associated with an
286: entry is contained in an attribute.
287: This attribute has a type,
288: describing both its syntax and semantics.
289: For example,
290: the \verb"surName" attribute of a person has a textual string syntax and
291: semantics corresponding to someone's last name.
292:
293: How the information associated with an entry is displayed to you
294: is {\em strictly\/} a function of the interface you use when talking to the
295: Directory.
296: The Directory will enforce all of the syntactic constraints associated with
297: the attributes,
298: but only the users of the Directory can assign meaning to the attribute
299: semantics.
300:
301: With this in mind,
302: here's an entry associated with a person,
303: as it might be displayed by a user interface:
304: \begin{quote}\small\begin{verbatim}
305: Marshall Rose (3) [email protected]
306: aka: Marshall T. Rose
307:
308: Principal Scientist
309: PSI, Inc.
310: PSI California Office
311: POB 391776
312: Mountain View, CA 94039
313:
314: Telephone: +1 415-961-3380
315: FAX: +1 415-961-3282
316:
317: Mailbox information:
318: Internet: [email protected]
319: UUCP: uupsi!mrose
320:
321: Principal Implementor of the ISO Development Environment
322:
323: Name: Marshall Rose, Mountain View, ...
324: \end{verbatim}\end{quote}
325: Of course,
326: there are dozens of possible ways that this information could have been
327: displayed.
328: Or {\em not\/} displayed~---~for example,
329: there are other attributes which the interface may not care (or be able) to
330: display,
331: such as access control information, passwords, and so on.
332:
333: Appendix~\ref{person:attributes} on page~\pageref{person:attributes} lists all
334: of the attributes which may be present for a person participating in the pilot
335: project.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.