File: rfc1491.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 (1011 lines) | stat: -rw-r--r-- 34,883 bytes parent folder | download | duplicates (8)
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
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011






Network Working Group                                          C. Weider
Request for Comments: 1491                           Merit Network, Inc.
FYI: 21                                                        R. Wright
                                            Lawrence Berkeley Laboratory
                                                               July 1993


                  A Survey of Advanced Usages of X.500

Status of this Memo

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

Abstract

   This document is the result of a survey asking people to detail their
   advanced usages of X.500. It is intended to show how various
   organizations are using X.500 in ways which extend the view of X.500
   as a "White Pages" service.  This RFC is a product of the Integrated
   Directory Services Working Group of the Application and User Services
   Areas of the IETF.

1. Introduction

   As the use of X.500 spreads in the Internet, organizations are
   finding uses for it which go beyond the "white pages" paradigm which
   has been used to introduce it to new users. Consequently, to document
   those new uses and to encourage the wider use of X.500, we sent out a
   survey to obtain "advanced usages" of X.500.

1.1 The survey

   The survey we sent out is included here for two purposes:

   1) completeness, and
   2) we'd like to encourage anyone who retrieves this document to send
      us their advanced usage for inclusion in the next revision.

   If you wish to fill this out, please send it to the working group
   list: IDS@merit.edu.









Integrated Directory Services Working Group                     [Page 1]

RFC 1491                 X.500 Advanced Usages                 July 1993


   _____________________________________________________________________

   Application Name:

   Author(s):

   Company or Institution:

   e-mail address for more information:

   If this is a product for public distribution, please give us the
     Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/RESEARCH
     FREE               - Anyone may obtain this product at zero cost.
     COMMERCIAL PRODUCT - One may purchase this product.
     PROTOTYPE/RESEARCH - This product is not yet available, only a
                          prototype.

   If FREE, please give us:
     * FTP and/or FTAM address (if available via FTP and/or FTAM):

   If COMMERCIAL, please give us:
     * Directions to obtain product:

   Availability: (When will product be available?)

   List of platforms product runs on:
   [The platform list can be general - e.g. UNIX]

   Short Description (< 100 words):

   Full Description (< 1 page):

                   Fig. 1: Advanced Usages Survey Template

   ______________________________________________________________________


   This survey went out to the following mailing lists: osi-
   ds@cs.ucl.ac.uk, disi@merit.edu (now ids@merit.edu), and
   dssig@ics.uci.edu.











Integrated Directory Services Working Group                     [Page 2]

RFC 1491                 X.500 Advanced Usages                 July 1993


1.2 Disclaimer

   Descriptions of the advanced usages were written by the implementors,
   and not by the members of IDS. Although IDS has worked with the
   description authors to ensure readability, no guarantees can be made
   regarding the validity of descriptions. Caveat emptor.

2. The Survey Responses

2.1 Index to Responses

   Application                                                   Page

   2.2.1  Global Time-table Information Service ................    3
   2.2.2  Pre-Message Security Protocol         ................    4
   2.2.3  Electronic Data Interchange           ................    5
   2.2.4  Network Topology Information          ................    7
   2.2.4.1  Shared Whois Information Project    ................    7
   2.2.4.2  EARN's Network Directory            ................    8
   2.2.5  Soft Pages                            ................    9
   2.2.6  X-Tel                                 ................   10
   2.2.7  Xerox Clearinghouse                   ................   12
   2.2.8  X.500 Sendmail                        ................   13
   2.2.9  Transparent ODA Conversion            ................   14
   2.2.10 X.500 and the whois protocol          ................   16
   2.2.11 X.400 table handling                  ................   17

2.2 Survey Responses

2.2.1 Global Time-table Information Service

   Application Name: Global Time-table Information Service based on X.500

   Date Received: 7/1/1992

   Date Last Validated: 7/1/1992

   Author(s):
     Jens Hofmann
     Cuno Lanz

   Company or Institution:
     Laboratory of Computer Engineering and Networks,
     Swiss Federal Institute of Technology (ETH Zurich)
     Switzerland

   e-mail address for more information:
     c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch)



Integrated Directory Services Working Group                     [Page 3]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Type:
     experimental prototype; not public

   FTP address: <none>

   Short Description:
     This application aims at integrating the time-table information
     services offered by public transport providers of different scope
     (local, regional, national or international) into a homogeneous and
     unified user interface.  X.500 is used to store the information in
     an autonomous and extensible way.

   Full Description:
     Most of the public tranport providers offer some kind of time-table
     information service like printed directory, help-desk, telephone
     support or PC software. Unfortunately these services have some of
     the following drawbacks:

         - no automatic update of data (information accuracy)
         - no global availability (place independency)
         - no permanent availability (time independency)
         - no inter-provider service (service integration).

     X.500 may serve as a vehicle to overcome these drawbacks as
     follows: The public transport providers store the time-table
     information in a standardized format on locally managed DSAs. There
     is some kind of special purpose DUA which (1) queries the user for
     the input parameters (date, time, source and destination station)
     then (2) searches for the relevant paths by querying the involved
     DSAs and (3) displays the resulting time-table to the user.

     In a diploma thesis a student is developing a new data model which
     supports easy selection of source and destination station as well
     as fast exploring of the time-table information. He is implementing
     a prototype application onto an existing DUA interface (based on
     HyperCard and running on Apple Macintosh) which is connected to the
     world-wide X.500 pilot service over DIXIE protocol.  In order to
     test the prototype application the time-table information of the
     Swiss national public transport company and of most of the regional
     providers around the city of Zurich is included under the branch:
     c=CH;o=ETH Zurich.

2.2.2 Pre-Message Security Protocol

   Application Name:
     Defense Message System Directory

   Date Recieved: 7/1/1992



Integrated Directory Services Working Group                     [Page 4]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Date Last Validated: 7/1/1992

   Author:
     Bob Cooney

   Company or Institution:
     The Naval Computer and Telecommunications Station, Washington
     and
     The Defense Information System Agency

   E-mail address for more information:
     cooney@wnyose.nctsw.navy.mil

   Type:
     experimental prototype, not public

   FTP address: <none>

   Short Description:
     The U.S. Navy will build a directory based on X.500 to support the
     distribution of Pre-Message Security Protocol security keys.

   Long Description:
     The U.S. Navy has been asked to build a directory service to support
     the distribution of Pre-Message Security Protocol security keys.
     The Pre-Message Security Protocol will provide SMTP/X.400 security
     services for unclassified but sensitive mail on the Defense Data
     Network.

     The directory will be based on QUIPU. Proof of concept is expected
     by October 1992, with initial operational capacity by October 1993.

2.2.3 Electronic Data Interchange

   Application Name: An X.500 User Agent for Electronic Data Interchange

   Date Received: 7/10/1992

   Date Last Validated: 7/10/1992

   Author:
     Neil Weldon

   Company or Institution:
     Networks Group,
     Computer Science Dept.,
     Trinity College Dublin,
     Ireland



Integrated Directory Services Working Group                     [Page 5]

RFC 1491                 X.500 Advanced Usages                 July 1993


   e-mail address for more information:
     omahony@cs.tcd.ie
     nmweldon@vax1.tcd.ie

   Type:
     Research product and not for public distribution

   FTP address: <none>

   Short Description:
     The Directory is used to assist in solving the 'first order'
     problem associated with Electronic Data Interchange (EDI). EDI is
     the transfer of trade documents between application processes in a
     processable form.  The 'first order' problem describes the
     agreements that two organizations must come to regarding
     capabilities and preferences, before using EDI.

     To solve this problem we defined object types to allow the storage
     of product catalogues within the Directory, as well as information
     about the EDI readiness of trading partners: addresses, preferences
     and EDI capabilities.

   Full Description:
     Electronic Data Interchange (EDI) is the means by which
     organizations exchange trade related documents between application
     processes in an format which may be processed electronically.

     Before using EDI an organization must establish a series of goals
     and objectives, to establish what type of documents they wish to be
     able to transmit (invoices, purchase orders etc.) and what their
     communication requirements are. Each of these time consuming and
     tedious steps is usually done in conjunction with trading partners
     where these agreements regarding EDI capabilities and preferences
     must be made.

     To solve this 'first order' problem (the need to come to agreements
     with other organizations before trading using EDI takes place) we
     defined object types to allow the storage of product catalogues
     within the Directory. The Directory may also convey information
     regarding the EDI readiness of trading partners: addresses,
     preferences and EDI capabilities.

     Using an experimental User Agent based on Pod which was developed
     at Brunel in the UK, trade documents may be built up by selecting
     products from the stored catalogues. These documents are then
     encoded as an EDI Interchange after the Directory has been queried
     about addresses, etc.




Integrated Directory Services Working Group                     [Page 6]

RFC 1491                 X.500 Advanced Usages                 July 1993


     The current object types are very basic and may only convey the
     minimal amount of information necessary. We are now in the process
     of extending this further to a full product class hierarchy which
     is being based on information that may be sent within an EDI trade
     document using the EDI standard document syntax EDIFACT.

     By using the Directory as a repository for product information to
     aid in EDI the catalogues become available worldwide. They may be
     replicated at various nodes, and the updating and propagation of
     changes to slave copies becomes trivial.

2.2.4 Network Topology Information

   There are two projects in this area; Merit Network's Shared Whois
   Information Project, and EARN's Network Directory.

2.2.4.1 Shared Whois Information Project

   Application Name: Shared Whois Project

   Date Received: 6/1/1993

   Date Last Validated: 6/1/1993

   Author(s): Sheri Repucci

   Company or Institution: Merit Network, Inc.

   e-mail address for more information: swip@merit.edu

   Availability: June 1993

   Type:
     experimental prototype, not public

   List of platforms product runs on: UNIX

   Short Description:
     The Shared Whois Project merges network data held by various
     organizations.  The principal purpose of merging this data is to
     find and resolve conflicting network information between the
     databases.  The longterm goal of this project is to move away from
     the current model of storing similar and/or duplicate network
     information in multiple databases and to move to a X.500
     distributed database model.  To this end, we are working on loading
     the NSFNET network information into X.500 in anticipation of
     participating in a distributed database trial.




Integrated Directory Services Working Group                     [Page 7]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Full Description:
     The Shared Whois Project is a collection of programs and shell
     scripts which collectively merges the network data held by each of
     the participating organizations.  Currently this includes Merit,
     the RIPE-NCC and the InterNIC.  The principal purpose of merging
     this vast quantity of data is to find and resolve conflicting
     network information between the various databases.  It is our
     intent to merge this data bi-weekly and thus rapidly reach, and
     thereafter maintain, a stable set of commonly held network
     information.

     While there is a common set of information all three of the
     participants hold in their various databases, additional
     information unique to the function of each organization is also
     held.  Furthermore, the resulting set of data created by the merger
     holds only one entry per network without attempting to combine the
     variations.  Thus, each entry includes a listing of all databases
     found to contain information for that network as well as all
     databases found to be in conflict with the entry held in the
     resultant set.

     The longterm goal of this project is to move away from the current
     model of storing similar and/or duplicate network information in
     multiple databases and to move to a X.500 distributed database
     model.  To this end, Merit is working to load the NSFNET network
     information into X.500 in anticipation of participating in a trial
     with the InterNIC and others on the road to a globally distributed
     database model.

2.2.4.2 EARN's Network Directory

   Application Name: Ditnet/EARN Network Directory

   Date Received: 7/7/1992

   Date Last Verified: 7/7/1992

   Author(s):
     Peter Sylvester

   Company or Institution:
     Inria Rocquencourt - France

   e-mail address for more information:
     peter.sylvester@inria.fr

   Type: FREE (data owned by EARN/Bitnet)




Integrated Directory Services Working Group                     [Page 8]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Short Description:
     The EARN/Bitnet Network database consists of descriptions of all
     participating members, network nodes, adminstrators, and topology
     information. This database commonly known as BITEARN NODES is being
     made available through x.500.

   Full Description:
     A full description of the contents of the EARN/Bitnet database
     can be found in some EARN internal document which is available
     as a file BITEARN NODES from any NETSERV in EARN/Bitnet. The
     contents of this file is mapped into an X.500 subtree containing
     descriptions of network nodes, adminstrational personnel, and
     topology information.

     The first version of the directory subtree will be created using a
     simple textual mapping to a flat directory tree using private
     attributes.

2.2.5 Soft Pages

   Application Name: Soft Pages

   Date Received: 9/25/1992

   Date Last Validated: 9/25/1992

   Author(s):
     Thomas Johannsen
     Glenn Mansfield

   Company or Institution:
     AIC Systems Laboratory,
     Tohoku University Sendai

   e-mail address for more information:
     spp-support@aic.co.jp

   Type:
     Intended for public distribution, not yet public

   FTP address: <none>

   Short Description:
     A file name look-up services for anonymous FTP servers, provides ls
     -lR information and FTP server address. Additionally, the nearest
     FTP site (from user's site) which holds the requested file is
     chosen.




Integrated Directory Services Working Group                     [Page 9]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Full Description:
     With the growing of number and size of electronic archives for
     documents, programs and the like, the problem of finding and
     retrieving a specific file becomes more and more complex.
     Furthermore, bandwidth in the Internet is still limited. Users
     should be encouraged and supported to do local FTP sessions as often
     as possible instead of getting everything from the other end of the
     world (i.e., the net).

     The Soft Pages Project combines an Archie-like file look-up service
     with network configuration knowledge.  A dedicated User Agent gives
     a suggestion how to retrieve a document in a network traffic
     optimized manner.

     Basically, Directory information introduced by Soft Pages falls
     into two parts: A file information part and a network configuration
     part.

     The file information part describes objects and attributes for file
     servers and their contents. For each file server, names and
     attributes of its files are stored and updated periodically. This
     provides global access to Archie-like information for all
     registered file servers and, furthermore, opens the way to store
     document description together with the file name.  Thus, document
     search is not restricted to file name matches but might be run for
     keywords as well.

     The network configuration part provides information on networks
     (subnetworks), nodes and lines in the Internet. Furthermore, IP
     numbers can be mapped to network and node objects. In order to
     evaluate file server sites, Internet (site to site) connections are
     given a cost index and then alternatives are compared by their cost
     index. Cost index is a calculated parameter representing properties
     of a connection like speed, average traffic, charges etc. where
     values for the latter are hold as attributes to line objects.

     If a document is stored at two or more sites, the site with the
     lowest cost index (which naturally will be the "nearest" in network
     terms) will be chosen for retrieval.  A Soft Pages User Agent
     basically interacts with the Directory for finding a pointer to the
     "best" copy of a file wanted by a user.

2.2.6 X-Tel

   Application Name: X-Tel's advanced applications

   Date received: 7/1/1992




Integrated Directory Services Working Group                    [Page 10]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Date last verified: 7/1/1992

   Author(s):
     Colin Robbins
     Julian Onions
     Graeme Lunt

   Company or Institution: X-Tel Services Ltd.

   e-mail address for more information:
     x500@xtel.co.uk

   Type:
     Commercial Products / Ideas

   Short Description:
     1) Product Information.  Products that have DUA facilites built in
     have a "latest info" button or other request method.  When
     "pressed" a well known node below the X-Tel part of the tree is
     read.  The attributes contain descriptions of the latest version of
     the software, new features etc.  If you decide you would like the
     new version, a second read obtains the information required for a
     template order form.

     2) BUG Status.  As above, but obtains details of known bugs in the
     version of software you are running.  (If only we could find a way
     of putting fixes in, and automatically updating the software
     itself!)

     3) X-Terms.  We have a conferencing product, allowing X users to
     "talk" and share windows.  The problem is identifying which X
     Terminal device a particular user is currently on.  One solution we
     are using is modify a users directory entry during login to say
     which X display they have logged into.  The conference can the
     query the directory, and open windows on the appropriate device.
     The directory is also used to store details of current conferences,
     so new delegates can join the conference easily.

     4) Organisation browsing.  There are a rich set of attributes about
     people and their roles stored in the directory.  We have a special
     purpose DUA that exploits this information, and presents
     information on who manages who, who is secretary for who etc.  This
     is very useful when combined with the search ACL mechanism defined
     in OSI-DS 21 as different views can be given to different
     catergories of users.

     5) MHS use of directory.  The directory is use to store MHS routing
     information (as per the MHS DS working group documents)



Integrated Directory Services Working Group                    [Page 11]

RFC 1491                 X.500 Advanced Usages                 July 1993


     6) Mail Lists.  Details of mailing lists are stored in the
     directory.  With careful use of access control, users can be given
     access so that they can subscribe and unsubscribe themselves
     to/from a list.

     7) Details of restuarants in the Nottingham area are stored in the
     directory!

     8) We plan to use the directory as a rendevuz for a multi-user
     adventure game.  Each "room" will be a different entry, and modify
     operations will be used to pick up and put down objects!

     The next two are "advanced" features of our DUA, they may not be
     considered relevant to this document!

     9) Templates.  The directory is used to store template entries.
     Our DUA then uses this template when adding new users.  Very
     useful, as a number of default attributes can be set.

     10) Editors.  Special purpose editors for a number of complex
     attribute syntaxes are built in to our DUAs.  This includes QUIPU
     ACLs, and X.400 OR Addresses.

2.2.7 Xerox Clearinghouse

   Application Name: Clearinghouse Interface

   Date Received: 7/1/1992

   Date Last Validated: 7/1/1992

   Author(s):
     Margaret Avino

   Company or Institution:
     Xerox Corporation

   e-mail address for more information
     mavin.cin_ops@xerox.com

   Type:
     Early Design/Implementation stages

   Short Description:
     X.500 DSA interface to XNS (Xerox Network Services) Clearinghouse
     directory to provide access to Xerox Corporation's Clearinghouse via
     X.500 DUAs.




Integrated Directory Services Working Group                    [Page 12]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Full Description:
     Xerox uses the XNS network protocol suite to provide Mail, Filing,
     Directory, Authentication, etc. network services for the installed
     based of 45,000+ Xerox workstations.  The Directory is based on the
     XNS Clearinghouse protocol which is similar to X.500 in that it
     contains objects which have properties (attributes) and is a fully
     distributed, replicatable directory.  The searching capabilities of
     the Clearinghouse protocol are not as robust as the X.500 search
     operation and the physical structure of the original database is
     not amenable to complex searches as it could be if it were stored
     in a relational database.

     The first piece of this project is to transfer the data into an
     Oracle relational database and create a new Clearinghouse server
     which accesses the oracle database and is a full fledged member of
     the Clearinghouse, sending and receiving updates to other servers
     using the XNS Clearinghouse protocol.  This will allow powerful SQL
     queries to be performed on the data which will provide some very
     desired functionality such as: list all of the Distribution Lists
     of which this name is a member.

     To build on the new database, we are probing the implementation of
     an X.500 DSA interface to the Oracle Clearinghouse Directory.  This
     would allow X.500 DUAs to access the data and utilize the powerful
     search operations.  It will require the definition of one or more
     new object classes and several new attributes and some thought
     about the appropriate schema.

2.2.8 X.500 Sendmail

   Application Name: X.500 Sendmail

   Date Received: 9/25/1992

   Date Last Verified: 9/25/1992

   Author(s):
     Tim Howes

   Company or Institution:
     University of Michigan

   e-mail address for more information:
     x500@umich.edu

   Type:
     FREE




Integrated Directory Services Working Group                    [Page 13]

RFC 1491                 X.500 Advanced Usages                 July 1993


   FTP address: terminator.cc.umich.edu

   Directions to obtain product:
     get x500/sendmail-5.65.x500.tar.Z

   Short Description:
     Modifications to sendmail-5.65 to do X.500 lookups.

   Full Description:
     We have modified sendmail-5.65 so that it does X.500 lookups,
     returning the value of a user's rfc822Mailbox attribute. It
     handles multiple matches by sending a message containing the
     choices back to the sender.  If the user has no email address in
     X.500, the sender is sent a message containing postal and phone
     information on the user. Both exact and approximate matching is
     supported.

2.2.9 Transparent ODA Conversion

   Application Name: Transparent ODA Conversion

   Date Received: 7/16/1992

   Date Last Verified: 7/16/1992

   Author(s):
     MacFarland Hale (MITRE Open Systems Group)

   Company or Institution:
     The MITRE Corporation

   e-mail address for more information:
     machale@mitre.org

   Type:
     Not Yet Available

   Short Description:
     Plan to use X.500 in conjunction with X.400 and Open Document
     Architecture (ODA) to provide transparent translation of compound
     documents between a sender and one or more recipients.

   Full Description:
     In the future, MITRE would like to combine X.500, X.400 and Open
     Document Architecture (ODA) to automate the conversion of compound
     documents in such a way that the users need not know about ODA or
     even that the conversion is taking place.  This will require new
     and/or updated X.400 products.



Integrated Directory Services Working Group                    [Page 14]

RFC 1491                 X.500 Advanced Usages                 July 1993


     A preferred compound document format (e.g., Microsoft Word,
     FrameMaker, etc.)  for each user is stored in the X.500 directory.
     Each X.400 Message Transfer Agent (MTA) host also houses converters
     between each such format and the Open Document Interchange Format
     (ODIF).

     A user (sender) creates a document with his or her preferred
     compound document editor.  Ideally, the editor software will have a
     link (e.g., button or pull-down menu) to the X.400 User Agent (UA).
     The user invokes the X.400 UA (either using this link, or outside
     of the editor software) to send the document as an X.400 message to
     one or more recipients.  Next, the document may need to be
     converted to ODIF, and this may be done in one of two ways.

     Preferably, the X.400 MTA will be responsible for the ODIF
     conversion.  The UA must somehow be told what format the original
     document is in.  This may be done via the UA invocation from inside
     the editor, via a UA configuration file, by examining the filename
     extension, etc.  It then tags the document to indicate the
     document's original format using one of the body parts:
     "Bilaterally Defined" (body part 14), "Nationally Defined" (body
     part 7) or "Externally Defined" (body part 15).  The UA then sends
     the message, and the MTA interprets the tag to determine the
     document's format.

     For messages internal to MITRE, the MTA will look up the
     recipient's preferred document format.  If it is different than the
     sender's format, the MTA calls the appropriate ODIF converter and
     sends the message.  If the recipient's preferred format is the same
     as that of the document being sent, then no conversion is
     performed.  For messages going outside MITRE, the document is
     always converted to ODIF.  The user may prevent this by specifying
     that the enclosed document is not to be converted, in which case
     the UA simply sends the document in binary form with no special
     tag.

     Alternatively, the UA may do the conversion.  As above, the UA must
     be told the document's original format.  The UA may then call the
     appropriate local ODIF converter, and then send the message.  There
     are some disadvantages to this approach:

       1) ODIF converters must be purchased for and maintained on many
          more hosts;

       2) the document is always converted to ODIF (unless the UA
          accesses the directory, but...);

       3) conversion overhead could be traumatic on a small PC.



Integrated Directory Services Working Group                    [Page 15]

RFC 1491                 X.500 Advanced Usages                 July 1993


     At each recipient host, the X.400 MTA catches the incoming message,
     recognizing the contents as ODIF.  It then looks up the recipients'
     preferred compound document formats, calls the appropriate
     converters to translate the contents, and then delivers the
     messages to the recipients.  If the incoming message contains one
     of the format tags described above, then no conversion is performed
     (since the document is not in ODIF).

     Please note that MITRE is a not-for-profit organization.  We will
     not produce commercial products to support this scenario, but we
     are anxious to encourage and work with companies interested in
     doing so.

2.2.10 X.500 and the WHOIS protocol

   Application Name: Phone Book

   Date Received: 7/15/1992

   Date Last Verified: 7/15/1992

   Author(s):
     Steven Schoch

   Company or Institution:
     NASA Ames Research Center

   e-mail address for more information:
     schoch@sheba.arc.nasa.gov

   Type:
     FREE, see Steve

   Short Description:
     On-line edition of our phone book, using X.500 for storage and
     retrieval.

   Full Description:
     Phone Book is a user application which communicates using the
     Internet WHOIS protocol.  It is listed in the Internet Resources
     Guide as such.  The latest incarnation, however, does not make use
     of a flat file -- it gets information from a DUA that performs
     conversions between information received via DAP and the format that
     users expect to get back from our Phone Book queries.  The change to
     X.500 has allowed us to supply additional data such as E-mail
     address which do not normally appear in the phone book.  The fields
     supplied in response to a query include:




Integrated Directory Services Working Group                    [Page 16]

RFC 1491                 X.500 Advanced Usages                 July 1993


           Name
           Telephone Number
           Mail Stop
           Office Number
           Organizational Affiliation (either a NASA organization code
                   or a contractor name)
           E-mail address

   Queries may be made on any of the fields specified, with the office
   being divided into building and room components.  A sample lookup
   might be:

   trident:297-->phbook yee
   Name                        Phone    M/S     Office    Organization
   --------------------------- -------- ------- --------- ------------
   Arnold M. Yee                 4-4315 258-6   N258/134  COMPSCICOR
   Cindy Yee                            226-3   N226/105  CALSPAN
                                        cyee@ames.arc.nasa.gov
   David H. Yee                  4-4106 213-8   N213/256  EEF
                                        david_yee@qmgate.arc.nasa.gov
   Dr. Helen M C. Yee            4-4769 202A-1  N202A/216 RF
   Harry Yee                     4-6557 213-2   N213/101F EES
   Peter Edmond Yee              4-3812 233-18  N233/240  EDC
                                        yee@atlas.arc.nasa.gov
   Robert Yee                    4-4122 T041-3  TA20/155  SFA
                                        robert_yee@qmgate.arc.nasa.gov

2.2.11 X.400 table handling

   Application Name: X.400 table handling

   Date Received: 7/15/1992

   Date Last Verified: 7/15/1992

   Author(s):
     Julian Onions
     Colin Robbins

   Company or Institution:
     X-Tel Service Limited,
     Nottingham, England

   e-mail address for more information:
     jpo@xtel.co.uk

   Type:
     FREE, not yet available to the general public



Integrated Directory Services Working Group                    [Page 17]

RFC 1491                 X.500 Advanced Usages                 July 1993


   Short Description:
     Implementation of the work of the IETF MHS-DS group. The goal is to
     put X.400 tables into X.500 in order to facilitate gateway and
     routing functions.

   Full Description:
     See the Internet drafts for MHS-DS. NASA Ames Research Center is
     participating in the testing and development of the next release of
     the PP message handling software. The latest update (alpha test)
     contains usage of X.500 by X.400 for RFC 822<->X.400 gatewaying, as
     well as hooks for X.400 intelligent routing. Use of X.500 to
     eliminate static tables will greatly improve the ability to
     maintain the information necessary for mail gatewaying and routing,
     while making it easier to keep this data current and well
     distributed.

3.  Security Considerations

   Security issues are not discussed in this memo.

4.   Authors' Addresses

   Chris Weider
   2901 Hubbard, Pod G
   Ann Arbor, MI 48105

   Phone: (313) 747-2730
   EMail: clw@merit.edu


   Russ Wright
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Berkeley, CA 94720

   Phone: (415) 486-6965
   EMail: wright@lbl.gov














Integrated Directory Services Working Group                    [Page 18]