remove unneeded image

[skm-ma-ws1314.git] / sec-xmpp.tex

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index a89f414..15321bc 100644 (file)
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -1,53 +1,44 @@
 \subsection{XMPP}
 \subsection{XMPP}

-\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
 
 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
+specified in RFC~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}
 extensions are usually defined by the XMPP community in \term{XMPP Extension
 Proposals (XEPs)}.
 
 \subsubsection{Addressing}

+\enlargethispage{2\baselineskip}

 
 Every user account in XMPP is addressed by a globally unique identifier, called
 the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
 
 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.
+\code{localpart@domain/resource}, where \code{domain} 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 at the same time, the
+\code{resource} part is a string chosen by the user to distinguish those
+clients. Only the part \code{localpart@domain} (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.5\textwidth}
   \tikzstyle{iconlabel}=[text width=3cm, align=center, font=\footnotesize]
 
 \subsubsection{Architecture}
 \begin{wrapfigure}{r}{0.5\textwidth}
   \tikzstyle{iconlabel}=[text width=3cm, align=center, font=\footnotesize]

+  \tikzstyle{label}=[font=\footnotesize]

   \begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]
   \begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]

-    \def\nodelist{
-      juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,
-      examplenet/{(-1,1)}/XMPP server \code{example.net}/above/server,
-      imexampleorg/{(1,1)}/XMPP server \code{im.example.org}/above/server,
-      romeo/{(1,-1)}/XMPP client \code{romeo@im.example.org}/below/computer%
-    }
-    \foreach \name/\pos/\text/\tpos/\icon in \nodelist {
-      \node (\name) at \pos { \includegraphics[width=1.2cm]{icon-\icon.pdf} };
-      \node[\tpos=of \name,iconlabel] (\name text) { \text };
-    }
-    \draw[<->,dashed] (juliet) -- node[anchor=east]{s2c} (examplenet);
-    \draw[<->] (examplenet) -- node[anchor=south]{s2s} (imexampleorg);
-    \draw[<->,dashed] (imexampleorg) -- node[anchor=west]{s2c} (romeo);
+    \input{fig-xmpparch.tex}

   \end{tikzpicture}
   \centering
   \caption{XMPP architecture, showing server-to-server (s2s) and
   \end{tikzpicture}
   \centering
   \caption{XMPP architecture, showing server-to-server (s2s) and

-    server-to-client (s2c, dashed) connection types}
+    server-to-client (s2c) connections}

   \label{fig:xmpparch}
 \end{wrapfigure}
 
 The original architecture underlying XMPP strongly leans on the established
 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
 The distributed network is formed by \term{XMPP servers} on one hand, which make
   \label{fig:xmpparch}
 \end{wrapfigure}
 
 The original architecture underlying XMPP strongly leans on the established
 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
 The distributed network is formed by \term{XMPP servers} on one hand, which make

-up the always-on backbone of the network used for routing message, and manage
-user accounts and statuses. On the other hand, \term{XMPP clients} represent a
-single logged-in user and are the interface for communication with other users.
+up the always-on backbone of the network used for message routing, and which
+manage user accounts and statuses. On the other hand, \term{XMPP clients}
+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
 
 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


@@ -66,9 +57,9 @@ manages the users for the domain \code{example.org} is given by the SRV record
 
 All communication over XMPP is based on XML. To minimize communication overhead,
 only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
 
 All communication over XMPP is based on XML. To minimize communication overhead,
 only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza

-is always well-formed as a whole; it consist of a root element, which also
-includes routing attributes (\code{to} and \code{from}), and its optional child
-elements.
+is always well-formed as a whole; it consists of a root element, which in most
+cases also includes routing attributes (\code{to} and \code{from}), and its
+optional child elements.

 
 On top of that, living connections between hosts are represented by \term{XML
 streams}. The client initiates a connection by sending an XML declaration
 
 On top of that, living connections between hosts are represented by \term{XML
 streams}. The client initiates a connection by sending an XML declaration


@@ -76,25 +67,23 @@ followed by an opening \code{<stream>} tag. The server then responds also with
 an opening \code{<stream>} tag. The client then performs SASL authentication and
 binds its stream to a resource for proper addressing. If this process succeeded,
 both client and server can send an unlimited number of stanzas, until the
 an opening \code{<stream>} tag. The client then performs SASL authentication and
 binds its stream to a resource for proper addressing. If this process succeeded,
 both client and server can send an unlimited number of stanzas, until the

-connection is closed by one side by sending an closing \code{</stream>} tag. The
-other side then has the chance to send all outstanding stanzas and likewise
+connection is closed by one side by sending a closing \code{</stream>} tag. The
+other side then has the chance to send all outstanding stanzas and then likewise

 closes its stream. If both streams are closed, the underlying TCP connection is
 terminated.
 
 closes its stream. If both streams are closed, the underlying TCP connection is
 terminated.
 

-\todo[Example stream]
-

 \subsubsection{Publish/Subscribe and Presence}
 
 Typically, a user wants to chat with a more or less fixed set of other users,
 whose JIDs she needs to know, so she needs some kind of ``address book'' that
 \subsubsection{Publish/Subscribe and Presence}
 
 Typically, a user wants to chat with a more or less fixed set of other users,
 whose JIDs she needs to know, so she needs some kind of ``address book'' that

-remembers the JIDs for her. In XMPP, this is address book is called
+remembers the JIDs for her. In XMPP, this address book is called

 \term{roster}, and it also shows the users' willingness to chat (``presence'').
 In order to see their chat status (which can be  one of ``online'', ``offline'',
 and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
 the other user's status. The mechanism behind this is called
 \term{Publish-Subscribe} and is specified in XEP-0060~\cite{xep0060}. It can
 be used to notify interested users about changes in personal information, and
 \term{roster}, and it also shows the users' willingness to chat (``presence'').
 In order to see their chat status (which can be  one of ``online'', ``offline'',
 and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
 the other user's status. The mechanism behind this is called
 \term{Publish-Subscribe} and is specified in XEP-0060~\cite{xep0060}. It can
 be used to notify interested users about changes in personal information, and

-implements the classic Observer pattern.
+implements the well-known Observer pattern~\cite{GOF95}.

 
 A user publishes information by creating a \term{node} on the XMPP server, which
 acts as a handle for the data. Interested users can then query the server for
 
 A user publishes information by creating a \term{node} on the XMPP server, which
 acts as a handle for the data. Interested users can then query the server for


@@ -107,16 +96,16 @@ All communication takes place between the client and the server over \code{<iq>}
 
 \subsubsection{Multi-User Chats}
 
 
 \subsubsection{Multi-User Chats}
 

-Besides one-to-one messaging, XMPP also allows users to create multi-user
-chat rooms, which is specified in \cite{xep0045}. Each chat room is given a
-unique JID to which the users send their messages to. Each incoming message is
-then dispatched to all users which have joined the room.
+Besides one-to-one messaging, XMPP also allows users to create multi-user chat
+rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a
+unique JID on the server managing the room to which the users send their
+messages to. Each incoming message is then dispatched to all users which have
+joined the room.

 
 To join a room, the user sends a \code{<presence>} stanza to the room JID, where
 the resource part of the room JID specifies the desired nick name.
 
 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
 
 To join a room, the user sends a \code{<presence>} stanza to the room JID, where
 the resource part of the room JID specifies the desired nick name.
 
 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}

-\pages{1}

 
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} allows XMPP clients on a network to build a
 
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} allows XMPP clients on a network to build a


@@ -124,21 +113,48 @@ peer-to-peer mesh network and chat directly with each other. This feature was
 first introduced by Apple as part of their \term{Bonjour} project, and nowadays
 it is also available in many other XMPP clients.
 
 first introduced by Apple as part of their \term{Bonjour} project, and nowadays
 it is also available in many other XMPP clients.
 

-With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
-then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
-to publish instance names in the domain \code{\_presence.\_tcp.local}. For
-example, if Juliet uses her machine (named \code{capulet}) with serverless
-messaging, her client would publish the following four mDNS records:
+%\begin{wrapfigure}{R}{0.4\textwidth}
+  %\tikzstyle{iconlabel}=[text width=2cm, align=center, font=\footnotesize]
+  %\tikzstyle{label}=[font=\footnotesize]
+  %\begin{tikzpicture}[node distance=0pt,scale=1.2,>=stealth,thick]
+    %\def\nodelist{
+      %juliet/{(-1,-1)}/\code{juliet@\ balcony.local}/below/computer,
+      %tybalt/{(-1,1)}/\code{tybalt@\ montague.local}/above/computer,
+      %mercutio/{(1,1)}/\code{mercutio@\ capulet.local}/above/computer,
+      %romeo/{(1,-1)}/\code{romeo@\ romeo.local}/below/computer%
+    %}
+    %\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
+      %\node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
+      %\node[\tpos=of \name,iconlabel] (\name text) { \text };
+    %}
+    %\draw[<->,dashed] (juliet) -- (tybalt);
+    %\draw[<->,dashed] (juliet) -- (romeo);
+    %\draw[<->,dashed] (juliet) -- (mercutio);
+    %\draw[<->,dashed] (romeo) -- (mercutio);
+    %\draw[<->,dashed] (romeo) -- (tybalt);
+    %\draw[<->,dashed] (mercutio) -- (tybalt);
+  %\end{tikzpicture}
+  %\centering
+  %\caption{XMPP architecture with Serverless Messaging}
+  %\label{fig:xmpparch2}
+%\end{wrapfigure}
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on their host,
+and then rely on mDNS and DNS-SD (see Section~\ref{sec:dns}) to publish instance
+names in the domain \code{\_presence.\_tcp.local}. For example, if Juliet uses
+her machine (named \code{capulet}) with serverless messaging, her client would
+publish the following four mDNS records:

 
 \begin{itemize}
   \item an A record \code{capulet.local}, specifying her IP address,
   \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
 
 \begin{itemize}
   \item an A record \code{capulet.local}, specifying her IP address,
   \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying

-    the port on which her XMPP client listens, and refering to
+    the port on which her XMPP client listens, and referring to

     \code{capulet.local} as the host name
   \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
     pointing to \code{juliet@capulet.\_presence.\_tcp.local}
   \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
     \code{capulet.local} as the host name
   \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
     pointing to \code{juliet@capulet.\_presence.\_tcp.local}
   \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying

-    more information about her (e.~g. her online status, contact data, etc.)
+    more information about her (e.~g. her online status, contact data, etc.) in
+    standardized key-value pairs.

 \end{itemize}
 
 When other clients in the same network enumerate the available services by
 \end{itemize}
 
 When other clients in the same network enumerate the available services by