查看源代码
来自Jabber/XMPP中文翻译计划
RFC6121
的源代码
跳转到:
导航
,
搜索
根据下列原因,你没有权限编辑本页:
您刚才请求的操作只有这个用户组中的用户才能使用:
用户
您可以查看并复制此页面的源代码:
[[Category:XMPP相关RFC]] [[Category:XMPP核心RFC]] [[Category:翻译中]] "本文的英文原文来自[http://xmpp.org/rfcs/rfc6121.html RFC 6121] {|border="1" cellspacing="0" width="65%" |互联网工程任务组(IETF) || P. Saint-Andre |- |申请讨论: 6121 || Cisco |- |取代: 3921 || 2011年3月 |- |类别: 标准跟踪 || |- |ISSN: 2070-1721 || |} :::'''可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息''' '''摘要''' :本文定义提供了遵循RFC2779要求的基本的即时消息(IM)和出席信息功能的可扩展的消息和出席信息协议(XMPP)的核心功能的扩展. 本文取代了 RFC 3921. '''本文的状态''' :这是一个互联网标准跟踪文档. :本文是互联网工程工作组(IETF)的一个成果. 它代表了IETF社区的一致意见. 它已经公开审核并由互联网工程控制组(IESG)批准发布了. 更多关于互联网标准的信息请参见RFC 5741第2章. :关于本文当前状态的信息, 任何错误, 以及如何对它提出反馈,请到 http://www.rfc-editor.org/info/rfc6121 . '''版权声明''' :Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. :This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. ==序论== ===概述=== 可扩展的消息和出席信息协议(XMPP)是可扩展的标记语言[[RFC6121#常规备注|XML]]的一个应用范畴,它能使两个或更多网络实体之间的结构化并且可扩展的数据进行准实时的交换. 在[[RFC6120|XMPP‑CORE]]中定义的XMPP的核心特性提供了各种类型的准实时应用的积木, 通过发送由特定的XML命名空间(参考[[RFC6121#常规备注|XML‑NAMES]])所限定的应用特有的数据,它们可被叠加在核心之上. 本文定义的XMPP扩展提供一个[[RFC6121#提示性备注|IMP‑REQS]]所述的即时消息(IM)和出席信息应用所预期的基本功能. ===历史=== XMPP的基本语法和语义最开始是由Jabber开源社区开发的, 主要是在1999年. 2002年, 根据 [[RFC6121#提示性备注|IMP‑REQS]] ,XMPP工作组被允许基于Jabber协议开发一个适合IETF的即时消息和出席信息技术. 到了2004年10月, 发布了 [[RFC3920]] 和 [[RFC3921]] , 意味着那时候XMPP的主要定义完成了. 从2004年开始,互联网社区已经获得了广泛的XMPP实现和布署经验, 包括XMPP标准基金会(XSF)主持下开展的正式的互操作性测试. 本文全面整合了从软件开发者和XMPP服务提供者得到的反馈, 包含了一系列向后兼容的修改,见 [[RFC6121#附录E:和RFC3921的不同|附录E]] . 结果是, 本文反映了互联网社区对于XMPP1.0的即时消息和出席信息特性的初步共识, 因此废止了RFC 3921. ===需求=== 传统上, IM应用组合了以下因素: :# 关注的中心点是某人的联系人的列表或 "好友们" (在XMPP中这个列表被称为一个 "roster"(名册)). :# 使用这类应用的目标是和特定的联系人准实时地交换相关的短文本消息 -- 在章节[[RFC6121#一对一聊天会话|5.1]]描述的一对一形式的"聊天会话"中, 快速连续的相关消息的数量经常是很大的. :# 交换消息的催化剂是 "presence" -- 即, 关于特定联系人们的网络可用性的信息(这样就知道谁在线并且有空进行一对一的聊天会话). :# 出席信息仅提供给通过一个被称为"出席信息订阅"的明确协议被授权的联系人. 所以在高层上本文假定用户能完成下列用例: :* 在某人的联系人列表中管理条目 :* 和某人的联系人们交换消息 :* 和某人的联系人们交换出席信息 :* 管理对某人的联系人们发出和接受出席信息的订阅 这些功能性领域的详细定义被包含在 RFC 2779 [[RFC6121#参考文献|IMP‑REQS]] 中, 关于深度需求感兴趣的读者可以参考那个文档. 尽管 XMPP IM 和这里定义的出席信息扩展满足了 RFC 2779 的需求, 它们不是特意为那个协议设计的, 因为在 RFC 2779 出现之前,Jabber开源社区就通过一个开放的开发流程进化出了基本协议. 尽管在XMP标准基金会的XEP系列中发表了一些其他功能领域的XMPP协议扩展(例如, [[XEP-0045]]定义的多用户文本聊天), 这类扩展未在本文中定义,因为它们未被 RFC 2779 授权. :实现备注: RFC 2779 规定出席信息服务必须独立于IM服务,反之亦然; 即, 必须有可能使用本协议提供一个出席信息服务, 一个消息服务, 或同时提供两者. 尽管本文的文本假定实现和部署会希望提供统一的IM和出席信息服务, 对于一个XMPP服务来说,并不强制同时提供一个出席信息服务和一个消息服务, 并且协议使得为出席信息和为消息提供独立和特别的服务成为可能. (例如, 如果一个客户端尝试发送一个<message/>节, 一个只有出席信息的服务可能返回一个<service-unavailable/>节错误.) ===功能汇总=== 这个非规范性的章节提供一个对开发者友好的, 基于XMPP的IM和出席信息特性的功能汇总; 参考接下来的的章节来察看这些特性的规范性的定义. [[RFC6120|XMPP‑CORE]] 定义了一个XMPP客户端如何连接到一个XMPP服务器. 特别是, 它定义了客户端在一个XMPP网络中被允许发送XML节(XMPP中的基本含意单位)给其他实体之前需要满足的前提条件. 这些前提条件包括,XML流的协商,XML流头的交换, 可选的通过传输层安全[[RFC6121#参考文献|TLS]]的通道加密, 通过简单验证和安全层[[RFC6121#参考文献|SASL]]强制验证, 和把资源绑定到客户端所在的流上. 关于这些前提条件的细节,读者可以参考 [[RFC6120|XMPP‑CORE]], [[RFC6120|XMPP‑CORE]] 的知识假定已经在此. Interoperability Note: [RFC3921] specified one additional precondition: formal establishment of an instant messaging and presence session. Implementation and deployment experience has shown that this additional step is unnecessary. However, for backward compatibility an implementation MAY still offer that feature. This enables older software to connect while letting newer software save a round trip. Upon fulfillment of the preconditions specified in [XMPP‑CORE], an XMPP client has a long-lived XML stream with an XMPP server, which enables the user controlling that client to send and receive a potentially unlimited number of XML stanzas over the stream. Such a stream can be used to exchange messages, share presence information, and engage in structured request-response interactions in close to real time. After negotiation of the XML stream, the typical flow for an instant messaging and presence session is as follows: Retrieve one's roster. (See Section 2.2.) Send initial presence to the server for broadcast to all subscribed contacts, thus "going online" from the perspective of XMPP communication. (See Section 4.2.) Exchange messages, manage presence subscriptions, perform roster updates, and in general process and generate other XML stanzas with particular semantics throughout the life of the session. (See Sections 5, 3, 2, and 6.) Terminate the session when desired by sending unavailable presence and closing the underlying XML stream. (See Section 4.5.) ===术语=== ==管理花名册 Managing the Roster== 在XMPP中, 一个用户的花名册(roster)包含任意数量的特定联系人。一个用户的花名册由用户的服务器代替用户储存,从而使用户可以从任何资源设备访问花名册信息。当用户添加或修改花名册项目,并且无错误发生时,服务器如果有可能应该(SHOULD)不加修改的存储数据,并且当一个授权的客户端请求花名册时,服务器必须(MUST)返回已存储的数据。 安全警告: 因为用户的花名册包含机密的数据,因此服务器必须(MUST)限制对这些数据的访问,只有经授权验证的实体(典型的为帐户拥有者)才有权利检索,修改和删除它。 ===语法和语义===
返回到
RFC6121
。
查看
页面
讨论
查看源代码
历史
个人工具
登录/创建账户
导航
首页
社区专页
新闻动态
最近更改
随机页面
帮助
XMPP资源
XMPP公共服务
XMPP客户端软件
XMPP服务器软件
友情链接
搜索
工具箱
链入页面
链出更改
特殊页面