Dear Mr. Johnson and other experts who are interested in H.ldap,
One of the action points from the previous SG16 meeting in October 2002 is to make a requirement capture as recorded in the meeting report COM16-R25:
"At the WP2 review session, it was suggested to formulate a requirements capture that would serve a check at the final stage of standardization. We can find a good precedent in D.281 for H.248.MCU."
I have tried a draft as attached based on the following materials:
- AVD-2199 Directory Services Architecture for Multimedia Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges - D271 Directory Services Architecture for Multimedia Conferencing (Cisco Systems, Inc.) - COM16-R25 Report of WP2/16, October 2002 - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002
Your additions, deletions, reorganization, improved wordings etc are very much welcome.
-- Best regards,
OKUBO Sakae e-mail: okubo@giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan
GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************
Draft AVD-2279 Source: TBD Title: Requirements for H.ldap "Directory Services Architecture for Multimedia Conferencing" Date: 11 January 2003 Purpose: Proposal
H.ldap will be able to support the following requirements as seen from the human user, gatekeeper and terminal configuration. The list will also serve as a checklist to verify that the proposed specification will support listed items. Some of the features are marked as advanced features and will be part of the future extension.
1. General
1/ Service administrators need call servers that are aware of enterprise directories, to avoid duplication of account management processes. Users need directories to locate other users with whom they wish to communicate. All of these processes should pull their information from canonical data sources in order to reduce redundant processes and ensure information accuracy. [AVD-2199]
2/ H.ldap should accommodate H.320, H.324, SIP or other call signaling protocols concurrently with or subsequently to H.323, subject to decision of the group. [COM16-R25]
3/ The fact that recent videoconferencing products are mostly of H.323/H.320 hybrid should be taken into account. [COM16-R25]
4/ Standards should include information to facilitate implementation in addition to normative specifications. [COM16-R25]
5/ It should be possible to create very large-scale distributed directories. These could include white pages "portals" that allow searching for users across multiple institutions. In this application, each enterprise directory would register itself with (or be unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories. [AVD-2199]
2. Object Classes
1/ Enable endpoint information to be associated with people (or resources such as conference rooms). [AVD-2199]
2/ Enable online searchable "white pages" where dialing information (e.g. H.323 URL) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc. [AVD-2199]
3/ Enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the gatekeeper, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the gatekeeper. [AVD-2199]
4/ Store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool. [AVD-2199]
5/ Include H.323 zone information - such as the zone administrators, network identity of the gatekeeper and resources associated with the zone. [AVD-2199]
6/ Be able to support multiple instances of endpoints per user. [AVD-2199]
7/ Enable a "whois" functionality for H.323 zones, so that one may query the network and find contact information for a particular H.323 zone, and published resources associated with the zone. [AVD-2199]
8/ Be extendable as necessary. [AVD-2199] Defining a minimum in the standard with provision of an extension mechanism has been a good practice. [COM16-R25] Careful consideration is needed for what should be in the standard and what should be left for extension. [COM16-R25]
9/ Be able to encompass H.32x, SIP or other related conferencing protocols in the future. [D271]
3. Security, authentication and authorization
1/ It is important that the H.323 LDAP infrastructure support not only H.235 Annex D (hop-by-hop authentication) and Annex E (end-to-end authentication) modes, but that an organization could shift from one mode to the other without reconstructing the schema. [AVD-2199]
2/ Associate authentication information with a user and enable both endpoint and gatekeeper access to that information, in order to support H.235 Annexes D and E. [AVD-2199]
3/ It should allow both endpoint-centric and user-centric authentication. [AVD-2199] Authentication credentials, such as certificate or user ID / password for station and that for user can be separate. This separation allows for flexibility in the implementation of security architectures. [COM16-R25]
4/ It should be possible to use the directory to manage the services that are authorized for each endpoint or user once authentication is achieved. [D271]
----------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com