Pontarius XMPP aims to be a convenient-to-use, powerful, correct, secure,
and extendable XMPP client library for Haskell.
It is written by Jon Kristensen and Mahdi Abdinejadi.
Being licensed under a three-clause BSD license, Pontarius XMPP is free
Pontarius XMPP 0.1 is a minimal XMPP client implementation with all the required
client features and behaviours of the RFC 6120 ("XMPP Core") specification
\begin_inset Foot
status open
\begin_layout Plain Layout
http://tools.ietf.org/html/rfc6120
\end_layout
\end_inset
.
Pontarius XMPP has been developed by the Pontarius project (mainly by Jon
Kristensen).
\series bold
\series default
Being licensed under a three-clause BSD license, Pontarius XMPP is free
and open source software.
\end_layout
@ -98,18 +113,40 @@ Features and Implementation Specifics
@@ -98,18 +113,40 @@ Features and Implementation Specifics
\end_layout
\begin_layout Standard
Pontarius XMPP 0.1 implements the XMPP Core specification (RFC 6120)
\begin_inset Foot
status open
Pontarius XMPP 0.1 implements the XMPP Core specification (RFC 6120).
Features include the following:
\end_layout
\begin_layout Plain Layout
http://tools.ietf.org/html/rfc6120
\begin_layout Itemize
Connecting and disconnecting from an XMPP server
\end_layout
\end_inset
\begin_layout Itemize
Opening the XMPP streams
\end_layout
.
Below are the specifics of our implementation.
\begin_layout Itemize
Securing XMPP streams with TLS
\end_layout
\begin_layout Itemize
Authenticate using SASL
\end_layout
\begin_layout Itemize
Perform resource binding
\end_layout
\begin_layout Itemize
Send and receive stanzas (message, presence, and IQ) and stanza errors
\end_layout
\begin_layout Itemize
Send and receive stream errors
\end_layout
\begin_layout Standard
Below are the specifics of our implementation:
\end_layout
\begin_layout Itemize
@ -147,20 +184,19 @@ For (SASL) authentication, the SHA-1 variant of SASL Salted Challenge Response
@@ -147,20 +184,19 @@ For (SASL) authentication, the SHA-1 variant of SASL Salted Challenge Response
Authentication Mechanism (SCRAM-SHA-1) is the only supported mechanism
\end_layout
\begin_layout Standard
Later versions will add supports for different XMPP extensions, such as
RFC 6121 (XMPP IM), XEP-0004: Data Forms, and XEP-0077: In-Band Registration.
\begin_inset Foot
status open
\begin_layout Plain Layout
XMPP RFCs can be found at http://xmpp.org/xmpp-protocols/rfcs/, and the so-called
XEPs at http://xmpp.org/xmpp-protocols/xmpp-extensions/.
\begin_layout Section
Future Development
\end_layout
\end_inset
\begin_layout Standard
The current goal for Pontarius XMPP 0.2 is to implement the Extended Personal
Media Network (XPMN) architecture so that the Pontarius project can develop
a media server and some other XPMN services on top of Pontarius XMPP.
However, if we get approached by people wanting to use Pontarius XMPP for
other things, we might decide to help them out by implement some other
features first.
Please let us know if you are looking for a Haskell XMPP library and Pontarius
@ -174,17 +174,8 @@ The Pontarius project
@@ -174,17 +174,8 @@ The Pontarius project
is not a legal entity, but is like a synonym for Jon Kristensen.
Jon Kristensen does DOES NOT TAKE ANY RESPONSIBILITY OR OFFER ANY GUARANTEES
in regards to the software, its requirements or this document.
Furthermore, the software is provided
\begin_inset Quotes eld
\end_inset
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE
\begin_inset Quotes erd
\end_inset
.
Consult the GNU General Public License for more information.
Furthermore, the software is provided WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
\end_layout
\begin_layout Subsection
@ -996,16 +987,6 @@ We assume that the Glasgow Haskell Compiler (GHC) is available on the system
@@ -996,16 +987,6 @@ We assume that the Glasgow Haskell Compiler (GHC) is available on the system
where Pontarius XMPP 0.1 applications are built.
\end_layout
\begin_layout Subsubsection
Apportioning of requirements
\end_layout
\begin_layout Standard
If IDNA2008 or the other stringprep-replacing specifications are not finished
or otherwise not suitable to implement, we will fall back to implementing
stringprep for Pontarius XMPP 0.1.
\end_layout
\begin_layout Section
Specific requirements
\end_layout
@ -1320,6 +1301,13 @@ REQ-32 Being a client library, the system shall support the 'jabber:client'
@@ -1320,6 +1301,13 @@ REQ-32 Being a client library, the system shall support the 'jabber:client'
REQ-33 XML namespaces for stanzas should always be known to the client.
\end_layout
\begin_layout Description
REQ-XX: While we validate that the incoming XML is valid and has everything
that we need, we are not validating the XML against the XML schemas.
(This functionality will most likely be implemented in xml-enumerator in
the future.)
\end_layout
\begin_layout Description
REQ-34 The system shall always check for the appropriate features before
trying to use them.
@ -1399,25 +1387,14 @@ REQ-41 The system must a convenient API to deal with stanza and stream errors.
@@ -1399,25 +1387,14 @@ REQ-41 The system must a convenient API to deal with stanza and stream errors.
RFC 6122: XMPP: Address Format
\end_layout
\begin_layout Standard
As can be read in Section 1 of RFC 6122, the XMPP community has started
discussions about moving from the 2003 version of IDNA (Internationalized
Domain Names in Applications) to the new IDNA2008 standard.
Unlike its predecessor, this new standard is not based on Stringprep, and
RFC 6122 will be obsoleted when an alternative to the Nodeprep and Resourceprep
profiles has been completed.
XMPP software implementations are in encouraged by RFC 6122 to follow IDNA2008
instead, and Pontarius XMPP should try to do that.
\end_layout
\begin_layout Description
REQ-42 JIDs should be validated, transformed, and internationalized in accordanc
e with the successor to the stringprep profiles
e with the stringprep profiles Nodeprep, Nameprep, and Resourceprep.
\end_layout
\begin_layout Description
REQ-43 JIDs should support internationalization of node names, domain names,
and resource names, through IDNA2008.
REQ-43 JIDs should be supported through hostnames, IPv4 addresses, and IPv6
Jon Kristensen
15 years ago