![[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-1|
Return to text.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / report-1 |
1.1 root 1: % -*- LaTeX -*-
2:
3: \newpage
4: \section {Introduction}
5: The need for a comprehensive white pages service increases in relation to the
6: size of the user community.
7: The early Internet was served well by a relatively simple facility.
8: Today's rapidly expanding Internet has outstripped the capabilities of the
9: existing system.
10: In order to meet new requirements,
11: NYSERNet, Inc.~is sponsoring a pilot project to provide white pages
12: service based on the OSI Directory.
13:
14: A natural function of computer networks is to form the {\em infrastructure\/}
15: between the users they interconnect.
16: For example,
17: the electronic mail service offered by computer networks provides a means for
18: users to collaborate towards some common goal.
19: In the simplest cases,
20: this collaboration may be solely for the dissemination of information.
21: In other cases,
22: two users may work on joint research project,
23: using electronic mail as their primary means of communication.
24:
25: Most network services are based on the implicit assumption that each user can
26: supply {\em infrastructural information} to
27: facilitate information transfers through the network.
28: For example,
29: electronic mail services expect that an originator can supply
30: addressing information
31: for all the intended recipients.
32: It is not necessarily the task of electronic mail, per se,
33: to provide this infrastructural information to the user.
34:
35: This model works fine in small environments,
36: particularly those where infrastructural information is not difficult to
37: obtain and remember.
38: However,
39: the model does not scale well.
40: Consider the case when the membership of a network consists of hundreds of
41: thousands of users belonging to thousands of organizations.
42: It is no longer reasonable for a single user to provide this information,
43: except in very limited circumstances.
44: Further,
45: it is likely that some of the information changes frequently,
46: due to personnel and other resource movement.
47: The goal of a {\em white pages\/} service is to
48: provide the necessary information, and to mask the complexity of the
49: infrastructural information.
50:
51: \newpage
52: \section {Approach}
53: The approach taken by the NYSERNet White Pages Pilot Project is
54: straight-forward, though somewhat controversial:
55: use the emerging OSI Directory standard as the basis for a white pages
56: service, and realize that technology on top of the Internet's TCP/IP-based
57: infrastructure.
58:
59: The choice of OSI Directory as the cornerstone technology was not made
60: lightly:
61: the richness of the service was evident,
62: and early prototype work had demonstrated that the underlying technology could
63: be realized.
64: Further,
65: it has often been noted that:
66: \begin{quote}\em
67: if one is going to crash and burn,
68: then it's probably best to be at the front of the airplane.
69: \end{quote}
70: Given the magnitude of the white pages problem in the Internet,
71: this analogy seems quite apt!
72:
73: Hence,
74: under the approach taken by the NYSERNet White Pages Pilot,
75: to implement a white pages service,
76: three things are needed:
77: \begin{itemize}
78: \item an OSI infrastructure;
79:
80: \item an implementation of the OSI Directory;
81: and,
82:
83: \item a white pages abstraction,
84: provided by an administrative discipline along with at least one user
85: interface through which the service is accessed.
86: \end{itemize}
87: It is important to distinguish between the white pages {\em service\/} and the
88: OSI Directory {\em technology} as defined by the International Standards.
89: The white pages abstraction is provided both by a focused use of the
90: underlying OSI Directory technology (the administrative discipline)
91: and by special user interfaces.
92:
93: \subsection {OSI Infrastructure}
94: The OSI infrastructure is provided by the ISODE (pronounced {\em I-SO-D-E\/}),
95: or {\em ISO Development Environment}, a collection of library
96: routines and programs that implements an extensive set of OSI upper-layer
97: services.%
98: \footnote{It is an unfortunate historical coincidence that the first three
99: letters of the ISODE are ``ISO''.
100: This is not an acronym for the International Organization for Standardization,
101: but rather three letters which,
102: when pronounced in English,
103: produce a pleasing sound.}
104: In brief,
105: the ISODE implementation of the upper-layers of OSI is interesting in four
106: respects:
107: it provides extensive automatic tools for the development of OSI applications;
108: it supports OSI applications on top of both OSI and TCP/IP-based networks;
109: it provides a novel approach to the problems of OSI coexistence
110: and transition;
111: and,
112: it is openly available (non-proprietary).
113:
114: The ISODE has been the subject of much joy and grief in both the Internet and
115: OSI communities.
116: It would be counter-productive to provide a more exacting description.
117: Interested readers might refer to either
118: the five-volume
119: {\em The ISO Development Environment: User's Manual},
120: for a detailed description,
121: or the professional reference entitled {\em The Open Book} by Rose and
122: published by Prentice-hall.
123:
124: The one detail worth mentioning is that the ISODE implements
125: ``the RFC1006 method'',
126: which is a {\em transport service convergence protocol} providing a
127: near-perfect emulation of the OSI transport service on top of TCP/IP-based
128: networks.
129: Thus,
130: given an TCP/IP-based internet infrastucture,
131: the RFC1006 method makes that infrastructure appear as a ``native'' OSI
132: environment,
133: in which OSI applications require no modifications in order to execute.
134:
135: \subsection {OSI Directory}
136: The ISODE implementation of the OSI Directory,
137: QUIPU
138: was implemented and is currently maintained by the University College London.
139: QUIPU is a complete implementation of the OSI Directory,
140: based on the {\oldstyle 1988\/} ISO standards and CCITT recommendations.
141:
142: The QUIPU Directory User Agent (DUA) can be used directly at the programmatic
143: level,
144: or exported from a interface process called \pgm{dish}~---~the DIrectory SHell.
145: The \pgm{dish} process is available available either as a monolithic \unix/
146: program containing an input-interpreter with several commands,
147: or as several \unix/ programs, each implementing one of those commands.
148:
149: The QUIPU Directory System Agent (DSA) is memory-based:
150: it uses the native \unix/ file-system to provide stable-storage between
151: reboots, but otherwise maintains all data in program memory.
152: As might be expected,
153: providing that the DSA avoids paging,
154: execution of the lookup and search facilities of the Directory can be realized
155: in a timely fashion.
156: Naturally, when an update operation occurs,
157: the copy on disk is updated and a journal entry written before the update is
158: acknowledged.
159: The disk copy is stored in a textual format to facilitate examination.
160: As this copy is read only once~---~when the DSA starts,
161: typically when \unix/ goes multi-user.
162: The cost of such a strategy is believed to be relatively small if properly
163: implemented and tuned.
164:
165: The DSA supports both Directory distributed operations (DSA-DSA) and the
166: Directory Abstract Service (DUA-DSA),
167: along with the full range of standard Directory attributes.
168: Further,
169: a large number of other attributes have been defined,
170: both to facilitate experimentation and support the white pages service.
171: Most notably these attributes were necessary to support automatic use of
172: replication of information in the Directory.
173:
174: \subsection {White Pages Abstraction}
175: The white pages abstraction is the layer of conceptualization which resides
176: above the OSI Directory service.
177: Its purpose is to hide the complexity of the underlying technology and provide
178: a user-friendly service.
179: There are two parts to the service:
180: an {\em administrative discipline}, and a {\em user interface}.
181:
182: \subsubsection {Administrative Discipline}
183: The OSI Directory leaves several issues to be decided by the implementor and
184: service provider.
185: These form the the administrative discipline.
186:
187: At the highest level, the key issue is that each entry in the white pages
188: corresponds to an information object in the OSI Directory.
189: Since the OSI Directory uses {\em Distinguished Names\/} to uniquely identify
190: information objects,
191: the straight-forward approach is to use Directory Distinguished Names as names
192: in the white pages.
193: This mapping considerly simplifies the complexity of providing the white pages
194: service with the OSI Directory.
195: However,
196: since Distinguished Names are length and unwieldy,
197: the user interface must provide effective mechanisms for managing these names
198: for the user.
199:
200: A second issue is to focus the scope of the project on persons and
201: organizations.
202: Although the underlying Directory implementation is capable of managing the
203: entire range of permissible information objects,
204: the user interface focuses on:
205: \begin{quote}\small\begin{tabular}{l}
206: organizations\\ organizational units\\ organizational roles (e.g., ``Chair of
207: the Department'')\\ localities (for those individuals not belonging to an
208: organization)\\ persons
209: \end{tabular}\end{quote}
210: However,
211: some modest work has been done as a part of the pilot in supporting other
212: objects,
213: such as networks, hosts, application processes, and document lookup.
214: Nonetheless,
215: the pilot project is emphasizing providing excellent support for persons and
216: organizations,
217: e.g., by defining additional attributes which are useful.
218: For example, users can store a
219: facsimile image of themselves as their \verb"photo" attribute.
220:
221: The administrative discipline also deals with issues such as caching, and
222: replication.
223: As these mechanisms were severely enhanced after initial deployment,
224: they are discussed later on.
225:
226: The most significant work in terms of the administrative discipline was the
227: writing of a one-hundred page {\em Administration Guide} explaining OSI
228: Directory concepts,
229: along with installation and maintenance procedures,
230: to \unix/ system administrators.
231: This document was well-received by the community of pilot administrators.
232: In addition,
233: a turn-key configuration program,
234: \pgm{dsaconfig},
235: was written to automatically generate the initial Directory configuration for
236: a participating organization.
237: This, too, was well-received.
238:
239: \subsubsection {User Interface}
240: Building the user interface consists of two tasks:
241: selecting the appropriate interface paradigm,
242: and mapping that paradigm to the Directory service.
243:
244: The paradigm selected is based on an earlier Internet nameservice called WHOIS.
245: This style of interaction was chosen for two reasons:
246: \begin{itemize}
247: \item experience with WHOIS since {\oldstyle 1982\/} has shown the syntax to
248: be well-liked by the user community;%
249: \footnote{It is beyond the scope of this report to speculate if the success of
250: the WHOIS syntax is due to a lack of competing nameservices in the Internet.}
251: and,
252:
253: \item by using a similar syntax in the interface,
254: the problem of training the user community is greatly reduced.
255: \end{itemize}
256: The user interface to the white pages service is called \pgm{fred}.%
257: \footnote{In tried-and-true \unix/ style,
258: \pgm{fred} stands for FRont-End to Dish.
259: The \verb"dish" program was mentioned earlier as the primary means for
260: exporting the DUA interface to the \unix/ shell.}
261:
262: Although the program has several commands,
263: only one is used for finding things in the white pages:
264: the \verb"whois" command,
265: which has syntax analogous to the WHOIS command.
266: For each \verb"whois" command,
267: \pgm{fred} constructs one or more Directory operations and then has \pgm{dish}
268: execute those operations.
269:
270: The \verb"whois" syntax in \pgm{fred} has been extended from that of the
271: earlier WHOIS service,
272: in order to provide focused searching at the organizational level.
273: For example, the command:
274: \begin{quote}\small\begin{verbatim}
275: fred> whois rose
276: \end{verbatim}\end{quote}
277: directs \pgm{fred} to find information about something called \verb"rose" in
278: the default searching area.
279: Initially,
280: this results in a single Directory operation,
281: textually described as:
282: \begin{quote}\small\begin{verbatim}
283: search
284: -nosizelimit -timelimit 300
285: -subtree -filter "o=*rose* | ou=*rose* | l=*rose* | cn=*rose*"
286: \end{verbatim}\end{quote}
287: which performs an entire subtree search of the default area,
288: looking for any entry matching the filter.
289: For each match,
290: a Directory read operation is performed and the resulting information
291: displayed accordingly.
292: As might be imagined,
293: more efficient searches can be performed if the user tells \pgm{fred} that a
294: person is being searched for.
295:
296: For a second example, the command
297: \begin{quote}\small\begin{verbatim}
298: fred> whois rose -org nyser
299: \end{verbatim}\end{quote}
300: directs \pgm{fred} to find information about something called \verb"rose"
301: associated with some organization called \verb"nyser".
302: Initially this results in this Directory operation:
303: \begin{quote}\small\begin{verbatim}
304: search
305: -dontdereferencealias
306: -singlelevel -filter "o=*nyser* & objectClass=organization"
307: "@c=US"
308: \end{verbatim}\end{quote}
309: which performs a single-level search in the United States portion of the
310: Directory,
311: looking for any entry matching the filter.
312: For each matching organization,
313: another Directory search operation takes place,
314: similar to that of the first example,
315: but anchored in that organization.
316:
317: The \pgm{fred} program also supports a mailbox specification for searching,
318: and performs a yellow pages-style search accordingly.%
319: \footnote{In general,
320: the distinction between white pages and yellow pages is poorly understood.
321: A white pages search implies that searching occurs on some part of an object's
322: name,
323: whilst a yellow pages search implies that searching occurs on any of an
324: object's attributes.
325: Since, in the OSI Directory,
326: an object's name is one of its attributes,
327: these definitions are problematic at best.}
328:
329: In addition to \pgm{fred},
330: two simple X~windows programs were written to interface to the white pages and
331: the Directory:
332: \begin{itemize}
333: \item \pgm{xwho}, an X~windows version of the \pgm{rwho} program that
334: displays the faces of people logged in on the local network,
335: by using the Directory to retrieve their \verb"photo" attribute;
336: and,
337:
338: \item \pgm{xface}, an X~windows program that displays the face of the person
339: who sent the mail message being read, by first using the Directory to
340: perform an inverse-mapping on the originator's mailbox address, and
341: then retrieving the \verb"photo" attribute.
342: \end{itemize}
343: Finally,
344: the popular \MH/ message handling system was modified to invoke \pgm{fred} to
345: provide name resolution when sending mail messages.
346:
347: \newpage
348: \section {First Milestone: Numbers}
349: Internally,
350: work began on the NYSERNet White Pages Pilot Project in
351: mid-May, {\oldstyle 1989}.
352: After defining and implementing the white pages abstraction,
353: the pilot began offering service in July, {\oldstyle 1989}.
354: The software supporting the pilot was based on ISODE~5.2(beta),
355: a stable, but bug-rich, version of the software.
356: By the end of the three-month mark,
357: 28~Internet sites were participating
358: (half of which where NYSERNet members),
359: and there were approximately 98K entries in the Directory.
360:
361: \subsection {Interop '89}
362: At the Interop$^{\mbox{\tiny TM}}$ trade-show and exhibition in
363: October, {\oldstyle 1989},
364: in the NYSERNet booth,
365: the white pages made its first public debut on the show floor.
366: This was particularly exciting as the floor network had Internet connectivity.
367:
368: \subsection {International Participation}
369: Although NYSERNet is running the US~Directory Management Domain (DMD) as a
370: part of the pilot,
371: one Canadian site wished to participate as well.
372: Since a volunteer for running the CA~DMD was not forthcoming,
373: this site was temporarily placed under the US~DMD.
374:
375: \newpage
376: \section {Second Milestone: Software}
377: The next three months (October through December, {\oldstyle 1989\/}),
378: were spent on two tasks: fixing implementation problems and hardening the code.
379: This resulted in ISODE~5.9(frozen).
380:
381: \subsection {Reliability}
382: Experience with the ISODE~5.2(beta) version of the software led to the motto:
383: \begin{quote}\em
384: it's nearly as good as bind, but not nearly as fast$\ldots$
385: \end{quote}
386: which was a fairly accurate assessment.
387: The software,
388: when running,
389: would act correctly.
390: However,
391: it would frequently crash.
392:
393: Thus, one major activity was to simply track down the myriad of bugs exercised
394: by placing the software in operational use.
395: It should be noted that this phenomenon is true of any complex system when
396: first fielded.
397: In the process of tracking down problems,
398: several performance improvements were made.
399: For example,
400: the program memory storage requirement for each entry was reduced by
401: approximately half.
402:
403: However,
404: two major logic problems existed:
405: DSAs would occasionally lock-up during synchronous operations,
406: and DSAs would not use any intelligence when distributing
407: operations to other DSAs.
408:
409: \subsection {Asynchrony}
410: The asynchrony problem was traced to two areas:
411: \begin{itemize}
412: \item the method used by QUIPU for replication of portions of the Directory
413: Information Tree (DIT) was synchronous,
414: resulting in the DSA blocking for potentially long (or infinite)
415: periods of time;
416: and,
417:
418: \item the underlying ISODE operations were only partially asynchronous;
419: in particular, whilst connection establishment and data reception were
420: non-blocking, connection release and data transmission were
421: synchronous.%
422: \footnote{Actually,
423: connection establishment would actually lock-up if two DSAs
424: simultaneously tried to associate with each other.}
425: \end{itemize}
426: Both problems were relative straight-forward to fix,
427: once the critical areas of code were identified.
428:
429: \subsection {Distribution}
430: When an operation cannot be satisfied locally,
431: a QUIPU DSA will generate,
432: based on knowledge information in the Directory,
433: a list of DSAs which either master or shadow the desired information.
434: The distribution problem was simple in that the QUIPU DSA did not
435: keep track of its previous associations with DSAs in order to judge the
436: ``responsiveness'' or ``reliability''.
437: Its choice was random,
438: which almost always led to problematic interactions
439: (e.g., ``broken'' DSAs frequently appeared at the front of the list).
440:
441: The new software now sorts the list based on several heuristics:
442: whether an association is currently open to that DSA;
443: how long ago the DSA was known to be operating responsively;
444: how long ago the DSA was known to be operating reliably;
445: and,
446: how ``close'' the DSA is.
447: Closeness is determined from a tailorable list of preferred DSAs defined by
448: the DSA's administrator,
449: and by the ``distance'' between the Distinguished Names of the two DSAs in the
450: DIT.
451:
452: In addition,
453: all of the key parameters dealing with replication and caching are now
454: tailorable.
455: At present,
456: cached entries are removed after 6~hours,
457: and shadow copies of information are checked for refresh every 24~hours.
458:
459: \subsection {User Interface}
460: The \pgm{fred} program proved spectacularly uncontroversial,
461: primarily due to its ease of use.
462: In addition to the usual lot of random bug-fixes,
463: two small changes were made during this period:
464: \begin{itemize}
465: \item In all cases,
466: the old software would issue a Directory read operation for all of an
467: entry's attributes when displaying an entry.
468: Of course,
469: the attributes would be cached in the DUA so that subsequent re-display
470: would not require another Directory read operation.
471:
472: However,
473: when searching results in multiple matches,
474: the default action is to display a one-line summary of each matching
475: entry.
476: This one-line summary contains the value of only two or three
477: attributes of the entry.
478: In this circumstance,
479: it is wasteful and slow to issue a Directory read operation for all
480: the attributes,
481: since the user will probably never display all of the entries matched.
482: Hence, when issuing the Directory search operation,
483: \pgm{fred} asks that those three key attributes be returned for each
484: matching entry.
485: Thus,
486: when multiple matches occur,
487: no further Directory operations need be issued.
488:
489: \item In any event,
490: the old software would display the one-line summaries in the same
491: order as the entries returned by the Directory,
492: which was essentially unordered.
493: At present,
494: \pgm{fred} name-collates the entries to provide a sorted output.
495: \end{itemize}
496:
497: \subsection {An Update and Interpolation}
498: After three months of intensive work,
499: ISODE~5.9(frozen) was released,
500: and our motto revised:
501: \begin{quote}\em
502: it's as good as bind, and nearly as fast$\ldots$
503: \end{quote}
504:
505: On 19 December, {\oldstyle 1989},
506: there were at least 84~DSAs in the global Directory pilot,
507: 79~of those were running the QUIPU software,
508: and 31~of those were running something very close to ISODE~5.9(frozen).
509: Those 31~DSAs mastered 64462~entries,
510: for an average of 2079~entries/DSA.
511: If this number is indicative,
512: then, on that day,
513: the size of the global DIT was on the order of 175K~entries.
514:
515: In the US portion of the DIT,
516: the allocation of sites and DSAs looked like this:
517: \[\begin{tabular}{|l|c|c|c|}
518: \hline
519: \multicolumn{1}{|c|}{\null}&
520: \multicolumn{3}{c|}{\bf Type of DSA}\\
521: \cline{2-4}
522: \bf Type of Institution&
523: local& remote& non-NYSER\\
524: \hline
525: University& 8& 3& 7\\
526: Corporate& 1& 1& 6\\
527: Non-profit& 1& 0& 1\\
528: Government& 0& 0& 3\\
529: \cline{2-4}
530: \multicolumn{1}{|r|}{total:}&
531: 10& 4& 17\\
532: \hline
533: \end{tabular}\]
534: where
535: \[\begin{tabular}{rp{3.0in}}
536: local& refers to a NYSERNet site running its own DSA\\
537: remote& refers to a NYSERNet site with a DSA being run remotely\\
538: non-NYSER&
539: refers to an Internet site outside of NYSERNet running its own DSA
540: \end{tabular}\]
541:
542: \newpage
543: \section {Direction}
544: Given the initial success of the pilot and the stability and robustness of the
545: new software,
546: the current direction for the NYSERNet White Pages Pilot is to emphasize
547: growth.
548: The value of a comprehensive white pages service increases in relation to the
549: size of the user community.
550:
551: \subsection {Software}
552: Work on the software is most likely going to lapse into maintenance mode,
553: as no problems remain in the ISODE~5.9(frozen) distribution.
554: As new problems arise,
555: they will be dealt with.
556:
557: \subsubsection {Platforms}
558: At present,
559: the ISODE and QUIPU are supported only on \unix/-based hosts.
560: Although retargeting the entire package for other platforms may be
561: prohibitively expensive,
562: the interprocess communications mechanism between \pgm{fred} and \pgm{dish} is
563: sufficiently general to permit these programs to be distributed across a
564: local area network
565: (e.g., a TCP connection is used as the IPC,
566: even when both processes are resident on the same host).
567:
568: \subsubsection {Interfaces}
569: The most interesting interface that might be developed is probably one based on
570: X~windows which provides a hyper-textual interface to the white pages.
571: This paradigm appears to have much promise.
572:
573: \subsection {(Teutonic) Discipline}
574: In terms of the administrative discipline,
575: there are two areas to be addressed for the next milestone.
576:
577: \subsubsection {Replication}
578: Although individual QUIPU DSAs are now robust and reliable,
579: and distributed operations are now sensible,
580: transient network outages may still prevent information from being available.
581: The solution, of course, is to use more replication in the system.
582: As such,
583: white pages administrators will be encouraged to team with each other in order
584: to provide shadow replication of their organizational DMDs.
585:
586: \subsubsection {International Participation}
587: In the next milestone,
588: NYSERNet will be working with the University of Toronto to provide a tight
589: interaction between the US~and CA~DMDs.
590: In particular,
591: a new locality for North America will be jointly administered.
592: This locality contains Directory aliases to organizations in both the US~and
593: CA~DMDs.
594: With the introduction of this locality,
595: users of the white pages will be able to automatically search both DMDs when
596: looking for information about organizations.
597:
598: \subsection {On the Far Horizon}
599: The NYSERNet White Pages Pilot Project is scheduled to finish at the end of
600: May, {\oldstyle 1990}.
601: At this time,
602: a determination must be made as to the viability of the service.
603: If the service is judged useful and maintainable,
604: then two issues must be addressed:
605: the level of supported required to offer the service,
606: along with additional hierarchy in the US~DMD.
607:
608: \subsubsection {The Need for Support}
609: At present,
610: implementation, maintenance, and support for the white pages abstraction along
611: with the operational pilot is done with 0.75FTE.
612: As the number of sites joining the white pages increases,
613: even with tools to semi-automate administration procedures,
614: the load will be too great.
615: A larger infrastructure will be needed.
616:
617: \subsubsection {Three-level DMD Scheme}
618: The two-level DMD scheme used by the pilot,
619: in which all organizations are placed directly under the~US,
620: is unscalable.
621: A three-level scheme,
622: in which organizations operating with a single state,
623: are placed under the DMD for that state,
624: must be put into effect.
625:
626: \newpage
627: \section {Documents}
628: As of this writing,
629: five documents have been produced:
630: \begin{itemize}
631: \item {\em An Introduction to a NYSERNet White Pages Pilot Project},
632: by Rose and Schoffstall,
633: 12~pages.
634:
635: This introduces the basic notion of a white pages service and outlines
636: the goals and milestones of the project.
637:
638: \item {\em NYSERNet White Pages Pilot: Administrator's Guide},
639: by Rose,
640: 104~pages.
641:
642: This is the authoritative tome which introduces the white pages service and
643: OSI Directory,
644: describes how to configure and install the service,
645: and finally discusses maintenance issues.
646:
647: This is a ``living'' document.
648:
649: \item {\em NYSERNet White Pages Pilot: User's Handbook},
650: by Rose,
651: 38~pages.
652:
653: This describes the pilot project from a user's perspective
654: and provides operational reference for the use of the white pages service.
655: In particular,
656: the white pages user interface, \pgm{fred}, is fully described.
657:
658: There is also a two-page {\em White Pages Quick Reference Sheet},
659: which summarizes the basic commands given to \pgm{fred}.
660:
661: \item {\em An Implementation of a White Pages Service},
662: by Rose,
663: 28~pages.
664:
665: This describes the technology underlying the NYSERNet White Pages Pilot
666: Project.
667:
668: Submitted to the IEEE {\em Journal on Selected Areas in Communications}.
669:
670: \item {\em NYSERNet White Pages Pilot Project},
671: by Rose,
672: 39~images.
673:
674: An accompanying presentation to the JSAC paper.
675: \end{itemize}
676: In addition,
677: independent of the work on the NYSERNet White Pages Pilot Project,
678: four other documents have been produced by the ISODE/QUIPU effort which
679: are germane to white pages:
680: \begin{itemize}
681: \item {\em The ISO Development Environment: User's Manual, Volume 5: QUIPU},
682: by Kille, Robbins, Rose, and Turland,
683: 290~pages.
684:
685: \item {\em Directory Navigation in the QUIPU X.500 System},
686: by Barker and Robbins,
687: 15~pages.
688:
689: \item {\em An interim approach to use of Network Addresses},
690: by Kille,
691: 10~pages.
692:
693: \item {\em A string encoding of Presentation Address},
694: by Kille,
695: 5~pages.
696: \end{itemize}
697:
698: \newpage
699: \section {Acknowledgements}
700: The NYSERNet White Pages Pilot Project builds on the work of many others:
701: \begin{itemize}
702: \item At the core,
703: the ISODE provides the programmatic infrastructure for OSI
704: applications.
705: So many people have contributed to the ISODE that it is presumptuous
706: to attempt to list them.
707:
708: \item The QUIPU directory from University College London,
709: designed by Stephen E.~Kille and programmed primarily by
710: Colin J.~Robbins, form the heart of the pilot's functionality.
711:
712: \item Although NYSERNet has devoted considerable resources to the hardening
713: of QUIPU,
714: it should be noted that UCL has been responsible for the vast majority
715: of improvements and fixes.
716:
717: \item The white pages abstraction was designed primarily at NYSERNet with
718: the help of several experts: Kille, Robbins, and Einar Stefferud.
719:
720: \item Geoffrey S.~Goodfellow was kind enough to be the alpha tester for the
721: white pages abstraction.
722:
723: \item The white pages administrators have been patient as the software
724: twitches.
725:
726: \item Finally,
727: it should be noted that none of this would be possible if it
728: weren't for the excellent end-to-end services provided by the Internet
729: suite of protocols (namely the TCP and the IP).
730: \end{itemize}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.