RFC 2713

RFC 2713: Schema for Representing Java(tm) Objects in an LDAP Directory 🎀

okay bestie, let's start with the title block because it's giving important facts 💅. This is RFC 2713, written by V. Ryan, S. Seligman, and R. Lee from Sun Microsystems, Inc. It's dated October 1999 and it's Informational 🦋. That means it's a "here's some useful info" doc, not a "you MUST do this" standard. It doesn't obsolete or update any other RFCs, so it's a fresh start 🌸.

The whole vibe is LDAP directories (the big shared phonebook-style databases) meeting Java objects. Think of it as a how-to for storing Java objects in a directory so any Java app can read them back, interoperably ✨.

Status of this Memo

Okay, so this memo just provides information for the internet community 💖. It is NOT an Internet standard of any kind, and distribution is unlimited, so share it with whoever 🫶.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

Abstract

So the main idea 🔥: this doc defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It covers four things: a Java serialized object [Serial], a Java marshalled object [RMI], a Java remote object [RMI], and a JNDI reference [JNDI] 💜.

1. Introduction

First, the assumption: you already know the Java programming language [Java] 💻. To keep things short, we just say "Java object" instead of "object in the Java programming language" throughout ✨.

Quick LDAP refresher, bestie 🧚. Directories are basically a hierarchy of entries, and each entry has a set of attributes 🌸. You look up an entry and grab the attribute you want, like someone's phone number. Or you search for entries that have certain attributes, like everyone with the surname "Smith" 🙈.

Now, Java apps often pass Java objects themselves around as their data 🍓. So it makes sense to use the directory as a place to store those objects. The directory is a centrally run service (and maybe replicated) that distributed Java apps across the network can use 👑.

For example, an application server might "register" the objects that represent its services in the directory, so a client can search and find them later 🦋.

The goal here is a common way for apps to store and fetch Java objects in the directory. With this shared schema, any Java app that wants to read or store Java objects can do it in an interoperable way 💅✨.

2. Representation of Java Objects

So this doc defines schema elements for three types of Java objects 🎀: a Java serialized object, a Java marshalled object, and a JNDI reference. A Java remote object gets stored as either a Java marshalled object or a JNDI reference 🌈.

2.1. Common Representations

Every Java object is stored in the directory using the object class javaObject 🫶. This is the base class for the other Java object classes: javaSerializedObject, javaMarshalledObject, and javaNamingReference ✨. javaObject is abstract, which means it can't exist on its own in the directory. Only auxiliary or structural subclasses of it can show up there 💀.

The object class javaContainer is an entry dedicated to storing a Java object, and it's a structural object class 🧚. When a subclass of javaObject is mixed in with another structural object class, javaContainer is not required 🌸.

The definitions for javaObject and javaContainer are in Section 4 🦋.

The javaObject class has one mandatory attribute (javaClassName) and four optional ones (javaClassNames, javaCodebase, javaDoc, description) 💖. javaClassName is single-valued and stores the fully qualified name of the object's Java class, like "java.lang.String" 🍓. It can be the most derived class's name, but it doesn't have to be. Sometimes a superclass or interface is the better pick 👑. This attribute is meant for the object's "distinguished" class, which is the class or interface the object should be identified with 🔥.

javaClassNames is multivalued and stores the fully qualified names of the object's Java classes and interfaces, like "java.lang.Byte" 🌈. Like all multivalued attributes, its values are unordered, so no single value is more "distinguished" than the others 💅. It's meant for the object's class and interface names plus those of its ancestors, though the list doesn't have to be complete. If javaClassNames is present, it SHOULD include the value of javaClassName.

Here's an example, bestie 🎀. Say an object is stored with a javaClassName of "java.io.FilePermission" and a javaClassNames of:

{"java.security.Permission",
 "java.io.FilePermission", "java.security.Guard",
 "java.io.Serializable"}

An app searching for Java objects could use javaClassName to summarize the names and types of objects in the directory 📊. Another app could search javaClassNames to find, say, every java.security.Permission object 💜.

javaCodebase is multivalued and stores where the object's class definition lives 🦋. javaDoc stores a pointer (a URL) to the Java docs for the class 🌸. description stores a text description of a Java object and is defined in [v3Schema] ✨. These attributes are defined in Section 3 💖.

2.2. Serialized Objects

To "serialize" an object means turning its state into a byte stream, in a way that the stream can later be turned back into a copy of the object 🧜‍♀️. A Java object is "serializable" if its class, or any of its superclasses, implements either java.io.Serializable or its subinterface java.io.Externalizable 🫶. "Deserialization" is the reverse, turning the serialized form back into a copy 🔁. When you serialize an object, the whole tree of objects under it gets serialized too, and deserialization rebuilds the whole tree 🌳. For example, say a serializable Book object has a serializable field holding an array of Page objects. Serializing the Book also serializes that array of Page objects 📖.

The Java platform has a default algorithm for serializing serializable objects 💅. A Java class can override that default with its own algorithm 🎨. [Serial] has all the details on object serialization 📚.

When you serialize an object, the stream records info that identifies its class ✨. But the class definition ("class file") itself is NOT recorded 🙅‍♀️. It's up to the system doing the deserializing to figure out how to find and load the class definitions. For example, the Java app might have a JAR file with the class definitions in its classpath, or it might load the definitions using info from the directory, which we'll get to below 🗂️.

2.2.1. Representation in the Directory

A serialized object is represented in the directory by the attributes javaClassName, javaClassNames, javaCodebase, and javaSerializedData, all defined in Section 3 💜. The mandatory attribute javaSerializedData holds the serialized form of the object 🔥. The serialized form already has the class name, but the mandatory javaClassName attribute ALSO records it, so apps can get class info without deserializing first 🦋. The optional javaClassNames attribute records extra class info about the serialized object 🌸. The optional javaCodebase attribute records where to find the class definitions needed to deserialize it 🧚.

A directory entry holding a serialized object is represented by the object class javaSerializedObject, which is a subclass of javaObject 🌈. It's an auxiliary object class, so it has to be mixed in with a structural object class 🫶. Its definition is in Section 4 ✨.

2.3. Marshalled Objects

To "marshal" an object means recording its state and codebase(s) so that when it gets "unmarshalled," you get a copy of the original object back, possibly by automatically loading its class definitions 🎁. You can marshal anything that's serializable or remote (meaning it implements java.rmi.Remote) 💖. Marshalling is like serialization, except it also records codebases 💅. It's different in one big way: 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 🦋. Just like serialization, the whole tree under the object gets marshalled, and unmarshalling rebuilds it 🌳.

A "marshalled" object is represented by the java.rmi.MarshalledObject class. Here's how to make MarshalledObjects for serializable and remote objects, bestie 🎀:

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);

And to get the originals back out of the MarshalledObjects, do this 🔁:

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

MarshalledObject is only available 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, all defined in Section 3 🌸. The mandatory attribute javaSerializedData holds 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 was marshalled 🦋. The optional javaClassNames attribute records extra class info about the object before marshalling 🧚.

A directory entry holding a marshalled object is represented by the object class javaMarshalledObject, a subclass of javaObject 🌈. It's an auxiliary object class, so it needs to be mixed in with a structural object class 🫶. Its definition is in Section 4 ✨.

As you can see, a javaMarshalledObject differs from a javaSerializedObject only in how it interprets the javaClassName and javaClassNames attributes 💅🔥.

---

Part 1 of 4 is done, bestie 🎀. Part 2 is coming with Section 2.4 and beyond, so stay tuned 💖✨.

2.4 JNDI References ✨

okay bestie, JNDI (the Java Naming and Directory Interface(tm) 💅) is a directory access API specified in the Java programming language [JNDI]. It gives you an object-oriented view of the directory, so Java objects can be added to and pulled back out of it without the client having to wrestle with data representation stuff 🫶.

JNDI has this concept called a "reference" 🦋 for when an object can't be stored in the directory directly, or when it's inappropriate or just undesirable to do so. So an object with a reference gets stored indirectly: you store its reference instead, and the object itself stays out of the way ✨.

2.4.1 Contents of a Reference

A JNDI reference is a Java object of class javax.naming.Reference. It's made up of class information about the object being referenced, plus an ordered list of addresses. Each address is a Java object of class javax.naming.RefAddr, and each one holds info on how to construct the object 💖.

JNDI references are super commonly used to represent connections to a network service, like a database, a directory, or a file system 🌸. Each address can then identify a "communications endpoint" for that service, which holds the info needed to contact it. You might end up with multiple addresses for different reasons, like replication, or because the object offers interfaces over more than one communication mechanism 🧚.

A reference also carries details that help create an instance of the object it points to 👑. It includes the Java class name of that object, plus the class name and location of the object factory that gets used to build it. The procedures for creating an object from its reference (and the reverse) are described in [JNDI], so go check there if you want the full tea ☕.

2.4.2 Representation in the Directory

A JNDI reference gets stored in the directory using the attributes javaClassName, javaClassNames, javaCodebase, javaReferenceAddress, and javaFactory, which are defined in Section 3. Together they store the information that matches the contents of a reference we just talked about 💅.

Here's the breakdown: javaReferenceAddress is a multivalued optional attribute for storing reference addresses, and javaFactory is the optional attribute for storing the object factory's fully qualified class name. The javaClassName attribute is the mandatory one, used to store the name of the distinguished class of the object. javaClassNames is optional and records any extra class and interface names, and javaCodebase is optional too and stores the locations of the object factory's and the object's class definitions 🎀.

A directory entry holding a JNDI reference is represented by the object class javaNamingReference, which is a subclass of javaObject. It's an auxiliary object class, which means it has to be mixed in with a structural object class 🌈. The definition of javaNamingReference lives in Section 4.

2.5 Remote Objects 🛸

The Java Remote Method Invocation (RMI) system [RMI] is the mechanism that lets an object on one Java virtual machine invoke methods on an object in another Java virtual machine. Any object whose methods can be invoked this way has to implement the java.rmi.Remote interface 🫠. When one of these objects gets invoked, its arguments are marshalled and sent from the local virtual machine over to the remote one, where they're unmarshalled and used. When the method finishes, the results are marshalled on the remote side and sent back to the caller's virtual machine 💜.

To make a remote object reachable by other virtual machines, a program typically registers it with the RMI registry 📮. The program hands the registry the string name of the remote object along with the remote object itself. When a program wants to access a remote object, it gives the object's string name to the RMI registry on the same machine as that object. The registry then returns a reference (called a "stub") to the remote object, and once the program has that stub, it can invoke methods on the remote object through it 🦋. A program can also get references to remote objects as the result of remote calls to other remote objects, or from other naming services. For example, a 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". Here, "hostname" and "port" identify the machine and port the RMI registry is running on, and "remoteObjectName" is the string name of the remote object. The "hostname", "port", and the "rmi:" prefix are all optional ✨. If "hostname" isn't specified, it defaults to the local host. If "port" isn't specified, it defaults to 1099. And if "remoteObjectName" isn't specified, the object being named is the RMI registry itself. See [RMI] for details 🧁.

RMI can be supported using different protocols: the Java Remote Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP) 🍓. JRMP is a specialized protocol designed just for RMI, while IIOP is the standard protocol for communication between CORBA objects [CORBA]. RMI over IIOP lets Java remote objects talk to 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 IIOP are represented in the directory as CORBA object references [CORBA-LDAP]. Remote objects that use 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, plus any serializable or remote objects it references, and it 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, like this 🎀:

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, and the javaClassNames attribute should contain the names of the classes and interfaces of the remote object 🧚. To read the remote object back out of the directory, first deserialize the contents of javaSerializedData to get a MarshalledObject (mobj), then retrieve the remote object from it like so 👑:

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

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

heads up: MarshalledObject is only available on the Java 2 Platform, Standard Edition, v1.2 and higher releases. So a remote object stored as a MarshalledObject can only be read by clients running the Java 2 Platform, Standard Edition, v1.2 or higher releases 🙈.

To store a remote object as a JNDI reference, you first create a javax.naming.Reference object instance for it. You use the remote object's string name as it has been (or will be) recorded with the RMI registry, with the extra 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 big advantage of a JNDI reference is that you can do this without having a reference to the remote object at all 🦋. In fact, the remote object doesn't even have to exist when this recording in the directory is made. It only needs to exist and be bound with the RMI registry by the time the object gets 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 Java objects, so let's untangle them 🧶.

A javaSerializableObject (as written in this document) or a serializable object stored as a javaMarshalledObject represents the object itself. A javaNamingReference, or a remote object stored as a javaMarshalledObject, represents a "pointer" to the object instead 🌈.

When you're storing a serializable object in the directory, you get a choice between storing it as a javaSerializedObject or as a javaMarshalledObject. The javaSerializedObject object class is the basic way to store serializable objects. If 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 🎀. If you create an LDAP entry using the javaMarshalledObject object class, you use the MarshalledObject class instead. The MarshalledObject class uses the RMI infrastructure on the Java platform to automate how codebase information gets gathered and recorded, so you don't have to set javaCodebase yourself 🤖. On the other hand, javaCodebase is human-readable and can be updated easily with text-based tools, without having to change any other parts of the entry. This means you could, for instance, move the class definitions to another location and then update javaCodebase to reflect the move, without having to update the serialized object itself 🦋.

A javaNamingReference provides a way to record address information about an object that isn't directly stored in the directory. A remote object stored as a javaMarshalledObject also records address information (the object's "stub") for an object that isn't stored in the directory 💜. In other words, you can think of these as compact representations of the information needed to access the object ✨.

A javaNamingReference typically consists of a small number of human-readable strings. That means standard text-based tools for directory administration can be used to add, read, or modify reference entries (if you want to) pretty easily 🫶. Serialized and marshalled objects, on the other hand, aren't meant 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's a single-valued attribute. Its syntax is Directory String, and its case is significant, so capitalization matters here 🔥.

( 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
)

3.2 javaCodebase ✨

okay so this attribute is where we stash the locations of the Java class definition 🗺️ it tells you where to go grab the class definition for whatever's named in the javaClassName attribute 💖 each value is an ordered list of URLs separated by spaces. so "url1 url2 url3" means those three URLs (url1, url2, and url3) are the codebase, and they might be interdependent, like besties who only work as a set 🫶

if javaCodebase has more than one value, each value is its own independent codebase 🌈 the URLs in one value have nothing to do with the URLs in another, so each value is basically an alternate source for loading the class definition. see [Java] for the class loading stuff 📚

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 one stores the fully qualified class or interface names of the Java object, like "java.lang.String" 💅 it's multivalued. when there's more than one value, each one is the name of a class or interface (or an ancestor class or interface) of this object. very family tree energy 🌳

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
    )

3.4 javaSerializedData 🍓

this attribute stores the serialized form of a Java object 🧳 the serialized form is described in [Serial], so go check that one out if you want the full deets 🤓

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 one stores the fully qualified class name of the object factory (think "com.wiz.jndi.WizObjectFactory") that can be used to create an instance of the object named by javaClassName ✨ its case is significant, and it's single-valued, so there's only ever one of these per entry 💖

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 🦋

okay this is the big one, so get comfy bestie 🧸 this attribute holds the sequence of addresses for a JNDI reference. each value is one address, which is a Java object of type javax.naming.RefAddr 💅 each value is the address type and address contents glued together, with a sequence number up front. the order of addresses in a JNDI reference actually matters, so the numbering is not optional 🔥 here's what it looks like:

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

so here's how the encoding works, step by step 🧚

the very first character of the value is the delimiter 🪄 for readability, the character '#' is recommended when it isn't used anywhere else in the value. but any character can be used, as long as it follows the restrictions further down.

after the first delimiter comes the sequence number. the sequence number is the address's position in the JNDI reference, and the first address is numbered 0 🔢 it's written in its shortest string form, in decimal notation.

then the sequence number is followed by a delimiter, then the address type, then another delimiter. if the address is of Java class javax.naming.StringRefAddr, that delimiter is followed by the address contents, which is a string 🧵 otherwise, that delimiter is followed right away by another delimiter, and then by the Base64 encoding of the serialized form of the entire address 🧁

now the rules for picking your delimiter 👑 it can be any character except a digit or a character that shows up in the address type. also, if the address contents is a string, the delimiter may not be the first character of that string. so no sneaky overlaps, okay? 🙈

this attribute's syntax is 'Directory String' and its case is significant 💜 it can hold multiple values, obviously 🌈

    ( 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. its value is a URL 🔗 for example, this 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
    )

---

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 can't exist in the directory by itself. 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 )
    )

4.3 javaSerializedObject 🍬

this auxiliary object class represents a Java serialized object. it has to 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 has to be mixed in with a structural object class too 🧚

    ( 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, and it also has to 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 )
    )

---

5. Security Considerations 🔒

okay bestie, this part is SERIOUS 😭 serializing an object and storing it in the directory means (a copy of) that object can be examined and used outside the environment where it was originally created 💀

the directory entry holding the serialized object could be read and modified, within the limits set by the directory's access control mechanisms 🛡️ so if an object has sensitive information, or info that could be misused outside the context it was created in, it should not be stored in the directory 🚫 that's the big warning 🙅‍♀️ for more on security issues with serialization in general, see [Serial] 🔐

6. Acknowledgements 🫶

big thank you to Joseph Fialli, Peter Jones, Roger Riggs, Bob Scheifler, and Ann Wollrath of Sun Microsystems for their comments and suggestions 💖 you're all iconic 👑

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

    [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

Appendix - LDAP Schema ✨

okay bestie, this is the appendix and it's literally the LDAP schema 🧚 every attribute type and object class lives right here, so here we go 💅

Attribute types 🎀

  -- 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
  )
  ( 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 🌸

  -- 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 🦋

  -- 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 )
  )
  ( 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 ✨

  -- Matching rule from ISO X.520 --

  ( 2.5.13.5
    NAME 'caseExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  )

---

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.