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®) that can help to minimize the carbon footprint (and thereby assuage the eco-guilt) of XMPP users.
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.
This specification is designed to meet the following requirements:
The following best practices are RECOMMENDED in Phase One.
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® clients MUST instead use an image of a compact flourescent bulb.
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® servers MUST prevent users from using more than one resource at a time.
ECO-XMPP® systems SHOULD do everything possible to reduce bandwidth consumption. Therefore it is RECOMMENDED to use Binary XMPP (XEP-0239) [2] rather than standard XML streams.
Recycling is a key to energy reduction. Therefore, ECO-XMPP® clients SHOULD actively discourage users from generating new messages. ECO-XMPP® servers MAY keep a history of interesting messages that they can substitute for the mindless drivel generated by the typical IM user (cf. Instant Messaging Intelligence Quotient (IM IQ) (XEP-0148) [3]), or even refuse to deliver such messages to the intended recipient. This is especially important in the context of Multi-User Chat (XEP-0045) [4], Publish-Subscribe (XEP-0060) [5], and other message multiplexers.
The XMPP Standards Foundation (XSF) [6] 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 [7], establish packet-offset trading programs similar to carbon offsets, and define a certification process for the ECO-XMPP® brand.
Software applications that comply with the ECO-XMPP® guidelines MAY initially allow entities to generate traffic that violates these rules, but SHOULD mark such traffic as Malicious Stanzas (XEP-0076) [8] and MAY annoy offending users using technologies such as Presence Obtained via Kinesthetic Excitation (POKE) (XEP-0132) [9].
The best practices proposed in Phase One are merely stop-gap measures that leave the core XMPP (or ECO-XMPP®) 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:
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.
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.
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 RFC 822 [10]. (Yes, more modern versions of SMTP have been defined, but they include unnecessary extensions; back to basics and RFC 822!)
The transfer semantics of SMTP are mainly for server-to-server communication. For client-to-server communication, an XMPP client can use Flexible Offline Message Retrieval (XEP-0013) [11], 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 RFC 1939 [12], or even the original Post Office Protocol defined in RFC 918 [13] (there never was a need to define more than a thousand RFCs, so we suggest that specifications after RFC 999 SHOULD be ignored).
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.
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 [14] 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.
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!
Think globally, act locally.
This entire document deals with security, since the future security of Planet Earth depends on eliminating wasteful practices of energy consumption.
Because this specification calls for an end to the use of XML streams, the XML namespaces listed in registries maintained by the Internet Assigned Numbers Authority (IANA) [15] 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.
The XMPP Registrar [16] shall require a new section in all XEPs: the Environmental Impact Statement.
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.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. Mother Earth, that is. Loving your human mother is merely another example of anthropocentric speciesism.
2. XEP-0239: Binary XMPP <https://xmpp.org/extensions/xep-0239.html>.
3. XEP-0148: Instant Messaging Intelligence Quotient (IM IQ) <https://xmpp.org/extensions/xep-0148.html>.
4. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.
5. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.
6. The XMPP Standards Foundation (XSF) is an independent, non-profit membership organization that develops open extensions to the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <https://xmpp.org/about/xmpp-standards-foundation>.
7. Subsidies are always necessary to encourage the development and use of green technologies.
8. XEP-0076: Malicious Stanzas <https://xmpp.org/extensions/xep-0076.html>.
9. XEP-0132: Presence Obtained via Kinesthetic Excitation (POKE) <https://xmpp.org/extensions/xep-0132.html>.
10. RFC 822: Standard for the Format of ARPA Internet Text Messages <http://tools.ietf.org/html/rfc0822>.
11. XEP-0013: Flexible Offline Message Retrieval <https://xmpp.org/extensions/xep-0013.html>.
12. RFC 1939: Post Office Protocol - Version 3 <http://tools.ietf.org/html/rfc1939>.
13. RFC 918: Post Office Protocol <http://tools.ietf.org/html/rfc0918>.
14. 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 failwhale.com.
15. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
16. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
April Fools!
END