idnits 2.17.1 draft-johnson-h350-directory-serv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1399. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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? ** Missing revision: the document name given in the document, 'draft-johnson-h350-directory-serv-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-johnson-h350-directory-serv-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-johnson-h350-directory-serv-', but the file name used is 'draft-johnson-h350-directory-serv-02' == There is 1 instance of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 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 396: '... MAY ( BillingAccount $ BillingManag...' RFC 2119 keyword, line 436: '... MAY ( BillingAccount $ BillingManag...' RFC 2119 keyword, line 488: '... MAY ( commURI )...' RFC 2119 keyword, line 540: '... MUST commUniqueId...' RFC 2119 keyword, line 541: '... MAY ( commOwner $ commPrivate )...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 2003) is 7466 days in the past. Is this intentional? -- 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LDAPv3' on line 1113 -- Looks like a reference, but probably isn't: 'SIPIdentity' on line 1114 == Unused Reference: '1' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1311, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1324, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (ref. '1') (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Duplicate reference: RFC3377, mentioned in '8', was also mentioned in '1'. -- Obsolete informational reference (is this intentional?): RFC 3377 (ref. '8') (Obsoleted by RFC 4510) Summary: 15 errors (**), 1 flaw (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft T. Johnson 2 Document: draft-johnson-h350-directory-serv- U. of North Carolina 3 02.txt 4 Category: Informational S. Okubo 5 Expires: May 2004 Waseda University 6 S.Campos 7 ITU-T 8 November 2003 10 H.350 Directory Services 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 This document may not be modified, and derivative works of it may 20 not be created, except to publish it as an RFC and to translate it 21 into languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than a "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet- Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Abstract 56 The International Telecommunications Union Standardization Sector 57 (ITU-T) has created the H.350 series of Recommendations that specify 58 directory services architectures in support of multimedia 59 conferencing protocols. The goal of the architecture is to 60 'directory enable' multimedia conferencing so that these services 61 can leverage existing identity management and enterprise 62 directories. A particular goal is to enable an enterprise or service 63 provider to maintain a canonical source of users and their 64 multimedia conferencing systems, so that multiple call servers from 65 multiple vendors, supporting multiple protocols, can all access the 66 same data store. 68 Because SIP is an IETF standard, the contents of H.350 and H.350.4 69 are made available via this document to the IETF community. This 70 document contains the entire normative text of ITU-T Recommendations 71 H.350 and H.350.4 in sections 4 and 5, respectively. The remaining 72 sections are included only in this document, not in the ITU-T 73 version. Specific differences between this text and the original 74 include: 76 1. This text contains a Security Considerations section (section 9) 77 not found in the original. 78 2. This text includes an additional reference to RFC 2798 which 79 defines inetOrgPerson and userSMIMECertificate. 80 3. This text does not contain the non-normative appendices found in 81 the original. These appendices include implementation 82 considerations and graphics for system implementers. 84 Table of Contents 86 H.350 Directory Services..........................................1 87 Status of this Memo...............................................1 88 Abstract..........................................................2 89 Table of Contents.................................................2 90 1. Scope........................................................3 91 2. Terminology..................................................4 92 3. Conventions used in this document............................4 93 4. H.350........................................................5 94 4.1. Scope......................................................5 95 4.1.1. Design Goals..............................................6 96 4.1.2. Extending the Schema......................................8 97 4.2. commURIObject Definition..................................10 98 4.2.1. commURIObject............................................10 99 4.2.2. commURI..................................................10 100 4.3. CommObject Definition.....................................11 101 4.3.1. commObject...............................................11 102 4.3.2. commUniqueId.............................................11 103 4.3.3. commOwner................................................12 104 4.3.4. commPrivate..............................................13 105 4.4. CommObject LDIF Files.....................................13 106 4.4.1. LDIF for commURIObject...................................13 107 4.4.2. LDIF for commObject......................................15 108 4.5. H.350 Annex A Indexing Profile............................17 109 5. H.350.4.....................................................17 110 5.1. Scope.....................................................17 111 5.1.1. Extending the schema.....................................18 112 5.2. Object class definitions..................................18 113 5.2.1. SIPIdentity..............................................18 114 5.2.2. SIPIdentitySIPURI........................................18 115 5.2.3. SIPIdentityRegistrarAddress..............................19 116 5.2.4. SIPIdentityProxyAddress..................................20 117 5.2.5. SIPIdentityAddress.......................................20 118 5.2.6. SIPIdentityPassword......................................21 119 5.2.7. SIPIdentityUserName......................................21 120 5.2.8. SIPIdentityServiceLevel..................................22 121 5.3. SIPIdentity LDIF Files....................................23 122 5.4. H.350.4 Annex A Indexing profile..........................25 123 6. Acknowledgments.............................................26 124 7. Normative References........................................26 125 8. Informative References......................................27 126 9. Security Considerations.....................................27 127 10. Contact Information.........................................28 129 1. Scope 130 The International Telecommunications Union Standardization Sector 131 (ITU-T) has created the H.350 series of Recommendations that specify 132 directory services architectures in support of multimedia 133 conferencing protocols. The goal of the architecture is to 134 'directory enable' multimedia conferencing so that these services 135 can leverage existing identity management and enterprise 136 directories. A particular goal is to enable an enterprise or service 137 provider to maintain a canonical source of users and their 138 multimedia conferencing systems, so that multiple call servers from 139 multiple vendors, supporting multiple protocols, can all access the 140 same data store. 142 H.350 architectures are not intended to change the operation of 143 multimedia conferencing protocols in any way. Rather, they are meant 144 to standardize the way the already defined protocol elements are 145 stored in a directory, so that they can be accessed in a 146 standardized manner. 148 In the H.350 series, Recommendation H.350 specifies the base 149 architecture and object classes, while subordinate Recommendations 150 specify elements that are specific to individual protocols. 151 Currently, the Recommendations include: 153 H.350 � Directory Services Architecture for Multimedia Conferencing 154 H.350.1 - Directory Services Architecture for H.323 155 H.350.2 - Directory Services Architecture for H.235 156 H.350.3 - Directory Services Architecture for H.320 157 H.350.4 - Directory Services Architecture for SIP 158 H.350.5 - Directory Services Architecture for Non-Standard Protocols 160 Because SIP is an IETF standard, the contents of H.350 and H.350.4 161 are made available via this document to the IETF community. 163 2. Terminology 165 The following terms are used throughout the document: 167 * call server: a protocol-specific signalling engine that routes 168 video or voice calls on the network. In H.323 this entity is a 169 gatekeeper. In SIP, this entity is a SIP Proxy Server. Note that 170 not all signalling protocols use a call server. 172 * endpoint: a logical device that provides video and/or voice media 173 encoding/decoding, and signalling functions. Examples include: 175 * a group teleconferencing appliance that is located in a 176 conference room 177 * an IP telephone. 178 * a software program that takes video and voice from a camera 179 and microphone and encodes it and applies signalling using a 180 host computer. 182 * enterprise directory: A canonical collection of information about 183 users in an organization. Typically this information is collected 184 from a variety of organizational units to create a whole. For 185 example, Human Resources may provide name and address, 186 Telecommunications may provide the telephone number, Information 187 Technology may provide the email address, etc. For the purposes 188 of this architecture, it is assumed that an enterprise directory 189 is accessible via LDAP. 191 * White Pages: An application that allows end users to look up the 192 address of another user. This may be web-based or use some other 193 user interface. 195 3. Conventions used in this document 197 Conventions in this document conform to ITU-T guidelines. In this 198 Recommendation, the following conventions are used: 200 "Shall" indicates a mandatory requirement. 202 "Should" indicates a suggested but optional course of action. 204 "May" indicates an optional course of action rather than a 205 recommendation that something take place. 207 References to clauses, sub clauses, annexes and appendices refer to 208 those items within this Recommendation unless another specification 209 is explicitly listed. 211 4. H.350 213 The normative text of H.350 is reproduced in this section. 215 4.1. Scope 217 This Recommendation describes a directory services architecture for 218 multimedia conferencing using LDAP. Standardized directory services 219 can support association of persons with endpoints, searchable white 220 pages, and clickable dialling. Directory services can also assist in 221 the configuration of endpoints, and user authentication based on 222 authoritative data sources. This document describes a standardized 223 LDAP schema to represent endpoints on the network and associate 224 those endpoints with users. It discusses design and implementation 225 considerations for the inter-relation of video and voice-specific 226 directories, enterprise directories, call servers and endpoints. 228 The use of a common, authoritative data source for call server, 229 endpoint, user, authentication and white pages information is an 230 important aspect of large scale multimedia conferencing 231 environments. Without a common data source, service providers must 232 create separate processes to manage each of these functions. By 233 standardizing the LDAP schema used to represent the underlying data, 234 products from different system vendors can be deployed together to 235 create an overall application environment. For example, a white 236 pages search engine developed by one provider could serve directory 237 information to IP telephones produced by a second provider, with 238 signalling managed by a call server produced by yet a third 239 provider. Each of these disparate systems can access the same 240 underlying data source, reducing or eliminating the need to 241 coordinate separate management of each system. A significant benefit 242 to the user is that the management of this data can be incorporated 243 into existing customer management tools, allowing for quick and 244 flexible scaling up of applications. Indeed, many technology 245 providers have already incorporate LDAP into their products, but 246 have been forced to do so without benefit of a standardized schema. 247 This Recommendation represents an effort to standardize those 248 representations to improve interoperability and performance. 250 While URLs are already standardized for several conferencing 251 protocols, their representation in a directory is not. This 252 Recommendation supports a standardized way for URLs to be searched 253 and located. This is a necessary step to support 'clickable 254 dialling'. 256 Management of endpoint configurations can be improved if the correct 257 settings are stored by the service provider in a location that is 258 accessible to both service provider and endpoint. LDAP provides a 259 convenient storage location that can be accessed by both call server 260 and endpoint; thus it is possible to use the directory to support 261 endpoint configuration, which is important for simplified operation 262 and supporting user mobility. Note that other technologies also 263 support endpoint configuration, notably the use of SNMP for complete 264 configuration and SRV records for obtaining registration server 265 addresses. Therefore, H.350 should be viewed not as an authoritative 266 endpoint configuration architecture, but rather one tool that can 267 assist with this task. Note that the use of H.350 has as a feature 268 endpoint specific configuration, where it is desirable that each 269 endpoint has a unique configuration. 271 This architecture uses a generic object class, called commObject, to 272 represent attributes common to any video or voice protocol. 273 Auxiliary classes represent specific protocols, such as H.323, 274 H.235, or H.320, as described in the H.350.x series of 275 Recommendations. Multiple H.350.x classes can be combined to 276 represent endpoints that support more than one protocol. For 277 example, endpoints that support H.323, H.235 and H.320 would include 278 H.350, H.350.1, H.350.2, and H.350.3 in their LDAP representations. 279 Further, each entry should contain commObject to serve as the 280 entry's structural object class. 282 There are two basic components in the architecture. The commURI 283 object is a class whose only purpose is to link a person or resource 284 to a commObject. By placing a commURI 'pointer' in an individual's 285 directory entry, that individual becomes associated with the 286 particular targeted commObject. Similarly, commObject contains a 287 pointer, called commOwner, which points to the individual or 288 resource that is associated with the commObject. In this way, people 289 or resources can be associated with endpoints. The only change 290 required in the enterprise directory is the addition of the simple 291 object class commURI. CommObject data may be instantiated in the 292 same or in entirely separate directories, thus allowing flexibility 293 in implementation. 295 4.1.1. Design Goals 297 Large-scale deployments of IP video and voice services have 298 demonstrated the need for complementary directory services 299 middleware. Service administrators need call servers that are aware 300 of enterprise directories to avoid duplication of account management 301 processes. Users need 'white pages' to locate other users with whom 302 they wish to communicate. All of these processes should pull their 303 information from canonical data sources in order to reduce redundant 304 administrative processes and ensure information accuracy. The 305 following design criteria are established for this architecture. The 306 architecture will: 308 1) enable endpoint information to be associated with people. 309 Alternately it enables endpoint information to be associated with 310 resources such as conference rooms or classrooms; 312 2) enable online searchable "white pages" where dialling 313 information (e.g. endpoint addresses) can be found, along with other 314 "traditional" directory information about a user, such as name, 315 address, telephone, email, etc.; 317 3) enable all endpoint information to be stored in a canonical 318 data source (the Directory), rather than local to the call server, 319 so that endpoints can be managed through manipulations of an 320 enterprise directory, rather than by direct entry into the call 321 server; 323 4) support the creation of very large-scale distributed 324 directories. These include white pages "portals" that allow 325 searching for users across multiple institutional directories. In 326 this application, each enterprise directory registers itself with 327 (or is unknowingly discovered by) a directory of directories that is 328 capable of searching across multiple LDAP directories; 330 5) be able to support multiple instances of endpoints per user or 331 resource; 333 6) represent endpoints that support more than one protocol, for 334 example, endpoints that are both H.320 and H.323; 336 7) store enough information about endpoint configuration so that 337 correct configuration settings can be documented to end users on a 338 per-endpoint basis, as a support tool, or loaded automatically into 339 the endpoint; 341 8) be extendable as necessary to allow implementation-specific 342 attributes to be included; 344 9) be non-invasive to the enterprise directory, so that support 345 for multimedia conferencing can be added in a modular fashion 346 without significant changes to the enterprise directory. 348 The scope of this Recommendation does not include extensions of 349 functionality to protocols as defined within the protocols 350 themselves. It is not the intent of the Recommendation to add 351 features, but merely to represent existing protocol attributes. The 352 exception to this case is when functionality is implied by the 353 directory itself, such as the commPrivate attribute. 355 4.1.2. Extending the Schema 357 H.350 object classes may be extended as necessary for specific 358 implementations. For example, a class may be extended to support 359 billing reference codes. Extensions to the schema are not considered 360 as part of the Recommendation and do not signify compliance. 362 In some cases it may be necessary to extend the H.350 schemas in 363 order to represent more information than is supported by the 364 Recommendations. This may be important for developers that implement 365 proprietary endpoint functionality that needs to be represented by 366 attributes in the directory. It may also be important for enterprise 367 applications. For example 'modelNumber', and 'accountNumber' are 368 examples of attributes that are not defined in the Recommendation 369 but may be useful if implemented. Adding attributes to this 370 architecture must be done in a way that does not break compatibility 371 with this Recommendation. 373 A full discussion of schema design and extension is beyond the scope 374 of this Recommendation. See IETF RFC 2252 for details. Two basic 375 approaches to schema extension that do not break compatibility with 376 this Recommendation, are extension through subclass and extension 377 through the use of auxiliary classes. 379 4.1.2.1. Extension Through Subclass 381 It is possible to create a subclass of an existing predefined object 382 class in order to add new attributes to it. To create a subclass, a 383 new object class must be defined, that is a subclass of the existing 384 one, by indicating in the definition of the new class that the 385 existing class is its superior. Once the subclass is created, new 386 attributes can be defined within it. 388 The following example shows how the commObject class can be 389 subclassed in order to add an attribute to represent a billing 390 account and a billing manager. 392 objectclass ( BillingInfo-OID 393 NAME 'BillingInfo' 394 DESC 'Billing Reference Information' 395 SUP commObject STRUCTURAL 396 MAY ( BillingAccount $ BillingManager $ ) 397 ) 398 Note that BillingInfo-OID must be replaced by an actual OID. Also 399 note that, whenever a structural class is extended, its subclass 400 must also be structural. 402 The following sample entry shows the newly created attributes. This 403 example also uses ITU-T Rec. H.350.1 for h323Identity. 405 dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com 406 objectclass: top 407 objectclass: commObject 408 objectclass: h323Identity 409 objectclass: BillingInfo 410 commUniqueId: 2000 411 BillingAccount: 0023456 412 BillingManager: John Smith 414 Note that this example and approach demonstrate extension of the 415 general commObject object class, and not any individual H.350.x 416 classes. If it is desired to extend an H.350.x auxiliary class, then 417 that should be accomplished through the definition of additional 418 auxiliary classes that support the desired attributes, as described 419 in section 4.1.2.2. 421 4.1.2.2. Extension Through The Use Of Auxiliary Classes 423 It is possible to add attributes to an LDAP entry by defining an 424 auxiliary class containing the new attributes and applying those 425 attributes to instantiated values in the directory. The auxiliary 426 class will not be subclassed from any existing object class. Note 427 that it should have the special class top as its superior. The 428 following example creates the same billing account and billing 429 manager attributes as the previous example, but does so by defining 430 them in their own auxiliary class. 432 objectclass ( BillingInfo-OID 433 NAME 'BillingInfo' 434 DESC 'Billing Reference Information' 435 SUP top AUXILIARY 436 MAY ( BillingAccount $ BillingManager $ ) 437 ) 439 Note how the superior was changed from commObject to top and the 440 object class changed from being a structural to auxiliary. 442 It is recommended that all attributes in the auxiliary class be 443 optional rather than mandatory. In this way, the auxiliary object 444 class itself can be associated with an entry regardless of whether 445 any values for its attributes are present. 447 The following example shows a sample endpoint that utilizes the new 448 auxiliary class and attributes. This example also uses H.350.1 for 449 h323Identity. 451 dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com 452 objectclass: top 453 objectclass: commObject 454 objectclass: BillingInfo 455 commUniqueId: 2000 456 BillingAccount: 0023456 457 BillingManager: John Smith 459 4.1.2.3. Object Identifiers 461 An attribute's Object Identifier (OID) is a unique numerical 462 identifier usually written as a sequence of integers separated by 463 dots. For example, the OID for the commUniqueId is 464 0.0.8.350.1.1.2.1.1. All attributes must have an OID. OIDs can be 465 obtained from anyone who has one and is willing to delegate a 466 portion of it as an arc, keeping a record of the arc to avoid 467 duplication. Further, the Internet Assigned Numbers Authority (IANA) 468 gives out OIDs to any organization that asks. 470 4.2. commURIObject Definition 472 Auxiliary object class that contains the commURI attribute. This 473 attribute is added to a person or resource object to associate one 474 or more commObject instances with that object. Its values are LDAP 475 URIs that point to the associated commObjects, for example, to a 476 user's H.323 conferencing station and SIP IP phone. Note that 477 multiple instances of commURI need not point to the same commObject 478 directory. In fact, each commURI instance could point to an endpoint 479 managed by a different service provider. 481 4.2.1. commURIObject 483 OID: 0.0.8.350.1.1.1.2.1 484 objectclasses: (0.0.8.350.1.1.1.2.1 485 NAME 'commURIObject' 486 DESC 'object that contains the URI attribute type' 487 SUP top AUXILIARY 488 MAY ( commURI ) 489 ) 491 4.2.2. commURI 493 OID: 0.0.8.350.1.1.1.1.1 494 attributetypes:( 0.0.8.350.1.1.1.1.1 495 NAME 'commURI' 496 DESC 'Labeled URI format to point to the distinguished name of the 497 commUniqueId' 498 EQUALITY caseExactMatch 499 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 500 Application utility class 501 Standard 502 Number of values 503 multi 504 Definition 505 Labelled URI containing an LDAP URL identifying the directory 506 containing the referenced commObject instance. The search filter 507 specified by this LDAP URL shall specify an equality search of the 508 commUniqueId attribute of the commObject class. 509 Permissible values (if controlled) 510 Notes 511 Used to find the endpoint of the user in question. The label 512 field may be used to represent the function of the endpoint, such as 513 'home IP phone' or 'desktop video' for user interface display 514 purposes. 515 Note that the label portion of the field may contain spaces as 516 in the example below showing 'desktop video'. 517 Semantics 518 Example applications for which this attribute would be useful 519 Example (LDIF fragment) 520 commURI: 521 ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob) 522 desktop video 524 4.3. CommObject Definition 526 Abstraction of video or voice over IP device. The commObject class 527 permits an endpoint (H.323 endpoint or SIP user agent or other 528 protocol endpoint) and all their aliases to be represented by a 529 single entry in a directory. Note that every directory entry should 530 contain commObject as the entry's structural object class. That 531 entry may also contain H.350.x auxiliary classes. 533 4.3.1. commObject 535 OID: 0.0.8.350.1.1.2.2.1 536 objectclasses: (0.0.8.350.1.1.2.2.1 537 NAME 'commObject' 538 DESC 'object that contains the Communication attributes' 539 SUP top STRUCTURAL 540 MUST commUniqueId 541 MAY ( commOwner $ commPrivate ) 542 ) 544 4.3.2. commUniqueId 545 OID: 0.0.8.350.1.1.2.1.1 546 attributetypes: (0.0.8.350.1.1.2.1.1 547 NAME 'commUniqueId' 548 DESC 'To hold the endpoints unique Id' 549 EQUALITY caseIgnoreIA5Match 550 SUBSTR caseIgnoreIA5SubstringsMatch 551 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 552 Application utility class 553 standard 554 Number of values 555 multi 556 Definition 557 The endpoint's unique ID. 558 Permissible values (if controlled) 559 Notes 560 This is the RDN of this object. In practice, there will always 561 be one and only one commUniqueId for every endpoint. This attribute 562 uniquely identifies an endpoint in the commObject directory. It must 563 be unique within that directory, but need not be unique globally. 564 This attribute has no relationship to the enterprise directory. 565 Semantics 566 Example applications for which this attribute would be useful 567 Example (LDIF fragment) 568 commUniqueId: bob 570 4.3.3. commOwner 572 OID: 0.0.8.350.1.1.2.1.2 573 attributetypes: 0.0.8.350.1.1.2.1.2 574 NAME 'commOwner' 575 DESC 'Labeled URI to point back to the original owner' 576 EQUALITY caseExactMatch 577 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 578 Application utility class 579 Standard 580 Number of values 581 multi 582 Definition 583 Labelled URI format to point back to the person or resource 584 object associated with this entry. 585 Permissible values (if controlled) 586 Notes 587 Used as a reverse entry finder of the owner(s). This attribute 588 may point to groups. Note that this URI can point to a cn, but in 589 applications where it is desired to bind authentication information 590 across both the commObject and enterprise directories, it may be 591 desirable that commOwner points to a dn rather than a cn, thus 592 uniquely identifying the owner of the commObject. 593 Semantics 594 Example applications for which this attribute would be useful 595 Example (LDIF fragment) 596 commOwner: 597 ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith) 598 commOwner: uid=bob,ou=people,dc=acme,dc=com 600 4.3.4. commPrivate 602 OID: 0.0.8.350.1.1.2.1.3 603 attributetypes: (0.0.8.350.1.1.2.1.3 604 NAME 'commPrivate' 605 DESC 'To decide whether the entry is visible to world or not' 606 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 607 Application utility class 608 Standard 609 Number of values 610 multi 611 Definition 612 To be used by the user and indicate privacy options for an 613 endpoint, i.e. unlisted number. 614 Permissible values (if controlled) 615 Notes 616 This attribute is defined as Boolean. Future version of this 617 Recommendation may develop a controlled vocabulary for this 618 attribute to accommodate multiple types of privacy. 619 Semantics 620 Example applications for which this attribute would be useful 621 Example (LDIF fragment) 622 commPrivate: true 624 4.4. CommObject LDIF Files 626 This section contains a schema configuration file for commURIObject 627 and commObject that can be used to configure an LDAP server to 628 support these classes. 630 4.4.1. LDIF for commURIObject 632 # Communication Object Schema 633 # 634 # Schema for Representing Communication Objects in an LDAP Directory 635 # 636 # Abstract 637 # 638 # This document defines the schema for representing Communication 639 # objects in an LDAP directory [LDAPv3]. It defines schema elements 640 # to represent a communication object URI [commURIObject]. 641 # 642 # 643 # 644 # .1 = Communication related work 645 # .1.1 = commURIObject 646 # .1.1.1 = attributes 647 # .1.1.2 = objectclass 648 # .1.1.3 = syntax 649 # 650 # Attribute Type Definitions 651 # 652 # The following attribute types are defined in this document: 653 # 654 # commURI 655 dn: cn=schema 656 changetype: modify 657 # 658 # if you need to change the definition of an attribute, 659 # then first delete and re-add in one step 660 # 661 # if this is the first time you are adding the commObject 662 # objectclass using this LDIF file, then you should comment 663 # out the delete attributetypes modification since this will 664 # fail. Alternatively, if your ldapmodify has a switch to continue 665 # on errors, then just use that switch -- if you're careful 666 # 667 delete: attributetypes 668 attributetypes: (0.0.8.350.1.1.1.1.1 NAME 'commURI' ) 669 - 670 # 671 # re-add the attributes -- in case there is a change of definition 672 # 673 # 674 add: attributetypes 675 attributetypes: (0.0.8.350.1.1.1.1.1 676 NAME 'commURI' 677 DESC 'Labeled URI format to point to the distinguished name of 678 the commUniqueId' 679 EQUALITY caseExactMatch 680 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 681 - 682 # Object Class Definitions 683 # 684 # The following object classes are defined in this document: 685 # 686 # commURIObject 687 # 688 # commURIObject 689 # 690 # This auxiliary object class represents a URI attribute type 691 # 692 # 693 delete: objectclasses 694 objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' ) 695 - 696 add: objectclasses 697 objectclasses: (0.0.8.350.1.1.1.2.1 698 NAME 'commURIObject' 699 DESC 'object that contains the URI attribute type' 700 SUP top AUXILIARY 701 MAY ( commURI ) 702 ) 703 - 704 # 705 # end of LDIF 706 # 708 4.4.2. LDIF for commObject 710 # Communication Object Schema 711 # 712 # Schema for Representing Communication Objects in an LDAP Directory 713 # 714 # Abstract 715 # 716 # This document defines the schema for representing Communication 717 # objects in an LDAP directory [LDAPv3]. It defines schema elements 718 # to represent a communication object [commObject]. 719 # 720 # 721 # .1 = Communication related work 722 # .1.2 = commObject 723 # .1.2.1 = attributes 724 # .1.2.2 = objectclass 725 # .1.2.3 = syntax 726 # 727 # 728 # Attribute Type Definitions 729 # 730 # The following attribute types are defined in this document: 731 # 732 # commUniqueId 733 # commOwner 734 # commPrivate 735 dn: cn=schema 736 changetype: modify 737 # 738 # if you need to change the definition of an attribute, 739 # then first delete and re-add in one step 740 # 741 # if this is the first time you are adding the commObject 742 # objectclass using this LDIF file, then you should comment 743 # out the delete attributetypes modification since this will 744 # fail. Alternatively, if your ldapmodify has a switch to continue 745 # on errors, then just use that switch -- if you're careful 746 # 747 delete: attributetypes 748 attributetypes: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' ) 749 attributetypes: (0.0.8.350.1.1.2.1.2 NAME 'commOwner' ) 750 attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' ) 751 - 752 # 753 # re-add the attributes -- in case there is a change of definition 754 # 755 # 756 add: attributetypes 757 attributetypes: (0.0.8.350.1.1.2.1.1 758 NAME 'commUniqueId' 759 DESC 'To hold the endpoints unique Id' 760 EQUALITY caseIgnoreIA5Match 761 SUBSTR caseIgnoreIA5SubstringsMatch 762 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 763 attributetypes: (0.0.8.350.1.1.2.1.2 764 NAME 'commOwner' 765 DESC 'Labeled URI to point back to the original owner' 766 EQUALITY caseExactMatch 767 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 768 attributetypes: (0.0.8.350.1.1.2.1.3 769 NAME 'commPrivate' 770 DESC 'To decide whether the entry is visible to world or not' 771 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 772 - 773 # Object Class Definitions 774 # 775 # The following object classes are defined in this document: 776 # 777 # commObject 778 # 779 # commObject 780 # 781 # 782 delete: objectclasses 783 objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' ) 784 - 785 add: objectclasses 786 objectclasses: (0.0.8.350.1.1.2.2.1 787 NAME 'commObject' 788 DESC 'object that contains the Communication attributes' 789 SUP top STRUCTURAL 790 MUST commUniqueId 791 MAY ( commOwner $ commPrivate ) 792 ) 793 - 794 # 795 # end of LDIF 796 # 798 4.5. H.350 Annex A Indexing Profile 800 Indexing of attributes is an implementation-specific activity and 801 depends upon the desired application. Non-indexed attributes can 802 result in search times sufficiently long to render some applications 803 unusable. Notably, user and alias lookup should be fast. The Annex A 804 Indexing Profile describes an indexing configuration for commObject 805 directories that will be optimized for use in directory of 806 directories applications. Use of this profile is optional. 808 commURI: no recommendation 810 commUniqueId: equality 812 commOwner: presence 814 commPrivate: presence 816 5. H.350.4 818 The normative text of H.350 is reproduced in this section. 820 5.1. Scope 822 This Recommendation describes an LDAP directory services 823 architecture for multimedia conferencing using SIP. In particular, 824 it defines an LDAP schema to represent SIP User Agents (UAs) on the 825 network and associate those endpoints with users. 827 This Recommendation is intended to supplement the CommObject 828 directory architecture as discussed in ITU-T Rec. H.350, and not 829 intended to be used as a stand-alone architecture. The 830 implementation of this LDAP schema, together with the use of the 831 H.350 CommObject architecture, facilitates the integration of SIP 832 User Agents and conferencing devices into existing Enterprise 833 Directories, thus allowing the user to perform white page lookups 834 and access clickable dialling supported by SIP devices. The primary 835 reasons for implementing this schema include those listed in ITU-T 836 Rec. H.350 (the CommObject class definition) as they apply 837 specifically to the use of SIP UAs, and to facilitate vendors making 838 SIP services more readily available to their users. 840 The scope of this Recommendation includes recommendations for the 841 architecture to integrate endpoint information for endpoints using 842 SIP into existing enterprise directories and white pages. 844 The scope of this Recommendation does not include normative methods 845 for the use of the LDAP directory itself or the data it contains. 846 The purpose of the schema is not to represent all possible data 847 elements in the SIP protocol, but rather to represent the minimal 848 set required to accomplish the design goals enumerated in ITU-T Rec. 849 H.350. 851 Note that SIP provides well-defined methods for discovering 852 registrar addresses and locating users on the network. Some of the 853 attributes defined here are intended for more trivial or manual 854 implementations and may not be needed for all applications. For 855 example, SIPIdentityRegistrarAddress and SIPIdentityAddress may not 856 be needed for many applications, but are included here for 857 completeness. Thus, SIPIdentitySIPURI is the primary attribute of 858 interest that will be served out, especially for white page 859 directory applications. 861 5.1.1. Extending the schema 863 The SIPIdentity classes may be extended as necessary for specific 864 implementations. See the base of ITU-T Rec. H.350 for a discussion 865 on schema extension. 867 5.2. Object class definitions 869 The SIPIdentity object class represents SIP User Agents (UAs). It is 870 an auxiliary class and is derived from the commObject class, which 871 is defined in the ITU-T Rec. H.350. 873 5.2.1. SIPIdentity 875 OID: 0.0.8.350.1.1.6.2.1 876 objectclasses: (0.0.8.350.1.1.6.2.1 877 NAME 'SIPIdentity' 878 DESC 'SIPIdentity object' 879 SUP top AUXILIARY 880 MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ 881 SIPIdentityProxyAddress $ SIPIdentityUserName $ 882 SIPIdentityPassword $ SIPIdentityServiceLevel $ 883 userSMIMECertificate ) 884 ) 886 5.2.2. SIPIdentitySIPURI 888 OID: 0.0.8.350.1.1.6.1.1 889 attributetypes: (0.0.8.350.1.1.6.1.1 890 NAME 'SIPIdentitySIPURI' 891 DESC 'Universal Resource Indicator of the SIP UA' 892 EQUALITY caseExactMatch 893 SUBSTR caseExactSubstringsMatch 894 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 895 Application utility class 896 standard 897 Number of values 898 multi 899 Definition 900 Uniform Resource Identifier that identifies a communication 901 resource in SIP. Usually contains a user name and a host name and is 902 often similar in format to an email address. 903 Permissible values (if controlled) 904 Notes 905 This URI may institute SIP or SIPS (secure). In the event that 906 SIPS is instituted, the URI must reflect that it is using SIPS as 907 opposed to SIP. See Examples below. 908 Semantics 909 Example applications for which this attribute would be useful 910 Online representation of most current listing of a user's 911 SIP(S) UA. 912 Example 913 SIPIdentitySIPURI: sip:alice@foo.com // SIP example 914 SIPIdentitySIPURI: sip:alice@152.2.158.212 // SIP example 915 SIPIdentitySIPURI: sips:bob@birmingham.edu // SIPS example 917 5.2.3. SIPIdentityRegistrarAddress 919 OID: 0.0.8.350.1.1.6.1.2 920 attributetypes: (0.0.8.350.1.1.6.1.2 921 NAME 'SIPIdentityRegistrarAddress' 922 DESC 'specifies the location of the registrar' 923 EQUALITY caseIgnoreIA5Match 924 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 925 Application utility class 926 Standard 927 Number of values 928 multi 929 Definition 930 Address for the domain to which the server that handles 931 REGISTER requests and forwarding to the location server for a 932 particular domain belongs. 933 Permissible values (if controlled) 934 Notes 935 Note that RFC 3261 states that user agents can discover their 936 registrar address by configuration, using the address-of-record, or 937 by multicast. The first scenario, by configuration, is noted as out 938 of scope for RC 3261. This attribute may be used for the first 939 scenario. It can be accomplished manually, (e.g. a web page that 940 displays a user's correct registrar address) or automatically with 941 an H.350.4 aware user agent. 942 Semantics 943 Example applications for which this attribute would be useful 944 white pages, a web page that displays a user's correct 945 configuration information. 946 Example (LDIF fragment) 947 SIPIdentityRegistrarAddress: 152.2.15.22 //IP address example 948 SIPIdentityRegistrarAddress: sipregistrar.unc.edu //FQDN example 950 5.2.4. SIPIdentityProxyAddress 952 OID: 0.0.8.350.1.1.6.1.3 953 attributetypes: (0.0.8.350.1.1.6.1.3 954 NAME 'SIPIdentityProxyAddress' 955 DESC 'Specifies the location of the SIP Proxy' 956 EQUALITY caseIgnoreIA5Match 957 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 958 Application utility class 959 Standard 960 Number of values 961 multi 962 Definition 963 Address which specifies the domain location of SIP proxy within 964 a domain. RFC 3261 defines the role of the SIP proxy. 965 Permissible values (if controlled) 966 Notes 967 SIP User Agents are not REQUIRED to use a proxy, but will in 968 many cases. 969 Semantics 970 Example applications for which this attribute would be useful 971 white pages, a web page that displays a user's correct 972 configuration information. 973 Example (LDIF fragment) 974 SIPIdentityProxyAddress: 172.2.13.234 //IP address example 975 SIPIdentityProxyAddress: sipproxy.unc.edu //FQDN example 977 5.2.5. SIPIdentityAddress 979 OID: 0.0.8.350.1.1.6.1.4 980 attributetypes: (0.0.8.350.1.1.6.1.4 981 NAME 'SIPIdentityAddress' 982 DESC 'IP address or FQDN of the UA' 983 EQUALITY caseIgnoreIA5Match 984 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 985 Application utility class 986 standard 987 Number of values 988 multi 989 Definition 990 Specifies the IP address or fully qualified domain name of the 991 UA. 992 Permissible values (if controlled) 993 Notes 994 This attribute may be useful for applications in which UA to UA 995 communication is direct, not involving a proxy or registrar. 996 Example applications for which this attribute would be useful 997 A web page that displays a user's proper user agent 998 configuration information. 999 Example (LDIF fragment) 1000 SIPIdentityAddress: 152.2.121.36 // IP address example 1001 SIPIdentityAddress: ipPhone.foo.org // FQDN example 1003 5.2.6. SIPIdentityPassword 1005 OID: 0.0.8.350.1.1.6.1.5 1006 attributetypes: (0.0.8.350.1.1.6.1.5 1007 NAME 'SIPIdentityPassword' 1008 DESC 'The user agent SIP password ' 1009 EQUALITY octetStringMatch 1010 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1011 Application utility class 1012 Standard 1013 Number of values 1014 multi 1015 Definition 1016 The SIP user agent's password, used for the HTTP digest 1017 authentication scheme as defined in RFC 2617. 1018 Permissible values (if controlled) 1019 Notes 1020 Because RFC 2069, which was made obsolete by RFC 2617, was used 1021 as the basis for HTTP Digest in RFC 2543, any SIP servers supporting 1022 RFC 2617 must ensure backward compatibility with RFC 2069. 1023 This SIPIdentityUserName, together with SIPIdentityPassword, 1024 are reserved for the purpose of use with Digest Access 1025 Authentication, and not intended for use with Basic Authentication 1026 methods. 1027 LDAP provides one method to store user passwords for reference. 1028 If passwords are stored in LDAP it makes the LDAP server a 1029 particularly valuable target for attack. Implementors are encouraged 1030 to exercise caution and implement appropriate security procedures 1031 such as encryption, access control, and transport layer security for 1032 access to this attribute. 1033 Semantics 1034 Example applications for which this attribute would be useful 1035 Example (LDIF fragment) 1036 SIPIdentityPassword: 36zxJmCIB18dM0FVAj 1038 5.2.7. SIPIdentityUserName 1040 OID: 0.0.8.350.1.1.6.1.6 1041 attributetypes: (0.0.8.350.1.1.6.1.6 1042 NAME 'SIPIdentityUserName' 1043 DESC 'The user agent user name.' 1044 EQUALITY caseIgnoreMatch 1045 SUBSTR caseIgnoreSubstringsMatch 1046 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1047 Application utility class 1048 Standard 1049 Number of values 1050 multi 1051 Definition 1052 The SIP user agent's user name, used for the HTTP digest 1053 authentication scheme as defined in RFC 2617. 1054 Permissible values (if controlled) 1055 Notes 1056 Because RFC 2069, which was made obsolete by RFC 2617, was used 1057 as the basis for HTTP Digest Authentication in RFC 2543, any SIP 1058 servers supporting HTTP Digest Authentication as defined in RFC 2617 1059 must ensure backward compatibility with RFC 2069. 1060 This SIPIdentityUserName, together with SIPIdentityPassword, 1061 are reserved for the purpose of use with Digest Access 1062 Authentication, and not intended for use with Basic Authentication 1063 methods. 1064 Note that in many cases the user name will be parsed from the 1065 user@proxy.domain portion of the SIP URI. In that case it may not be 1066 necessary to populate this attribute. 1067 Semantics 1068 Example applications for which this attribute would be useful 1069 Example (LDIF fragment) 1070 SIPIdentityUserName: nelkhour 1072 5.2.8. SIPIdentityServiceLevel 1074 OID: 0.0.8.350.1.1.6.1.7 1075 attributetypes: (0.0.8.350.1.1.6.1.7 1076 NAME 'SIPIdentityServiceLevel' 1077 DESC 'To define services that a user can belong to.' 1078 EQUALITY caseIgnoreIA5Match 1079 SUBSTR caseIgnoreIA5SubstringsMatch 1080 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1081 Application utility class 1082 Standard 1083 Number of values 1084 multi 1085 Definition 1086 This describes the level of services a user can belong to. 1087 Permissible values (if controlled) 1088 Notes 1089 This attribute does not represent a data element found in SIP. 1090 SIP itself does not support distinctions in service levels. Instead, 1091 this attribute provides a mechanism for the storage of service level 1092 information directly in LDAP. This mapping allows service providers 1093 to adapt to an existing LDAP directory without changing the values 1094 of the SIPIdentityServiceLevel instances in the directory. 1095 Semantics 1096 Example applications for which this attribute would be useful 1097 Example (LDIF fragment) 1098 SIPIdentityServiceLevel: premium 1100 5.3. SIPIdentity LDIF Files 1102 This clause contains a schema configuration file for SIPIdentity 1103 that can be used to configure an LDAP server to support this class. 1105 # SIPIdentity Object Schema 1106 # 1107 # Schema for representing SIPIdentity Object in an LDAP Directory 1108 # 1109 # Abstract 1110 # 1111 # This Recommendation defines the schema for representing 1112 SIPIdentity 1113 # object in an LDAP directory [LDAPv3]. It defines schema elements 1114 # to represent an SIPIdentity object [SIPIdentity]. 1115 # 1116 # .1 = Communication related work 1117 # .1.6 = SIPIdentity 1118 # .1.6.1 = attributes 1119 # .1.6.2 = objectclass 1120 # .1.6.3 = syntax 1121 # 1122 # 1123 # 1124 # Attribute Type Definitions 1125 # 1126 # The following attribute types are defined in this 1127 Recommendation: 1128 # 1129 # SIPIdentitySIPURI 1130 # SIPIdentityRegistrarAddress 1131 # SIPIdentityProxyAddress 1132 # SIPIdentityAddress 1133 # SIPIdentityPassword 1134 # SIPIdentityUserName 1135 # SIPIdentityServiceLevel 1136 dn: cn=schema 1137 changetype: modify 1138 # 1139 # if you need to change the definition of an attribute, 1140 # then first delete and re-add in one step 1141 # 1142 # if this is the first time you are adding the SIPIdentity 1143 # objectclass using this LDIF file, then you should comment 1144 # out the delete attributetypes modification since this will 1145 # fail. Alternatively, if your ldapmodify has a switch to continue 1146 # on errors, then just use that switch -- if you are careful 1147 # 1148 delete: attributetypes 1149 attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' ) 1150 attributetypes: (0.0.8.350.1.1.6.1.2 NAME 1151 'SIPIdentityRegistrarAddress' ) 1152 attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' 1153 ) 1154 attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' ) 1155 attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' ) 1156 attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' ) 1157 attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' 1158 ) 1159 - 1160 # 1161 # re-add the attributes -- in case there is a change of definition 1162 # 1163 # 1164 add: attributetypes 1165 attributetypes: (0.0.8.350.1.1.6.1.1 1166 NAME 'SIPIdentitySIPURI' 1167 DESC 'Universal Resource Indicator of the SIP UA' 1168 EQUALITY caseExactMatch 1169 SUBSTR caseExactSubstringsMatch 1170 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1171 attributetypes: (0.0.8.350.1.1.6.1.2 1172 NAME 'SIPIdentityRegistrarAddress' 1173 DESC 'specifies the location of the registrar' 1174 EQUALITY caseIgnoreIA5Match 1175 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1176 attributetypes: (0.0.8.350.1.1.6.1.3 1177 NAME 'SIPIdentityProxyAddress' 1178 DESC 'Specifies the location of the SIP Proxy' 1179 EQUALITY caseIgnoreIA5Match 1180 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1181 attributetypes: (0.0.8.350.1.1.6.1.4 1182 NAME 'SIPIdentityAddress' 1183 DESC 'IP address of the UA' 1184 EQUALITY caseIgnoreIA5Match 1185 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1186 attributetypes: (0.0.8.350.1.1.6.1.5 1187 NAME 'SIPIdentityPassword' 1188 DESC 'The user agent SIP password ' 1189 EQUALITY octetStringMatch 1190 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1191 attributetypes: (0.0.8.350.1.1.6.1.6 1192 NAME 'SIPIdentityUserName' 1193 DESC 'The user agent user name.' 1194 EQUALITY caseIgnoreMatch 1195 SUBSTR caseIgnoreSubstringsMatch 1196 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1197 attributetypes: (0.0.8.350.1.1.6.1.7 1198 NAME 'SIPIdentityServiceLevel' 1199 DESC 'To define services that a user can belong to.' 1200 EQUALITY caseIgnoreIA5Match 1201 SUBSTR caseIgnoreIA5SubstringsMatch 1202 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1203 - 1204 # Object Class Definitions 1205 # 1206 # The following object class is defined in this Recommendation: 1207 # 1208 # SIPIdentity 1209 # 1210 # SIPIdentity 1211 # 1212 # 1213 delete: objectclasses 1214 objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' ) 1215 - 1216 add: objectclasses 1217 objectclasses: (0.0.8.350.1.1.6.2.1 1218 NAME 'SIPIdentity' 1219 DESC 'SIPIdentity object' 1220 SUP top AUXILIARY 1221 MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ 1222 SIPIdentityProxyAddress $ SIPIdentityAddress $ 1223 SIPIdentityPassword $ SIPIdentityUserName $ 1224 SIPIdentityServiceLevel $ userSMIMECertificate ) 1225 ) 1226 - 1227 # 1228 # end of LDIF 1229 # 1231 5.4. H.350.4 Annex A Indexing profile 1233 Indexing of attributes is an implementation-specific activity and 1234 depends upon the desired application. Non-indexed attributes can 1235 result in search times sufficiently long to render some applications 1236 unusable. Notably, user and alias lookup should be fast. The Annex A 1237 Indexing Profile describes an indexing configuration for SIPIdentity 1238 directories that will be optimized for use in directory of 1239 directories applications. Use of this profile is optional. 1241 SIPIdentitySIPURI: equality 1242 SIPIdentityRegistrarAddress: no recommendation 1244 SIPIdentityProxyAddress: no recommendation 1246 SIPIdentityAddress: equality 1248 SIPIdentityUserName: equality 1250 SIPIdentityPassword: no recommendation 1252 SIPIdentityServiceLevel: equality 1254 6. Acknowledgments 1256 We are grateful to numerous colleagues for reaching across multiple 1257 boundaries of standards bodies, research networks, academia and 1258 private industry in order to produce an architecture that works 1259 toward integrating multimedia conferencing deployments. In 1260 particular, standards from both IETF and ITU-T were drawn from 1261 extensively, and the architecture is meant to serve all communities. 1263 This work developed out of the Video Conferencing Middleware 1264 (VidMid-VC) working group, a joint effort of Internet2 1265 (www.internet2.edu) and the Video Development Initiative 1266 (www.vide.net). The architecture was developed in response to 1267 deployment challenges discovered in the ViDeNet 1268 (https//:videnet.unc.edu) academic test bed providing video and 1269 voice over IP infrastructure across research networks 1270 internationally. 1272 This work was supported in part by a grant from the United States 1273 National Science Foundation contract number ANI-0222710. 1275 7. Normative References 1277 [1] Hodges, J., Morgan, R., "Lightweight Directory Access Protocol 1278 (v3): Technical Specification," RFC 3377, September 2002. 1280 [2] ITU-T Recommendation H.350, "Directory services architecture 1281 for multimedia conferencing," 2003. 1283 [3] ITU-T Recommendation H.350.4, "Directory services architecture 1284 for SIP," 2003. 1286 [4] Franks, J., Hallam-Baker P., Hostetler, J., Lawrence, S., 1287 Leach, P., Luotonen, A., Stewart, L., "HTTP Authentication: 1288 Basic and Digest Access Authentication," RFC 2617, June 1999. 1290 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1291 Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: 1292 Session Initiation Protocol," RFC 3261, June 2002. 1294 [6] Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol 1295 (SIP): Locating SIP Servers," RFC 3263, June 2002 1297 [7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class," 1298 RFC 2798, April 2000. 1300 8. Informative References 1302 [8] Hodges, J., Morgan, R., "Lightweight Directory Access Protocol 1303 (v3): Technical Specification," RFC 3377, September 2002. 1305 [9] ITU-T Recommendation H.350.1, " Directory services architecture 1306 for H.323," 2003. 1308 [10] ITU-T Recommendation H.350.2, " Directory services architecture 1309 for H.235," 2003. 1311 [11] ITU-T Recommendation H.350.3, " Directory services architecture 1312 for H.320," 2003. 1314 [12] ITU-T Recommendation H.350.5, " Directory services architecture 1315 for Non-Standard Protocols," 2003. 1317 [13] ITU-T Recommendation H.350.6, " Directory services architecture 1318 for Call Forwarding and Preferences," 2004. 1320 [14] Howes T. and Smith, M., "Understanding And Deploying LDAP 1321 Directory Services," New Riders Publishing, ISBN: 1578700701, 1322 1999. 1324 [15] Howes T. and Smith, M., " LDAP Programming Directory-Enabled 1325 Applications with Lightweight Directory Access Protocol," New 1326 Riders Publishing, ISBN: 1578700000, 1997. 1328 9. Security Considerations 1330 This section is not present in the ITU-T standard, but gives 1331 information for the IETF community. Its content has the consensus of 1332 the ITU-T Study Group 16. 1334 H.350 does not alter the security architectures of any particular 1335 protocol. However, it does offer a standardized place to store 1336 authentication credentials where appropriate. It should be noted 1337 that both H.323 and SIP support shared secret authentication (H.235 1338 Annex D and HTTP Digest, respectively). These approaches require 1339 that the call server have access to the password. Thus, if the call 1340 server or H.350 directory is compromised, passwords also may become 1341 compromised. These weaknesses may be due to weaknesses in the 1342 systems (H.350 directory or call servers) and their operation rather 1343 than in H.350 per se. 1345 The userSMIMECertificate attribute is defined in RFC 2798 (section 1346 2.8) as a part of inetOrgPerson. The SIP user agent's X.509 1347 certificate can be stored in this attribute. When the certificate 1348 is present, it can be employed with S/MIME to provide 1349 authentication, integrity, and confidentiality as specified in RFC 1350 3261 [5]. 1352 It is strongly encouraged that call servers and an H.350 directory 1353 mutually authenticate each other before sharing information. 1354 Further, it is strongly encouraged that communications between H.350 1355 directories and call servers or endpoints happen over secure 1356 communication channels such as SSL or TLS. 1358 Finally, access control lists on LDAP servers are a matter of policy 1359 and are not a part of the standard. System administrators are 1360 advised to use common sense when setting access control on H.350 1361 attributes. For example, password attributes should only be 1362 accessible by the authenticated user, while address attributes might 1363 be publicly available. 1365 10. Contact Information 1367 Tyler Johnson 1368 Editor, H.350 1369 University of North Carolina 1370 Chapel Hill, NC 27599 1371 Tel: +1.919.843.7004 1372 Email: Tyler_Johnson@unc.edu 1374 Sakae Okubo 1375 Rapporteur for Q.4/16, ITU-T SG16 1376 Waseda University 1377 YRP Ichibankan, 3-4 Hikarinooka 1378 Yokosuka-shi, 239-0847 Japan 1379 Tel: +81 46 847 5406 1380 e-mail: sokubo@waseda.jp 1382 Simao Ferraz de Campos Neto 1383 Counsellor, ITU-T SG 16 1384 International Telecommunication Union 1385 Place des Nations 1386 Geneva CH1211 - Switzerland 1387 Tel: +41-22-730-6805 1388 E-mail: simao.campos@itu.int 1389 Copyright (C) The Internet Society (year). This document is subject 1390 to the rights, licenses and restrictions contained in BCP 78, and 1391 except as set forth therein, the authors retain all their rights. 1393 This document and the information contained herein are provided on 1394 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1395 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1396 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1397 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1398 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.