<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-hartke-xmpp-stupid-00" category="info">
<front>
<title abbrev="STuPiD">STUN/TURN using PHP in Despair</title>
<author initials="K." surname="Hartke" fullname="Klaus Hartke">
<organization>Universität Bremen TZI</organization>
<address>
<email>hartke@tzi.org</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
<date year="2009" month="July" day="05"/>
<area>General</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
<t>“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.</t>
</abstract>
</front>
<middle>
<section anchor="problems" title="Introduction">
<t>NAT (Network Address Translator) Traversal may require TURN
(Traversal Using Relays around NAT)
<xref target="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.</t>
<t>“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
<xref target="RFC5389"/>.</t>
<t>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 <xref target="figimpl"/> in <xref target="impl"/>.
(This single-page script has been tested with a free-of-charge
web hoster, so it should be deployable by literally everyone.)</t>
<section anchor="need" title="The Need for Standardization">
<t>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.</t>
<t>Having one standard form of STuPiD service instead of one
specific to each kind of client also creates an incentive
for optimized implementations.</t>
<t>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 <xref target="xmpp"/>), it is a good
thing if STuPiD is already defined.</t>
<t>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.</t>
</section>
</section>
<section anchor="ops" title="Basic Protocol Operation">
<t>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 <xref target="RFC5389"/>. However, with STuPiD,
STUN is not really needed for TCP, as was demonstrated in
previous STUN-like implementations <xref target="STUNT"/>.
Instead, STuPiD (like <xref target="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.</t>
<t>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 <xref target="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 <xref target="xmpp"/>,
where the out-of-band channel is typically throughput-limited
to on the order of a few kilobits per second.)</t>
<t>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 <xref target="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.</t>
<t>The STuPiD data relay is implemented as follows (see <xref target="figops"/>):</t>
<t><list style="numbers">
<t>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.</t>
<t>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.)</t>
<t>Peer B retrieves the data from the STuPiD server using the URI
provided by Peer A.</t>
</list></t>
<t>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.</t>
<figure title="STuPiD Protocol Operation" anchor="figops"><artwork><![CDATA[
STuPiD ```````````````````````````````,
Script <----------------------------. ,
| ,
^ , | ,
| , | ,
(1) | , | , (3)
POST | , | , GET
| , | ,
| v | v
Peer A -----------------------> Peer B
(2)
out-of-band
Notification
]]></artwork></figure>
</section>
<section anchor="protocol-definition" title="Protocol Definition">
<section anchor="Terminology" title="Terminology">
<t>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
<xref target="RFC2119"/> and indicate requirement levels for compliant STuPiD
implementations.</t>
</section>
<section anchor="discovering-external-ip-address-and-port" title="Discovering External IP Address and Port">
<t>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:</t>
<t>host “:” port</t>
<t>where ‘host’ and ‘port’ are defined as in <xref target="RFC3986"/>.</t>
</section>
<section anchor="storing-data" title="Storing Data">
<t>Data chunks are stored using the POST request of HTTP. The
STuPiD server MUST support one URI parameter which is passed
as query-string:</t>
<t>‘chid’: A unique ID identifying the data chunk to be stored.
The ID SHOULD be chosen from the characters of the base64url
set <xref target="RFC4648"/>.</t>
<t>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.)</t>
<t>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.</t>
<t>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.</t>
<t>The sender MUST wait for the HTTP response before
going on to notify the receiver.</t>
</section>
<section anchor="notification" title="Notification">
<t>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):</t>
<t>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.</t>
<t>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 <xref target="xmpp"/> for one
example of such an out-of-band channel.</t>
</section>
<section anchor="retrieving-data" title="Retrieving Data">
<t>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’.</t>
</section>
</section>
<section anchor="implementation-notes" title="Implementation Notes">
<t>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
(<xref target="impl"/>).
(TODO: It may be useful to provide some hints in the storing
POST request.)</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>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 <xref target="I-D.meyer-xmpp-e2e-encryption"/>.</t>
<t>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 <xref target="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).</t>
<t>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.</t>
</section>
</middle>
<back>
<references title='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>
</references>
<references title='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 & 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>
</references>
<section anchor="xmp" title="Examples">
<t>This appendix provides some examples of the STuPiD protocol operation.</t>
<figure title="Discovering External IP Address and Port" anchor="figxmpdisco"><artwork><![CDATA[
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
]]></artwork></figure>
<figure title="Storing Data" anchor="figxmpstore"><artwork><![CDATA[
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
]]></artwork></figure>
<figure title="Retrieving Data" anchor="figxmpretr"><artwork><![CDATA[
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
]]></artwork></figure>
</section>
<section anchor="impl" title="Sample Implementation">
<figure title="STuPiD Sample Implementation" anchor="figimpl"><artwork><![CDATA[
<?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();
?>
]]></artwork></figure>
</section>
<section anchor="xmpp" title="Using XMPP as Out-Of-Band Channel">
<t>XMPP <xref target="I-D.ietf-xmpp-3920bis"/> is a good choice for
an out-of-band channel.</t>
<t>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 <xref target="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.)</t>
<t>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)</t>
<t>Of course, other methods can be used for setup and teardown, such as Jingle
(see http://xmpp.org/extensions/xep-0261.html).</t>
<figure title="Creating a Bytestream: Initiator requests session" anchor="figxmpcri"><artwork><![CDATA[
<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>
]]></artwork></figure>
<figure title="Creating a Bytestream: Responder accepts session" anchor="figxmpcrr"><artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='jn3h8g65'
to='romeo@montague.net/orchard'
type='result'/>
]]></artwork></figure>
<figure title="Sending Notifications: Notification in an IQ stanza" anchor="figxmpnots"><artwork><![CDATA[
<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>
]]></artwork></figure>
<figure title="Sending Notifications: Acknowledging notification using IQ" anchor="figxmpnota"><artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='kr91n475'
to='romeo@montague.net/orchard'
type='result'/>
]]></artwork></figure>
<figure title="Closing the Bytestream: Request" anchor="figxmpclor"><artwork><![CDATA[
<iq from='romeo@montague.net/orchard'
id='us71g45j'
to='juliet@capulet.com/balcony'
type='set'>
<close xmlns='urn:xmpp:tmp:stupid'
sid='i781hf64'/>
</iq>
]]></artwork></figure>
<figure title="Closing the Bytestream: Success response" anchor="figxmpclos"><artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='us71g45j'
to='romeo@montague.net/orchard'
type='result'/>
]]></artwork></figure>
</section>
</back>
<!-- ##markdown-source:
H4sIAN0V/FkAA+1c63Ibx5X+P0/RC6eWYBYAwYtukBmHN1uMJZImoThZl1ca
zDSAMQcz8FwoIQpT+xD7CPsm+yb7JPt9p7tnBhBI0SltUtlalBVBg76cc/o7
9550u12viIpYD9TV8PXZ1vD15Zkq8yiZqIsXFypK1LHO536Uef5olOkbDisv
omMvTIPEn2FamPnjojv1s+Jad9/P5vNuXpTzKOz2+17oFxix0+8/6/afdPuP
vAAPJmm2GGDlcep50TwbqCIr84KD+juen2l/oL7Ric782HuXZteTLC3nA/WH
VxcX6nv8m6R9w2fetV5gQDhQp0mhs0QX3WPS4nl54SfhGz9OE+y+0Lk3jwbq
hyINOipPsyLT4xzfFjN++dHz/LKYptnAU11P4RMl+UB921MvhCV5ZDj9NvbL
vPk4zSZ+Ev3JL6I0GajXSXSjszwq/us/C3WY6ZlO1PBfT2WknvlRPFBGSr8t
/hT1MHdpw6OeOkyzmZ8kjR2P/CwvsEzzF0y8f68cDOpioC7SvBj7wVTt7vb3
9vryWxAVkL2ZYB6kIfY57u483X30zD4pk4In9I3mpgt5OJ+KLP9l71l3b2e7
u7P9tPt499nOtvyITfJoFsUrA570+/0m84E/SivWvYQsFeACcleXXx/tbG8/
s193nz19bL/u9euvj/eeDoAY4GZ55qPdpzLztHvci3Qx7o701L/R3aLMEj4n
rocDoaTwswlFMy2K+WBrK9QA3qI3itNJPk+LXpDOtoDDJ1v9Z1sAcVJ00xJ/
sCLw1A2mOAId571pMYvNcrXiDNU/q8Zg5QbLuApgqj7ay3Q0ijTQlORpYn8R
IFz2mg8rDYL6POtuP7F8zvRCZ0bb9I7u6iTIFnOBYVMQ8juOqT+KcojO87rd
rvJHAIgfQE3ODoaqfaYLapk6CMNM57kaZtg89os02+R3osyP1cxfqEz/XEaZ
VjQRXrv+7bVYi0sd+4tc+dBMsI+lN9W4TALS5MdAHU1JoLPCjxJYgVznqpj6
BcZrlaSFKpM4utbxQhWpSoOgzHpKDacav0a5wnwIGkcf6IQHz0GhnsfpQohR
uc5IS0fp94GeF2qEZaZprtW7aaoSrUOvmOqZ+u9//w95Qma450iTKF/NUygS
6Gws62PaOzXPUhiNNPbwm5/UZiZIcbZBoUMsE+oOV5lDs6OgjP1Mloa2qHdR
MfXMetC2wsmP3yGnXE2jyZR/G1LTsfDS87zW/Ya4RYn4MhviMuv7I4jHUaug
ICodUdKczYW6FO7yeXQgCqis8uM85dSbKORoCErNYDhUNJvDVPqg200jiSSt
Z3A0i8IQu3qQSpaGpRliPx++wIqgaZbfevuNz/865rwPH9aZgdtb7//B+H8S
jDhw6wJub0EuTsmwEuoJvCBHOaIic/AgN5hG+gbywsnMfIknbEzjq+/1SA4w
CijJ2TwWCZEjOZ1kISP8+TyOAnH7qpaplwc4WA2sHOQiJgzTcOA8SZwumcnT
uHTUB9MUu1A+nn+TGoYbB+QUiPtyKveF0sRhB/LG6nAzObCU+ySyQWotHLJE
fufQMfwChrHUhw/jaMLRt7fmn+Z7D8o1xVgecay7c38CYoMsAn6nQMVII74o
dM5FiCSQMIZ46e3g6OBTvXcgD9ABJhljqahQ+TQt45Cc17CgyHEMjO0AFxxC
tgA4e5ueObkzaIcA5ooBnJ+FNrYSi0LVuaXlufMDW9TkG2RoP1/UikSULVRe
rQ14JKD0K+/rCGEWhQayOm4Fo8crks3BfhwLU9Sq0cJLcTiZmuuUxwArYk4r
iCPRLIuv0uiUQMCgq+cdxQAHpICgY1YmAieMHME0irCnODT3WxHBQomiTdI0
9KJQ+6t6HsnqsFC0YbmGzSLaYRtyjM4M7dCPF/4NdyHtTg4U+KyBGEsgg5FC
+yF/wXAvn+sgGkcBxakZVYIx+dGwKqqrAkTvgAntU2UfPbEACE5mkHi4Kk/Q
9HWUEA48HTJgyRhpMI+lyKMcjdvI0e218zIQm0WjWXAzOAb9Ht9yaz+ZM2xQ
g0xMNloUusvo2J/V9klsX60dDJlubzc7RHAt8WJKqUVNdPkx1glp88ZRokPK
FlEYrEZBPUJ2VIoaj/GF/iU1uJDRkdNRPrGmp5J6ket4jFUynnlB/3CtzZqg
dGLyIn6Fn8gjWlrqIyJPChwUiY2G5CDk90QAZB/QgpJ/AO5GXB3pgEVGdErB
wqitiFY2HpfwnLrihCflHWL9QF042Z3PLbREQdP5irdf9vzDitnKlRllKhZz
oJ8GAWoFYTkTUxtZj1j0IV3rp8eir35R6BkMFJ20OBhlXWF0Q87FXXkzzUg8
yme0bchRoCoYb7xcqGniRubozVnAoTigG8aa7kWpF+k7Gq2OodBw0/E4jZCg
r8URkBMaK2vLhkcXHR7YO/wJ9QyYR/ht8AYU6psoRVLJJYxfXLU3Hz5IekET
fWo0srJQbZlQDdhUxnNS/7xc1mn6MxGdB3GkFgPw/lAb5dsgjAihlxVlE/1N
ZwTTi+HwwmO4APP/nJISjyxRkwU7/tNJWsLrQrTIr2T1n9KR2MgeI0QZDvlU
J5TyUcIDx6rwDFE+dedeGD9E8kWy7eGmkUx1lPSAdSCRMQgU8RuZi0EY06Z4
Y5wFVD+47q1FX17OyXAuW3bUCEoEB824rxYkjm0hFky0xi9848092RVqr9yq
eBAZPQdfazJBzgNAovGC8R8cBrwGDF5CPEl8J4tTzW+gmeIs2/kiCaZZ6koM
kMoEbG32vCutK1tlIiwYdBuz6vcmJMAxGgOZeGvIgcM/4+mLPpGgdSQzNmUM
DTHMuFQM+GcgP+Nhz8ui9ne1EDDFTWeIWwHkPVLO2PAuYLAq56i1El+ywh3P
eIS7yMOyte2oqQIsZogxYLVTZ3bTDE7QeJExRH0dxekIlhankNFZpknIGOSQ
1pwydrGn5epdQ4lAnpEqgWGkF1EbEm/U0F0TXPoWxhIM2mjK+SyZWUVmXiMU
c65nOXZZSiM8Qr1JoaUuNziH4o6A/6aXwcl1G+e2TpoMRFcBx9/vEARRNyrj
a8GtUQfxkYy7Zvod2csjMerYD0YhX7UKDY0U6Fd63JQiJDVOY1CfQxsE9Ahf
6WhuNweet91TF9Sjg46NrsssqAKtWlmVVVZEpkgxRauDaZlcY6RnSiy+slqw
HPuZjIf6PPdh/xQAiihjHNEDcHRLluEa9S+tHr2EOV+zS/0buQt4iIkkkimQ
SwrJAxc5eC5YcmEzvXhKdyi4RYocpjNQlkt0E4VyOIAYLTNco0rK2UhnEOyO
k4qxN1Fl7gPNomFTPp1q78OOTYFrW2Spb1gkCFCc48IpyOvLU2t2uQYhkWlG
Ljc+DIxi0mzcYu1PJR+xqm4BWRlM/Fk2UVihfZCbA5D40azBfWZlXETULYa4
CHdNJs46wliS7wM1QxpYyNlIxVAdwhgYdPgySdJJaOA4em9EAu7JDylIEwAX
xwQBc4UbPxOWJRato84V0dM2SGS8xDCMIJdwdpDKYaJJA80Q8gzrCMQEYl0b
jzUX4iLOc9FY7dpTPnQid5Edj26cASp34dkenF3QHAWsi8EM8LPsF4waWcHW
Ppi8QI+7sIIwWD1kveCHEvOMH7N2V5KjMMqsz2cYpJljWdKJHQk2YYh5SOIe
kNIyO9Hz3CngChuWMhkHKPheGI1BHCVGneJOYOMv1QeBqytM2YWUenv/p1PP
MHZbqS/vSz17qp7xsM+fl2b8m+r8whl//gUz2tubD5+B4bubMu3i/Gr4C6Z9
czL8K+lz/7p5wIyb+jCtlVPqjkP5jRtzeN/ZtHc27/q54SbvGnLWVNEG5D4M
1BfGVZkuwX7LQu/j5Kl1C4BWj4+rDHFdLgW3qTOE5WmcThY1FR++aDxeKpIw
+F7KSI3nutYLVpOgfK1Xr6+GrY75W52dy/fLk+9en16eHLc6XuvqxcHLl3wo
X9yIqxfnr18e19/qmUfnr16dnB2fyI+vDv6INWhSW+cXw9Pzs4OXLSlRGOvH
xDuDDbaufikhOzy6UNt7HXZ4FJtDptLHb4h5uWKUhBS8btYykePe6DgXFyFZ
cEQrb3Psj0sP3nGUBylsCs3MyXtWVOGSTy+qyjT3uUCOcG/dabkGdeCyaUbP
oV2feb3UJtwGzaxL8gFuYhkxeaPkYpANmBTbCRNtraSxiczLROdsbkaRrljK
nhp+5APkmDPElAvPpltrM0H7SIiwxtwEYkyqTQcOARgrfqo1aBnybbi+wacb
ssoGn2/Igds6CY85smk1+3xStfWuEJeRq2PGksviPK5CkdzUthjChQ1XJlbK
yQCOnHIRxr01jNuUT/IlOnt4dHiRQnKxCK6b4Ymfs7AKOrFktmDBCFuB2Y1g
GoUbA8RpqkwixoOnxy64qyKiRuRkIG7oNYE5xlttYXhnAsHKVbOQihwJ0YuL
0FjhfbxXZrGXI6kWkbEJWhW65/4iTk2F7iNBCLe26txIWy01gouNozRh2aw7
XMz1Rk2Zt9EovWylIKmwVbMNZN4xq00M2pZxtaJcbjVJgBDVT5LUJnIruzKQ
8qzCrCxB/ZHgnScgDQ5CyvVLJEMuUluukWTLVSiXt0CK3j7pTXqdRtPHli/q
TNzuZTNHF8ssHaqfeyboRBDYpQaw65oyeGKemxcR45pqNEM9g1ThkKVHZYTI
4G1JdLntdP2EIKmBn0ZPKmaJPZNs22MAKWbB6pOQTHhFXOd9NCuRJLC2HSVS
8BQ0SVi6HNQ3DLVnkPr40aPdxwyoZqAbEEPkLTbGVTqrokgdEkIWEMLCCLKx
fu0TpMRj5WR09lBQLYFb4srnH61YB5rPXeOFR9ZZLZlScVlDFETU9UBE1djR
qhUIsgrDM3WW4J0fFcoVdoRPAG3OZAIk47n2JqkpldeVm6U8inZryfsv263G
fp9Mw6zUaOFhfGhhbyL/rjpSu7JUZNqVxxtycVkCM2RSMS4hoNeXL42pMbNX
dra1OJdJhB3PhPQuyuZsQSOLmFKipYYUTqfrlTrsi8ZlpTlmedi9ytDao5B6
0HKmVOcW4jHvqPp4zmMul9L9OjNmHDGn5JPC1n/WFsAQ2q+ponkfl8/WUcHD
vzTSWuu3KgjYsw+NmVmTqhkJuUQH/tyZ8No9U/p0XHFkMrWigtZdDl4cxhpr
a4ECMsqMxmOUhqwx3WPxyejpsl1mfpivLfQz+Lmve+bsQqhjXVSuXMRAs+Yh
x0cUMi4kXhKsOX91WqzYLAG/aLosxUOWdYzuqjHLAQiUShpAKWHq2J8TuOuW
RxjoEkjripwO2X6frFBnmZBMYKrzkJ2xXVQOGSWtUkNVSDuNQKnMWJcV9AA8
0uv3KlVzB7oElOcmZrdeieXCLLqJpPHjzf3gWjPTRaSWCiccFvjsMUoVLbKd
1qrZJd0cP4q9tqsxbrLfe358PqBg7S6YD0shybgx9HIm0hyrmtC5idO8ZqjR
8Geu62lbv/5kkukJI3RXEzB1WHa1oLrsB8rB2fIJwGmXzE2PZhXZjWqtMa/O
4buNjBVBgBK66MpYgrr9JrXKRs4QqrazJ855GoWkC9007ibGeLgkr3llolMF
7s27ADlOG9FgwNTCtnddNbecO55WVMJ4K4p7KmVDS2Qj4gXWSilxO2VAAJqX
YzBOafO51FnvDcekGCY2zrXSlMHLq8XVdy9lS0abEou75vHRUvP4rs6e83R2
Ujr6STpwJu6wNNUJH3WOQ+VbNJbrQEV1q2eKYBZGN5CKoikrdcQAJ925z5Zg
URD8mdTb6SSmkLGcxNiXBlGe+xNtWzmcNx5/PBGK1uNFAXNrBc8kZRR775gQ
F5ITHp2lmwxeVS+Tg5sv+XBbZKY+28ag0gg7+W/TivzD8OWVMveT7ry+J7H9
K/qd6rqAE2yz+Sx3PxyoETKUs7kBE1t89zCuJiUTvNoz17XpnLjy8jIyt13q
WropPCecZ1KQPrM2KxTPtWyl88fmNPNIpuE+O7TLOJUwthmxeB8RodpaQvV1
FNaVcZ8XaaW/Y/ixVVyToFa9F2T1wJQxLpsMO8SyFYyyP7Yt/sSnZuDcE84S
NJhGB4s/ttm+MCaRwb9L0sZFY6xT9qXY2hVSxWZSoZbDNUfASDvqDAPiEN3V
DF4gpRicnbElaBOeL/3WuKnmmZtqyjSLlplnnEFa7F0+9kih+icm9slZUAI4
626+Z/ILXmhCVvS+TgVEHtpNW2as6rOmrtK1XJVVSl0aez9wNT2StWWuj/fm
07kwuLXd69ufX0NW3QPgrBgoSyt+3d7u7dkBBwGv3A3Ur7d+bZ+8SLG8o9Bc
upbPUdWIHqhvtZ53D2LeVTFEmTygospSsc1ruOr8W/v0WG7mXpVJR/Ufqd/B
dfIKu+r3B7v474n65pUrh17JCQ/UAVz3VG/t9HYcEfx3lyFalsYDhADdgE86
albmRTdjGyXiBWA7/OT9HDYpx6Z+0VE7j2XT7WfPnoCAAfYFdfWmv/d5h9sI
pHvCDIw2qGJegsKXOpkU04GSa8X81JIYKAZjiHz3tzt0jft7/f79oltemvHm
QN0VVjrJbj/b6fV7EMjus8Hu48eP9taUUAFEqaK5OupDS3Ysq96PNtHIBty+
YoFnP3rydHs6frzX7f/t4feLZHjHWW5XsNUwh3xlAmb6s+B6B7je+0fCdf9v
Deu16LV5su0CNCqdn0boij38+wP08+Boe7Dz7B8JR9vbfyf72FThtdhiGumg
tVKPkLbSlSlmrGTw/Hz4QlLB9WH9Ei6//ArQ8xBqIxdotx56Jq3N59Wchx1M
c8bDxMQZ3myR/xy/sRfL2nKpgg2IjmohMM34sg0bUSysseHFKWZGjhw9KN6E
o3bLaJis9iuqmNpXZgxv873ReeDP9RvTB2j/6g2U8ocWh7V+5IxorPDw6uTy
9yeXP0jn7ORq+ObVyfDF+XHrR7W/r1qY0dpUH+QyAkazSrloy06b9jE+vJmn
mgu9Oh+evDk4Pr7EKj3psvQ+/v3i/HLY+vE517hVOs61kANhl3FRsSGNjHbr
6uTlydFQvWW68lZ9fXn+Sr09lu9Y+u4Waev7FyeXJ+ot6X2LNTeE8o1Wg3az
KfJXt+NYF8H0jZ9l/sJR01Gv/ohc883B1dX5UWOuY910O96Y0q2s9kOLlIqU
zTjDYXOmw4szhGqvv8cClfqar4S06pn2b0tdpvUbQ5WjbrMhwmqDB61+6zUE
fz8OGHB8GggP23WZ0qVzPsY5D08ecMDuZGnK8gKm4q36Uh0fAFZXrw/bZ+ff
tzc76vRsCJ4OXqpH6tXp2evhyWYt1l9J5rvvzs4U+tvjKNZvJrqgUlKL83YL
FmSwtRUl87IAbp43YPNPS6SfnkGAQ+557khvG+B1LG437wNrC3RC7KptMdoB
WDlrY7O1jLg1Mt5Vh37oPPAKctwZmyXWTIZsTN2J53Rg0lC7hhstTwd06R31
4uTguKMMHJ57t86GxWmu23jw1W/WWHua65W7BGutu9h9836UvDOLPPG8LLrn
4+4hQ+Mj20YwKd787hvbDWcg6zTerGq+V8j3SNw9+aV3Wu6qm9dVcZvNVnki
b8dRBMizZylLqK5aa+7xe6eJYeGQbS1xALlqnx4edpBDa8++00naGMdsVW8C
5Fvv4YT7/b0n8ubmZg/uJy+kB+4HtgIJL5HPfZPts0Sms6UiwaW71SZN48ab
EZxs6nOur+WaXeZ6XXVnEWSB6VzetFm+YBWUWWZLzvOUVbBMh9Bz35T2pHrJ
i6T2vp+X65/dNSpzj5SFEvzavC1oXh4p3qXPXXmYtSv7woDcl7evY9ibz3V5
o9H0XLkj59nkngKQi3R+YfqLpsQsb35ICQq2hCXhZmssr9rRYDLQ7K9XN8RM
RXiqF6wSerY7xor/uNF6qW/ardwldOOltOl7jRdiXDuoHbLrNJNe6Yh3k3Vw
7VjcwLobrJFl0ags9Kb0Me19GXe7xLVhl7euXooCXgtz2wCkRHNpHribNI7b
1UbSWm46fCNaGp3mFQepZUmfIuJ9wboXZxl77mAoxbLV3d2LP7aGaDtjiQRn
bIgfhP6chSa2BB+sOV8QHjja8zFLcRnbsaZ9a2ruuWsjSkGQB5JrBFamUq79
LEzfIRdwtavfyZtmntzq/RQBO4+3requJkz4fBn9LGzsb+B/dPrbGZyOPyl1
L9HFVprxWkW40XAYyKA2fkp2p08njx81nxcpnpcxDNxvEe+VsTbvg4/8GMJc
LI1EULoP7BQbv6mefpnOgYb3szjJ9zf44jmZGRSz+cAElxsrLmuEQPW6yy7D
/oY03lcH5KTTpXof/QjF/JOP33/e2HI0fLkV/bzOb4CQIIuc5zgSPZVeY21G
+f+gEBURX8CtWzAWNeJO7hH6w0R2n9AfdmxG6CZYI9N3MJp9glGTvFIzfEn9
lvn8POi6zp5tJ3tPPie6JM56OLpgYfY3+r8IUmUW729YRWyUA+6pPjwIenR6
VdRivcuSaxgs/dNc9lCn31mIf1wi+SvBd9eZfEbwgVX/E6weBNdJ+g6BzYQ/
LnkUcwPg9LtPcPxwFJb5k+3J3qOfPiMKJTr7BTBcQdyDTFWc1iqM7ZyrXtZh
E6N/LmzcJanPaZjAyqfYumLnM8+re0jg738A/F0Wy55HAAA=
-->
</rfc>