adfa_idn_chat chat comet eclipse ietf im instant_messaging instantmessaging location messenger-business mobile msrp oma pikaviestimet presence protocol protocols protokollat push rfc rfc3428 server simple sip spec standards sätti voip xmpp

My tags:

From Wikipedia, the free encyclopedia

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP · RARP · NDP · OSPF · Tunnels (L2TP) · Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) · Device Drivers · (more)
This box: view • talk • edit

SIMPLE, the Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP) managed by the IETF.^[1] Like XMPP, and in contrast to the vast majority of IM and presence protocols used by software deployed today, SIMPLE is an open standard.

Contents 1 Purpose 2 Technical description 2.1 Presence 2.2 IM 3 References 4 External links

[edit] Purpose

SIMPLE applies SIP to the problems of:

• registering for presence information and receiving notifications when such events occur, for example when a user logs-in or comes back from lunch;
• sending short messages, analogous to SMS or two-way paging;
• managing a session of real-time messages between two or more participants.

Implementations of the SIMPLE based protocols can be found in SIP Softphones and also in SIP Hardphones.

[edit] Technical description

[edit] Presence

The SIMPLE presence specifications can be broken up into:

• The core protocol machinery. This provides the actual SIP extensions for subscriptions, notifications and publications. RFC 3265 defines the SUBSCRIBE and NOTIFY methods. SUBSCRIBE allows to subscribe to an event on a server, the server responds with NOTIFY whenever the event come up. RFC 3856 defines how to make use of SUBSCRIBE/NOTIFY for presence. Two models are defined: an end-to-end model in which each User Agent handles presence subscriptions itself; and a centralized model. The latter introduces the concept of a presence server; all subscriptions are handled by this server. The message PUBLISH (RFC 3903) allows User Agents to inform the presence server about their subscription states.

• Presence documents. The presence information is coded in XML documents, that are carried in the bodies of the respective SIP messages. RFC 3863 and RFC 4479 describe this procedure, RFC 4480 (RPID), RFC 4481, RFC 4482 (CPID) and various drafts describe contents and formats of the presence documents.

• Privacy, policy and provisioning. If the centralized model is used, the User Agents need a way to define who may subscribe to which amount of their presence information. RFC 4745 and RFC 5025 define a framework for authorization policies controlling access to application-specific data. The XCAP protocol (RFC 4825), carried by HTTP, allows User Agents to communicate their presence rules to a XCAP server, which rules the information exposed by the presence server. RFC 3857 and RFC 3858 define a subscription event "watcher info". User Agents may subscribe to this event to be informed who is subscribing to their presence information.

[edit] IM

SIP defines two modes of instant messaging:

• The Page Mode makes use of the SIP method MESSAGE, as defined in RFC 3428. This mode establishes no sessions.

• The Session Mode. The Message Session Relay Protocol (RFC 4975, RFC 4976) defines text-based protocol for exchanging arbitrarily sized content of any time between users. An MSRP session is set up by exchanging certain information, such as an MSRP URI, within SIP and SDP signaling.

[edit] References

1. ^ SIMPLE Working Group

[edit] External links

• Rich Presence - A New User Communications Experience Technology White Paper