![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to introduction.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 / introduction|
Return to introduction.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / introduction |
1.1 root 1: % -*- LaTeX -*-
2:
3: \input lcustom
4:
5: \documentstyle[12pt,titlepage]{article}
6:
7: \makeatletter
8: \let\titlep@ge=\titlepage
9: \def\titlepage{\titlep@ge \def\thefootnote{\fnsymbol{footnote}}}
10:
11: \let\endtitlep@ge=\endtitlepage
12: \let\endtitlepage=\relax
13:
14: \let\m@ketitle=\maketitle
15: \def\maketitle{\m@ketitle\let\titlepage=\relax\let\endtitlepage=\endtitlep@ge}
16: \makeatother
17:
18: \advance\textwidth by0.5in
19: \advance\oddsidemargin by-0.25in
20: \advance\evensidemargin by-0.25in
21:
22: \begin{document}
23:
24: \title{An Introduction to a NYSERNet\\ White Pages Pilot Project}
25: \author{Marshall T.~Rose\\ Martin L.~Schoffstall\\ NYSERNet, Inc.}
26: \maketitle
27:
28: \begin{abstract}
29: The need for a comprehensive white pages service increases in relation to the
30: size of the user community.
31: The early Internet was served well by a relatively simple facility.
32: Today's rapidly expanding Internet has outstripped the capabilities of the
33: existing system.
34: This paper proposes a new white pages service designed to meet the needs
35: of both the current and future Internet.
36: A pilot project will be undertaken,
37: both to demonstrate the viability of a new service and to provide extended services
38: to a widely distributed pilot community.
39:
40: \footnotetext[0]{\hskip -2\parindent
41: This work was partially supported by the
42: U.S.~Defense Advanced Research Projects Agency
43: and the Rome Air Development Center of the U.S.~Air Force Systems Command
44: under contract number F30602--88--C--0016.
45: The content of the information contained herein does not necessarily reflect
46: the position or the policy of the U.S.~Government,
47: and no official endorsement should be inferred.}
48: \end{abstract}
49:
50: \section {A White Pages Service}
51: A natural function of computer networks is to form the {\em infrastructure\/}
52: between the users they interconnect.
53: For example,
54: the electronic mail service offered by computer networks provides a means for
55: users to collaborate towards some common goal.
56: In the simplest cases,
57: this collaboration may be solely for the dissemination of information.
58: In other cases,
59: two users may work on a joint research project,
60: using electronic mail as their primary means of communication.
61:
62: Most network services are based on the implicit assumption that each user can
63: supply {\em infrastructural information} to
64: facilitate information transfers through the network.
65: For example,
66: electronic mail services expect that an originator can supply
67: addressing information
68: for all the intended recipients.
69: It is not necessarily the task of electronic mail, per se,
70: to provide this infrastructural information to the user.
71:
72: This model works fine in small environments,
73: particularly those where infrastructural information is not difficult to
74: obtain and remember.
75: However,
76: the model does not scale well.
77: Consider the case when the membership of a network consists of hundreds of
78: thousands of users belonging to thousands of organizations.
79: It is no longer reasonable for a single user to provide this information,
80: except in very limited circumstances.
81: Further,
82: it is likely that some of the information changes frequently,
83: due to personnel and other resource movement.
84: The goal of a {\em white pages\/} service is to
85: provide the necessary information, and to mask the complexity of the
86: infrastructural information.
87:
88: \subsection {White Pages in the Real World}
89: The telephone system
90: white pages service provides an excellent model.
91:
92: In the telephone system,
93: the listed user is a person, private enterprise or government organization.
94: To find some infrastructural information associated with a listed user
95: (e.g., a telephone number),
96: the name of the listed user is looked up in the telephone book.
97: Upon finding the name,
98: the telephone number is listed nearby.
99:
100: We note that telephone books also include other information
101: such as a partial postal address of each user.
102: This is an important issue:
103: the telephone white pages book contains more than one kind of information.
104: In fact,
105: if a user of the telephone system had to consult one book for telephone
106: numbers
107: and a second book for postal addresses,
108: the telephone system white pages service would be much less convenient to use.
109: Further,
110: if there are two entries which are similar
111: (e.g., both entries have the same first initial and last name),
112: then additional information may help the user to determine which entry is the
113: ``correct'' listing.
114:
115: At the next level,
116: we see that most telephone books include two parts:
117: the white pages,
118: and the equally familiar yellow pages.
119: The yellow pages contains essentially the same information as the white pages,
120: but in an indexed form with additional key information about the listed users.
121: Rather than indexing by the name of each user,
122: the yellow pages index by the business service offered by each user.
123:
124: Given the scope of the telephone system
125: (both in terms of size and number of autonomous administrations),
126: everyone recognizes that it would be impractical to have a single telephone
127: book for the entire United States, a region, or even a single very large city.
128: Typically,
129: there is a telephone book for each local geographical area.
130: Since use of the telephone system tends to obey the 90\% rule of locality,
131: local telephone books are commonplace.
132: Telephone books for remote areas are found only in small quantities.
133: Of course,
134: there is no reason,
135: other than economics,
136: why any particular set of users might not be listed together in a specialized
137: white pages service.
138:
139: This naturally leads to the last aspect of the telephone system's white pages
140: service, directory assistance.
141: If a telephone book isn't available,
142: then the user places a phone call to ask for assistance in retrieving the
143: desired information.
144: In addition to making remote information readily available,
145: directory assistance has another interesting feature:
146: {\em imprecise matching}.
147: It is not uncommon to have partial or even incorrect information about a user,
148: when trying to determine that user's telephone number.
149: The combination of personnel and computers which provide directory assistance
150: usually employ phonetic matching (soundex) and other heuristics to try and
151: generate a list of entries, of which is the ``correct'' entry.
152:
153: \subsection {White Pages in the Computer World}
154: The role of a white pages service in a computer environment is quite similar
155: to the one played in the real world.
156: To begin,
157: information from the telephone book
158: (name, postal address and telephone number)
159: is available from the white pages service.
160: Further,
161: the ``local'' white pages information maintained by each organization,
162: e.g., an internal telephone directory,
163: is typically available.
164:
165: Because local information is made available through the white pages service,
166: this argues for both distribution of information
167: (each local organization will wish to maintain their own ``part'' of the
168: white pages),
169: and access control
170: (some information, such as internal telephone numbers,
171: may be ``company confidential''). Every organization has some directory
172: information that should not be openly published.
173:
174: In addition to containing infrastructural information for the
175: network community,
176: the white pages service may also contain network information for
177: listed users of the network.
178: Of these,
179: the most notable is a user's electronic mail address.
180: Of course,
181: other information,
182: such as passwords and access rights,
183: might also be available from the white pages service.
184: For example,
185: the white pages service might keep track of the network nodes each user is to
186: be permitted access for cycles or spooling.
187:
188: Finally,
189: the programs which run in the network make use of the white pages service for
190: other purposes.
191: For example,
192: a sophisticated network management program might use the white pages service
193: to obtain information about the computers attached to a particular physical
194: network
195: (e.g., contact information for the system administrators of those systems)
196: in order to perform some task
197: (e.g., notify those administrators of problems).
198:
199: This simple example illustrates the variety of service a white pages offers.
200: First,
201: the network management program asks the white pages service to identify
202: the computers it is interested in.
203: This is probably done with a yellow pages query~---~a search on one of the
204: attributes of the entries for the computers.
205: Second,
206: for each computer identified,
207: the ``administrator'' attribute must be retrieved.
208: The value of this attribute is the name of a person, or the role of a person,
209: which in turn is a pointer to another entry in the white pages service.
210: Thus,
211: the white pages service is again queried for the ``electronic mail address''
212: attribute for each administrator.
213:
214: In order for programs,
215: rather than humans,
216: to make use of the white pages service,
217: it is essential that the information be rigorously structured.
218: This makes manipulative operations feasible:
219: associated with each attribute is a set of procedures defining how operations
220: such as matching, exact or imprecise (as with soundex), are performed.
221:
222: Ultimately,
223: a white pages service might be the unifying facility for both system and
224: network administration:
225: local databases (password files, configuration files, and so on),
226: are generated automatically from the infrastructural information available from
227: the white pages service.
228: By providing a common framework, powerful tools, and semi-intelligent
229: programs,
230: the administrator may be able to configure and maintain all resources in the
231: network.
232: This scenario is beyond the scope of the current discussion,
233: though it is a very probable application in the long term.
234:
235: To appreciate why a new direction is required for white pages service in the
236: Internet,
237: it is useful to briefly examine the current service.
238:
239: \section {The Existing Facility}
240: The Internet community is currently served by the WHOIS facility.
241: This is a simple, text-based service originally deployed in {\oldstyle 1982}.
242: Although the users are predominantly humans,
243: information on some networks, hosts, and so on,
244: are also kept in the WHOIS facility.
245: Currently,
246: it is estimated that there are over 70,000 WHOIS entries.
247:
248: An entry of a user consists of:
249: \begin{itemize}
250: \item a {\em handle},
251: which is a unique key in the database;
252:
253: \item a {\em type},
254: which indicates what kind of user is recorded by the entry
255: (e.g., a person);
256: and,
257:
258: \item several {\em fields},
259: each containing a textual description.
260: \end{itemize}
261: For example,
262: an entry for a person looks like:
263: \begin{quote}\small\begin{verbatim}
264: Rose, Marshall T. (MTR) [email protected]
265: NYSERNet, Inc.
266: Western Development Office
267: 420 Whisman Court
268: Mountain View, CA 94043-2112
269: (415) 961-3380
270: \end{verbatim}\end{quote}
271: The first line contains both the handle and all fields available for searching.
272: Here,
273: the handle is \verb"MTR",
274: and there are two fields available for searching:
275: a name and a mailbox.
276: The remainder of the entry is a textual annotation.
277:
278: Access to the WHOIS facility is via a server program residing at the SRI
279: Network Information Center.
280: The interface follows the query/response paradigm,
281: and provides both for wildcard matching facilities and ambiguous results.
282:
283: The program can also be accessed via the network~---~one query/response
284: interaction is carried on a single network connection.
285:
286: \subsection {Problems with the Existing Facility}
287: It must be emphasized that the existing facility has proven useful for many
288: years.
289: Only recently,
290: with the explosive growth of the Internet,
291: has the WHOIS mechanism become unworkable.
292:
293: There are three problems with the existing facility:
294: \begin{itemize}
295: \item It is centralized; all entry updates must be inserted by a clerk,
296: after the entry's owner/controller requests a change.
297: As such, much of the information is always out of date.
298: Further, the service is subject to the usual availability and
299: congestion problems.
300:
301: \item It contains only limited, unstructured information;
302: while rudimentary postal and electronic mail addresses are useful,
303: the needs of the community have grown much larger.
304: For example,
305: it is often useful to address correspondence to an organizational
306: role (e.g., ``Chair of the Department'').
307: While it is possible for the textual information annotated to each
308: entry to contain such information,
309: given the current informational framework,
310: it is not possible to search for or otherwise mechanically process
311: this attribute.
312:
313: \item As a $2^{\underline{\mbox{\scriptsize nd}}}$ order effect of these
314: limitations,
315: most sites maintain their own local white pages service.
316: These local services do not interoperate with the WHOIS facility.
317: This leads to at least two
318: sets of user interfaces, procedures, programs, and so on.
319: \end{itemize}
320: Of course,
321: other Network Information Centers provide similar facilities
322: (such as CSNet or NSFNet, etc.).
323: These do not interoperate with the WHOIS facility
324: and suffer the same general problems.
325:
326: It should be clear that any replacement facility must not only provide
327: (at least) equivalent functionality to WHOIS,
328: but must also address all three of these deficiencies.
329: This replacement
330: should be based on a standard distributed directory service model and
331: the OSI Directory Service is the best available candidate.
332:
333: \section {The OSI Directory}
334: The OSI Directory is designed to provide
335: for the management of names and associated attributes.
336:
337: The OSI Directory is structured in the form of a hierarchical tree.
338: Each object in the tree has a {\em distinguished name},
339: which uniquely identifies it.
340: Associated with each object is one or more {\em attributes}
341: and possibly one or more child objects.
342: The attributes of an object consist of a name and one or more values.
343: One of these values may be marked as a {\em distinguished value} to set it
344: apart from the other values.
345: Based on the name of the attribute,
346: the value(s) are strongly-typed.
347: The OSI Directory standard defines several kinds of attributes along with their
348: associated data types.
349: In addition,
350: users of the Directory may define additional attributes of their own.
351:
352: The Directory itself is distributed,
353: being composed of {\em Directory System Agents\/} (DSAs).
354: A group of DSAs under a common administration is responsible for a portion of
355: the tree,
356: termed a {\em Directory Management Domain\/} (DMD).
357: When a user wishes to access the Directory,
358: a {\em Directory User Agent\/} (DUA) is invoked.
359: This DUA contacts a DSA and issues requests.
360: The DSA may (or may not) have the information locally available.
361: If not,
362: a decision has to be made:
363: either the DSA can contact another DSA to get the information
364: (this is called {\em chaining\/}); or,
365: the DSA can tell the DUA to contact another DSA directly
366: (this is called {\em referral\/}).
367:
368: The operations that the DUA can request of a DSA are fairly general:
369: \begin{itemize}
370: \item read the attributes of an object;
371:
372: \item get a list of the object's children;
373:
374: \item recursively search for objects with certain attribute values;
375:
376: \item compare a given value to an object's attribute;
377:
378: \item add new objects, or attributes to an existing object;
379:
380: \item change the name of an object or its attributes; and,
381:
382: \item delete an object or its attributes.
383: \end{itemize}
384: In short,
385: the DSAs provide mechanisms for traversing the tree and manipulating the
386: information contained therein.
387:
388: \subsection {Existing Implementation}
389: The Directory is one of OSI's newer standards.
390: As such,
391: there are few implementations available.
392:
393: However,
394: one implementation is openly available,
395: QUIPU,
396: as a part of the ISO Development Environment (ISODE).
397: QUIPU is a full-functional implementation of an OSI Directory,
398: and is the subject of (at least) three ongoing pilot projects in OSI Directory
399: services.
400:
401: These pilot projects,
402: while national (U.S., U.K.) and international in scope,
403: are not focused:
404: there are no explicit services to be offered to the user community.
405: Rather,
406: the pilot projects are largely intended to bring together currently disjoint
407: communities to explore aspects of implementation and operation.
408: The scale of these communities is currently quite small.
409:
410: We propose a different project:
411: one which provides useful white pages service to a subset of the Internet
412: community to explore the service provision aspects of the OSI Directory.
413:
414: \section {A Pilot Project}
415: We propose a new white pages service to be offered to members of the NYSERNet
416: community.
417: Participation is strictly voluntary~---~the pilot project is a ``grass roots''
418: effort,
419: both to understand the white pages service desired by users along with
420: the limitations of the OSI Directory in providing those services.
421:
422: \subsection {Goals of the Pilot Project}
423: The primary goal of the pilot project is to encourage organizations to use
424: the OSI Directory to store infrastructural information about their personnel.
425: (Note that this does not require the elimination of existing mechanisms,
426: such as internal telephone directories.)
427:
428: At the next level,
429: organizations will be encouraged to maintain their own Directory Management
430: Domain.
431: However,
432: this is not mandatory;
433: the sponsors of the pilot project will offer to
434: manage a DMD on an organization's behalf~---~either on an interim or
435: permanent basis, for the durtation of the pilot project.
436: (For the Domain Name System,
437: NYSERNet has been offering a similar service for the past three years.)
438:
439: In addition,
440: the sponsor will create and manage a ``dial-up'' DMD for
441: individuals from organizations which are not participating in the pilot.
442:
443: Another goal of the pilot project is to use the same programs and tools to
444: access both global and local white pages information.
445: As a part of this,
446: new applications which might make use of the white pages service,
447: such as private mail,
448: will be encouraged.
449:
450: \subsection {Phases of the Pilot Project}
451: The pilot project consists of three phases.
452:
453: \subsubsection {Phase 0}
454: The first phase, Phase~0, focuses on developing the initial policies and
455: programs for the pilot.
456: Issues such as the naming architecture (how the Directory tree is structured),
457: the kind of information to be stored,
458: and so on,
459: must be decided by the sponsor of the pilot.
460:
461: In addition,
462: a white pages user interface will be developed.
463: Initially,
464: a text-based interface will be used,
465: although later on an X-windows based interface might be developed.
466: The text-based interface will support an interaction mode as close as
467: possible to the WHOIS query syntax.
468:
469: As its primary software,
470: the pilot project will use the QUIPU Directory.
471: To be sure,
472: QUIPU is not a high-performance Directory,
473: nor is it a hardened technology.
474: Nevertheless,
475: it promises to be a solid platform for the development of services which use
476: the OSI Directory.
477:
478: Other Directory implementations may participate in the pilot project,
479: but must do so in ``unsupported'' mode.
480: (It is beyond the scope of this pilot project to debug other people's Directory
481: implementations.)
482:
483: Finally,
484: during Phase~0,
485: prospective sites will be approached to solicit participation in the
486: pilot project.
487: As of this writing,
488: the following organizations have received permission,
489: and are participating in the pilot:
490: \begin{quote}
491: \begin{tabular}{l}
492: Anterior Technology\\
493: Clarkson University\\
494: Columbia University\\
495: Eastman Kodak\\
496: NASA\\
497: Navy\\
498: New Mexico State University\\
499: New York University\\
500: NYSERNet, Inc.\\
501: Polytechnic University\\
502: Rockefeller University\\
503: SUNY Albany\\
504: SUNY Buffalo\\
505: University of Michigan\\
506: University of Pittsburgh\\
507: University of Rochester\\
508: \end{tabular}
509: \end{quote}
510:
511: Phase~0 will complete on June, 30, {\oldstyle 1989}.
512: Upon completion,
513: the sponsor of the pilot will issue a press release announcing the
514: pilot and the participants.
515: Work will also begin on a brochure for users at each participating
516: organization.
517: This brochure will be completed by August 1, {\oldstyle 1989}.
518:
519: \subsubsection {Phase I}
520: Phase~I focuses on collecting data for the pilot project,
521: and determining the responsibilities of a DMD for each organization.
522: The duration of Phase~I varies by participant,
523: once a participant completes Phase~I,
524: it enters Phase~II.
525: For some participants,
526: Phase~I will be completed in less than a week;
527: for others,
528: a month or so may be required.
529:
530: It is the responsibility of each participant to provide data for the
531: Directory.
532: If the participant plans to run the DSA(s) for their DMD,
533: then this is a moot issue.
534: Otherwise,
535: if the sponsor is to run the DSA for the participant's DMD,
536: then the participant must supply the information in an ASCII file
537: formatted to the specification of the sponsor.
538:
539: The sponsor of the pilot project will provide modest management tools
540: to aid in the maintenance of the project's DMDs.
541: For example:
542: a ``tree walker'',
543: a ``skulker'',
544: a program which keeps track of the last update made to an entry,
545: and so on.
546:
547: The sponsor of the pilot project will provide QUIPU DSAs in source form
548: for systems derived from Berkeley \unix/.%
549: \footnote{It is beyond the scope of the pilot project to support the Directory
550: on non-Berkeley \unix/ systems.
551: Considering the widespread penetration of Berkeley \unix/ into every segment
552: of the computing market place,
553: it is difficult to believe that any site doesn't have at least one system
554: running BSD \unix/ available to support white pages.}
555:
556: \subsubsection {Phase II}
557: Phase~II focuses on offering the service to the pilot user community.
558: Each participating organization enters this phase once it has completed its
559: ``initial load'' of its DMD.
560:
561: User interfaces will be supplied in source form for systems derived from
562: Berkeley \unix/.
563: The user interfaces may be easily exported to other platforms via telnet,
564: rlogin, xterm, and as a special network port (ala network WHOIS access).
565: In addition,
566: a special electronic mail address will be supported,
567: which accepts queries in the ``Subject:'' line and body of a message
568: and generates a reply to the originator.
569:
570: The sponsor of the pilot will provide access to the Directory both via
571: the network and via dial-up.
572:
573: It is anticipated that all participants will have entered Phase~II prior
574: to the INTEROP$^{\hbox{\tiny TM}}$ 89 conference and exhibition in early
575: October.
576: As such,
577: the NYSERNet booth at Interop will provide access to the pilot for
578: demonstration purposes.
579:
580: Phase~II completes for all participants on June 1, {\oldstyle 1990}.
581: At this time, the pilot project will be evaluated.
582: If successful,
583: the membership to the pilot project may be expanded beyond NYSERNet,
584: with Phase~I being re-activated on a larger scale.
585: Most likely this will also result in other applications,
586: such as a window-based user interface being fielded.
587:
588: \section {Conclusions}
589: A white pages service has the potential to unify the management of the
590: infrastructural information that is vital to networking.
591: By sponsoring a pilot project,
592: in addition to offering a valuable service to the user community,
593: vital administrative and operational experience will be gained.
594:
595: \showsummary
596:
597: \end{document}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.