xep-0263.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>ECO-XMPP</title>
  <abstract>This specification defines best practices and protocol modifications that will reduce the energy consumption of XMPP systems and thereby help to save the planet.</abstract>
  &LEGALNOTICE;
  <number>0263</number>
  <status>Active</status>
  <type>Humorous</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>eco-xmpp</shortname>
  <author>
    <firstname>Peter</firstname>
    <surname>Saint-Andre</surname>
    <email>stpeter@jabber.org</email>
  </author>
  <author>
    <firstname>Fabio</firstname>
    <surname>Forno</surname>
    <email>bdg@bluendo.com</email>
  </author>
  <revision>
    <version>1.0</version>
    <date>2009-04-01</date>
    <initials>psa/ff</initials>
    <remark><p>April Fools!</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>The Extensible Messaging and Presence Protocol (XMPP) is an extremely wasteful technology for real-time communication over the Internet. Because the sky is indeed falling, this specification defines techniques (collectively called ECO-XMPP&#174;) that can help to minimize the carbon footprint (and thereby assuage the eco-guilt) of XMPP users.</p>
  <p>The authors of this document realize that the spoiled, selfish users of today's Internet will not easily give up their unnecessarily interactive real-time technologies. Therefore our recommendations take a phased approach to the development of more ecologically-friendly communication methods. Phase One  defines best practices that can be pursued within the context of current XMPP implementations. Phase Two defines protocol simplifications that will significantly reduce the environmental impact of XMPP technologies. Phase Three proposes more radical solutions that will help to realize the ultimate dream of saving the planet.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
  <p>This specification is designed to meet the following requirements:</p>
  <ol start='1'>
    <li>Save the planet.</li>
    <li>Love your mother. <note>Mother Earth, that is. Loving your human mother is merely another example of anthropocentric speciesism.</note></li>
    <li>Reduce, reuse, recycle.</li>
    <li>Earth first, humans second, and computers a <em>very</em> distant third.</li>
  </ol>
</section1>
<section1 topic='Phase One' anchor='phase1'>
  <p>The following best practices are RECOMMENDED in Phase One.</p>
  <ol start='1'>
    <li><p>It is traditional for instant messaging (IM) clients to show a light bulb icon next to XMPP roster items in order to indicate network availability or "presence". The standard image used is an incandescent bulb. However, incandescent light bulbs are evil. Therefore, ECO-XMPP&#174; clients MUST instead use an image of a compact flourescent bulb.</p></li>
    <li><p>To be ecologically-minded means to save resources. Yet XMPP allows a user to connect with multiple resources simultaneously. This is excessive. Therefore, ECO-XMPP&#174; servers MUST prevent users from using more than one resource at a time.</p></li>
    <li><p>ECO-XMPP&#174; systems SHOULD do everything possible to reduce bandwidth consumption. Therefore it is RECOMMENDED to use &xep0239; rather than standard XML streams.</p></li>
    <li><p>Recycling is a key to energy reduction. Therefore, ECO-XMPP&#174; clients SHOULD actively discourage users from generating new messages. ECO-XMPP&#174; servers MAY keep a history of interesting messages that they can substitute for the mindless drivel generated by the typical IM user (cf. &xep0148;), or even refuse to deliver such messages to the intended recipient. This is especially important in the context of &xep0045;, &xep0060;, and other message multiplexers.</p></li>
    <li><p>The &XSF; SHOULD consider establishing an organizational unit that is dedicated to encouraging and, if necessary, enforcing earth-friendly practices; this unit might provide subsidies to ecologically-friendly software projects <note>Subsidies are always necessary to encourage the development and use of green technologies.</note>, establish packet-offset trading programs similar to carbon offsets, and define a certification process for the ECO-XMPP&#174; brand.</p></li>
    <li><p>Software applications that comply with the ECO-XMPP&#174; guidelines MAY initially allow entities to generate traffic that violates these rules, but SHOULD mark such traffic as &xep0076; and MAY annoy offending users using technologies such as &xep0132;.</p></li>
  </ol>
</section1>
<section1 topic='Phase Two' anchor='phase2'>
  <p>The best practices proposed in Phase One are merely stop-gap measures that leave the core XMPP (or ECO-XMPP&#174;) technology intact. Yet this technology is itself ecologically problematic. In Phase Two, the XMPP community will undertake a concerted reform program that will consist of the following changes:</p>
  <ol start='1'>
    <li><p>Presence uses more bandwidth and energy than any other aspect of XMPP (perhaps 80% of the packets in an XMPP system are consumed by presence notifications). Therefore presence MUST be eliminated, resulting in a slimmed-down technology called Extensible Messaging Protocol or XMP.</p></li>
    <li><p>In XMPP, presence is closely tied to XML streams (e.g., when a client closes its stream, the server automatically sends an unavailable presence stanza on behalf of the client). Once we get rid of presence, we can also get rid of XML streams and, indeed, XML itself (all that extensibility is a lavish extravagance). This radical simplification of XMPP will result in a technology called Simple Messaging Protocol or SMP.</p></li>
    <li><p>Once XML streams are removed, entities need a way to transfer messages among themselves. Therefore we need to add some special message transfer semantics, resulting in a technology called Simple Message Transfer Protocol or SMTP. However, because XML has also been removed, we no longer need to support extensible messages and can use plain old mail messages instead. This enables us to reuse and recycle an existing Internet technology called Simple Mail Transfer Protocol (also SMTP), as defined in &rfc0822;. (Yes, more modern versions of SMTP have been defined, but they include unnecessary extensions; back to basics and RFC 822!)</p></li>
    <li><p>The transfer semantics of SMTP are mainly for server-to-server communication. For client-to-server communication, an XMPP client can use &xep0013;, which provides semantics similar to Post Office Protocol Version 3 (POP3) and thus enables a client to log in and retrieve messages, then quickly log off again to save energy. But why stop there? Instead of using XEP-0013, it makes sense to use POP3 itself as defined in &rfc1939;, or even the original Post Office Protocol defined in &rfc0918; (there never was a need to define more than a thousand RFCs, so we suggest that specifications after RFC 999 SHOULD be ignored).</p></li>
  </ol>
  <p>Thus instead of using fancy real-time technologies like XMPP, it is time to return to an older, simpler time and just use SMTP and POP for communication over the Internet.</p>
</section1>
<section1 topic='Phase Three' anchor='phase3'>
  <p>Although the measures described Phase One and Phase Two will reduce energy consumption, they only go so far. The next step is to stop using Internet communication technologies entirely. The XSF and other organizations SHOULD encourage worldwide blackouts of online communication services, similar to the "Earth Hour" movement whereby people around the world choose to turn off their electric lights for an hour. This kind of voluntary service outage has already been employed with great success by non-XMPP messaging services like Twitter <note>Twitter is a popular "microblogging" service that causes people to spend inordinate amounts of time chattering about what they're doing at any given moment. This kind of technology is a huge time-sink and a tremendous waste of energy. However, at least Twitter has been a pioneer in voluntary service outages, thus paving the way for an Internet-free future; for details, see <link url='http://failwhale.com/'>failwhale.com</link>.</note> as well as by Blackberry, Skype, Gmail, MSN, and others. However, to date such efforts have been random and ad-hoc, so now it is time to pursue them in a more rigorous, coordinated fashion.</p>
  <p>If Internet communication services are increasingly unavailable, people around the world will learn to live more quietly, without the "need" (really a frivolous desire) to send messages to people all over the world. Why chat over the Internet when you can walk to the local pub or bistro for human interaction, ride your bicycle to meet a friend in your own town, work in a community garden, or forage for food in the forest? Yes, it will be difficult for some people to transition from "always-on" to "always-off"; however, we are doing this for the good of the planet, so we are sure that no one will mind if we force them to be free from the tyranny of constant interruptions. Internet users unite: you have nothing to lose but the false god of real-time interaction! Verily, the Internet is the opiate of the masses!</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
  <p>Think globally, act locally.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>This entire document deals with security, since the future security of Planet Earth depends on eliminating wasteful practices of energy consumption.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>Because this specification calls for an end to the use of XML streams, the XML namespaces listed in registries maintained by &IANA; can safely be removed. Indeed, we look forward to the day when Internet standards organizations like the IANA, the IETF, and the XSF will wither away like the Marxian state.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>The &REGISTRAR; shall require a new section in all XEPs: the Environmental Impact Statement. </p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
  <p>Because this specification recommends an XML-free profile of XMPP, no XML schema is needed. Indeed, data extensibility is merely one symptom of a deeper disease: atomistic individualism and the ceaseless desire for personalized, customized experiences. Get over it, will you? One color (gray) is good enough for everyone, and the same is true of data fields.</p>
</section1>
</xep>