From 137f7e976469420696ba4390bcfd6a8cbf598751 Mon Sep 17 00:00:00 2001 From: Jon Kristensen Date: Fri, 30 Mar 2012 18:31:48 +0200 Subject: [PATCH] removal of srs document from the git repository --- .../Software Requirements Specification.lyx | 1256 ----------------- 1 file changed, 1256 deletions(-) delete mode 100644 Documentation/Software Requirements Specification.lyx diff --git a/Documentation/Software Requirements Specification.lyx b/Documentation/Software Requirements Specification.lyx deleted file mode 100644 index 03687c7..0000000 --- a/Documentation/Software Requirements Specification.lyx +++ /dev/null @@ -1,1256 +0,0 @@ -#LyX 2.0 created this file. For more info see http://www.lyx.org/ -\lyxformat 413 -\begin_document -\begin_header -\textclass article -\use_default_options true -\maintain_unincluded_children false -\language english -\language_package default -\inputencoding auto -\fontencoding global -\font_roman default -\font_sans default -\font_typewriter default -\font_default_family default -\use_non_tex_fonts false -\font_sc false -\font_osf false -\font_sf_scale 100 -\font_tt_scale 100 - -\graphics default -\default_output_format default -\output_sync 0 -\bibtex_command default -\index_command default -\paperfontsize default -\spacing single -\use_hyperref false -\papersize default -\use_geometry false -\use_amsmath 1 -\use_esint 1 -\use_mhchem 1 -\use_mathdots 1 -\cite_engine basic -\use_bibtopic false -\use_indices false -\paperorientation portrait -\suppress_date false -\use_refstyle 1 -\index Index -\shortcut idx -\color #008000 -\end_index -\secnumdepth 3 -\tocdepth 3 -\paragraph_separation indent -\paragraph_indentation default -\quotes_language english -\papercolumns 1 -\papersides 1 -\paperpagestyle default -\tracking_changes false -\output_changes false -\html_math_output 0 -\html_css_as_file 0 -\html_be_strict false -\end_header - -\begin_body - -\begin_layout Title -Pontarius 1.0 Software Requirements Specification (Fourth Draft) -\end_layout - -\begin_layout Author -Nejla -\end_layout - -\begin_layout Date -March 25, 2012 -\end_layout - -\begin_layout Standard -\begin_inset CommandInset toc -LatexCommand tableofcontents - -\end_inset - - -\end_layout - -\begin_layout Section -Introduction -\end_layout - -\begin_layout Subsection -Purpose -\end_layout - -\begin_layout Standard -The goal of this document is to clarify---for Pontarius developers, the - XMPP community, and to some extent the Haskell community---what we are - implementing. - We hope that it will help us to keep track of functionality and requirements, - provide a basis for scheduling, and help us with our validation and verificatio -n processes. -\end_layout - -\begin_layout Subsection -Scope -\end_layout - -\begin_layout Standard -Pontarius 1.0 will implement the client capabilities of RFC 6120: XMPP: Core - and the depending specifications, such as RFC 6122: XMPP: Address Format, - RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2, RFC 4422: - Simple Authentication and Security Layer (SASL), RFC 5280: Internet X.509 - Public Key Infrastructure Certificate and Certificate Revocation List (CRL) - Profile, and Extensible Markup Language (XML) 1.0, among others. -\end_layout - -\begin_layout Standard -Support for common extensions such as Instant Messaging, Data Forms, Service - Discovery, server components, XMPP server capabilities, etc. - will -\emph on -not -\emph default - be included in the 1.0 version. -\end_layout - -\begin_layout Standard -We will not repeat the specifics of the requirements from the RFC 6120: - XMPP Core specification and its depending specifications in this document - unless we see any special reason to. -\end_layout - -\begin_layout Subsection -Definitions, acronyms, and abbrevations -\end_layout - -\begin_layout Description -JID JabberID: An address for XMPP entities -\end_layout - -\begin_layout Description -Pontarius A free and open source software project that aims to produce XMPP-base -d, uncentralized, and privacy-aware software solutions -\end_layout - -\begin_layout Description -P1 Pontarius 1.0 -\end_layout - -\begin_layout Description -REQ Requirement -\end_layout - -\begin_layout Description -RFC Request for Comments: A memorandum published by the Internet Engineering - Task Force; some of these, including XMPP: Core and XMPP: Address Format, - are published as Internet standards -\end_layout - -\begin_layout Description -TCP Transmission Control Protocol: A reliable network transport protocol -\end_layout - -\begin_layout Description -TLS Transport Layer Security: A secure network protocol, a successor to - Secure Sockets Layer (SSL) -\end_layout - -\begin_layout Description -XMPP Extendable Messaging and Presence Protocol: An uncentralized, open, - and near-real-time presence and messaging protocol -\end_layout - -\begin_layout Subsection -References -\end_layout - -\begin_layout Itemize -Extensible Messaging and Presence Protocol (XMPP): Core, RFC 6120, March - 2011, Internet Engineering Task Force (see also its depending specifications) -\end_layout - -\begin_layout Subsection -Overview -\end_layout - -\begin_layout Standard -The second section provides an overall description of the requirements of - P1, going through the features in a non-strict fashion, talking shortly - about the product functions, as well as some constraints and assumptions. -\end_layout - -\begin_layout Standard -The third section simply lists the requirements, categorized by external - interfaces, functions, performance requirements, design constraints, and - software system (quality) attributes. -\end_layout - -\begin_layout Section -Overall Description -\end_layout - -\begin_layout Subsection -Product perspective -\end_layout - -\begin_layout Standard -P1 will be used by XMPP clients to manage presence and messaging in a uncentrali -zed near-real-time environments. - For this first milestone of the library, we have chosen to implement only - the XMPP: Core specification, and only the client capabilities of it. - The reason for this is that we want to get the library out quickly, and - want to have the core functionality of the library particularly well tested. - The X in XMPP stands for extendable, and Pontarius must be flexible in - regards for extensions, such as RFCs and XEPs; we might end up implementing - hundreds of them. - This is one of the most important quality attribute of the software. -\end_layout - -\begin_layout Standard -P1 is designed to be used with Haskell. -\end_layout - -\begin_layout Standard -P1 must work on GNU/Linux, the main Free Software operating system. - However, due to the platform support and high-level nature of Haskell, - running it on other common operating systems is likely to work as well. -\end_layout - -\begin_layout Standard -P1 must work with (at least) the (estimated) most popular free and open - source software XMPP server that works with the specifics of our implementation - (such as SCRAM). -\end_layout - -\begin_layout Standard -P1 depends on the below (free and open source software) Haskell packages. - I have omitted specification number [...]. - I have also omitted the source, as they are all available on Hackage. -\end_layout - -\begin_layout Standard -\begin_inset space \space{} -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Tabular - - - - - - - -\begin_inset Text - -\begin_layout Plain Layout -Name (Mnemonic) -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -Version Number -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -Purpose -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -base -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -base64-string -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -binary -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -bytestring -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -containers -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -crypto-api -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -enumerator -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -hslogger -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -network -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -pureMD5 -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -QuickCheck -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -random -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -regex-posix -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -text -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -tls -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -0.4.1 -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -transformers -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -utf8-string -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -xml-enumerator -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\begin_inset Text - -\begin_layout Plain Layout -xml-types -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - -\begin_inset Text - -\begin_layout Plain Layout -N/A -\end_layout - -\end_inset - - - - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset space \space{} -\end_inset - - -\end_layout - -\begin_layout Standard -Every P1 client will open up at most one TCP port on the system. - P1 in itself does not write anything to the file system storage of the - operating system, with the exception of the optional logging facility, - disabled by default, which may be configured to write to disk. -\end_layout - -\begin_layout Standard -We will utilize -\emph on -at least -\emph default - Transport Layer Security to help protect clients using the library from - attacks. - P1 will not provide any spam protection. -\end_layout - -\begin_layout Standard -As we expect a very limited amount of concurrent XMPP clients, and a (relatively -) limited actitivity over XMPP streams--even when they are being fully active--w -e are not specifying any detailed memory or (process) performance requirements - for P1. - However, we will stress test the library. -\end_layout - -\begin_layout Standard -We see no hardware or user interfaces to take into account. -\end_layout - -\begin_layout Subsection -Product functions -\end_layout - -\begin_layout Standard -P1 implements XMPP: Core and allow clients to do roughly the following: - Open a TCP connection to a server, exchange XML information with the server - to configure the (XML) stream, handle stream errors and encoding issues, - have the connection secured by TLS, authenticate using a SASL mechanism - and binding a resource to the stream, as well as sending and receiving - so-called XMPP stanzas, certain -\begin_inset Quotes eld -\end_inset - -top level -\begin_inset Quotes erd -\end_inset - - XML elements in the stream for communicating messages and presence. -\end_layout - -\begin_layout Subsection -User characteristics -\end_layout - -\begin_layout Standard -We expect developers using P1 to understand the XMPP: Core specification - (and its depending specifications), Haskell, and monads, including the - StateT monad transformer. -\end_layout - -\begin_layout Subsection -Constraints -\end_layout - -\begin_layout Standard -In addition to the requirements in XMPP: Core, XMPP applications should - be reliable in that they should be able to be online (active or inactive) - for a very long period of time, without problems of memory leaks, unnecessary - CPU usage, or similar, arising. -\end_layout - -\begin_layout Subsubsection -Assumptions and dependencies -\end_layout - -\begin_layout Standard -We assume that the Glasgow Haskell Compiler (GHC) is available on the system - where P1 applications are built. -\end_layout - -\begin_layout Section -Specific requirements -\end_layout - -\begin_layout Subsection -External interfaces -\end_layout - -\begin_layout Standard -The software is accessible from Haskell and may be configured to do logging. -\end_layout - -\begin_layout Description -REQ-1 The system shall be importable and fully functional from Haskell through - a full import of the Network.XMPP namespace. -\end_layout - -\begin_layout Description -REQ-2 The system shall be able to log information through arbitrary and - flexible log handlers. -\end_layout - -\begin_layout Description -REQ-3 The system shall run under GNU/Linux. -\end_layout - -\begin_layout Description -REQ-4 The system shall work against (at least) the (estimated) most popular - free and open source software XMPP server supporting the features that - we require (such as SCRAM). -\end_layout - -\begin_layout Subsection -Functions -\end_layout - -\begin_layout Standard -If an error arises due to a bug in the software, the system shall throw - a runtime exception and the process should exit. - If an -\begin_inset Quotes eld -\end_inset - -acceptable -\begin_inset Quotes erd -\end_inset - - exception is possible to arise, such as the XMPP server times out, then - the related functions should reflect that by being able to return values - such as Nothing or null. - This allows the XMPP clients to take the appropriate actions. -\end_layout - -\begin_layout Description -REQ-5 The system shall be validating input from all functions exposed through - any of the system's APIs. - -\end_layout - -\begin_layout Description -REQ-6 Each incoming stanza should move through a stack of (client) handlers, - where each handler may block the stanza from being delivered to handlers - further up in the stack. - The exceptions to this rule is stanza errors and IQ result stanzas, which - may be delivered directly to a callback provided when generating the stanza - (and possibly surpressed there). -\end_layout - -\begin_layout Standard -Rationale: We have so far found it useful to stack XMPP client handlers - on top of each other, letting them all manage their particular responsibilities - and surpress their messages to handlers further up the stack. -\end_layout - -\begin_layout Description -REQ-7 When the client is disconnected, a -\begin_inset Quotes eld -\end_inset - -disconnect event -\begin_inset Quotes erd -\end_inset - - is generated in a way similar to in REQ-5. - It is moved through the stack handlers; however, these events move down - the stacks completely and can't be surpressed. - The same thing applies for incoming stream errors, which can either be - recoverable or unrecoverable. - (?) -\end_layout - -\begin_layout Standard -Rationale: We want the handlers to all do the appropriate clean-up activities. -\end_layout - -\begin_layout Description -REQ-8 The API shall allow for opening a stream to a given IP or host name - on a given port, returning either a success value or the reason for failing. -\end_layout - -\begin_layout Description -REQ-9 The API shall allow for securing an opened stream with TLS, returning - either a success value or the reason for failing. -\end_layout - -\begin_layout Description -REQ-10 The API shall allow for authenticating an opened (possibly TLS secured) - stream, returning either a success value of the reason for failing. - If the credentials were wrong, the system shall allow the client to make - as many retries as allowed by the server, without restarting the stream. -\end_layout - -\begin_layout Description -REQ-11 The API shall allow for perform resource binding on an authenticated - stream, either by trying to set a specific resource, or have the server - generate one. -\end_layout - -\begin_layout Standard -Rationale: Even though most clients wants to do REQ-8, REQ-9, REQ-10, and - REQ-11 in one action, some uses of XMPP (such as In-Band Registration) - demands more flexibility. -\end_layout - -\begin_layout Description -REQ-12 The API shall provide a convenience function for opening a stream, - securing the stream with TLS, authenticating an XMPP account, and perform - resource binding in one function call, returning either a success value - or the reason for failing. -\end_layout - -\begin_layout Standard -Rationale: This makes the library easier and more efficient to use for most - uses cases. -\end_layout - -\begin_layout Description -REQ-13 The API shall provide the possibility for clients to close the stream. -\end_layout - -\begin_layout Description -REQ-14 The API shall provide the possibility for clients to send stream - errors. -\end_layout - -\begin_layout Description -REQ-15 The API shall allow a convenient way for -\begin_inset Quotes eld -\end_inset - -standard disconnect -\begin_inset Quotes erd -\end_inset - - the client. -\end_layout - -\begin_layout Description -REQ-16 The API shall provide a facility for convenient stanza (message, - presence, info/query) creation, eliminating the risk of illegal stanzas - where feasible. -\end_layout - -\begin_layout Description -REQ-17 The API shall allow for convenient construction of JabberIDs. -\end_layout - -\begin_layout Description -REQ-18 The API shall provide utility functions to check whether or not a - JID is full or bare. -\end_layout - -\begin_layout Description -REQ-19 The API shall provide conversion functions to convert from a string - to ( -\begin_inset Quotes eld -\end_inset - -Maybe -\begin_inset Quotes erd -\end_inset - -) JID, and JID to string. -\end_layout - -\begin_layout Description -REQ-20 The API shall provide an optional way for clients to receive time-out - events on requests made, such as an IQ or connection attempt. - The time-out interval should be customizable. -\end_layout - -\begin_layout Description -REQ-21 The library should generate an internal infinite list of unique stanza - IDs; the API should provide a way for application developers to acquire - any amount of such IDs -\end_layout - -\begin_layout Description -REQ-22 The system must offer timeout callbacks to be called if an asynchronous - result is not guaranteed to be produced in a timely fashion. -\end_layout - -\begin_layout Description -REQ-23 The system must a convenient API to deal with stanza and stream errors. -\end_layout - -\begin_layout Subsection -Performance requirements -\end_layout - -\begin_layout Standard -There is only one XMPP client per instance of the system. -\end_layout - -\begin_layout Description -REQ-24 Regular desktop computers should be able to run hundreds of P1 clients. -\end_layout - -\begin_layout Description -REQ-25 P1 should support virtually as many stanzas per second as (non-throttled) - XMPP servers are able to route. - This goes for both lightweight, heavy and mixed stanzas. -\end_layout - -\begin_layout Description -REQ-26 Processing (parsing, generating, and firing the event) a received - stanza should take at most 0.01 seconds. -\end_layout - -\begin_layout Subsection -Design constraints -\end_layout - -\begin_layout Subsubsection -RFC 6120: XMPP: Core -\end_layout - -\begin_layout Description -REQ-27 The system shall support one persistant TCP stream/connection between - the XMPP client and the XMPP server. -\end_layout - -\begin_layout Description -REQ-28 The system shall implement (at least) the TLS_RSA_WITH_AES_128_CBC_SHA - cipher suite for TLS. -\end_layout - -\begin_layout Description -REQ-29 The system shall support (at least) the SHA-1 variant of SASL Salted - Challenge Response Authentication Mechanism (SCRAM-SHA-1). -\end_layout - -\begin_layout Description -REQ-30 XML namespaces for stanzas should always be known to the client. -\end_layout - -\begin_layout Description -REQ-31 We must validate incoming XML (though not against the XML schemas). -\end_layout - -\begin_layout Description -REQ-32 The system shall always check for the appropriate features before - trying to use them. -\end_layout - -\begin_layout Description -REQ-33 End-to-end presence or anything else presence-related defined outside - of XMPP: Core (such as in XMPP: Instant Messaging) is -\emph on -not -\emph default - supported. -\end_layout - -\begin_layout Subsubsection -RFC 6122: XMPP: Address Format -\end_layout - -\begin_layout Description -REQ-34 JIDs should be validated, transformed, and internationalized in accordanc -e with the stringprep profiles Nodeprep, Nameprep, and Resourceprep. -\end_layout - -\begin_layout Description -REQ-35 JIDs should be able to use hostnames, IPv4 addresses, and IPv6 addresses, - as domainparts. -\end_layout - -\begin_layout Subsubsection -Standards compliance -\end_layout - -\begin_layout Description -REQ-36 The project and its source code shall adhere to the guidelines prestented - in the guidelines found at http://www.haskell.org/haskellwiki/Programming_guideli -nes. -\end_layout - -\begin_layout Subsection -Software system attributes -\end_layout - -\begin_layout Description -REQ-37 The system shall be -\emph on -extendable -\emph default -; it must be flexible in regards for extensions, such as RFCs and XEPs. -\end_layout - -\begin_layout Description -REQ-38 The system shall be -\emph on -reliable -\emph default -; it should produce not crash, lag behind, or get some data corruption under - very heavy and lengthy use. -\end_layout - -\begin_layout Description -REQ-39 The system shall be -\emph on -secure -\emph default -; steps should be taken to protect the clients against man-in-the-middle - attacks and the like. -\end_layout - -\end_body -\end_document