]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2713.txt
Sync with HEAD
[openldap] / doc / rfc / rfc2713.txt
1
2
3
4
5
6
7 Network Working Group                                            V. Ryan
8 Request for Comments: 2713                                   S. Seligman
9 Category: Informational                                           R. Lee
10                                                   Sun Microsystems, Inc.
11                                                             October 1999
12
13
14      Schema for Representing Java(tm) Objects in an LDAP Directory
15
16 Status of this Memo
17
18    This memo provides information for the Internet community.  It does
19    not specify an Internet standard of any kind.  Distribution of this
20    memo is unlimited.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (1999).  All Rights Reserved.
25
26 Abstract
27
28    This document defines the schema for representing Java(tm) objects in
29    an LDAP directory [LDAPv3].  It defines schema elements to represent
30    a Java serialized object [Serial], a Java marshalled object [RMI], a
31    Java remote object [RMI], and a JNDI reference [JNDI].
32
33 1. Introduction
34
35    This document assumes that the reader has a general knowledge of the
36    Java programming language [Java].  For brevity we use the term "Java
37    object" in place of "object in the Java programming language"
38    throughout this text.
39
40    Traditionally, LDAP directories have been used to store data. Users
41    and programmers think of the directory as a hierarchy of directory
42    entries, each containing a set of attributes.  You look up an entry
43    from the directory and extract the attribute(s) of interest.  For
44    example, you can look up a person's telephone number from the
45    directory.  Alternatively, you can search the directory for entries
46    with a particular set of attributes.  For example, you can search for
47    all persons in the directory with the surname "Smith".
48
49    For applications written in the Java programming language, a kind of
50    data that is typically shared are Java objects themselves.  For such
51    applications, it makes sense to be able to use the directory as a
52    repository for Java objects.  The directory provides a centrally
53    administered, and possibly replicated, service for use by Java
54    applications distributed across the network.
55
56
57
58 Ryan, et al.                 Informational                      [Page 1]
59 \f
60 RFC 2713                Schema for Java Objects             October 1999
61
62
63    For example, an application server might use the directory for
64    "registering" objects representing the services that it manages, so
65    that a client can later search the directory to locate those services
66    as it needs.
67
68    The motivation for this document is to define a common way for
69    applications to store and retrieve Java objects from the directory.
70    Using this common schema, any Java application that needs to read or
71    store Java objects in the directory can do so in an interoperable
72    way.
73
74 2 Representation of Java Objects
75
76    This document defines schema elements to represent three types of
77    Java objects:  a Java serialized object, a Java marshalled object,
78    and a JNDI reference. A Java remote object is stored as either a Java
79    marshalled object or a JNDI reference.
80
81 2.1 Common Representations
82
83    A Java object is stored in the LDAP directory by using the object
84    class javaObject. This is the base class from which other Java object
85    related classes derive: javaSerializedObject, javaMarshalledObject,
86    and javaNamingReference.  javaObject is an abstract object class,
87    which means that a javaObject cannot exist by itself in the
88    directory; only auxiliary or structural subclasses of it can exist in
89    the directory.
90
91    The object class javaContainer represents a directory entry dedicated
92    to storing a Java object. It is a structural object class.  In cases
93    where a subclass of javaObject is mixed in with another structural
94    object class, javaContainer is not required.
95
96    The definitions for the object classes javaObject and javaContainer
97    are presented in Section 4.
98
99    The javaObject class has one mandatory attribute (javaClassName) and
100    four optional attributes (javaClassNames, javaCodebase, javaDoc,
101    description).  javaClassName is a single valued attribute that is
102    used to store the fully qualified name of the object's Java class
103    (for example, "java.lang.String").  This may be the object's most
104    derived class's name, but does not have to be; that of a superclass
105    or interface in some cases might be most appropriate.  This attribute
106    is intended for storing the name of the object's "distinguished"
107    class, that is, the class or interface with which the object should
108    be identified.
109
110
111
112
113
114 Ryan, et al.                 Informational                      [Page 2]
115 \f
116 RFC 2713                Schema for Java Objects             October 1999
117
118
119    javaClassNames is a multivalued attribute that is used to store the
120    fully qualified names of the object's Java classes and interfaces
121    (for example, "java.lang.Byte"). Like all multivalued attributes, the
122    javaClassNames attribute's values are unordered and so no one value
123    is more "distinguished" than the others. This attribute is intended
124    for storing an object's class and interface names and those of its
125    ancestor classes and interfaces, although the list of values does not
126    have to be complete.  If the javaClassNames attribute is present, it
127    should include the value of javaClassName.
128
129    For example, suppose an object is stored in the directory with a
130    javaClassName attribute of "java.io.FilePermission", and a
131    javaClassNames attribute of {"java.security.Permission",
132    "java.io.FilePermission", "java.security.Guard",
133    "java.io.Serializable"}. An application searching a directory for
134    Java objects might use javaClassName to produce a summary of the
135    names and types of Java objects in that directory.  Another
136    application might use the javaClassNames attribute to find, for
137    example, all java.security.Permission objects.
138
139    javaCodebase is a multivalued attribute that is used to store the
140    location(s) of the object's class definition.  javaDoc is used to
141    store a pointer (URL) to the Java documentation for the class.
142    description is used to store a textual description of a Java object
143    and is defined in [v3Schema]. The definitions of these attributes are
144    presented in Section 3.
145
146 2.2 Serialized Objects
147
148    To "serialize" an object means to convert its state into a byte
149    stream in such a way that the byte stream can be converted back into
150    a copy of the object.  A Java object is "serializable" if its class
151    or any of its superclasses implements either the java.io.Serializable
152    interface or its subinterface java.io.Externalizable.
153    "Deserialization" is the process of converting the serialized form of
154    an object back into a copy of the object.  When an object is
155    serialized, the entire tree of objects rooted at the object is also
156    serialized. When it is deserialized, the tree is reconstructed. For
157    example, suppose a serializable Book object contains (a serializable
158    field of) an array of Page objects.  When a Book object is
159    serialized, so is the array of Page objects.
160
161    The Java platform specifies a default algorithm by which serializable
162    objects are serialized. A Java class can also override this default
163    serialization with its own algorithm.  [Serial] describes object
164    serialization in detail.
165
166
167
168
169
170 Ryan, et al.                 Informational                      [Page 3]
171 \f
172 RFC 2713                Schema for Java Objects             October 1999
173
174
175    When an object is serialized, information that identifies its class
176    is recorded in the serialized stream. However, the class's definition
177    ("class file") itself is not recorded. It is the responsibility of
178    the system that is deserializing the object to determine the
179    mechanism to use for locating and loading the associated class
180    definitions. For example, the Java application might include in its
181    classpath a JAR file containing the class definitions of the
182    serialized object, or load the class definitions using information
183    from the directory, as explained below.
184
185 2.2.1 Representation in the Directory
186
187    A serialized object is represented in the directory by the attributes
188    javaClassName, javaClassNames, javaCodebase, and javaSerializedData,
189    as defined in Section 3.  The mandatory attribute,
190    javaSerializedData, contains the serialized form of the object.
191    Although the serialized form already contains the class name, the
192    mandatory javaClassName attribute also records the class name of the
193    serialized object so that applications can determined class
194    information without having to first deserialize the object.  The
195    optional javaClassNames attribute is used to record additional class
196    information about the serialized object.  The optional javaCodebase
197    attribute is used to record the locations of the class definitions
198    needed to deserialize the serialized object.
199
200    A directory entry that contains a serialized object is represented by
201    the object class javaSerializedObject, which is a subclass of
202    javaObject.  javaSerializedObject is an auxiliary object class, which
203    means that it needs to be mixed in with a structural object class.
204    javaSerializedObject's definition is given in Section 4.
205
206 2.3 Marshalled Objects
207
208    To "marshal" an object means to record its state and codebase(s) in
209    such a way that when the marshalled object is "unmarshalled," a copy
210    of the original object is obtained, possibly by automatically loading
211    the class definitions of the object.  You can marshal any object that
212    is serializable or remote (that is, implements the java.rmi.Remote
213    interface).  Marshalling is like serialization, except marshalling
214    also records codebases. Marshalling is different from serialization
215    in that marshalling treats remote objects specially. If an object is
216    a java.rmi.Remote object, marshalling records the remote object's
217    "stub" (see Section 2.5), instead of the remote object itself.  Like
218    serialization, when an object is marshalled, the entire tree of
219    objects rooted at the object is marshalled. When it is unmarshalled,
220    the tree is reconstructed.
221
222
223
224
225
226 Ryan, et al.                 Informational                      [Page 4]
227 \f
228 RFC 2713                Schema for Java Objects             October 1999
229
230
231    A "marshalled" object is the represented by the
232    java.rmi.MarshalledObject class. Here's an example of how to create
233    MarshalledObjects for serializable and remote objects:
234
235        java.io.Serializable sobj = ...;
236        java.rmi.MarshalledObject mobj1 =
237            new java.rmi.MarshalledObject(sobj);
238
239        java.rmi.Remote robj = ...;
240        java.rmi.MarshalledObject mobj2 =
241            new java.rmi.MarshalledObject(robj);
242
243    Then, to retrieve the original objects from the MarshalledObjects, do
244    as follows:
245
246        java.io.Serializable sobj = (java.io.Serializable) mobj1.get();
247        java.io.Remote rstub = (java.io.Remote) mobj2.get();
248
249    MarshalledObject is available only on the Java 2 Platform, Standard
250    Edition, v1.2, and higher releases.
251
252 2.3.1 Representation in the Directory
253
254    A marshalled object is represented in the directory by the attributes
255    javaClassName, javaClassNames, and javaSerializedData, as defined in
256    Section 3.  The mandatory attribute, javaSerializedData, contains the
257    serialized form of the marshalled object (that is, the serialized
258    form of a MarshalledObject instance).  The mandatory javaClassName
259    attribute records the distinguished class name of the object before
260    it has been marshalled.  The optional javaClassNames attribute is
261    used to record additional class information about the object before
262    it has been marshalled.
263
264    A directory entry that contains a marshalled object is represented by
265    the object class javaMarshalledObject, which is a subclass of
266    javaObject.  javaMarshalledObject is an auxiliary object class, which
267    means that it needs to be mixed in with a structural object class.
268    javaMarshalledObject's definition is given in Section 4.
269
270    As evident in this description, a javaMarshalledObject differs from a
271    javaSerializedObject only in the interpretation of the javaClassName
272    and javaClassNames attributes.
273
274
275
276
277
278
279
280
281
282 Ryan, et al.                 Informational                      [Page 5]
283 \f
284 RFC 2713                Schema for Java Objects             October 1999
285
286
287 2.4 JNDI References
288
289    Java Naming and Directory Interface(tm) (JNDI) is a directory access
290    API specified in the Java programming language [JNDI].  It provides
291    an object-oriented view of the directory, allowing Java objects to be
292    added to and retrieved from the directory without requiring the
293    client to manage data representation issues.
294
295    JNDI defines the notion of a "reference" for use when an object
296    cannot be stored in the directory directly, or when it is
297    inappropriate or undesirable to do so.  An object with an associated
298    reference is stored in the directory indirectly, by storing its
299    reference instead.
300
301 2.4.1 Contents of a Reference
302
303    A JNDI reference is a Java object of class javax.naming.Reference.
304    It consists of class information about the object being referenced
305    and an ordered list of addresses.  An address is a Java object of
306    class javax.naming.RefAddr.  Each address contains information on how
307    to construct the object.
308
309    A common use for JNDI references is to represent connections to a
310    network service such as a database, directory, or file system.  Each
311    address may then identify a "communications endpoint" for that
312    service, containing information on how to contact the service.
313    Multiple addresses may arise for various reasons, such as replication
314    or the object offering interfaces over more than one communication
315    mechanism.
316
317    A reference also contains information to assist in the creation of an
318    instance of the object to which the reference refers.  It contains
319    the Java class name of that object, and the class name and location
320    of the object factory to be used to create the object.  The
321    procedures for creating an object given its reference and the reverse
322    are described in [JNDI].
323
324 2.4.2 Representation in the Directory
325
326    A JNDI reference is stored in the directory by using the attributes
327    javaClassName, javaClassNames, javaCodebase, javaReferenceAddress,
328    and javaFactory, defined in Section 3.  These attributes store
329    information corresponding to the contents of a reference described
330    above.  javaReferenceAddress is a multivalued optional attribute for
331    storing reference addresses.  javaFactory is the optional attribute
332    for storing the object factory's fully qualified class name.  The
333    mandatory javaClassName attribute is used to store the name of the
334    distinguished class of the object.  The optional javaClassNames
335
336
337
338 Ryan, et al.                 Informational                      [Page 6]
339 \f
340 RFC 2713                Schema for Java Objects             October 1999
341
342
343    attribute is used to record additional class and interface names.
344    The optional javaCodebase attribute is used to store the locations of
345    the object factory's and the object's class definitions.
346
347    A directory entry containing a JNDI reference is represented by the
348    object class javaNamingReference, which is a subclass of javaObject.
349    javaNamingReference is an auxiliary object class, which means that it
350    needs to be mixed in with a structural object class.
351    javaNamingReference's definition is given in Section 4.
352
353 2.5 Remote Objects
354
355    The Java Remote Method Invocation (RMI) system [RMI] is a mechanism
356    that enables an object on one Java virtual machine to invoke methods
357    on an object in another Java virtual machine. Any object whose
358    methods can be invoked in this way must implement the java.rmi.Remote
359    interface.  When such an object is invoked, its arguments are
360    marshalled and sent from the local virtual machine to the remote one,
361    where the arguments are unmarshalled and used.  When the method
362    terminates, the results are marshalled from the remote machine and
363    sent to the caller's virtual machine.
364
365    To make a remote object accessible to other virtual machines, a
366    program typically registers it with the RMI registry.  The program
367    supplies to the RMI registry the string name of the remote object and
368    the remote object itself.  When a program wants to access a remote
369    object, it supplies the object's string name to the RMI registry on
370    the same machine as the remote object.  The RMI registry returns to
371    the caller a reference (called "stub") to the remote object.  When
372    the program receives the stub for the remote object, it can invoke
373    methods on the remote object (through the stub).  A program can also
374    obtain references to remote objects as a result of remote calls to
375    other remote objects or from other naming services.  For example, the
376    program can look up a reference to a remote object from an LDAP
377    server that supports the schema defined in this document.
378
379    The string name accepted by the RMI registry has the syntax
380    "rmi://hostname:port/remoteObjectName", where "hostname" and "port"
381    identify the machine and port on which the RMI registry is running,
382    respectively, and "remoteObjectName" is the string name of the remote
383    object.  "hostname", "port", and the prefix, "rmi:", are optional. If
384    "hostname" is not specified, it defaults to the local host.  If
385    "port" is not specified, it defaults to 1099.  If "remoteObjectName"
386    is not specified, then the object being named is the RMI registry
387    itself.  See [RMI] for details.
388
389
390
391
392
393
394 Ryan, et al.                 Informational                      [Page 7]
395 \f
396 RFC 2713                Schema for Java Objects             October 1999
397
398
399    RMI can be supported using different protocols: the Java Remote
400    Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP).
401    The JRMP is a specialized protocol designed for RMI; the IIOP is the
402    standard protocol for communication between CORBA objects [CORBA].
403    RMI over IIOP allows Java remote objects to communicate with CORBA
404    objects which might be written in a non-Java programming language
405    [RMI-IIOP].
406
407 2.5.1 Representation in the Directory
408
409    Remote objects that use the IIOP are represented in the directory as
410    CORBA object references [CORBA-LDAP].  Remote objects that use the
411    JRMP are represented in the directory in one of two ways: as a
412    marshalled object, or as a JNDI reference.
413
414    A marshalled object records the codebases of the remote object's stub
415    and any serializable or remote objects that it references, and
416    replaces remote objects with their stubs.  To store a Remote object
417    as a marshalled object (java.rmi.MarshalledObject), you first create
418    a java.rmi.MarshalledObject instance for it.
419
420        java.rmi.Remote robj = ...;
421        java.rmi.MarshalledObject mobj =
422            new java.rmi.MarshalledObject(robj);
423
424    You can then store the MarshalledObject instance as a
425    javaMarshalledObject.  The javaClassName attribute should contain the
426    fully qualified name of the distinguished class of the remote object.
427    The javaClassNames attribute should contain the names of the classes
428    and interfaces of the remote object.  To read the remote object back
429    from the directory, first deserialize the contents of the
430    javaSerializedData to get a MarshalledObject (mobj), then retrieve it
431    from the MarshalledObject as follows:
432
433        java.rmi.Remote robj = (java.rmi.Remote)mobj.get();
434
435    This returns the remote stub, which you can then use to invoke remote
436    methods.
437
438    MarshalledObject is available only on the Java 2 Platform, Standard
439    Edition, v1.2 and higher releases. Therefore, a remote object stored
440    as a MarshalledObject can only be read by clients using the the Java
441    2 Platform, Standard Edition, v1.2 or higher releases.
442
443
444
445
446
447
448
449
450 Ryan, et al.                 Informational                      [Page 8]
451 \f
452 RFC 2713                Schema for Java Objects             October 1999
453
454
455    To store a remote object as a JNDI reference, you first create a
456    javax.naming.Reference object instance for it using the remote
457    object's string name as it has been, or will be, recorded with the
458    RMI registry, with the additional restriction that the "rmi:" prefix
459    must be present. Here's an example:
460
461        javax.naming.Reference ref = new javax.naming.Reference(
462          obj.getClass().getName(),
463          new javax.naming.StringRefAddr("URL",
464              "rmi://rserver/AppRemoteObjectX"));
465
466    You then store the javax.naming.Reference instance as a
467    javaNamingReference.  The advantage of using a JNDI reference is that
468    this can be done without a reference to the remote object. In fact,
469    the remote object does not have to exist at the time that this
470    recording in the directory is made.  The remote object needs to exist
471    and be bound with the RMI registry when the object is looked up from
472    the directory.
473
474 2.6  Serialized Objects Vs. Marshalled Objects Vs. References
475
476    The object classes defined in this document store different aspects
477    of the Java objects.
478
479    A javaSerializedObject or a serializable object stored as a
480    javaMarshalledObject represents the object itself, while a
481    javaNamingReference or a remote object stored as a
482    javaMarshalledObject represents a "pointer" to the object.
483
484    When storing a serializable object in the directory, you have a
485    choice of storing it as a javaSerializedObject or a
486    javaMarshalledObject.  The javaSerializedObject object class provides
487    the basic way in which to store serializable objects. When you create
488    an LDAP entry using the javaSerializableObject object class, you must
489    explicitly set the javaCodebase attribute if you want readers of that
490    entry to know where to load the class definitions of the object. When
491    you create an LDAP entry using the javaMarshalledObject object class,
492    you use the MarshalledObject class.  The MarshalledObject class uses
493    the RMI infrastructure available on the Java platform to automate how
494    codebase information is gathered and recorded, thus freeing you from
495    having to set the javaCodebase attribute. On the other hand, the
496    javaCodebase attribute is human-readable and can be updated easily by
497    using text-based tools without having to change other parts of the
498    entry.  This allows you, for instance, to move the class definitions
499    to another location and then update the javaCodebase attribute to
500    reflect the move without having to update the serialized object
501    itself.
502
503
504
505
506 Ryan, et al.                 Informational                      [Page 9]
507 \f
508 RFC 2713                Schema for Java Objects             October 1999
509
510
511    A javaNamingReference provides a way of recording address information
512    about an object which itself is not directly stored in the directory.
513    A remote object stored as a javaMarshalledObject also records address
514    information (the object's "stub") of an object which itself is not
515    directory stored in the directory.  In other words, you can think of
516    these as compact representations of the information required to
517    access the object.
518
519    A javaNamingReference typically consists of a small number of human-
520    readable strings.  Standard text-based tools for directory
521    administration may therefore be used to add, read, or modify
522    reference entries -- if so desired -- quite easily.  Serialized and
523    marshalled objects are not intended to be read or manipulated
524    directly by humans.
525
526 3 Attribute Type Definitions
527
528    The following attribute types are defined in this document:
529
530        javaClassName
531        javaClassNames
532        javaCodebase
533        javaSerializedData
534        javaFactory
535        javaReferenceAddress
536        javaDoc
537
538 3.1 javaClassName
539
540    This attribute stores the fully qualified name of the Java object's
541    "distinguished" class or interface (for example, "java.lang.String").
542    It is a single-valued attribute. This attribute's syntax is '
543    Directory String' and its case is significant.
544
545        ( 1.3.6.1.4.1.42.2.27.4.1.6
546          NAME 'javaClassName'
547          DESC 'Fully qualified name of distinguished Java class or
548                interface'
549          EQUALITY caseExactMatch
550          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
551          SINGLE-VALUE
552        )
553
554
555
556
557
558
559
560
561
562 Ryan, et al.                 Informational                     [Page 10]
563 \f
564 RFC 2713                Schema for Java Objects             October 1999
565
566
567 3.2 javaCodebase
568
569    This attribute stores the Java class definition's locations.  It
570    specifies the locations from which to load the class definition for
571    the class specified by the javaClassName attribute.  Each value of
572    the attribute contains an ordered list of URLs, separated by spaces.
573    For example, a value of "url1 url2 url3" means that the three
574    (possibly interdependent) URLs (url1, url2, and url3) form the
575    codebase for loading in the Java class definition.
576
577    If the javaCodebase attribute contains more than one value, each
578    value is an independent codebase. That is, there is no relationship
579    between the URLs in one value and those in another; each value can be
580    viewed as an alternate source for loading the Java class definition.
581    See [Java] for information regarding class loading.
582
583    This attribute's syntax is 'IA5 String' and its case is significant.
584
585        ( 1.3.6.1.4.1.42.2.27.4.1.7
586          NAME 'javaCodebase'
587          DESC 'URL(s) specifying the location of class definition'
588          EQUALITY caseExactIA5Match
589          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
590        )
591
592 3.3 javaClassNames
593
594    This attribute stores the Java object's fully qualified class or
595    interface names (for example, "java.lang.String").  It is a
596    multivalued attribute. When more than one value is present, each is
597    the name of a class or interface, or ancestor class or interface, of
598    this object.
599
600    This attribute's syntax is 'Directory String' and its case is
601    significant.
602
603        ( 1.3.6.1.4.1.42.2.27.4.1.13
604          NAME 'javaClassNames'
605          DESC 'Fully qualified Java class or interface name'
606          EQUALITY caseExactMatch
607          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
608        )
609
610
611
612
613
614
615
616
617
618 Ryan, et al.                 Informational                     [Page 11]
619 \f
620 RFC 2713                Schema for Java Objects             October 1999
621
622
623 3.4 javaSerializedData
624
625    This attribute stores the serialized form of a Java object.  The
626    serialized form is described in [Serial].
627
628    This attribute's syntax is 'Octet String'.
629
630        ( 1.3.6.1.4.1.42.2.27.4.1.8
631          NAME 'javaSerializedData
632          DESC 'Serialized form of a Java object'
633          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
634          SINGLE-VALUE
635        )
636
637 3.5 javaFactory
638
639    This attribute stores the fully qualified class name of the object
640    factory (for example, "com.wiz.jndi.WizObjectFactory") that can be
641    used to create an instance of the object identified by the
642    javaClassName attribute.
643
644    This attribute's syntax is 'Directory String' and its case is
645    significant.
646
647        ( 1.3.6.1.4.1.42.2.27.4.1.10
648          NAME 'javaFactory'
649          DESC 'Fully qualified Java class name of a JNDI object factory'
650          EQUALITY caseExactMatch
651          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
652          SINGLE-VALUE
653        )
654
655 3.6 javaReferenceAddress
656
657    This attribute represents the sequence of addresses of a JNDI
658    reference.  Each of its values represents one address, a Java object
659    of type javax.naming.RefAddr.  Its value is a concatenation of the
660    address type and address contents, preceded by a sequence number (the
661    order of addresses in a JNDI reference is significant).  For example:
662
663        #0#TypeA#ValA
664        #1#TypeB#ValB
665        #2#TypeC##rO0ABXNyABpq...
666
667    In more detail, the value is encoded as follows:
668
669
670
671
672
673
674 Ryan, et al.                 Informational                     [Page 12]
675 \f
676 RFC 2713                Schema for Java Objects             October 1999
677
678
679    The delimiter is the first character of the value.  For readability
680    the character '#' is recommended when it is not otherwise used
681    anywhere in the value, but any character may be used subject to
682    restrictions given below.
683
684    The first delimiter is followed by the sequence number.  The sequence
685    number of an address is its position in the JNDI reference, with the
686    first address being numbered 0.  It is represented by its shortest
687    string form, in decimal notation.
688
689    The sequence number is followed by a delimiter, then by the address
690    type, and then by another delimiter.  If the address is of Java class
691    javax.naming.StringRefAddr, then this delimiter is followed by the
692    value of the address contents (which is a string).  Otherwise, this
693    delimiter is followed immediately by another delimiter, and then by
694    the Base64 encoding of the serialized form of the entire address.
695
696    The delimiter may be any character other than a digit or a character
697    contained in the address type.  In addition, if the address contents
698    is a string, the delimiter may not be the first character of that
699    string.
700
701    This attribute's syntax is 'Directory String' and its case is
702    significant.  It can contain multiple values.
703
704        ( 1.3.6.1.4.1.42.2.27.4.1.11
705          NAME 'javaReferenceAddress'
706          DESC 'Addresses associated with a JNDI Reference'
707          EQUALITY caseExactMatch
708          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
709        )
710
711 3.7 javaDoc
712
713    This attribute stores a pointer to the Java documentation for the
714    class.  It's value is a URL. For example, the following URL points to
715    the specification of the java.lang.String class:
716    http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
717
718    This attribute's syntax is 'IA5 String' and its case is significant.
719
720        ( 1.3.6.1.4.1.42.2.27.4.1.12
721          NAME 'javaDoc'
722          DESC 'The Java documentation for the class'
723          EQUALITY caseExactIA5Match
724          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
725        )
726
727
728
729
730 Ryan, et al.                 Informational                     [Page 13]
731 \f
732 RFC 2713                Schema for Java Objects             October 1999
733
734
735 4 Object Class Definitions
736
737    The following object classes are defined in this document:
738
739        javaContainer
740        javaObject
741        javaSerializedObject
742        javaMarshalledObject
743        javaNamingReference
744
745 4.1 javaContainer
746
747    This structural object class represents a container for a Java
748    object.
749
750        ( 1.3.6.1.4.1.42.2.27.4.2.1
751          NAME 'javaContainer'
752          DESC 'Container for a Java object'
753          SUP top
754          STRUCTURAL
755          MUST ( cn )
756        )
757
758 4.2 javaObject
759
760    This abstract object class represents a Java object.  A javaObject
761    cannot exist in the directory; only auxiliary or structural
762    subclasses of it can exist in the directory.
763
764        ( 1.3.6.1.4.1.42.2.27.4.2.4
765          NAME 'javaObject'
766          DESC 'Java object representation'
767          SUP top
768          ABSTRACT
769          MUST ( javaClassName )
770          MAY ( javaClassNames $
771                javaCodebase $
772                javaDoc $
773                description )
774        )
775
776
777
778
779
780
781
782
783
784
785
786 Ryan, et al.                 Informational                     [Page 14]
787 \f
788 RFC 2713                Schema for Java Objects             October 1999
789
790
791 4.3 javaSerializedObject
792
793    This auxiliary object class represents a Java serialized object.  It
794    must be mixed in with a structural object class.
795
796        ( 1.3.6.1.4.1.42.2.27.4.2.5
797          NAME 'javaSerializedObject'
798          DESC 'Java serialized object'
799          SUP javaObject
800          AUXILIARY
801          MUST ( javaSerializedData )
802        )
803
804 4.4 javaMarshalledObject
805
806    This auxiliary object class represents a Java marshalled object.  It
807    must be mixed in with a structural object class.
808
809        ( 1.3.6.1.4.1.42.2.27.4.2.8
810          NAME 'javaMarshalledObject'
811          DESC 'Java marshalled object'
812          SUP javaObject
813          AUXILIARY
814          MUST ( javaSerializedData )
815        )
816
817 4.5 javaNamingReference
818
819    This auxiliary object class represents a JNDI reference.  It must be
820    mixed in with a structural object class.
821
822        ( 1.3.6.1.4.1.42.2.27.4.2.7
823          NAME 'javaNamingReference'
824          DESC 'JNDI reference'
825          SUP javaObject
826          AUXILIARY
827          MAY ( javaReferenceAddress $
828                javaFactory )
829        )
830
831
832
833
834
835
836
837
838
839
840
841
842 Ryan, et al.                 Informational                     [Page 15]
843 \f
844 RFC 2713                Schema for Java Objects             October 1999
845
846
847 5. Security Considerations
848
849    Serializing an object and storing it into the directory enables (a
850    copy of) the object to be examined and used outside the environment
851    in which it was originally created.  The directory entry containing
852    the serialized object could be read and modified within the
853    constraints imposed by the access control mechanisms of the
854    directory.  If an object contains sensitive information or
855    information that could be misused outside of the context in which it
856    was created, the object should not be stored in the directory.  For
857    more details on security issues relating to serialization in general,
858    see [Serial].
859
860 6. Acknowledgements
861
862    We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob
863    Scheifler, and Ann Wollrath of Sun Microsystems for their comments
864    and suggestions.
865
866 7. References
867
868    [CORBA]      The Object Management Group, "Common Object Request
869                 Broker Architecture Specification 2.0,"
870                 http://www.omg.org
871
872    [CORBA-LDAP] Ryan, V., Lee, R. and S. Seligman, "Schema for
873                 Representing CORBA Object References in an LDAP
874                 Directory", RFC 2714, October 1999.
875
876    [Java]       Ken Arnold and James Gosling, "The Java(tm) Programming
877                 Language," Second Edition, ISBN 0-201-31006-6.
878
879    [JNDI]       Java Software, Sun Microsystems, Inc., "The Java(tm)
880                 Naming and Directory Interface (tm) Specification,"
881                 February 1998.  http://java.sun.com/products/jndi/
882
883    [LDAPv3]     Wahl, M., Howes, T. and  S. Kille, "Lightweight
884                 Directory Access Protocol (v3)", RFC 2251, December
885                 1997.
886
887    [RMI]        Java Software, Sun Microsystems, Inc., "Remote Method
888                 Invocation," November 1998.
889                 http://java.sun.com/products/jdk/1.2/docs/guide/rmi
890
891
892
893
894
895
896
897
898 Ryan, et al.                 Informational                     [Page 16]
899 \f
900 RFC 2713                Schema for Java Objects             October 1999
901
902
903    [RMI-IIOP]   IBM and Java Software, Sun Microsystems, Inc., "RMI over
904                 IIOP", June 1999.
905                 http://java.sun.com/products/rmi-iiop/
906
907    [Serial]     Java Software, Sun Microsystems, Inc., "Object
908                 Serialization Specification," November 1998.
909                 http://java.sun.com/products/jdk/1.2/docs/guide/
910                 serialization
911
912    [v3Schema]   Wahl, M., "A Summary of the X.500(96) User Schema for
913                 use with LDAPv3", RFC 2256, December 1997.
914
915 8. Authors' Addresses
916
917    Vincent Ryan
918    Sun Microsystems, Inc.
919    Mail Stop EDUB03
920    901 San Antonio Road
921    Palo Alto, CA 94303
922    USA
923
924    Phone: +353 1 819 9151
925    EMail: vincent.ryan@ireland.sun.com
926
927
928    Scott Seligman
929    Sun Microsystems, Inc.
930    Mail Stop UCUP02-209
931    901 San Antonio Road
932    Palo Alto, CA 94303
933    USA
934
935    Phone: +1 408 863 3222
936    EMail: scott.seligman@eng.sun.com
937
938
939    Rosanna Lee
940    Sun Microsystems, Inc.
941    Mail Stop UCUP02-206
942    901 San Antonio Road
943    Palo Alto, CA 94303
944    USA
945
946    Phone: +1 408 863 3221
947    EMail: rosanna.lee@eng.sun.com
948
949
950
951
952
953
954 Ryan, et al.                 Informational                     [Page 17]
955 \f
956 RFC 2713                Schema for Java Objects             October 1999
957
958
959 Appendix - LDAP Schema
960
961   -- Attribute types --
962
963   ( 1.3.6.1.4.1.42.2.27.4.1.6
964     NAME 'javaClassName'
965     DESC 'Fully qualified name of distinguished Java class or interface'
966     EQUALITY caseExactMatch
967     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
968     SINGLE-VALUE
969   )
970
971   ( 1.3.6.1.4.1.42.2.27.4.1.7
972     NAME 'javaCodebase'
973     DESC 'URL(s) specifying the location of class definition'
974     EQUALITY caseExactIA5Match
975     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
976   )
977
978   ( 1.3.6.1.4.1.42.2.27.4.1.8
979     NAME 'javaSerializedData'
980     DESC 'Serialized form of a Java object'
981     SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
982     SINGLE-VALUE
983   )
984
985   ( 1.3.6.1.4.1.42.2.27.4.1.10
986     NAME 'javaFactory'
987     DESC 'Fully qualified Java class name of a JNDI object factory'
988     EQUALITY caseExactMatch
989     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
990     SINGLE-VALUE
991   )
992
993   ( 1.3.6.1.4.1.42.2.27.4.1.11
994     NAME 'javaReferenceAddress'
995     DESC 'Addresses associated with a JNDI Reference'
996     EQUALITY caseExactMatch
997     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
998   )
999
1000   ( 1.3.6.1.4.1.42.2.27.4.1.12
1001     NAME 'javaDoc'
1002     DESC 'The Java documentation for the class'
1003     EQUALITY caseExactIA5Match
1004     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
1005   )
1006
1007
1008
1009
1010 Ryan, et al.                 Informational                     [Page 18]
1011 \f
1012 RFC 2713                Schema for Java Objects             October 1999
1013
1014
1015   ( 1.3.6.1.4.1.42.2.27.4.1.13
1016     NAME 'javaClassNames'
1017     DESC 'Fully qualified Java class or interface name'
1018     EQUALITY caseExactMatch
1019     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1020   )
1021
1022   -- from RFC-2256 --
1023
1024   ( 2.5.4.13
1025     NAME 'description'
1026     EQUALITY caseIgnoreMatch
1027     SUBSTR caseIgnoreSubstringsMatch
1028     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
1029   )
1030
1031   -- Object classes --
1032
1033   ( 1.3.6.1.4.1.42.2.27.4.2.1
1034     NAME 'javaContainer'
1035     DESC 'Container for a Java object'
1036     SUP top
1037     STRUCTURAL
1038     MUST ( cn )
1039   )
1040
1041   ( 1.3.6.1.4.1.42.2.27.4.2.4
1042     NAME 'javaObject'
1043     DESC 'Java object representation'
1044     SUP top
1045     ABSTRACT
1046     MUST ( javaClassName )
1047     MAY ( javaClassNames $ javaCodebase $ javaDoc $ description )
1048   )
1049
1050   ( 1.3.6.1.4.1.42.2.27.4.2.5
1051     NAME 'javaSerializedObject'
1052     DESC 'Java serialized object'
1053     SUP javaObject
1054     AUXILIARY
1055     MUST ( javaSerializedData )
1056   )
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Ryan, et al.                 Informational                     [Page 19]
1067 \f
1068 RFC 2713                Schema for Java Objects             October 1999
1069
1070
1071   ( 1.3.6.1.4.1.42.2.27.4.2.7
1072     NAME 'javaNamingReference'
1073     DESC 'JNDI reference'
1074     SUP javaObject
1075     AUXILIARY
1076     MAY ( javaReferenceAddress $ javaFactory )
1077   )
1078
1079   ( 1.3.6.1.4.1.42.2.27.4.2.8
1080     NAME 'javaMarshalledObject'
1081     DESC 'Java marshalled object'
1082     SUP javaObject
1083     AUXILIARY
1084     MUST ( javaSerializedData )
1085   )
1086
1087   -- Matching rule from ISO X.520 --
1088
1089   ( 2.5.13.5
1090     NAME 'caseExactMatch'
1091     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
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 Ryan, et al.                 Informational                     [Page 20]
1123 \f
1124 RFC 2713                Schema for Java Objects             October 1999
1125
1126
1127 Full Copyright Statement
1128
1129    Copyright (C) The Internet Society (1999).  All Rights Reserved.
1130
1131    This document and translations of it may be copied and furnished to
1132    others, and derivative works that comment on or otherwise explain it
1133    or assist in its implementation may be prepared, copied, published
1134    and distributed, in whole or in part, without restriction of any
1135    kind, provided that the above copyright notice and this paragraph are
1136    included on all such copies and derivative works.  However, this
1137    document itself may not be modified in any way, such as by removing
1138    the copyright notice or references to the Internet Society or other
1139    Internet organizations, except as needed for the purpose of
1140    developing Internet standards in which case the procedures for
1141    copyrights defined in the Internet Standards process must be
1142    followed, or as required to translate it into languages other than
1143    English.
1144
1145    The limited permissions granted above are perpetual and will not be
1146    revoked by the Internet Society or its successors or assigns.
1147
1148    This document and the information contained herein is provided on an
1149    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1150    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1151    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1152    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1153    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1154
1155 Acknowledgement
1156
1157    Funding for the RFC Editor function is currently provided by the
1158    Internet Society.
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Ryan, et al.                 Informational                     [Page 21]
1179 \f