rename files

diff --git a/address-allocation.tex b/address-allocation.tex
deleted file mode 100644 (file)
index 4198074..0000000
--- a/address-allocation.tex
+++ /dev/null
@@ -1,73 +0,0 @@
-\subsection{Address allocation}
-Considering the TCP/IP protocol suite, in order to be able to communicate on the
-IP layer, a device needs to configure one of its network interfaces with
-an IP address that can be reached from the network that the device wants to connect
-to. There are several ways of achieving this:
-
-\begin{itemize}
-  \item The IP address is pre-selected by a human and stored in the device
-    configuration. This process is cumbersome when more than one device needs to
-    be configured, and humans have to remember which addresses are configured on
-    which device, and which addresses are still free to use on additional
-    devices.
-
-  \item Deploying a central server that assigns network addresses
-    to the devices in the network, which in order query the server (for example
-    via broadcast or on a lower layer) for a unique address before they use the
-    IP layer for the first time. This technique supersedes the dependency of
-    human memory for mapping IP addresses to devices, and can easily be combined
-    with additional central configuration management, like the automatic
-    assignment of a static gateway, or a DNS resolver.\\
-    The DHCP protocol is one example of central IP address management.
-
-  \item A third alternative is the use of a distributed protocol which enables
-    the devices on the network to choose addresses in accordance with other
-    devices on the same network, so no IP address is used more than once. In
-    respect to the Internet of Things, this approach has the advantage that
-    those devices can easily be used in different scenarios without needing
-    central deployment at all, and also allowing them to change their addresses
-    dynamically, therefore easily reacting to changes in the network. \\
-    There are two major protocols which are used for dynamic configuration of IP
-    addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
-    used, and in IPv6 networks, Stateless Address
-    Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every
-    device.
-
-\end{itemize}
-
-\paragraph{IPv4 Link-Local Addressing}
-
-\term{Link-Local Addressing}, also known as \term{Automatic Private IP
-Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet
-\code{169.254.0.0/16} for addressing. Every device first chooses a random
-address from that address space.  Then it checks if the chosen address is used
-by any other device on the network by probing the chosen address, which is
-usually done using the ARP protocol. If the probing process results that the
-address is not used on the network (e.~g.  no device returned an ARP response
-during a random time interval), the device claims its chosen address and uses it
-for communication on the IPv4 layer. If the chosen address is already used, the
-  device continues the process, subsequently choosing a new random address and
-  trying to claim it, until a free address has been found.
-
-\paragraph{IPv6 Stateless Address Autoconfiguration}
-
-Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6
-Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet
-\code{fe80::/64}. First, an \term{interface identifier} is generated using the
-interface's MAC address. Since MAC addresses must be unique in the network, a
-unique IPv6 address is obtained by combining the subnet prefix and the interface
-identifier. To ensure that no other device exists with this generated IPv6
-address, the device performs \term{Duplicate Address Detection} on the network
-through \term{Neighbor Advertisement} messages and listening for \term{Neighbor
-Solicitation} messages. If such messages are received from other hosts, the
-configured address cannot be used by the device and must be discarded.
-Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC
-addresses are unique on the network.
-
-In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
-Autoconfiguration can also be used with a central server. In this case, a
-central server broadcasts \term{Router Solicitation} messages on the network
-which contain a global network prefix. The hosts on the network can then use
-that prefix instead to configure a global IPv6 address.
-
-% vim: set ft=tex et ts=2 sw=2 :

diff --git a/dns-extensions.tex b/dns-extensions.tex
deleted file mode 100644 (file)
index c4c84e3..0000000
--- a/dns-extensions.tex
+++ /dev/null
@@ -1,82 +0,0 @@
-\subsection{Extensions to the Domain Name System}\label{sec:dns}
-
-In a distributed context, it is often not feasible to rely on a central,
-authoritative DNS server, and there is usually no easy way to discover services.
-The first problem is addressed with \term{Multicast DNS}, and since DNS is
-basically a key-value store, it can also be used for service discovery, which is
-achieved using \term{DNS-Based Service Discovery}. Both techniques were first
-developed by Apple as part of the \term{Bonjour} project, and are now maintained
-by the IETF Zeroconf working group.
-
-\subsubsection{Multicast DNS}
-
-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
-Name System that allows DNS resource records to be distributed on multiple hosts
-in a network, therefore avoiding central authorities and enabling every host to
-publish its own entries. For that purpose, a special domain, usually
-named \code{.local}, is used.
-
-Software that supports mDNS listens on the reserved
-link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
-\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries.
-Queries sent to those multicast address and port are standard DNS queries.
-If a host receives a query and knows about the queried resource, it responds to the
-querying host with a standard DNS response. The querying host can then simply
-finish and use the result, or wait until other hosts respond to its query. The
-latter is typically the case when a record can have multiple values, as it is
-the case with \code{SRV} and \code{PTR} records.
-
-Another feature of Multicast DNS is the reduction of traffic through
-\term{Known-Answer Suppression}. It allows a querying host to specify already
-known resources in its query when querying resources that could exist on more
-than one host (e.~g., SRV records). The hosts matching those resources then do
-not generate a response.
-
-Finally, hosts may also send unsolicited responses. This can be used to notify
-the network of new services available on a host.
-
-\pages{1}
-
-\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
-
-As another recent extension for the Domain Name System, \term{DNS-Based Service
-Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
-\code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
-for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
-process of browsing for all XMPP clients in the domain \code{example.org}.
-This is a two-step process, consisting of \term{Service Instance Enumeration}
-and \term{Service Instance Resolution}.
-
-\begin{figure}[top]
-  \centering
-  \includegraphics[width=0.9\textwidth]{dnssd-mock.jpg}
-  \caption{DNS-SD: Service Instance Enumeration and Resolution
-    \todo[XMPP is a bad example here, use IPP]}
-  \label{fig:dnssd}
-\end{figure}
-
-\paragraph{Service Instance Enumeration} At first, to enumerate the available
-services in a domain for a given protocol, a DNS-SD-enabled client queries
-resources of type \code{PTR} of the form \code{\_service.\_proto.domain}. The
-result of this query is then a list of \term{instance names} of the form
-\code{name.\_service.\_proto.domain} which provide the specified service. For
-example, in Figure~\ref{fig:dnssd}, by querying for
-\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol in the
-domain \code{example.org} are enumerated, and as a result, the instance names of
-three hosts are returned.
-
-\paragraph{Service Instance Resolution} As a second step, the returned instance
-names are resolved as \code{SRV} records to retrieve the actual host names and
-port numbers of a service. In the example, resolution of one instance name shows
-that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
-Additionally, an optional \code{TXT} record with the same instance name can
-contain further information about the service (e.~g., information about the
-supported paper sizes).
-
-Through the usage of \code{SRV} records, it is easily possible for a service to
-inform clients about non-standard port numbers, and especially in connection
-with Multicast DNS makes it easy to deploy decentralized systems for the
-Internet of Things~\cite{Klauck:2012:BCC:2352852.2352881}.
-
-\pages{1}
-% vim: set ft=tex et ts=2 sw=2 :

diff --git a/dnssd-mock.jpg b/dnssd-mock.jpg
deleted file mode 100644 (file)
index 9d90ecb..0000000
Binary files a/dnssd-mock.jpg and /dev/null differ

diff --git a/fig-dnssd-mock.jpg b/fig-dnssd-mock.jpg
new file mode 100644 (file)
index 0000000..9d90ecb
Binary files /dev/null and b/fig-dnssd-mock.jpg differ

diff --git a/fig-xmpp-architecture-mock.jpg b/fig-xmpp-architecture-mock.jpg
new file mode 100644 (file)
index 0000000..dcaaec1
Binary files /dev/null and b/fig-xmpp-architecture-mock.jpg differ

diff --git a/main.tex b/main.tex
index 8219bb3..bd1cb9b 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -38,9 +38,9 @@ overview to the techniques used in the paper by Klauk and Kirsche
 
 \cite{klauck-kirsche-chattythings}
 
 
 \cite{klauck-kirsche-chattythings}
 

-\input{address-allocation.tex}
-\input{dns-extensions.tex}
-\input{xmpp.tex}
+\input{sec-address-allocation.tex}
+\input{sec-dns-extensions.tex}
+\input{sec-xmpp.tex}

 \input{sec-chatty-things.tex}
 
 \section{Related Approaches}
 \input{sec-chatty-things.tex}
 
 \section{Related Approaches}

diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex
new file mode 100644 (file)
index 0000000..4198074
--- /dev/null
+++ b/sec-address-allocation.tex
@@ -0,0 +1,73 @@
+\subsection{Address allocation}
+Considering the TCP/IP protocol suite, in order to be able to communicate on the
+IP layer, a device needs to configure one of its network interfaces with
+an IP address that can be reached from the network that the device wants to connect
+to. There are several ways of achieving this:
+
+\begin{itemize}
+  \item The IP address is pre-selected by a human and stored in the device
+    configuration. This process is cumbersome when more than one device needs to
+    be configured, and humans have to remember which addresses are configured on
+    which device, and which addresses are still free to use on additional
+    devices.
+
+  \item Deploying a central server that assigns network addresses
+    to the devices in the network, which in order query the server (for example
+    via broadcast or on a lower layer) for a unique address before they use the
+    IP layer for the first time. This technique supersedes the dependency of
+    human memory for mapping IP addresses to devices, and can easily be combined
+    with additional central configuration management, like the automatic
+    assignment of a static gateway, or a DNS resolver.\\
+    The DHCP protocol is one example of central IP address management.
+
+  \item A third alternative is the use of a distributed protocol which enables
+    the devices on the network to choose addresses in accordance with other
+    devices on the same network, so no IP address is used more than once. In
+    respect to the Internet of Things, this approach has the advantage that
+    those devices can easily be used in different scenarios without needing
+    central deployment at all, and also allowing them to change their addresses
+    dynamically, therefore easily reacting to changes in the network. \\
+    There are two major protocols which are used for dynamic configuration of IP
+    addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
+    used, and in IPv6 networks, Stateless Address
+    Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every
+    device.
+
+\end{itemize}
+
+\paragraph{IPv4 Link-Local Addressing}
+
+\term{Link-Local Addressing}, also known as \term{Automatic Private IP
+Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet
+\code{169.254.0.0/16} for addressing. Every device first chooses a random
+address from that address space.  Then it checks if the chosen address is used
+by any other device on the network by probing the chosen address, which is
+usually done using the ARP protocol. If the probing process results that the
+address is not used on the network (e.~g.  no device returned an ARP response
+during a random time interval), the device claims its chosen address and uses it
+for communication on the IPv4 layer. If the chosen address is already used, the
+  device continues the process, subsequently choosing a new random address and
+  trying to claim it, until a free address has been found.
+
+\paragraph{IPv6 Stateless Address Autoconfiguration}
+
+Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6
+Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet
+\code{fe80::/64}. First, an \term{interface identifier} is generated using the
+interface's MAC address. Since MAC addresses must be unique in the network, a
+unique IPv6 address is obtained by combining the subnet prefix and the interface
+identifier. To ensure that no other device exists with this generated IPv6
+address, the device performs \term{Duplicate Address Detection} on the network
+through \term{Neighbor Advertisement} messages and listening for \term{Neighbor
+Solicitation} messages. If such messages are received from other hosts, the
+configured address cannot be used by the device and must be discarded.
+Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC
+addresses are unique on the network.
+
+In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
+Autoconfiguration can also be used with a central server. In this case, a
+central server broadcasts \term{Router Solicitation} messages on the network
+which contain a global network prefix. The hosts on the network can then use
+that prefix instead to configure a global IPv6 address.
+
+% vim: set ft=tex et ts=2 sw=2 :

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
new file mode 100644 (file)
index 0000000..5be64d4
--- /dev/null
+++ b/sec-chatty-things.tex
@@ -0,0 +1,7 @@
+\section{System Architecture of ``Chatty Things''}
+\todo
+\pages{3}
+\subsection{Service Provisioning Sublayer}
+\subsection{Bootstrapping}
+\subsection{Presence Subscription}
+

diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex
new file mode 100644 (file)
index 0000000..7ef413c
--- /dev/null
+++ b/sec-dns-extensions.tex
@@ -0,0 +1,82 @@
+\subsection{Extensions to the Domain Name System}\label{sec:dns}
+
+In a distributed context, it is often not feasible to rely on a central,
+authoritative DNS server, and there is usually no easy way to discover services.
+The first problem is addressed with \term{Multicast DNS}, and since DNS is
+basically a key-value store, it can also be used for service discovery, which is
+achieved using \term{DNS-Based Service Discovery}. Both techniques were first
+developed by Apple as part of the \term{Bonjour} project, and are now maintained
+by the IETF Zeroconf working group.
+
+\subsubsection{Multicast DNS}
+
+\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
+Name System that allows DNS resource records to be distributed on multiple hosts
+in a network, therefore avoiding central authorities and enabling every host to
+publish its own entries. For that purpose, a special domain, usually
+named \code{.local}, is used.
+
+Software that supports mDNS listens on the reserved
+link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
+\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries.
+Queries sent to those multicast address and port are standard DNS queries.
+If a host receives a query and knows about the queried resource, it responds to the
+querying host with a standard DNS response. The querying host can then simply
+finish and use the result, or wait until other hosts respond to its query. The
+latter is typically the case when a record can have multiple values, as it is
+the case with \code{SRV} and \code{PTR} records.
+
+Another feature of Multicast DNS is the reduction of traffic through
+\term{Known-Answer Suppression}. It allows a querying host to specify already
+known resources in its query when querying resources that could exist on more
+than one host (e.~g., SRV records). The hosts matching those resources then do
+not generate a response.
+
+Finally, hosts may also send unsolicited responses. This can be used to notify
+the network of new services available on a host.
+
+\pages{1}
+
+\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
+
+As another recent extension for the Domain Name System, \term{DNS-Based Service
+Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
+\code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
+for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
+process of browsing for all XMPP clients in the domain \code{example.org}.
+This is a two-step process, consisting of \term{Service Instance Enumeration}
+and \term{Service Instance Resolution}.
+
+\begin{figure}[top]
+  \centering
+  \includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg}
+  \caption{DNS-SD: Service Instance Enumeration and Resolution
+    \todo[XMPP is a bad example here, use IPP]}
+  \label{fig:dnssd}
+\end{figure}
+
+\paragraph{Service Instance Enumeration} At first, to enumerate the available
+services in a domain for a given protocol, a DNS-SD-enabled client queries
+resources of type \code{PTR} of the form \code{\_service.\_proto.domain}. The
+result of this query is then a list of \term{instance names} of the form
+\code{name.\_service.\_proto.domain} which provide the specified service. For
+example, in Figure~\ref{fig:dnssd}, by querying for
+\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol in the
+domain \code{example.org} are enumerated, and as a result, the instance names of
+three hosts are returned.
+
+\paragraph{Service Instance Resolution} As a second step, the returned instance
+names are resolved as \code{SRV} records to retrieve the actual host names and
+port numbers of a service. In the example, resolution of one instance name shows
+that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
+Additionally, an optional \code{TXT} record with the same instance name can
+contain further information about the service (e.~g., information about the
+supported paper sizes).
+
+Through the usage of \code{SRV} records, it is easily possible for a service to
+inform clients about non-standard port numbers, and especially in connection
+with Multicast DNS makes it easy to deploy decentralized systems for the
+Internet of Things~\cite{Klauck:2012:BCC:2352852.2352881}.
+
+\pages{1}
+% vim: set ft=tex et ts=2 sw=2 :

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
new file mode 100644 (file)
index 0000000..451a317
--- /dev/null
+++ b/sec-xmpp.tex
@@ -0,0 +1,121 @@
+\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]{fig-xmpp-architecture-mock.jpg}
+  \caption{XMPP architecture}
+  \label{fig:xmpparch}
+%\end{figure}
+\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.
+
+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.
+
+XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
+determine the server being in charge of a domain. For example, the server who
+manages the users for the domain \code{example.org} is given by the SRV record
+\code{\_xmpp-server.\_tcp.example.org}.
+
+\subsubsection{Communication primitives}
+
+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.
+
+On top of that, living connections between hosts are represented by \term{XML
+streams}. The client initiates a connection by sending an XML declaration
+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
+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
+closes its stream. If both streams are closed, the underlying TCP connection is
+terminated.
+
+\todo[Example stream]
+
+\subsubsection{Multi-User Chats}
+
+\cite{xep-0045}
+
+\subsubsection{Publish/Subscribe, Presence and the Roster}
+
+\cite{xep-0060}
+
+
+\cite{rfc6121}
+
+\subsubsection{XMPP Serverless Messaging}
+\todo
+
+To overcome the need for a central server and authentication, XMPP Serverless
+Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
+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.
+
+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{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
+    \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.)
+\end{itemize}
+
+When other clients in the same network enumerate the available services by
+querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
+her to the roster automatically. In that way, XMPP users can see who is
+currently available for communication. To start a chat session, clients initiate
+a TCP connection over the advertised ports, open their XML streams, and send
+message or IQ stanzas like they would to an XMPP server. Presence is managed
+over the corresponding TXT record in the mDNS. To go offline, a client
+announces the deletion of its mDNS records.
+
+\pages{1}
+
+% vim: set ft=tex et ts=2 sw=2 :

diff --git a/xmpp-architecture-mock.jpg b/xmpp-architecture-mock.jpg
deleted file mode 100644 (file)
index dcaaec1..0000000
Binary files a/xmpp-architecture-mock.jpg and /dev/null differ

diff --git a/xmpp.tex b/xmpp.tex
deleted file mode 100644 (file)
index 7bef910..0000000
--- a/xmpp.tex
+++ /dev/null
@@ -1,121 +0,0 @@
-\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}
-  \label{fig:xmpparch}
-%\end{figure}
-\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.
-
-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.
-
-XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
-determine the server being in charge of a domain. For example, the server who
-manages the users for the domain \code{example.org} is given by the SRV record
-\code{\_xmpp-server.\_tcp.example.org}.
-
-\subsubsection{Communication primitives}
-
-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.
-
-On top of that, living connections between hosts are represented by \term{XML
-streams}. The client initiates a connection by sending an XML declaration
-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
-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
-closes its stream. If both streams are closed, the underlying TCP connection is
-terminated.
-
-\todo[Example stream]
-
-\subsubsection{Multi-User Chats}
-
-\cite{xep-0045}
-
-\subsubsection{Publish/Subscribe, Presence and the Roster}
-
-\cite{xep-0060}
-
-
-\cite{rfc6121}
-
-\subsubsection{XMPP Serverless Messaging}
-\todo
-
-To overcome the need for a central server and authentication, XMPP Serverless
-Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
-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.
-
-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{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
-    \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.)
-\end{itemize}
-
-When other clients in the same network enumerate the available services by
-querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
-her to the roster automatically. In that way, XMPP users can see who is
-currently available for communication. To start a chat session, clients initiate
-a TCP connection over the advertised ports, open their XML streams, and send
-message or IQ stanzas like they would to an XMPP server. Presence is managed
-over the corresponding TXT record in the mDNS. To go offline, a client
-announces the deletion of its mDNS records.
-
-\pages{1}
-
-% vim: set ft=tex et ts=2 sw=2 :