RFC 2714

RFC 2714: Schema for Representing CORBA Object References in an LDAP Directory ✨

Part 1 of 2 🎀

Network Working Group 🌸

Authors: V. Ryan, R. Lee, and S. Seligman, all at Sun Microsystems, Inc. 💖

Category: Informational 📚

Date: October 1999 📅

Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates 🙈

Status of This Memo 📣

okay so this memo is just here to give info to the internet community 💅 It doesn't specify an internet standard of any kind, so it's not a standard. Distribution of this memo is unlimited, so share it with everyone you know 🫶

Copyright Notice ©️

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

Abstract 🦋

CORBA [CORBA] is the Common Object Request Broker Architecture from the Object Management Group, and this document is the one that defines the schema for storing CORBA object references in an LDAP directory [LDAPv3]. It's giving organization 🗂️

1. Introduction 🧚

This document assumes you already have a general understanding of CORBA, so we're skipping the basics 😎

Okay, so LDAP directories have traditionally been used to store data 🗃️ Users and programmers picture the directory as a hierarchy of directory entries, and each entry holds a set of attributes. You look up an entry and pull out the attribute(s) you care about. For example, you can look up a person's telephone number. You can also search the directory for entries that have a particular set of attributes. For example, you can search for every person in the directory with the surname "Smith" 🔍

CORBA applications need access to CORBA objects, and they've traditionally used the COS Naming service to store and retrieve CORBA object references. When there's a directory in the environment, CORBA applications should be able to use it as a repository for CORBA object references 💅 The directory is a centrally administered, and possibly replicated, service that CORBA applications spread across the network can all use. Main character energy 👑

For example, an application server might use the directory to "register" CORBA objects that represent the services it manages. That way, a client can search the directory later to find those services whenever it needs them ✨

The whole point of this document is to define a common way for applications to store and retrieve CORBA object references in the directory 🎀 With this common schema, any CORBA application that needs to read or store CORBA object references in the directory can do it in an interoperable way. It's so iconic 🫶

Quick note: this schema is only for storing CORBA "object references," not CORBA objects in general 🙈 There might be other ways to store CORBA objects in an LDAP directory, but this schema doesn't cover them.

2. Representation of CORBA Object References 🦋

This document defines the schema elements that represent a CORBA object reference in an LDAP directory 💜 An application that has a reference to an object can invoke calls on that object. That kind of reference is called an "interoperable object reference," or IOR. Using IORs gives applications access to CORBA objects transparently, through the General Inter-ORB Protocol 🌸

A CORBA object reference is represented in the directory by the object class corbaObjectReference. This is a subclass of the abstract corbaObject object class. corbaObjectReference is an auxiliary object class, which means it has to be mixed in with a structural object class 🧩

The object class corbaContainer is used in a directory entry that represents a CORBA object or object reference. It's a structural object class. When it's representing an object reference, the corbaObjectReference object class also needs to be present in the entry. corbaContainer isn't required when a subclass of corbaObject (such as corbaObjectReference) is mixed in with another structural object class 💅

The definitions for the object classes corbaObject, corbaObjectReference, and corbaContainer are in Section 4 🗒️

The corbaObject class has two optional attributes: corbaRepositoryId and description. corbaRepositoryId is a multivalued attribute that stores the repository ids of the interfaces a CORBA object implements. description stores a textual description of a CORBA object 📝

The corbaObjectReference class has one mandatory attribute: corbaIor. corbaIor stores the object's stringified IOR 🎀

corbaIor and corbaRepositoryId are defined in Section 3. description is defined in [v3Schema] 🌈

3. Attribute Type Definitions 💖

These are the attribute types defined in this document:

corbaIor
corbaRepositoryId

3.1 corbaIor 🧁

This attribute stores the string representation of the interoperable object reference (IOR) for a CORBA object. An IOR is an opaque handle for the object. It has the information needed to locate the object, even if the object lives in another ORB 🔍

The syntax of this attribute is 'IA5 String', and its case is insignificant 🙈

   ( 1.3.6.1.4.1.42.2.27.4.1.14
    NAME 'corbaIor'
    DESC 'Stringified interoperable object reference of a CORBA object'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE
   )

3.2 corbaRepositoryId 🦋

Every CORBA interface has a unique "repository id" (also called a "type id") that identifies it. A CORBA object has one or more repository ids, one for each interface it implements 🫶

A repository id can be any string, but the OMG specifies four standard formats 📜

a. IDL-style

The format is:

IDL:Prefix/ModuleName/InterfaceName:VersionNumber

For example, the repository id for the "NamingContext" in OMG's COS Naming module is "IDL:omg.org/CosNaming/NamingContext:1.0" ✨

b. RMI-style

The format is:

RMI:ClassName:HashCode[:SUID]

This format is used by RMI-IIOP remote objects [RMI-IIOP]. ClassName is the fully qualified name of the class (for example, "java.lang.String"). HashCode is the object's hash code, which is the one you get by invoking the "hashCode()" method. SUID is the "stream unique identifier," a 64-bit number that uniquely identifies the serialization version of the class. SUID is optional in the repository id 💜

c. DCE-style

The format is:

DCE:UUID

This format is used for DCE/CORBA interoperability [CORBA-DCE]. UUID represents a DCE UUID 🌸

d. "local"

This format is defined by the local Object Request Broker (ORB) 🏠

The corbaRepositoryId attribute is multivalued. Each value records a single repository id of an interface that the CORBA object implements. This attribute doesn't need to contain a complete list of the interfaces the CORBA object implements 🧚

The syntax of this attribute is 'Directory String', and its case is significant. The values of this attribute are encoded using UTF-8. Some values may need translation from their native representation to be encoded correctly in UTF-8 🌈

   ( 1.3.6.1.4.1.42.2.27.4.1.15
    NAME 'corbaRepositoryId'
    DESC 'Repository ids of interfaces implemented by a CORBA object'
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   )

4. Object Class Definitions 🎀

These are the object classes defined in this document:

corbaContainer
corbaObject
corbaObjectReference

4.1 corbaContainer 🧺

This structural object class represents a container for a CORBA object 📦

   ( 1.3.6.1.4.1.42.2.27.4.2.10
    NAME 'corbaContainer'
    DESC 'Container for a CORBA object'
    SUP top
    STRUCTURAL
    MUST ( cn )
   )

4.2 corbaObject 🌷

This abstract object class is the root class for representing a CORBA object 👑

   ( 1.3.6.1.4.1.42.2.27.4.2.9
    NAME 'corbaObject'
    DESC 'CORBA object representation'
    SUP top
    ABSTRACT
    MAY ( corbaRepositoryId $ description )
   )

4.3 corbaObjectReference 🔗

This auxiliary object class represents a CORBA object reference. It has to be mixed in with a structural object class 🧩

   ( 1.3.6.1.4.1.42.2.27.4.2.11
    NAME 'corbaObjectReference'
    DESC 'CORBA interoperable object reference'
    SUP corbaObject
    AUXILIARY
    MUST ( corbaIor )
   )

10. Full Copyright Statement 💖

okay bestie, this is the legal part, so it's a little stiff, but I've kept every bit of the meaning. 🫶

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

so the rules are: you can copy this doc and share it, and you can write stuff that talks about it, explains it, or helps people implement it, and publish or distribute that stuff too, all or part, no restrictions 🎀. the one catch is the copyright notice and this paragraph have to stay on every copy and every derivative work ✨.

BUT (big but 😭) you can't change the document itself. no deleting the copyright notice, no removing the references to the Internet Society or other Internet orgs. the exceptions are when you need it for developing Internet standards, in which case the Internet Standards process copyright procedures have to be followed, or when you're translating it into a language other than English 🌍.

the permissions I just described are perpetual, which means they will not be revoked by the Internet Society or its successors or assigns. forever and ever 💜.

Disclaimer (read it, it matters 🙈): 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. thank you to them for keeping the lights on for the RFC Editor 🙏✨