asciidoctor-rfc 0.2.0 → 0.8.0

data/spec/examples/stupid-s.mkd.adoc

@@ -0,0 +1,771 @@
+= STUN/TURN using PHP in Despair
+Klaus Hartke <hartke@tzi.org>; Carsten Bormann <cabo@tzi.org>
+:doctype: internet-draft
+:abbrev: STuPiD
+:name: draft-hartke-xmpp-stupid-00
+:date: 2009-07-05
+:status: informational
+:ipr: trust200902
+:area: General
+:workgroup: XMPP Working Group
+:keyword: Internet-Draft
+:toc-include: yes
+:sort-refs: yes
+:sym-refs: yes
+:forename_initials: K.
+:organization: Universität Bremen TZI
+:forename_initials_2: C.
+:organization_2: Universität Bremen TZI
+:street_2: Postfach 330440
+:city_2: Bremen
+:code_2: D-28359
+:country_2: Germany
+:phone_2: +49-421-218-63921
+:fax_2: +49-421-218-7000
+
+
+[abstract]
+NAT (Network Address Translator) Traversal may require TURN
+(Traversal Using Relays around NAT) functionality in certain
+cases that are not unlikely to occur.  There is little
+incentive to deploy TURN servers, except by those who need
+them — who may not be in a position to deploy a new protocol
+on an Internet-connected node, in particular not one with
+deployment requirements as high as those of TURN.
+
+"STUN/TURN using PHP in Despair" is a highly deployable
+protocol for obtaining TURN-like functionality, while also
+providing the most important function of STUN.
+
+[#problems]
+== Introduction        
+
+NAT (Network Address Translator) Traversal may require TURN
+(Traversal Using Relays around NAT)
+<<I-D.ietf-behave-turn>>
+functionality in certain
+cases that are not unlikely to occur.  There is little
+incentive to deploy TURN servers, except by those who need
+them — who may not be in a position to deploy a new protocol
+on an Internet-connected node, in particular not one with
+deployment requirements as high as those of TURN.
+
+"STUN/TURN using PHP in Despair" is a highly deployable
+protocol for obtaining TURN-like functionality, while also
+providing the most important function of STUN
+<<RFC5389>>.
+
+The high degree of deployability is achieved by making STuPiD
+a Web service, implementable in any Web application deployment
+scheme.  As PHP appears to be the solution of choice for
+avoiding deployment problems in the Web world, a PHP-based
+sample implementation of STuPiD is presented in <<figimpl>> in <<impl>>.
+(This single-page script has been tested with a free-of-charge
+web hoster, so it should be deployable by literally everyone.)
+
+[#need]
+=== The Need for Standardization   
+
+If STuPiD is so easy to deploy, why standardize on it?
+First of all, STuPiD server implementations will be done by
+other people than the clients making use of the service.
+Clearly communicating between these communities is a good
+idea, in particular if there are security considerations.
+
+Having one standard form of STuPiD service instead of one
+specific to each kind of client also creates an incentive
+for optimized implementations.
+
+Finally, where STuPiD becomes part of a client standard
+(such as a potential extension to XMPP's in-band byte-stream
+protocol as hinted in <<xmpp>>), it is a good
+thing if STuPiD is already defined.
+
+Hence, this document focuses on the definition of the STuPiD
+service itself, tries to make this as general as possible
+without increasing complexity or cost and leaves the details
+of any client standards to future documents.
+
+[#ops]
+== Basic Protocol Operation 
+
+The STuPiD protocol will typically be used with application
+instances that first attempt to obtain connectivity using
+mechanisms similar to those described in the STUN
+specification <<RFC5389>>.  However, with STuPiD,
+STUN is not really needed for TCP, as was demonstrated in
+previous STUN-like implementations <<STUNT>>.
+Instead, STuPiD (like <<STUNT>>) provides a
+simple Web service that
+echoes the remote address and port of an incoming HTTP
+request; in most cases, this is enough to get the job done.
+
+In case no connection can be established with this simple
+STUN(T)-like mechanism, a TURN-like relay is needed as a final
+fall-back.
+The STuPiD protocol supports this, but solely provides a way
+for the data to be
+relayed.  STuPiD relies on an out-of-band channel to notify
+the peer whenever new data is available (synchronization signal).
+See <<xmpp>> for one likely example of such an
+out-of-band channel.
+(Note that the out-of-band channel may have a much lower
+throughput than the STuPiD relay channel — this is exactly
+the case in the example provided in <<xmpp>>,
+where the out-of-band channel is typically throughput-limited
+to on the order of a few kilobits per second.)
+
+By designing the STuPiD web service in such a way that it can
+be implemented by a simple PHP script such as that presented
+in <<impl>>, it is easy to deploy by those who
+need the STuPiD services.
+The combination of the low-throughput out-of-band channel for
+synchronization and the STuPiD web service for bulk data
+relaying is somewhat silly but gets the job done.
+
+The STuPiD data relay is implemented as follows (see <<figops>>):
+
+. Peer A, the source of the data to be relayed, stores a chunk of
+   data at the STuPiD server using an opaque identifier, the "chunk
+   identifier". How that chunk identifier is chosen is local to Peer
+   A; it could be composed of a random session id and a sequence number.
+. Peer A notifies the receiver of the data, Peer
+   B, that a new data chunk is available, specifying the URI needed
+   for retrieval.
+   This notification is provided through an out-out-band channel.
+   (As an optimization for multiple consecutive transfers, A might
+   inform B once of a constant prefix of that URI and only send a
+   varying part such as a sequence number in each notification —
+   this is something to be decided in the client-client notification
+   protocol.)
+. Peer B retrieves the data from the STuPiD server using the URI
+   provided by Peer A.
+
+Note that the data transfer mechanism is one-way, i.e. to send
+data in the other direction as well, Peer B needs to perform
+the same steps using a STuPiD server at the same or a
+different location.
+
+[#figops]
+.STuPiD Protocol Operation
+====
+....
+
+
+        STuPiD   ```````````````````````````````,
+        Script   <----------------------------. ,
+                                              | ,
+          ^ ,                                 | ,
+          | ,                                 | ,
+    (1)   | ,                                 | ,  (3)
+    POST  | ,                                 | ,  GET
+          | ,                                 | ,
+          | v                                 | v
+
+        Peer A   ----------------------->   Peer B
+                           (2)
+                       out-of-band
+                       Notification
+....
+====
+
+
+== Protocol Definition
+
+[#Terminology]
+=== Terminology          
+
+In this document, the key words "**MUST**", "**MUST NOT**", "**REQUIRED**",
+"**SHALL**", "**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**" are to be interpreted as described in BCP 14, RFC 2119
+<<RFC2119>> and indicate requirement levels for compliant STuPiD
+implementations.
+
+
+=== Discovering External IP Address and Port
+
+A client may discover its external IP address and the port
+required for port prediction by performing a HTTP GET
+request to a STuPiD server. The STuPiD server **MUST** reply
+with the remote address and remote port in the following
+format:
+
+host ":" port
+
+where 'host' and 'port' are defined as in <<RFC3986>>.
+
+
+=== Storing Data
+
+Data chunks are stored using the POST request of HTTP. The
+STuPiD server **MUST** support one URI parameter which is passed
+as query-string:
+
+'chid':  A unique ID identifying the data chunk to be stored.
+The ID **SHOULD** be chosen from the characters of the base64url
+set <<RFC4648>>.
+
+The payload of the POST request **MUST** be the data to be
+stored. The 'Content-Type' **SHOULD** be
+'application/octet-stream', although a STuPiD server
+implementation **SHOULD** simply ignore the 'Content-Type' as a
+client implementation may be restricted and may not able to
+specify a specific 'Content-Type'.  (E.g., in certain cases,
+the peer may be limited to sending the data as
+multipart-form-encoded — still, the data is stored as a
+byte stream.)
+
+STuPiD servers may reject data chunks that are larger than
+some predefined limit.
+This maximum size in bytes of each data chunk is **RECOMMENDED**
+to be 65536 or more.
+
+As HTTP already provides data transparency,
+the data chunk **SHOULD NOT** be encoded using Base64 or any
+other data transparency mechanism; in any case, the STuPiD
+server will not attempt to decode the chunk.
+
+The sender **MUST** wait for the HTTP response before
+going on to notify the receiver.
+
+
+=== Notification
+
+The sender notifies the receiver of the data chunk by passing
+via an out-of-band channel (which is not part of the STuPiD
+protocol):
+
+The full URL from which the data chunk can be retrieved,
+i.e. the same URL that was used to store the data chunk,
+including the chunk ID parameter.
+
+The exact notification mechanism over the out-of-band channel
+and the definition of a session is dependent on the
+out-of-band channel.  See <<xmpp>> for one
+example of such an out-of-band channel.
+
+
+=== Retrieving Data
+
+The notified peer retrieves the data chunk using a GET request
+with the URL supplied by the sender. The STuPiD server **MUST**
+set the 'Content-Type' of the returned body to
+'application/octet-stream'.
+
+
+== Implementation Notes
+
+A STuPiD server implementation **SHOULD** delete stored data some
+time after it was stored. It is **RECOMMENDED** not to delete the
+data before five minutes have elapsed after it was stored.
+Different client protocols will have different reactions to
+data that have been deleted prematurely and cannot be
+retrieved by the notified peer; this may be as trivial as
+packet loss or it may cause a reliable byte-stream to fail
+(<<impl>>).
+(TODO: It may be useful to provide some hints in the storing
+POST request.)
+
+STuPiD clients should aggregate data in order to minimize the
+number of requests to the STuPiD server per second.
+The specific aggregation method chosen depends on the data
+rate required (and the maximum chunk size), the latency
+requirements, and the application semantics.
+
+Clearly, it is up to the implementation to decide how the data
+chunks are actually stored.  A sufficiently silly STuPiD server
+implementation might for instance use a MySQL database.
+
+
+== Security Considerations
+
+The security objectives of STuPiD are to be as secure as if
+NAT traversal had succeeded, i.e., an on-path attacker can
+overhear and fake messages, but an off-path attacker cannot.
+If a higher level of security is desired, it should be
+provided on top of the data relayed by STuPiD, e.g. by using
+XTLS <<I-D.meyer-xmpp-e2e-encryption>>.
+
+Much of the security of STuPiD is based on the assumption that
+an off-path attacker cannot guess the chunk identifiers.  A
+suitable source of randomness <<RFC4086>> should
+be used to generate at least a sufficiently large part of the
+chunk identifiers (e.g., the chunk identifier could be a hard
+to guess prefix followed by a serial number).
+
+To protect the STuPiD server against denial of service and
+possibly some forms of theft of service, it is **RECOMMENDED**
+that the POST side of the STuPiD server be protected by some
+form of authentication such as HTTP authentication.  There is
+little need to protect the GET side.
+
+[bibliography]
+== Normative References
+++++
+
+<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
+<front>
+<title>
+Key words for use in RFCs to Indicate Requirement Levels
+</title>
+<author initials="S." surname="Bradner" fullname="S. Bradner">
+<organization/>
+</author>
+<date year="1997" month="March"/>
+<abstract>
+<t>
+In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="14"/>
+<seriesInfo name="RFC" value="2119"/>
+<seriesInfo name="DOI" value="10.17487/RFC2119"/>
+</reference>
+
+<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
+<front>
+<title>Uniform Resource Identifier (URI): Generic Syntax</title>
+<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
+<organization/>
+</author>
+<author initials="R." surname="Fielding" fullname="R. Fielding">
+<organization/>
+</author>
+<author initials="L." surname="Masinter" fullname="L. Masinter">
+<organization/>
+</author>
+<date year="2005" month="January"/>
+<abstract>
+<t>
+A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="STD" value="66"/>
+<seriesInfo name="RFC" value="3986"/>
+<seriesInfo name="DOI" value="10.17487/RFC3986"/>
+</reference>
+
+<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086">
+<front>
+<title>Randomness Requirements for Security</title>
+<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
+<organization/>
+</author>
+<author initials="J." surname="Schiller" fullname="J. Schiller">
+<organization/>
+</author>
+<author initials="S." surname="Crocker" fullname="S. Crocker">
+<organization/>
+</author>
+<date year="2005" month="June"/>
+<abstract>
+<t>
+Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
+</t>
+<t>
+Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="106"/>
+<seriesInfo name="RFC" value="4086"/>
+<seriesInfo name="DOI" value="10.17487/RFC4086"/>
+</reference>
+
+<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648">
+<front>
+<title>The Base16, Base32, and Base64 Data Encodings</title>
+<author initials="S." surname="Josefsson" fullname="S. Josefsson">
+<organization/>
+</author>
+<date year="2006" month="October"/>
+<abstract>
+<t>
+This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="4648"/>
+<seriesInfo name="DOI" value="10.17487/RFC4648"/>
+</reference>
+++++
+
+[bibliography]
+== Informative References
+++++
+<reference anchor="RFC5389" target="https://www.rfc-editor.org/info/rfc5389">
+<front>
+<title>Session Traversal Utilities for NAT (STUN)</title>
+<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
+<organization/>
+</author>
+<author initials="R." surname="Mahy" fullname="R. Mahy">
+<organization/>
+</author>
+<author initials="P." surname="Matthews" fullname="P. Matthews">
+<organization/>
+</author>
+<author initials="D." surname="Wing" fullname="D. Wing">
+<organization/>
+</author>
+<date year="2008" month="October"/>
+<abstract>
+<t>
+Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
+</t>
+<t>
+STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.
+</t>
+<t>
+This document obsoletes RFC 3489. [STANDARDS-TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="5389"/>
+<seriesInfo name="DOI" value="10.17487/RFC5389"/>
+</reference>
+
+<reference anchor="I-D.ietf-behave-turn">
+<front>
+<title>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)</title>
+
+<author initials='J' surname='Rosenberg' fullname='Jonathan Rosenberg'>
+    <organization />
+</author>
+
+<author initials='R' surname='Mahy' fullname='Rohan Mahy'>
+    <organization />
+</author>
+
+<author initials='P' surname='Matthews' fullname='Philip Matthews'>
+    <organization />
+</author>
+
+<date month='July' day='3' year='2009' />
+
+<abstract><t>If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers).  In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay.  This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.  TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.  The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE.</t></abstract>
+
+</front>
+
+<seriesInfo name='Internet-Draft' value='draft-ietf-behave-turn-16' />
+<format type='TXT'
+        target='http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-16.txt' />
+</reference>
+
+<reference anchor="STUNT" target="http://deusty.blogspot.com/2007/09/stunt-out-of-band-channels.html">
+  <front>
+    <title>STUNT &amp; out-of-band channels</title>
+    <author initials="R." surname="Hanson" fullname="Robbie Hanson">
+      <organization></organization>
+    </author>
+    <date year="2007" month="September" day="17"/>
+  </front>
+</reference>    
+<reference anchor="I-D.meyer-xmpp-e2e-encryption">
+<front>
+<title>XTLS: End-to-End Encryption for the Extensible Messaging and Presence Protocol (XMPP) Using Transport Layer Security (TLS)</title>
+
+<author initials='D' surname='Meyer' fullname='Dirk Meyer'>
+    <organization />
+</author>
+
+<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
+    <organization />
+</author>
+
+<date month='June' day='29' year='2009' />
+
+<abstract><t>This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic.  XTLS is an application-level usage of Transport Layer Security (TLS) that is set up using the XMPP Jingle extension for session negotiation and transported using any streaming transport as the data delivery mechanism.  Thus XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, enabling XMPP entities to communicate in a way that is designed to ensure the confidentiality and integrity XML stanzas.  The protocol can be used for secure end-to-end messaging as well as other XMPP applications, such as file transfer.</t></abstract>
+
+</front>
+
+<seriesInfo name='Internet-Draft' value='draft-meyer-xmpp-e2e-encryption-02' />
+<format type='TXT'
+        target='http://www.ietf.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.txt' />
+</reference>  
+  
+  
+<reference anchor="I-D.ietf-xmpp-3920bis">
+<front>
+<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
+
+<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
+    <organization />
+</author>
+
+<date month='December' day='20' year='2010' />
+
+<abstract><t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920.</t></abstract>
+
+</front>
+
+<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-3920bis-22' />
+<format type='TXT'
+        target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3920bis-22.txt' />
+</reference>
+
+++++
+
+[#xmp]
+== Examples  
+
+This appendix provides some examples of the STuPiD protocol operation.
+
+[#figxmpdisco]
+.Discovering External IP Address and Port
+====
+....
+   Request:
+
+      GET /stupid.php HTTP/1.0
+      User-Agent: Example/1.11.4
+      Accept: */*
+      Host: example.org
+      Connection: Keep-Alive
+
+   Response:
+
+      HTTP/1.1 200 OK
+      Date: Sun, 05 Jul 2009 00:30:37 GMT
+      Server: Apache/2.2
+      Cache-Control: no-cache, must-revalidate
+      Expires: Sat, 26 Jul 1997 05:00:00 GMT
+      Vary: Accept-Encoding
+      Content-Length: 17
+      Keep-Alive: timeout=1, max=400
+      Connection: Keep-Alive
+      Content-Type: application/octet-stream
+
+      192.0.2.239:36654
+....
+====
+
+[#figxmpstore]
+.Storing Data
+====
+....
+   Request:
+
+      POST /stupid.php?chid=i781hf64-0 HTTP/1.0
+      User-Agent: Example/1.11.4
+      Accept: */*
+      Host: example.org
+      Connection: Keep-Alive
+      Content-Type: application/octet-stream
+      Content-Length: 11
+
+      Hello World
+
+   Response:
+
+      HTTP/1.1 200 OK
+      Date: Sun, 05 Jul 2009 00:20:34 GMT
+      Server: Apache/2.2
+      Cache-Control: no-cache, must-revalidate
+      Expires: Sat, 26 Jul 1997 05:00:00 GMT
+      Vary: Accept-Encoding
+      Content-Length: 0
+      Keep-Alive: timeout=1, max=400
+      Connection: Keep-Alive
+      Content-Type: application/octet-stream
+....
+====
+
+[#figxmpretr]
+.Retrieving Data
+====
+....
+   Request:
+
+      GET /stupid.php?chid=i781hf64-0 HTTP/1.0
+      User-Agent: Example/1.11.4
+      Accept: */*
+      Host: example.org
+      Connection: Keep-Alive
+
+   Response:
+
+      HTTP/1.1 200 OK
+      Date: Sun, 05 Jul 2009 00:21:29 GMT
+      Server: Apache/2.2
+      Cache-Control: no-cache, must-revalidate
+      Expires: Sat, 26 Jul 1997 05:00:00 GMT
+      Vary: Accept-Encoding
+      Content-Length: 11
+      Keep-Alive: timeout=1, max=400
+      Connection: Keep-Alive
+      Content-Type: application/octet-stream
+
+      Hello World
+....
+====
+
+[#impl]
+== Sample Implementation 
+
+[#figimpl]
+.STuPiD Sample Implementation
+====
+[source,php]
+----
+<?php
+header("Cache-Control: no-cache, must-revalidate");
+header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");
+header("Content-Type: application/octet-stream");
+
+mysql_connect(localhost, "username", "password");
+mysql_select_db("stupid");
+
+$chid = mysql_real_escape_string($_GET["chid"]);
+
+if ($_SERVER["REQUEST_METHOD"] == "GET") {
+   if (empty($chid)) {
+      echo $_SERVER["REMOTE_ADDR"] . ":" . $_SERVER["REMOTE_PORT"];
+   } elseif ($result = mysql_query("SELECT `data` FROM `Data` " .
+                         "WHERE `chid` = '$chid'")) {
+      if ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
+         echo base64_decode($row["data"]);
+      } else {
+         header("HTTP/1.0 404 Not Found");
+      }
+      mysql_free_result($result);
+   } else {
+      header("HTTP/1.0 404 Not Found");
+   }
+} elseif ($_SERVER["REQUEST_METHOD"] == "POST") {
+   if (empty($chid)) {
+      header("HTTP/1.0 404 Not Found");
+   } else {
+      mysql_query("DELETE FROM `Data` " .
+                  "WHERE `timestamp` < DATE_SUB(NOW(), INTERVAL 5 MINUTE)");
+      $data = base64_encode(file_get_contents("php://input"));
+      if (!mysql_query("INSERT INTO `Data` (`chid`, `data`) " .
+                       "VALUES ('$chid', '$data')")) {
+         header("HTTP/1.0 403 Bad Request");
+      }
+   }
+} else {
+   header("HTTP/1.0 405 Method Not Allowed");
+   header("Allow: GET, HEAD, POST");
+}
+mysql_close();
+?>
+----
+====
+
+[#xmpp]
+== Using XMPP as Out-Of-Band Channel  
+
+XMPP <<I-D.ietf-xmpp-3920bis>> is a good choice for
+an out-of-band channel.
+
+The notification protocol is closely modeled after XMPP's
+In-Band Bytestreams (IBB, see
+http://xmpp.org/extensions/xep-0047.html). Just replace the
+namespace and insert the STuPiD Retrieval URI instead of the
+actual Base64 encoded data, see <<figxmpnots>>.
+(Note that the current proposal redundantly sends a sid and a
+seq as well as the chid composed of these two; it may be
+possible to optimize this, possibly sending the constant prefix
+of the URI once at bytestream creation time.)
+
+Notifications **MUST** be processed in the order they are
+received. If an out-of-sequence notification is received for a
+particular session (determined by checking the 'seq' attribute),
+then this indicates that a notification has been lost. The
+recipient **MUST NOT** process such an out-of-sequence notification,
+nor any that follow it within the same session; instead, the
+recipient **MUST** consider the session invalid.  (Adapted from
+http://xmpp.org/extensions/xep-0047.html#send)
+
+Of course, other methods can be used for setup and teardown, such as Jingle
+(see http://xmpp.org/extensions/xep-0261.html).
+
+[#figxmpcri]
+.Creating a Bytestream: Initiator requests session
+====
+[source,xml]
+----
+      <iq from='romeo@montague.net/orchard'
+          id='jn3h8g65'
+          to='juliet@capulet.com/balcony'
+          type='set'>
+        <open xmlns='urn:xmpp:tmp:stupid'
+              block-size='65536'
+              sid='i781hf64'
+              stanza='iq'/>
+      </iq>
+----
+====
+
+[#figxmpcrr]
+.Creating a Bytestream: Responder accepts session
+====
+[source,xml]
+----
+      <iq from='juliet@capulet.com/balcony'
+          id='jn3h8g65'
+          to='romeo@montague.net/orchard'
+          type='result'/>
+----
+====
+
+[#figxmpnots]
+.Sending Notifications: Notification in an IQ stanza
+====
+[source,xml]
+----
+      <iq from='romeo@montague.net/orchard'
+          id='kr91n475'
+          to='juliet@capulet.com/balcony'
+          type='set'>
+        <data xmlns='urn:xmpp:tmp:stupid'
+              seq='0'
+              sid='i781hf64'
+              url='http://example.org/stupid.php?chid=i781hf64-0'/>
+      </iq>
+----
+====
+
+[#figxmpnota]
+.Sending Notifications: Acknowledging notification using IQ
+====
+[source,xml]
+----
+      <iq from='juliet@capulet.com/balcony'
+          id='kr91n475'
+          to='romeo@montague.net/orchard'
+          type='result'/>
+----
+====
+
+[#figxmpclor]
+.Closing the Bytestream: Request
+====
+[source,xml]
+----
+      <iq from='romeo@montague.net/orchard'
+          id='us71g45j'
+          to='juliet@capulet.com/balcony'
+          type='set'>
+        <close xmlns='urn:xmpp:tmp:stupid'
+               sid='i781hf64'/>
+      </iq>
+----
+====
+
+[#figxmpclos]
+.Closing the Bytestream: Success response
+====
+[source,xml]
+----
+      <iq from='juliet@capulet.com/balcony'
+          id='us71g45j'
+          to='romeo@montague.net/orchard'
+          type='result'/>
+----
+====
+
+