File: rfc2713.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites:
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1179 lines) | stat: -rw-r--r-- 40,745 bytes parent folder | download | duplicates (9)
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
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179






Network Working Group                                            V. Ryan
Request for Comments: 2713                                   S. Seligman
Category: Informational                                           R. Lee
                                                  Sun Microsystems, Inc.
                                                            October 1999


     Schema for Representing Java(tm) Objects in an LDAP Directory

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 (1999).  All Rights Reserved.

Abstract

   This document defines the schema for representing Java(tm) objects in
   an LDAP directory [LDAPv3].  It defines schema elements to represent
   a Java serialized object [Serial], a Java marshalled object [RMI], a
   Java remote object [RMI], and a JNDI reference [JNDI].

1. Introduction

   This document assumes that the reader has a general knowledge of the
   Java programming language [Java].  For brevity we use the term "Java
   object" in place of "object in the Java programming language"
   throughout this text.

   Traditionally, LDAP directories have been used to store data. Users
   and programmers think of the directory as a hierarchy of directory
   entries, each containing a set of attributes.  You look up an entry
   from the directory and extract the attribute(s) of interest.  For
   example, you can look up a person's telephone number from the
   directory.  Alternatively, you can search the directory for entries
   with a particular set of attributes.  For example, you can search for
   all persons in the directory with the surname "Smith".

   For applications written in the Java programming language, a kind of
   data that is typically shared are Java objects themselves.  For such
   applications, it makes sense to be able to use the directory as a
   repository for Java objects.  The directory provides a centrally
   administered, and possibly replicated, service for use by Java
   applications distributed across the network.



Ryan, et al.                 Informational                      [Page 1]

RFC 2713                Schema for Java Objects             October 1999


   For example, an application server might use the directory for
   "registering" objects representing the services that it manages, so
   that a client can later search the directory to locate those services
   as it needs.

   The motivation for this document is to define a common way for
   applications to store and retrieve Java objects from the directory.
   Using this common schema, any Java application that needs to read or
   store Java objects in the directory can do so in an interoperable
   way.

2 Representation of Java Objects

   This document defines schema elements to represent three types of
   Java objects:  a Java serialized object, a Java marshalled object,
   and a JNDI reference. A Java remote object is stored as either a Java
   marshalled object or a JNDI reference.

2.1 Common Representations

   A Java object is stored in the LDAP directory by using the object
   class javaObject. This is the base class from which other Java object
   related classes derive: javaSerializedObject, javaMarshalledObject,
   and javaNamingReference.  javaObject is an abstract object class,
   which means that a javaObject cannot exist by itself in the
   directory; only auxiliary or structural subclasses of it can exist in
   the directory.

   The object class javaContainer represents a directory entry dedicated
   to storing a Java object. It is a structural object class.  In cases
   where a subclass of javaObject is mixed in with another structural
   object class, javaContainer is not required.

   The definitions for the object classes javaObject and javaContainer
   are presented in Section 4.

   The javaObject class has one mandatory attribute (javaClassName) and
   four optional attributes (javaClassNames, javaCodebase, javaDoc,
   description).  javaClassName is a single valued attribute that is
   used to store the fully qualified name of the object's Java class
   (for example, "java.lang.String").  This may be the object's most
   derived class's name, but does not have to be; that of a superclass
   or interface in some cases might be most appropriate.  This attribute
   is intended for storing the name of the object's "distinguished"
   class, that is, the class or interface with which the object should
   be identified.





Ryan, et al.                 Informational                      [Page 2]

RFC 2713                Schema for Java Objects             October 1999


   javaClassNames is a multivalued attribute that is used to store the
   fully qualified names of the object's Java classes and interfaces
   (for example, "java.lang.Byte"). Like all multivalued attributes, the
   javaClassNames attribute's values are unordered and so no one value
   is more "distinguished" than the others. This attribute is intended
   for storing an object's class and interface names and those of its
   ancestor classes and interfaces, although the list of values does not
   have to be complete.  If the javaClassNames attribute is present, it
   should include the value of javaClassName.

   For example, suppose an object is stored in the directory with a
   javaClassName attribute of "java.io.FilePermission", and a
   javaClassNames attribute of {"java.security.Permission",
   "java.io.FilePermission", "java.security.Guard",
   "java.io.Serializable"}. An application searching a directory for
   Java objects might use javaClassName to produce a summary of the
   names and types of Java objects in that directory.  Another
   application might use the javaClassNames attribute to find, for
   example, all java.security.Permission objects.

   javaCodebase is a multivalued attribute that is used to store the
   location(s) of the object's class definition.  javaDoc is used to
   store a pointer (URL) to the Java documentation for the class.
   description is used to store a textual description of a Java object
   and is defined in [v3Schema]. The definitions of these attributes are
   presented in Section 3.

2.2 Serialized Objects

   To "serialize" an object means to convert its state into a byte
   stream in such a way that the byte stream can be converted back into
   a copy of the object.  A Java object is "serializable" if its class
   or any of its superclasses implements either the java.io.Serializable
   interface or its subinterface java.io.Externalizable.
   "Deserialization" is the process of converting the serialized form of
   an object back into a copy of the object.  When an object is
   serialized, the entire tree of objects rooted at the object is also
   serialized. When it is deserialized, the tree is reconstructed. For
   example, suppose a serializable Book object contains (a serializable
   field of) an array of Page objects.  When a Book object is
   serialized, so is the array of Page objects.

   The Java platform specifies a default algorithm by which serializable
   objects are serialized. A Java class can also override this default
   serialization with its own algorithm.  [Serial] describes object
   serialization in detail.





Ryan, et al.                 Informational                      [Page 3]

RFC 2713                Schema for Java Objects             October 1999


   When an object is serialized, information that identifies its class
   is recorded in the serialized stream. However, the class's definition
   ("class file") itself is not recorded. It is the responsibility of
   the system that is deserializing the object to determine the
   mechanism to use for locating and loading the associated class
   definitions. For example, the Java application might include in its
   classpath a JAR file containing the class definitions of the
   serialized object, or load the class definitions using information
   from the directory, as explained below.

2.2.1 Representation in the Directory

   A serialized object is represented in the directory by the attributes
   javaClassName, javaClassNames, javaCodebase, and javaSerializedData,
   as defined in Section 3.  The mandatory attribute,
   javaSerializedData, contains the serialized form of the object.
   Although the serialized form already contains the class name, the
   mandatory javaClassName attribute also records the class name of the
   serialized object so that applications can determined class
   information without having to first deserialize the object.  The
   optional javaClassNames attribute is used to record additional class
   information about the serialized object.  The optional javaCodebase
   attribute is used to record the locations of the class definitions
   needed to deserialize the serialized object.

   A directory entry that contains a serialized object is represented by
   the object class javaSerializedObject, which is a subclass of
   javaObject.  javaSerializedObject is an auxiliary object class, which
   means that it needs to be mixed in with a structural object class.
   javaSerializedObject's definition is given in Section 4.

2.3 Marshalled Objects

   To "marshal" an object means to record its state and codebase(s) in
   such a way that when the marshalled object is "unmarshalled," a copy
   of the original object is obtained, possibly by automatically loading
   the class definitions of the object.  You can marshal any object that
   is serializable or remote (that is, implements the java.rmi.Remote
   interface).  Marshalling is like serialization, except marshalling
   also records codebases. Marshalling is different from serialization
   in that marshalling treats remote objects specially. If an object is
   a java.rmi.Remote object, marshalling records the remote object's
   "stub" (see Section 2.5), instead of the remote object itself.  Like
   serialization, when an object is marshalled, the entire tree of
   objects rooted at the object is marshalled. When it is unmarshalled,
   the tree is reconstructed.





Ryan, et al.                 Informational                      [Page 4]

RFC 2713                Schema for Java Objects             October 1999


   A "marshalled" object is the represented by the
   java.rmi.MarshalledObject class. Here's an example of how to create
   MarshalledObjects for serializable and remote objects:

       java.io.Serializable sobj = ...;
       java.rmi.MarshalledObject mobj1 =
           new java.rmi.MarshalledObject(sobj);

       java.rmi.Remote robj = ...;
       java.rmi.MarshalledObject mobj2 =
           new java.rmi.MarshalledObject(robj);

   Then, to retrieve the original objects from the MarshalledObjects, do
   as follows:

       java.io.Serializable sobj = (java.io.Serializable) mobj1.get();
       java.io.Remote rstub = (java.io.Remote) mobj2.get();

   MarshalledObject is available only on the Java 2 Platform, Standard
   Edition, v1.2, and higher releases.

2.3.1 Representation in the Directory

   A marshalled object is represented in the directory by the attributes
   javaClassName, javaClassNames, and javaSerializedData, as defined in
   Section 3.  The mandatory attribute, javaSerializedData, contains the
   serialized form of the marshalled object (that is, the serialized
   form of a MarshalledObject instance).  The mandatory javaClassName
   attribute records the distinguished class name of the object before
   it has been marshalled.  The optional javaClassNames attribute is
   used to record additional class information about the object before
   it has been marshalled.

   A directory entry that contains a marshalled object is represented by
   the object class javaMarshalledObject, which is a subclass of
   javaObject.  javaMarshalledObject is an auxiliary object class, which
   means that it needs to be mixed in with a structural object class.
   javaMarshalledObject's definition is given in Section 4.

   As evident in this description, a javaMarshalledObject differs from a
   javaSerializedObject only in the interpretation of the javaClassName
   and javaClassNames attributes.









Ryan, et al.                 Informational                      [Page 5]

RFC 2713                Schema for Java Objects             October 1999


2.4 JNDI References

   Java Naming and Directory Interface(tm) (JNDI) is a directory access
   API specified in the Java programming language [JNDI].  It provides
   an object-oriented view of the directory, allowing Java objects to be
   added to and retrieved from the directory without requiring the
   client to manage data representation issues.

   JNDI defines the notion of a "reference" for use when an object
   cannot be stored in the directory directly, or when it is
   inappropriate or undesirable to do so.  An object with an associated
   reference is stored in the directory indirectly, by storing its
   reference instead.

2.4.1 Contents of a Reference

   A JNDI reference is a Java object of class javax.naming.Reference.
   It consists of class information about the object being referenced
   and an ordered list of addresses.  An address is a Java object of
   class javax.naming.RefAddr.  Each address contains information on how
   to construct the object.

   A common use for JNDI references is to represent connections to a
   network service such as a database, directory, or file system.  Each
   address may then identify a "communications endpoint" for that
   service, containing information on how to contact the service.
   Multiple addresses may arise for various reasons, such as replication
   or the object offering interfaces over more than one communication
   mechanism.

   A reference also contains information to assist in the creation of an
   instance of the object to which the reference refers.  It contains
   the Java class name of that object, and the class name and location
   of the object factory to be used to create the object.  The
   procedures for creating an object given its reference and the reverse
   are described in [JNDI].

2.4.2 Representation in the Directory

   A JNDI reference is stored in the directory by using the attributes
   javaClassName, javaClassNames, javaCodebase, javaReferenceAddress,
   and javaFactory, defined in Section 3.  These attributes store
   information corresponding to the contents of a reference described
   above.  javaReferenceAddress is a multivalued optional attribute for
   storing reference addresses.  javaFactory is the optional attribute
   for storing the object factory's fully qualified class name.  The
   mandatory javaClassName attribute is used to store the name of the
   distinguished class of the object.  The optional javaClassNames



Ryan, et al.                 Informational                      [Page 6]

RFC 2713                Schema for Java Objects             October 1999


   attribute is used to record additional class and interface names.
   The optional javaCodebase attribute is used to store the locations of
   the object factory's and the object's class definitions.

   A directory entry containing a JNDI reference is represented by the
   object class javaNamingReference, which is a subclass of javaObject.
   javaNamingReference is an auxiliary object class, which means that it
   needs to be mixed in with a structural object class.
   javaNamingReference's definition is given in Section 4.

2.5 Remote Objects

   The Java Remote Method Invocation (RMI) system [RMI] is a mechanism
   that enables an object on one Java virtual machine to invoke methods
   on an object in another Java virtual machine. Any object whose
   methods can be invoked in this way must implement the java.rmi.Remote
   interface.  When such an object is invoked, its arguments are
   marshalled and sent from the local virtual machine to the remote one,
   where the arguments are unmarshalled and used.  When the method
   terminates, the results are marshalled from the remote machine and
   sent to the caller's virtual machine.

   To make a remote object accessible to other virtual machines, a
   program typically registers it with the RMI registry.  The program
   supplies to the RMI registry the string name of the remote object and
   the remote object itself.  When a program wants to access a remote
   object, it supplies the object's string name to the RMI registry on
   the same machine as the remote object.  The RMI registry returns to
   the caller a reference (called "stub") to the remote object.  When
   the program receives the stub for the remote object, it can invoke
   methods on the remote object (through the stub).  A program can also
   obtain references to remote objects as a result of remote calls to
   other remote objects or from other naming services.  For example, the
   program can look up a reference to a remote object from an LDAP
   server that supports the schema defined in this document.

   The string name accepted by the RMI registry has the syntax
   "rmi://hostname:port/remoteObjectName", where "hostname" and "port"
   identify the machine and port on which the RMI registry is running,
   respectively, and "remoteObjectName" is the string name of the remote
   object.  "hostname", "port", and the prefix, "rmi:", are optional. If
   "hostname" is not specified, it defaults to the local host.  If
   "port" is not specified, it defaults to 1099.  If "remoteObjectName"
   is not specified, then the object being named is the RMI registry
   itself.  See [RMI] for details.






Ryan, et al.                 Informational                      [Page 7]

RFC 2713                Schema for Java Objects             October 1999


   RMI can be supported using different protocols: the Java Remote
   Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP).
   The JRMP is a specialized protocol designed for RMI; the IIOP is the
   standard protocol for communication between CORBA objects [CORBA].
   RMI over IIOP allows Java remote objects to communicate with CORBA
   objects which might be written in a non-Java programming language
   [RMI-IIOP].

2.5.1 Representation in the Directory

   Remote objects that use the IIOP are represented in the directory as
   CORBA object references [CORBA-LDAP].  Remote objects that use the
   JRMP are represented in the directory in one of two ways: as a
   marshalled object, or as a JNDI reference.

   A marshalled object records the codebases of the remote object's stub
   and any serializable or remote objects that it references, and
   replaces remote objects with their stubs.  To store a Remote object
   as a marshalled object (java.rmi.MarshalledObject), you first create
   a java.rmi.MarshalledObject instance for it.

       java.rmi.Remote robj = ...;
       java.rmi.MarshalledObject mobj =
           new java.rmi.MarshalledObject(robj);

   You can then store the MarshalledObject instance as a
   javaMarshalledObject.  The javaClassName attribute should contain the
   fully qualified name of the distinguished class of the remote object.
   The javaClassNames attribute should contain the names of the classes
   and interfaces of the remote object.  To read the remote object back
   from the directory, first deserialize the contents of the
   javaSerializedData to get a MarshalledObject (mobj), then retrieve it
   from the MarshalledObject as follows:

       java.rmi.Remote robj = (java.rmi.Remote)mobj.get();

   This returns the remote stub, which you can then use to invoke remote
   methods.

   MarshalledObject is available only on the Java 2 Platform, Standard
   Edition, v1.2 and higher releases. Therefore, a remote object stored
   as a MarshalledObject can only be read by clients using the the Java
   2 Platform, Standard Edition, v1.2 or higher releases.








Ryan, et al.                 Informational                      [Page 8]

RFC 2713                Schema for Java Objects             October 1999


   To store a remote object as a JNDI reference, you first create a
   javax.naming.Reference object instance for it using the remote
   object's string name as it has been, or will be, recorded with the
   RMI registry, with the additional restriction that the "rmi:" prefix
   must be present. Here's an example:

       javax.naming.Reference ref = new javax.naming.Reference(
         obj.getClass().getName(),
         new javax.naming.StringRefAddr("URL",
             "rmi://rserver/AppRemoteObjectX"));

   You then store the javax.naming.Reference instance as a
   javaNamingReference.  The advantage of using a JNDI reference is that
   this can be done without a reference to the remote object. In fact,
   the remote object does not have to exist at the time that this
   recording in the directory is made.  The remote object needs to exist
   and be bound with the RMI registry when the object is looked up from
   the directory.

2.6  Serialized Objects Vs. Marshalled Objects Vs. References

   The object classes defined in this document store different aspects
   of the Java objects.

   A javaSerializedObject or a serializable object stored as a
   javaMarshalledObject represents the object itself, while a
   javaNamingReference or a remote object stored as a
   javaMarshalledObject represents a "pointer" to the object.

   When storing a serializable object in the directory, you have a
   choice of storing it as a javaSerializedObject or a
   javaMarshalledObject.  The javaSerializedObject object class provides
   the basic way in which to store serializable objects. When you create
   an LDAP entry using the javaSerializableObject object class, you must
   explicitly set the javaCodebase attribute if you want readers of that
   entry to know where to load the class definitions of the object. When
   you create an LDAP entry using the javaMarshalledObject object class,
   you use the MarshalledObject class.  The MarshalledObject class uses
   the RMI infrastructure available on the Java platform to automate how
   codebase information is gathered and recorded, thus freeing you from
   having to set the javaCodebase attribute. On the other hand, the
   javaCodebase attribute is human-readable and can be updated easily by
   using text-based tools without having to change other parts of the
   entry.  This allows you, for instance, to move the class definitions
   to another location and then update the javaCodebase attribute to
   reflect the move without having to update the serialized object
   itself.




Ryan, et al.                 Informational                      [Page 9]

RFC 2713                Schema for Java Objects             October 1999


   A javaNamingReference provides a way of recording address information
   about an object which itself is not directly stored in the directory.
   A remote object stored as a javaMarshalledObject also records address
   information (the object's "stub") of an object which itself is not
   directory stored in the directory.  In other words, you can think of
   these as compact representations of the information required to
   access the object.

   A javaNamingReference typically consists of a small number of human-
   readable strings.  Standard text-based tools for directory
   administration may therefore be used to add, read, or modify
   reference entries -- if so desired -- quite easily.  Serialized and
   marshalled objects are not intended to be read or manipulated
   directly by humans.

3 Attribute Type Definitions

   The following attribute types are defined in this document:

       javaClassName
       javaClassNames
       javaCodebase
       javaSerializedData
       javaFactory
       javaReferenceAddress
       javaDoc

3.1 javaClassName

   This attribute stores the fully qualified name of the Java object's
   "distinguished" class or interface (for example, "java.lang.String").
   It is a single-valued attribute. This attribute's syntax is '
   Directory String' and its case is significant.

       ( 1.3.6.1.4.1.42.2.27.4.1.6
         NAME 'javaClassName'
         DESC 'Fully qualified name of distinguished Java class or
               interface'
         EQUALITY caseExactMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
         SINGLE-VALUE
       )









Ryan, et al.                 Informational                     [Page 10]

RFC 2713                Schema for Java Objects             October 1999


3.2 javaCodebase

   This attribute stores the Java class definition's locations.  It
   specifies the locations from which to load the class definition for
   the class specified by the javaClassName attribute.  Each value of
   the attribute contains an ordered list of URLs, separated by spaces.
   For example, a value of "url1 url2 url3" means that the three
   (possibly interdependent) URLs (url1, url2, and url3) form the
   codebase for loading in the Java class definition.

   If the javaCodebase attribute contains more than one value, each
   value is an independent codebase. That is, there is no relationship
   between the URLs in one value and those in another; each value can be
   viewed as an alternate source for loading the Java class definition.
   See [Java] for information regarding class loading.

   This attribute's syntax is 'IA5 String' and its case is significant.

       ( 1.3.6.1.4.1.42.2.27.4.1.7
         NAME 'javaCodebase'
         DESC 'URL(s) specifying the location of class definition'
         EQUALITY caseExactIA5Match
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
       )

3.3 javaClassNames

   This attribute stores the Java object's fully qualified class or
   interface names (for example, "java.lang.String").  It is a
   multivalued attribute. When more than one value is present, each is
   the name of a class or interface, or ancestor class or interface, of
   this object.

   This attribute's syntax is 'Directory String' and its case is
   significant.

       ( 1.3.6.1.4.1.42.2.27.4.1.13
         NAME 'javaClassNames'
         DESC 'Fully qualified Java class or interface name'
         EQUALITY caseExactMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
       )









Ryan, et al.                 Informational                     [Page 11]

RFC 2713                Schema for Java Objects             October 1999


3.4 javaSerializedData

   This attribute stores the serialized form of a Java object.  The
   serialized form is described in [Serial].

   This attribute's syntax is 'Octet String'.

       ( 1.3.6.1.4.1.42.2.27.4.1.8
         NAME 'javaSerializedData
         DESC 'Serialized form of a Java object'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
         SINGLE-VALUE
       )

3.5 javaFactory

   This attribute stores the fully qualified class name of the object
   factory (for example, "com.wiz.jndi.WizObjectFactory") that can be
   used to create an instance of the object identified by the
   javaClassName attribute.

   This attribute's syntax is 'Directory String' and its case is
   significant.

       ( 1.3.6.1.4.1.42.2.27.4.1.10
         NAME 'javaFactory'
         DESC 'Fully qualified Java class name of a JNDI object factory'
         EQUALITY caseExactMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
         SINGLE-VALUE
       )

3.6 javaReferenceAddress

   This attribute represents the sequence of addresses of a JNDI
   reference.  Each of its values represents one address, a Java object
   of type javax.naming.RefAddr.  Its value is a concatenation of the
   address type and address contents, preceded by a sequence number (the
   order of addresses in a JNDI reference is significant).  For example:

       #0#TypeA#ValA
       #1#TypeB#ValB
       #2#TypeC##rO0ABXNyABpq...

   In more detail, the value is encoded as follows:






Ryan, et al.                 Informational                     [Page 12]

RFC 2713                Schema for Java Objects             October 1999


   The delimiter is the first character of the value.  For readability
   the character '#' is recommended when it is not otherwise used
   anywhere in the value, but any character may be used subject to
   restrictions given below.

   The first delimiter is followed by the sequence number.  The sequence
   number of an address is its position in the JNDI reference, with the
   first address being numbered 0.  It is represented by its shortest
   string form, in decimal notation.

   The sequence number is followed by a delimiter, then by the address
   type, and then by another delimiter.  If the address is of Java class
   javax.naming.StringRefAddr, then this delimiter is followed by the
   value of the address contents (which is a string).  Otherwise, this
   delimiter is followed immediately by another delimiter, and then by
   the Base64 encoding of the serialized form of the entire address.

   The delimiter may be any character other than a digit or a character
   contained in the address type.  In addition, if the address contents
   is a string, the delimiter may not be the first character of that
   string.

   This attribute's syntax is 'Directory String' and its case is
   significant.  It can contain multiple values.

       ( 1.3.6.1.4.1.42.2.27.4.1.11
         NAME 'javaReferenceAddress'
         DESC 'Addresses associated with a JNDI Reference'
         EQUALITY caseExactMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
       )

3.7 javaDoc

   This attribute stores a pointer to the Java documentation for the
   class.  It's value is a URL. For example, the following URL points to
   the specification of the java.lang.String class:
   http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html

   This attribute's syntax is 'IA5 String' and its case is significant.

       ( 1.3.6.1.4.1.42.2.27.4.1.12
         NAME 'javaDoc'
         DESC 'The Java documentation for the class'
         EQUALITY caseExactIA5Match
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
       )




Ryan, et al.                 Informational                     [Page 13]

RFC 2713                Schema for Java Objects             October 1999


4 Object Class Definitions

   The following object classes are defined in this document:

       javaContainer
       javaObject
       javaSerializedObject
       javaMarshalledObject
       javaNamingReference

4.1 javaContainer

   This structural object class represents a container for a Java
   object.

       ( 1.3.6.1.4.1.42.2.27.4.2.1
         NAME 'javaContainer'
         DESC 'Container for a Java object'
         SUP top
         STRUCTURAL
         MUST ( cn )
       )

4.2 javaObject

   This abstract object class represents a Java object.  A javaObject
   cannot exist in the directory; only auxiliary or structural
   subclasses of it can exist in the directory.

       ( 1.3.6.1.4.1.42.2.27.4.2.4
         NAME 'javaObject'
         DESC 'Java object representation'
         SUP top
         ABSTRACT
         MUST ( javaClassName )
         MAY ( javaClassNames $
               javaCodebase $
               javaDoc $
               description )
       )











Ryan, et al.                 Informational                     [Page 14]

RFC 2713                Schema for Java Objects             October 1999


4.3 javaSerializedObject

   This auxiliary object class represents a Java serialized object.  It
   must be mixed in with a structural object class.

       ( 1.3.6.1.4.1.42.2.27.4.2.5
         NAME 'javaSerializedObject'
         DESC 'Java serialized object'
         SUP javaObject
         AUXILIARY
         MUST ( javaSerializedData )
       )

4.4 javaMarshalledObject

   This auxiliary object class represents a Java marshalled object.  It
   must be mixed in with a structural object class.

       ( 1.3.6.1.4.1.42.2.27.4.2.8
         NAME 'javaMarshalledObject'
         DESC 'Java marshalled object'
         SUP javaObject
         AUXILIARY
         MUST ( javaSerializedData )
       )

4.5 javaNamingReference

   This auxiliary object class represents a JNDI reference.  It must be
   mixed in with a structural object class.

       ( 1.3.6.1.4.1.42.2.27.4.2.7
         NAME 'javaNamingReference'
         DESC 'JNDI reference'
         SUP javaObject
         AUXILIARY
         MAY ( javaReferenceAddress $
               javaFactory )
       )












Ryan, et al.                 Informational                     [Page 15]

RFC 2713                Schema for Java Objects             October 1999


5. Security Considerations

   Serializing an object and storing it into the directory enables (a
   copy of) the object to be examined and used outside the environment
   in which it was originally created.  The directory entry containing
   the serialized object could be read and modified within the
   constraints imposed by the access control mechanisms of the
   directory.  If an object contains sensitive information or
   information that could be misused outside of the context in which it
   was created, the object should not be stored in the directory.  For
   more details on security issues relating to serialization in general,
   see [Serial].

6. Acknowledgements

   We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob
   Scheifler, and Ann Wollrath of Sun Microsystems for their comments
   and suggestions.

7. References

   [CORBA]      The Object Management Group, "Common Object Request
                Broker Architecture Specification 2.0,"
                http://www.omg.org

   [CORBA-LDAP] Ryan, V., Lee, R. and S. Seligman, "Schema for
                Representing CORBA Object References in an LDAP
                Directory", RFC 2714, October 1999.

   [Java]       Ken Arnold and James Gosling, "The Java(tm) Programming
                Language," Second Edition, ISBN 0-201-31006-6.

   [JNDI]       Java Software, Sun Microsystems, Inc., "The Java(tm)
                Naming and Directory Interface (tm) Specification,"
                February 1998.  http://java.sun.com/products/jndi/

   [LDAPv3]     Wahl, M., Howes, T. and  S. Kille, "Lightweight
                Directory Access Protocol (v3)", RFC 2251, December
                1997.

   [RMI]        Java Software, Sun Microsystems, Inc., "Remote Method
                Invocation," November 1998.
                http://java.sun.com/products/jdk/1.2/docs/guide/rmi








Ryan, et al.                 Informational                     [Page 16]

RFC 2713                Schema for Java Objects             October 1999


   [RMI-IIOP]   IBM and Java Software, Sun Microsystems, Inc., "RMI over
                IIOP", June 1999.
                http://java.sun.com/products/rmi-iiop/

   [Serial]     Java Software, Sun Microsystems, Inc., "Object
                Serialization Specification," November 1998.
                http://java.sun.com/products/jdk/1.2/docs/guide/
                serialization

   [v3Schema]   Wahl, M., "A Summary of the X.500(96) User Schema for
                use with LDAPv3", RFC 2256, December 1997.

8. Authors' Addresses

   Vincent Ryan
   Sun Microsystems, Inc.
   Mail Stop EDUB03
   901 San Antonio Road
   Palo Alto, CA 94303
   USA

   Phone: +353 1 819 9151
   EMail: vincent.ryan@ireland.sun.com


   Scott Seligman
   Sun Microsystems, Inc.
   Mail Stop UCUP02-209
   901 San Antonio Road
   Palo Alto, CA 94303
   USA

   Phone: +1 408 863 3222
   EMail: scott.seligman@eng.sun.com


   Rosanna Lee
   Sun Microsystems, Inc.
   Mail Stop UCUP02-206
   901 San Antonio Road
   Palo Alto, CA 94303
   USA

   Phone: +1 408 863 3221
   EMail: rosanna.lee@eng.sun.com






Ryan, et al.                 Informational                     [Page 17]

RFC 2713                Schema for Java Objects             October 1999


Appendix - LDAP Schema

  -- Attribute types --

  ( 1.3.6.1.4.1.42.2.27.4.1.6
    NAME 'javaClassName'
    DESC 'Fully qualified name of distinguished Java class or interface'
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE
  )

  ( 1.3.6.1.4.1.42.2.27.4.1.7
    NAME 'javaCodebase'
    DESC 'URL(s) specifying the location of class definition'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  )

  ( 1.3.6.1.4.1.42.2.27.4.1.8
    NAME 'javaSerializedData'
    DESC 'Serialized form of a Java object'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    SINGLE-VALUE
  )

  ( 1.3.6.1.4.1.42.2.27.4.1.10
    NAME 'javaFactory'
    DESC 'Fully qualified Java class name of a JNDI object factory'
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE
  )

  ( 1.3.6.1.4.1.42.2.27.4.1.11
    NAME 'javaReferenceAddress'
    DESC 'Addresses associated with a JNDI Reference'
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  )

  ( 1.3.6.1.4.1.42.2.27.4.1.12
    NAME 'javaDoc'
    DESC 'The Java documentation for the class'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  )




Ryan, et al.                 Informational                     [Page 18]

RFC 2713                Schema for Java Objects             October 1999


  ( 1.3.6.1.4.1.42.2.27.4.1.13
    NAME 'javaClassNames'
    DESC 'Fully qualified Java class or interface name'
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  )

  -- from RFC-2256 --

  ( 2.5.4.13
    NAME 'description'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
  )

  -- Object classes --

  ( 1.3.6.1.4.1.42.2.27.4.2.1
    NAME 'javaContainer'
    DESC 'Container for a Java object'
    SUP top
    STRUCTURAL
    MUST ( cn )
  )

  ( 1.3.6.1.4.1.42.2.27.4.2.4
    NAME 'javaObject'
    DESC 'Java object representation'
    SUP top
    ABSTRACT
    MUST ( javaClassName )
    MAY ( javaClassNames $ javaCodebase $ javaDoc $ description )
  )

  ( 1.3.6.1.4.1.42.2.27.4.2.5
    NAME 'javaSerializedObject'
    DESC 'Java serialized object'
    SUP javaObject
    AUXILIARY
    MUST ( javaSerializedData )
  )









Ryan, et al.                 Informational                     [Page 19]

RFC 2713                Schema for Java Objects             October 1999


  ( 1.3.6.1.4.1.42.2.27.4.2.7
    NAME 'javaNamingReference'
    DESC 'JNDI reference'
    SUP javaObject
    AUXILIARY
    MAY ( javaReferenceAddress $ javaFactory )
  )

  ( 1.3.6.1.4.1.42.2.27.4.2.8
    NAME 'javaMarshalledObject'
    DESC 'Java marshalled object'
    SUP javaObject
    AUXILIARY
    MUST ( javaSerializedData )
  )

  -- Matching rule from ISO X.520 --

  ( 2.5.13.5
    NAME 'caseExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  )





























Ryan, et al.                 Informational                     [Page 20]

RFC 2713                Schema for Java Objects             October 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ryan, et al.                 Informational                     [Page 21]