draft-ietf-xmpp-im-21.txt

开源代码的pwlib的1.10.0版本,使用openh323的1.18.0版本毕备

XMPP Working Group                                  P. Saint-Andre (ed.)
Internet-Draft                                Jabber Software Foundation
Expires: September 19, 2004                               March 21, 2004


  Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
                              and Presence
                         draft-ietf-xmpp-im-21

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 19, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This memo describes extensions to and applications of the core
   features of the Extensible Messaging and Presence Protocol (XMPP)
   that provide the basic instant messaging (IM) and presence
   functionality defined in RFC 2779.











Saint-Andre (ed.)      Expires September 19, 2004               [Page 1]

Internet-Draft                  XMPP IM                       March 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .    3
   2.  Syntax of XML Stanzas  . . . . . . . . . . . . . . . . . . .    4
   3.  Session Establishment  . . . . . . . . . . . . . . . . . . .   11
   4.  Exchanging Messages  . . . . . . . . . . . . . . . . . . . .   14
   5.  Exchanging Presence Information  . . . . . . . . . . . . . .   16
   6.  Managing Subscriptions . . . . . . . . . . . . . . . . . . .   26
   7.  Roster Management  . . . . . . . . . . . . . . . . . . . . .   28
   8.  Integration of Roster Items and Presence Subscriptions . . .   32
   9.  Subscription States  . . . . . . . . . . . . . . . . . . . .   56
   10. Blocking Communication . . . . . . . . . . . . . . . . . . .   62
   11. Server Rules for Handling XML Stanzas  . . . . . . . . . . .   84
   12. IM and Presence Compliance Requirements  . . . . . . . . . .   87
   13. Internationalization Considerations  . . . . . . . . . . . .   88
   14. Security Considerations  . . . . . . . . . . . . . . . . . .   88
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . .   89
       Normative References . . . . . . . . . . . . . . . . . . . .   90
       Informative References . . . . . . . . . . . . . . . . . . .   91
       Author's Address . . . . . . . . . . . . . . . . . . . . . .   91
   A.  vCards . . . . . . . . . . . . . . . . . . . . . . . . . . .   91
   B.  XML Schemas  . . . . . . . . . . . . . . . . . . . . . . . .   92
   C.  Differences Between Jabber IM/Presence Protocols and XMPP  .  104
       Intellectual Property and Copyright Statements . . . . . . .  105



























Saint-Andre (ed.)      Expires September 19, 2004               [Page 2]

Internet-Draft                  XMPP IM                       March 2004


1. Introduction

1.1 Overview

   The Extensible Messaging and Presence Protocol (XMPP) is a protocol
   for streaming XML [XML] elements in order to exchange messages and
   presence information in close to real time.  The core features of
   XMPP are defined in Extensible Messaging and Presence Protocol
   (XMPP): Core [XMPP-CORE].  These features -- mainly XML streams, use
   of TLS and SASL, and the <message/>, <presence/>, and <iq/> children
   of the stream root -- provide the building blocks for many types of
   near-real-time applications, which may be layered on top of the core
   by sending application-specific data qualified by particular XML
   namespaces [XML-NAMES].  This memo describes extensions to and
   applications of the core features of XMPP that provide the basic
   functionality expected of an instant messaging (IM) and presence
   application as defined in RFC 2779 [IMP-REQS].

1.2 Requirements

   For the purposes of this memo, the requirements of a basic instant
   messaging and presence application are defined by [IMP-REQS], which
   at a high level stipulates that a user must be able to complete the
   following use cases:

   o  Exchange messages with other users

   o  Exchange presence information with other users

   o  Manage subscriptions to and from other users

   o  Manage items in a contact list (in XMPP this is called a "roster")

   o  Block communications to or from specific other users

   Detailed definitions of these functionality areas are contained in
   [IMP-REQS], and the interested reader is directed to that document
   regarding the requirements addressed herein.

   [IMP-REQS] also stipulates that presence services must be separable
   from instant messaging services; i.e., it must be possible to use the
   protocol to provide a presence service, an instant messaging service,
   or both.  Although the text of this memo assumes that implementations
   and deployments will want to offer a unified instant messaging and
   presence service, there is no requirement that a service must offer
   both a presence service and an instant messaging service, and the
   protocol makes it possible to offer separate and distinct services
   for presence and for instant messaging.



Saint-Andre (ed.)      Expires September 19, 2004               [Page 3]

Internet-Draft                  XMPP IM                       March 2004


   Note: While XMPP-based instant messaging and presence meets the
   requirements of [IMP-REQS], it was not designed explicitly with that
   specification in mind, since the base protocol evolved through an
   open development process within the Jabber open-source community
   before RFC 2779 was written.  Note also that although protocols
   addressing many other functionality areas have been defined in the
   Jabber community, such protocols are not included in this memo
   because they are not required by [IMP-REQS].

1.3 Terminology

   This memo inherits the terminology defined in [XMPP-CORE].

   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [TERMS].

1.4 Contributors

   Most of the core aspects of the Extensible Messaging and Presence
   Protocol were developed originally within the Jabber open-source
   community in 1999.  This community was founded by Jeremie Miller, who
   released source code for the initial version of the jabberd server in
   January 1999.  Major early contributors to the base protocol also
   included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave
   Smith.  Work specific to instant messaging and presence by the XMPP
   Working Group has concentrated especially on IM session establishment
   and communication blocking (privacy lists); the session establishment
   protocol was mainly developed by Rob Norris and Joe Hildebrand, and
   the privacy lists protocol was originally contributed by Peter
   Millard.

1.5 Acknowledgements

   Thanks are due to a number of individuals in addition to the
   contributors listed.  Although it is difficult to provide a complete
   list, the following individuals were particularly helpful in defining
   the protocols or in commenting on the specifications in this memo:
   Thomas Charron, Richard Dobson, Schuyler Heath, Jonathan Hogg, Craig
   Kaes, Jacek Konieczny, Lisa Dusseault, Alexey Melnikov, Keith
   Minkler, Julian Missig, Pete Resnick, Marshall Rose, Jean-Louis
   Seguineau, Alexey Shchepin, Iain Shigeoka, and David Waite.  Thanks
   also to members of the XMPP Working Group and the IETF community for
   comments and feedback provided throughout the life of this memo.

2. Syntax of XML Stanzas




Saint-Andre (ed.)      Expires September 19, 2004               [Page 4]

Internet-Draft                  XMPP IM                       March 2004


   The basic semantics and common attributes of XML stanzas qualified by
   the 'jabber:client' and 'jabber:server' namespaces are defined in
   [XMPP-CORE].  However, these namespaces also define various child
   elements, as well as values for the common 'type' attribute, that are
   specific to instant messaging and presence applications.  Thus,
   before addressing particular "use cases" for such applications, we
   here further describe the syntax of XML stanzas, thereby
   supplementing the discussion in [XMPP-CORE].

2.1 Message Syntax

   Message stanzas qualified by the 'jabber:client' or 'jabber:server'
   namespace are used to "push" information to another entity.  Common
   uses in instant messaging applications include single messages,
   messages sent in the context of a chat conversation, messages sent in
   the context of a multi-user chat room, headlines and other alerts,
   and errors.

2.1.1 Types of Message

   The 'type' attribute of a message stanza is RECOMMENDED; if included,
   it specifies the conversational context of the message, thus
   providing a hint regarding presentation (e.g., in a GUI).  If
   included, the 'type' attribute MUST have one of the following values:

   o  chat -- The message is sent in the context of a one-to-one chat
      conversation.  A compliant client SHOULD present the message in an
      interface enabling one-to-one chat between the two parties,
      including an appropriate conversation history.

   o  error -- An error has occurred related to a previous message sent
      by the sender (for details regarding stanza error syntax, refer to
      [XMPP-CORE]).  A compliant client SHOULD present an appropriate
      interface informing the sender of the nature of the error.

   o  groupchat -- The message is sent in the context of a multi-user
      chat environment (similar to that of [IRC]).  A compliant client
      SHOULD present the message in an interface enabling many-to-many
      chat between the parties, including a roster of parties in the
      chatroom and an appropriate conversation history.  Full definition
      of XMPP-based groupchat protocols is out of scope for this memo.

   o  headline -- The message is probably generated by an automated
      service that delivers or broadcasts content (news, sports, market
      information, RSS feeds, etc.).  No reply to the message is
      expected, and a compliant client SHOULD present the message in an
      interface that appropriately differentiates the message from
      standalone messages, chat sessions, or groupchat sessions (e.g.,



Saint-Andre (ed.)      Expires September 19, 2004               [Page 5]

Internet-Draft                  XMPP IM                       March 2004


      by not providing the recipient with the ability to reply).

   o  normal -- The message is a single message that is sent outside the
      context of a one-to-one conversation or groupchat, and to which it
      is expected that the recipient will reply.  A compliant client
      SHOULD present the message in an interface enabling the recipient
      to reply, but without a conversation history.

   An IM application SHOULD support all of the foregoing message types;
   if an application receives a message with no 'type' attribute or the
   application does not understand the value of the 'type' attribute
   provided, it MUST consider the message to be of type "normal" (i.e.,
   "normal" is the default).  The "error" type MUST be generated only in
   response to an error related to a message received from another
   entity.

   Although the 'type' attribute is OPTIONAL, it is considered polite to
   mirror the type in any replies to a message; furthermore, some
   specialized applications (e.g., a multi-user chat service) MAY at
   their discretion enforce the use of a particular message type (e.g.,
   type='groupchat').

2.1.2 Child Elements

   As described under extended namespaces (Section 2.4), a message
   stanza MAY contain any properly-namespaced child element.

   In accordance with the default namespace declaration, by default a
   message stanza is qualified by the 'jabber:client' or 'jabber:server'
   namespace, which defines certain allowable children of message
   stanzas.  If the message stanza is of type "error", it MUST include
   an <error/> child; for details, see [XMPP-CORE].  Otherwise, the
   message stanza MAY contain any of the following child elements
   without an explicit namespace declaration:

   1.  <subject/>

   2.  <body/>

   3.  <thread/>


2.1.2.1 Subject

   The <subject/> element contains human-readable XML character data
   that specifies the topic of the message.  The <subject/> element MUST