idnits 2.17.1 draft-ryan-java-schema-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RMI], [Serial], [LDAPv3], [JNDI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 634: '... MUST ( cn )...' RFC 2119 keyword, line 648: '... MUST ( javaClassName )...' RFC 2119 keyword, line 649: '... MAY ( javaClassNames $...' RFC 2119 keyword, line 665: '... MUST ( javaSerializedData )...' RFC 2119 keyword, line 678: '... MUST ( javaSerializedData )...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 726 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CORBA' -- Possible downref: Non-RFC (?) normative reference: ref. 'CORBA-LDAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Java' -- Possible downref: Non-RFC (?) normative reference: ref. 'JNDI' ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. 'RMI' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMI-IIOP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Serial' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT V. Ryan 3 Expires 15 October, 1999 S. Seligman 4 R. Lee 5 Sun Microsystems, Inc. 6 15 April, 1999 8 Schema for Representing Java(tm) Objects in an LDAP Directory 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Please see the Copyright section near the end of this document for 34 more information. 36 Abstract 38 This document defines the schema for representing Java(tm) objects in 39 an LDAP directory [LDAPv3]. It defines schema elements to represent 40 a Java serialized object [Serial], a Java marshalled object [RMI], a 41 Java remote object [RMI], and a JNDI reference [JNDI]. 43 1. Introduction 45 This document assumes that the reader has a general knowledge of the 46 Java programming language [Java]. For brevity we use the term "Java 47 object" in place of "object in the Java programming language" 48 throughout this text. 50 Traditionally, LDAP directories have been used to store data. Users 51 and programmers think of the directory as a hierarchy of directory 52 entries, each containing a set of attributes. You look up an entry 53 from the directory and extract the attribute(s) of interest. For 54 example, you can look up a person's telephone number from the 55 directory. Alternatively, you can search the directory for entries 56 with a particular set of attributes. For example, you can search for 57 all persons in the directory with the surname "Smith". 59 For applications written in the Java programming language, a kind of 60 data that is typically shared are Java objects themselves. For such 61 applications, it makes sense to be able to use the directory as a 62 repository for Java objects. The directory provides a centrally 63 administered, and possibly replicated, service for use by Java 64 applications distributed across the network. 66 For example, an application server might use the directory for 67 "registering" objects representing the services that it manages, so 68 that a client can later search the directory to locate those services 69 as it needs. 71 The motivation for this document is to define a common way for 72 applications to store and retrieve Java objects from the directory. 73 Using this common schema, any Java application that needs to read or 74 store Java objects in the directory can do so in an interoperable 75 way. 77 2 Representation of Java Objects 79 This document defines schema elements to represent three types of 80 Java objects: a Java serialized object, a Java marshalled object, 81 and a JNDI reference. A Java remote object is stored as either a Java 82 marshalled object or a JNDI reference. 84 2.1 Common Representations 86 A Java object is stored in the LDAP directory by using the object 87 class javaObject. This is the base class from which other Java object 88 related classes derive: javaSerializedObject, javaMarshalledObject, 89 and javaNamingReference. javaObject is an abstract object class, 90 which means that a javaObject cannot exist by itself in the 91 directory; only auxiliary or structural subclasses of it can exist in 92 the directory. 94 The object class javaContainer represents a directory entry dedicated 95 to storing a Java object. It is a structural object class. In cases 96 where a subclass of javaObject is mixed in with another structural 97 object class, javaContainer is not required. 99 The definitions for the object classes javaObject and javaContainer 100 are presented in Section 4. 102 The javaObject class has one mandatory attribute (javaClassName) and 103 four optional attributes (javaClassNames, javaCodebase, javaDoc, 104 description). javaClassName is a single valued attribute that is 105 used to store the fully qualified name of the object's Java class 106 (for example, "java.lang.String"). This may be the object's most 107 derived class's name, but does not have to be; that of a superclass 108 or interface in some cases might be most appropriate. This attribute 109 is intended for storing the name of the object's "distinguished" 110 class, that is, the class or interface with which the object should 111 be identified. 113 javaClassNames is a multivalued attribute that is used to store the 114 fully qualified names of the object's Java classes and interfaces 115 (for example, "java.lang.Byte"). Like all multivalued attributes, the 116 javaClassNames attribute's values are unordered and so no one value 117 is more "distinguished" than the others. This attribute is intended 118 for storing an object's class and interface names and those of its 119 ancestor classes and interfaces, although the list of values does not 120 have to be complete. If the javaClassNames attribute is present, it 121 should include the value of javaClassName. 123 For example, suppose an object is stored in the directory with a 124 javaClassName attribute of "java.io.FilePermission", and a 125 javaClassNames attribute of {"java.security.Permission", 126 "java.io.FilePermission", "java.security.Guard", 127 "java.io.Serializable"}. An application searching a directory for 128 Java objects might use javaClassName to produce a summary of the 129 names and types of Java objects in that directory. Another 130 application might use the javaClassNames attribute to find, for 131 example, all java.security.Permission objects. 133 javaCodebase is a multivalued attribute that is used to store the 134 location(s) of the object's class definition. javaDoc is used to 135 store a pointer (URL) to the Java documentation for the class. 136 description is used to store a textual description of a Java object 137 and is defined in [v3Schema]. The definitions of these attributes are 138 presented in Section 3. 140 2.2 Serialized Objects 142 To "serialize" an object means to convert its state into a byte 143 stream in such a way that the byte stream can be converted back into 144 a copy of the object. A Java object is "serializable" if its class 145 or any of its superclasses implements either the java.io.Serializable 146 interface or its subinterface java.io.Externalizable. 147 "Deserialization" is the process of converting the serialized form of 148 an object back into a copy of the object. When an object is 149 serialized, the entire tree of objects rooted at the object is also 150 serialized. When it is deserialized, the tree is reconstructed. For 151 example, suppose a serializable Book object contains (a serializable 152 field of) an array of Page objects. When a Book object is 153 serialized, so is the array of Page objects. 155 The Java platform specifies a default algorithm by which serializable 156 objects are serialized. A Java class can also override this default 157 serialization with its own algorithm. [Serial] describes object 158 serialization in detail. 160 When an object is serialized, information that identifies its class 161 is recorded in the serialized stream. However, the class's definition 162 ("class file") itself is not recorded. It is the responsibility of 163 the system that is deserializing the object to determine the 164 mechanism to use for locating and loading the associated class 165 definitions. For example, the Java application might include in its 166 classpath a JAR file containing the class definitions of the 167 serialized object, or load the class definitions using information 168 from the directory, as explained below. 170 2.2.1 Representation in the Directory 172 A serialized object is represented in the directory by the attributes 173 javaClassName, javaClassNames, javaCodebase, and javaSerializedData, 174 as defined in Section 3. The mandatory attribute, 175 javaSerializedData, contains the serialized form of the object. 176 Although the serialized form already contains the class name, the 177 mandatory javaClassName attribute also records the class name of the 178 serialized object so that applications can determined class 179 information without having to first deserialize the object. The 180 optional javaClassNames attribute is used to record additional class 181 information about the serialized object. The optional javaCodebase 182 attribute is used to record the locations of the class definitions 183 needed to deserialize the serialized object. 185 A directory entry that contains a serialized object is represented by 186 the object class javaSerializedObject, which is a subclass of 187 javaObject. javaSerializedObject is an auxiliary object class, which 188 means that it needs to be mixed in with a structural object class. 189 javaSerializedObject's definition is given in Section 4. 191 2.3 Marshalled Objects 192 To "marshal" an object means to record its state and codebase(s) in 193 such a way that when the marshalled object is "unmarshalled," a copy 194 of the original object is obtained, possibly by automatically loading 195 the class definitions of the object. You can marshal any object that 196 is serializable or remote (that is, implements the java.rmi.Remote 197 interface). Marshalling is like serialization, except marshalling 198 also records codebases. Marshalling is different from serialization 199 in that marshalling treats remote objects specially. If an object is 200 a java.rmi.Remote object, marshalling records the remote object's 201 "stub" (see Section 2.5), instead of the remote object itself. Like 202 serialization, when an object is marshalled, the entire tree of 203 objects rooted at the object is marshalled. When it is unmarshalled, 204 the tree is reconstructed. 206 A "marshalled" object is the represented by the 207 java.rmi.MarshalledObject class. Here's an example of how to create 208 MarshalledObjects for serializable and remote objects: 210 java.io.Serializable sobj = ...; 211 java.rmi.MarshalledObject mobj1 = 212 new java.rmi.MarshalledObject(sobj); 214 java.rmi.Remote robj = ...; 215 java.rmi.MarshalledObject mobj2 = 216 new java.rmi.MarshalledObject(robj); 218 Then, to retrieve the original objects from the MarshalledObjects, do 219 as follows: 221 java.io.Serializable sobj = (java.io.Serializable) mobj1.get(); 222 java.io.Remote rstub = (java.io.Remote) mobj2.get(); 224 MarshalledObject is available only on the Java 2 Platform, Standard 225 Edition, v1.2, and higher releases. 227 2.3.1 Representation in the Directory 229 A marshalled object is represented in the directory by the attributes 230 javaClassName, javaClassNames, and javaSerializedData, as defined in 231 Section 3. The mandatory attribute, javaSerializedData, contains the 232 serialized form of the marshalled object (that is, the serialized 233 form of a MarshalledObject instance). The mandatory javaClassName 234 attribute records the distinguished class name of the object before 235 it has been marshalled. The optional javaClassNames attribute is 236 used to record additional class information about the object before 237 it has been marshalled. 239 A directory entry that contains a marshalled object is represented by 240 the object class javaMarshalledObject, which is a subclass of 241 javaObject. javaMarshalledObject is an auxiliary object class, which 242 means that it needs to be mixed in with a structural object class. 243 javaMarshalledObject's definition is given in Section 4. 245 As evident in this description, a javaMarshalledObject differs from a 246 javaSerializedObject only in the interpretation of the javaClassName 247 and javaClassNames attributes. 249 2.4 JNDI References 251 Java Naming and Directory Interface(tm) (JNDI) is a directory access 252 API specified in the Java programming language [JNDI]. It provides 253 an object-oriented view of the directory, allowing Java objects to be 254 added to and retrieved from the directory without requiring the 255 client to manage data representation issues. 257 JNDI defines the notion of a "reference" for use when an object 258 cannot be stored in the directory directly, or when it is 259 inappropriate or undesirable to do so. An object with an associated 260 reference is stored in the directory indirectly, by storing its 261 reference instead. 263 2.4.1 Contents of a Reference 265 A JNDI reference is a Java object of class javax.naming.Reference. 266 It consists of class information about the object being referenced 267 and an ordered list of addresses. An address is a Java object of 268 class javax.naming.RefAddr. Each address contains information on how 269 to construct the object. 271 A common use for JNDI references is to represent connections to a 272 network service such as a database, directory, or file system. Each 273 address may then identify a "communications endpoint" for that 274 service, containing information on how to contact the service. 275 Multiple addresses may arise for various reasons, such as replication 276 or the object offering interfaces over more than one communication 277 mechanism. 279 A reference also contains information to assist in the creation of an 280 instance of the object to which the reference refers. It contains 281 the Java class name of that object, and the class name and location 282 of the object factory to be used to create the object. The 283 procedures for creating an object given its reference and the reverse 284 are described in [JNDI]. 286 2.4.2 Representation in the Directory 287 A JNDI reference is stored in the directory by using the attributes 288 javaClassName, javaClassNames, javaCodebase, javaReferenceAddress, 289 and javaFactory, defined in Section 3. These attributes store 290 information corresponding to the contents of a reference described 291 above. javaReferenceAddress is a multivalued optional attribute for 292 storing reference addresses. javaFactory is the optional attribute 293 for storing the object factory's fully qualified class name. The 294 mandatory javaClassName attribute is used to store the name of the 295 distinguished class of the object. The optional javaClassNames 296 attribute is used to record additional class and interface names. 297 The optional javaCodebase attribute is used to store the locations of 298 the object factory's and the object's class definitions. 300 A directory entry containing a JNDI reference is represented by the 301 object class javaNamingReference, which is a subclass of javaObject. 302 javaNamingReference is an auxiliary object class, which means that it 303 needs to be mixed in with a structural object class. 304 javaNamingReference's definition is given in Section 4. 306 2.5 Remote Objects 308 The Java Remote Method Invocation (RMI) system [RMI] is a mechanism 309 that enables an object on one Java virtual machine to invoke methods 310 on an object in another Java virtual machine. Any object whose 311 methods can be invoked in this way must implement the java.rmi.Remote 312 interface. When such an object is invoked, its arguments are 313 marshalled and sent from the local virtual machine to the remote one, 314 where the arguments are unmarshalled and used. When the method 315 terminates, the results are marshalled from the remote machine and 316 sent to the caller's virtual machine. 318 To make a remote object accessible to other virtual machines, a 319 program typically registers it with the RMI registry. The program 320 supplies to the RMI registry the string name of the remote object and 321 the remote object itself. When a program wants to access a remote 322 object, it supplies the object's string name to the RMI registry on 323 the same machine as the remote object. The RMI registry returns to 324 the caller a reference (called "stub") to the remote object. When 325 the program receives the stub for the remote object, it can invoke 326 methods on the remote object (through the stub). A program can also 327 obtain references to remote objects as a result of remote calls to 328 other remote objects or from other naming services. For example, the 329 program can look up a reference to a remote object from an LDAP 330 server that supports the schema defined in this document. 332 The string name accepted by the RMI registry has the syntax 333 "rmi://hostname:port/remoteObjectName", where "hostname" and "port" 334 identify the machine and port on which the RMI registry is running, 335 respectively, and "remoteObjectName" is the string name of the remote 336 object. "hostname", "port", and the prefix, "rmi:", are optional. If 337 "hostname" is not specified, it defaults to the local host. If 338 "port" is not specified, it defaults to 1099. If "remoteObjectName" 339 is not specified, then the object being named is the RMI registry 340 itself. See [RMI] for details. 342 RMI can be supported using different protocols: the Java Remote 343 Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP). 344 The JRMP is a specialized protocol designed for RMI; the IIOP is the 345 standard protocol for communication between CORBA objects [CORBA]. 346 RMI over IIOP allows Java remote objects to communicate with CORBA 347 objects which might be written in a non-Java programming language 348 [RMI-IIOP]. 350 2.5.1 Representation in the Directory 352 Remote objects that use the IIOP are represented in the directory as 353 CORBA object references [CORBA-LDAP]. Remote objects that use the 354 JRMP are represented in the directory in one of two ways: as a 355 marshalled object, or as a JNDI reference. 357 A marshalled object records the codebases of the remote object's stub 358 and any serializable or remote objects that it references, and 359 replaces remote objects with their stubs. To store a Remote object 360 as a marshalled object (java.rmi.MarshalledObject), you first create 361 a java.rmi.MarshalledObject instance for it. 363 java.rmi.Remote robj = ...; 364 java.rmi.MarshalledObject mobj = 365 new java.rmi.MarshalledObject(robj); 367 You can then store the MarshalledObject instance as a 368 javaMarshalledObject. The javaClassName attribute should contain the 369 fully qualified name of the distinguished class of the remote object. 370 The javaClassNames attribute should contain the names of the classes 371 and interfaces of the remote object. To read the remote object back 372 from the directory, first deserialize the contents of the 373 javaSerializedData to get a MarshalledObject (mobj), then retrieve it 374 from the MarshalledObject as follows: 376 java.rmi.Remote robj = (java.rmi.Remote)mobj.get(); 378 This returns the remote stub, which you can then use to invoke remote 379 methods. 381 MarshalledObject is available only on the Java 2 Platform, Standard 382 Edition, v1.2 and higher releases. Therefore, a remote object stored 383 as a MarshalledObject can only be read by clients using the the Java 384 2 Platform, Standard Edition, v1.2 or higher releases. 386 To store a remote object as a JNDI reference, you first create a 387 javax.naming.Reference object instance for it using the remote 388 object's string name as it has been, or will be, recorded with the 389 RMI registry, with the additional restriction that the "rmi:" prefix 390 must be present. Here's an example: 392 javax.naming.Reference ref = new javax.naming.Reference( 393 obj.getClass().getName(), 394 new javax.naming.StringRefAddr("URL", 395 "rmi://rserver/AppRemoteObjectX")); 397 You then store the javax.naming.Reference instance as a 398 javaNamingReference. The advantage of using a JNDI reference is that 399 this can be done without a reference to the remote object. In fact, 400 the remote object does not have to exist at the time that this 401 recording in the directory is made. The remote object needs to exist 402 and be bound with the RMI registry when the object is looked up from 403 the directory. 405 2.6 Serialized Objects Vs. Marshalled Objects Vs. References 407 The object classes defined in this document store different aspects 408 of the Java objects. 410 A javaSerializedObject or a serializable object stored as a 411 javaMarshalledObject represents the object itself, while a 412 javaNamingReference or a remote object stored as a 413 javaMarshalledObject represents a "pointer" to the object. 415 When storing a serializable object in the directory, you have a 416 choice of storing it as a javaSerializedObject or a 417 javaMarshalledObject. The javaSerializedObject object class provides 418 the basic way in which to store serializable objects. When you create 419 an LDAP entry using the javaSerializableObject object class, you must 420 explicitly set the javaCodebase attribute if you want readers of that 421 entry to know where to load the class definitions of the object. When 422 you create an LDAP entry using the javaMarshalledObject object class, 423 you use the MarshalledObject class. The MarshalledObject class uses 424 the RMI infrastructure available on the Java platform to automate how 425 codebase information is gathered and recorded, thus freeing you from 426 having to set the javaCodebase attribute. On the other hand, the 427 javaCodebase attribute is human-readable and can be updated easily by 428 using text-based tools without having to change other parts of the 429 entry. This allows you, for instance, to move the class definitions 430 to another location and then update the javaCodebase attribute to 431 reflect the move without having to update the serialized object 432 itself. 434 A javaNamingReference provides a way of recording address information 435 about an object which itself is not directly stored in the directory. 436 A remote object stored as a javaMarshalledObject also records address 437 information (the object's "stub") of an object which itself is not 438 directory stored in the directory. In other words, you can think of 439 these as compact representations of the information required to 440 access the object. 442 A javaNamingReference typically consists of a small number of human- 443 readable strings. Standard text-based tools for directory 444 administration may therefore be used to add, read, or modify 445 reference entries -- if so desired -- quite easily. Serialized and 446 marshalled objects are not intended to be read or manipulated 447 directly by humans. 449 3 Attribute Type Definitions 451 The following attribute types are defined in this document: 453 javaClassName 454 javaClassNames 455 javaCodebase 456 javaSerializedData 457 javaFactory 458 javaReferenceAddress 459 javaDoc 461 3.1 javaClassName 463 This attribute stores the fully qualified name of the Java object's 464 "distinguished" class or interface (for example, "java.lang.String"). 465 It is a single-valued attribute. This attribute's syntax is 466 'Directory String' and its case is significant. 468 ( 1.3.6.1.4.1.42.2.27.4.1.6 469 NAME 'javaClassName' 470 DESC 'Fully qualified name of distinguished Java class or 471 interface' 472 EQUALITY caseExactMatch 473 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 474 SINGLE-VALUE 475 ) 477 3.2 javaCodebase 479 This attribute stores the Java class definition's locations. It 480 specifies the locations from which to load the class definition for 481 the class specified by the javaClassName attribute. Each value of 482 the attribute contains an ordered list of URLs, separated by spaces. 483 For example, a value of "url1 url2 url3" means that the three 484 (possibly interdependent) URLs (url1, url2, and url3) form the 485 codebase for loading in the Java class definition. 487 If the javaCodebase attribute contains more than one value, each 488 value is an independent codebase. That is, there is no relationship 489 between the URLs in one value and those in another; each value can be 490 viewed as an alternate source for loading the Java class definition. 491 See [Java] for information regarding class loading. 493 This attribute's syntax is 'IA5 String' and its case is significant. 495 ( 1.3.6.1.4.1.42.2.27.4.1.7 496 NAME 'javaCodebase' 497 DESC 'URL(s) specifying the location of class definition' 498 EQUALITY caseExactIA5Match 499 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 500 ) 502 3.3 javaClassNames 504 This attribute stores the Java object's fully qualified class or 505 interface names (for example, "java.lang.String"). It is a 506 multivalued attribute. When more than one value is present, each is 507 the name of a class or interface, or ancestor class or interface, of 508 this object. 510 This attribute's syntax is 'Directory String' and its case is 511 significant. 513 ( 1.3.6.1.4.1.42.2.27.4.1.13 514 NAME 'javaClassNames' 515 DESC 'Fully qualified Java class or interface name' 516 EQUALITY caseExactMatch 517 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 518 ) 520 3.4 javaSerializedData 522 This attribute stores the serialized form of a Java object. The 523 serialized form is described in [Serial]. 525 This attribute's syntax is 'Binary'. 527 ( 1.3.6.1.4.1.42.2.27.4.1.8 528 NAME 'javaSerializedData 529 DESC 'Serialized form of a Java object' 530 SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 531 SINGLE-VALUE 532 ) 534 3.5 javaFactory 536 This attribute stores the fully qualified class name of the object 537 factory (for example, "com.wiz.jndi.WizObjectFactory") that can be 538 used to create an instance of the object identified by the 539 javaClassName attribute. 541 This attribute's syntax is 'Directory String' and its case is 542 significant. 544 ( 1.3.6.1.4.1.42.2.27.4.1.10 545 NAME 'javaFactory' 546 DESC 'Fully qualified Java class name of a JNDI object factory' 547 EQUALITY caseExactMatch 548 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 549 SINGLE-VALUE 550 ) 552 3.6 javaReferenceAddress 554 This attribute represents the sequence of addresses of a JNDI 555 reference. Each of its values represents one address, a Java object 556 of type javax.naming.RefAddr. Its value is a concatenation of the 557 address type and address contents, preceded by a sequence number (the 558 order of addresses in a JNDI reference is significant). For example: 560 #0#TypeA#ValA 561 #1#TypeB#ValB 562 #2#TypeC##rO0ABXNyABpq... 564 In more detail, the value is encoded as follows: 566 The delimiter is the first character of the value. For readability 567 the character '#' is recommended when it is not otherwise used 568 anywhere in the value, but any character may be used subject to 569 restrictions given below. 571 The first delimiter is followed by the sequence number. The sequence 572 number of an address is its position in the JNDI reference, with the 573 first address being numbered 0. It is represented by its shortest 574 string form, in decimal notation. 576 The sequence number is followed by a delimiter, then by the address 577 type, and then by another delimiter. If the address is of Java class 578 javax.naming.StringRefAddr, then this delimiter is followed by the 579 value of the address contents (which is a string). Otherwise, this 580 delimiter is followed immediately by another delimiter, and then by 581 the Base64 encoding of the serialized form of the entire address. 583 The delimiter may be any character other than a digit or a character 584 contained in the address type. In addition, if the address contents 585 is a string, the delimiter may not be the first character of that 586 string. 588 This attribute's syntax is 'Directory String' and its case is 589 significant. It can contain multiple values. 591 ( 1.3.6.1.4.1.42.2.27.4.1.11 592 NAME 'javaReferenceAddress' 593 DESC 'Addresses associated with a JNDI Reference' 594 EQUALITY caseExactMatch 595 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 596 ) 598 3.7 javaDoc 600 This attribute stores a pointer to the Java documentation for the 601 class. It's value is a URL. For example, the following URL points to 602 the specification of the java.lang.String class: 603 http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html . 605 This attribute's syntax is 'IA5 String' and its case is significant. 607 ( 1.3.6.1.4.1.42.2.27.4.1.12 608 NAME 'javaDoc' 609 DESC 'The Java documentation for the class' 610 EQUALITY caseExactIA5Match 611 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 612 ) 614 4 Object Class Definitions 616 The following object classes are defined in this document: 618 javaContainer 619 javaObject 620 javaSerializedObject 621 javaMarshalledObject 622 javaNamingReference 624 4.1 javaContainer 626 This structural object class represents a container for a Java 627 object. 629 ( 1.3.6.1.4.1.42.2.27.4.2.1 630 NAME 'javaContainer' 631 DESC 'Container for a Java object' 632 SUP top 633 STRUCTURAL 634 MUST ( cn ) 635 ) 637 4.2 javaObject 639 This abstract object class represents a Java object. A javaObject 640 cannot exist in the directory; only auxiliary or structural 641 subclasses of it can exist in the directory. 643 ( 1.3.6.1.4.1.42.2.27.4.2.4 644 NAME 'javaObject' 645 DESC 'Java object representation' 646 SUP top 647 ABSTRACT 648 MUST ( javaClassName ) 649 MAY ( javaClassNames $ 650 javaCodebase $ 651 javaDoc $ 652 description ) 653 ) 655 4.3 javaSerializedObject 657 This auxiliary object class represents a Java serialized object. It 658 must be mixed in with a structural object class. 660 ( 1.3.6.1.4.1.42.2.27.4.2.5 661 NAME 'javaSerializedObject' 662 DESC 'Java serialized object' 663 SUP javaObject 664 AUXILIARY 665 MUST ( javaSerializedData ) 666 ) 668 4.4 javaMarshalledObject 670 This auxiliary object class represents a Java marshalled object. It 671 must be mixed in with a structural object class. 673 ( 1.3.6.1.4.1.42.2.27.4.2.8 674 NAME 'javaMarshalledObject' 675 DESC 'Java marshalled object' 676 SUP javaObject 677 AUXILIARY 678 MUST ( javaSerializedData ) 679 ) 681 4.5 javaNamingReference 683 This auxiliary object class represents a JNDI reference. It must be 684 mixed in with a structural object class. 686 ( 1.3.6.1.4.1.42.2.27.4.2.7 687 NAME 'javaNamingReference' 688 DESC 'JNDI reference' 689 SUP javaObject 690 AUXILIARY 691 MAY ( javaReferenceAddress $ 692 javaFactory ) 693 ) 695 5. Security Considerations 697 Serializing an object and storing it into the directory enables (a 698 copy of) the object to be examined and used outside the environment 699 in which it was originally created. The directory entry containing 700 the serialized object could be read and modified within the 701 constraints imposed by the access control mechanisms of the 702 directory. If an object contains sensitive information or 703 information that could be misused outside of the context in which it 704 was created, the object should not be stored in the directory. For 705 more details on security issues relating to serialization in general, 706 see [Serial]. 708 6. Acknowledgements 710 We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob 711 Scheifler, and Ann Wollrath of Sun Microsystems for their comments 712 and suggestions. 714 7. Copyright 716 Copyright (C) The Internet Society (1999). All Rights Reserved. 718 This document and translations of it may be copied and furnished to 719 others, and derivative works that comment on or otherwise explain it 720 or assist in its implementation may be prepared, copied, published 721 and distributed, in whole or in part, without restriction of any 722 kind, provided that the above copyright notice and this paragraph are 723 included on all such copies and derivative works. However, this 724 document itself may not be modified in any way, such as by removing 725 the copyright notice or references to the Internet Society or other 726 Internet organizations, except as needed for the purpose of 727 developing Internet standards in which case the procedures for 728 copyrights defined in the Internet Standards process must be 729 followed, or as required to translate it into languages other than 730 English. 732 The limited permissions granted above are perpetual and will not be 733 revoked by the Internet Society or its successors or assigns. 735 This document and the information contained herein is provided on an 736 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 737 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 738 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 739 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 740 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 742 8. References 744 [CORBA] The Object Management Group, "Common Object Request Broker 745 Architecture Specification 2.0," http://www.omg.org 747 [CORBA-LDAP] V. Ryan, R. Lee, and S. Seligman, "Schema for 748 Representing CORBA Objects in an LDAP Directory," 749 http://java.sun.com/products/jndi/draft-ryan-corba-schema-00.txt 751 [Java] Ken Arnold and James Gosling, "The Java(tm) Programming 752 Language," Second Edition, ISBN 0-201-31006-6. 754 [JNDI] Java Software, Sun Microsystems, Inc., "The Java(tm) Naming 755 and Directory Interface (tm) Specification," February 1998. 756 http://java.sun.com/products/jndi/ 758 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 759 Protocol (v3)," RFC-2251, December 1997. 760 http://www.ietf.org/rfc/rfc2251.txt 762 [RMI] Java Software, Sun Microsystems, Inc., "Remote Method 763 Invocation," November 1998. 764 http://java.sun.com/products/jdk/1.2/docs/guide/rmi 766 [RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over 767 IIOP," February 1999. IBM and Java Software, Sun Microsystems, Inc., 768 http://www.ibm.com/java/jdk/rmi-iiop/ 769 http://developer.java.sun.com/developer/earlyAccess/rmi- 770 iiop/index.html 772 [Serial] Java Software, Sun Microsystems, Inc., "Object Serialization 773 Specification," November 1998. 775 http://java.sun.com/products/jdk/1.2/docs/guide/serialization 777 [v3Schema] M. Wahl, "A Summary of the X.500(96) User Schema for use 778 with LDAPv3," RFC-2256, December 1997. 779 http://www.ietf.org/rfc/rfc2256.txt 781 9. Authors' Addresses 783 Vincent Ryan 784 Sun Microsystems, Inc. 785 Mail Stop EDUB03 786 901 San Antonio Road 787 Palo Alto, CA 94303 788 USA 789 +353 1 819 9151 790 vincent.ryan@ireland.sun.com 792 Scott Seligman 793 Sun Microsystems, Inc. 794 Mail Stop UCUP02-209 795 901 San Antonio Road 796 Palo Alto, CA 94303 797 USA 798 +1 408 863 3222 799 scott.seligman@eng.sun.com 801 Rosanna Lee 802 Sun Microsystems, Inc. 803 Mail Stop UCUP02-206 804 901 San Antonio Road 805 Palo Alto, CA 94303 806 USA 807 +1 408 863 3221 808 rosanna.lee@eng.sun.com 810 10. Appendix - LDAP Schema 812 -- Attribute types -- 814 ( 1.3.6.1.4.1.42.2.27.4.1.6 815 NAME 'javaClassName' 816 DESC 'Fully qualified name of distinguished Java class or interface' 817 EQUALITY caseExactMatch 818 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 819 ) 821 ( 1.3.6.1.4.1.42.2.27.4.1.7 822 NAME 'javaCodebase' 823 DESC 'URL(s) specifying the location of class definition' 824 EQUALITY caseExactIA5Match 825 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 826 ) 828 ( 1.3.6.1.4.1.42.2.27.4.1.8 829 NAME 'javaSerializedData' 830 DESC 'Serialized form of a Java object' 831 SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 832 SINGLE-VALUE 833 ) 835 ( 1.3.6.1.4.1.42.2.27.4.1.10 836 NAME 'javaFactory' 837 DESC 'Fully qualified Java class name of a JNDI object factory' 838 EQUALITY caseExactMatch 839 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 840 SINGLE-VALUE 841 ) 843 ( 1.3.6.1.4.1.42.2.27.4.1.11 844 NAME 'javaReferenceAddress' 845 DESC 'Addresses associated with a JNDI Reference' 846 EQUALITY caseExactMatch 847 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 848 ) 850 ( 1.3.6.1.4.1.42.2.27.4.1.12 851 NAME 'javaDoc' 852 DESC 'The Java documentation for the class' 853 EQUALITY caseExactIA5Match 854 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 855 ) 857 ( 1.3.6.1.4.1.42.2.27.4.1.13 858 NAME 'javaClassNames' 859 DESC 'Fully qualified Java class or interface name' 860 EQUALITY caseExactMatch 861 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 862 ) 864 -- from RFC-2256 -- 866 ( 2.5.4.13 867 NAME 'description' 868 EQUALITY caseIgnoreMatch 869 SUBSTR caseIgnoreSubstringsMatch 870 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 872 ) 874 -- Object classes -- 876 ( 1.3.6.1.4.1.42.2.27.4.2.1 877 NAME 'javaContainer' 878 DESC 'Container for a Java object' 879 SUP top 880 STRUCTURAL 881 MUST ( cn ) 882 ) 884 ( 1.3.6.1.4.1.42.2.27.4.2.4 885 NAME 'javaObject' 886 DESC 'Java object representation' 887 SUP top 888 ABSTRACT 889 MUST ( javaClassName ) 890 MAY ( javaClassNames $ javaCodebase $ javaDoc $ description ) 891 ) 893 ( 1.3.6.1.4.1.42.2.27.4.2.5 894 NAME 'javaSerializedObject' 895 DESC 'Java serialized object' 896 SUP javaObject 897 AUXILIARY 898 MUST ( javaSerializedData ) 899 ) 901 ( 1.3.6.1.4.1.42.2.27.4.2.7 902 NAME 'javaNamingReference' 903 DESC 'JNDI reference' 904 SUP javaObject 905 AUXILIARY 906 MAY ( javaReferenceAddress $ javaFactory ) 907 ) 909 ( 1.3.6.1.4.1.42.2.27.4.2.8 910 NAME 'javaMarshalledObject' 911 DESC 'Java marshalled object' 912 SUP javaObject 913 AUXILIARY 914 MUST ( javaSerializedData ) 915 ) 917 -- Matching rule from ISO X.520 -- 919 ( 2.5.13.5 920 NAME 'caseExactMatch' 921 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 922 )