polishing

diff --git a/biblio.bib b/biblio.bib
index 928c8c5..2a4c8ed 100644 (file)
--- a/biblio.bib
+++ b/biblio.bib
@@ -262,4 +262,16 @@
        year = "2013"
 }
 
        year = "2013"
 }
 

-
+@misc{rfc2131,
+  author="R. Droms",
+  title="{Dynamic Host Configuration Protocol}",
+  series="Request for Comments",
+  number="2131",
+  howpublished="RFC 2131 (Draft Standard)",
+  publisher="IETF",
+  organization="Internet Engineering Task Force",
+  year=1997,
+  month=mar,
+    note="Updated by RFCs 3396, 4361, 5494, 6842",
+  url="http://www.ietf.org/rfc/rfc2131.txt",
+}

diff --git a/main.tex b/main.tex
index 5d279ac..692256f 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -38,6 +38,12 @@ how do we talk to our smart home?
 what are the challenges? (interoperability, H2M interface, self-configuration,
 information filtering to prevent information overflow)
 
 what are the challenges? (interoperability, H2M interface, self-configuration,
 information filtering to prevent information overflow)
 

+In a distributed context like the Internet of Things, devices need to be ready
+to use out of the box. Users often do not want to set up configurations for each
+device they use, and when using several of those devices, it is often not
+reasonable having to configure every single one.
+
+

 %\paragraph{Human-to-Machine Communication:} especiall in the Internet of Things,
        %Chatty Things need to be accessible for the user and should be easy to talk
        %to.
 %\paragraph{Human-to-Machine Communication:} especiall in the Internet of Things,
        %Chatty Things need to be accessible for the user and should be easy to talk
        %to.

diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex
index 4198074..d2d0625 100644 (file)
--- a/sec-address-allocation.tex
+++ b/sec-address-allocation.tex
@@ -1,39 +1,24 @@
 \subsection{Address allocation}
 \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}
+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. Letting the user choose and configure IP addresses manually is a cumbersome
+when it comes to several devices. Deploying a central server for assigning IP
+addresses automatically from a pre-configured address pool is possible (e.~g.
+using the DHCP protocol~\cite{rfc2131}), however, there is also the alternative
+to use a distributed protocol which enables the devices on a network to choose
+addresses in accordance with each other so no IP address is used twice.
+
+In respect to the Internet of Things, this decentralized approach has the
+advantage that devices can easily be used in different scenarios, even when
+central deployment does not exist, and it also allows them to change their
+addresses dynamically in order to react 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 specified in the IPv6 protocol.

 
 \paragraph{IPv4 Link-Local Addressing}
 
 
 \paragraph{IPv4 Link-Local Addressing}
 


@@ -46,23 +31,25 @@ 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
 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.
+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
 
 \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.
+Stateless Address Auto\-configuration} use an IPv6 address from the subnet
+\code{fe80::/64}. First, a 64-bit \term{interface identifier} is generated,
+which can be random, or based on the interface's MAC address. Most likely, this
+interface identifier is unique in the network, so a unique IPv6 address is
+obtained by combining the subnet prefix and the interface identifier.
+Nonetheless, to ensure that no other device use the generated IPv6 address, the
+device performs \term{Duplicate Address Detection} on the network by
+broadcasting
+its generated address with \term{Neighbor Advertisement} messages and listening
+for \term{Neighbor Solicitation} messages. If such a message is received from
+another hosts, the generated address cannot be used by the device and must be
+discarded, and the address generation process is repeated until a unique
+address has been found.

 
 In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
 Autoconfiguration can also be used with a central server. In this case, a
 
 In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
 Autoconfiguration can also be used with a central server. In this case, a

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index 01f0ed0..25b1426 100644 (file)
--- a/sec-chatty-things.tex
+++ b/sec-chatty-things.tex
@@ -1,7 +1,7 @@
 \section{System Architecture of ``Chatty Things''}
 
 \section{System Architecture of ``Chatty Things''}
 

-After the underlying techniques have been explained, we can have a look at the
-system architecture which Klauck and
+After the underlying techniques have been explained, we can now have a look at
+the system architecture which Klauck and

 Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
 
 \pages{3}
 Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
 
 \pages{3}


@@ -53,11 +53,12 @@ unoptimized uXMPP implementation while also implementing new features.
 In order to react to different network infrastructures, their implementation
 allows both communication with a central XMPP server as well as peer-to-peer
 communication over XMPP Serverless Messaging. When a central XMPP server is
 In order to react to different network infrastructures, their implementation
 allows both communication with a central XMPP server as well as peer-to-peer
 communication over XMPP Serverless Messaging. When a central XMPP server is

-detected over uBonjour, it is used instead with the ANONYMOUS login method, and the
-XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
-encryption is not yet implemented, and it assigns random JID to the client,
-which do not need to exist on the server. However, a server must exist and must
-be configured in order to use this method.
+detected over uBonjour, it is used instead with the ANONYMOUS login method, and
+the XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
+encryption is not yet implemented, and with this method, the server assigns a
+random JID to the client, which does not need to exist on the server. However, a
+server must exist and must be configured to use this login method in order to
+use this method.

 
 With a server, information filtering is achieved by creating topic-based
 Multi-User Chats where multiple devices can be grouped. A user can then simply
 
 With a server, information filtering is achieved by creating topic-based
 Multi-User Chats where multiple devices can be grouped. A user can then simply


@@ -79,11 +80,6 @@ level.
 
 \subsection{Bootstrapping}
 
 
 \subsection{Bootstrapping}
 

-In a distributed context like the Internet of Things, devices need to be ready
-to use out of the box. Users often do not want to set up configurations for each
-device they use, and when using several of those devices, it is often not
-reasonable having to configure every single one.
-

 With the given approach, bootstrapping new Chatty Things is easy and no
 configuration is neccessary: on the network layer, IP addresses can simply be
 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
 With the given approach, bootstrapping new Chatty Things is easy and no
 configuration is neccessary: on the network layer, IP addresses can simply be
 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address


@@ -119,16 +115,18 @@ During runtime, a device can then react to changes in network infrastructure:
 
 \subsection{Temporary Subscription for Presence}\label{sec:tsp}
 
 
 \subsection{Temporary Subscription for Presence}\label{sec:tsp}
 

-To further reduce the message overhead and allow more fine-grained controls over
+To further reduce the message overhead and allow more fine-grained control over

 information filtering, \term{Temporary Subscription for Presence} is introduced.
 information filtering, \term{Temporary Subscription for Presence} is introduced.

-This technique builds on top of presence stanzas as defined in core XMPP. These
-presence stanzas are sent without a \code{to} or \code{from} attribute, and
-therefore fit into a single TCP/IP packet over IEEE~802.15.4. However, to be
-able to receive these stanzas, a client must manually subscribe to those
-information in their roster, which requires further communication between nodes. As the network
-can change rapidly, subscriptions would be often outdated, and there would be
-much overhead of subscriptions and unsubscription packets, which would inhibit
-the flow of the actual information.
+This technique builds on top of presence stanzas as defined in core XMPP, which
+are sent by default without a \code{to} or \code{from} attribute, and therefore
+fit into a single TCP/IP packet over IEEE~802.15.4. However, a drawback of the
+presence mechanism defined by core XMPP is the fact that a client must manually
+subscribe to presence information of another client in order to receive it,
+which requires further communication between the clients. Since the network can
+change rapidly, and clients can frequently join and leave the network,
+subscriptions would often be outdated and must be renewed, leading to overhead
+of subscriptions and unsubscription packets, which would inhibit the flow of the
+actual information.

 
 To solve this problem, a dynamic, topic-based roster is implemented on top of
 Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
 
 To solve this problem, a dynamic, topic-based roster is implemented on top of
 Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes

diff --git a/sec-discussion.tex b/sec-discussion.tex
index c882773..0e4fe59 100644 (file)
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -59,7 +59,7 @@ be used in existing infrastructures, and is also focused on multiple platforms
 like embedded systems and servers. Web Services can be very flexible and
 composable, and discovery is already specified, however, this also comes at a
 cost: web services are enclosed in SOAP, which is enclosed in HTTP, which is
 like embedded systems and servers. Web Services can be very flexible and
 composable, and discovery is already specified, however, this also comes at a
 cost: web services are enclosed in SOAP, which is enclosed in HTTP, which is

-transported over TCP, which introduces very much overhead, except with SOAP
+transported over TCP, which introduces very much overhead, especially with SOAP

 being based on verbose XML. IPv6 support is only partially implemented.
 For communication, standard APIs can be used.
 
 being based on verbose XML. IPv6 support is only partially implemented.
 For communication, standard APIs can be used.
 


@@ -70,10 +70,10 @@ protocol, there is the need to implement at least an XML parser on each node,
 which comes with protocol overhead and increased code size. However Klauck and
 Kirsche show that with good optimization (in the code as well as in the
 procotol), a complete stack can be implemented in 12 kByte of ROM, which leaves
 which comes with protocol overhead and increased code size. However Klauck and
 Kirsche show that with good optimization (in the code as well as in the
 procotol), a complete stack can be implemented in 12 kByte of ROM, which leaves

-enough space for other applications to build onto it. As compared to Web
+enough space for other applications to be built onto it. As compared to Web

 Services, Chatty Things are probably not as flexible, but they have less
 overhead, even when using XML, while MQTT and CoAP provide less flexibility for
 Services, Chatty Things are probably not as flexible, but they have less
 overhead, even when using XML, while MQTT and CoAP provide less flexibility for

-future enhancement, therefore less protocol overhead and easier parsing.
+future enhancement, but less protocol overhead and easier parsing.

 
 With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
 on reliable and established standards, which allows it to reuse Chatty Things in
 
 With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
 on reliable and established standards, which allows it to reuse Chatty Things in


@@ -85,7 +85,7 @@ which is caused by the lack of support for Multi-User Chats in XEP-0174
 (Serverless Messaging). If this gap can be closed, or a different way for topic
 filtering in distributed networks is found, the server can be
 eliminated and what remains is truly distributed network without the need for
 (Serverless Messaging). If this gap can be closed, or a different way for topic
 filtering in distributed networks is found, the server can be
 eliminated and what remains is truly distributed network without the need for

-any central infrastructure, therefore eliminating every single point of failure
+any central infrastructure, therefore eliminating most single points of failure

 in the system.
 
 It is always hard to trade flexibility and accessibility for efficiency. The
 in the system.
 
 It is always hard to trade flexibility and accessibility for efficiency. The

diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex
index 65926db..d3ec16e 100644 (file)
--- a/sec-dns-extensions.tex
+++ b/sec-dns-extensions.tex
@@ -30,7 +30,8 @@ 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
 \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.
+not generate a response, thus reducing the messages in the network and saving
+bandwidth, which is usually a scarce resource in wireless networks.

 
 Finally, hosts may also send unsolicited responses. This can be used to notify
 the network of new services available on a host.
 
 Finally, hosts may also send unsolicited responses. This can be used to notify
 the network of new services available on a host.

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index d939b38..41a9ca4 100644 (file)
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -21,6 +21,7 @@ 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]
     \def\nodelist{
       juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,
   \begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]
     \def\nodelist{
       juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,


@@ -29,25 +30,26 @@ the resource is only needed for routing between client and server.
       romeo/{(1,-1)}/XMPP client \code{romeo@im.example.org}/below/computer%
     }
     \foreach \name/\pos/\text/\tpos/\icon in \nodelist {
       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 (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };

       \node[\tpos=of \name,iconlabel] (\name text) { \text };
     }
       \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);
+    \draw[<->,dashed] (juliet) -- node[anchor=east,label]{s2c} (examplenet);
+    \draw[<->] (examplenet) -- node[anchor=south,label]{s2s} (imexampleorg);
+    \draw[<->,dashed] (imexampleorg) -- node[anchor=west,label]{s2c} (romeo);

   \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
+up the always-on backbone of the network used for message routing, and manage

 user accounts and statuses. On the other hand, \term{XMPP clients} represent a
 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.
+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 +68,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


@@ -77,7 +79,7 @@ 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
 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
+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.
 


@@ -92,7 +94,7 @@ 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
 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.

 
 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


@@ -105,8 +107,8 @@ 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
+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 to which the users send their messages to. Each incoming message is
 then dispatched to all users which have joined the room.
 
 unique JID to which the users send their messages to. Each incoming message is
 then dispatched to all users which have joined the room.
 


@@ -119,8 +121,9 @@ the resource part of the room JID specifies the desired nick name.
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} allows XMPP clients on a network to build a
 peer-to-peer mesh network and chat directly with each other. This feature was
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} 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.
+first introduced by Apple as part of their \term{Bonjour}\footnote{see
+\url{https://developer.apple.com/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})
 
 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})


@@ -136,7 +139,8 @@ messaging, her client would publish the following four mDNS records:
   \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
   \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