Recommendation H.350.5 - Directory Services Architecture for Non-Standard Protocols
Summary
This Recommendation describes an LDAP schema to represent non-standard multimedia communications endpoints, and is meant to provide a very basic framework for representing these elements in a directory. It is an auxiliary class related to H.350 and derives much of its functionality from that architecture. Implementers should review H.350 in detail before proceeding with this Recommendation.
The scope of this Recommendation does not include normative methods for the use of the LDAP directory itself or the data it contains. The purpose of the schema is not to represent all possible data elements in the H.323 protocol, but rather to represent the minimal set required to accomplish the design goals enumerated in H.350.
Keywords
LDAP, Directory Services, H.323, H.320, H.235, SIP
Table of Contents
1.1........ Extending the Schema
2.1........ Normative References
2.2........ Non-Normative References
6.2........ genericIdentityProtocolIdentifier
6.3........ genericIdentityMessage
1 Scope
This Recommendation describes an LDAP schema to represent non-standard multimedia communications endpoints, and is meant to provide a very basic framework for representing these elements in a directory. It is an auxiliary class related to H.350 and derives much of its functionality from that architecture. Implementers should review H.350 in detail before proceeding with this Recommendation.
The scope of this Recommendation does not include normative methods for the use of the LDAP directory itself or the data it contains. The purpose of the schema is not to represent all possible data elements in the H.323 protocol, but rather to represent the minimal set required to accomplish the design goals enumerated in H.350.
1.1 Extending the Schema
The genericIdentity classes may be extended as necessary for specific implementations. See the base H.350 document for a discussion on schema extension.
In general, non-standard protocols will have a variety of attributes that only have meaning to the specific protocol. Implementers should be careful to use consistent and meaningful naming schemes to avoid confusion with other protocols that may be represented by the same object class.
It should be noted that standardized protocols should not extend and use genericIdentity but should instead create and standardize their own protocol-specific auxiliary classes as new contributions to the H.350 series of recommendations.
2 References
The following ITU-T Recommendations and other references contain provisions, which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.
The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation
2.1 Normative References
- ITU-T Recommendation H.350 (2003), Directory Services Architecture for Multimedia Conferencing.
- IETF RFC 3377 (2002), Lightweight Directory Access Protocol (v3): Technical Specification.
2.2 Non-Normative References
- Timothy A. Howes, PhD, Mark C. Smith, Gordon S. Good, New Riders Publishing (1999),ISBN: 1578700701, Understanding And Deploying LDAP Directory Services.
- Timothy A. Howes, PhD, Mark C. Smith, New Riders Publishing (1997), ISBN: 1578700000, LDAP Programming Directory-Enabled Applications with Lightweight Directory Access Protocol.
3 Definitions
The following terms used throughout the document:
commObject: An LDAP object class defined in ITU-T H.350 that represents generic multimedia conferencing endpoints.
White Pages: An application that allows end users to look up the address of another user.
4 Abbreviations
LDAP: Lightweight Directory Access Protocol as defined in RFC 3377.
5 Conventions
In this Recommendation, the following conventions are used:
"Shall" indicates a mandatory requirement.
"Should" indicates a suggested but optional course of action.
"May" indicates an optional course of action rather than a recommendation that something take place.
References to clauses, sub clauses, annexes and appendices refer to those items within this Recommendation unless another specification is explicitly listed.
6 Object Class Definitions
The genericIdentity object class represents generic multimedia conferencing information associated with a person or resource. It is an auxiliary class and is related to the commObject class, which is defined in the ITU-T H.350 Recommendation. It should be noted that the particular user or resource with which an endpoint is associated via commOwner takes on special importance, as that may represent contact information required for further information in the use of the particular endpoint.
If specific attributes such as IP address or URIs are necessary to support this endpoint type, then the standard attributes defining IP address and URI should be used. Keep in mind that in a directory of directories scenario, external searches will only be aware of the genericIdentity attributes and will not know to display IP address or URI.
6.1 genericIdentity
OID: 0.0.8.350.1.1.7.2.1
objectclasses: (0.0.8.350.1.1.7.2.1
NAME 'genericIdentity'
DESC 'genericIdentity object'
SUP top AUXILIARY
MAY (genericIdentityProtocolIdentifier $ genericIdentityMessage
)
)
6.2 genericIdentityProtocolIdentifier
OID: 0.0.8.350.1.1.7.1.1
attributetypes: (0.0.8.350.1.1.7.1.1
NAME 'genericIdentityProtocolIdentifier'
DESC ‘name of the non-standard protocol’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
Application utility class
Standard
Number of values
multi
Definition
Text string indicating the name of the non-standard protocol represented by this endpoint.
Notes
Semantics
Example applications for which this attribute would be useful
Search for endpoints that support a specific non-standard protocol.
Example (LDIF fragment)
genericIdentityProtocolIdentifier: ‘MPEG2’ //MPEG2 endpoint
6.3 genericIdentityMessage
OID: 0.0.8.350.1.1.7.1.2
attributetypes: (0.0.8.350.1.1.7.1.2
NAME 'genericIdentityMessage'
DESC ‘informative text string’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
Application utility class
Standard
Number of values
multi
Definition
Informative text string containing information about multimedia conferencing capabilities of the associated user and/or location of the service. This information may include instructions, other connection information, or pointers to specific documentation.
Notes
Semantics
Example applications for which this attribute would be useful
Multimedia conferencing services that are not H.323, H.320, or SIP; for example: MPEG2, Access Grid or other IP Multicast service; Instant Messaging Service
Example (LDIF fragment)
genericIdentityMessage: ‘see www.foo.com/mpeg2 for connection instructions’
7 genericIdentity LDIF Files
This section contains a schema configuration file for genericIdentity that can be used to configure an LDAP server to support this class
# genericIdentity Object Schema
#
# Schema for representing a genericIdentity Protocol Object in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing genericIdentity
# object in an LDAP directory [LDAPv3]. It defines schema elements
# to represent an genericIdentity object [genericIdentity].
#
# .1 = Communication related work
# .1.7 = genericIdentity
# .1.7.1 = attributes
# .1.7.2 = objectclass
# .1.7.3 = syntax
#
#
#
# Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# genericIdentityProtocolIdentifier
# genericIdentityMessage
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
#
# if this is the first time you are adding the genericIdentity
# objectclass using this LDIF file, then you should comment
# out the delete attributetypes modification since this will
# fail. Alternatively, if your ldapmodify has a switch to continue
# on errors, then just use that switch -- if you're careful
#
delete: attributetypes
attributetypes:(0.0.8.350.1.1.7.1.1 NAME 'genericIdentityProtocolIdentifier' )
attributetypes: (0.0.8.350.1.1.7.1.2 NAME 'genericIdentityMessage' )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.7.1.1
NAME 'genericIdentityProtocolIdentifier'
DESC 'name of the non-standard protocol'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.7.1.2
NAME 'genericIdentityMessage'
DESC 'informative text string'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
# Object Class Definitions
#
# The following object class is defined in this document:
#
# genericIdentity
#
# genericIdentity
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.7.2.1 NAME 'genericIdentity' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.7.2.1
NAME 'genericIdentity'
DESC 'genericIdentity object'
SUP top AUXILIARY
MAY ( genericIdentityProtocolIdentifier $ genericIdentityMessage )
)
-
#
# end of LDIF
#
A Annex A Indexing Profile
Indexing of attributes is an implementation-specific activity and depends upon the desired application. Non-indexed attributes can result in search times sufficiently long to render some applications unusable. Use of this profile is optional.
genericIdentityProtocolIdentifier: equality
genericIdentityMessage: equality
Appendix I Electronic Attachment
I Electronic Attachment
The attached file genericIdentity.ldif.txt contains a text only version of the LDIF file described in section 7.
