}
@misc{xep-0060,
- abstract = "
-
-This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications.
-",
+ abstract = "This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications.",
author = "Millard, Peter and Saint-Andre, Peter and Meijer, Ralph",
howpublished = "http://xmpp.org/extensions/xep-0060.html",
month = jul,
year = "2012"
}
+@misc{rfc6121,
+ author = "Saint-Andre, P.",
+ howpublished = "RFC 6121 (Proposed Standard)",
+ month = mar,
+ number = "6121",
+ organization = "Internet Engineering Task Force",
+ publisher = "IETF",
+ series = "{Request for Comments}",
+ title = "{Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence}",
+ url = "http://www.ietf.org/rfc/rfc6121.txt",
+ year = 2011
+}
+
+@misc{rfc6122,
+ author = "Saint-Andre, P.",
+ howpublished = "RFC 6122 (Proposed Standard)",
+ month = mar,
+ number = "6122",
+ organization = "Internet Engineering Task Force",
+ publisher = "IETF",
+ series = "{Request for Comments}",
+ title = "{Extensible Messaging and Presence Protocol (XMPP): Address Format}",
+ url = "http://www.ietf.org/rfc/rfc6122.txt",
+ year = 2011
+}
+
\subsection{XMPP}
\todo
+\pages{3-4}
+
+The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
+XML-based protocol for real-time communication. Its core functionalities are
+specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
+extensions are usually defined by the XMPP community in \term{XMPP Extension
+Proposals (XEPs)}.
+
+\subsubsection{Addressing}
+
+Every user account in XMPP is addressed by a globally unique identifier, called
+the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
+\code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
+an XMPP server, and \code{localpart} is the name of a user account on that
+server. Since a user can be logged in from multiple clients, the \code{resource}
+part is a string chosen by the user to distinguish those clients. Only the part
+\code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
+the resource is only needed for routing between client and server.
+
+\subsubsection{Architecture}
+\begin{wrapfigure}{r}{0.4\textwidth}
+%\begin{figure}[htop]
+ \centering
+ \includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg}
+ \caption{XMPP architecture}
+%\end{figure}
+\end{wrapfigure}
+
+The original architecture underlying XMPP strongly leans on the established
+design of Internet Mail. The distributed network is formed by \term{XMPP
+servers} on one hand, which make up the always available backbone of the network
+and manage user accounts and statuses, and \term{XMPP clients} on the other
+hand, which represent a single logged-in user and make up the interface for
+communication with other users.
+
+Every client communicates only with the server that manages the respective user
+account which is configured in the client, as given in the user's JID. The
+server then routes the messages to their recipients, using the JID to determine
+the correct server for a message to be sent to. Finally, the receiving server
+sends the message to a client where the receiving JID is logged in. If the user
+is not logged in at the time the message is sent, the server can store it for
+the user and deliver it on the next login.
+
+\todo{use of DNS-SD?}
+
+\subsubsection{Communication primitives}
+
+\subsubsection{Multi-User Chats}
+
+\cite{xep-0045}
+
+\subsubsection{Publish/Subscribe and the Roster}
+
+is this really needed?
+
+\cite{xep-0060}
+
+\subsubsection{Presence}
+
+
\cite{rfc6120}
\begin{itemize}
\item architecture: client-server, use of DNS-SD
\item multi-user chats \cite{xep-0045}
\end{itemize}
-\pages{3-4}
\subsubsection{XMPP Serverless Messaging}