ImageVerifierCode 换一换
格式:PDF , 页数:20 ,大小:120.49KB ,
资源ID:797722      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-797722.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T H 350 7-2007 Directory services architecture for XMPP《XMPP目录服务体系结构 研究组16》.pdf)为本站会员(周芸)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

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

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1