XMPP协议学习--RFC2778

转载：http://blog.sina.com.cn/s/blog_53a49285010006mr.html

RFC2778
出席与即时消息模型（Presence and instant messaging）

摘要：
       本文档定义了出席与即时消息系统的一个抽象模型。定义了所涉及的各种实体，术语，略述了系统提供的服务。目标是为进一步研究协议需求与标记出席与即时消息提供通用词汇。

1．介绍
     出席与即时消息系统允许用户彼此订阅并通知状态改变，并用于用户间传送即时短消息。为便于开发提供此类服务的协议套件，我们认为先开发一个系统模型是有价值的。模型涉及各种实体，所提供的基本功能的描述，最重要的是，定义了用于便于讨论的词汇。

     模型的目标是描述性的与普遍的：我们希望模型合理映射到非正式描述的出席或即时消息的所有系统。模型并不打算指定或达到互操作性：出现在模型中的元素并不需要是可互操作协议的一个元素，也可能不是一个好观点。

     本文档中，模型的每个元素以大写出现（如，PRESENCE SERVICE）。

     本档的第一部分是模型的概述。包括图表，为帮助读者理解元素间关系的术语。第二部分是模型实际定义，术语以字母顺序显示以便于参考。

     概述起一定帮助作用但并非确定；可能与模型定义略有不同。对任何不同，模型定义是正确的，而不是概述方面的解释。

2．概述
     模型提供了一种方法，用于理解，对比，描述支持此类主要参照出席与即时消息服务的方法。由许多出现，存在于系统中的命名实体组成。没有实际的实现是每个模型的实体作为独立部分参加。取而代之的是，几乎总是包含两个或两个以上的模型实体作为实现的部分。然而，不同的实现可能以不同的方法联合实体。

     模型定义了两个服务：PRESENCE SERVICE与INSTANT MESSAGESERVICE。
PRESENCE SERVICE接收，存储，发布信息。信息存储就是PRESENCEINFORMATION。INSTANT MESSAGE SERVICE用于接收与传送INSTANTMESSAGES给INSTANT INBOXES。

2．1 PRESENCE SERVICE
       PRESENCESERVICE有两套不同的“clients”（记住，这些可能合并在一个实现里，但在模型中分离对待）。一套客户端为PRESENTITIES，提供PRESENCEINFORMATION用于存储与发布。另一套客户端为WATCHERS，从服务接收PRESENCEINFORMATION。
                   +----------------------------------+
                   |    PRESENCESERVICE    |
                   +----------------------------------+
                       ^                              |
                       |                               |
                       |                              v
                +-----------------+    +-----------------+
                | PRESENTITY|     |  WATCHER  |
                +-----------------+    +-----------------+
                Fig. 1: Overview of Presence Service
     两类WATCHERS，分别是FETCHERS，SUBSCRIBERS。
     FETCHERS向PRESENCE SERVICE简单请求某些PRESENTITY的PRESENCEINFORMATION的当前值。
     相反，SUBSCRIBER向 PRSENCE SERVICE请求某些PRESENTITY的PRESENCEINFORMATION（将来的）改变通知。
     基于规则基础的一种特殊的获取信息的FETCHER称作POLLER。
             +----------------WATCHER-------------------+
             |                                                                    |
             |  +----FETCHER---+ +--SUBSCRIBER--+  |
             | |             | |             |  |
             |  | +--POLLER--+ | |             |  |
             |  ||         | | |             |  |
             |  | +----------+ | |             |  |
             |  +--------------+ +--------------+  |
             +--------------------------------------=====---+
                  Fig. 2: Varieties of WATCHER

     PRESENCE SERVICE也有相关WATCHERS的WATCHERINFORMATION，他们的行为要根据取消或订阅PRESENCEINFORMATION。PRESENCE SERVICE也可能发布WATCHERINFORMATION给某些WATCHERS，使用用于发布PRESENCEINFORMATION相同的机制。

     PRESENCEINFORMATION的改变通过NOTIFICATION发布到SUBSCRIBERS。图3a-3c显示了P1->P2的PRESENCEINFORMATION改变的信息流。
                  +----------------------------------+
                  |    PRESENCESERVICE     |
                  |           P1                               |
                  +----------------------------------+

               +------------+      +------------+
               |  P1->P2  |      |    P1        |
               | PRESENTITY|      | SUBSCRIBER |
               +------------+      +------------+
                  Fig. 3a: NOTIFICATION (Step 1)

                  +----------------------------------+
                  |    PRESENCESERVICE     |
                  |         P1->P2          |
                  +---------------------------+
                      ^
                      |P2
               +------------+      +------------+
               |    P2    |             |   P1     |
               | PRESENTITY|      | SUBSCRIBER |
               +------------+      +------------+
                  Fig. 3b: NOTIFICATION (Step 2)

                  +----------------------------------+
                  |    PRESENCESERVICE     |
                  |           P2                               |
                  +----------------------------------+
                                          |P2
                                          v
               +------------+      +------------+
               |    P2    |           |  P1->P2   |
               | PRESENTITY|      | SUBSCRIBER |
               +------------+      +------------+
                  Fig. 3c: NOTIFICATION (Step 3)

2．2 INSTANT MESSAGE SERVICE
       INSTANT MESSAGE SERVICE也有两套独立的“client”：SENDERS与INSTANTINBOXES。
       SENDER提供INSTANT MESSAGES给INSTANT MESSAGESERVICE来传送。每个INSTANT MESSAGE都被标记了一个特别的INSTANT INBOXADDRESS，INSTANT MESSAGE SERVICE尝试传消息给相应的INSTANTINBOX。
                +------------------------------------------+
                |  INSTANT MESSAGE SERVICE |
                +------------------------------------------+
                    ^                                   |
                    |                                    v
             +--------------+      +----------------------+
             |  SENDER  |      | INSTANT INBOX |
             +--------------+      +----------------------+
           Fig. 4: Overview of Instant Message Service

2．3 协议
       PRESENCE PROTOCOL定义了PRESENCESERVICE，PRESENTITIES，WATCHERS。PRESENCE INFORMATION由PRESENCEPROTOCOL承载。
       INSTANT MESSAGE PROTOCOL定义了INSTANT MESSAGESERVICE，SENDERS，INSTANT INBOXES。INSTANT MESSAGES由INSTNATMESSAGE PROTOCOL承载。
       根据此模型，我们相信IMPP工作组计划为PRESENCE PROTOCOL，PRESENCEINFORMATION， INSTANT MESSAGE PROTOCOL与INSTANTMESSAGES的结构与格式开发细节需求与说明

2．4 格式
       此模型定义的PRESENCE INFORMATION由任意数目的称作PRESENCETUPLES的元素组成。每个元素由一个STATUS标记（可能表达在线/离线/忙碌/离开/不要打扰信息），一个可选COMMUNICATIONADDRESS，和可选的OTHER PRESENCE MARKUP组成。COMMUNICATIONADDRESS包括一个COMMUNICATION MEANS与一个CONTACTADDRESS。一种类型且仅有一种类型的COMMUNICATIONMEANS定义在此模型中，是INSTANT MESSAGESERVICE。一种类型且仅有一种类型的CONTACTADDRESS定义在此模型中，是INSTANT INBOXADDRESS。然而，其它的可能性也存在：COMMUNICATIONMEANS可能指一些电话学形式，例，与CONTACTADDRESS一致，包含一个电话号码。
     +------------------------------------+
     | PRESENCEINFORMATION              |
     +------------------------------------+
      | +-------------------------------+
      =>| PRESENCETUPLE               |
      | +-------------------------------+
      |   |+-------------------------+
      |   =>|STATUS                 |
      |   |+-------------------------+
      |   |+-------------------------+
      |   =>| COMMUNICATIONADDRESS   |
      |   |+-------------------------+
      |  |    | +-----------------+
      |  |    =>| CONTACT MEANS   |
      |  |    | +-----------------+
      |  |    | +-----------------+
      |  |    =>| CONTACT ADDRESS |
      |  |      +-----------------+
      |   |+-------------------------+
      |   =>| OTHERMARKUP           |
      |    +-------------------------+
      | +-------------------------------+
      =>| PRESENCETUPLE               |
      | +-------------------------------+
      |   |+-------------------------+
      |   =>|STATUS                 |
      |   |+-------------------------+
      |   |+-------------------------+
      |   =>| COMMUNICATIONADDRESS   |
      |   |+-------------------------+
      |  |    | +-----------------+
      |  |    =>| CONTACT MEANS   |
      |  |    | +-----------------+
      |  |    | +-----------------+
      |  |    =>| CONTACT ADDRESS |
      |  |      +-----------------+
      |   |+-------------------------+
      |   =>| OTHERMARKUP           |
      |    +-------------------------+
      | +-------------------------------+
      =>| PRESENCETUPLE               |
      | +-------------------------------+
      |    ...
       Fig. 5: The structure of PRESENCE INFORMATION

       STATUS由模型进一步定义为与INSTANTMESSAGE传送相结合的至少两个状态——OPEN，INSTANTMESSAGES将被接受，与CLOSED，INSTANTMESSAGES将不被接受。OPEN与CLOSED或能也应用于其它COMMUNICATIONMEANS——OPEN映射到某些状态意味着“available”或“open forbusiness”，而CLOSED意味着“unavailable”或“closed tobusiness”。模型允许STATUS包括其它可能由程序或仅由人来叙述的值。模型也允许STATUS由单值或多值组成。

2．5 在即时消息中，出席及其效果
       INSTANT INBOX是INSTANT MESSAGES的容器。它的INSTANT INBOXADDRESS是可以被包括在PRESENCE INFORMATION中的信息，用来定义INSTANTMESSAGE应该怎样被传送至那个INSTANTINBOX。如上所述，STATUS标记的确定值指示是否INSTANTMESSAGES将会被INSTANTINBOX接受。模型并不限制即时消息的传输机制与格式。有理的人可以不同意这种冗长是此模型的优点或缺点。

2．6 PRINCIPALS与它们的代理
       此模型包括其它有利于表现协议与标记如何工作的元素。PRINCIPALS是人，团体，与/或系统之外的“现实世界”中的软件，此系统用于协调与通信。它完全位于模型之外，现实世界怎样映射到PRINCIPALS——模型实体系统仅知道两个不同的PRINCIPALS是独立的，两个同样的PRINCIPALS是同样的。
       PRINCIPAL通过一个或几个用户代理（INBOX USER AGENT；SENDER USERAGENT；PRESENCE USER AGENT；WATCHER USERAGENT）与系统进行交互。通常，不同种用户代理仍分离在模型中，即使大部分实现会把某些用户代理合并在一起。用户代理是PRINCIPAL与一些系统的核心实体（分别为：INSTANTINBOX；SENDER；PRESENTITY；WATCHER）之间单纯的联结。
                  +----------------------------------+
                  |    PRESENCESERVICE     |
                  +----------------------------------+
                      ^                  |
                      | PRESENCE PROTOCOL |
                      |                  v
               +------------+      +------------+
               | PRESENTITY|      |  WATCHER  |
               +------------+      +------------+
                     ^                  ^
                     |                  |
                     |                  |
       o     +--------------+     +-------------+                         o
      /|\  -->| PRESENCE UA |     | WATCHER UA  |<--  /|\
       X     +--------------+     +-------------+     X

  (PRINCIPAL)                                       (PRINCIPAL)

                   Fig. 6: A presence system

                 +---------------------------+
                 |  INSTANT MESSAGE SERVICE |
                 +---------------------------+
                     ^                   |
                   IM|   INSTANTMESSAGE  |IM
                     |      PROTOCOL    v
              +------------+       +---------------+
              |  SENDER  |       | INSTANT INBOX |
              +------------+       +---------------+
                    ^                     ^
                    |                     |
                    |                     |
      o     +-------------+      +------------------+     o
     /|\  -->|  SENDERUA |      |  INBOXUA       |<--  /|\
      X     +-------------+      +------------------+     X

  (PRINCIPAL)                                          (PRINCIPAL)

               Fig. 7: An instant messaging system

2．7 例子
       应用模型的简单例子：描述一个普通“好友列表”应用。此应用主要展示用户的出席信息给其他人，并可以看到其他人的出席信息。因此，我们可以描述一个好友列表合并PRESENCEUSER AGENT与WATCHER USERAGENT为一个单PRINCIPAL，使用单PRESENTITY和单SUBSCRIBER。

       然后扩展例子至即时消息并描述一个普遍的“instantmessenger”作为一个有额外能力收发即时消息的好友列表。因此，一个即时消息者将合并PRESENCEUSER AGENT，WATCHER USER AGENT，INBOX USER AGENT，and SENDER USERAGENT为单一的PRINCIPAL，使用单一的PRESENTITY，单一的SUBSCRIBER，和单一的INSTANTINBOX，PRESENTITY的PRESENCE INFORMATION包括一个去向INSTANTINBOX的INSTANT INBOX ADDRESS。

3．模型
     ACCESS RULES：PRESENCE SERVICE怎样使PRESENCEINFORMATION对WATCHERS可利用的约束。对每个PRESENTITY的PRESENCEINFORMATION，ACCESSRULES的可利用性由控制PRESENTITY的PRINCIPAL的PRESENCE USERAGENT操纵。
动机：我们需要谈论一些来自人的隐藏出席信息。

     CLOSED：STATUS标记的一个突出值。在INSTANTMESSAGES上下文中，此值与INSTANT INBOXADDRESS相关，即便，符合一个INSTANT INBOX，也不能接受INSTANTMESSAGE。此值与其它COMMUNICATIONMEANS有相似的意思，但任何那类含义均没定义在模型中。与OPEN对比。

     COMMUNICATION ADDRESS：由COMMUNICATION MEANS与CONTACTADDRESS组成。

     COMMUNICATION MEANS：指通信凭什么能发生的方法。INSTANT MESSAGESERVICE就是COMMUNICATION MEANS的一个例子。

     CONTACT ADDRESS：通过一些COMMUNICATIONMEANS联系的特殊的点。当使用INSTANT MESSAGE SERVICE时，CONTACTADDRESS就是INSTANT INBOX ADDRESS。

     DELIVERY RULES：INSTANT MESSAGE SERVICE怎样传送收到的INSTANTMESSAGES给INSTANT INBOXES。对每个INSTANT INBOX，可应用的DELIVERYRULES由控制INSTANT INBOX的PRINCIPAL的INBOX USER AGENT操纵。

     动机：我们需要讨论过滤即时消息。

     FETCHER：WATCHER的一种形式，向PRESENCESERVICE请求一个或多个PRESENTITIES的PRESENCEINFORMATION，但不要求SUBSCRIPTION去创建。
INBOX USER AGENT：PRINCIPAL操作由PRINCIPAL控制的一个或多个INSTANTINBOXES的方法。

     INSTANT INBOXADDRESS：指PRESENTITY的PRINCIPAL是否并怎样能接收一个INSTANTMESSAGE进INSTANT INBOX。STATUS与INSTANT INBOXADDRESS信息充分决定是否PRINCIPAL出现准备接受INSTANT MESSAGE。

     动机：关于确切的这个怎样工作定义相当松散，即使对即时消息重用Email架构的部分的可能性未解决。

     INSTANT MESSAGE：一个可确认的，小尺寸的，送至INSTANTINBOX的数据单元。
动机：我们不定义“small”，但在定义中查找以避免传输任意长度标记为“即时消息”的流的可能性。

     INSTANT MESSAGE SERVICE：接受并传送INSTANT MESSAGES。
--可能需要SENDER USER AGENTS与/或INSTANT INBOXES的认证。
--对不同的INSTANTINBOXES可能有不同的认证需求，对由一个单PRINCIPAL控制的不同INSTANTINBOXES可能也有不同的认证需求。
--可能有一个涉及多SERVERS与/或PROXIES的一个内部结构。当保留一个单INSTANTMESSAGESERVICE的逻辑连通性，可能会是重定向与/或代理的复杂模式。注意：INSTANTMESSAGESERVICE不需要有一个截然不同的SERVER—此服务可能作为SENDER与INSTANTINBOX间的直接通信被实现。
--可能有涉及其它INSTANT MESSAGESERVICES的内部结构，可以在自己的权力下独立被访问也可以通过初始化INSTANTMESSAGE SERVICE而被获得。

     NOTIFICATION：是当某些感兴趣的PRESENTITY的PRESENCEINFORMATION改变时，从PRESENCESERVICE到一个SUBSCRIBER的消息，以一个或多个SUBSCRIPTIONS记录。

     OPEN：STATUS标记的一个特殊值。在INSTANTMESSAGES上下文中，此值与INSTANT INBOXADDRESS相关，即便，符合一个INSTANT INBOX，准备接受INSTANTMESSAGE。此值与其它COMMUNICATIONMEANS有相似的意思，但任何那类含义均没定义在模型中。与CLOSED对比。

     OTHER PRESENCE MARKUP：任何包含在一个PRESENTITY的PRESENCEINFORMATION中的其它信息。此模型没进一步定义。

     POLLER：是一个基于规则基础请求PRESENCE INFORMATION的FETCHER。

     PRESENCE INFORMATION：由一个或多个PRESENCE TUPLES组成。

     PRESENCE PROTOCOL：PRESENTITY与PRESENCESERVICE间或是WATCHER与
PRESENCE SERVICE间的可以交换的信息。

     PRESENCE SERVICE：接收，存储与发布PRESENCE INFORMATION。
--可能需要PRESENTITIES与/或WATCHERS的认证。
--对不同的PRESENTITIES可能有不同的认证需求。
--不同的WATCHERS可能有不同的认证需求，对由单WATCHER观察的不同的PRESENTITIES可能也有不同的认证需求。
--可能有一个涉及多SERVERS与/或PROXIES的一个内部结构。当保留一个单PRESENCESERVICE的逻辑连通性，可能会是重定向与/或代理的复杂模式。注意：PRESENCESERVICE不需要有一个截然不同的SERVER—此服务可能作为PRESENCE与WATCHERS间的直接通信被实现。
--可能有涉及其它PRESENCESERVICES的内部结构，可以在自已的权力下独立被访问也可以通过初始化PRESENCESERVICE而被获得。

     PRESENCE TUPLE：由一个STATUS，一个可选的COMMUNICATIONADDRESS与可选的OTHER PRESENCE MARKUP组成。

     PRESENCE USERAGENT：PRINCIPAL操纵零个或多个PRESENTITIES的方法。

     动机：这是一个“model/view”的区别：PRESENTITY是被展示的表现模型，在任何用户界面上，独立于它的显示。另外，我们故意不考虑PRESENCEUSER AGENT，PRESENTITY与PRESENCESERVICE怎样跨机器被定位与分布。

     PRESENTITY（出席实体）：向PRESENCE服务提供PRESENCEINFORMATION。

     动机：我们不喜欢造新词，但“presentity”看起来值得，因为对出席服务的兴趣实体有清晰的语义。注意：出席实体并不（通常）位于出席服务：出席服务仅有一出席实体出席信息的一个最近版本。出席实体发起出席信息的改变，被出席服务而分布。

     PRINCIPAL：人，程序，或团体与/或程序集（选择对PRESENCESERVICE作为一个单一参与者出现，不同于所有其他PRINCIPALS）
     注意：我们需要关于外部系统参与者的一个清晰概念。“Principal”是个好用语。

     PROXY：一个SERVER，与其他的SERVER交流PRESENCE INFORMATION，INSTANTMESSAGES，SUBSCRIPTIONS与/或NOTIFICATIONS。

     SENDER：通过INSTANT MESSAGE SERVICE传送的源INSTANT MESSAGES。
SENDER USER AGENT：PRIINCIPAL操纵零个或多个SENDERS的方法。

     SERVER：一个PRESENCE SERVICE或INSTANT MESSAGESERVICE的不可分割的单元。

     SPAM：不期望的INSTANT MESSAGES。

     SPOOFING：一个不正确的，模仿其他PRINCIPAL的PRINCIPAL。

     STALKING：使用PRESENCEINFORMATION去推断一个PRINCIPAL在何处，特别是用于恶意的或非法的意图。

     STATUS：一个PRESENTITY的PRESENCEINFORMATION的显著部分。STATUS有至少一对互斥值OPEN与CLOSED，有接受INSTANTMESSAGES的意思，并可能有其它COMMUNICATIONMEANS的意思。可能有其它的STATUS值并不暗示任何有关INSTANTMESSAGE接受的信息。其它STATUS值可能合并OPEN与CLOSED或可能是互斥值。
     一些实现可能用其它实体合并STATUS。举例，一个实现仅当INSTANTINBOX能够接受一个INSTANT MESSAGE时才使INSTANT INBOXADDRESS可见。然后，INSTANT INBOXADDRESS的存在暗示OPEN，缺乏则暗示CLOSED。

SUBSCRIBER：WATCHER的一种形式要求PRESENCESERVICE在一个或多个PRESENTITIES的PRESENCEINFORMATION改变时立即通知它。

     SUBSCRIPTION：PRESENCESERVICE所保留的关于一个SUBSCRIBER请求在一个或多个PRESENTITIES的PRESENCEINFORMATION改变时的通知的信息。

     VISIBILITY RULES：PRESENCE SERVICE使WATCHERINFORMATION对WATCHERS的可利用程度的约束。对每个WATCHER的WATCHERINFORMATION，VISIBILITYRULES的应用由控制WATCHER的PRINCIPAL的WATCHER USERAGENT来操纵。

动机：需要讨论来自人们的隐藏观察者的信息。

     WATCHER：请求来自于PRESENCE SERVICE的有关PRESENTITY的PRESENCEINFORMATION，或有关WATCHER的WATCHERINFORMATION。特别类型的WATCHER是FETCHER，POLLER，SUBSCRIBER。

     WATCHERINFORMATION：WATCHERS在最近一段特殊时间内已经收到的关于一个特别PRESENTITY的PRESENCEINFORMATION的信息。WATCHER INFORMATION由PRESENCESERVICE维护，可以选择与PRESENCEINFORMATION一样的格式来表示；即，服务可能选择使WATCHERS看起来像一个特别形式的PRESENTITY。

     动机：如果一个PRESENTITY想知道谁知道它，仅检查相关的SUBSCRIPTIONS信息是不够的。一个WATCHER可能重复取得信息而没有订阅。另外，WATCHER可能重复订阅，然后取消SUBSCRIPTION。如果PRESENCESERVICE提供了WATCHERSINFORMATION，那类WATCHERS对于PRESENTITY应该是可见的。

     WATCHER USERAGENT：PRINCIPAL操纵零个或多个由它控制的WATHCERS的方法。
     动机：当有PRESENCE USERAGENT与PRESENTITY时，区别意指将一个WATCHER的核心功能从它可能被一个产品的操作隔离开来。像以前一样，我们不考虑WATCHERUSER AGENT，WATCHER，与PRESENCE SERVICE穿过机器联合/分布。

4．安全考虑
     此文档为有一定价值安全论点的系统提供了模型与词汇。特别的，出席与即时消息系统必须处理“3S”：STALKING，SPOOFING，SPAM。ACCESSRULES，VISIBILITY RULES，WATCHERINFORMATION用于处理STALKING。有几种认证提及INSTANT MESSAGESERVICE与PRESENCE
  SERVICE，用于处理SPOOFING。DELIVERY RULES用于处理SPAM。

5．总结
此文档为出席与即时系统提供了模型。模型为进一步定义与实现可互操作的出席与即时消息协议提供了统一的词汇。

英文：http://shindowyu.blogbus.com/c3459396/