Page 1

Network-Centric Operations Industry Consortium (NCOIC) Instant Messaging Protocol Functional Collection (IM PFC) Version 1.0 January 5th 2007

Dr. Frank Miller – Rockwell Collins M. Francois-Xavier Lebas – Thales Dr. Allen Jones – Boeing Instant Messaging Protocol Functional Collection (IM PFC) version 1.0 Document Number: NCOIC_IMPFC_0602 Published by the Network Centric Operations Industry Consortium, January 2007 http://www.ncoic.org/ Copyright © 2007, Network Centric Operations Industry Consortium Inc. This document, or portions of it, may be copied and displayed for any purpose without charge, provided that this copyright notice and rights statement is included in any such copy, and this document or excerpts from this document are reproduced without alteration.

Approved for Public Release NCOIC Aug 06-113-1 (v1.0)


Table of Contents 1

2

Introduction................................................................................................................. 3 1.1

Document Overview ...................................................................................................... 3

1.2

Support Service (PFC) Selection ................................................................................... 6

Protocol Descriptions.................................................................................................. 7 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5

2.2 2.2.1 2.2.2

2.3

3

XMPP/Jabber ................................................................................................................. 7 Overview ................................................................................................................................ 7 Server...................................................................................................................................... 7 Client ...................................................................................................................................... 8 Gateway.................................................................................................................................. 8 Network .................................................................................................................................. 8

SIMPLE ......................................................................................................................... 8 Primary Products and Guidelines ........................................................................................... 9 Overview ................................................................................................................................ 9

Other ............................................................................................................................ 10

Interoperability.......................................................................................................... 11 3.1

General ......................................................................................................................... 11

3.2

Global Aspects (Definitions and Performance Factors)............................................... 11

3.2.1 3.2.2 3.2.3 3.2.4

Addressing............................................................................................................................ 11 Information Assurance.......................................................................................................... 12 Mobility ................................................................................................................................ 14 Quality-of-Service (QoS)...................................................................................................... 15

3.3

Discovery & Registration............................................................................................. 16

3.4

Management................................................................................................................. 17

3.4.1 3.4.2 3.4.3 3.4.4 3.4.5

3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 3.5.7 3.5.8 3.5.9

Faults, Configuration, Accounting, Performance, and Security (FCAPS)............................ 17 Network Design.................................................................................................................... 17 Network Configuration......................................................................................................... 17 Network Monitoring ............................................................................................................. 17 Network Maintenance........................................................................................................... 17

Jabber/XMPP and SIMPLE Feature Comparison........................................................ 18 Introduction .......................................................................................................................... 18 Basic Instant Messaging and Presence ................................................................................. 18 Privacy and Security............................................................................................................. 18 Internationalization............................................................................................................... 19 Intermediate Instant Messaging ............................................................................................ 19 Advanced Messaging............................................................................................................ 20 Extended Presence................................................................................................................ 21 Multimedia ........................................................................................................................... 22 Conclusions .......................................................................................................................... 22

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 2


1 Introduction 1.1 Document Overview This document describes the Protocol Functional Collection (PFC) for Instant Messaging (IM) Network Applications. The collection contained herein is characterized with respect to the Network Centric Operations (NCO) Industry Consortium (NCOIC) Interoperability Framework (NIF) parameters, referred to as “Global Aspects� in a later section. The contents of this document meet the intent defined in the NIF Communications document version 1.0. Consideration of some of the comments received during the initial preparation of the IM PFC has been deferred to future revisions. The development of this IM PFC followed the NCOIC systems engineering process and the NIF Communications version 1.0 process. These processes begin with mission requirements identification by the NCOIC Customer Requirements Functional Team; this identification is documented in Operational Descriptions (ODs). The OD characterizes scenarios requiring interoperability between systems which themselves may become nodes in a System of Systems or Federated System. Guidance contained in the OD may reflect a need for services, bridges, wrappers, or other capabilities that could be defined by one or more User Applications (UA). The OD and postulated UAs will be subjected to Systems, Capabilities, Operations, Programs, and Enterprises (SCOPE) analyses that result in identification of a need for a collection of functional protocols that may include an Instant Messaging capability for a given mission.

IM PFC

Figure 1 illustrates how protocols discussed in this document fit into the NIF Technical Model 1 . The dashed line indicates that the network protocols, while not explicitly tied to Instant Messaging, are needed to provide addressing information. This model contains software described in the application, infrastructure, transport, network, and data link layers. It also includes hardware and software in the Application physical layer. Infrastructure

Network Data Link Physical

Global Attributes

Transport

Figure 1: Instant Messaging PFC in the context of the NIF Technical View

IM refers to a set of protocols that provide for the transfer of messages, generally text, between two internet participating nodes in near real-time. This document recommends use of Jabber/ Extensible Messaging and Presence Protocol (XMPP) along with SIP for Instant Messaging & Presence Leveraging Extensions (SIMPLE) as the primary base protocols upon which Instant Messaging implementations are based for NCO systems. Jabber/XMPP users include Google, the United States Navy, the Defense Information Systems Agency (DISA), the Electronic Systems Center, and the Open Geospatial Consortium.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 3


SIMPLE implementations are also deployed in commercial and military applications, including Google, the United States armed services, and DISA. Both XMPP and SIMPLE are projects accepted by the Internet Engineering Task Force (IETF). The Jabber Software Foundation (JSF) continues to develop extensions to the Jabber protocol for additional capabilities. For the purposes of this PFC, any reference to “XMPP” refers to shared standards used by both Jabber and XMPP. When “Jabber” is used in this document, it refers to the Jabber extensions developed by the JSF which have not been standardized within the IETF as of this writing. The JSF publishes extensions as XMPP Extension Protocols (XEPs). The JSF (www.jabber.org) should not be confused with Jabber, Inc. (www.jabber.com) which is a commercial entity offering products based on the Jabber/XMPP protocols developed by JSF and IETF. SIMPLE (Page Mode using MESSAGE requests) is a second protocol that is recommended if current work underway demonstrates that Jabber/XMPP and SIMPLE could interoperate. Jabber/XMPP and SIMPLE were selected as the primary protocols due to their widespread usage and non-proprietary, open character. A more detailed tradeoff comparing alternative protocols is a future enhancement. The following table provides a brief summary of the comparison performed during the selection of Jabber and XMPP protocols for this PFC.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 4


Protocol

Maturity 2

Market Acceptance 3

Open vs. Proprietary

Oscar (AIM®/ICQ®)

Mature

Over 70 million active users

Proprietary

Jabber™/XMPP

Mature

13.5 million enterprise Open and accepted users, plus an estimated 7.5 by the IETF million individual users through their ISPs

Yahoo!® Messenger

Mature

21 million active users

Proprietary

Skype™

Mature

8 million peak

Proprietary

Gadu-Gadu

Mature

5.6 million total

Proprietary

SIMPLE

Mature

Distributed in Windows XP (over 400 million copies in use 4 ) as Windows Messenger and identified as a future technology for Google™.

Open and accepted by the IETF

Windows Live™ Messenger (MSN™ Messenger)

Mature

29 million active users

Proprietary

Novell Groupwise® Messenger

Mature

Distributed with all GroupWise installations (over 26 million worldwide 5 )

Proprietary

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 5


1.2 Support Service (PFC) Selection The table below describes use of various Interoperability Capabilities for messaging, interaction and contribution. It shows use of Instant Messaging as a support service for an application with respect to other capabilities. Table 1-2 Messaging, Interaction and Contribution Capabilities. #

Capability

Primary Use

Secondary Use

Comments

1

Hypertext Transfer

Text, Imagery

Video

(Asynchronous)

2 3

File Transfer Instant Messaging

Files Text

Voice

Real time (Asynchronous) Notification

4 5

E-Mail Voice/Video-Over IP

Email Voice

Attachments Video

(session oriented) (Asynchronous) Live or archived

Web Applications CORBA

(common CODEC) Web Client Interaction Distributed Processing

(common CODEC)

6 7 8

Java Message Service

Dissemination

9

Web Services

Web Operations

(session oriented) Static Web Pages Tightly coupled systems Message oriented middleware Web Services Description Language (WSDL)

Instant Messaging is a session-based support service that is primarily used for short, bursty messages.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 6


2 Protocol Descriptions The following paragraphs describe XMPP/Jabber and SIMPLE protocols.

2.1 XMPP/Jabber 6 XMPP is a protocol for streaming Extensible Markup Language (XML) elements to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet requirements of RFC 2779 7 . XMPP is an open protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics of the protocol were developed originally within the Jabber open-source community, in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF IM and presence technology. As a result of work by the XMPP WG, the material below defines core features of XMPP 1.0. Some extensions that provide instant messaging and presence functionality defined in RFC 2779 are described in references.

2.1.1 Overview Although XMPP is not wedded to any specific network architecture, this protocol is usually implemented via a client-server architecture in which a client utilizing XMPP accesses a server over a TCP connection. Servers communicate with one another over TCP connections as well. The following diagram provides a high-level overview of this architecture (where "-" represents communications that use XMPP and "=" represents communications that use any other protocol). C1----S1---S2---C3| C2----+--G1===FN1===FC1 The symbols are as follows: o o o o o

C1, C2, C3 = XMPP clients S1, S2 = XMPP servers G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network FN1 = A foreign messaging network FC1 = A client on a foreign messaging network

2.1.2 Server A server acts as an intelligent abstraction layer for XMPP communications. The primary responsibilities of the server are: To manage connections from or sessions for other entities, in the form of XML streams to and from authorized clients, servers, and other entities To route appropriately addressed XML stanzas among such entities over XML streams

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 7


Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client, and is not routed to another entity.

2.1.3 Client Most clients connect directly to a server over a TCP connection, and use XMPP to take full advantage of the functionality provided by the server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., <node@domain/ home> vs. <node@domain/work>) as defined under Addressing Scheme. The recommended port for connections between a client and a server is 5222, as registered with the Internet Assigned Numbers Authority (IANA).

2.1.4 Gateway A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples of this service are gateways to email (see SMTP), Internet Relay Chat (see IRC), SIMPLE (see SIMPLE), Short Message Service (SMS), and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications between gateways and servers, and between gateways and the foreign messaging system, are not addressed in this document. XMPP and SIMPLE gateway technology is feasible and at least one commercial implementation has been developed.

2.1.5 Network Because each server is identified by a network address and because server-to-server communications are a straightforward extension of the client-to-server protocol, in practice, the system consists of a network of servers that inter-communicate. Thus, for example, <juliet@example.com> is able to exchange messages, presence, and other information with <romeo@example.net>. This pattern is familiar from messaging protocols (such as SMTP) that make use of network addressing standards. Communications between any two servers are optional. If enabled, such communications should occur over XML streams that are bound to TCP connections. The recommended port for connections between servers is 5269, as registered with the IANA.

2.2 SIMPLE SIMPLE is an instant messaging (IM) protocol. Like Jabber, and in contrast to the vast majority of IM software deployed today, SIMPLE is an open standard. SIMPLE applies the Session Initiation Protocol to the problems of:

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 8


â&#x20AC;˘ â&#x20AC;˘

Registering for Presence Information and receiving notifications when such events occur, for example when a user logs-in or comes back from lunch. Managing a session of real-time messages between two or more participants.

SIMPLE is IETF work in progress, taking place in the SIMPLE workgroup. Some parts have been standardized, e.g. RFC 3428 8 . Other parts, in particular IM sessions, are still under discussion. Several implementations are already available, notably the Microsoft Windows Messenger. This section describes application of the Session Initiation Protocol (SIP, RFC 3261 9 ) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has drafted an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share commonality with IMP, adaptation of SIP to IMP is a natural choice given the widespread support for (and relative maturity of) the SIP standard.

2.2.1 Primary Products and Guidelines 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM and in BCP 41. 2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. 3. An architecture for implementation of a buddy list-based instant messaging and presence application with SIP, including new mechanisms for message confirmation delivery, indications for when a party is in process of typing a message, secure buddy list manipulation operations, and extension of CPIM presence format to describe typical IM states. These mechanisms are consistent with a SIP-based architecture, as well as meeting constraints otherwise described. 4. All SIMPLE products document mappings of their operations to CPIM. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. 5. Documents will be within the framework for presence and IM described in RFC 2778. Extensions are compliant with SIP processes for extensions. Baseline SIP behavior does not modify nor define new versions of SIP for IM and Presence.

2.2.2 Overview When one user wishes to send an instant message to another, the sender formulates and issues a SIP request using the new MESSAGE method defined by this document. The request URI of this request will normally be the im: URL of the party to whom the

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 9


message is directed, but can also be a normal SIP URL. The body of the request will contain the message to be delivered. This body can be of any MIME type, including "message/cpim". 10 The request may traverse a set of SIP proxies using a variety of transport mechanism (UDP 11 , TCP, even SCTP) before reaching its destination. The destination for each hop is located using the address resolution rules detailed in the CPIM and SIP specifications. During traversal, each proxy may rewrite the request URI based on available routing information. Provisional and final responses to the request will be returned to the sender as with any other SIP request. Normally, a â&#x20AC;&#x153;200 OKâ&#x20AC;? response will be generated by the user agent of the request's final recipient. This indicates only that the user agent accepted the message, not that the user has seen it. Groups of messages in a common thread may be associated by keeping them in the same session as identified by the combination of the To, From and Call-ID headers. Other potential means of grouping messages are discussed below. It is possible that a proxy may fork a MESSAGE request based on the available routing mechanism. This SIMPLE protocol includes a mechanism that takes advantage of this, delivering messages in a session to multiple endpoints until one sends a message back. After that, all remaining messages in the session are delivered to the responding agent.

2.3 Other Other Instant Messaging Protocols that can be considered include: AIM (Oscar)

MSRP (SIMPLE)

ICQ

Y!M (Yahoo)

MSN

Gadu-Gadu

Zephyr

SILC

Novell Groupwise

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 10


3 Interoperability 3.1 General Figure 2 illustrates a block diagram showing how two Instant Messaging techniques would interoperate. This figure is drawn from the architectures for Jabber/XMPP and SIMPLE protocols as documented in the protocol standards for their respective IM protocol suite. As interoperability is achieved between the primary XMPP IM application and other IM types, one can replace SIMPLE with other types, assuming that proxies are appropriate. SIMPLE Presence Server

XMPP Server

XMPP Client

XMPP Gateway/ SIMPLE Proxy

XMPP Client

SIMPLE Proxy

SIMPLE Client

SIMPLE Client

Figure 2: Combined Jabber/XMPP and SIMPLE IM Reference Architecture

The Jabber/XMPP IM protocols consist of three element types, Clients, Servers, and Gateways. Each Client can source and sink messages. Each Server relays messages between Clients and from/to Gateways and handles presence information. The Gateway provides transformations between Jabber/XMPP and other IM protocols. SIMPLE employs four elements types, Clients, Proxies, Presence Servers, and Gateways. Each Client can source and sink messages. A Proxy serves relays messages between Clients and/or Gateways. SIMPLE defines separable Presence Servers to maintain presence about Client users. Gateways provide transformations between SIMPLE and other IM protocols.

3.2 Global Aspects (Definitions and Performance Factors) This section details how the IM protocols reflect the NIF version 1.0 Global Aspects.

3.2.1 Addressing Jabber/XMPP uses a Uniform Resource Indicator (URI) based address. This address takes the general form: [ node "@" ] domain [ "/" resource ] This three-level address contains a mandatory domain part, an optional node part, and an optional resource part. The domain identifier is the primary identifier and is the only Approved for Public Release NCOIC Aug 06-113-1(v1.0) 11


required element of a Jabber Identifier (JID). It usually represents the network gateway or primary server to which other entities connect for XML routing and data management capabilities. The node identifier is an optional secondary identifier that represents the entity requesting and using network access provided by the server or gateway (i.e., a client), although it can also represent other kinds of entities (e.g., a chat room associated with a multi-user chat service). The resource identifier is an optional tertiary identifier that may modify either a <node@domain> or a mere <domain> address. It usually represents a specific session, connection (e.g., a device or location), or object (e.g., a participant in a multi-user chat room) belonging to the entity associated with a node identifier. An example of a Jabber/XMPP URI is: chat@rockwellcollins.com/fwmiller SIMPLE also uses a URI based address that is derived from the URIs used for the Session Initiation Protocol (SIP). The address takes the general form: ("sip:" | “sips”) [ userinfo ] hostport uri-parameters [ headers ] The URI is prefaced by either the “sip:” or “sips:” prefix. The main required portion is the hostport part which specifies an internet host and transport port number. The userinfo portion identifies an instance of a UA on the host. The URI can also be qualified with uri-parameters and headers. An example of a SIMPLE URI is: sip:fwmiller@rockwellcollins.com

3.2.2 Information Assurance This section discusses how each of the protocols is affected by the various Information Assurance (IA) Global Aspects.

3.2.2.1 Confidentiality Like all security services, Confidentiality is an option for instant messaging. When a security service is required, XMPP can make use of Transport Layer Security (TLS) 12 to encrypt messages streams, whereas SIMPLE relies on SIP mechanisms for encryption. SIP may use TLS to encrypt signaling messages, including MESSAGE requests used to implement IM. SIP also supports S/MIME for message level encryption for the body of SIP requests and this mechanism can be used to encrypt IM message contents. Access Controls must be implemented by the Client Element programs and by Authentication of the Clients by the Server Elements. Authentication of Clients by Servers is discussed below.

3.2.2.2 Integrity Both Jabber/XMPP and SIMPLE rely on underlying protocol for integrity checks. XMPP uses a combination of TCP, TLS, and SASL 13 . TCP implementations provide

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 12


CRC checksums for their payloads by default, although checksums do not imply security. TLS uses TCP for transport. SIMPLE also specifies the use of TCP and TLS for transport layer security. SIMPLE can also make use of UDP for transport. UDP has the ability to perform a CRC checksum over its payload but this option is often not turned on. Also, if UDP is used for transport, the use of TLS and SASL is not an option. It is recommended that TCP be used for these reasons. SIMPLE can also make use of S/MIME to assist integrity of the MESSAGE request bodies. TLS provides a level of cryptographic integrity. Refer to encryption algorithms for transport layer protocols for more information. In addition, SIMPLE uses S/MIME for the MESSAGE request body which provides for the use of cryptographic algorithms such as Advanced Encryption Standard (AES). SIMPLE and XMPP have the capability to carry digital signatures to provide an additional level of integrity to verify the source of the message. XMPP does not have methods for distributing or remotely validating certificates. Effective use of certificates is very likely to require integration with other IA-related standards.

3.2.2.3 Availability Availability in Jabber/XMPP is based on availability of Server and Gateway elements. Availability in SIMPLE has two facets. When using the system in a centralized mode, where the Proxy and Presence Servers are used to facilitate IM conversations, Availability is based on the availability of the client and server elements. When used for point-to-point IM conversations, overall availability is only dependent on the availability of individual Client elements. There are no specific features within the protocols that provide additional availability capabilities.

3.2.2.4 Non-repudiation SIMPLE and XMPP have the capability to carry digital signatures. XMPP does not have methods for distributing or remotely validating certificates, hence effective use of certificates is likely to require integration with other IA-related standards. Both Jabber/XMPP and SIMPLE provide for Server based IM conversations. During Server based conversations, the Servers can maintain records of the conversations that can be used for non-repudiation.

3.2.2.5 Authentication Jabber/XMPP provides for authentication of Clients before they can forward messages to other Clients through Servers using SASL between the Client and the Server. SIMPLE provides also provides for simple challenge/response authentication of MESSAGE requests. This mechanism uses the SIP outbound proxy authentication mechanism. Authentication is generally not available for Client-to-Client IM communications.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 13


3.2.3 Mobility This section discusses implications of mobility on the Instant Messaging protocols.

3.2.3.1 Connected vs. Disconnected To support Connected Mobility, these protocols must provide continuous operations as the endpoint computers change physical locations. Connected Mobility implies that the IM conversation can survive as the IP addresses of one or both Client endpoints changes. Neither Jabber/XMPP nor SIMPLE supports Connected Mobility unless the underlying network allows mobility without changing the IP addresses of the various reference architecture elements. One scenario that supports Connected Mobility has the Clients connected over cellular telephone network connections and the Server elements remaining immobile with respect to IP addressing changes. To support Disconnected Mobility, the endpoints must be able to disconnect from the network and resume operations after reconnecting at a different location. Jabber/XMPP supports Disconnected Mobility by forcing the Client to login again from the new location. All subsequent conversations take place to the new location. In progress conversations are lost but can be quickly reestablished after reconnection. SIMPLE supports a similar operational paradigm for Proxy/Presence Server based conversations. For Client-to-Client conversations, a mechanism such as the Mobile IP protocol must be used to mask the change in location. This approach essentially uses Mobile IP to implement the handling of the change in location that the Proxy/Presence Server is handling.

3.2.3.2 Application Transparency vs. Awareness Application Transparency vs. Awareness for IM refers to whether the IM protocols need to be notified and/or take action when connectivity changes occur, specifically due to a change in network location. Neither Jabber/XMPP nor SIMPLE is application transparent. Both require either a new login or an update to addressing information to reestablish communications as mobility occurs.

3.2.3.3 Addressing Changes Jabber/XMPP and SIMPLE protocols are address aware at both the transport and network layers. In both protocol suites, changes to any of these addresses require that any in progress conversations be terminated and restarted using the new addresses.

3.2.3.4 Connection Maintenance Jabber/XMPP makes use of TCP connections. If mobility affecting Layer 3 causes a dropped connection, the connection must be reestablished. If mobility preserves the IP address, the TCP connection will not be dropped. Any TLS session and SASL associations must also be reestablished if the TCP connection is dropped. XMPP binds directly to TCP in the core specification, so the TCP session must remain open for the entire duration of the chat/conversation. Jabber does define a protocol extension (XEP-

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 14


0124) allowing transport over HTTP, so that individual messages are carried using HTTP and are more robust in environments such as mobile networks, allowing for better recovery if a TCP session is broken. SIMPLE is similar when using TCP. SIMPLE also uses UDP which is a connectionless protocol for transport that does not require connection maintenance.

3.2.4 Quality-of-Service (QoS) This section defines the various QoS measurements that are relevant to the IM protocols.

3.2.4.1 Availability Availability for Jabber/XMPP is defined by the availability of the Server and Client Elements. Availability for SIMPLE is defined by the availability of the Proxy/Presence Server and Client Elements. Neither Jabber/XMPP nor SIMPLE contains any unique availability features that would affect the normal methods of determining availability.

3.2.4.2 Response Time IM Response Time is not a relevant QoS measurement due to lack of a real time messaging requirement.

3.2.4.3 Delay and Round Trip Delay IM delay is defined by the time, in seconds, it takes a message to travel from one client to another. Round-trip delay is defined as the time it takes for any acknowledgements (if they are used by the protocol) to be returned in response to a message being sent from one client to another.

3.2.4.4 Jitter IM Jitter is not a relevant QoS measurement. The infrastructure elements that support IM â&#x20AC;&#x201C; such as networks, communications media, and servers â&#x20AC;&#x201C; will be the primary drivers of Jitter. The PFCs associated with these elements should address Jitter.

3.2.4.5 Throughput (Offered) and Goodput (Carried) IM Throughputs and Goodputs are relevant to the Client and Server Elements in the Reference Architecture. Throughput and Goodput rates can be specified for these elements in messages/second and in total simultaneous conversations supported.

3.2.4.6 Transaction Rate IM Transaction Rate is not a relevant QoS measurement for IM.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 15


3.2.4.7 Locking IM Locking is not a relevant QoS measurement for IM.

3.2.4.8 Connect Time Connect Time for IM is defined as the time it takes to logon and authenticate a Client with a Server Element in seconds.

3.2.4.9 Idle Time Idle time is not a relevant QoS measurement for IM.

3.2.4.10

Graceful Degradation

Graceful Degradation is relevant to Server Elements only. The protocols do not contain any policies for message shedding, but do support error messaging to indicate a resource constraint by the server. Any message shedding policies would be manifested in specific implementation of the protocol to shed load as Server Elements reach capacity.

3.2.4.11

Preemption

Preemption is not a relevant QoS measure for IM. The Jabber/XMPP and SIMPLE protocols do no provide any specific provisions for preemption. For IM, preemption will be a function of the underlying network, communications, and server elements.

3.2.4.12

Speech/Video Quality

Speech/Video Quality is not a relevant QoS measurement for IM which is a text-based collaboration method. Speech/Video capabilities are either supported or planned for both protocols, they are separate collaboration methods outside the scope of this PFC.

3.3 Discovery & Registration Discovery and Registration are functions that generally fall outside of the IM protocols. Jabber/XMPP does not specify a specific mechanism for discovering where Servers are located on the network. Server discovery is done outside the Jabber/XMPP protocol. Once a Server has been discovered, Jabber/XMPP provides a mechanism to query for the Services available on the Server. Jabber/XMPP Clients connect to desired Servers and logon before initiating conversations. This logon registration includes the exchange of Presence Information. SIMPLE specifies a mechanism (based on the underlying SIP protocol) for discovering the locations of SIMPLE Proxy servers that uses the DNS protocol. This facility also includes some information about the specific SIP/SIMPLE services that are available by each discovered Proxy. SIMPLE does not explicitly require registration of a Client with a Proxy Server prior to forwarding IM messages.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 16


3.4 Management This section describes aspects of Network Management using IM protocols.

3.4.1 Faults, Configuration, Accounting, Performance, and Security (FCAPS) FCAPS encapsulates elements of traditional network management functions. The implementation of the Reference Architecture Elements should include the ability to manage these Network Management functions locally. Jabber/XMPP does not specify a MIB for using SNMP to manage its elements. SIP defines a MIB but that MIB does not currently cover the SIMPLE aspects of the SIP protocol.

3.4.2 Network Design The design should focus on the priorities established for specific implementation, including considerations such as reliability, availability, and latency for the Jabber/XMPP Server element. For example, in a centralized design, the issues of reliability and availability may have the highest priority, whereas a distributed design may focus on redundant paths for messages through different Proxy servers and mechanisms that allow Clients to discover other Clients.

3.4.3 Network Configuration Configuration for Clients for Jabber/XMPP and SIMPLE takes the form of local Client program settings, Server addresses and logon information, and Local Client program settings and logon information are maintained in configuration files local to the machine running the Client program. For Jabber/XMPP, it is very likely that Server addresses will be maintained locally as well. For SIMPLE, it may be necessary to store Proxy Server addresses but the DNS SRV service 14 can also be used to query for Proxy Server addresses. Presence information in both protocols is assumed to be stored centrally either on the Jabber/XMPP Server or the logical SIMPLE Presence Server.

3.4.4 Network Monitoring Neither Jabber/XMPP nor SIMPLE provides any build-in capabilities for monitoring. As mentioned in Section 3.4.1, Jabber/XMPP does not specify a MIB for using SNMP to manage its elements and while SIP defines a MIB, it does not currently cover the SIMPLE aspects of the SIP protocol.

3.4.5 Network Maintenance The protocols require maintenance of keys for authentication and encryption.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 17


3.5 Jabber/XMPP and SIMPLE Feature Comparison 15 3.5.1 Introduction This section compares the capabilities of Jabber/XMPP technologies with SIP/SIMPLE technologies. The Jabber/XMPP technologies are defined in RFCs produced by the IETF's XMPP WG and in specifications published in the Jabber Software Foundation's XEP Series. The SIP/SIMPLE technologies are defined in RFCs and Internet-Drafts produced by the IETF's SIP WG, SIMPLE WG, SIPPING WG, GEOPRIV WG, XCON WG, & MMUSIC WG. The documents referenced herein are constantly evolving and have various levels of maturity ranging from experimental (unstable standards still being defined) to well established standards. Appendix A should be consulted for the current status on any given reference. When â&#x20AC;&#x153;Unsupportedâ&#x20AC;? is indicated for a given capability, it indicates that the feature is not supported by that protocol as of the writing of this PFC.

3.5.2 Basic Instant Messaging and Presence IM and presence are core functionality for XMPP. For SIP, IM and presence are made possible through specific SIP extensions, collectively known as "SIMPLE" after the name of the IETF's SIP for Instant Messaging and Presence Leveraging Extensions Working Group. Feature

Jabber/XMPP RFC3921 16

Presence

SIP/SIMPLE RFC3856 17

Single Messages RFC3921

RFC3428

Service Discovery

XEP-0030 18

RFC3840 19

Chat Messages

RFC3921

draft-ietf-simple-message-sessions-12 20

Contact Lists

RFC3921

draft-ietf-simple-xcap-list-usage-05 21

3.5.3 Privacy and Security

Feature

XMPP

SIP/SIMPLE

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 18


Communications Blocking RFC3921 Unsupported

3.5.4 Internationalization Feature

XMPP

SIP/SIMPLE

Non-ASCII Addresses RFC3920 22 Unsupported Multilingual Messages RFC3921

Unsupported

3.5.5 Intermediate Instant Messaging Feature

Jabber

SIP/SIMPLE

Composing Indicators

XEP-0085 23

RFC3994 24

Capabilities Advertisement

XEP-0115 25

draft-ietf-simple-prescaps-ext-05 26

Service Registration

XEP-0077 27

Unsupported

Multi-User Chat

XEP-0045 28

Unsupported

Formatted Messages XHTML

XEP-0071 29

Unsupported

Offline Messages

XEP-0160 30

Unsupported

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 19


3.5.6 Advanced Messaging Feature

Jabber

SIP/SIMPLE

Workflow Forms

XEP-0004 31 Unsupported

Multiple Recipients

XEP-0033 32 Unsupported

Reliable Delivery

XEP-0079 33 Unsupported

Publish-Subscribe

XEP-0060 34 Unsupported

XML-RPC

XEP-0009 35 Unsupported

SOAP Binding

XEP-0072 36 Unsupported

Privacy Extensions

Unsupported RFC 3325 37

Privacy Mechanism

Unsupported RFC 3323 38

Content Indirection

Unsupported RFC 4483 39

Feature Conveyance

Unsupported RFC 4508 40

Communication Resource Priority

Unsupported RFC 4412 41

Stream Control Transmission Protocol Unsupported RFC 4168 42 HTTP Binding

XEP-0124 43 Unsupported

Session Timers

Unsupported RFC 4028 44

Integrated Compression

Unsupported RFC 3486 45

Security Mechanism Agreement

Unsupported RFC 3329 46

Assured Identity

Unsupported RFC 4474 47

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 20


3.5.7 Extended Presence Feature Geolocation

Jabber

SIP/SIMPLE

XEP-0080 48 RFC-4119 49

Physical Location XEP-0112 50 RFC-4119 Mood

XEP-0107 51 RFC-4480 52

Activity

XEP-0108 53 RFC-4480

Tune

XEP-0118 54 Unsupported

Invisible Presence XEP-0126 55 Unsupported

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 21


3.5.8 Multimedia Multimedia functionality refers to elements such as voice, video, file transfer, and gaming. For XMPP, such functions are documented as extensions that use XMPP for negotiation and transfer the media data outside the XMPP band. For SIP, the signaling occurs using basic SIP methods and the media data is exchanged using dedicated data transport mechanisms such as RTP. Feature

Jabber/XMPP SIP/SIMPLE XEP-0096 56

File Transfer

Unsupported

Voice Sessions Unsupported

Standard

Video Sessions Unsupported

Standard

3.5.9 Conclusions Both XMPP and SIP/SIMPLE have much to offer for interoperable and netcentric implementations of IM. With the addition of gateways the two protocols are interoperable. There are unique benefits to either approach which can be broadly summarized as follows: XMPP Benefits: • •

XMPP is a simpler protocol since it is assuming TCP only and does not handle issues in the network that may result when working with other types of networks such as those using UDP. XMPP RFCs are fewer in number, while in SIP there are dozens of RFCs that may be relevant to different aspects of the system.

SIMPLE Benefits (realized by using SIP to establish sessions): • • • •

SIP can work in any type of network and support situations where there is intermittent network connectivity. SIP is the chosen protocol for the telecomm industry. The IP Multimedia Subsystem architecture that is defined by 3rd Generation Partnership Project and is deployed by telecomm operators assumes SIP and may be used in enterprises applications. Although an XMPP extension to enable creation of voice sessions has been defined (called Jingle and based on SIP methodology), SIP is generally more powerful in: - Creating media sessions - Traversing firewalls and NATs.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 22


Network equipment manufacturers who provide Session Border Controllers, Public Switched Telephone Network gateways, firewalls and Network Address Translation all are experienced with SIP. A significant point to note is that the connectivity to the world of legacy telephony is possible using SIP but not XMPP. SIP’s many RFCs do make the protocol more complex but also shows that many aspects and features were extensively discussed and designed for SIP.

Approved for Public Release NCOIC Aug 06-113-1(v1.0) 23


Appendix A – References

Appendix A – References

1

Miller, et. al., Network-Centric Operations Industry Consortium Interoperability Framework (NIF™), January 2006 2

Maturity was judged based on age of the protocol in use (i.e., date of first inception) and level of market acceptance.

3

Exerpted from Wikipedia, http://en.wikipedia.org/wiki/Instant_messaging, 14 December 2006

4

Kirk, No effect from tardy XP service pack, IDG News Service, London Bureau, 18 January 2006

5

Bliss Consulting and Research, A Survey of Novell GroupWise Customers, July 2005

6

Exerpted from Network Working Group, P. Saint-Andre, Ed., Request for Comments: 3920, Jabber Software Foundation, Category: Standards Track, October 2004

7

Day, et. al., IETF RFC 2779: Instant Messaging / Presence Protocol Requirements, February 2000

8

Campbell, et. al., IETF RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging, December 2002

9

Rosenberg, et. al., IETF RFC 3261: Session Initiation Protocol (SIP), June 2002

10

Exerpted from Rosenberg, et. Al. Internet-Draft, SIP Extensions for Instant Messaging April 2001

11

Postel, IETF RFC 768: User Datagram Protocol (UDP), 28 August 1980

12

Dierks & Allen, IETF RFC 2246: The TLS Protocol Version 1.0, January 1999

13

Myers, IETF RFC 2222: Simple Authentication and Security Layer (SASL), October 1997

14

Gulbrandsen, et al., IETF RFC 2782: A DNS RR for specifying the location of services (DNS SRV), February 2000 15

Peter Saint-Andre, XMPP-SIMPLE Feature Comparison, Version: 0.2, 2005-12-08, Jabber Software Foundation, http://www.jabber.org/protocol/xmpp-simple.shtml

Approved for Public Release NCOIC Aug 06-113-1(v1.0)

A-1


Appendix A â&#x20AC;&#x201C; References

16

Saint-Andre, IETF RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, October 2004 17

Rosenberg, IETF RFC 3856: A Presence Event Package for the Session Initiation Protocol (SIP), August 2004

18

Hildebrand, et. al., XEP-0030: Service Discovery, Jabber Software Foundation, 24 January 2006

19

Rosenberg, et. al., IETF RFC 3840: Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), August 2004 20

Campbell, et. al., IETF Internet Draft draft-ietf-simple-message-sessions-18: The Message Session Relay Protocol, 13 December 2006 21

Rosenberg, IETF Internet Draft draft-ietf-simple-xcap-list-usage-05: Extensible Markup Language (XML) Formats for Representing Resource Lists, February 2005 22

Saint-Andre, IETF RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core, October 2004

23

Saint-Andre et. al., XEP-0085: Chat State Notifications, Jabber Software Foundation, 12 July 2006

24

Schulzrinne, IETF RFC 3994: Indication of Message Composition for Instant Messaging, January 2005

25

Hildebrand, et. al., XEP-0115: Entity Capabilities, Jabber Software Foundation, 29 October 2004

26

Lonnfors & Kiss, IETF Internet Draft draft-ietf-simple-prescaps-ext-07: Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF), July 2006

27

Saint-Andre, XEP-0077: In-Band Registration, Jabber Software Foundation, 24 January 2006

28

Saint-Andre, XEP-0045: Multi-User Chat, Jabber Software Foundation, 13 September 2006

29

Saint-Andre, XEP-0071: XHTML-IM, Jabber Software Foundation, 11 January 2006

30

Saint-Andre, XEP-0160: Best Practices for Handling Offline Messages, Jabber Software Foundation, 24 January 2006 31

Eatmon, et. al., XEP-0004: Data Forms, Jabber Software Foundation, 25 January 2006

Approved for Public Release NCOIC Aug 06-113-1(v1.0)

A-2


Appendix A â&#x20AC;&#x201C; References

32

Hildebrand & Saint-Andre, XEP-0033: Extended Stanza Addressing, Jabber Software Foundation, 15 September 2004 33

Miller & Saint-Andre, XEP-0079: Advanced Message Processing, Jabber Software Foundation, 30 November 2005 34

Millard, et. al., XEP-0060: Publish-Subscribe, Jabber Software Foundation, 13 November 2006

35

Adams, XEP-0009: Jabber-RPC, Jabber Software Foundation, 9 February 2006

36

Forno & Saint-Andre, XEP-0072: SOAP Over XMPP, Jabber Software Foundation, 14 December 2005

37

Jennings, et. al., IETF RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, November 2002

38

Peterson, IETF RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP), November 2002

39

Burger, IETF RFC 4483: A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages, May 2006 40

Levin & Johnston, IETF RFC 4508: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method, May 2006 41

Schulzrinne & Polk, IETF RFC 4412: Communications Resource Priority for the Session Initiation Protocol (SIP), February 2006 42

Rosenberg, et. al., IETF RFC 4168: The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP), October 2005 43

Paterson, et. al., XEP-0124: HTTP Binding, Jabber Software Foundation, 28 April 2006

44

Donovan & Rosenberg, IETF RFC 4028: Session Timers in the Session Initiation Protocol (SIP), April 2005

45

Camarillo, IETF RFC 3486: Compressing the Session Initiation Protocol (SIP), February 2003

46

Arkko, et. al., IETF RFC 3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP), January 2003

Approved for Public Release NCOIC Aug 06-113-1(v1.0)

A-3


Appendix A â&#x20AC;&#x201C; References

47

Peterson & Jennings, IETF RFC 4474: Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), August 2006 48

Hildebrand & Saint-Andre, XEP-0080: User Geolocation, Jabber Software Foundation, 21 August 2006

49

Peterson, IETF RFC 4119: A Presence-based GEOPRIV Location Object Format, December 2005

50

Saint-Andre, XEP-0112: User Physical Location, Jabber Software Foundation, 12 October 2004

51

Saint-Andre & Meijer, XEP-0107: User Mood, Jabber Software Foundation, 20 October 2004

52

Schulzrinne, et al., IETF RFC 4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF), July 2006 53

Meijer & Saint-Andre, XEP-0108: User Activity, Jabber Software Foundation, 20 October 2004

54

Saint-Andre, XEP-0118: User Tune, Jabber Software Foundation, 12 November 2004

55

Saint-Andre, XEP-0126: Invisibility, Jabber Software Foundation, 19 August 2005

56

Muldowney, et. al., XEP-0096: File Transfer, Jabber Software Foundation, 13 April 2004

Approved for Public Release NCOIC Aug 06-113-1(v1.0)

A-4

Instant Messaging Protocol Functional Collection  

This document describes the Protocol Functional Collection (PFC) for Instant Messaging (IM) Network Applications. The collection contained h...