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