File: rfc2258.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (843 lines) | stat: -rw-r--r-- 34,871 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843






Network Working Group                                         J. Ordille
Request for Comments: 2258                Bell Labs, Lucent Technologies
Category: Informational                                     January 1998





                      Internet Nomenclator Project


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The goal of the Internet Nomenclator Project is to integrate the
   hundreds of publicly available CCSO servers from around the world.
   Each CCSO server has a database schema that is tailored to the needs
   of the organization that owns it.  The project is integrating the
   different database schema into one query service.  The Internet
   Nomenclator Project will provide fast cross-server searches for
   locating people on the Internet.  It augments existing CCSO services
   by supplying schema integration, more extensive indexing, and two
   kinds of caching -- all this in a system that scales as the number of
   CCSO servers grows.  One of the best things about the system is that
   administrators can incorporate their CCSO servers into Nomenclator
   without changing the servers. All Nomenclator needs is basic
   information about the server.

   This document provides an overview of the Nomenclator system,
   describes how to register a CCSO server in the Internet Nomenclator
   Project, and how to use the Nomenclator search engine to find people
   on the Internet.










Ordille                      Informational                      [Page 1]

RFC 2258              Internet Nomenclator Project          January 1998


1.  Introduction

   Hundreds of organizations provide directory information through the
   CCSO name service protocol [3]. Although the organizations provide a
   wealth of information about people, finding any one person can be
   difficult because each organization's server is independent.  The
   different servers have different database schemas (attribute names
   and data formats).  The 300+ CCSO servers have more than 900
   different attributes to describe information about people. Very few
   common attributes exist.  Only name and email occur in more than 90%
   of the servers [4].  No special support exists for cross-server
   searches, so searching can be slow and expensive.

   The goal of the Internet Nomenclator Project is to provide fast,
   integrated access to the information in the CCSO servers.  The
   project is the first large-scale use of the  Nomenclator system.
   Nomenclator is a more general system than a white pages directory
   service.  It is a scalable, extensible information system for the
   Internet.

   Nomenclator answers descriptive (i.e. relational) queries.  Users can
   locate information about people, organizations, hosts, services,
   publications, and other objects by describing their attributes.
   Nomenclator achieves fast descriptive query processing through an
   active catalog, and extensive meta-data and data caching.  The active
   catalog constrains the search space for a query by returning a list
   of data repositories where the answer to the query is likely to be
   found.  Meta-data and data caching keep frequently used query
   processing resources close to the user, thus reducing communication
   and processing costs.

   Through the Internet Nomenclator Project, users can query any CCSO
   server, regardless of its attribute names or data formats, by
   specifying the query to Nomenclator (see Figure 1).  Nomenclator
   provides a world view of the data in the different servers.  Users
   express their queries in this world view.  Nomenclator returns the
   answer immediately if it has been cached by a previous query. If not,
   Nomenclator uses its active catalog to constrain the query to the
   subset of relevant CCSO servers.  The speed of the query is
   increased, because only relevant servers are contacted. Nomenclator
   translates the global query into local queries for each relevant CCSO
   server.  It then translates the responses into the format of the
   world view.








Ordille                      Informational                      [Page 2]

RFC 2258              Internet Nomenclator Project          January 1998


   --------------------------------------------------------------------


                     +-------------+             +-------------+
                     |             |             |             |
         World View  |             | Local View  |             |
         Query       |             | Query       |  Relevant   |
         ----------->|             |------------>|             |
                     | Nomenclator |             |  CCSO       |
                     |             |             |             |
         <-----------|             |<------------|  Server     |
          World View |             |  Local View |             |
          Response   |             |  Response   |             |
                     +-------------+             +-------------+



                      Figure 1:  A Nomenclator Query

                  Nomenclator translates queries to and from
                  the language of the relevant CCSO servers.

   --------------------------------------------------------------------

   The Internet Nomenclator Project makes it easier for users to find a
   particular CCSO server, but it does not send all queries to that
   server.  When Nomenclator constrains the search for a query answer,
   it screens out irrelevant queries from ever reaching the server.
   When Nomenclator finds an answer in its cache, it screens out
   redundant queries from reaching the server.  The server becomes
   easier to find and use without experiencing the high loads caused by
   exhaustive and redundant searches.

   The Internet Nomenclator Project creates the foundation for a much
   broader heterogeneous directory service for the Internet.  The
   current version of Nomenclator provides integrated access to CCSO and
   relational database services. The Nomenclator System Architecture
   supports fast, integrated searches of any collection of heterogeneous
   directories.  The Internet Nomenclator Project can be enhanced to
   support additional name services, or provide intergated query
   services for other application domains. The project is starting with
   CCSO services, because the CCSO services are widely available and
   successful.

   Section 2 describes the Nomenclator system in more detail.  Section 3
   explains how to register a CCSO server as part of the project.
   Section 4 briefly describes how to use Nomenclator.  Section 5
   provides a summary.



Ordille                      Informational                      [Page 3]

RFC 2258              Internet Nomenclator Project          January 1998


2.  Nomenclator System

   Nomenclator is a scalable, extensible information system for the
   Internet. It supports descriptive (i.e. relational) queries.  Users
   locate information about people, organizations, hosts, services,
   publications, and other objects by describing their attributes.
   Nomenclator achieves fast descriptive query processing through an
   active catalog, and extensive meta-data and data caching.

   The active catalog constrains the search space for a query by
   returning a list of data repositories where the answer to the query
   is likely to be found.  Components of the catalog are distributed
   indices that isolate queries to parts of the network, and smart
   algorithms for limiting the search space by using semantic,
   syntactic, or structural constraints.  Meta-data caching improves
   performance by keeping frequently used characterizations of the
   search space close to the user, thus reducing active catalog
   communication and processing costs.  When searching for query
   responses, these techniques improve query performance by contacting
   only the data repositories likely to have actual responses, resulting
   in acceptable search times.

   Administrators make their data available in Nomenclator by supplying
   information about the location, format, contents, and protocols of
   their data repositories.  Experience with Nomenclator shows that
   gathering a small amount of information from data owners can have a
   substantial positive impact on the ability of users to retrieve
   information.  For example, each CCSO administrator provides a mapping
   from the local view of data (i.e. the local schema) at the CCSO
   server to Nomenclator's world view.  The administrator also supplies
   possible values for any attributes with small domains at the data
   repository (such as the "city" or "state_or_province" attributes).
   With this information, Nomenclator can isolate queries to a small
   percentage of the CCSO data repositories, and provide an integrated
   view of their data.  Nomenclator provides tools that minimize the
   effort that administrators expend in characterizing their data
   repositories.  Nomenclator does not require administrators to change
   the format of their data or the access protocol for their database.

2.1 Components of a Nomenclator System

   A Nomenclator system is comprised of a distributed catalog service
   and a query resolver (see Figure 2).  The distributed catalog service
   gathers meta-data about data repositories and makes it available to
   the query resolver. Meta-data includes constraints on attribute






Ordille                      Informational                      [Page 4]

RFC 2258              Internet Nomenclator Project          January 1998


   values at a data repository, known patterns of data distribution
   across several data repositories, search and navigation techniques,
   schema and protocol translation techniques, and the differing schema
   at data repositories.

   --------------------------------------------------------------------


                     +-------------+             +-------------+
                     |             |             |             |
         World View  |             |  Meta Data  |             |
         Query       |             |  Request    | Distributed |
         ----------->|   Query     | ----------->|             |
                     |   Resolver  |             |  Catalog    |
                     |             |             |             |
         <-----------|   (caches)  | <-----------|  Service    |
          World View |             |  Meta Data  |             |
          Response   |             |  Response   |             |
                     +-------------+             +-------------+



                   Figure 2: Components of a Nomenclator System

   --------------------------------------------------------------------

   Query resolvers at the user sites retrieve, use, cache, and re-use
   this meta-data in answering user queries.  The catalog is "active" in
   two ways. First, some meta-data moves from the distributed catalog
   service to each query resolver during query processing.  Second, the
   query resolver uses the initial meta-data, in particular the search
   and navigation techniques, to generate additional meta-data that
   guides query processing.  Typically, one resolver process serves a
   few hundred users in an organization, so users can benefit from
   larger resolver caches.

   Query resolvers cache techniques for constraining the search space
   and the results of previously constrained searches (meta-data), and
   past query answers (data) to speed future query processing.  Meta-
   data and data caching tailor the query resolver to the specific needs
   of the users at the query site.  They also increase the scale of a
   Nomenclator system by reducing the load from repeated searches or
   queries on the distributed catalog service, data repositories, and
   communications network.







Ordille                      Informational                      [Page 5]

RFC 2258              Internet Nomenclator Project          January 1998


   The distributed catalog service is logically one network service, but
   it can be divided into pieces that are distributed and/or replicated.
   Query resolvers access this distributed, replicated service using the
   same techniques that work for multiple data repositories.

   A Nomenclator system naturally includes many query resolvers.
   Resolvers are independent, but renewable, query agents that can be as
   powerful as the resources available at the user site.  Caching
   decreases the dependence of the resolver on the distributed catalog
   service for frequently used meta-data, and on data repositories for
   frequently used data.  Caching thus improves the number of users that
   can be supported and the local availability of the query service.

2.2 Meta-Data Techniques

   The active catalog structures the information space into a collection
   of relations about people, hosts, organizations, services and other
   objects. It collects meta-data for each relation and structures it
   into "access functions" for locating and retrieving data.  Access
   functions respond to the question: "Where is data to answer this
   query?"  There are two types of responses corresponding to the two
   types of access functions.  The first type of response is: "Look over
   there." "Catalog functions" return this response; they constrain the
   query search by limiting the data repositories contacted to those
   having data relevant to the query. Catalog functions return a
   referral to data access functions that will answer the query or to
   additional catalog functions to contact for more detailed
   information.  The second response to "Where?" is: "Here it is!" "Data
   access functions" return this response; they understand how to obtain
   query answers from specific data repositories.  They return tuples
   that answer the query.  Nomenclator supplies access functions for
   common name services, such as the CCSO service, and organizations can
   write and supply access functions for data in their repositories.

   Access functions are implemented as remote or local services.  Remote
   access functions are services that are available through a standard
   remote procedure call interface.  Local access functions are
   functions that are supplied with the query resolver.  Local access
   functions can be applied to a variety of indexing and data retrieval
   tasks by loading them with meta-data stored in distributed catalog
   service.  Remote access functions are preferred over local ones when
   the resources of the query resolver are inadequate to support the
   access function.  The owners of data may also choose to supply remote
   access functions for privacy reasons if their access functions use
   proprietary information or algorithms.  Local functions are preferred
   whenever possible, because they are highly replicated in resolver
   caches.  They can reduce system and network load by bringing the
   resources of the active catalog directly to the users.



Ordille                      Informational                      [Page 6]

RFC 2258              Internet Nomenclator Project          January 1998


   Remote access functions are simple to add to Nomenclator and local
   access functions are simple to apply to new data repositories,
   because the active catalog provides "referrals" that describe the
   conditions for using access functions.  For simplicity, this document
   describes referral techniques for exact matching of query strings.
   Extensions to these techniques in Nomenclator support matching query
   strings that contain wildcards or word-based matching of query
   strings in the style of the CCSO services.

   Each referral contains a template and a list of references to access
   functions.  The template is a conjunctive selection predicate that
   describes the scope of the access functions.  Conjunctive queries
   that are within the scope of the template can be answered with the
   referral.  When a template contains a wildcard value ("*") for an
   attribute, the attribute must be present in any queries that are
   processed by the referral.  The system follows the following rule:

     Query Coverage Rule:

     If the set of tuples satisfying the selection predicate in a query
     is covered by (is a subset of) the set of tuples satisfying the
     template, then the query can be answered by the access functions in
     the reference list of the referral.

   For example, the query below:

     select * from People where country = "US" and surname = "Ordille";


   is covered by the following templates in Lines (1) through (3), but
   not by the templates in Lines (4) and (5):


      (1) country = "US" and surname = "*"

      (2) country = "US" and surname = "Ordille"

      (3) country = "US"

      (4) organization = "*"

      (5) country = "US" and surname = "Elliott"

   Referrals form a generalization/specialization graph for a relation
   called a "referral graph."  Referral graphs are a conceptual tool
   that guides the integration of different catalog functions into our
   system and that supplies a basis for catalog function construction
   and query processing.  A "referral graph" is a partial ordering of



Ordille                      Informational                      [Page 7]

RFC 2258              Internet Nomenclator Project          January 1998


   the referrals for a relation.  It is constructed using the
   subset/superset relationship: "S is a subset of G."  A referral S is
   a subset of referral G if the set of queries covered by the template
   of S is a subset of the set of queries covered by the template of G.
   S is considered a more specific referral than G; G is considered a
   more general referral than S.  For example, the subset relationship
   exists between the pairs of referrals with the templates listed
   below:


      (1) country = "US" and surname = "Ordille"
          is a subset of
          country = "US"

      (2) country = "US" and surname = "Ordille"
          is a subset of
          country = "US" and surname = "*"

      (3) country = "US" and surname = "*"
          is a subset of
          country ="US"

      (4) country = "US"
          is a subset
          "empty template"

   but it does not exist between the pairs of referrals with the
   following templates:

      (5) country = "US"
          is not a subset of
          department = "CS"

      (6) country = "US" and name = "Ordille"
          is not a subset of
          country = "US" and name = "Elliott"

   In Lines (1) and (2), the more general referral covers more queries,
   because it covers queries that list different values for surname.  In
   Line (3), the more general referral covers more queries, because it
   covers queries that do not constrain surname to a value.  In Line
   (4), the specific referral covers only those queries that constrain
   the country to "US" while the empty template covers all queries.

   During query processing, wildcards in a template are replaced with
   the value of the corresponding attribute in the query.  For any query
   covered by two referrals S and G such that S is a subset of G, the
   set of tuples satisfying the template in S is covered by the set of



Ordille                      Informational                      [Page 8]

RFC 2258              Internet Nomenclator Project          January 1998


   tuples satisfying the template in G.  S is used to process the query,
   because it provides the more constrained (and faster) search space.
   The referral S has a more constrained logical search space than G,
   because the set of tuples in the scope of S is no larger, and often
   smaller, than the set in the scope of G. Moreover, S has a more
   constrained physical search space than G, because the data
   repositories that must contacted for answers to S must also be
   contacted for answers to G, but additional data repositories may need
   to be contacted to answer G.

   In constraining a query, a catalog function always produces a
   referral that is more specific than the referral containing the
   catalog function.  Wildcards ("*") in a template indicate which
   attribute values are used by the associated catalog function to
   generate a more specific referral.  In other words, catalog functions
   always follow the rule:

      Catalog Function Constrained Search Rule:

      Given a referral R with a template t and a catalog function cf,
      and a query q covered by t, the result of using cf to process q,
      cf(q), is a referral R' with template t' such that q  is covered
      by t' and R' is more specific than R.

   Catalog functions make it possible to import a portion of the indices
   for the information space into the query resolver.  Since they
   generate referrals, the resolver can cache the most useful referrals
   for a relation and call the catalog function as needed to generate
   new referrals.

   The resolver query processing algorithm obtains an initial set of
   referrals from the distributed catalog service.  It then navigates
   the referral graph, calling catalog functions as necessary to obtain
   additional referrals that narrow the search space. Sometimes, two
   referrals that cover the query have the relationship of general to
   specific to each other.  The resolver eliminates unnecessary access
   function processing by using only the most specific referral along
   each path of the referral graph.

   The search space for the query is initially set to all the data
   repositories in the relation.  As the resolver obtains referrals to
   sets of relevant data repositories (and their associated data access
   functions) it forms the intersection of the referrals to constrain
   the search space further.  The intersection of the referrals includes
   only those data repositories listed in all the referrals.
   Intersection combines independent paths through the referral graph to
   derive benefit from indices on different attributes.




Ordille                      Informational                      [Page 9]

RFC 2258              Internet Nomenclator Project          January 1998


2.3 Meta-Data and Data Caching

   A Nomenclator query resolver caches the meta-data that result from
   calling catalog functions.  It also caches the responses for queries.
   If the predicate of a new query is covered by the predicate of a
   previous query, Nomenclator calculates the response for the new query
   from the cached response of the old query.  Nomenclator timestamps
   its cache entries to provide measures of the currentness of query
   responses and selective cache refresh.  The timestamps are used to
   calculate a t-bound on query responses [5][1].  A t-bound is the time
   after which changes may have occurred to the data that are not
   reflected in the query response. It is the time of the oldest cache
   entry used to calculate the response.  Nomenclator returns a t-bound
   with each query response.  Users can request more current data by
   asking for responses that are more recent than this t-bound. Making
   such a request flushes older items from the cache if more recent
   items are available.  Query resolvers calculate a minimum t-bound
   that is some refresh interval earlier than the current time.
   Resolvers keep themselves current by replacing items in the cache
   that are earlier than the minimum t-bound.

2.4 Scale and Performance

   Three performance studies of active catalog and meta-data caching
   techniques are available [5].  The first study shows that the active
   catalog and meta-data caching can constrain the search effectively in
   a real environment, the X.500 name space.  The second study examined
   the performance of an active catalog and meta-data caching for single
   users on a local area network.  The experiments showed that the
   techniques to eliminate data repositories from the search space can
   dramatically improve response time.  Response times improve, because
   latency is reduced.  The reduction of latency in communications and
   processing is critical to large-scale descriptive query optimization.
   The experiments also showed that an active catalog is the most
   significant contributor to better response time in a system with low
   load, and that meta-data caching functions to reduce the load on the
   system.  The third study used an analytical model to evaluate the
   performance and scaling of these techniques for a large Internet
   environment.  It showed that meta-data caching plays an essential
   role in scaling the distributed catalog service to millions of users.
   It also showed that constraining the search space with an active
   catalog contributes significantly to scaling data repositories to
   millions of users.  Replication and data caching also contribute to
   the scale of the system in a large Internet environment.







Ordille                      Informational                     [Page 10]

RFC 2258              Internet Nomenclator Project          January 1998


3.  Registering a CCSO Server

   The Internet Nomenclator Project supports the following home page:

      http://cm.bell-labs.com/cs/what/nomenclator

   The home page provides a variety of information and services.

   Administrators can register their CCSO servers through services on
   this home page.  The registration service collects CCSO server
   location information, contact information for the administrator of
   the CCSO server, implicit and explicit constraints on entries in the
   server's database, and a mapping from the local schema of the CCSO
   server to the schema of the world view.

   The implicit and explicit constraints on the server's database are
   the fuel for Nomenclator's catalog functions.  The registration
   center currently collects constraints on organization name,
   department, city, state or province name, country, phone number,
   postal code, and email address.  These constraints are automatically
   incorporated into Nomenclator's distributed catalog service.  They
   are used by catalog functions in query resolvers to constrain
   searches to relevant CCSO servers.  For example, a database only
   contains information about the computer science and electrical
   engineering departments at a French university.  The department,
   organization and country attributes are constrained.  Nomenclator
   uses these constraints to prevent queries about other departments,
   organizations or countries from being sent to this CCSO server.

   The mapping from the local schema of the CCSO server to the schema of
   the world view allows Nomenclator to translate queries and responses
   for the CCSO server.  The registration center currently collects this
   mapping by requesting an example of how to translate a typical entry
   in the CCSO server into the world view schema and, optionally, an
   example of how to translate a canonical entry in the world view
   schema into the local schema of the CCSO server [4].  These examples
   are then used to generate a mapping program that is stored in the
   distributed catalog service.  The CCSO data access function in the
   query resolver interprets these programs to translate queries and
   responses communicated with that CCSO server.  We plan to release the
   mapping language to CCSO server administrators, so administrators can
   write and maintain the mapping for their servers.  We have
   experimented with more than 20 mapping programs.  They are seldom
   more than 50 lines, and are often shorter.  It typically takes one or
   two lines to map an attribute.






Ordille                      Informational                     [Page 11]

RFC 2258              Internet Nomenclator Project          January 1998


4.  Using Nomenclator

   The Internet Nomenclator Project currently provides a centralized
   query service on the Internet.  The project runs a Nomenclator query
   resolver that is accessible through its Web page (see the URL in
   Section 3) and the Simple Nomenclator Query Protocol (SNQP) [2].

   The service answers queries that are a conjunction of string values
   for attributes.  A variety of matching techniques are supported
   including exact string matching, matching with wildcards, and word-
   based matching in the style of the CCSO service.  Our web interface
   uses the Simple Nomenclator Query Protocol (SNQP) [2].  Programmers
   can create their own interfaces by using this protocol to communicate
   with the Nomenclator query resolver.  They will require the host name
   and port number for the query resolver which they can obtain from the
   Nomenclator home page.  SNQP, and hence the web interface, are
   defined for US-ASCII.  Support for other character sets will require
   further work.

   Subsequent phases of the project will provide enhanced services such
   as providing advice about the cost of queries and ways to constrain
   queries further to produce faster response times, and allowing users
   to request more current data.  We also plan to distribute query
   resolvers, so users can benefit from running query resolvers locally.
   Local query resolvers reduce latency for the user, and distribute
   query processing load throughout the network.

5.  Summary

   The Internet Nomenclator Project augments existing CCSO services by
   supplying schema integration and fast cross-server searches. The key
   to speed in descriptive query processing is an active catalog, and
   extensive meta-data and data caching.  The Nomenclator system is the
   result of research in distributed systems [5][6][7][4].  It can be
   extended to incorporate other name servers, besides the CCSO servers,
   and to address distributed search and retrieval challenges in other
   application domains. In addition to providing a white pages service,
   the Internet Nomenclator Project will evaluate how an active catalog,
   meta-data caching and data caching perform in very large global
   information system.  The ultimate goal of the project is to refine
   these techniques to provide the best possible global information
   systems.









Ordille                      Informational                     [Page 12]

RFC 2258              Internet Nomenclator Project          January 1998


6.  Security Considerations

   In the Internet Nomenclator Project, the participants' data are
   openly available and read-only. Since the risk of tampering with
   queries and responses is considered low, this version of Nomenclator
   does not define procedures for protecting the information in its
   queries and responses.

7.  References


   [1]   H. Garcia-Molina, G. Wiederhold. "Read-Only Transactions in
         a Distributed Database,"  ACM Transactions on Database Systems
         7(2), pp. 209-234.  June 1982.

   [2]   Elliott, J., and J. Ordille, "The Simple Nomenclator Query
         Protocol (SNQP)," RFC 2259, January 1998.

   [3]   S. Dorner, P. Pomes. "The CCSO Nameserver: A Description,"
         Computer and Communications Services Office Technical Report,
         University of Illinois, Urbana, USA. 1992. Avaialble in the
         current "qi" distribution from
         <URL:ftp://uiarchive.cso.uiuc.edu/local/packages/ph>

   [4]   A. Levy, J. Ordille. "An Experiment in Integrating Internet
         Information Sources," AAAI Fall Symposium on AI Applications in
         Knowledge Navigation and Retrieval, November 1995.
         <URL:http://cm.bell-labs.com/cm/cs/doc/95/11-01.ps.gz>

   [5]   J. Ordille. "Descriptive Name Services for Large Internets,"
         Ph. D. Dissertation. University of Wisconsin. 1993.
         <URL:http://cm.bell-labs.com/cm/cs/doc/93/12-01.ps.gz>

   [6]   J. Ordille, B. Miller. "Distributed Active Catalogs and
         Meta-Data Caching in Descriptive Name Services," Thirteenth
         International IEEE Conference on Distributed Computing Systems,
         pp. 120-129.  May 1993.
         <URL:http://cm.bell-labs.com/cm/cs/doc/93/5-01.ps.gz>

   [7]   J. Ordille, B. Miller. "Nomenclator Descriptive Query
         Optimization in Large X.500 Environments," ACM SIGCOMM
         Symposium on Communications Architectures and Protocols, pp.
         185-196, September 1991.
         <URL:http://cm.bell-labs.com/cm/cs/doc/91/9-01.ps.gz>







Ordille                      Informational                     [Page 13]

RFC 2258              Internet Nomenclator Project          January 1998


8.  Author's Address

   Joann J. Ordille
   Bell Labs, Lucent Technologies
   Computing Sciences Research Center
   700 Mountain Avenue, Rm 2C-301
   Murray Hill, NJ 07974  USA

   EMail: joann@bell-labs.com










































Ordille                      Informational                     [Page 14]

RFC 2258              Internet Nomenclator Project          January 1998


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Ordille                      Informational                     [Page 15]