idnits 2.17.1 draft-ryan-corba-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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 11 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 are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([CORBA], [LDAPv3]), 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 221: '... MUST ( cn )...' RFC 2119 keyword, line 234: '... MAY ( corbaRepositoryId $ des...' RFC 2119 keyword, line 247: '... MUST ( corbaIor )...' RFC 2119 keyword, line 375: '... MAY ( corbaRepositoryId $ descrip...' RFC 2119 keyword, line 383: '... MUST ( cn )...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 273 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. 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-DCE' ** 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-IIOP' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT V. Ryan 2 Expires 25 January, 2000 R. Lee 3 S. Seligman 4 Sun Microsystems, Inc. 5 25 August, 1999 7 Schema for Representing CORBA Object References in an LDAP Directory 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 32 Please see the Copyright section near the end of this document for 33 more information. 35 Abstract 37 CORBA [CORBA] is the Common Object Request Broker Architecture 38 defined by the Object Management Group. This document defines the 39 schema for representing CORBA object references in an LDAP directory 40 [LDAPv3]. 42 1. Introduction 44 This document assumes that the reader has a general understanding of 45 CORBA. 47 Traditionally, LDAP directories have been used to store data. Users 48 and programmers think of the directory as a hierarchy of directory 49 entries, each containing a set of attributes. You look up an entry 50 from the directory and extract the attribute(s) of interest. For 51 example, you can look up a person's telephone number from the 52 directory. Alternatively, you can search the directory for entries 53 with a particular set of attributes. For example, you can search for 54 all persons in the directory with the surname "Smith". 56 CORBA applications require access to CORBA objects. Traditionally, 57 CORBA applications have used the COS Naming service for storage and 58 retrieval of CORBA object references. When deployed in environments 59 with a directory, CORBA applications should be able to use the 60 directory as a repository for CORBA object references. The directory 61 provides a centrally administered, and possibly replicated, service 62 for use by CORBA applications distributed across the network. 64 For example, an application server may use the directory for 65 "registering" CORBA objects representing the services that it 66 manages, so that a client can later search the directory to locate 67 those services as it needs. 69 The motivation for this document is to define a common way for 70 applications to store and retrieve CORBA object references from the 71 directory. Using this common schema, any CORBA application that 72 needs to read or store CORBA object references in the directory can 73 do so in an interoperable way. 75 Note that this schema is defined for storing CORBA "object 76 references," not CORBA objects in general. There might be other ways 77 to store CORBA objects in an LDAP directory but they are not covered 78 by this schema. 80 2 Representation of CORBA Object References 82 This document defines schema elements to represent a CORBA object 83 reference in LDAP directory. Applications in possession of a 84 reference to an object can invoke calls on that object. Such a 85 reference is termed an "interoperable object reference," or IOR. 86 Access to CORBA objects by using IORs is achieved transparently to 87 the application, by means of the General Inter-ORB Protocol. 89 A CORBA object reference is represented in the directory by the 90 object class corbaObjectReference. corbaObjectReference is a subclass 91 of the abstract corbaObject object class. corbaObjectReference is an 92 auxiliary object class, which means that it needs to be mixed in with 93 a structural object class. 95 The object class corbaContainer is used in a directory entry which 96 represents a CORBA object or object reference. It is a structural 97 object class, and when representing an object reference, the 98 corbaObjectReference object class would also need to be present in 99 the entry. corbaContainer is not required when a subclass of 100 corbaObject (such as corbaObjectReference) is mixed in with another 101 structural object class. 103 The definitions for the object classes corbaObject, 104 corbaObjectReference, and corbaContainer are presented in Section 4. 106 The corbaObject class has two optional attributes: corbaRepositoryId 107 and description. corbaRepositoryId is a multivalued attribute that 108 is used to store the repository ids of the interfaces implemented by 109 a CORBA object. description is used to store a textual description 110 of a CORBA object. 112 The corbaObjectReference class has one mandatory attribute: corbaIor. 113 corbaIor is used to store the object's stringified IOR. 115 corbaIor and corbaRepositoryId are defined in Section 3; description 116 is defined in [v3Schema]. 118 3 Attribute Type Definitions 120 The following attribute types are defined in this document: 122 corbaIor 123 corbaRepositoryId 125 3.1 corbaIor 127 This attribute stores the string representation of the interoperable 128 object reference (IOR) for a CORBA object. An IOR is an opaque handle 129 for the object which contains the information necessary to locate the 130 object, even if the object is in another ORB. This attribute 131 includes, but is not limited to, the two formats already defined by 132 the OMG for an IOR: the IOR string version and the URL version (in 133 the Interoperable Naming Service). 135 This attribute's syntax is 'IA5 String' and its case is 136 insignificant. 138 ( 1.3.6.1.4.1.42.2.27.4.1.14 139 NAME 'corbaIor' 140 DESC 'Stringified interoperable object reference of a CORBA object' 141 EQUALITY caseIgnoreIA5Match 142 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 143 SINGLE-VALUE 144 ) 146 3.2 corbaRepositoryId 148 Each CORBA interface has a unique "repository id" (also called "type 149 id") that identifies the interface. A CORBA object has one or more 150 repository ids, one for each interface that it implements (as a 151 result of interface inheritance). 153 The format of a repository id can be any string, but the OMG 154 specifies four standard formats: 156 a. IDL-style 158 IDL:Prefix/ModuleName/InterfaceName:VersionNumber 160 For example, the repository id for the "NamingContext" in OMG's COS 161 Naming module is: "IDL:omg.org/CosNaming/NamingContext:1.0". 163 b. RMI-style 165 RMI:ClassName:HashCode[:SUID] 167 This format is used by RMI-IIOP remote objects [RMI-IIOP]. 168 "ClassName" is the fully qualified name of the class (for example, 169 "java.lang.String"). "HashCode" is the object's hash code (that is, 170 that obtained by invoking the "hashCode()" method). "SUID" is the 171 "stream unique identifier", which is a 64-bit number that uniquely 172 identifies the serialization version of the class; SUID is optional 173 in the repository id. 175 c. DCE-style 177 DCE:UUID 179 This format is used for DCE/CORBA interoperability [CORBA-DCE]. 180 "UUID" represents a DCE UUID. 182 d. "local" 184 This format is defined by the local Object Request Broker (ORB). 186 The corbaRepositoryId attribute is a multivalued attribute; each 187 value records a single repository id of an interface implemented by 188 the CORBA object. This attribute need not contain a complete list of 189 the interfaces implemented by the CORBA object. 191 This attribute's syntax is 'Directory String' and its case is 192 significant. The values of this attribute are encoded using UTF-8. 193 Some values may require translation from their native representation 194 in order to be correctly encoded using UTF-8. 196 ( 1.3.6.1.4.1.42.2.27.4.1.15 197 NAME 'corbaRepositoryId' 198 DESC 'Repository ids of interfaces implemented by a CORBA object' 199 EQUALITY caseExactMatch 200 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 201 ) 203 4 Object Class Definitions 205 The following object classes are defined in this document: 207 corbaContainer 208 corbaObject 209 corbaObjectReference 211 4.1 corbaContainer 213 This structural object class represents a container for a CORBA 214 object. 216 ( 1.3.6.1.4.1.42.2.27.4.2.10 217 NAME 'corbaContainer' 218 DESC 'Container for a CORBA object' 219 SUP top 220 STRUCTURAL 221 MUST ( cn ) 222 ) 224 4.2 corbaObject 226 This abstract object class is the root class for representing a CORBA 227 object. 229 ( 1.3.6.1.4.1.42.2.27.4.2.9 230 NAME 'corbaObject' 231 DESC 'CORBA object representation' 232 SUP top 233 ABSTRACT 234 MAY ( corbaRepositoryId $ description ) 235 ) 237 4.3 corbaObjectReference 239 This auxiliary object class represents a CORBA object reference. It 240 must be mixed in with a structural object class. 242 ( 1.3.6.1.4.1.42.2.27.4.2.11 243 NAME 'corbaObjectReference' 244 DESC 'CORBA interoperable object reference' 245 SUP corbaObject 246 AUXILIARY 247 MUST ( corbaIor ) 248 ) 250 5. Security Considerations 252 Obtaining a reference to an object and storing it in the directory 253 may make a handle to the object available to a wider audience. This 254 may have security implications. 256 6. Acknowledgements 257 We would like to thank Sanjeev Krishnan of Sun Microsystems, Simon 258 Nash of IBM, and Jeffrey Spirn of Oracle for their comments and 259 suggestions. 261 7. Copyright 263 Copyright (C) The Internet Society (1999). All Rights Reserved. 265 This document and translations of it may be copied and furnished to 266 others, and derivative works that comment on or otherwise explain it 267 or assist in its implementation may be prepared, copied, published 268 and distributed, in whole or in part, without restriction of any 269 kind, provided that the above copyright notice and this paragraph are 270 included on all such copies and derivative works. However, this 271 document itself may not be modified in any way, such as by removing 272 the copyright notice or references to the Internet Society or other 273 Internet organizations, except as needed for the purpose of 274 developing Internet standards in which case the procedures for 275 copyrights defined in the Internet Standards process must be 276 followed, or as required to translate it into languages other than 277 English. 279 The limited permissions granted above are perpetual and will not be 280 revoked by the Internet Society or its successors or assigns. 282 This document and the information contained herein is provided on an 283 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 284 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 285 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 286 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 287 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 8. References 291 [CORBA] The Object Management Group, "Common Object Request Broker 292 Architecture Specification 2.2," http://www.omg.org 294 [CORBA-DCE] Distributed Systems Technology Center and Digital 295 Equipment Corporation, "DCE/CORBA Interworking Specification," May 296 1998. 297 http://www.omg.org/library/schedule/DCE_CORBA_Interworking_RFP.html 299 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 300 Protocol (v3)," RFC-2251, December 1997. 301 http://www.ietf.org/rfc/rfc2251.txt 303 [RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over 304 IIOP," June 1999. http://java.sun.com/products/rmi-iiop/index.html 306 [v3Schema] M. Wahl, "A Summary of the X.500(96) User Schema for use 307 with LDAPv3," RFC-2256, December 1997. 308 http://www.ietf.org/rfc/rfc2256.txt 310 9. Authors' Addresses 312 Rosanna Lee 313 Sun Microsystems, Inc. 314 Mail Stop UCUP02-206 315 901 San Antonio Road 316 Palo Alto, CA 94303 317 USA 318 +1 408 863 3221 319 rosanna.lee@eng.sun.com 321 Vincent Ryan 322 Sun Microsystems, Inc. 323 Mail Stop EDUB03 324 901 San Antonio Road 325 Palo Alto, CA 94303 326 USA 327 +353 1 819 9151 328 vincent.ryan@ireland.sun.com 330 Scott Seligman 331 Sun Microsystems, Inc. 332 Mail Stop UCUP02-209 333 901 San Antonio Road 334 Palo Alto, CA 94303 335 USA 336 +1 408 863 3222 337 scott.seligman@eng.sun.com 339 10. Appendix A - LDAP Schema 341 -- Attribute types -- 343 ( 1.3.6.1.4.1.42.2.27.4.1.14 344 NAME 'corbaIor' 345 DESC 'Stringified interoperable object reference of a CORBA object' 346 EQUALITY caseIgnoreIA5Match 347 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 348 SINGLE-VALUE 350 ) 352 ( 1.3.6.1.4.1.42.2.27.4.1.15 353 NAME 'corbaRepositoryId' 354 DESC 'Repository ids of interfaces implemented by a CORBA object' 355 EQUALITY caseExactMatch 356 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 357 ) 359 -- from RFC-2256 -- 361 ( 2.5.4.13 362 NAME 'description' 363 EQUALITY caseIgnoreMatch 364 SUBSTR caseIgnoreSubstringsMatch 365 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 366 ) 368 -- Object classes -- 370 ( 1.3.6.1.4.1.42.2.27.4.2.9 371 NAME 'corbaObject' 372 DESC 'CORBA object representation' 373 SUP top 374 ABSTRACT 375 MAY ( corbaRepositoryId $ description ) 376 ) 378 ( 1.3.6.1.4.1.42.2.27.4.2.10 379 NAME 'corbaContainer' 380 DESC 'Container for a CORBA object' 381 SUP top 382 STRUCTURAL 383 MUST ( cn ) 384 ) 386 ( 1.3.6.1.4.1.42.2.27.4.2.11 387 NAME 'corbaObjectReference' 388 DESC 'CORBA interoperable object reference' 389 SUP corbaObject 390 AUXILIARY 391 MUST ( corbaIor ) 392 ) 394 -- Matching rule from ISO X.520 -- 396 ( 2.5.13.5 397 NAME 'caseExactMatch' 398 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 399 ) 401 11. Appendix B - Changes since the -01 revision 403 1. Section 2 Paragraph 1 405 Replaced: 406 `by means of the Internet Inter-ORB Protocol' 408 with: 409 `by means of the General Inter-ORB Protocol' 411 2. Section 2 Paragraph 3 413 Replaced: 414 `The object class corbaContainer represents a directory entry dedicated 415 to storing a CORBA object. It is a structural object class.' 417 with: 418 `The object class corbaContainer is used in a directory entry which 419 represents a CORBA object or object reference. It is a structural 420 object class, and when representing an object reference, the 421 corbaObjectReference object class would also need to be present 422 in the entry.' 424 3. Section 3.1 Paragraph 1 426 Added: 427 `This attribute includes, but is not limited to, the two formats 428 already defined by the OMG for an IOR: the IOR string version 429 and the URL version (in the Interoperable Naming Service).' 431 4. Section 3.2 Paragraph 1 433 Removed: 434 `for example,' 436 5. Section 3.2 Paragraph 2 438 Replaced: 439 `format of a repository' 441 with: 442 `format of a repository id' 444 6. Section 3.2 Final Paragraph 446 Added: 447 `The values of this attribute are encoded using UTF-8. Some values 448 may require translation from their native representation in order 449 to be correctly encoded using UTF-8.' 451 7. Section 4.2 and Appendix 10: 453 Replaced: 454 `MAY ( corbaRepositoryId description )' 456 with: 457 `MAY ( corbaRepositoryId $ description )'