ITU-T H 350 7-2007 Directory services architecture for XMPP《XMPP目录服务体系结构 研究组16》.pdf

《ITU-T H 350 7-2007 Directory services architecture for XMPP《XMPP目录服务体系结构 研究组16》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 350 7-2007 Directory services architecture for XMPP《XMPP目录服务体系结构 研究组16》.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T H.350.7 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (01/2007) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services Directory services architecture for audiovisual and multimedia services Directory services architecture f

2、or XMPP ITU-T Recommendation H.350.7 ITU-T H-SERIES RECOMMENDATIONS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.239

3、Communication procedures H.240H.259 Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia services H.350H.359 Quality of service architecture for audiovisu

4、al and multimedia services H.360H.369 Supplementary services for multimedia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mobility for H-Series multimedia systems and services H.510H.519 Mobile multimedia col

5、laboration applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 Mobility interworking procedures H.550H.559 Mobile multimedia collaboration inter-working procedures H.560H

6、.569 BROADBAND AND TRIPLE-PLAY MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.350.7 (01/2007) i ITU-T Recommendation H.350.7 Directory services architecture for XMPP Summary The Extensible Me

7、ssaging and Presence Protocol (XMPP) is an IETF standard protocol for exchanging information between network endpoints using Extensible Markup Language (XML). It is used to enable instant messaging and presence applications and is growing in popularity. This Recommendation includes XMPP in the suite

8、 of protocols that is supported in ITU-T H.350, so that an organization can directory-enable and manage XMPP resources in the same way that other multimedia protocols (e.g., H.320, H.323, SIP) are managed in ITU-T H.350. Source ITU-T Recommendation H.350.7 was approved on 13 January 2007 by ITU-T St

9、udy Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure. Keywords Directory services, instant messaging, LDAP, presence, XMPP. ii ITU-T Rec. H.350.7 (01/2007) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunica

10、tions. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunicati

11、on Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of inf

12、ormation technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating ag

13、ency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some

14、 other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or i

15、mplementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development pro

16、cess. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strong

17、ly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. H.350.7 (01/2007) iii CONTENTS Page 1 Scope 1 1.1 Extending the s

18、chema. 1 1.2 Typical use cases 1 2 References. 1 3 Definitions 2 4 Abbreviations 2 5 Conventions 2 6 Object Class definitions 2 6.1 xmppURIObject Object Class 3 6.2 xmppIdentityURI attribute. 3 6.3 xmppUserId attribute 3 6.4 xmppPassword attribute. 4 7 xmppURIObject LDIF Files. 4 8 ASN.1 representat

19、ion 6 9 DSML representation 7 Annex A Indexing profile . 9 Appendix I Electronic versions of formal definitions. 10 Bibliography. 11 ITU-T Rec. H.350.7 (01/2007) 1 ITU-T Recommendation H.350.7 Directory services architecture for XMPP 1 Scope The Extensible Messaging and Presence Protocol (XMPP) is a

20、n IETF standard protocol for exchanging information between network endpoints using Extensible Markup Language (XML). It is used to enable instant messaging and presence applications and is growing in popularity. This Recommendation includes XMPP in the suite of protocols that is supported in ITU-T

21、H.350, so that an organization can directory-enable and manage XMPP resources in the same way that other multimedia protocols (e.g., H.320, H.323, SIP) are managed in ITU-T H.350. The schema provides a method for representing XMPP URIs and user information in the directory. Note that this Recommenda

22、tion defines representation of URIs and not IRIs, as described in IETF RFC 4622. The scope of this Recommendation does not include normative methods for the use of the LDAP directory itself or the data it contains. 1.1 Extending the schema The xmppURIObject classes may be extended as necessary for s

23、pecific implementations. See the base ITU-T H.350 document for a discussion on schema extension. 1.2 Typical use cases Many applications external to an XMPP network may need to identify XMPP entities as full URIs; in this case an LDAP directory that needs to store XMPP addresses and non-native user

24、agents (e.g., web browsers, calendaring applications and enterprise white pages) that provide interface to XMPP services. The simplest case is to have a white page lookup where a user is using a web browser to search for other users that are using an XMPP-based client. Another use case would be for

25、an XMPP server to use XMPP account credentials (xmppUserId and xmppPassword attributes) stored in an H.350 directory for authenticating requests from XMPP clients. This is useful for environments where there is no backend authentication mechanism available. 2 References The following ITU-T Recommend

26、ations 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 theref

27、ore 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-

28、alone document, the status of a Recommendation. ITU-T H.350 ITU-T Recommendation H.350 (2003), Directory services architecture for multimedia conferencing. ITU-T H.350.1 ITU-T Recommendation H.350.1 (2003), Directory services architecture for H.323. ITU-T H.350.2 ITU-T Recommendation H.350.2 (2003),

29、 Directory services architecture for H.235. ITU-T H.350.3 ITU-T Recommendation H.350.3 (2003), Directory services architecture for H.320. 2 ITU-T Rec. H.350.7 (01/2007) ITU-T H.350.4 ITU-T Recommendation H.350.4 (2003), Directory services architecture for SIP. ITU-T H.350.5 ITU-T Recommendation H.35

30、0.5 (2003), Directory services architecture for non-standard protocols. IETF RFC 3920 IETF RFC 3920 (2004), Extensible Messaging and Presence Protocol (XMPP): Core. IETF RFC 4622 IETF RFC 4622 (2006), Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Exten

31、sible Messaging and Presence Protocol (XMPP). 3 Definitions This Recommendation uses the following terms defined elsewhere: 3.1 Uniform Resource Identifier (URI): See IETF RFC 4622 for a discussion of URIs and IRIs in XMPP. 3.2 Internationalized Resource Identifier (IRI): See IETF RFC 4622 for a dis

32、cussion of URIs and IRIs in XMPP. 4 Abbreviations This Recommendation uses the following abbreviations: LDAP Lightweight Directory Access Protocol (as defined in IETF RFC 1777). SASL Simple Authentication and Security Layer (as defined in b-IETF RFC 4422). XMPP Extensible Messaging and Presence Prot

33、ocol (an IETF standard protocol for exchanging information between network endpoints using Extensible Markup Language (XML). It is commonly used for instant messaging, presence and voice over IP applications.) 5 Conventions In this Recommendation, the following conventions are used: “Shall“ indicate

34、s 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, subclauses, annexes and appendices refer to those items within this Recommendation unle

35、ss another specification is explicitly listed. 6 Object Class definitions The xmppURIObject represents an XMPP URI; that is, the address of an entity that is capable of communicating using the XMPP protocol. Because it is its own unique object class, the directory can be searched for the presence of

36、 this attribute. Note that XMPP uses Simple Authentication and Security Layer (SASL) for authentication, enabling each deployment to make use of its own backend authentication mechanism such as Kerberos. Because of this, many applications will not need to use the username and password attributes. Ho

37、wever, these attributes are included for those implementations which do not use backend authentication, or for implementations which do, but need a small number of static ITU-T Rec. H.350.7 (01/2007) 3 identities such as might be associated with server accounts for which there is associated central

38、identity management system in the enterprise. 6.1 xmppURIObject Object Class OID: 0.0.8.350.1.1.9.2.1 objectclasses: (0.0.8.350.1.1.9.2.1 NAME xmppURIObject DESC XmppURI object SUP top AUXILIARY MAY ( xmppIdentityURI $ xmppUserId $ xmppPassword ) ) 6.2 xmppIdentityURI attribute OID: 0.0.8.350.1.1.9.

39、1.1 attributetypes: (0.0.8.350.1.1.9.1.1 NAME xmppIdentityURI DESC Labeled URI format to represent an XMPP URI EQUALITY caseIgnoreMatch EQUALITY caseIgnoreSubstringsMatch SYNTAX 1 1.3.6.1.4.1.1466.115.121.1.15) Application utility class standard Number of values multi Definition Specifies an XMPP UR

40、I. Permissible values (if controlled) Notes Implementers should review IETF RFC 4622 for rules about escaping characters to ensure full international character set compatibility. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) 6.3 xmppUserId attribute

41、OID: 0.0.8.350.1.1.9.1.2 attributetypes: (0.0.8.350.1.1.9.1.2 NAME xmppUserId DESC Xmpp Userid EQUALITY caseIgnoreMatch EQUALITY caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) Application utility class standard Number of values multi 4 ITU-T Rec. H.350.7 (01/2007) Definition Holds t

42、he user ID of an XMPP user for authentication purposes. Permissible values (if controlled) Notes Implementers should be aware that if a single H.350 directory serves multiple XMPP domains, it will not be possible to determine to which domain a particular user ID belongs. Care may be taken in the str

43、ucture of the directory or in controlled access to the directory to ensure that this is deterministic. This attribute is not necessary if backend authentication is used. Semantics Example applications for which this attribute would be useful XMPP User ID and Password are useful if backend authentica

44、tion is not used, or if implementation requires that users have multiple XMPP accounts. Example (LDIF fragment) 6.4 xmppPassword attribute OID: 0.0.8.350.1.1.9.1.3 attributetypes: (0.0.8.350.1.1.9.1.3 NAME xmppPassword DESC Xmpp password EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40

45、) Application utility class standard Number of values multi Definition Holds the password of an XMPP user for authentication purposes. Permissible values (if controlled) Notes Not necessary if backend authentication is used. Semantics Example applications for which this attribute would be useful XMP

46、P User ID and Password are useful if backend authentication is not used, or if implementation requires that users have multiple XMPP accounts. Example (LDIF fragment) 7 xmppURIObject LDIF Files This clause contains a schema configuration file for xmppURIObject that can be used to configure an LDAP s

47、erver to support this class. # XmppURIObject Object Schema # # Schema for representing a XmppURIObject Object in an LDAP Directory ITU-T Rec. H.350.7 (01/2007) 5 # # Abstract # # This document defines the schema for representing XmppURIObject # object in an LDAP directory LDAPv3. It defines schema e

48、lements # to represent an xmppURIObject object xmppURIObject. # # .1 = Communication related work # .1.9 = xmppURIObject # .1.9.1 = attributes # .1.9.2 = objectclass # .1.9.3 = syntax # # # # Attribute Type Definitions # # The following attribute types are defined in this document: # # xmppIdentityU

49、RI # xmppUserId # xmppPassword 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 youre careful # del