spellcheck

diff --git a/outline.tex b/outline.tex
index f0eb019..ba40bb4 100644 (file)
--- a/outline.tex
+++ b/outline.tex
@@ -20,7 +20,7 @@ short overview, not too long: what do we want, what are we
 going to do
 
 \section{Prerequisites}
 going to do
 
 \section{Prerequisites}

-overview to the techniques used in the paper by Klauk and Kirsche
+overview to the techniques used in the paper by Klauck and Kirsche

 \cite{klauck-kirsche-chattythings}
 
 \subsection{Address allocation}
 \cite{klauck-kirsche-chattythings}
 
 \subsection{Address allocation}

diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex
index ba09a10..0ca0764 100644 (file)
--- a/sec-address-allocation.tex
+++ b/sec-address-allocation.tex
@@ -11,7 +11,7 @@ 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
 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 desployments, even where
+advantage that devices can easily be used in different deployments, even where

 central infrastructures do not exist, and it also allows them to change their
 addresses dynamically in order to react to changes in the network.
 
 central infrastructures do not exist, and it also allows them to change their
 addresses dynamically in order to react to changes in the network.
 

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index 9ac3428..6acde0c 100644 (file)
--- a/sec-chatty-things.tex
+++ b/sec-chatty-things.tex
@@ -7,7 +7,7 @@ Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
 \subsection{Service Provisioning Sublayer}
 
 Considering the application in deeply embedded systems and the special needs of
 \subsection{Service Provisioning Sublayer}
 
 Considering the application in deeply embedded systems and the special needs of

-the Internet of Things on the one hand, the protocol stack needs to fulfil
+the Internet of Things on the one hand, the protocol stack needs to fulfill

 certain technical requirements.
 
 First, memory, computing resources and bandwidth on embedded systems are limited,
 certain technical requirements.
 
 First, memory, computing resources and bandwidth on embedded systems are limited,


@@ -66,7 +66,7 @@ devices talk directly with the user or with other devices. This method has the
 drawback that Multi-User Chats cannot be used for topic filtering, since no
 method is specified to do XEP-0045 and XEP-0174 at the same time. In this case,
 a user must have an XEP-0174-compliant chat client, but it also gives her the
 drawback that Multi-User Chats cannot be used for topic filtering, since no
 method is specified to do XEP-0045 and XEP-0174 at the same time. In this case,
 a user must have an XEP-0174-compliant chat client, but it also gives her the

-opportunity to interact with things spontaneously on an ad-hoc basis (e.~g. when
+opportunity to interact with things spontaneously on an ad hoc basis (e.~g. when

 entering a room) without need for any additional gateway on the application
 level.
 
 entering a room) without need for any additional gateway on the application
 level.
 


@@ -77,7 +77,7 @@ level.
 \subsection{Bootstrapping}
 
 With the given approach, bootstrapping new Chatty Things is easy and no
 \subsection{Bootstrapping}
 
 With the given approach, bootstrapping new Chatty Things is easy and no

-configuration is neccessary: on the network layer, IP addresses can simply be
+configuration is necessary: on the network layer, IP addresses can simply be

 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
 Autoconfiguration. On the transport layer, all needed ports can be obtained over
 DNS-Based Service Discovery. Finally, on the application layer, host names can
 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
 Autoconfiguration. On the transport layer, all needed ports can be obtained over
 DNS-Based Service Discovery. Finally, on the application layer, host names can


@@ -93,7 +93,7 @@ Bootstrapping a Chatty Thing therefore incorporates three steps:
   \item If a server is found, connect to it using ANONYMOUS login, join
     topic-based Multi-User Chats, deactivate the uBonjour client
     \term{(Infrastructure mode).}
   \item If a server is found, connect to it using ANONYMOUS login, join
     topic-based Multi-User Chats, deactivate the uBonjour client
     \term{(Infrastructure mode).}

-  \item If no server is found, activate the XEP-0174 client \term{(Ad-hoc
+  \item If no server is found, activate the XEP-0174 client \term{(Ad hoc

     mode)}.
 \end{enumerate}
 
     mode)}.
 \end{enumerate}
 


@@ -104,7 +104,7 @@ changing from one mode to the other:
   \item In Infrastructure mode: when connection to the server is lost, enable
     the uBonjour client, try to find a server, and when none is found, enable
     Serverless Messaging.
   \item In Infrastructure mode: when connection to the server is lost, enable
     the uBonjour client, try to find a server, and when none is found, enable
     Serverless Messaging.

-  \item In Ad-hoc mode: if uBonjour detects a new XMPP server joining the
+  \item In Ad hoc mode: if uBonjour detects a new XMPP server joining the

     network, try to connect to it. If this succeeds, disable Serverless
     Messaging and uBonjour and join topic-based Multi-User Chats.
 \end{itemize}
     network, try to connect to it. If this succeeds, disable Serverless
     Messaging and uBonjour and join topic-based Multi-User Chats.
 \end{itemize}

diff --git a/sec-discussion.tex b/sec-discussion.tex
index 2b26283..534bb25 100644 (file)
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -3,7 +3,7 @@
 \subsection{Future Work}
 
 In addition to the XEPs covered above, there are a few additional XEPs which can
 \subsection{Future Work}
 
 In addition to the XEPs covered above, there are a few additional XEPs which can

-be implemented to further increase the effictivity of Chatty Things. Especially
+be implemented to further increase the effectivity of Chatty Things. Especially

 the documents XEP-0323 through XEP-0326 (which are currently in Experimental
 status) are targeted to the Internet of Things.
 
 the documents XEP-0323 through XEP-0326 (which are currently in Experimental
 status) are targeted to the Internet of Things.
 


@@ -89,7 +89,7 @@ summarized in Table~\ref{tab:comparison}.
   \hline
   Feature & Chatty Things & CoAP & MQTT & WS4D \\
   \hline\hline
   \hline
   Feature & Chatty Things & CoAP & MQTT & WS4D \\
   \hline\hline

-  application gateways neccessary & - & yes & yes & - \\ \hline
+  application gateways necessary & - & yes & yes & - \\ \hline

   usable with standard clients & yes & - & - & (yes) \\ \hline
   discovery support & yes & yes & - & yes\\ \hline
   IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline
   usable with standard clients & yes & - & - & (yes) \\ \hline
   discovery support & yes & yes & - & yes\\ \hline
   IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline


@@ -105,7 +105,7 @@ machine-to-machine communication and originates from the IETF Constrained
 Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
 but still has been only in draft status since 2010.\ It allows a mapping to
 HTTP, and is therefore stateless, but it specifies a binary protocol, which
 Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
 but still has been only in draft status since 2010.\ It allows a mapping to
 HTTP, and is therefore stateless, but it specifies a binary protocol, which

-makes it neccessary to deploy application-level gateways and special client
+makes it necessary to deploy application-level gateways and special client

 software to communicate with its environment. It relies on UDP, but emulates
 congestion control, message confirmation and message IDs, since – in contrast to
 HTTP – messages can be sent asynchronously. Discovery is also specified and done
 software to communicate with its environment. It relies on UDP, but emulates
 congestion control, message confirmation and message IDs, since – in contrast to
 HTTP – messages can be sent asynchronously. Discovery is also specified and done


@@ -142,7 +142,7 @@ For communication, standard APIs can be used.
 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
 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
+protocol), a complete stack can be implemented in 12 kBytes of ROM, which leaves

 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
 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

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index fbc1dbe..d3ecf61 100644 (file)
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -160,7 +160,7 @@ 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}
     \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}