xmpp 之Jabber RFC3920 [草稿]

::-- run mei [2005-07-05 10:11:22]

Contents

  1. 翻译者
  2. Extensible Messaging and Presence Protocol (XMPP): Core
    1. Status of this Memo
    2. Copyright Notice
    3. Abstract
    4. Table of Contents
    5. 1. Introduction
      1. 1.1. Overview
      2. 1.2. Terminology
    6. 2. Generalized Architecture
      1. 2.1. Overview
      2. 2.2. Server
      3. 2.3. Client
      4. 2.4. Gateway
      5. 2.5. Network
    7. 3. Addressing Scheme
      1. 3.1. Overview
      2. 3.2. Domain Identifier
      3. 3.3. Node Identifier
      4. 3.4. Resource Identifier
      5. 3.5. Determination of Addresses
    8. 4. XML Streams
      1. 4.1. Overview
      2. 4.2. Binding to TCP
      3. 4.3. Stream Security
      4. 4.4. Stream Attributes
        1. 4.4.1. Version Support
      5. 4.5. Namespace Declarations
      6. 4.7. Stream Errors
        1. 4.7.1. Rules
        2. 4.7.2. Syntax
        3. 4.7.3. Defined Conditions
        4. 4.7.4. Application-Specific Conditions
      7. 4.8. Simplified Stream Examples
    9. 5. Use of TLS
      1. 5.1. Overview
      2. 5.2. Narrative
      3. 5.3. Client-to-Server Example
      4. 5.4. Server-to-Server Example
    10. 6. Use of SASL
      1. 6.1. Overview
      2. 6.2. Narrative
      3. 6.3. SASL Definition
      4. 6.4. SASL Errors
      5. 6.5. Client-to-Server Example
    11. 7. Resource Binding
    12. 8. Server Dialback
      1. 8.1. Overview
      2. 8.2. Order of Events
      3. 8.3. Protocol
    13. 9. XML Stanzas
      1. 9.1. Common Attributes
      2. 9.2. Basic Semantics
      3. 9.3. Stanza Errors
    14. 10. Server Rules for Handling XML Stanzas
      1. 10.1. No 'to' Address
      2. 10.2. Foreign Domain
      3. 10.3. Subdomain
      4. 10.4. Mere Domain or Specific Resource
      5. 10.5. Node in Same Domain
    15. 11. XML Usage within XMPP
      1. 11.1. Restrictions
      2. 11.2. XML Namespace Names and Prefixes
      3. 11.3. Validation
      4. 11.4. Inclusion of Text Declaration
      5. 11.5. Character Encoding
    16. 12. Core Compliance Requirements
      1. 12.1. Servers
      2. 12.2. Clients
    17. 13. Internationalization Considerations
    18. 14. Security Considerations
      1. 14.1. High Security
      2. 14.2. Certificate Validation
      3. 14.3. Client-to-Server Communications
      4. 14.4. Server-to-Server Communications
      5. 14.5. Order of Layers
      6. 14.6. Lack of SASL Channel Binding to TLS
      7. 14.7. Mandatory-to-Implement Technologies
      8. 14.8. Firewalls
      9. 14.9. Use of base64 in SASL
      10. 14.10. Stringprep Profiles
    19. 15. IANA Considerations
      1. 15.1. XML Namespace Name for TLS Data
      2. 15.2. XML Namespace Name for SASL Data
      3. 15.3. XML Namespace Name for Stream Errors
      4. 15.4. XML Namespace Name for Resource Binding
      5. 15.5. XML Namespace Name for Stanza Errors
      6. 15.6. Nodeprep Profile of Stringprep
      7. 15.7. Resourceprep Profile of Stringprep
      8. 15.8. GSSAPI Service Name
      9. 15.9. Port Numbers
    20. 16. References
      1. 16.1. Normative References
      2. 16.2. Informative References
    21. Appendix A. Nodeprep
      1. A.1. Introduction
      2. A.2. Character Repertoire
      3. A.3. Mapping
      4. A.4. Normalization
      5. A.5. Prohibited Output
      6. A.6. Bidirectional Characters
    22. Appendix B. Resourceprep
      1. B.1. Introduction
      2. B.2. Character Repertoire
      3. B.3. Mapping
      4. B.4. Normalization
      5. B.5. Prohibited Output
      6. B.6. Bidirectional Characters
    23. Appendix C. XML Schemas
      1. C.1. Streams namespace
      2. C.2. Stream error namespace
      3. C.3. TLS namespace
      4. C.4. SASL namespace
      5. C.5. Resource binding namespace
      6. C.6. Dialback namespace
      7. C.7. Stanza error namespace
    24. Appendix D. Differences Between Core Jabber Protocols and XMPP
      1. D.1. Channel Encryption
      2. D.2. Authentication
      3. D.3. Resource Binding
      4. D.4. JID Processing
      5. D.5. Error Handling
      6. D.6. Internationalization
      7. D.7. Stream Version Attribute
    25. Contributors
    26. Acknowledgements
    27. Author's Address

翻译者

Extensible Messaging and Presence Protocol (XMPP): Core

Status of this Memo

Abstract

Table of Contents

  1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3
  3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5
  4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7
  5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19
  6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27
  7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37
  8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41
  9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48
  10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58
  11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60
  12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62
  13. Internationalization Considerations . . . . . . . . . . . . 64
  14. Security Considerations . . . . . . . . . . . . . . . . . . 64
  15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69
  16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
  17. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75 B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76 C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78 D. Differences Between Core Jabber Protocols and XMPP . . . . . 87 Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90

1. Introduction

1.1. Overview

1.2. Terminology

2. Generalized Architecture

2.1. Overview

2.2. Server

2.3. Client

2.4. Gateway

2.5. Network

因为每一个服务器都可以通过一个网络地址来标识,同时因为 服务器之间的通信 是 客户端与服务器之间的通信协议的一个直接的扩展,在实践中,系统由交互通 信的服务器网络组成。因此,例如< juliet@example.com >能够与< romeo@example.net > 交换消息、presence和其它信息。这种模式在使用网络地址标准的消息通信协议 (如SMTP)中是常见的,任何两个通信是可选的。如开启,那么通信在基于xml流上 发生,它一定要建立 TCP 连接。推荐的连接端口为 5269, 它已向IANA注册。

Saint-Andre, Ed. Standards Track [Page 4]

RFC 3920 XMPP Core October 2004

3. Addressing Scheme

3.1. Overview

Saint-Andre, Ed. Standards Track [Page 5]

RFC 3920 XMPP Core October 2004

3.2. Domain Identifier

3.3. Node Identifier

3.4. Resource Identifier

Saint-Andre, Ed. Standards Track [Page 6]

RFC 3920 XMPP Core October 2004

3.5. Determination of Addresses

4. XML Streams

4.1. Overview

Saint-Andre, Ed. Standards Track [Page 7]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 8]

RFC 3920 XMPP Core October 2004

   |--------------------|
   | <stream>           |
   |--------------------|
   | <presence>         |
   |   <show/>          |
   | </presence>        |
   |--------------------|
   | <message to='foo'> |
   |   <body/>          |
   | </message>         |
   |--------------------|
   | <iq to='bar'>      |
   |   <query/>         |
   | </iq>              |
   |--------------------|
   | ...                |
   |--------------------|
   | </stream>          |
   |--------------------|

Saint-Andre, Ed. Standards Track [Page 9]

RFC 3920 XMPP Core October 2004

4.2. Binding to TCP

4.3. Stream Security

4.4. Stream Attributes

Saint-Andre, Ed. Standards Track [Page 10]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 11]

RFC 3920 XMPP Core October 2004

            |  initiating to receiving  |  receiving to initiating
   ---------+---------------------------+-----------------------
   to       |  hostname of receiver     |  silently ignored
   from     |  silently ignored         |  hostname of receiver
   id       |  silently ignored         |  session key
   xml:lang |  default language         |  default language
   version  |  signals XMPP 1.0 support |  signals XMPP 1.0 support

4.4.1. Version Support

Saint-Andre, Ed. Standards Track [Page 12]

RFC 3920 XMPP Core October 2004

  1. The receiving entity MUST set the value of the 'version'
    • attribute on the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on

      "<major>.<minor>". "receiving entity" 必须在"response stream"头中的"version"属性设置 成 "intiating entity"和自已支持的最高版本 之中较小的版本号."receiving entity" 必须将主版本号和次版本号进行算术比较,而不是简单的字符串比较。

  2. If the version number included in the response stream header is
    • at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described above, the

      initiating entity SHOULD generate an <unsupported-version/> stream error and terminate the XML stream and underlying TCP connection. 如果在"response stream"头中的版本号是比"initial stream"头中的版本号 低时,如果"initiating entity"不兼容它,就要生成一个<unsupported-version/> "stream error"并终止 XML stream 和下层的TCP连接。

  3. If either entity receives a stream header with no 'version'
    • attribute, the entity MUST consider the version supported by the other entity to be "0.0" and SHOULD NOT include a 'version' attribute in the stream header it sends in reply. 如果实体没有在流的头中找到 "version"属性,实体必须认为对端支持的版 本为"0.0",并不要在"response stream"头中包含"version"属性。

4.5. Namespace Declarations

===4.6. Stream Features===

Saint-Andre, Ed. Standards Track [Page 13]

RFC 3920 XMPP Core October 2004

4.7. Stream Errors

4.7.1. Rules

4.7.2. Syntax

<error/>节点

Saint-Andre, Ed. Standards Track [Page 14]

RFC 3920 XMPP Core October 2004

4.7.3. Defined Conditions

Saint-Andre, Ed. Standards Track [Page 15]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 16]

RFC 3920 XMPP Core October 2004

4.7.4. Application-Specific Conditions

Saint-Andre, Ed. Standards Track [Page 17]

RFC 3920 XMPP Core October 2004

4.8. Simplified Stream Examples

Saint-Andre, Ed. Standards Track [Page 18]

RFC 3920 XMPP Core October 2004

5. Use of TLS

5.1. Overview

Saint-Andre, Ed. Standards Track [Page 19]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 20]

RFC 3920 XMPP Core October 2004

5.1.1. ASN.1 Object Identifier for XMPP Address

Saint-Andre, Ed. Standards Track [Page 21]

RFC 3920 XMPP Core October 2004

5.2. Narrative

Saint-Andre, Ed. Standards Track [Page 22]

RFC 3920 XMPP Core October 2004

  1. Upon receiving the new stream header from the initiating entity,
    • the receiving entity MUST respond by sending a new XML stream header to the initiating entity along with the available features (but not including the STARTTLS feature). 在从"initiating entity"接收新的流头后,"receiving entity"必须将可用的"feature"(但 不包含"STARTTLS")一起放在旧的流头后发送回去。

5.3. Client-to-Server Example

Saint-Andre, Ed. Standards Track [Page 23]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 24]

RFC 3920 XMPP Core October 2004

5.4. Server-to-Server Example

Saint-Andre, Ed. Standards Track [Page 25]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 26]

RFC 3920 XMPP Core October 2004

6. Use of SASL

6.1. Overview

Saint-Andre, Ed. Standards Track [Page 27]

RFC 3920 XMPP Core October 2004

6.2. Narrative

Saint-Andre, Ed. Standards Track [Page 28]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 29]

RFC 3920 XMPP Core October 2004

  1. The receiving entity reports failure of the handshake by sending
    • a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity (the particular cause of failure SHOULD be communicated in an appropriate child element of the <failure/> element as defined under SASL Errors (Section 6.4)). If the failure case occurs, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2), after which it MUST terminate the TCP connection; this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect.

      • "receiving entity"发送'urn:ietf:params:xml:ns:xmpp-sasl'命名空间下的<failure/>节

      点给"initiating entity"(错误的细节将作为SASL Errors(第6.4节)下<failure/>节点的子 节点发送的)报告握手过程的错误。如果错误发生,"receiving entity "将根据配置重试适 当的次数(至少2次),之后必须中断TCP连接;

  2. The receiving entity reports success of the handshake by sending
    • a <success/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity; this element MAY contain XML character data (in SASL terminology, "additional data with success") if required by the chosen SASL mechanism. Upon receiving the <success/> element, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon sending or receiving the <success/> element). Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity, along with any available features (but not including the STARTTLS and SASL features) or an empty <features/> element (to signify that no additional features are available); any such additional features not defined herein MUST be defined by the relevant extension to XMPP.

      • "receiving entity"发送'urn:ietf:params:xml:ns:xmpp-sasl'命名空间下的<failure/>节

      点给"initiating entity"报告握手过程成功。如果选择的SASL机制的需要的话,这个节点可

      能包含XML数据。在收到<success/>节点后,"initiating entity"发送一个打开"XML stream" 的头给"receiving entity"(在"receiving entity"和"initiating entity"在发送或收到<success/> 节点后必须认为流关闭后,它不一定要先发送一个</stream> tag,)来初始化新的流。在从 "initiating entity"收到一个新的流头后,"receiving entity"必须发送一个新的"xml stream" 头给"initiating entity"来响应,以及所有可用的"features"(不包括STARTTLS 和 SASL的 "features")或一个空的<features/>节点( 表示没有可用的"features");。

6.3. SASL Definition

Saint-Andre, Ed. Standards Track [Page 30]

RFC 3920 XMPP Core October 2004

6.4. SASL Errors

Saint-Andre, Ed. Standards Track [Page 31]

RFC 3920 XMPP Core October 2004

6.5. Client-to-Server Example

Saint-Andre, Ed. Standards Track [Page 32]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 33]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 34]

RFC 3920 XMPP Core October 2004

===6.6. Server-to-Server Example===

Saint-Andre, Ed. Standards Track [Page 35]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 36]

RFC 3920 XMPP Core October 2004

7. Resource Binding

Saint-Andre, Ed. Standards Track [Page 37]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 38]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 39]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 40]

RFC 3920 XMPP Core October 2004

8. Server Dialback

8.1. Overview

Saint-Andre, Ed. Standards Track [Page 41]

RFC 3920 XMPP Core October 2004

8.2. Order of Events

Saint-Andre, Ed. Standards Track [Page 42]

RFC 3920 XMPP Core October 2004

   Originating               Receiving
     Server                    Server
   ___________               ____________
       |                         |
       |   establish connection  |
       | ______________________> |
       |                         |
       |   send stream header    |
       | ______________________> |
       |                         |
       |   send stream header    |
       | <______________________ |
       |                         |                   Authoritative
       |   send dialback key     |                       Server
       | ______________________> |                   _____________
       |                         |                         |
                                 |   establish connection  |
                                 | ______________________> |
                                 |                         |
                                 |   send stream header    |
                                 | ______________________> |
                                 |                         |
                                 |   send stream header    |
                                 | <______________________ |
                                 |                         |
                                 |   send verify request   |
                                 | ______________________> |
                                 |                         |
                                 |   send verify response  |
                                 | <______________________ |
                                 |
       |  report dialback result |
       | <______________________ |
       |                         |

8.3. Protocol

Saint-Andre, Ed. Standards Track [Page 43]

RFC 3920 XMPP Core October 2004

  1. The Originating Server sends a stream header to the Receiving
    • Server:

    <stream:stream

    Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports dialback. If the namespace name is incorrect, then

    the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.

  2. The Receiving Server SHOULD send a stream header back to the
    • Originating Server, including a unique ID for this interaction:

    <stream:stream

    Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Originating

    Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. Note well that the Receiving Server SHOULD reply but MAY silently terminate the XML stream and underlying TCP connection depending on security policies in place; however, if the Receiving Server desires to proceed, it MUST send a stream header back to the Originating Server.

  3. The Originating Server sends a dialback key to the Receiving
    • Server:

    <db:result

    • to='Receiving Server'

      from='Originating Server'>

    • 98AF014EDC0...

    </db:result> Note: This key is not examined by the Receiving Server, since the Receiving Server does not keep information about the Originating Server between sessions. The key generated by the Originating Server MUST be based in part on the value of the ID provided by the

Saint-Andre, Ed. Standards Track [Page 44]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 45]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 46]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 47]

RFC 3920 XMPP Core October 2004

9. XML Stanzas

9.1. Common Attributes

9.1.1. to

Saint-Andre, Ed. Standards Track [Page 48]

RFC 3920 XMPP Core October 2004

9.1.2. from

Saint-Andre, Ed. Standards Track [Page 49]

RFC 3920 XMPP Core October 2004

9.1.3. id

9.1.4. type

9.1.5. xml:lang

Saint-Andre, Ed. Standards Track [Page 50]

RFC 3920 XMPP Core October 2004

9.2. Basic Semantics

9.2.1. Message Semantics

9.2.2. Presence Semantics

9.2.3. IQ Semantics

Saint-Andre, Ed. Standards Track [Page 51]

RFC 3920 XMPP Core October 2004

   Requesting                 Responding
     Entity                     Entity
   ----------                 ----------
       |                           |
       | <iq type='get' id='1'>    |
       | ------------------------> |
       |                           |
       | <iq type='result' id='1'> |
       | <------------------------ |
       |                           |
       | <iq type='set' id='2'>    |
       | ------------------------> |
       |                           |
       | <iq type='error' id='2'>  |
       | <------------------------ |
       |                           |

Saint-Andre, Ed. Standards Track [Page 52]

RFC 3920 XMPP Core October 2004

  1. An IQ stanza of type "get" or "set" MUST contain one and only one
    • child element that specifies the semantics of the particular request or response. 一个"get"或"set"类型的IQ stanza必须含有一个且仅有一个子节点,来指定请 求或响应的语义。
  2. An IQ stanza of type "result" MUST include zero or one child
    • elements.
      • 一个"result"类型的IQ stanza必须包含零个或一个子节点。
  3. An IQ stanza of type "error" SHOULD include the child element
    • contained in the associated "get" or "set" and MUST include an

      <error/> child; for details, see Stanza Errors (Section 9.3). 一个"error"类型的IQ stanza将含有关于"get" 或 "set"的子节点,并必须包含一 个<error/>子节点;详细信息见Stanza Errors (第 9.3 节).

9.3. Stanza Errors

9.3.1. Rules

Saint-Andre, Ed. Standards Track [Page 53]

RFC 3920 XMPP Core October 2004

9.3.2. Syntax

Saint-Andre, Ed. Standards Track [Page 54]

RFC 3920 XMPP Core October 2004

9.3.3. Defined Conditions

Saint-Andre, Ed. Standards Track [Page 55]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 56]

RFC 3920 XMPP Core October 2004

9.3.4. Application-Specific Conditions

Saint-Andre, Ed. Standards Track [Page 57]

RFC 3920 XMPP Core October 2004

10. Server Rules for Handling XML Stanzas

10.1. No 'to' Address

10.2. Foreign Domain

Saint-Andre, Ed. Standards Track [Page 58]

RFC 3920 XMPP Core October 2004

10.3. Subdomain

10.4. Mere Domain or Specific Resource

10.5. Node in Same Domain

Saint-Andre, Ed. Standards Track [Page 59]

RFC 3920 XMPP Core October 2004

  1. If the JID is of the form <node@domain> and there exists at least

    • one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources, according to application-specific rules (a set of delivery rules for instant messaging and presence applications is defined in [XMPP-IM]).

      如果JID形如<node@domain>,并且存在至少一个到这个节点的连接"resource", 接收者服务器依照application-specific"规则( 见XMPP-IM),至少将传递它到连接 "resource"中的一个。

11. XML Usage within XMPP

11.1. Restrictions

11.2. XML Namespace Names and Prefixes

Saint-Andre, Ed. Standards Track [Page 60]

RFC 3920 XMPP Core October 2004

11.2.1. Streams Namespace

11.2.2. Default Namespace

Saint-Andre, Ed. Standards Track [Page 61]

RFC 3920 XMPP Core October 2004

11.2.3. Dialback Namespace

11.3. Validation

11.4. Inclusion of Text Declaration

11.5. Character Encoding

12. Core Compliance Requirements

Saint-Andre, Ed. Standards Track [Page 62]

RFC 3920 XMPP Core October 2004

12.1. Servers

12.2. Clients

Saint-Andre, Ed. Standards Track [Page 63]

RFC 3920 XMPP Core October 2004

13. Internationalization Considerations

14. Security Considerations

14.1. High Security

14.2. Certificate Validation

Saint-Andre, Ed. Standards Track [Page 64]

RFC 3920 XMPP Core October 2004

14.3. Client-to-Server Communications

Saint-Andre, Ed. Standards Track [Page 65]

RFC 3920 XMPP Core October 2004

14.4. Server-to-Server Communications

Saint-Andre, Ed. Standards Track [Page 66]

RFC 3920 XMPP Core October 2004

14.5. Order of Layers

14.6. Lack of SASL Channel Binding to TLS

14.7. Mandatory-to-Implement Technologies

Saint-Andre, Ed. Standards Track [Page 67]

RFC 3920 XMPP Core October 2004

14.8. Firewalls

14.9. Use of base64 in SASL

14.10. Stringprep Profiles

Saint-Andre, Ed. Standards Track [Page 68]

RFC 3920 XMPP Core October 2004

15. IANA Considerations

15.1. XML Namespace Name for TLS Data

15.2. XML Namespace Name for SASL Data

Saint-Andre, Ed. Standards Track [Page 69]

RFC 3920 XMPP Core October 2004

15.3. XML Namespace Name for Stream Errors

15.4. XML Namespace Name for Resource Binding

15.5. XML Namespace Name for Stanza Errors

15.6. Nodeprep Profile of Stringprep

Saint-Andre, Ed. Standards Track [Page 70]

RFC 3920 XMPP Core October 2004

15.7. Resourceprep Profile of Stringprep

15.8. GSSAPI Service Name

15.9. Port Numbers

16. References

16.1. Normative References

Saint-Andre, Ed. Standards Track [Page 71]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 72]

RFC 3920 XMPP Core October 2004

16.2. Informative References

Saint-Andre, Ed. Standards Track [Page 73]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 74]

RFC 3920 XMPP Core October 2004

Appendix A. Nodeprep

A.1. Introduction

A.2. Character Repertoire

A.3. Mapping

A.4. Normalization

Saint-Andre, Ed. Standards Track [Page 75]

RFC 3920 XMPP Core October 2004

A.5. Prohibited Output

A.6. Bidirectional Characters

Appendix B. Resourceprep

B.1. Introduction

Saint-Andre, Ed. Standards Track [Page 76]

RFC 3920 XMPP Core October 2004

B.2. Character Repertoire

B.3. Mapping

B.4. Normalization

Saint-Andre, Ed. Standards Track [Page 77]

RFC 3920 XMPP Core October 2004

B.5. Prohibited Output

B.6. Bidirectional Characters

Appendix C. XML Schemas

C.1. Streams namespace

Saint-Andre, Ed. Standards Track [Page 78]

RFC 3920 XMPP Core October 2004

Saint-Andre, Ed. Standards Track [Page 79]

RFC 3920 XMPP Core October 2004

C.2. Stream error namespace

Saint-Andre, Ed. Standards Track [Page 80]

RFC 3920 XMPP Core October 2004