XEP Editor

commit 2ac91f50c862f5ebccba409789c4a1c2f8dac461 Author: Peter Saint-Andre Date: Mon Oct 2 22:22:13 2006 +0000 Initial revision git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2 4b5297f7-1745-476d-ba37-a9c6900126ab diff --git a/all.sh b/all.sh new file mode 100755 index 00000000..192295e1 --- /dev/null +++ b/all.sh @@ -0,0 +1,31 @@ +#!/bin/sh +# for each XEP, generates HTML file and IETF reference, then copies XML file +# also generates HTML for the README and template +# finally, copies the stylesheet, DTD, and schema +# usage: ./all.sh + +xeppath=/var/www/stage.xmpp.org/extensions + +ls xep-0*.xml > tmp.txt +sed s/xep-$.*$.xml/\1/ tmp.txt > nums.txt +rm tmp.txt + +while read f +do + xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html + xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.JSF.XEP-$f.xml + cp xep-$f.xml $xeppath/ +done < nums.txt + +rm nums.txt + +xsltproc xep.xsl xep-README.xml > $xeppath/README.html +xsltproc xep.xsl xep-template.xml > $xeppath/template.html + +cp xep.dtd $xeppath/ +cp xep.ent $xeppath/ +cp xep.xsd $xeppath/ +cp xep.xsl $xeppath/ + +# END + diff --git a/announce.py b/announce.py new file mode 100755 index 00000000..113aa6ad --- /dev/null +++ b/announce.py @@ -0,0 +1,187 @@ +#!/usr/bin/env python + +# File: announce.py +# Version: 0.8 +# Description: a script for announcing XEPs +# Last Modified: 2006-10-03 +# Author: Peter Saint-Andre (stpeter@jabber.org) +# License: public domain +# HowTo: ./announce.py xepnum dbuser dbpw 'cvsmodsurl' +# NOTE: the cvsmodsurl MUST be in quotes! + +# IMPORTS: +# +import glob +import MySQLdb +import os +from select import select +import smtplib +import socket +from string import split,strip,join,find +import sys +import time +from xml.dom.minidom import parse,parseString,Document + +def getText(nodelist): + thisText = "" + for node in nodelist: + if node.nodeType == node.TEXT_NODE: + thisText = thisText + node.data + return thisText + +# get the seconds in the Unix era +now = int(time.time()) + +# READ IN ARGS: +# +# 1. XEP number +# 2. database user +# 3. database password + +xepnum = sys.argv[1]; +dbuser = sys.argv[2]; +dbpw = sys.argv[3]; +mods = sys.argv[4]; + +xepfile = 'xep-' + xepnum + '.xml' + +# PARSE XEP HEADERS: +# +# - title +# - abstract +# - version +# - date +# - initials +# - remark + +thexep = parse(xepfile) +xepNode = (thexep.getElementsByTagName("xep")[0]) +headerNode = (xepNode.getElementsByTagName("header")[0]) +titleNode = (headerNode.getElementsByTagName("title")[0]) +title = getText(titleNode.childNodes) +abstractNode = (headerNode.getElementsByTagName("abstract")[0]) +abstract = getText(abstractNode.childNodes) +statusNode = (headerNode.getElementsByTagName("status")[0]) +xepstatus = getText(statusNode.childNodes) +typeNode = (headerNode.getElementsByTagName("type")[0]) +xeptype = getText(typeNode.childNodes) +revNode = (headerNode.getElementsByTagName("revision")[0]) +versionNode = (revNode.getElementsByTagName("version")[0]) +version = getText(versionNode.childNodes) +dateNode = (revNode.getElementsByTagName("date")[0]) +date = getText(dateNode.childNodes) +initialsNode = (revNode.getElementsByTagName("initials")[0]) +initials = getText(initialsNode.childNodes) +remNode = (revNode.getElementsByTagName("remark")[0]) +# could be

XEP Editor

In accordance with XEP-0001, the XEP Editor is responsible for overall management of the Jabber Software Foundation's standards process and publication of XMPP Extension Protocols; in particular, the XEP Editor:

works with XEP authors
ensures that each XEP is properly formatted
assigns a unique number to each XEP
assigns or modifies the status of each XEP
maintains each XEP under source control
maintains the canonical list of XEPs
publishes each XEP to the xmpp.org website
publicly announces the existence and status of each XEP
gathers and tallies the votes of the XMPP Council
fulfills the responsibilities of the XMPP Registrar

Since the founding of the Jabber Software Foundation in 2001, the XEP Editor has been Peter Saint-Andre, who may be contacted via <editor@jabber.org>.

+ + + + + + + + + + + + + + + + + + + + + + JEP- + + + + + + Document Information + Document Author(s) + + Name: + + + + + + + Email: + + + + + + JID: + + + + + Abstract + + + + Document Status + + + + Dependencies/References + + + + Legal Notice + + + + Revision History + + + + + + + + + Version + + + Date + + + Initials + + + Comment + + + + +

+ + + + + + + + + IJEP-: + + + Page of + + + + + Notes: + + + + + + + + + + + + + + + + + + + + Table of Contents + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + . + + + + + + + + + + + + + + + + + + + + + + + + + . + + + + + + + + + + + + + + + + + + . + + + + + + + + + + + + + + + + + + + + + + + + . + . + + + + + + + + + + + + + + + + + + . + + + + + + + + + + + + + + + + + FR-. + + SS-. + + + + + + + + + + + + + + + + + + + + + + + + Example . + + + + + + + + + + + + +

+ + + + + + + + + [ + + ] + + + + + + + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + • + + + + + + + + + + + + + + + + . + + + + + + + + +

GPS Datum Example

The following example of GPS datum differences was kindly provided by Randy Steele of Apollo, Pennsylvania (URL: <http://www.nb.net/~resteele/>) and is archived here so that a permanent link is available from JEP-0080: User Geolocation.

BEGIN EXAMPLE

This is an example of the differences in the datums you can use with a GPS. +Below is a site I was checking out. I marked it on my GPS in the field. When I got back +home to find it on the topo map, I noticed something was not right. Using +the UTM coordinates from the GPS, I located the site on the topo map. But +the map site and the site I checked in the field did not match. The terrain +was different, the site I actually checked was near the road (the top red +circle). I then remembered about map datums. The topo map was made to NAD27, while +my GPS was set to WGS84. After changing the GPS to the NAD27 datum, all was fine. +So the moral of this story is: MAKE SURE THE GPS DATUM AND THE MAP DATUM MATCH!!! +Note the difference in the circle locations. I also changed my GPS datum to NAD27.

GPS Datum Example +

END EXAMPLE

XMPP Extensions

ATOM RSS

The Jabber Software Foundation (JSF) develops extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs). The process is managed by the XMPP Extensions Editor and involves intensive discussion on the Standards-JIG mailing list, formal review and voting by the XMPP Council, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal IPR Policy for wide implementation. Submissions are welcome (see also the "inbox"). Changes are tracked via a CVS repository (see instructions), old versions are available, and IETF-style XML reference files are provided.

This page lists approved XMPP extensions as well as proposals that are under active consideration. A list of all XEPs (including retracted, rejected, deprecated, and obsolete XEPs) is also available. Good places for developers to start are the basic and intermediate protocol suites.

Note: The following table is sortable, just click on the headers (click twice to reverse the sort order).

Number	Name	Type	Status	Date

JSF IPR Policy

This document defines the official policy of the Jabber Software Foundation regarding intellectual property rights (IPR) pertaining to XMPP Extension Protocol (XEPs) specifications.

Version 1.2

Table of Contents:

1. Introduction
2. Terms
3. Terms of Contributing to XMPP Extensions
4. Legal Notice +

1. Introduction

This document defines the official policy of the Jabber Software Foundation (JSF) regarding intellectual property rights (IPR) as they pertain to extensions to XMPP in the form of XMPP Extension Protocol specifications (XEPs). [1]

+
1.1 History
+
The Jabber/XMPP protocols have been under development since 1998 and have been discussed and documented in public forums since January 1999 in the open-source projects that were a precursor to the JSF. Through force of history and activity since its founding in the summmer of 2001, the JSF has assumed responsibility for managing the evolution of the Jabber/XMPP protocols in two ways: (1) through working with the IETF to standardize the core protocols under the name Extensible Messaging and Presence Protocol (XMPP); and (2) through the definition of extensions to the core protocol in the JSF's XMPP Extension Protocol (XEP) specification series. Through this work, the JSF has in effect "homesteaded" the domain of XMPP Extensions and has acted as a trusted third party or "intellectual property conservancy" [2] to which new and established participants in the Jabber community have entrusted their XMPP Extensions.
+
1.2 Purpose
+
The JSF does not seek to disparage the legitimate rights of any individual or organization to assert ownership over an Implementation of XMPP or of any XMPP Extension. However, the JSF must ensure that XMPP Extensions do not pollute the free and open nature of the protocols. Preventing such pollution means that in perpetuity any entity may independently, and without payment or hindrance, create, use, sell, distribute, or dispose of implementations of XMPP and of any XMPP Extension. Such is the intent of this policy.
+

2. Terms

+
2.1 XMPP +
+
The core XML streaming, instant messaging, and presence protocols developed by the Jabber community have been contributed by the JSF to the Internet Engineering Task Force (IETF) under the name Extensible Messaging and Presence Protocol (XMPP). XMPP is all and only these core protocols, as currently defined in RFC 3920 and RFC 3921.
+

+
2.2 XMPP Extension
+
For the purposes of this IPR policy, an XMPP Extension is any specification approved by, or submitted for approval or consideration by, the JSF or its constituent committees (most particularly the XMPP Council). Such a specification must exist in the form of a standards-track XMPP Extension Protocol (XEP) specification in order to be considered an official submission. (Also referred to as an Extension.)
+

+
2.3 Implementation
+
Any software that implements XMPP or XMPP Extensions for the purpose of providing the functionality defined by the relevant specification(s).
+

+
2.4 Intellectual Property Claim
+
Any patent, copyright, or other proprietary claim or claims made by an entity regarding a XMPP Extension. (Also referred to as a Claim.)
+

3. Terms of Contributing an XMPP Extension

The JSF recognizes the possibility that the creator of an XMPP Extension may make an Intellectual Property Claim regarding an XMPP Extension. Therefore, the JSF takes the following positions:

+
3.1 Ownership
+
By submitting an XMPP Extension for consideration by the JSF, the author of the Extension shall assign any ownership rights or other Claims asserted over the Extension to the JSF. This does not apply to Claims regarding any Implementations of the Extension, but rather to the Extension itself. Any documentation of the Extension (in the form of a XEP specification) shall be copyrighted by the JSF. Once an author assigns ownership to the JSF, the JSF shall in turn make the Extension available to all entities so that they may create, use, sell, distribute, or dispose of implementations of XMPP and all XMPP Extensions in perpetuity and without payment or hindrance.
+
+
3.3 Approval of Extensions
+
No Extension shall be approved by the JSF or its constituent committees if there are Claims to the Extension itself, or any Claims that would prevent perpetual, unrestricted, royalty-free use of the Extension in a compliant Implementation by any interested party. If Claims preventing such use are discovered, the JSF shall immediately seek to replace the Extension with unencumbered protocols that may be implemented without condition by any entity.
+
3.3 A Note about Private Extensions
+
By its nature as XML, XMPP enables implementers to create their own private extensions to XMPP within custom XML namespaces. Such extensions may be kept private, and there is no compulsion for implementers to contribute such extensions to the Jabber community. It is only when an implementer seeks to have an extension standardized through the JSF's public standards process that ownership over such an extension must be transferred to the JSF. If an implementer wishes to keep its extensions private, it may simply refrain from submitting them to the JSF. However, private extensions exist outside the boundaries of XMPP and approved XMPP Extensions and must not be considered or described as part of XMPP or JSF-approved XMPP Extensions.
+

5. Legal Notice

All XMPP Extension Protocol (XEP) specifications shall contain the following Legal Notice:

+This XMPP Extension Protocol is copyright 1999 - [year] 
+by the Jabber Software Foundation (JSF) and is in full
+conformance with the JSF's Intellectual Property Rights 
+Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). 
+This material may be distributed only subject to the terms and
+conditions set forth in the Creative Commons Attribution
+License (<http://creativecommons.org/by/2.5/>).
+

Notes

1. For information about XMPP Extension Protocols, see <http://www.xmpp.org/extensions/> and JEP-0001.

2. For information about intellectual property conservancies, see <http://www.creativecommons.org/concepts/#ip> and M. van Houweling, "Cultivating Open Information Platforms: A Land Trust Model." Journal of Telecommunications & High Technology Law 1, no. 1 (2002): 309-23.

Acknowledgements

Many thanks to Lawrence Lessig and Molly van Houweling for their assistance in formulating this policy.

Changelog

Version 1.2 (2006-10-04): Modified terminology to reflect protocol branding change from Jabber to XMPP (e.g., Jabber Enhancement Proposal to XMPP Extension Protocol).

Version 1.1 (2005-10-04): Replaced Open Publication License with Creative Commons Attribution License.

Version 1.0 (2002-10-29): Initial version approved by JSF Board of Directors.

+ + + + + + + <xsl:value-of select='/jep/header/shortname'/> + + + + alternate + http://www.jabber.org/jeps/jep-

.html

+ + + + DC.Title +

+ + + DC.Publisher + Jabber Software Foundation + + + DC.Date +

+ + + + +

This page provides information about the XML namespaces defined in + + + http://www.jabber.org/jeps/jep- + + .html + + JEP-: + + (part of the JEP series published by the Jabber Software Foundation).

+ + + +

The following XML schemas are available for the protocol:

+ + +

Last Updated:

+ + + + + + + + + + +

+ + +

+ + + + +

+ + + + + + XEP-

+ + <xsl:value-of select='/xep/header/title' /> + + + + + + + +

+ + + January + + + February + + + March + + + April + + + May + + + June + + + July + + + August + + + September + + + October + + + November + + + December + + + + + +

+ + + + JSF XEP +

+ + + HTML + http://www.xmpp.org/extensions/xep-

.html

+ + + + + + + + + A. + B. + C. + D. + E. + F. + G. + H. + I. + J. + K. + L. + M. + N. + O. + P. + Q. + R. + S. + T. + U. + V. + W. + X. + Y. + Z. + + + + +

+ +

+ + + +

How to Submit an XMPP Extension Protocol

Here is how to submit a proposal to the Jabber Software Foundation for consideration as an XMPP Extension Protocol:

Contact the XMPP Extensions Editor so that he knows to expect your submission.
Write your proposal following the guidelines described in XEP-0143: Guidelines for Authors of XMPP Extension Protocols.
Make sure you read, understand, and agree to the JSF's IPR Policy before you submit your proposal!
Email the XML file (or a URL for the file) to the XMPP Extensions Editor with a subject line of "ProtoJEP: [your title here]".

Note: It is the author's responsibility to provide a properly-formatted source file (see the template and CVS repository). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting.

+ Jabber Enhancement Proposals (JEPs) + This document defines the standards process followed by the Jabber Software Foundation. + &LEGALNOTICE; + 0001 + Active + Procedural + None + Board + + + + N/A + &stpeter; + + 1.16 + 2006-06-23 + psa +

Clarified and simplified the state charts based on implementation experience; summarized state definitions.

+ + + 1.15 + 2004-11-02 + psa +

Specified that a Standards Track JEP defines either (1) a wire protocol or (2) a protocol suite.

+ + + 1.14 + 2004-09-28 + psa +

Defined Procedural JEP type as the union of JIG Formation JEPs and certain Informational JEPs in order to clarify the JEP categories; added Modifications to Approved JEPs section in order to make explicit existing Council practices regarding Active and Final JEPs; specified that JEPs on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on JEPs for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.

+ + + 1.13 + 2004-08-24 + psa +

Further specified the goals of the JEP process; mentioned Board-approved JEPs.

+ + + 1.11 + 2004-07-14 + psa +

Specified the procedure for changing a JEP from Historical to Standards Track.

+ + + 1.10 + 2004-03-24 + psa +

Specified the procedure for acceptance of a proposal as a JEP; clarified the JEP types; completed editorial review.

+ + + 1.9 + 2003-12-22 + psa +

Added rule about automatic deferral of inactive JEPs.

+ + + 1.8 + 2003-10-06 + psa +

Clarified the definition of informational JEP.

+ + + 1.7 + 2003-04-11 + psa +

Added status of Retracted; corrected several errors related to the Jabber Registrar.

+ + + 1.6 + 2003-01-08 + psa +

Further clarified the proposal process per discussion on the JSF members list.

+ + + 1.5 + 2002-10-29 + psa +

Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a JEP (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and Jabber Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.

+ + + 1.4 + 2002-01-16 + psa +

Added information about the new "Experimental" state for Standards Track JEPs and made appropriate changes to the JEP process.

+ + + 1.3.1 + 2002-01-11 + psa +

Added link to DTD.

+ + + 1.3 + 2001-10-23 + psa +

(1) Added information about the "cooling off" period before a Standards Track JEP may be advanced from Draft to Final; (2) Added a link to the JEP template file; (3) Performed several minor fixes.

+ + + 1.2 + 2001-09-27 + psa +

(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track JEPs.

+ + + 1.1 + 2001-09-09 + psa +

(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal JEP" to "JIG Formation JEP"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of JEP Editor; (4) Clarified the possible states of acceptance of each kind of JEP and described in greater detail the criteria for advancement from one state to another.

+ + + 1.0 + 2001-07-09 + psa +

Changed status to Active.

+ + + 0.1 + 2001-06-28 + psa +

Initial release -- a simplified and updated version of Rahul Dave's Jabberization of the process and format for Python Enhancement Proposals

+ +

The &JSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, Effectively the only such exceptions are protocols that were superseded by RFC 3920 and RFC 3921. such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. Advancement through the JSF's standards process is subject to open discussion on public discussion lists and approval by a technical steering committee elected by the members of the JSF. The focal point of the process is a series of protocol specifications called Jabber Enhancement Proposals or JEPs. The JEP concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see PEP-1). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with the JEP process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. The nature of JEPs and the mechanisms for managing and advancing them within the Jabber Software Foundation's standards process are canonically described in the current document, which represents the first document in the JEP series.

+ + +

The Jabber Software Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber/XMPP developer community. The work of the Jabber Software Foundation has several objectives:

To produce practical, technically excellent solutions to important problems of real-time communication based on the set of streaming XML technologies known as Jabber/XMPP.
To document Jabber protocols and XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.
To ensure interoperability among the disparate technologies used on Jabber/XMPP networks.
To guarantee that any person or entity may implement the protocols without encumbrance.
To work in an fair, open, objective manner.

The standards process specified herein has been developed and refined in order to meet these objectives.

+ + +

The five JEP types are described in the following sections.

The approving body for all Standards Track, Informational, Historical, and Humorous JEPs is the &COUNCIL;; the approving body for Procedural JEPs may be either the &BOARD; or the Jabber Council.

This document focuses primarily on Standards Track JEPs since they are the vehicle for defining new protocols, but also discusses the other JEP types.

+ +

A Standards Track JEP defines one of the following:

A wire protocol intended to be used as a standard part of Jabber/XMPP technologies. + Note well that a protocol defined in a Standards Track JEP is not considered a full standard of the Jabber Software Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track JEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track JEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress). +
A protocol suite that determines conformance requirements (e.g., &jep0073;).

+ + +

An Informational JEP defines one of the following:

Best practices for protocol development (e.g., &jep0128;).
A usage profile for an existing protocol (e.g., &jep0126;).

+ + +

An Historical JEP documents a protocol that was developed before the JEP process was instituted, but that is still in use within the Jabber/XMPP developer community; such a JEP may or may not be obsoleted by a Standards Track JEP, or upgraded to Standards Track.

+ + +

A Humorous JEP attempts to be funny by defining a protocol that would never be used in the real world; such JEPs are usually published on April 1 and automatically have a status of Active.

+ + +

A Procedural JEP defines a process or activity to be followed by the JSF, including JIG charters as specified by &jep0002;.

+ + + +

The JSF welcomes and encourages the submission of protocols to the JSF's standards process. It is important to understand that private extensions to XMPP are also allowed. The JSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the JSF. The processes and procedures in this document apply only to protocols that are submitted to the JSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the JSF. Any individual or group of individuals may author a proposal and submit it to the JSF for consideration as a JEP, and there is no requirement that a JEP author shall be an elected member of the JSF. However, proposals to define official JSF protocols must be presented in the JEP format and must follow the rules defined herein. The JEP authoring and submission process is defined in &jep0143; (see also <http://www.jabber.org/jeps/submit.shtml>). All inquiries related to the JEP process, and all submissions, should be directed to the &EDITOR;.

Note well that JEP authors must transfer ownership of their protocols (but not implementations thereof) to the JSF. Refer to the &JSFIPR; for details. JEP authors must make sure that they have read, understood, and agreed to the JSF IPR Policy before submitting a proposal to the JEP Editor!

All proposals submitted to the JSF for consideration as JEPs must contain the following information:

Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy
Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors

Finally, Standards Track, Informational, and Historical JEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.

+ + +

The approving body for almost all JEPs is the Jabber Council; therefore, in order to be published as a JEP, a proposal must first be accepted by the Jabber Council (the only exceptions are certain kinds of Procedural JEPs, for which the approving body may be the JSF Board of Directors and which may be accepted for publication by the JEP Editor in consultation with the Board). Upon receiving a proposal, the JEP Editor shall do the following:

ensure that its format is correct
publish it to <http://www.jabber.org/jeps/inbox/>
publicly announce its existence by sending a message to the discussion list of the &SJIG;
request acceptance of the proposal as a JEP by the Jabber Council

If no member of the Jabber Council objects to publication of the proposal within seven (7) days or at the next meeting of the Council, the JEP Editor shall accept it as a JEP. If objections are raised by the Council on the Standards-JIG list or in its meeting, the JEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the JEP Editor or objecting Council member(s) regarding how to proceed.

If the proposal is accepted as a JEP, the JEP Editor shall do the following:

assign it a number
specify an appropriate type
specify a status of Experimental
add it to source control JEPs are kept under source control in the 'jeps' module of the CVS repository maintained at the jabberstudio.org service. Instructions for accessing these files can be found at <http://www.jabberstudio.org/cvs.php>, and a web interface to these files is available at <http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jeps/>.
add tracking information to the JEPs database
publish version 0.1 of the JEP to the JSF website The canonical URL for accessing JEPs is <http://www.jabber.org/jeps/>.
publicly announce the existence of the JEP by sending a message to the Standards-JIG list

Note well that no special criteria (other than acceptance by the Jabber Council and minimal formatting compliance) need to be met in order for a JEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the JSF, the Jabber Council, or the Jabber/XMPP developer community. Implementation of Experimental JEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations may not be appropriate for deployment in production systems.

+ + +

Once a JEP is published, it becomes available for public discussion within the Standards JIG and the broader Jabber/XMPP developer community. The JEP author is responsible for collecting feedback from the Jabber/XMPP developer community during the life of the JEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the JEP author should be subscribed to the Standards-JIG list, which is the primary venue for discussion of JEPs. Changes made based on feedback received by the JEP author must be captured in updated versions of the JEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the JEP Editor.

If an Experimental JEP is inactive (i.e., no updated versions are published) for a period of six (6) months, the JEP Editor shall automatically change the status of the JEP to Deferred unless it is in the queue of JEPs under active consideration for advancement by the Jabber Council; upon submission of an updated version, the JEP Editor shall change the status back to Experimental.

+ + +

Before an Experimental JEP may be proposed to the Jabber Council for advancement to Draft (Standards Track JEPs) or Active (Historical, Informational, and Procedural JEPs), the Jabber Council must agree that the JEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the JEP Editor to (1) change the status of the JEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards JIG list. The Last Call shall expire not less than 10 days after the date of issue.

Once the consensus of the Standards JIG has been incorporated into the JEP and all issues of substance raised during the Last Call have been addressed by the JEP author, the JEP Editor shall formally propose a specific revision of the JEP to the Jabber Council for its vote. If necessary, the JEP Editor may, at his discretion and in consultation with the Jabber Council, extend the Last Call or issue a new Last Call if the JEP requires further discussion.

Last Calls regarding Procedural JEPs for which the approving body is the JSF Board of Directors may be issued directly by the JEP Editor once instructed by the Board.

+ + +

After a JEP has been proposed to the Jabber Council, any change in its status shall be determined by a vote of the Jabber Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A JEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the JEP to advance. A majority of Council members must vote +1 in order for a JEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the Jabber Council.) A vote of the Jabber Council is final and binding, although a JEP author is free to address the concerns of the Council and to resubmit the JEP for future consideration.

If the Jabber Council does not complete voting on a JEP before the end of its term, the JEP Editor shall issue a new Last Call on the Standards JIG list and the newly-elected Council shall vote anew on the JEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the JEP.

A vote of the Jabber Council applies only to the specific revision of the JEP that has been presented to it. Further revisions may need to be re-submitted for approval.

Any change in the status of a JEP must be announced on the Standards-JIG list by the JEP Editor. If a JEP advances to a status of Final, it shall be so announced and also published as one of the official JSF protocols A list of official JSF protocols is maintained at <http://www.jabber.org/protocol>. on the website of the Jabber Software Foundation.

Approval of Procedural JEPs for which the approving body is the JSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the &BYLAWS;.

More detailed information about the approval process is provided below, including criteria for Standards Track JEPs and for Historical, Informational, and Procedural JEPs.

+ +

The possible states for a Standards Track JEP are as follows:


+
+     +--> Retracted
+     |
+     |
+     +--> Deferred    +--> Rejected
+     |                |
+     |                |
+Experimental ----> Proposed ----> Draft ----> Final
+                                    |           |
+                                    |           |
+                                    +-----------+---> Deprecated ---> Obsolete
+

The ideal path is for a Standards Track JEP is to be advanced by the Jabber Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental JEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track JEP may be voted to a status of Rejected if the Jabber Council deems it unacceptable. (Note that if a JEP is Deferred, the JEP Editor may at some point re-assign it to Experimental status, and that, even if a JEP is Rejected, it is retained in source control and on the Jabber Software Foundation website for future reference.) Finally, a JEP author may voluntarily remove an Experimental JEP from further consideration, resulting in a status of Retracted.

In order for a Standards Track JEP to advance from Proposed to Draft, it must:

fill known gaps in Jabber/XMPP technologies or deficiencies with existing protocols
be clearly described and accurately documented so that it can be understood and implemented by interested and knowledgeable members of the Jabber/XMPP developer community
document any known security considerations with the proposed technology
be generally stable and appropriate for further field experience
have achieved rough consensus (though not necessarily unanimity) within the Standards JIG
be formally defined by an XML schema
receive the requisite votes from the Jabber Council

Elevation to Draft status (version 1.0) is a major advancement for the JEP, indicating a strong sense on the part of the Jabber Council and Jabber/XMPP developer community that the specification will be of lasting value. Since a Draft standard must be well-understood and must be known to be reasonably stable, it is relatively safe to use it as the basis for implementations and production deployments. However, note that because a Draft standard may still require additional field experience and may be subject to change based on such experience, mission-critical or large-scale implementations of the Draft standard may not be advisable (although every effort shall be made to ensure that any changes to a Draft JEP will be backwards-compatible with the 1.0 version). Note also that any changes to a Draft JEP must be provisionally published at <http://www.jabber.org/jeps/tmp/>, announced on the Standards-JIG mailing list, and formally approved by the Jabber Council before being officially published at the canonical URL for the JEP.

In order for a JEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. Before presenting a Draft standard to the Jabber Council for consideration as a Final standard, the JEP Editor shall issue a Call for Experience on the Standards-JIG list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the JEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track JEP shall retain a status of Draft. Once (1) two implementations have been presented to the Jabber Council, (2) feedback provided during the Call for Experience has been incorporated into the JEP, and (3) the JEP has been fully checked for accuracy, the status of the JEP may be changed to Final upon a vote of the Council.

Finally, a Standards Track JEP that has been granted a status of Final may be superseded by a future JEP approved by the Jabber Council. In such cases, the status of the earlier JEP shall be changed to Deprecated, possibly with an expiration date assigned by the Jabber Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the JEP shall be changed to Obsolete.

+ + +

The possible states for a Historical, Informational, or Procedural JEP are as follows:


+
+     +--> Retracted
+     |
+     |
+     +--> Deferred    +--> Rejected
+     |                |
+     |                |
+Experimental ----> Proposed ----> Active
+                                    |
+                                    |
+                                    +--> Deprecated --> Obsolete
+

Because such JEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the Jabber Council. However, some of these JEPs may be remanded from the Council to the JEP author and/or JEP Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track JEPs, the JEP author may retract such a JEP when it is Experimental, and the Council may reject such a JEP when it is Proposed.

Once approved, Historical, Informational, and Procedural JEPs will have a status of Active. Such a JEP may be replaced by a new JEP on the same or a similar topic, thus rendering the earlier JEP out of date; in such cases, the earlier JEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding JEP.

The Jabber Council may, at its discretion, decide to convert an Historical JEP into a Standards Track JEP if the protocol defined in the JEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical JEP shall be treated in the same way as a Standards Track JEP that has a status of Experimental, beginning with the Proposal Process. If after the Last Call and voting by the Jabber Council the JEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.

+ + + +

The possible states for a JEP are summarized in the following sections.

+ +

A JEP of any type is in the Experimental state after it has been accepted by the Jabber Council and published by the Jabber Software Foundation but before it has advanced within the standards process to a state of Active or Draft.

+ + +

A JEP of any type is in the Proposed state while it is in Last Call or under consideration by the Jabber Council for advancement from Experimental to Draft or Active.

+ + +

A Standards Track JEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards-JIG list and has been voted forward on the standards track by the Jabber Council.

+ + +

A Standards Track JEP is in the Final state after it has been in the Draft state for at least 60 days, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the Jabber Council.

+ + +

A JEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the Jabber Council.

+ + +

An Experimental JEP of any type is changed to the Deferred state if it has not been updated in six (6) months.

+ + +

A JEP of any type is in the Retracted state if the authors have asked the JEP Editor to remove the JEP from further consideration in the JSF's standards process.

+ + +

A JEP of any type is in the Rejected state if the Jabber Council has deemed it unacceptable and has voted to not move it forward within the standards process.

+ + +

A JEP of any type is in the Deprecated state if the Jabber Council has determined that the protocol defined therein is out of date and that new implementations are no longer encouraged (e.g., because it has been superseded by a more modern protocol).

+ + +

A JEP of any type is changed from Deprecated to Obsolete if the Jabber Council has determined that the protocol defined therein should no longer be implemented or deployed.

+ + + +

Sometimes it is necessary to modify JEPs that have received final approval by the Jabber Council or JSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track JEPs that have achieved a status of Final and Historical, Informational, and Procedural JEPs that have achieved a status of Active.

With regard to Standards Track JEPs, the Jabber Software Foundation (in particular, the Jabber Council) strives to ensure that such JEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the JEP). The Call for Experience and discussion within the Standards JIG help to ensure this result, but final responsibility rests with the Jabber Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final JEPs (the individual who discovers such an error should inform the Council via the Standards-JIG mailing list or communicate directly with the JEP Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the JSF makes changes to the Final JEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the JEP Editor or JEP author in consultation with the Jabber Council, discussed within the Standards JIG if appropriate, and agreed upon by the full Jabber Council. Upon agreement regarding the exact changes, the Jabber Council shall instruct the JEP Editor to publish a revised version of the JEP and announce the existence of the revised version through the normal channels (e.g., on the JSF website and to the Standards-JIG list). Naturally, if members of the Jabber/XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards-JIG list) before or after the revised version has been published.

The process is similar with regard to Historical and Informational JEPs that have achieved a status of Active (corresponding to document version 1.0 of the JEP): the Jabber Council agrees on the exact changes to be made and instructs the JEP Editor to publish and announce a revised version (e.g., version 1.1). Here again the Jabber Council bears responsibility for any changes and public discussion is welcome.

Procedural JEPs may be modified more frequently as the Jabber Software Foundation gains experience with the processes defined therein. For example, JEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the JEP process; similar changes are sometimes made to the &jep0053; JEP and to various JIG-related JEPs. Changes to these JEPs are discussed by the Jabber Council, JSF Board of Directors, JSF membership, and Standards JIG as appropriate, and exact changes are agreed to by the relevant approving body (Jabber Council or JSF Board of Directors). The approving body then instructs the JEP Editor to publish and announce the revised version as described above.

+ + +

In rare cases, a protocol enhancement may be accepted as an interim solution, especially when it is recognized that expected future improvements in technology or the underlying Jabber/XMPP protocols will make possible a much better solution to the problem at hand (e.g., a better protocol for user avatars may be contingent upon the development of a robust protocol for publish/subscribe functionality). In such cases, a JEP may be approved provisionally and be assigned an expiration date.

The exact form of such an expiration date shall be left up to the discretion of the Jabber Council. However, the preferred form is to assign an expiration date of six (6) months in the future, at which time the Jabber Council must re-affirm the status of the JEP and, if desired, extend the expiration date for another six (6) months. While this process may continue indefinitely (although that is unlikely), it has the virtue of forcing the Jabber Council and Jabber/XMPP developer community to re-examine the provisional protocol on a fairly regular basis in the light of technological changes. Alternatively, a JEP may be assigned a "soft" expiration date: that is, the JEP will expire when an expected future protocol comes into existence, whenever that may be. In either case, the status of the JEP shall be changed to Deprecated when it expires.

In addition, an expiration date may be assigned when the status of a JEP is changed from Final (or, potentially, Draft) to Deprecated. In this case, the expiration date applies to the date when the JEP is expected to change from Deprecated to Obsolete. These dates may be flexible; however it is expected that they will follow the same six-month rule as provisional protocol enhancements.

+ + +

Every JEP must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track JEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol. JEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the JEP Editor and/or Jabber Council regarding this important task.

+ + +

Some JEPs may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222 and 5269 used by the Jabber/XMPP developer community are registered with the IANA). Whether or not a JEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the JEP entitled "IANA Considerations". Registration with the IANA should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs), and should be initiated by the Jabber Registrar in consultation with the JEP author, not by the JEP author directly with the IANA.

+ + +

The ®ISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &jep0030;).

Whether or not a JEP requires registration of protocol namespaces or parameters with the Jabber Registrar, that fact must be noted and explained in a distinct section of the JEP entitled "Jabber Registrar Considerations". Such registration should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs). Registration of protocol namespaces is initiated by the JEP Editor when a JEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a JEP author within the text of the JEP, or by an implementor of the JEP after it has advanced to Draft or Active. For details regarding the Jabber Registrar and its processes, refer to &jep0053;.

A JEP may also request that a new registry is to be created by the Jabber Registrar. The JEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and must do so in collaboration with the Registrar.

+ + +

JEPs that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.

The schema for the JEP format itself is as follows:


+
+
+
+  
+    
+      
+
+        This schema defines the document format for Jabber Enhancement 
+        Proposals (JEPs). For further information about JEPs, visit:
+
+           http://www.jabber.org/jeps/ 
+        
+        The canonical URL for this schema is:
+        
+           http://www.jabber.org/jeps/jep.xsd
+
+      
+    
+    
+      
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+         
+        
+        
+        
+        
+        
+        
+         
+         
+        
+         
+         
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+        
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+        
+      
+      
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+        
+      
+      
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+        
+      
+      
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+      
+      
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+      
+      
+      
+    
+  
+
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+      
+      
+    
+  
+
+  
+
+  
+    
+      
+        
+           
+        
+      
+    
+  
+
+  
+    
+      
+        
+           
+        
+      
+    
+  
+
+  
+
+  
+    
+      
+        
+           
+        
+      
+    
+  
+
+  
+    
+      
+        
+           
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+      
+    
+  
+
+  
+    
+      
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+           
+           
+        
+      
+    
+  
+
+  
+    
+      
+        
+           
+           
+        
+      
+    
+  
+
+  
+    
+      
+      
+      
+      
+      
+      
+      
+      
+    
+    
+    
+  
+
+  
+    
+      
+    
+  
+
+
+  ]]>

+ +

+ Jabber Interest Groups (JIGs) + A definition of Jabber Interest Groups, including their structure and role within the Jabber Software Foundation. + &LEGALNOTICE; + 0002 + Active + Procedural + None + Board + + + + &stpeter; + + 1.1 + 2002-01-11 + psa + Clarified some details and added information about cut-offs for inactivity. + + + 1.0 + 2001-06-28 + psa + First release, modified from Rahul Dave's modification of my original post. + +

+ +

A Jabber Interest Group (JIG) is a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community, usually by means of developing and publishing Jabber Enhancements Proposals (JEPs).

+ + +

The main function of most JIGs is to produce acceptable enhancements to the Jabber protocol (delivered in the form of Jabber Enhancement Proposals or JEPs For information about Jabber Enhancement Proposals, see http://foundation.jabber.org/jeps/jep-0001.html.) within a reasonably limited period of time. However, at the discretion of the Jabber Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).

Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a Jabber Enhancement Proposal outlining the need for the JIG and its proposed focus. However, JIG leaders must be members of the Jabber Software Foundation. The number of leaders for a JIG is flexible, and shall be determined by each JIG, in consultation with the Jabber Council if necessary. The concept of "membership" with regard to JIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each JIG has its own mailing list, which is archived for public review). JIG members do not need to be members of the Jabber Software Foundation, and any member of the general public may subscribe to JIG mailing lists.

It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track JEPs for review by the Jabber Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the Jabber Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).

+ +

+ Proxy Accept Socket Service (PASS) + A proposal for proxy support in Jabber. + &LEGALNOTICE; + 0003 + Active + Historical + Standards JIG + + XMPP Core + + + + pass + + http://jabber.org/protocol/pass/pass.xsd + + &jer; + &reatmon; + + 1.2 + 2004-01-22 + psa + Editorial revisions. + + + 1.1 + 2004-01-06 + psa + Added XML schema. + + + 1.0 + 2002-10-15 + psa + Changed status to Active. + + + 0.4 + 2001-07-02 + rwe + Error codes update + + + 0.3 + 2001-06-29 + rwe + Protocol update + + + 0.2 + 2001-06-28 + psa + DocBook version + + + 0.1 + 2001-06-01 + jer + Initial release + +

+ +

Complete direct client-to-client file transfers presents a major problem for clients that are behind a firewall or NAT. Proxy Accept Socket Service (PASS) enables clients to do real-time file transfers via a third party; in addition, it does not limit clients to file transfers but enables any two clients to create a raw TCP socket between them for any purpose, such as VoIP (SIP/RTP), BEEP, or binary game data.

+ + +

The first step is to communicate with a PASS service to set it up.

+ +<iq id='pass1' type='set' to='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <expire>600</expire> + </query> +</iq> + + +<iq id='pass1' type='result' from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <server port='43253'>1.2.3.4</server> + </query> +</iq> + +

At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.

The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an <expire/> value (in seconds). If the service is not configured with an expire value, it will not timeout the connection, and will start listening on the port again after one of the two sides disconnects.

+ + + + + + + + + + + +

Code	Message	Cause
502	No more ports available. Try again later.	The PASS service is listening on all of its available ports.

+ + +

When an incoming connection is attempted to that IP and port, the PASS service MUST send an IQ request to the entity on whose behalf it is listening:

+ +<iq type='set' + id='pass2' + to='user@jabber.org/resource' + from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <client port='1234'>4.3.2.1</client> + <proxy port='43523'>1.2.3.4</proxy> + </query> +</iq> + + +<iq type='result' + id='pass2' + from='user@jabber.org/resource' + to='pass.jabber.org'> + <query xmlns='jabber:iq:pass'/> +</iq> + +

The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.

Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.

+ + +

A Jabber client can send various controls to the PASS service via the set to control how the PASS service behaves, how the server handles a listening port.

+ +

This tells the server to shut down the port after a specified number of seconds. After the timeout period, the PASS service MUST send an <iq/> to the JID to tell it that the port has been closed down. It notifies the client with:

+ +<iq type='set' + id='pass3' + to='user@jabber.org/resource' + from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <expire/> + <close/> + <proxy port='43253'>1.2.3.4</proxy> + </query> +</iq> + + +<iq type='result' + id='pass3' + from='user@jabber.org/resource' + to='pass.jabber.org'> + <query xmlns='jabber:iq:pass'/> +</iq> + + + +

This tells the server to listen once, and then close the port. Even if the <expire/> has not been met, the <oneshot/> overrides that and shuts down the listening port. When this happens the server notifies the client with the following packet:

+ +<iq type='set' + id='pass4' + to='user@jabber.org/resource' + from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <oneshot/> + <close/> + <proxy port='43253'>1.2.3.4</proxy> + </query> +</iq> + + +<iq type='result' + id='pass4' + from='user@jabber.org/resource' + to='pass.jabber.org'> + <query xmlns='jabber:iq:pass'/> +</iq> + + + +

This tells the server to explicitly shut down a listening port. Useful for when the client shuts down and can tell the PASS service to recycle the port. The server sends back:

+ +<iq type='set' + id='pass5' + to='pass.jabber.org' + from='user@jabber.org/resource'> + <query xmlns='jabber:iq:pass'> + <close/> + <proxy port='43253'>1.2.3.4</proxy> + </query> +</iq> + + +<iq type='result' + id='pass5' + to='user@jabber.org/resource' + from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'/> +</iq> + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Code	Message	Cause
400	Missing <proxy/> specification.	Sent a <close/> w/o a <proxy/>
401	Port not registered to your JID.	You did not register this port with the server.
404	Port not found in registry.	The <proxy port=''/> was not a defined port.
405	Proxy IP does not match.	The IP sent in the <proxy/> does not match the IP of the pass-service

+ + + + +

The PASS protocol can be used for clients to talk to each other and find out information about each other. When a client wants to send a file to another client, it can use the jabber:iq:pass namespace to query the IP address of the other client. For example:

You send the other client:

+ +<iq type='get' + id='pass6' + to='them@jabber.org/resource' + from='you@jabber.org/resource'> + <query xmlns='jabber:iq:pass'/> +</iq> + +

The other client SHOULD send back:

+ +<iq type='result' + id='pass6' + to='you@jabber.org/resource' + from='them@jabber.org/resource'> + <query xmlns='jabber:iq:pass'> + <client>4.3.2.1</client> + <query> +</iq> + +

Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the <client/> information upon a connection.

+ + +

When a server gets an Incoming Connection notification the client has the right to deny that connection based on the <client/> information that it receives. It can return an error to the PASS service specifying the <proxy/> port and hangup on the active <client/> connection and start listening again. This does not affect the <oneshot/> control. For example:

The PASS service sends you:

+ +<iq type='set' + id='pass7' + to='user@jabber.org/resource' + from='pass.jabber.org'> + <query xmlns='jabber:iq:pass'> + <client port='1234'>4.3.2.1</client> + <proxy port='43523'>1.2.3.4</proxy> + <query> +</iq> + +

Your client would send back:

+ +<iq type='error' + id='pass7' + to='pass.jabber.org' + from='user@jabber.org/resource'> + <query xmlns='jabber:iq:pass'> + <client port='1234'>4.3.2.1</client> + <proxy port='43523'>1.2.3.4</proxy> + <query> + <error code='401' type='auth'> + <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + </error> +</iq> + + + + + + + + + + + + +

Code	Message	Cause
401	Unauthorized	The incoming <client/> does not match the <client/> from the client you want to exchange data with.

+ + + +

This JEP requires no interaction with &IANA;.

+ + +

No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:pass' is already a registered protocol namespace.

+ + +


+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0003: http://www.jabber.org/jeps/jep-0003.html
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+    ]]>

+ +

+ Data Forms + This JEP defines a protocol for data forms and generic data description in Jabber/XMPP. + &LEGALNOTICE; + 0004 + Final + Standards Track + Standards JIG + + XMPP Core + + + + x-data + + http://jabber.org/protocol/x-data/x-data.xsd + + &reatmon; + &hildjj; + &jer; + &temas; + &stpeter; + + 2.7 + 2006-01-25 + psa + Incorporated errata: (1) clarified rules regarding inclusion of option and value elements depending on field type; (2) clarified handling of default values; (3) added value elements to list-multi field in Example 2; (4) harmonized spelling of form-processing entity and form-submitting entity. + + + 2.6 + 2004-10-13 + psa + Incorporated errata: (1) corrected syntax of <reported/> element (<field/> element should not contain a <value/> child); (2) corrected Example 8. + + + 2.5 + 2004-05-07 + psa + Clarified terminology regarding form-processing entities and form-submitting entities; corrected several small errors in the schema. + + + 2.4 + 2004-05-04 + psa + Per discussion by the JEP authors and Jabber Council, specified that the 'var' attribute is required for all field types except "fixed", for which the 'var' attribute is optional. + + + 2.3 + 2004-03-31 + psa + Formalization and further editorial revisions. + + + 2.2 + 2004-01-22 + psa + Editorial revisions. + + + 2.1 + 2003-02-16 + psa + Added schema. + + + 2.0 + 2002-12-09 + psa + Per a vote of the Jabber Council, changed status to Final. + + + 1.1 + 2002-10-15 + rwe + Call for Experience changes (see Changes Between Draft and Final section). This version voted to Final on 2002-12-09. + + + 1.0 + 2002-04-24 + psa + Per a vote of the Jabber Council, changed status to Draft. + + + 0.6 + 2002-03-15 + rwe + Protocol tweaks based on standards-jig discussion. + + + 0.5 + 2002-02-06 + rwe + Protocol tweaks based on implementation and discussion. + + + 0.4 + 2001-11-16 + rwe + Major redesign to attempt to clarify the scope of this JEP and limit what it is trying to solve. + + + 0.3 + 2001-07-23 + rwe + Protocol update + + + 0.2 + 2001-06-29 + rwe + Protocol update and DocBook version + + + 0.1 + 2001-01-25 + rwe + Initial release + +

+ +

Several existing Jabber/XMPP protocols involve the exchange of structured data between users and applications for common tasks such as registration (&jep0077;) and searching (&jep0055;). Unfortunately, these early protocols were "hard coded" and thus place significant restrictions on the range of information that can be exchanged. Furthermore, other protocols (e.g., &jep0045;) may need to exchange data for purposes such as configuration, but the configuration options may differ depending on the specific implementation or deployment. Finally, developers may want to extend other protocols (e.g., &jep0030;) in a flexible manner in order to provide information that is not defined in the base protocol. In all of these cases, it would be helpful to use a generic data description format that can be used for dynamic forms generation and data "modelling" in a variety of circumstances.

An example may be helpful. Let us imagine that when a user creates a multi-user chatroom on a text conferencing service, the service allows the user to configure the room in various ways. While most implementations will probably provide a somewhat common set of configurable features (discussion logging, maximum number of room occupants, etc.), there will be some divergence: perhaps one implementation will enable archiving of the room log in a variety of file types (XML, HTML, PDF, etc.) and for a variety of time periods (hourly, daily, weekly, etc.), whereas another implementation may present a boolean on/off choice of logging in only one format (e.g., daily logs saved in HTML). Obviously, the first implementation will have more configuration options than the second implementation. Rather than "hard-coding" every option via distinct XML elements (e.g., <room_logging_period/>), a better design would involve a more flexible format.

The 'jabber:x:data' protocol described herein defines such a flexible format for use by Jabber/XMPP entities, steering a middle course between the simplicity of "name-value" pairs and the complexity of &w3xforms; (on which development had just begun when this protocol was designed). In many ways, 'jabber:x:data' is similar to the Forms Module of &w3xhtml;; however, it provides several Jabber-specific data types, enables applications to require data fields, integrates more naturally into the "workflow" semantics of IQ stanzas, and can be included as an extension of existing Jabber/XMPP protocols in ways that the XHTML Forms Module could not when this protocol was developed (especially because &w3xhtmlmod; did not exist at that time).

+ + +

This JEP addresses the following requirements:

Data Gathering -- the protocol should enable a form-processing entity (commonly a server, service, or bot) to gather data from a form-submitting entity (commonly a client controlled by a human user); this should be done via distinct data fields (e.g., items in a questionnaire or configuration form), each of which can be a different data "type" and enable free-form input or a choice between multiple options (as is familiar from HTML forms).
Data Reporting -- the protocol should enable a form-processing entity to report data (e.g., search results) to a form-submitting entity, again via distinct data fields.
Portability -- the protocol should as much as possible define generic data formats and basic datatypes only; hints may be provided regarding the user interface, but they should be hints only and not hard-and-fast requirements.
Simplicity -- the protocol should be simple for clients to implement, and most of the complexity (e.g., data validation and processing) should be the responsibility of servers and components rather than clients.
Flexibility -- the protocol should be flexible and extensible rather than "hard-coded".
Compatibility -- the protocol should define an extension to existing Jabber/XMPP protocols and not break existing implementations unless absolutely necessary.

+ + +

The base syntax for the 'jabber:x:data' namespace is as follows (a formal description can be found in the XML Schema section below):


+  
+  <instructions/>
+  <field var='field-name'
+         type='{field-type}'
+         label='description'>
+    <desc/>
+    <required/>
+    <value>field-value</value>
+    <option label='option-label'><value>option-value</value></option>
+    <option label='option-label'><value>option-value</value></option>
+  </field>
+</x>
+  ]]></code>
+  <p>The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included as a first-level child of an XML stanza; the stanza MAY be of any kind (&IQ;, &MESSAGE;, or &PRESENCE;), although it is RECOMMENDED to use &IQ; or &MESSAGE; (see also the restrictions enumerated below).</p>
+  <p>The OPTIONAL <title/> and <instructions/> elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the <instructions/> element MAY be included.</p>
+  <section2 topic='Form Types' anchor='protocol-formtypes'>
+    <p>The data gathered or provided in a 'jabber:x:data' form can be situated in a number of different contexts. Examples include an empty form that needs to be filled out, a completed form, the results of a submission, a search result, or simply a set of data that is encapsulated using the 'jabber:x:data' namespace. The full context for the data is provided by three things:</p>
+    <ol>
+      <li>the "wrapper" protocol (i.e., the namespace whose root element is the direct child of the &IQ; stanza and the parent of the &X; element qualified by the 'jabber:x:data' namespace)</li>
+      <li>the place of the form within a transaction (e.g., an IQ "set" or "result") or structured conversation (e.g., a message <thread/>)</li>
+      <li>the 'type' attribute on the form's root &X; element</li>
+    </ol>
+    <p>The first two pieces of contextual information are provided by other protocols, whereas the form types are described in the following table.</p>
+    <table caption='Form Types'>
+      <tr>
+        <th>Type</th>
+        <th>Description</th>
+      </tr>
+      <tr>
+        <td>form</td>
+        <td>The form-processing entity is asking the form-submitting entity to complete a form.</td>
+      </tr>
+      <tr>
+        <td>submit</td>
+        <td>The form-submitting entity is submitting data to the form-processing entity.</td>
+      </tr>
+      <tr>
+        <td>cancel</td>
+        <td>The form-submitting entity has cancelled submission of data to the form-processing entity.</td>
+      </tr>
+      <tr>
+        <td>result</td>
+        <td>The form-processing entity is returning data (e.g., search results) to the form-submitting entity, or the data is a generic data set.</td>
+      </tr>
+    </table>
+    <p>In order to maintain the context of the data as captured in the form type, the following rules MUST be observed:</p>
+    <ul>
+      <li><p>For &IQ; stanzas, the root element qualified by the "wrapper" namespace in a form of type "form" or "submit" MUST be returned in a form of type "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the "wrapper" namespace's root element. As defined in &xmppcore;, the 'id' attribute MUST be copied in the IQ result. For data forms of type "form" or "result", the &IQ; stanza SHOULD be of type "result".  For data forms of type "submit" or "cancel", the &IQ; stanza SHOULD be of type "set".</p></li>
+      <li><p>For &MESSAGE; stanzas, the <thread/> SHOULD be copied in the reply if provided. The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &MESSAGE; stanza.</p></li>
+      <li><p>The only data form type allowed for <presence/> stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with <strong>XMPP Core</strong>, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.</p></li>
+    </ul>
+  </section2>
+  <section2 topic='The Field Element' anchor='protocol-field'>
+    <p>A data form of type "form", "submit", or "result" SHOULD contain at least one <field/> element; a data form of type "cancel" SHOULD NOT contain any <field/> elements.</p>
+    <p>The <field/> element MAY contain any of the following child elements:</p>
+    <ul>
+      <li><p><strong><desc/></strong> -- The XML character data of this element provides a natural-language description of the field, intended for presentation in a user-agent (e.g., as a "tool-tip", help button, or explanatory text provided near the field). The <desc/> element SHOULD NOT contain newlines (the \n and \r characters), since layout is the responsibility of a user agent, and any handling of newlines (e.g., presentation in a user interface) is unspecified herein. (Note: To provide a description of a field, it is RECOMMENDED to use a <desc/> element rather than a separate <field/> element of type "fixed".)</p></li>
+      <li><p><strong><required/></strong> -- This element, which MUST be empty, flags the field as required in order for the form to be considered valid.</p></li>
+      <li><p><strong><value/></strong> -- The XML character data of this element defines the default value for the field (according to the form-processing entity), the data provided by a form-submitting entity, or a data result. In data forms of type "form", if the form-processing entity provides a default value via the <value/> element, then the form-submitting entity SHOULD NOT attempt to enforce a different default value (although it MAY do so to respect user preferences or anticipate expected user input). Fields of type list-multi, jid-multi, text-multi, and hidden MAY contain more than one <value/> element; all other field types MUST NOT contain more than one <value/> element.</p></li>
+      <li><p><strong><option/></strong> -- One of the options in a field of type "list-single" or "list-multi". The XML character of the <value/> child defines the option value, and the 'label' attribute defines a human-readable name for the option. The <option/> element MUST contain one and only one <value/> child. If the field is not of type "list-single" or "list-multi", it MUST NOT contain an <option/> element.</p></li>
+    </ul>
+    <p>If the <field/> element type is anything other than "fixed" (see below), it MUST possess a 'var' attribute that uniquely identifies the field in the context of the form (if it is "fixed", it MAY possess a 'var' attribute). The <field/> element MAY possess a 'label' attribute that defines a human-readable name for the field. For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single"); fields provided in the context of other forms types MAY possess a 'type' attribute as well.</p>
+    <p>If fields are presented in a user interface (e.g., as items in a questionnaire or form result), the order of the field elements in the XML SHOULD determine the order of items presented to the user.</p>
+  </section2>
+  <section2 topic='Field Types' anchor='protocol-fieldtypes'>
+    <p>The following field types represent data "types" that are commonly exchanged between Jabber/XMPP entities. These field types are not intended to be as comprehensive as the datatypes defined in, for example, &w3xmlschema2;, nor do they define user interface elements.</p>
+    <table caption='Field Types'>
+      <tr>
+        <th>Type</th>
+        <th>Description</th>
+      </tr>
+      <tr>
+        <td>boolean</td>
+        <td>The field enables an entity to gather or provide an either-or choice between two options. The default value is "false". &BOOLEANNOTE;</td>
+      </tr>
+      <tr>
+        <td>fixed</td>
+        <td>The field is intended for data description (e.g., human-readable text such as "section" headers) rather than data gathering or provision. The <value/> child SHOULD NOT contain newlines (the \n and \r characters); instead an application SHOULD generate multiple fixed fields, each with one <value/> child.</td>
+      </tr>
+      <tr>
+        <td>hidden</td>
+        <td>The field is not shown to the form-submitting entity, but instead is returned with the form.</td>
+      </tr>
+      <tr>
+        <td>jid-multi *</td>
+        <td>The field enables an entity to gather or provide multiple Jabber IDs.</td>
+      </tr>
+      <tr>
+        <td>jid-single *</td>
+        <td>The field enables an entity to gather or provide a single Jabber ID.</td>
+      </tr>
+      <tr>
+        <td>list-multi</td>
+        <td>The field enables an entity to gather or provide one or more options from among many.</td>
+      </tr>
+      <tr>
+        <td>list-single</td>
+        <td>The field enables an entity to gather or provide one option from among many.</td>
+      </tr>
+      <tr>
+        <td>text-multi **</td>
+        <td>The field enables an entity to gather or provide multiple lines of text.</td>
+      </tr>
+      <tr>
+        <td>text-private</td>
+        <td>The field enables an entity to gather or provide a single line or word of text, which shall be obscured in an interface (e.g., *****).</td>
+      </tr>
+      <tr>
+        <td>text-single</td>
+        <td>The field enables an entity to gather or provide a single line or word of text, which may be shown in an interface. This field type is the default and MUST be assumed if a form-submitting entity receives a field type it does not understand.</td>
+      </tr>
+    </table>
+    <p>* Note: Data provided for fields of type "jid-single" or "jid-multi" MUST contain one or more valid Jabber IDs, where validity is determined by the addressing rules defined in <strong>XMPP Core</strong> (see the <link url='#validation'>Data Validation</link> section below).</p>
+    <p>** Note: Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters). Instead, the application SHOULD split the data into multiple strings (based on the newlines inserted by the platform), then specify each string as the XML character data of a distinct <value/> element. Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.</p>
+  </section2>
+  <section2 topic='Multiple Items in Form Results' anchor='protocol-results'>
+    <p>In some contexts (e.g., the results of a search request), it may be necessary to communicate multiple items. Therefore, a data form of type "result" MAY contain two child elements not described in the basic syntax above: one <reported/> element followed by zero or more <item/> elements. The syntax is as follows:</p>
+    <code><![CDATA[
+<x xmlns='jabber:x:data'
+   type='result'>
+  <reported>
+    <field var='field-name' label='description' type='{field-type}'/>
+  </reported>
+  <item>
+    <field var='field-name'>
+      <value>field-value</value>
+    </field>
+  </item>
+  <item>
+    <field var='field-name'>
+      <value>field-value</value>
+    </field>
+  </item>
+  .
+  .
+  .
+</x>
+    ]]></code>
+    <p>Each of these elements MUST contain one or more <field/> children. The <reported/> element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the <field/> elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a <value/> element. Each <item/> element defines one item in the result set, and MUST contain each field specified in the <reported/> element (although the XML character data of the <value/> element MAY be null).</p>
+  </section2>
+</section1>
+<section1 topic='Data Validation' anchor='validation'>
+  <p>Data validation is the responsibility of the form-processing entity (commonly a server, service, or bot) rather than the form-submitting entity (commonly a client controlled by a human user). This helps to meet the requirement for keeping client implementations simple. If the form-processing entity determines that the data provided is not valid, it SHOULD return a "Not Acceptable" error, optionally providing a textual explanation in the XMPP <text/> element or an application-specific child element that identifies the problem (see &jep0086; for information about mappings and formats).</p>
+</section1>
+<section1 topic='Examples' anchor='examples'>
+  <p>For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at <botster.shakespeare.lit>. This service enables registered users to create and configure new bots, find and interact with existing bots, and so on. We will assume that these interactions occur using the &jep0050; protocol, which is used as a "wrapper" protocol for data forms qualified by the 'jabber:x:data' namespace. The examples in the sections that follow show most of the features of the data forms protocol described above.</p>
+  <p>Note: Additional examples can be found in the specifications for various using protocols, such as <strong>JEP-0045: Multi-User Chat</strong> and <strong>JEP-0055: Jabber Search</strong>.</p>
+  <section2 topic='Configuration' anchor='examples-config'>
+    <p>The first step is for a user to create a new bot on the hosting service. We will assume that this is done by sending a "create" command to the desired bot:</p>
+    <example caption="User Requests Bot Creation"><![CDATA[
+<iq from='romeo@montague.net/home'
+    to='joogle@botster.shakespeare.lit'
+    type='get'
+    xml:lang='en'
+    id='create1'>
+  <command xmlns='http://jabber.org/protocol/commands' 
+           node='create'
+           action='execute'/>
+</iq>
+    ]]></example>
+    <p>The hosting service then returns a data form to the user:</p>
+    <example caption="Service Returns Bot Creation Form"><![CDATA[
+<iq from='joogle@botster.shakespeare.lit'
+    to='romeo@montague.net/home'
+    type='result'
+    xml:lang='en'
+    id='create1'>
+  <command xmlns='http://jabber.org/protocol/commands'
+           node='create'
+           sessionid='create:20040408T0128Z'
+           status='executing'>
+    <x xmlns='jabber:x:data' type='form'>
+      <title>Bot Configuration
+      Fill out this form to configure your new bot!
+      
+        jabber:bot
+      
+      Section 1: Bot Info
+      
+      
+      
+        
+      
+      
+      Section 2: Features
+      
+        
+        
+        
+        
+        
+        news
+        search
+      
+      Section 3: Subscriber List
+      
+        20
+        
+        
+        
+        
+        
+        
+      
+      Section 4: Invitations
+      
+        Tell all your friends about your new bot!
+      
+    
+  
+
+    ]]>
+    The user then submits the configuration form:
+    
+  
+    
+      
+        jabber:bot
+      
+      
+        The Jabber Google Bot
+      
+      
+        This bot enables you to send requests to
+        Google and receive the search results right
+        in your Jabber client. It' really cool!
+        It even supports Google News!
+      
+      
+        0
+      
+      
+        v3r0na
+      
+      
+        news
+        search
+      
+      
+        50
+      
+      
+        juliet@capulet.com
+        benvolio@montague.net
+      
+    
+  
+
+    ]]>
+    The service then returns the results to the user:
+    
+  
+    
+      
+        jabber:bot
+      
+      
+        The Jabber Google Bot
+      
+      
+        0
+      
+      
+        v3r0na
+      
+      
+        news
+        search
+      
+      
+        50
+      
+      
+        juliet@capulet.com
+        benvolio@montague.net
+      
+    
+  
+
+    ]]>
+  
+  
+    Now that the user has created this search bot, let us suppose that one of the friends he has invited decides to try it out by sending a search request:
+    
+  
+
+    ]]>
+    
+  
+    
+      Joogle Search
+      Fill out this form to search for information!
+      
+        
+      
+    
+  
+
+    ]]>
+    
+  
+    
+      
+        verona
+      
+    
+  
+
+    ]]>
+    
+  
+    
+      Joogle Search: verona
+      
+        
+        
+      
+      
+        
+          Comune di Verona - Benvenuti nel sito ufficiale
+        
+        
+          http://www.comune.verona.it/
+        
+      
+      
+        
+          benvenuto!
+        
+        
+          http://www.hellasverona.it/
+        
+      
+      
+        
+          Universita degli Studi di Verona - Home Page
+        
+        
+          http://www.univr.it/
+        
+      
+      
+        
+          Aeroporti del Garda
+        
+        
+          http://www.aeroportoverona.it/
+        
+      
+      
+        
+          Veronafiere - fiera di Verona
+        
+        
+          http://www.veronafiere.it/
+        
+      
+    
+  
+
+    ]]>
+  
+


+
+  There are no security concerns related to this specification above and beyond those described in the relevant section of XMPP Core.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  
+    The ®ISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.
+  
+  
+    The Jabber Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &jep0068;; the registry is located at <http://www.jabber.org/registrar/formtypes.html>.
+  
+
+
+  This schema is descriptive, not normative.
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0004: http://www.jabber.org/jeps/jep-0004.html
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+      
+      
+        
+          
+            
+            
+            
+            
+          
+        
+      
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+      
+      
+      
+        
+          
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+          
+        
+      
+      
+    
+  
+
+  
+    
+      
+        
+      
+      
+    
+  
+
+  
+
+  
+    
+      
+        
+      
+    
+    
+      
+        When contained in a "reported" element, the "field" element
+        SHOULD NOT contain a "value" child.
+      
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+  ]]>
+
+
+  The following protocol changes were incorporated in the Final specification as a result of experience with the Draft specification (described in version 1.0 of this document):
+  
+    The <x/> element MAY be included in <message/> and <presence/> elements.
+    The <x/> element MAY contain a <title/> child for forms and results.
+    The <x/> element MUST possess a 'type' attribute.
+    A <field/> element MAY be of type='jid-single'.
+    Results MAY be reported back in <item/> tags.
+    Results MAY contain a <reported/> element with result set.
+    The <reported/> fields MAY possess a 'type' attribute to provide hints about how to interact with the data (type='jid-single' being the most useful).
+  
+
+


diff --git a/xep-0005.xml b/xep-0005.xml
new file mode 100644
index 00000000..9820bc7b
--- /dev/null
+++ b/xep-0005.xml
@@ -0,0 +1,108 @@
+
+
+%ents;
+]>
+
+
+
+  Jabber Interest Groups
+  This is the official list and summary information of the Jabber Interest Groups.
+  &LEGALNOTICE;
+  0005
+  Obsolete
+  Informational
+  None
+  
+    Jeremie
+    Miller
+    jer@jabber.org
+  
+  
+    1.1
+    2002-05-08
+    psa
+    Changed Status to Obsolete per approval of JEP-0019.
+  
+  
+    1.0
+    2001-07-03
+    jer
+    First Post! ;)
+  
+
+
+
+  
+    Michael Bauer / bauer@jabber.com
+    Julian Missig / julian@jabber.org
+    Terry Smelser / tsmelser@sltscommunications.net
+    DJ Adams / dj.adams@pobox.com
+    Mike Szczerban / mikeszcz@delanet.com
+  
+  Determine standards for implementing derivative trademarks (e.g., "100% Jabber Protocol Compliant") and test software and services for compliance.
+
+
+
+  
+    Ryan Eatmon / reatmon@jabber.org
+    Jer / jer@jabber.org
+    Stephen Lee / srlee@myjabber.org
+    Jim Powell / PowellJF@navair.navy.mil
+    Zad / zadk@mynet.com
+    Michael J. Emswiler / memswiler@hotmail.com
+  
+  Resolve issues around using the jabber:*:oob namespaces, and explore extending them to support additional requirements for managing multimedia streams (SIP).
+Create additional protocols and methods to assist exchanging OOB data in heterogeneous environments where direct connections are not possible (PASS).
+
+
+
+  
+    Thomas Muldowney / temas@jabber.org
+    Al Sutton / al@alsutton.com
+    Rahul Dave / rahul@mozdev.org
+  
+  Focusing on authentication, message encryption, connection security, etc.
+
+
+
+  
+    Ryan Eatmon / reatmon@jabber.org
+    Thomas Muldowney / temas@jabber.org
+    Adam Theo / adamtheo@theoretic.com
+    Mike Szczerban / mikeszcz@delanet.com
+    Michael J. Emswiler / memswiler@hotmail.com
+  
+  To define a new namespace for dynamic forms.  Minimally to supplant jabber:iq:register and jabber:iq:search.
+
+
+
+  
+    Julian Missig / julian@jabber.org
+    Michael J. Emswiler / memswiler@hotmail.com
+  
+  Will determine the protocol for sending and receiving formatted messages in Jabber (XHTML-Basic)
+
+
+
+  
+    Jer / jer@jabber.org
+    Peter Millard / me@pgmillard.com
+    David Waite / dwaite@jabber.com
+  
+  The replacement for agents, including extensible directory lookups and namespace feature negotiation. Defined as a draft protocol but needs additional work.
+
+
+
+  
+    Dave Smith / dave@jabber.org
+    Oliver Wing / owing@vianetworks.co.uk
+    David Waite / dwaite@jabber.com
+    Rahul Dave / rahul@mozdev.org
+    Peter Millard / me@pgmillard.com
+  
+  Describe in detail how presence management currently works, and work on proposals for things like invisibility.
+
+
+
+
diff --git a/xep-0006.xml b/xep-0006.xml
new file mode 100644
index 00000000..2afa9927
--- /dev/null
+++ b/xep-0006.xml
@@ -0,0 +1,96 @@
+
+
+%ents;
+]>
+
+
+
+  Profiles
+  A proposal for a more powerful and extensible protocol for the management of personal information within Jabber.
+  &LEGALNOTICE;
+  0006
+  Obsolete
+  JIG Formation
+  Forms, Security
+  
+    Adam
+    Theo
+    adamtheo@theoretic.com
+    adamtheo@theoretic.com
+  
+  
+    Michael
+    Hearn
+    mhearn@subdimension.com
+    tweedledee@jabber.org
+  
+  
+    Eric
+    Murphy
+    ericmurphy@jabber.org
+    ericmurphy@jabber.org
+  
+  
+    1.1
+    2002-05-08
+    psa
+    Changed Status to Obsolete per approval of JEP-0019.
+  
+  
+    1.0
+    2001-07-30
+    at
+    Initial release
+  
+
+
+  Although popular, the vCard spec is too inflexible and limited. These problems become apparent when a User wants to set information outside the scope of the vCard in a standard format others will know is there. The so called 'IQ-Set' in custom namespaces is not sufficient because set information is often not in a standard format that others recognize or support. A short list of problems with vCard:
+  
+    It is inflexible, as you can only store information that is defined by a subset of the vCard format.
+    It is inefficient, as the whole vCard must be retrieved even if all you want to know is the name of a user.
+    It is impersonal, as the vCard format was designed for electronic business cards, and as such is focused on things like business contact details. We believe that people should be able to describe themselves in much greater detail than this.
+    It is unreliable, as the data is not controlled or verified by any program. I have had many problems in the past with corrupted vCards.
+  
+  But instead of bringing down the entire customization of the 'IQ-Set' to only pre-defined schemas, it is important to keep the flexibility and power of it.
+  Therefore, we propose that Jabber needs a very flexible, extensible, and powerful information structure and retrieval system. There exist four aspects to solve for when designing an improved information storage and retrieval system for any platform, especially Jabber: Interface, Structure, Storage, and Gate.
+
+
+  
+    Interface is the process, steps, and protocol a Service has to go through to access the information with the User's approval, for the User to approve or reject the access, and the User's Server to manage and secure it all.
+    Although it will be part of the Jabber protocol, it is still undecided how heavily the Profiles specification will rely on and use the Jabber system. This is the first thing that will have to be decided on, but thankfully there are some plans we have already outlined as possibilities, listed at the Theoretic Identity website.
+  
+  
+    Structure is the format that the information will be stored in and accessed by. It will have to be very flexible, likely eventually allowing the User to specify the info-sets they want to use instead of having them all set by this project.
+    The personal information will be stored in XML documents or info-sets, called 'Profiles', possibly making use of RDF, and usually following Schema specifications, although that should not be a requirement.
+  
+  
+    Storage is describing and accessing the physical location where the Profiles are kept. It will likely start off being only the Jabber Server, but will eventually allow for remote (specialized network hard drive services) and local (on the User's local machine or a portable floppy) storage. It also describes how this data will be transferred between computers and networks in an efficient and secure manner.
+    This will likely be the most other-JIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related JIGs when we get to this point to make sure their results can be used by this system.
+  
+  
+    Gate gives the User complete control at all times of others' access to and power over their Profiles. Since this system is designed to hold the bulk, if not all, of a User's personal information, they *must* have a powerful way to prevent unwanted others to access their data. So there must exist a powerful access regulation framework to precisely control which, when, and how other parties can get this information.
+    Since we want this kept flexible and very secure, the techniques used in this system will likely be a new Jabber server module that receives special 'jabber:profiles' namespaces, compares the sending JID to a User-stored list of permission-granted JIDs, and acts upon the message accordingly, either following through or rejecting the requested transfer of information.
+  
+
+
+  To make sure this project progresses smoothly and orderly, it has been decided it will be split up into steps, or 'Phases'. Each of the above four aspects will be split into two to four Phases, and the Road-map for the entire project will follow along these Phases. Version 1.0 of the Profiles system will be little more than an expanded vCard schema with simple rules and permissions to regulate access to it. It will progress up to Version 4.0 or 5.0, adding in advanced verification to persuade Services to use a User's Jabber Profiles instead of forcing them to set up a local account, and also adding write permissions so Services can set receipts of purchases and similar information in a User's Account.
+  This Road-map will be produced soon after the JIG is set up, and will give a good feature list and time-line to follow.
+
+
+  Such an improved system would obviously provide for more types of information storage and management, but there are some other side-benefits that can be conceived of.
+  
+    Since the User will have all personal information in their one account, and Services can retrieve this information with permission, this could mean no more having to fill out forms, especially account sign-up forms with Services. The information can be automatically retrieved and filled in for you. This is similar to client-side form-filler applications, except it can be used from any computer, no matter what software it has installed on it.
+    With write permission allowed to Services by the User, the Service can store their own Profiles about you in your Jabber Account. Information such as your Amazon wish list, receipts of purchases, calendar events, etc. This is similar to what Services do now, except you have control over where and how this information is physically stored and accessed.
+    Also, with an advanced authentication system (which will be the focus of a future JIG), a Service could use your Jabber Account to verify you are who you say you are, instead of requiring you set up a new account just with them. This is often called 'Universal Accounts', and similar to Microsoft's Passport and AOL's new Magic Carpet services.
+    With cookies and other auto-detection methods allowed by the User, Services can automatically detect their JID from the web browser or other tool. This eliminates the step of the User having to type in their JID, and can make this system all the more seamless to them. Combined with the above universal account benefit, this is similar to single sign-on systems such as Microsoft's Passport or AOL's new Magic Carpet.
+  
+
+
+  Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this JIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.
+  It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.
+
+
+  The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this JEP agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (http://www.theoretic.com/identity/), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.
+
+
diff --git a/xep-0007.xml b/xep-0007.xml
new file mode 100644
index 00000000..8c883609
--- /dev/null
+++ b/xep-0007.xml
@@ -0,0 +1,73 @@
+
+
+%ents;
+]>
+
+
+
+  Conferencing JIG
+  A proposal for a Jabber Interest Group that will discuss the protocol for implementing many-to-many communications.
+  &LEGALNOTICE;
+  0007
+  Obsolete
+  JIG Proposal
+  Conferencing
+  
+    David
+    Waite
+    akuma@jabber.org
+    akuma@jabber.org
+  
+  
+    1.1
+    2002-05-08
+    psa
+    Changed Status to Obsolete per approval of JEP-0019.
+  
+  
+    1.0
+    2001-08-03
+    akuma
+    Initial version
+  
+
+
+  The following proposal is for the formation of a Jabber Interest Group that will create a new conferencing protocol, as well as create additional functionality and standardize communications on top of said conferencing protocol.
+
+
+  The initial task of the Conferencing JIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.
+  The framework's scope consists of the following minimum functionality:
+  
+    Browsing a list of public rooms
+    Finding a public room based on search parameters
+    Creating new rooms
+    Destroying rooms
+    Entering existing rooms
+    Altering functionality of a room
+    Querying a room for public information
+    Sending and accepting invitations to a room
+    Changing a participant's nickname within a room
+    Discovering and changing features on a running room
+    Changing a participant's status within a room
+    Sending a message to a room or a specific participant within a room
+  
+  In addition to these basic functions, we can imagine numerous different types of conferencing features; for example, hidden rooms created on the fly for discussions between a Jabber user and their friends or co-workers, transports providing access to similar foreign systems such as IRC, additional client functionality such as shared-location (URL/Co-browsing) and whiteboarding, and so on. There might also be requirements for security levels (for instance, normal participant, moderator, and room admin).  Additional information may also be conveyed to users about one another, such as a user's real Jabber ID. Room entry or participation within a discussion might also have restrictions on some systems.
+  The framework protocol is meant to provide a basis for designing these additional features. Some features, such as co-browsing, could be implemented entirely client-side; others may require significant logic within the conferencing implementation. In addition, some features may be optional for participation within a room, while other features could be required in order for a client to participate within a room.
+
+
+  While the current "groupchat" specification is rather simple to implement, it is rather inflexible and cannot easily be extended; specifically, it has the following disadvantages:
+  
+    There is no control over how you enter a room - for instance, you can not specify a password for entering a password-protected room.
+    There is no way to create a room without entering it, and no way to tell the state of the room without being a participant within it. This means among other things that a client can not transparently use groupchat for starting multi-user chats.
+    Changes in room state are often conveyed via text messages rather than XML.  Among other things, this limits the display of messages to the English language and limits a client author's freedom in displaying this information.
+    A Participant's entry into a room is abstracted from their real Jabber account in both the old and new protocols; however, "groupchat" provides no way of tracking users across nickname changes or across sessions within a conference room.
+    The "groupchat" protocol has no way of performing feature negotiation (e.g., specifying the additional protocol elements needed to participate in a room, or optionally allowed from participants within a room). If there were participants with clients sending custom data through the room (such as XHTML or whiteboarding), you would receive that information even without your client being able to support it, and have no way of distinguishing altered behavior due to additional features of a "groupchat" implementation.
+  
+  This new conferencing protocol will be designed to solve these problems.
+  Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated.  A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features. 
+
+
+  As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing JIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the JIG will become a group for discussing and proposing new features, and for formally specifying those features.
+
+
diff --git a/xep-0008.xml b/xep-0008.xml
new file mode 100644
index 00000000..d79e21bc
--- /dev/null
+++ b/xep-0008.xml
@@ -0,0 +1,138 @@
+
+
+%ents;
+]>
+
+
+
+  IQ-Based Avatars
+  This JEP provides historical documentation of an IQ-based protocol for exchanging user avatars.
+  &LEGALNOTICE;
+  0008
+  Deferred
+  Historical
+  Standards JIG
+  Council
+  
+    XMPP Core
+    XMPP IM
+  
+  None
+  None
+  None
+  &temas;
+  &xvirge;
+  
+    Jens
+    Alfke
+    jens@mac.com
+  
+  &pgmillard;
+  
+    0.3
+    2005-06-16
+    psa
+    Coincident with publication of JEP-0153, changed type to Historical.
+  
+  
+    0.2
+    2003-05-06
+    psa
+    At the request of the authors, the status of this JEP has been changed to Retracted, to be superseded by a forthcoming JEP. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.1
+    2001-09-14
+    tm
+    Initial release
+  
+
+
+  Many communication applications now allow for the association of a small image or buddy icon (avatar) with a user of that application. The avatar is not intended to be a defining portrait of the user, but rather a simple expression of the user's appearance, mood, status, and the like. This proposal outlines a way to incorporate avatars into the current Jabber platform.
+
+
+  Certain restrictions are placed upon the image. First, the image height and width must be between thirty-two (32) and sixty-four (64) pixels. The suggested size is sixty-four (64) pixels high and sixty-four (64) pixels wide It is highly recommended that clients never scale up images when displaying them.. Images should be square, but this is not required. Images should be in GIF, JPEG, or PNG format, although it is possible that in future revisions of this spec more formats will be allowed. Finally, images must use less than eight (8) kilobytes of data.
+
+
+  There are two methods of showing that a client has an avatar available:
+  
+    Embedding the jabber:x:avatar namespace within <presence/> packets using Jabber's <x/> element
+    Displaying the jabber:iq:avatar namespace in browse requests
+  
+  Partly because Jabber browsing is relatively undeveloped, this proposal focuses on the first option.
+  The <x/> element in the jabber:x:avatar namespace contains a SHA1 hash (hexadecimal, not base64) of the image data itself (not the base64-encoded version) in a <hash/> element. (Because the odds of creating an identical hash are small, the hash is considered unique to the image and can be used to cache images between client sessions, resulting in fewer requests for the image.) The initial announcement of the availability of an avatar is done by sending a presence packet with the jabber:x:avatar information, as follows:
+  
+<presence>
+  <x xmlns='jabber:x:avatar'>
+    <hash>SHA1 of image data</hash>
+  </x>
+</presence>
+  
+  If the avatar-generating user changes the avatar, a new presence packet is sent out with the updated information:
+  
+<presence>
+  <x xmlns='jabber:x:avatar'>
+    <hash>SHA1 of new image data</hash>
+  </x>
+</presence>
+  
+  To disable the avatar, the avatar-generating user's client will send a presence packet with the jabber:x:avatar namespace but with no hash information:
+  
+<presence>
+  <x xmlns='jabber:x:avatar'/>
+</presence>
+  
+  Clients should send the current avatar hash in every <presence/> packet even if the avatar has not changed. Remember that other clients logging in will receive a copy of the most recent <presence/> element, which should therefore always contain the most recent avatar hash. However, if the client's connection is lost unexpectedly or the client disconnects without sending an unavailable presence, the server will send other clients a <presence/> element containing no jabber:x:avatar extension. Therefore if, after receiving one or more presence packets containing jabber:x:avatar information, an avatar-receiving client receives a presence packet that does not include the jabber:x:avatar namespace, it is recommended that the client save the avatar image until the next set of information is received. In this case the avatar-generating client might send something as simple as the following:
+  
+<presence/>
+  
+
+
+  There are two methods for retrieving the actual avatar data:
+  
+    An exchange between clients of <iq/> elements in the jabber:iq:avatar namespace
+    Public XML storage from the avatar-generating client to the server and public XML retrieval from the server to the avatar-requesting client Refer to the Generic XML Namespace Storage draft protocol.
+  
+  The first of these methods is preferred. On this model, a query is sent directly to the avatar-generating client using an <iq/> element of type "get" in the jabber:iq:avatar namespace Whenever possible, the avatar-requesting client should attempt to determine if the avatar-generating client has an avatar available before requesting it. It is suggested that no request be made if it is known (such as through a browse reply) that a client does not support the jabber:iq:avatar namespace.:
+  
+<iq id='2' type='get' to='user@server/resource'>
+  <query xmlns='jabber:iq:avatar'/>
+</iq>
+  
+  The avatar-generating client will reply with an <iq/> element of type "result" in the jabber:iq:avatar namespace; this reply will contain a query element that in turn contains a <data/> element with the MIME type in the 'mimetype' attribute and the data base64-encoded in the body of the <data/> element:
+  
+<iq id='2' type='result' to='user@server/resource'>
+  <query xmlns='jabber:iq:avatar'>
+    <data mimetype='image/jpeg'>
+      Base64-Encoded Data
+    </data>
+  </query>
+</iq>
+  
+  If the first method fails, the second method that should be attempted by sending a request to the server for the avatar-generating user's public XML containing the avatar data. This data is to be stored in the storage:client:avatar namespace. This method presumes that the avatar-generating client has already stored its avatar data on the server:
+  
+<iq id='0' type='set' to='user@server'>
+  <query xmlns='storage:client:avatar'>
+    <data mimetype='image/jpeg'>
+      Base64 Encoded Data
+    </data>
+  </query>
+</iq>
+  
+  Once such data has been set, the avatar can be retrieved by any requesting client from the avatar-generating client's public XML storage:
+  
+<iq id='1' type='get' to='user@server'>
+  <query xmlns='storage:client:avatar'/>
+</iq>
+  
+
+
+  It is acknowledged that sending avatar information within presence packets is less than desirable in many respects (e.g., in network traffic generated); however, there currently exists in Jabber no generic framework for addressing these shortcomings. Possible solutions on the horizon include live browsing and a pub/sub model, but these are still embryonic and experimental. Once something of that nature is accepted by the Council, the avatar spec will be modified to work within that framework rather than by attaching to presence.
+
+
+
+  Peter Millard, a co-author of this specification from version 0.1 through version 0.3, died on April 26, 2006.
+
+
+
diff --git a/xep-0009.xml b/xep-0009.xml
new file mode 100644
index 00000000..c1a05303
--- /dev/null
+++ b/xep-0009.xml
@@ -0,0 +1,316 @@
+
+
+%ents;
+]>
+
+
+	
+  Jabber-RPC
+  This JEP defines a method for transporting XML-RPC encoded requests and responses over Jabber/XMPP.
+  &LEGALNOTICE;
+  0009
+  Final
+  Standards Track
+  Standards JIG
+  
+    XMPP Core
+    XML-RPC
+  
+  
+  
+  jabber-rpc
+  
+    http://jabber.org/protocol/jabber-rpc/jabber-rpc.xsd
+  
+  
+    DJ
+    Adams
+    dj.adams@pobox.com
+    dj@gnu.mine.nu
+  
+  
+    2.1
+    2006-02-09
+    psa
+    Defined error handling, service discovery, security considerations, and Jabber Registrar considerations.
+  
+  
+    2.0
+    2002-12-09
+    psa
+    Per a vote of the Jabber Council, changed status to Final.
+  
+  
+    1.0
+    2001-09-27
+    psa
+    Changed status to Draft
+  
+  
+    0.1
+    2001-09-14
+    dja
+    Initial version
+  
+
+
+  &xmlrpc; is a method of encoding RPC requests and responses in XML. The original specification defines HTTP (see &rfc2068;) as the only valid transport for XML-RPC payloads.
+  Various initiatives exist already to transport XML-RPC payloads over Jabber. These initiatives were independent of each other and used slightly differing methods (e.g. carrying the payload in a  element as opposed to an &IQ; stanza), resulting in potential interoperability problems.
+  A working session during JabberCon 2001 resulted in a formalisation of a single method. This JEP describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.
+
+
+  The &IQ; stanza is used to transport XML-RPC payloads. XML-RPC requests are transported using an &IQ; stanza of type "set", and XML-RPC responses are transported using an &IQ; stanza of type "result". An &IQ; stanza MUST NOT contain more than one request or response.
+  The &IQ; stanza contains a single &QUERY; sub-element in the jabber:iq:rpc namespace. The direct child of the &QUERY; element will be either a single <methodCall/> element (in the case of a request) or a single <methodResponse/> element (in the case of a response). This child element will contain the XML-RPC payload. Note that the XML declaration that normally appears at the head of an XML-RPC request or response when transported as the payload of an HTTP POST request MUST BE omitted when it is transported via a Jabber &IQ; stanza.
+  The encoding of the Jabber XML stream is UTF-8. It is assumed that the encoding of the XML-RPC payload is also UTF-8.
+  Application-level errors will be indicated within the XML-RPC payload (as is the case with the traditional HTTP-based XML-RPC mechanism). Transport level errors will be indicated in the normal way for &IQ; stanzas -- namely, by an &IQ; stanza of type "error" and the addition of an <error/> tag as a direct child of the &IQ; stanza. There are no specific XML-RPC-related, transport-level errors.
+
+
+  
+  
+    
+      examples.getStateName
+      
+        
+          6
+        
+      
+    
+  
+
+  ]]>
+  
+  
+    
+      
+        
+          Colorado
+        
+      
+    
+  
+
+  ]]>
+  If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:
+  
+  
+    
+      examples.getStateName
+      
+        
+          6
+        
+      
+    
+  
+  
+    
+  
+
+  ]]>
+
+
+  If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &jep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":
+  
+  
+
+  ]]>
+  
+  
+    
+    
+  
+
+  ]]>
+
+
+  An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  
+    The ®ISTRAR; includes 'jabber:iq:rpc' in its registry of protocol namespaces.
+  
+  
+    The Jabber Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.
+  
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0009: http://www.jabber.org/jeps/jep-0009.html
+
+      There is no official XML schema for XML-RPC. The main body 
+      of this schema has been borrowed from an unofficial schema 
+      representation contained in the book "Processing XML With 
+      Java" by Elliotte Rusty Harold, as located at:
+
+      http://www.ibiblio.org/xml/books/xmljava/chapters/ch02s05.html
+    
+  
+
+  
+    
+      
+        
+        
+      
+    
+  
+
+  
+    
+      
+        
+          
+            
+              
+            
+          
+        
+        
+          
+            
+              
+            
+          
+         
+      
+      
+  
+
+  
+    
+      
+        
+          
+            
+              
+            
+          
+        
+        
+          
+          
+            
+              
+                
+                  
+                     
+                       
+                         
+                          
+                          
+                          
+                          
+                        
+                      
+                    
+                  
+                
+              
+            
+          
+         
+      
+      
+  
+
+  
+    
+      
+    
+  
+
+  
+    
+      
+      
+      
+      
+      
+      
+      
+      
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+  
+    
+      
+      
+    
+  
+
+  
+    
+      
+        
+          
+            
+          
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+  ]]>
+
+
diff --git a/xep-0010.xml b/xep-0010.xml
new file mode 100644
index 00000000..9d613eb9
--- /dev/null
+++ b/xep-0010.xml
@@ -0,0 +1,55 @@
+
+
+%ents;
+]>
+
+
+
+  Whiteboarding JIG
+  A proposal to form a JIG to develop a protocol for whiteboarding over Jabber.
+  &LEGALNOTICE;
+  0010
+  Obsolete
+  JIG Formation
+  None
+  
+    Niklas
+    Gustavsson
+    niklas@protocol7.com
+    nikgus@jabber.org
+  
+  
+    1.1
+    2002-05-08
+    psa
+    Changed Status to Obsolete per approval of JEP-0019.
+  
+  
+    1.0
+    2001-09-30
+    ng
+    Initial release
+  
+
+
+  Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.
+  There exists today a protocol draft for sending streaming XPM over Jabber XPM over Jabber (http://docs.jabber.org/draft-proto/html/sxpm.html). XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.
+  Therefore, the Whiteboard JIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing JIG Conferencing protocol draft (http://jabber.org/?oid=1538).
+
+
+  The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council as a JEP):
+  
+    A set of requirements that the proposed protocol should fulfill.
+  
+  
+    There are today at least four different attempts Distributed SVG documents (http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding JIG should evaluate them all and see which features of each are worth keeping.
+  
+  
+    One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.
+  
+  
+  The actual protocol for how the graphics data is sent over Jabber. This will also include an analysis of any associated functionality that must be performed by Jabber servers and clients.
+  
+
+
diff --git a/xep-0011.xml b/xep-0011.xml
new file mode 100644
index 00000000..c125870f
--- /dev/null
+++ b/xep-0011.xml
@@ -0,0 +1,483 @@
+
+
+%ents;
+]>
+
+
+
+  Jabber Browsing
+  This JEP defines a way to describe information about Jabber entities and the relationships between entities. Note: This JEP is superseded by JEP-0030: Service Discovery.
+  &LEGALNOTICE;
+  0011
+  Deprecated
+  Historical
+  Standards JIG
+  
+    XMPP Core
+  
+  
+  
+    JEP-0030
+  
+  iq-browse
+  
+    http://jabber.org/protocol/iq-browse/iq-browse.xsd
+  
+  &jer;
+  &xvirge;
+  &temas;
+  
+    1.2
+    2004-11-12
+    psa
+    Per a vote of the Jabber Council, changed status to Deprecated.
+  
+  
+    1.1
+    2004-01-06
+    psa
+    Added schema.
+  
+  
+    1.0
+    2002-05-08
+    psa
+    Changed status to Active.
+  
+  
+    0.4
+    2002-04-15
+    jer
+    Changed the suggested use of category to an attribute of item instead of the element names.
+  
+  
+    0.3
+    2002-01-16
+    psa
+    Added additional category/type combinations from the protocol draft (also created new category 'validate' as a bucket for the grammar and spelling checkers, which formerly were under the 'render' category).
+  
+  
+    0.2
+    2002-01-04
+    jkm
+    Updated to JEP format and revised description.
+  
+  
+    0.1
+    2001-01-25
+    jm
+    Initial draft version.
+  
+
+
+  The Jabber world is a diverse place, with lots of services, transports, software agents, users, groupchat rooms, translators, headline tickers, and just about anything that might interact on a real-time basis using conversational messages or presence. Every JabberID (JID) is a node that can be interacted with via messages, presence, and special purpose IQ namespaces. Some JIDs are parents (such as transports), and often many JIDs have relationships with other JIDs (such as a user to their resources, a server to its services, etc.). We need a better way to structure and manage this culture of multi-namespace JID stew. The answer: Jabber Browsing.
+  Note well that implementors are encouraged to implement &jep0030; instead of Jabber Browsing.
+
+
+  One of the concepts in browsing which helps to extend the interaction between JIDs is a "JID-Type", a simple heirarchy for identifying the role of any JabberID that is similar to the mime-type format. Many programmers are comfortable with the concept of identifying file types by mime-types, which use the format "category/type". A JID-Type, once discovered, is to be used in the same way that a mime-type would be for a file, to alter the user interface representing that JID or provide alternative functionality for interacting with it (either automatically or driven by user interaction). The following categories and types are proposed as the canonical list for the purpose of JID-Types:
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  Category Type Description
application/  Specific applications running as a resource on a user@host
bot Automated conversations
calendar Calendaring and scheduling service
editor Collaborative editor
fileserver Available files
game Multi-player game
whiteboard Whiteboard tool
conference/  Nodes of this category provide multi-user chat facilities (a.k.a. conference rooms).
irc IRC rooms (note: this enables Jabber users to connect to Internet Relay Chat rooms)
list Mailing-list-style conferences
private Private, dynamically-generated conference rooms
public Public, permanent conference rooms
topic Topic-based conferences
url Website-hosted conferences
headline/  Recognize different sources of headlines, GUI hints
logger Log messages (usually presented in a scrolling GUI)
notice Alerts and warnings (usually presented as popup messages)
rss Rich Site Summary syndication
stock Stock market information by symbol (ticker)
keyword/  Keyword-based lookup services (search engines, etc.)
dictionary Dictionary lookup service
dns DNS resolver
software Software search
thesaurus Thesaurus lookup service
web Web search
whois Whois query service
render/  Automated translation services
en2fr English to French
*2* Other language to language (using standard language codes)
tts Text to Speech
service/  Nodes of this category provide a link to another Instant Messaging network or messaging gateway. The 'jabber:iq:register' namespace can be used to gain access to such networks, and the 'jabber:iq:search' namespace may also be available.
aim AIM transport
icq ICQ transport
irc IRC gateway (note: this enables IRC users to connect to Jabber)
jabber A Jabber server which conforms to the specification for the 'jabber:client' namespace
jud Jabber User Directory
msn MSN transport
pager Pager gateway
serverlist A list of servers. It is assumed that this node has service/* children
sms SMS gateway
smtp SMTP gateway
yahoo Yahoo! transport
user/  Nodes of this category are Jabber users, typically implementing enough of the 'jabber:client' namespace to be compliant.
client A standard or fully-featured Jabber client compliant with the 'jabber:client' namespace
forward A forward alias
inbox An alternate inbox
portable A portable device implementing some of the 'jabber:client' namespace
voice A node providing phone or voice access
validate/  Validation services
grammar Grammar-checking tool
spell Spell-checking tool
xml XML validator
+  Historically each category was used as the name of an element, and the type was an attribute, such as ]]>. The proper expression for all new implementations supporting this specification is to express the type information as attributes on a generic item element: ]]>. When processing returned browse information this new syntax should always be handled first, and the old syntax only used if it is important to be able to access older implementations.
+  Additional unofficial categories or types may be specified by prefixing their name with an "x-", such as "service/x-virgeim" or "x-location/gps". Changes to the official categories and subtypes may be defined either by revising this JEP or by activating another JEP. Removal of a category or subtype must be noted in this document.
+
+
+  The namespace containing the Jabber Browsing data is jabber:iq:browse. The primary element within this namespace is 'item' (again, historically every category listed above would also be an element).
+  
+    The common way to browse to a JabberID using IQ is:
+    
+<iq type="get" to="jer@jabber.org" id="browse1"/>
+  <query xmlns="jabber:iq:browse"/>
+</iq>
+    
+  
+  
+    The item element has these attributes in a browse result:
+    
+      jid [required] -- The full JabberID of the entity described.
+      category [optional] -- One of the categories from the list above, or a non-standard category prefixed with the string "x-".
+      type [optional] -- One of the official types from the specified category, or a non-standard type prefixed with the string "x-".
+      name [optional] -- A friendly name that may be used in a user interface.
+      version [optional] -- A string containing the version of the node, equivalent to the response provided to a query in the 'jabber:iq:version' namespace. This is useful for servers, especially for lists of services (see the 'service/serverlist' category/type above).
+    
+  
+  
+    Any item may contain any number of additional items as a child, which describes the hierarchical relationship between the parent and the child items. This relationship could be represented as a "link" in a wizard or page-based user interface, or as a branch in a tree as it is expanded. Browse results usually only contain the direct children of a node, not the grandchildren. Browsing to a user, but not a resource, will return results from the server (still with the user's JID) containing the list of resources.
+    For example, this could be the result of browsing to jer@jabber.org:
+    
+<iq type="result" from="jer@jabber.org" id="browse1">
+  <query
+      xmlns="jabber:iq:browse"
+      category="user"
+      jid="jer@jabber.org"
+      name="jer">
+    <item
+        category="user"
+        jid="jer@jabber.org/foxy"
+        type="client"/>
+    <item
+        category="application"
+        jid="jer@jabber.org/chess"
+        name="XChess"/
+        type="game">
+    <item
+        category="user"
+        jid="jer@jabber.org/palm"
+        type="client"/>
+  </query>
+</iq>
+    
+    More definitively, throughout all of browsing, a parent describes the children, and the children when browsed to fully describe themselves. The browse data received from the child takes precedence.
+    Parents should list children only if they are available. This means that if for a user a child client goes offline, the parent should remove it from its browse result.
+  
+  
+    On top of the browsing framework, a simple form of "feature advertisement" can be built. This enables any entity to advertise which features it supports, based on the namespaces associated with those features. The <ns/> element is allowed as a subelement of the item. This element contains a single namespace that the entity supports, and multiple <ns/> elements can be included in any item. For a connected client this might be <ns>jabber:iq:oob</ns>, or for a service <ns>jabber:iq:search</ns>. This list of namespaces should be used to present available options for a user or to automatically locate functionality for an application.
+    The children of a browse result may proactively contain a few <ns/> elements (such as the result of the service request to the home server), which advertises the features that the particular service supports. This list may not be complete (it is only for first-pass filtering by simpler clients), and the JID should be browsed if a complete list is required.
+    Clients should answer incoming browsing requests to advertise the namespaces they support.
+    
+<iq type="result" from="jer@jabber.org/foxy" id="browse2">
+  <query
+      xmlns="jabber:iq:browse"
+      category="user"
+      jid="jer@jabber.org/foxy"
+      name="laptop"
+      type="client">
+    <ns>jabber:client</ns>
+    <ns>jabber:iq:browse</ns>
+    <ns>jabber:iq:conference</ns>
+    <ns>jabber:iq:time</ns>
+    <ns>jabber:iq:version</ns>
+    <ns>jabber:x:roster</ns>
+    <ns>jabber:x:signed</ns>
+    <ns>jabber:x:encrypted</ns>
+  </query>
+</iq>
+    
+  
+  
+    When a JabberID is browsed, the result may contain children or it may be empty. An empty result means there are no further relationships or links under that JID, which could be represented as a page containing a list of functions available for the JID, such as vCard, message, register, etc. When the result contains children, they may also be empty (as in the first result from jer@jabber.org above). An empty child does not mean anything, and to determine the namespaces supported or if there are more children, it must be browsed to directly.
+  
+
+
+  The first important use of jabber:iq:browse is to replace the jabber:iq:agents namespace. When a client connects, it may optionally browse to the server to which it connected in order to retrieve a list of available services. The resulting iq might look like the following example:
+    
+<iq type="result" from="jabber.org" id="browse3">
+  <query
+      xmlns="jabber:iq:browse"
+      category="service"
+      type="jabber"
+      jid="jabber.org"
+      name="Jabber.org Public Server">
+    <ns>jabber:client</ns>
+    <ns>jabber:iq:browse</ns>
+    <ns>jabber:iq:conference</ns>
+    <ns>jabber:iq:time</ns>
+    <ns>jabber:iq:version</ns>
+    <item
+        category="service"
+        jid="icq.jabber.org"
+        name="ICQ Transport"
+        type="icq">
+      <ns>jabber:iq:register</ns>
+      <ns>jabber:iq:search</ns>
+      <ns>jabber:iq:gateway</ns>
+    </item>
+    <item
+      category="conference"
+      type="private"
+      jid="conference.jabber.org"
+      name="Private Chatrooms"/>
+    <item
+        category="application"
+        jid="jabber.org/help"
+        name="Assistance Agent"
+        type="bot"/>
+  </query>
+</iq>
+  
+  To determine any further details from this list, each child would have to be browsed. The elements within the icq service are only hints to a client for building user interface elements. The icq.jabber.org service would still need to be browsed in order to determine any relationships or additional namespaces. This top-level list is the master "services" list available from the server, and should be used for any default functionality when available. This list could also serve as the "home page" for a page-based browsing user interface.
+
+
+  A client should not just blindly request browse information every time the user requests it, rather, a client should cache the browse results based on JabberID. Any display or use of the browse data should then be returned from the cache. This model is similiar to that of presence.
+
+
+  There are no security features or concerns related to this proposal.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:browse' is already a registered protocol namespace.
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0011: http://www.jabber.org/jeps/jep-0011.html
+    
+  
+
+  
+    
+      
+        
+        
+      
+      
+      
+      
+      
+    
+  
+
+  
+    
+      
+        
+      
+      
+      
+      
+      
+    
+  
+
+  
+
+
+    ]]>
+
+
+  The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this JEP will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.
+
+
diff --git a/xep-0012.xml b/xep-0012.xml
new file mode 100644
index 00000000..b2a9e6f9
--- /dev/null
+++ b/xep-0012.xml
@@ -0,0 +1,159 @@
+
+
+%ents;
+]>
+
+
+
+  Last Activity
+  This JEP defines a protocol for retrieving information about the last activity associated with a Jabber entity.
+  &LEGALNOTICE;
+  0012
+  Active
+  Historical
+  Standards JIG
+  
+    XMPP Core
+    XMPP IM
+  
+  
+  
+  iq-last
+  
+    http://jabber.org/protocol/iq-last/iq-last.xsd
+  
+  &jer;
+  &temas;
+  &stpeter;
+  
+    1.1
+    2004-01-22
+    psa
+    Editorial revisions.
+  
+  
+    1.0
+    2002-01-22
+    psa
+    Changed status to Active.
+  
+  
+    0.3
+    2002-01-14
+    psa
+    Made appropriate changes to reflect this JEP's status as informational.
+  
+  
+    0.2
+    2002-01-04
+    tjm
+    JEP form for standardization.
+  
+  
+    0.1
+    2001-01-25
+    jm
+    Initial version from website.
+  
+
+
+  It is often helpful to know the time of the last activity associated with a Jabber Entity. The canonical usage is to discover when a disconnected user last accessed the server (a closely related usage is to discover when a connected user was last active on the server, i.e., the user's idle time). The 'jabber:iq:last' namespace provides a method for retrieving this kind of information. In historical usage, the 'jabber:iq:last' namespace has also been used to query Jabber servers and components about their current uptime; however, this is an extension to the core usage of the 'jabber:iq:last' namespace and may require the addition of a separate namespace in the future.
+  Although the 'jabber:iq:last' namespace has been in use since January 2001, it is still not considered one of the standard Jabber protocols. While the &jabberd; server, many components, and some clients already implement this namespace, it is often overlooked by new developers because of the lack of standardization. This informational JEP defines the protocol as it is used today in order to more fully document it for historical purposes.
+
+
+  The 'jabber:iq:last' namespace is used as the value of the 'xmlns' attribute of a <query> element contained within an <iq/> element. When requesting last activity information, a Jabber Entity sends an <iq> element of type='get' to another Jabber Entity (i.e., a JID). When responding to such a request, a Jabber Entity sends an <iq> element of type='result'. The <query> element never has any children and contains only one attribute and CDATA, depending on the scenario in which it is used.
+  As currently implemented, the Jabber Entity receiving an IQ reply in the 'jabber:iq:last' namespace must interpret it based on the sending JID's type in order to determine the meaning of the information. Specifically, currently the information means something different depending on whether the JID sending the reply is of the form 'host', 'user@host', or 'user@host/resource'. These differences and established usage are explained more fully below.
+
+
+  As noted above, the primary usage of the 'jabber:iq:last' namespace is to find out how long ago a user logged out (and, additionally, what their status message was at that time). This primary usage assumes that the IQ get is sent to (and the IQ reply is received from) a JID of the form 'user@host'. When used in this way, the <query> element contained in the IQ reply has a 'seconds' attribute, which is the number of seconds that have passed since the user last logged out, and the element CDATA is the status message of the last unavailable presence received from the user. An example is shown below:
+  
+  
+
+
+
+  
+    Heading home
+  
+
+  ]]>
+  In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence packet of type='unavailable' whose <status/> element contained the text "Heading home".
+  If the user has at least one available resource when the server receives the request, the response SHOULD contain an empty <query/> element whose 'seconds' attribute is set to a value of '0'.
+  Note well that, as specified in &xmppcore; and &xmppim;, an IQ query sent to a JID of the form user@host is handled by a server on the user's behalf, not forwarded to one or more active resources. In addition, a server MUST NOT return last activity information to an entity that is not authorized to view the user's presence information (normally via presence subscription), and MUST return a "Forbidden" error in response to such a request (for information about error conditions, refer to &jep0086;).
+
+
+  When the IQ get in the 'jabber:iq:last' namespace is sent to a specific resource of an online user (i.e., a JID of the form of 'user@host/resource'), the JID sending the reply MAY respond with the idle time of the user. This is not a required protocol for clients to support, so clients sending such requests MUST NOT depend on receiving a meaningful result from the target user (although a client that does not support the protocol, or that does not wish to divulge this information, SHOULD return a "Service Unavailable" error). The standard does not specify what resolution the clients must use for the idle times, so the result SHOULD NOT be used as a precise measurement. Here is an example:
+    
+  
+
+     
+
+  
+
+  ]]>
+  In this example, the user has been idle for about two minutes.
+  If there is no available resource matching the user@host/resource in the 'to' attribute of the request, the server MUST follow the rules in XMPP IM in order to determine what error stanza to return.
+
+
+  When the IQ get in the 'jabber:iq:last' namespace is sent to a server or component (i.e., to a JID of the form 'host'), the information contained in the IQ reply reflects the uptime of the JID sending the reply. The seconds attribute is how long the host has been up, and the CDATA is unused.
+  
+  
+
+
+
+  
+
+  ]]>
+  In this example, the server has been up for a little more than 34 hours.
+
+
+  A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form user@host or user@host/resource; Last Activity information MAY be divulged only to those entities that have permission to view the user's presence (normally via presence subscription), potentially as restricted by privacy rules (as defined in XMPP IM and further profiled in &jep0126;).
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:last' is already a registered protocol namespace.
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0012: http://www.jabber.org/jeps/jep-0012.html
+    
+  
+
+  
+    
+      
+        
+          
+        
+      
+    
+  
+
+
+    ]]>
+
+
+  The 'jabber:iq:last' namespace has been used intensively (in the jabberd server, components such as most transports, and some Jabber clients), and no major faults have been found in the current implementations. However, as noted, it has not necessarily been used widely, and many Jabber clients lack support for this namespace. For this reason it is probably best to consider it a non-core namespace.
+  The current specification assumes that the 'resource' portion of a JID is equivalent to a device or connection (laptop, PDA, etc.). While in that context it makes sense to interpret the information returned by an IQ reply in the 'jabber:iq:last' namespace as client idle time, such an assumption will make less sense in a future world where a resource may be not a device or connection but truly a more generic resource such as a calendar or weblog. The current interpretation of 'jabber:iq:last' for 'user@host/resource' as idle time may not be appropriate for the more diverse Jabber resources of the future.
+  The most significant point of contention regarding the 'jabber:iq:last' namespace is the perceived ambiguity of the information contained in an IQ reply for this namespace. Specifically, for a 'user@host' the information is the time since the JID was last connected to the host, for a 'user@host/resource' the information is the time since the resource was last active (i.e., in most circumstances the client idle time), and for a 'host' the information is the uptime for the server or component. Because of this ambiguity (real or perceived), there is some sentiment in the Jabber community that it would be better to create a separate 'jabber:iq:uptime' namespace (and perhaps even a 'jabber:iq:idletime' namespace), leaving the 'jabber:iq:last' namespace for last disconnection time only. These potential namespaces may be proposed in one or more future JEPs if needed.
+
+
diff --git a/xep-0013.xml b/xep-0013.xml
new file mode 100644
index 00000000..66081514
--- /dev/null
+++ b/xep-0013.xml
@@ -0,0 +1,447 @@
+
+
+%ents;
+]>
+
+
+
+  Flexible Offline Message Retrieval
+  This JEP defines a protocol for flexible, POP3-like handling of offline messages in Jabber/XMPP.
+  &LEGALNOTICE;
+  0013
+  Draft
+  Standards Track
+  Standards JIG
+  
+    XMPP Core
+    XMPP IM
+    JEP-0030
+    JEP-0082
+  
+  
+  
+  offline
+  
+    http://jabber.org/protocol/offline/offline.xsd
+  
+  &stpeter;
+  
+    Craig
+    Kaes
+    ckaes@jabber.com
+    ckaes@corp.jabber.com
+  
+  
+    1.2
+    2005-07-14
+    psa
+    Added use case for retrieving number of messages; defined registar considerations more completely.
+  
+  
+    1.1
+    2004-01-22
+    psa
+    Editorial revisions.
+  
+  
+    1.0
+    2003-09-09
+    psa
+    Per a vote of the Jabber Council, advanced status to Draft.
+  
+  
+    0.8
+    2003-08-25
+    psa
+    More changes to address Council feedback: removed bandwidth rationale in requirements; added protocol flow section; adjusted semantics for node values (opaque, but dictionary ordering allowed). Also added <fetch/> and <purge/> elements.
+  
+  
+    0.7
+    2003-08-21
+    psa
+    Changes to address Council feedback: added error codes; enhanced the security considerations; clarified the nature of the node IDs and removed the protocol URI string (leaving only the timestamp).
+  
+  
+    0.6
+    2003-06-10
+    psa
+    Slight fixes to JEP-0082 reference and XML schema.
+  
+  
+    0.5
+    2003-04-28
+    psa
+    Added reference to JEP-0082; changed timestamp format to use milliseconds rather than ten-thousandths of a second; made several small editorial changes throughout.
+  
+  
+    0.4
+    2003-02-27
+    psa
+    Major overhaul: clarified requirements, incorporated disco, simplified and updated the protocol, specified syntax and semantics for nodes, defined business rules, and added XML schema.
+  
+  
+    0.3
+    2002-10-02
+    cak
+    Reworked to exclude XDBID performace hack, thereby maximizing palatability.  Removed all changes made by psa.
+  
+  
+    0.2
+    2002-10-02
+    psa
+    Changed type and added information about scope.
+  
+  
+    0.1
+    2002-01-11
+    cak
+    Initial version
+  
+
+
+  Although not required to do so by &rfc3920; and &rfc3921;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:
+  
+    It can be overwhelming, which is undesirable for the vacationer or heavy user. Many individuals upon returning to work from a weeklong vacation spend the first few hours wading through the dozens, even hundreds, of emails that they received during their absence. Unlucky, however, is this user who then logs onto their Jabber server and is bombarded by hundreds of instant messages, possibly in scores of popup dialogs, simultaneously. Should their client crash, they have lost all communication that occurred while they were away.
+    It can be difficult to integrate with web-based email clients, which is undesirable for some portals. Several large portals are currently trying to blur the distinction between IM and email -- providing both through one web interface. With offline retrieval semantics so vastly different between the two, this is quite difficult.
+  
+  What is needed is a flexible semantic for offline message handling, similar to POP3 in the email world (see &rfc1939;). This would enable the wireless user to view header information for all offline messages and select only those from their boss and important clients for viewing. It would enable the vacationer to read and delete their messages one at a time, minimizing the possibility of losing all correspondence. And it would provide for seamless integration with existing web-based email clients.
+  In particular, such a protocol should support the following use cases:
+    
+      Client determines server support for this protocol.
+      Client requests number of messages.
+      Client requests message "header" information (thereby choosing flexible offline message retrieval as opposed to old-fashioned "flood" mode).
+      Client retrieves specific messages.
+      Client removes specific messages.
+      Client retrieves all messages.
+      Client removes all messages.
+    
+
+
+  
+    In order to discover whether one's server supports this protocol, one uses &jep0030;.
+    
+   
+
+    ]]>
+    
+  
+    ...
+    
+    ...
+  
+
+    ]]>
+    If the server supports this protocol, it MUST return a <feature/> element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.
+  
+  
+    RFC 1939 includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth.
+    In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline':
+    
+  
+
+    ]]>
+    If the server supports retrieval of the number of messages, it MUST include &jep0128; data specifying the number of messages:
+    
+  
+    
+    
+    
+      
+        http://jabber.org/protocol/offline
+      
+      
+        66
+      
+    
+  
+
+    ]]>
+    Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this JEP applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.
+  
+  
+    In order to retrieve headers for all of the messages in the queue, the user sends a disco#items request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline'.
+    
+  
+
+    ]]>
+    The server now MUST return headers for all of the user's offline messages. So that the user may determine whether to view a full message, the header information provided MUST include the full Jabber ID of the sender (encoded in the 'name' attribute) and a unique identifier for the message within the user's "inbox" (encoded in the 'node' attribute), so that the user may appropriately manage (view or remove) the message.
+    
+  
+    
+    
+    
+    
+    
+  
+
+    ]]>
+    If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. If there are no offline messages for this user, the server MUST return an empty query as defined in JEP-0030. (For information about the syntax of error conditions, refer to &jep0086;.)
+    The syntax and semantics of the attributes are as follows:
+    
+      The 'jid' attribute is the Jabber ID with which the item nodes are associated, i.e., the user himself.
+      The 'name' attribute is the full JID of the sender as received in the 'from' address of the message itself.
+      The 'node' attribute is a unique identifier for the message. The value SHOULD be considered opaque, but applications MAY perform character-by-character dictionary ordering on the values. This enables applications to implement ordering on messages, such as that shown above, wherein the node values are UTC timestamps (if timestamps are used, they MUST conform to the 'Datetime' profile defined in &jep0082;).
+    
+  
+  
+    Messages are viewed based on the value of the 'node' attribute as provided for each item returned by the server in the header information. A user MAY request one or more messages in the same IQ get.
+    
+  
+    
+  
+
+    ]]>
+    If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:
+    
+  O Romeo, Romeo! wherefore art thou Romeo?
+  
+    
+  
+
+
+
+    ]]>
+    In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &jep0091; information in the message.
+  
+  
+    A server MUST NOT remove a message simply because it has been requested by and delivered to the user; instead, the user must specifically request to remove a message. This further implies that the user's offline message queue SHOULD NOT be automatically cleared out by the server if there are offline messages remaining when the user's session ends. However, an implementation or deployment MAY remove messages according to its own algorithms (e.g., storage timeouts based on a "first in first out" rule) or policies (e.g., message queue size limits) if desired.
+    As with viewing, messages are removed based on the value of the 'node' attribute as provided for each item returned by the server in the header information. The user MAY request the removal of one or more messages in the same IQ set.
+    
+  
+    
+  
+
+    ]]>
+    If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove the messages and inform the user:
+    
+    ]]>
+  
+  
+    The user retrieves all message by sending the "fetch" command:
+    
+  
+    
+  
+
+    ]]>
+    If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST retrieve all messages and inform the user:
+    
+  O Romeo, Romeo! wherefore art thou Romeo?
+  
+    
+  
+
+
+...
+
+
+    ]]>
+    A client MAY retrieve all messages without first requesting message headers. In this case, the server MUST return all of the user's offline messages and also MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. That is, the semantics here are the same as for requesting message headers.
+  
+  
+    The user removes all message by sending the "purge" command:
+    
+  
+    
+  
+
+    ]]>
+    If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove all messages and inform the user:
+    
+    ]]>
+  
+
+
+  This section shows the flow of protocol between client (C:) and server (S:) for the existing (flood) scenario and the improved (POP3-like) scenario.
+    
+
+S: 
+
+C: authentication (SASL in XMPP, non-SASL in older systems)
+
+S: acknowledge successful authentication 
+
+C: 
+
+S: send message flood to Client
+
+C: receive flood, send and receive messages, etc.
+
+... and so on]]>
+    The semantics change with POP-like offline message handling, and server behavior changes as well...
+    
+
+S: 
+
+C: authentication (SASL in XMPP, non-SASL in older systems)
+
+S: acknowledge successful authentication 
+
+C: request message headers
+
+S: send message headers to Client
+
+NOTE: Server now MUST NOT flood Client with offline messages.
+
+C: 
+
+NOTE: Server does not flood Client with offline messages, but 
+      sends in-session messages as usual.
+
+C: request and remove offline messages, send and receive messages, etc.
+
+... and so on]]>
+
+
+  A server MUST NOT deliver a user's offline messages to any JID except one of the user's authorized resources.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  
+    The ®ISTRAR; includes 'http://jabber.org/protocol/offline' in its registry of protocol namespaces.
+  
+  
+    The Jabber Registrar includes "automation" in its registry of Service Discovery categories for use for any entities and nodes that provide automated or programmed interaction. This JEP specifies the following new types for the "automation" category:
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    Type Description
message-list The node for the offline message queue; valid only for the node "http://jabber.org/protocol/offline".
message-node A node for a specific offline message if service discovery is provided for messages.
+    The registry submission is as follows:
+    
+      message-list
+      
+        The node for the offline message queue; valid only for the node 
+        "http://jabber.org/protocol/offline"
+      
+      JEP-0013
+    
+    
+      message-node
+      A node for a specific offline message if service discovery is provided for messages
+      JEP-0013
+    
+  
+    ]]>
+  
+  
+    The Jabber Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.
+  
+  
+    &jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. There is one uses of such forms in offline message retrieval as described in the Requesting Number of Messages section of this JEP. The registry submission is as follows:
+    
+  http://jabber.org/protocol/offline
+  JEP-0013
+  
+    Service Discovery extension for number of messages
+    in an offline message queue.
+  
+  
+
+    ]]>
+  
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0013: http://www.jabber.org/jeps/jep-0013.html
+    
+  
+
+  
+    
+      
+        
+      
+    
+  
+
+  
+    
+      
+        
+          
+            
+            
+          
+        
+      
+      
+      
+    
+  
+
+
+  ]]>
+
+
diff --git a/xep-0014.xml b/xep-0014.xml
new file mode 100644
index 00000000..1ea01435
--- /dev/null
+++ b/xep-0014.xml
@@ -0,0 +1,70 @@
+
+
+%ents;
+]>
+
+
+
+  Message Tone
+  A proposal for including the sender's tone in messages.
+  &LEGALNOTICE;
+  0014
+  Rejected
+  Standards Track
+  Standards JIG
+  
+    Mike
+    Mintz
+    psicoder@yahoo.com
+    mikem@jabber.org
+  
+  
+    0.2
+    2002-01-16
+    psa
+    First release to CVS, including editorial changes by the JEP Editor and assignment of JEP number.
+  
+  
+    0.1
+    2001-11-17
+    mm
+    Initial version.
+  
+
+
+  When people speak to one another, they use various tones of voice and body language to express themselves. When communicating online, people have no easy way of expressing themselves clearly. By incorporating message tones into Jabber, people will be able to convey tones such as anger, sarcasm, and confusion.
+
+
+  Tone can be added only to messages, and it is added as an <x> tag inside a message. The <x> tag will look something like this:
+  
+<x xmlns='jabber:x:tone'>angry</x>
+  
+  The specified tone is included as CDATA within the <x> element.
+  
+    Here is an example of a message with a tone:
+    
+<message to='mikem@jabber.org'>
+  <body>
+    Why the hell did they reject my idea?
+  </body>
+  <x xmlns='jabber:x:tone'>angry</x>
+</message>
+    
+  
+
+
+  Tones are not meant to be sent with every message. They should be used only in cases where a tone dramatically applies. The overuse of tones will cause them to lose their effect.
+  Because tones are abstract and not clearly defined, there is no standard list of tones. Clients should receive the tone as it is and display it as plain text, in such a way that it is linked to a specific message. Clients may want to have a specified list of tones that a user can select from when sending a message.
+  Tones should be short and simple. Here is a list of good tones:
+  
+    angry
+    confused
+    excited
+    joking
+    sad
+    sarcastic
+    serious
+  
+
+
diff --git a/xep-0015.xml b/xep-0015.xml
new file mode 100644
index 00000000..805cf124
--- /dev/null
+++ b/xep-0015.xml
@@ -0,0 +1,258 @@
+
+
+%ents;
+]>
+
+
+  
+    Account Transfer
+    A proposal for enabling the ability to transfer an account from one Jabber server to another.
+    &LEGALNOTICE;
+    0015
+    Rejected
+    Standards Track
+    Standards JIG
+    
+      Casey
+      Crabb
+      crabbkw@nafai.dyndns.org
+      airog@floobin.cx
+    
+    
+      0.4
+      2002-04-18
+      cwc
+      Cleaned up the open issues and concerns section.
+    
+    
+      0.3
+      2002-04-16
+      cwc
+      Added more specific details to the protocol. Added more examples. Tried to make the whole JEP more readable.
+    
+    
+      0.2
+      2002-02-26
+      cwc
+      Setting scope, adding discussion about using jabber:iq:browse in the future for transports
+    
+    
+      0.1
+      2002-01-24
+      cwc
+      Added more pseudo-protocol information. Added a known issues section.
+    
+    
+      1.0
+      2002-01-16
+      psa
+      First release to CVS, including editorial changes by the JEP Editor and assignment of JEP number.
+    
+    
+      0.9
+      2001-12-04
+      cwc
+      Initial version.
+    
+  
+  
+
+    I have found the need in the past to migrate an account from
+    one server to another for various reasons. Many of the people who
+    ask me about Jabber ask if there is a way to migrate their account
+    from one server to another if the need arises. There is no reason
+    Jabber can not handle this internally and update all the
+    JID-references appropriately.
+
+    Jabber servers come and go, especially ones run by people who
+    are just playing with the technology. Computers also die and
+    funding runs out. It can be hard on users to have to re-create
+    their rosters every time they have to change to a different
+    server. Administrators also want to provide an 'out' for their
+    users, so that they feel more secure in the time spent setting up
+    rosters. For these reasons there should be a way to migrate an
+    account from one server to another. 
+
+  
+  
+
+    A basic overview of the behavior would be as follows.
+    
+      
+        Bob has a jabber account on a server, floobin.cx
+          specifically: olduser@floobin.cx.
+
+        Bob knows that the floobin.cx server is going to go down soon
+          and therefore needs to find a new jabber server.
+
+        He realizes that jabber.org offers accounts to anyone, so he
+          sets out to migrate his account to jabber.org.
+
+        Bob does not yet have an account on jabber.org.
+      
+    
+    
+      Throughout most of the account transfer the server hosting
+        the old account will be acting for the user. The end client
+        should have very little to do with the actual transfer.
+
+      
+        Bob creates an account on Jabber.org:
+          bobsnewaccount@jabber.org.
+
+        Bob logs into both bobsnewaccount@jabber.org and
+          olduser@floobin.cx.
+
+        From olduser@floobin.cx he sends the 'I want to migrate my
+          account' packet to Floobin.cx. This packet includes the JID
+          to migrate to.
+
+        Floobin.cx sends the 'user wants to migrate account to
+          you' packet to bobsnewaccount@jabber.org. This packet contains
+          the JID of the old account.
+
+        bobsnewsaccount@jabber.org receives the 'user wants to
+          migrate account to you' packet and authorizes the
+          transfer.
+
+        Once the migration is authorized the floobin.cx server
+          will start the migration process. The first part is to
+          notify each person subscribed to olduser@floobin.cx's
+          presence that the account has moved to
+          bobsnewaccount@jabber.org.
+
+        Once that is complete the roster itself
+          must be added into bobsnewaccount@jabber.cx's roster. There are
+          many issues with that remain and should be dealt with in the
+          future. See the section on scope for more information.
+
+        finally floobin.cx informs olduser@floobin.cx that the
+          transfer was completed.
+      
+    
+
+    
+
+      
+        <iq id='initacctxfer' to='floobin.cx' from='airog@floobin.cx' type='ask'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <oldaccount>airog@jabber.org</oldaccount>
+            <newaccount>newaccount@jabber.org</newaccount>
+          </query>
+        </iq>
+      
+
+      
+        <iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <oldaccount>airog@jabber.org</oldaccount>
+          </query>
+        </iq>
+      
+
+      
+        <iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <oldaccount>airog@jabber.org</oldaccount>
+          </query>
+        </iq>
+      
+
+      
+        <iq id='acctxfer1' type='result' to='floobin.cx' from='newaccount@jabber.org'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <allowed/>
+          </query>
+        </iq>
+      
+
+      On acceptance the server on which the old account resides
+        starts the migration process by sending this to each person
+        subscribed to the user's presence.
+      
+        <iq id='acctxferss1' type='set' from='floobin.cx' to='jabber.org'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <oldaccount>airog@jabber.org</oldaccount>
+            <newaccount>newaccount@jabber.org</newaccount>
+            <rosteritem jid='frienduser@jabber.org'/>
+          </query>
+        </iq>
+      
+
+      
+        <iq id='acctxferss1' type='result' to='floobin.cx' from='jabber.org'/>
+      
+
+      Once that update has been sent to all the contacts on the
+        roster the floobin.cx server sends to the jabber.org server airog@floobin.cx's roster as follows:
+      
+        <iq type='set' id='acctxferss2' from='floobin.cx' to='jabber.org'>
+          <query xmlns='jabber:iq:accountxfer'>
+            <oldaccount>airog@jabber.org</oldaccount>
+            <newaccount>newaccount@jabber.org</newaccount>
+            <item jid='frienduser@jabber.org' name='friend1' subscription='both'/>
+            <item jid='annoyuser@jabber.org' ask='subscribe'/>
+            <item jid='someone@jabber.org' subscription='from'/>
+          </query>
+        </iq>
+      
+
+      
+        <iq type='set' id='acctxferss2' to='floobin.cx' from='jabber.org'>
+      
+
+      Once the migration finishes a notification is sent to the user:
+      
+        <iq id='initacctxfer' from='floobin.cx' to='airog@floobin.cx' type='result'/>
+      
+    
+  
+  
+    
+      Because we cannot determine easily if the new server will
+        support the same transports as the old server we cannot
+        easily transfer entities that pass through the
+        transport. Therefore, until jabber:iq:browse matures, or
+        some other solution for determining if two transports
+        support the same functionality we should not attempt to
+        migrate transport information.
+
+      I propose the following algorithm for determining if a
+        particular roster item is a sub-item of a transport. There are
+        jabber roster items for each of the transports themselves,
+        something to the effect of icq.jabber.org or
+        aim.jabber.org. They contain no user portion of the jid. We
+        record all of these in a list that we will call the
+        'transport-list'. Then for each roster item we want to migrate
+        we compare its 'host' part of the jid to all items in the
+        'transport-list'. If the roster item matches, then the roster
+        item is a hosted through the transport and shouldn't be
+        migrated.
+    
+
+    
+      Does the server keep an empty account that redirects requests
+        to the new account?  I've been hearing mass rumblings of 'NO'
+        here.
+    
+
+    
+      How do we handle vCard information or server side stored
+        preferences? Since the account we're migrating to can be any
+        account some of that information might already be there, how do
+        we resolve conflicts?
+
+      Also, we cannot be sure that the new server supports
+        storage of private data. This again needs some sort of
+        features negotiation, discovery which could be provided by
+        jabber:iq:browse.
+
+       Until jabber:iq:browse is in the 'standards' stage, I
+        recommend we only transfer regular jabber users, and not
+        transfer anything but the roster. All the client software will
+        have to set their preferences for themselves on the new
+        server.
+    
+  
+
diff --git a/xep-0016.xml b/xep-0016.xml
new file mode 100644
index 00000000..3f0f4ba3
--- /dev/null
+++ b/xep-0016.xml
@@ -0,0 +1,236 @@
+
+
+%ents;
+]>
+
+
+	
+		Server-Based Privacy Rules
+		Note: This JEP has been superseded by the XMPP IM Internet-Draft; please refer to that document for the most up-to-date protocol.
+                &LEGALNOTICE;
+		0016
+		Retracted
+		Standards Track
+		Standards JIG
+		None
+                None
+                XMPP IM
+                None
+		&pgmillard;
+                
+                        1.3
+                        2004-07-26
+                        psa
+                        Formally retracted this proposal in favor of XMPP IM.
+                
+		
+			1.2
+			2003-03-12
+			psa
+			Changed status to Deprecated since this protocol is now included in the XMPP IM Internet-Draft.
+		
+		
+			1.1
+			2002-11-17
+			pgm
+			Added remarks about default handling, and where list processing should take place.
+		
+		
+			1.0
+			2002-10-22
+			psa
+			Changed status to Draft.
+		
+		
+			0.4
+			2002-10-03
+			pgm
+			Elaborated on various JID possibilities.
+		
+		
+			0.3
+			2002-07-31
+			pgm
+			Added info describing current session issues
+		
+		
+			0.2
+			2002-07-30
+			pgm
+			Added whitelists, subscription filtering, and multiple list capabilities. Changed block to deny.
+		
+		
+			0.1
+			2002-01-18
+			pgm
+			Initial version.
+		
+	
+	
+          Note: This JEP has been superseded by &xmppim;; please refer to that document for the most up-to-date protocol!
+		Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users (the rationale for such blockage depends on the needs of the individual user). The method for implementing this functionality in the current Jabber system is for each client application to keep its own "blacklist" of the Jabber IDs from which the user does not wish to receive messages. This current implementation has the following drawbacks:
+		
+			The XML packets are blocked at the client network endpoint. The unwanted packets need to traverse the entire Jabber network before they are blocked from being delivered. However, these packets could be blocked at the server and never delivered "across the wire" to the client, which becomes especially important for clients that have bandwidth restrictions or in situations where bandwidth is expensive.
+			Currently there exists no Jabber standard enabling clients to share their individual blacklists. Thus blacklist entries are not portable across clients and if a user accesses their account with a different client, the user must re-enter the blacklist entries.
+			Most implementations have no way of blocking specific types of packets -- they typically block only message packets.
+		
+		The solution to these shortfalls is to have a common blacklist which is stored on the Jabber server along with the other information which clients receive from the server (primarily the roster).
+	
+	
+		This document proposes the addition of a new namespace to handle the storage and retrieval of the server-side blacklist and whitelist information. The proposed 'jabber:iq:privacy' namespace would be consistent with the existing jabber:* namespaces and use the <query/> element as a direct child under the main <iq/> element. A client application would use <iq type="get"> to retrieve the lists from the server, and use <iq type="set"> to add or edit items in a specific list. Each list is a combination of multiple items. Each item can be of type allow or deny. For this document, these lists will be called "zebra lists".
+		Each <query/> element would have one or more <list> elements which would contain the information for an entire zebra list. The <query> element also contains an <active> element and a <default> element. These elements contain the name of the currently active zebra list or the name of the default zebra list. A client application may perform a get request with an empty <active> element and/or and empty <default> which indicates that it only wants to know which list is currently active or the default list. A client application may also specify a default list to be used for offline processing and when no active list is directly specified. To fetch the currently active list and the rules for each list, the client application performs a simple blank get request.
+		The <default> element is used when processing packets and the client is offline, and is used whenver the client connection (session) does not specify a specific list to be active.
+		Each <item> element in the zebra list MAY contain a jid attribute (the Jabber ID, i.e. user@host, of the contact which is to be blocked or allowed), MAY contain a subscription attribute, and MUST contain a type attribute. If no jid attribute is specified, then the rule MUST apply to all jids. The possible values of the type attribute would be either "deny", "allow". To remove items from the list, simply send back the list tag with the various <item> elements missing.
+		If the <item> element contains a subscription attribute, it means that the rule applies to all jids in the current users roster which have matching subscription elements. Note that a subscription of "both" MUST be treated the same as "from" and "to" together. 
+		If the <item> element contains no child elements, then all packets would be blocked or allowed. This includes: messages, presence packets, and iq packets. The <item> elements MAY contain the following empty child elements:
+		
+			The <message/> element (blocks or allows all message packets).
+			The <presence/> element (blocks or allows all presence packets).
+			The <iq/> element (blocks or allows all iq packets).
+		
+		When a message or other XML packet is blocked according to the entries in the list, the server MUST bounce the packet back to the original sender. The bounced packet MUST be of type="error" and contain a child <error/> element with a code attribute of 405.
+		If a <list> element is sent that contains no child elements, the list of that name is removed. If the active list is not reset during the list removal, and the list removed was the active list, the user is returned back to a default state of allow all packets.
+	
+	
+		Setting your active zebra list is effective for the current session only, but the storage of the lists is for the user. During usage, a client application should set the active list before sending available presence or fetching the roster. If a client does not set the active zebra list for the current session, the default rules of allowing all packets would apply to that session.
+		
+		When changing or editing in a specific zebra list, the client application MUST send back all items in the list in the desired order. Server side components that are performing the packet filtering MUST preserve the order of the individual <item> tags and process the rules in that order. All lists MUST have at least one rule that SHOULD specify the default action. The client application MAY send back an <active> element indicating the new currently active list. If no <active> element is sent, the currently active list is used.
+		When a client application wishes to just change the currently active zebra list, they MUST NOT send back all of the lists and their contents. The client application SHOULD send back just the new <active> element. If the named list does not exist, the server MUST send back an error using error code 406 (Not Acceptable).
+		Client applications can NOT set the default or active list, and alter the actual lists in the same packet. If a client connection attempts to modify both things at once, the server implementation must send back a iq-error using error code 406.
+		Implementations of zebra lists MAY choose to allow specific packet types to be checked. If a client attempts to set an item with a specific packet type (message, presence, or iq) and the implementation does not support that feature, the server MUST send back the <iq/> as a type="error" using an error code of 406 (Not Acceptable).
+		Implementation of zebra lists SHOULD NOT "push" new lists and additions to existing clients already connected using the same JID (as you would get jabber:iq:roster pushes). If a client application wants to know the current zebra list information, it SHOULD send a get request.
+		When a jabber ID is specified on a rule and the ID does not conform to user@host, the following rules apply:
+		
+			JIDs of the form 'domain.com' must apply to all users from that domain (ie, *@domain.com). Note that the asterisk (*) is a legal user character, thus, 'domain.com' is different from '*@domain.com'
+			JIDs of the form 'user@domain.com/resource' apply to that specific resource. Packets from other resources from that user MUST not match the rule.
+			JIDs of the form 'service.domain.com/resource' apply to that specific resource of that service. (As opposed to 'service.domain.com', which matches for '*@service.domain.com'.)
+		
+		If a packet does not match any rules in the active list, the default action is to allow.
+	
+	
+		The following protocol segments illustrate the exchange of packets between the client application and the server in order to retrieve the zebra list information.
+		
+  
+]]>
+		
+  
+    
+    
+      
+      
+      
+    
+    
+    	
+    	
+    	
+    
+  
+]]>
+	
+	
+		The following protocol segments illustrate the exchange of packets used to change the active zebra list.
+		
+  
+    
+  
+]]>
+		
+<iq type="result" id="2"/>
+    
+	
+	
+		The following protocol segments illustrate the exchange of packets used to add or edit a zebra list.
+		
+  
+    
+      
+      
+      
+      
+    
+  
+]]>
+		
+<iq type="result" id="3"/>
+    
+	
+	
+		The following protocol segments illustrate how a client application would remove a zebra list.
+		
+  
+    
+  
+]]>
+		
+<iq type="result" id="4"/>
+    
+	
+	
+		The following protocol segments illustrate the exchange of message packets when the sender is blocked by the currently active zebra list.
+		
+  Hey, I just wanted to chat!
+]]>
+		
+  Hey, I just wanted to chat!
+  Not Allowed
+]]>
+	
+	
+		
+
+
+
+
+
+
+
+
+
+
+
+]]>
+	
+	
+		In the future, it may be desirable at some point to allow clients to filter specific iq namespaces. The protocol could easily handle this capability by doing something like the following:
+		
+  
+    
+      
+      
+      
+      	jabber:iq:oob
+      
+    
+  
+]]>
+		
+<iq type="result" id="6"/>
+    
+        In the future, it may be desirable to have be able to block normal presence/availability packets, while still allowing subscription packets through the zebra list.
+		In the current open source Jabber server, there is a JSM module called mod_filter which has the capability to implement this type of functionality. However, most servers with large user bases have found it impossible to use mod_filter because of the load that it imposes on packet processing. Using normal whitelist/blacklist operations should make the processing much simpler than mod_filter's processing of an unknown set of rules various rules (not just blocking).
+	
+
+
+  Peter Millard, the author of this specification from version 0.1 through version 0.3, died on April 26, 2006.
+
+
+
diff --git a/xep-0017.xml b/xep-0017.xml
new file mode 100644
index 00000000..5c99553f
--- /dev/null
+++ b/xep-0017.xml
@@ -0,0 +1,83 @@
+
+
+%ents;
+]>
+
+
+
+Naive Packet Framing Protocol
+An intermediate method for more efficient framing of the Jabber XML Stream.
+This document has been placed in the public domain.
+0017
+Rejected
+Informational
+Standards JIG
+
+Mike
+Lin
+mikelin@mit.edu
+mlin@mlin.mit.edu
+
+
+Julian
+Missig
+julian@jabber.org
+julian@jabber.org
+
+
+0.3
+2002-02-19
+mfl
+Continued improvement and specification.
+
+
+0.2
+2002-01-31
+mfl
+Added various clarifications and implementation notes.
+
+
+0.1
+2002-01-23
+mfl
+Initial revision.
+
+
+
+Framing is the mechanism by which a listener is able to separate a stream of information into discrete semantic units. In Jabber, each of these semantic units is a fragment of a <stream:stream> document consisting of a direct (depth=1) child element of the <stream:stream> document element, and all its attributes and child nodes. These semantic units are hereafter called packets. A Jabber session document, excluding the document element start tag and end tag which are handled as special cases, is implicitly encoded into these packets and transmitted across the network.
+This JEP describes a framing method that may provide performance and code simplicity advantages over the framing method currently used.
+
+ The current scheme for framing in Jabber relies on the inherent structure of XML to determine packet boundaries. Since each packet is a well-formed XML fragment, the start of the packet is unambiguously denoted by the element start tag at depth=1, and the end of the packet is unambiguously denoted by the corresponding close tag at depth=1.
+This method of framing is elegant because all the necessary framing information is inherent in the XML; it makes framing independent of the underlying transport layer so long as that transport layer guarantees per-session FIFO delivery. However, it has significant performance and implementation disadvantages, as it requires any Jabber node (endpoint or router) to XML-parse the packet as it is still being received in order to determine the packet boundary. Many XML parsing suites are not designed to be used in this manner, and various hacks and workarounds have emerged in current Jabber software in order to adapt them for this purpose.
+
+
+Consider a simple method that prefixes the byte length of each packet as an XML text node at depth=1. Put more simply, the transmitting agent calculates the byte length of the element it wishes to transmit. It then transmits this integer length encoded as text, immediately followed by the element.
+This technique has the following advantages:
+
+The receiving agent is able to anticipate the size of the incoming packet. It can then buffer the element without having to parse it while it is only partially received, which is significantly more straightforward and more efficient to implement given the design of most current XML parsing suites. For large packets, this also allows the receiving agent to reduce potentially expensive memory realocation and copying.
+A router needs not load the entire packet payload into a DOM; it has the option of parsing only the element start tag and retransmitting the rest of the packet verbatim after checking for well-formedness.
+Since the framing data are just XML text nodes, their addition should be largely backwards compatible with current Jabber software, which should be made to ignore the extraneous depth=1 text with few, or possibly no, modifications.
+Implementation of the protocol takes very little effort. Transmitting agents generally should know the size of the packets they are about to transmit. In comparison to the work they must currently do, receiving agents are only helped by the addition of framing data; in any case, interpretation of the framing data is optional.
+
+This technique has the following disadvantages:
+
+The simple insertion of framing data into the streaming XML document does not pay attention to the logical distinction between the XML document and the framing transport over which it is being transmitted.
+Error-handling semantics must be arbitrarily defined in the event that a transmitting agent misframes a packet (that is, sends the incorrect packet size).
+
+
+
+Framing data is included for the <stream:stream> and </stream:stream> tags as if they were their own packets, although they are not independently well-formed XML. These should be handled as special cases in a Jabber XML streams implementation.
+The connecting agent (client) implicitly requests that the receiving agent (server) use JEP-0017 framing by transmitting JEP-0017 framing data in its own outgoing stream (the connecting agent always "goes first"). Servers should detect the presence of framing data in the client's stream (by testing whether the first character received is a digit or a <) and, if it is detected, activate outgoing framing for that session.
+Regardless of the use of framing data, all nodes must verify the well-formedness of XML payloads in order to avoid propagating misframes.
+
+
+
+94<message to="whomever@mlin.mit.edu" from="mlin@mlin.mit.edu">some opaque information</message>
+  
+
+
+This framing method is not intended as a fully satisfactory or permanent solution to XML stream framing. In the "distant" (longer than one year) time span, it may be desirable to consider more thorough systems such as BEEP. The intent of this JEP is to establish an intermediate solution that will provide code simplicity advantages to new implementations in the near term without requiring fundamental changes to the Jabber transport or protocol (as adopting BEEP would almost certainly require).
+
+
+
diff --git a/xep-0018.xml b/xep-0018.xml
new file mode 100644
index 00000000..4952a796
--- /dev/null
+++ b/xep-0018.xml
@@ -0,0 +1,135 @@
+
+
+%ents;
+]>
+
+
+
+  Invisible Presence
+  Documentation of invisible presence.
+  &LEGALNOTICE;
+  0018
+  Rejected
+  Informational
+  Standards JIG
+  XMPP Core, XMPP IM
+  None
+  None
+  N/A
+  
+    Ben
+    Schumacher
+    ben@blahr.com
+    rynok@jabber.com
+  
+  
+    Jeremie
+    Miller
+    jer@jabber.org
+    jer@jabber.org
+  
+  
+    0.2
+    2003-09-26
+    bs
+    Updated to focus solely on <presence type='invisible'/>.
+  
+  
+    0.1
+    2002-01-28
+    jmm
+    Initial draft.
+  
+
+  
+    Jabber users have long wanted the ability to come online using Jabber, but appear "unavailable" to a subset of their roster, an ability which is commonly referred to as invisible mode. While several current implementations have various ways of providing this functionality, the systems currently in place often lack clear behavior and documentation. This document provides requirements for invisible mode and clarifies the existing protocol-in-use to provide the desired functionality.
+    Note well: The functionality described herein can and should be implemented by means of the Privacy Rules namespace defined in &xmppim;. This document is provided for historical purposes only.
+  
+  
+    The requirements for invisible mode are basic:
+    
+      A user should be able to become visible or invisible at any time.
+      When in either mode, users should be able to selectively allow or block presence updates to be distributed to their contacts.
+    
+  
+  
+    For the purposes of this discussion, we will assume this terminology.
+    
+      Undirected Presence - A presence stanza without a "to" attribute.
+      Directed Presence - A presence stanza with a "to" attribute.
+    
+    
+      Assuming the user's client has authenticated with the system normally, it would send the following presence stanza to become invisible (note: this can be the initial presence stanza sent by the user). To do so, the client will send undirected presence with a type="invisible" attribute.
+      ]]>
+    
+    
+      If a user chooses to become visible after being invisible, the client will send undirected presence with a type="visible" attribute.
+      ]]>
+    
+    
+      If a user is visible to all of their contacts, and wishes to become invisible to selected contacts on their roster, then their client will send the following directed presence stanza.
+      ]]>
+      In this case, the server begins to track that the user is invisible to the contact joe@foo.com, and does not forward further presence updates to joe@foo.com. If the user wishes joe@foo.com to received further presence updates, then their client must send either an undirected presence stanza with a type="visible" attribute (see Example 2), or a directed presence stanza to joe@foo.com with a type="visible" attribute as below.
+      ]]>
+    
+    
+      The opposite behavior of the previous section should, also, be present in the server. For example, if a user is invisible to all of their contacts, they should be able to become visible to a selected contact by send a stanza similar to the one in Example 4.
+      As with the previous section, a user can later choose to hide his presence updates for joe@foo.com by either sending an undirected presence stanza (see Example 1), or by sending a directed presence stanza to joe@foo.com (see Example 3).
+    
+  
+  
+    The above section documents the major points of the invisible mode protocol. It is important to understand how the server should interact with the protocol documented above.
+    Normally, when a server receives a presence stanza, it stamps the appropriate 'from' attribute on the stanza and sends it on its way. If the stanza does not possess a 'to' attribute, the process of sending the stanza on its way involves broadcasting that stanza to all contacts listed in the user's roster. If the stanza does have a 'to' attribute, the stanza is simply routed to the correct contact. With the addition of invisible mode presence, the server MUST now verify that a stanza should be directed to contacts on a user's roster before sending it on. In addition, stanzas that are directly related to invisible presence (stanzas with a 'type' attribute of either "visible" or "invisible") MUST NOT be sent to any contacts, but MAY cause other presence stanzas to be sent instead.
+    
+      One of the biggest failings of older invisible mode implementations were client features like auto-away. In most cases, these auto-away stanza would inadvertently cause a user to become visible (although away) to all contacts on its roster. This invisible presence protocol has been designed to deal with that problem elegantly.
+      Consider the following situation (the protocol for which is shown in the examples below):
+      
+        joe@foo.com has contacts stpeter@foo.com, pgmillard@foo.com and rynok@foo.com on his roster.
+        joe@foo.com has logged into the foo.com sever, but has set his presence to invisible.
+        Assume that stpeter@foo.com, pgmillard@foo.com and rynok@foo.com are all online and visible.
+        joe@foo.com wants rynok@foo.com to see his presence updates, but not stpeter@foo.com or pgmillard@foo.com
+        joe@foo.com sets his presence to extended away.
+        joe@foo.com decides to become visible to all contacts on his roster.
+        joe@foo.com decides to become invisible to pgmillard@foo.com.
+        joe@foo.com set his presence to free to chat.
+      
+      ]]>
+      Since joe@foo.com has just come online, the server SHOULD NOT forward any presence stanzas to contacts on his roster.
+      ]]>
+      ]]>
+      xaAway (due to idle)]]>
+      
+    awayMeeting
+]]>
+      Note that in this example, presence updates from joe@foo.com are routed only to rynok@foo.com, despite the fact that stpeter@foo.com and pgmillard@foo.com are both online and available. This is because joe@foo.com has chosen to be visible only to rynok@foo.com. If joe@foo.com chooses to become visible to his entire roster, he simply sends an undirected presence stanza with the type="visible" attribute. In this case the server SHOULD forward the last undirected presence stanza received to stpeter@foo.com and pgmillard@foo.com.
+      ]]>
+      
+
+]]>
+      Now Joe has decided that he doesn't want pgmillard@foo.com to receive further presence updates. Since he is currently visible to all contacts, he simply needs to send a directed presence stanza to pgmillard@foo.com with the type="invisible" attribute set.
+      ]]>
+      In this case, the server will send a directed presence stanza to pgmillard@foo.com with the type="unavailable" attribute set, which indicates to pgmillard@foo.com's client that joe@foo.com has gone "offline."
+      ]]>
+      Further presence updates sent by joe@foo.com will now be forwarded to stpeter@foo.com and rynok@foo.com, and MUST NOT be forwarded pgmillard@foo.com.
+      chat]]>
+      
+    chat
+
+    
+
+    chat
+]]>
+      The server MUST NOT forward presence stanzas containing the type="visible" or type="invisible" attribute to a client.
+    
+  
+  
+    There are no security features or concerns related to this proposal.
+  
+  
+    No interaction with &IANA; is required as a result of this JEP.
+  
+  
+    No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.
+  
+
diff --git a/xep-0019.xml b/xep-0019.xml
new file mode 100644
index 00000000..707eee1e
--- /dev/null
+++ b/xep-0019.xml
@@ -0,0 +1,81 @@
+
+
+%ents;
+]>
+
+
+
+  Streamlining the JIGs
+  This JEP proposes to streamline the existing Jabber Interest Groups (JIGs).
+  &LEGALNOTICE;
+  0019
+  Active
+  Procedural
+  None
+  Board
+  
+  
+  
+  
+    Peter
+    Saint-Andre
+    stpeter@jabber.org
+    stpeter@jabber.org
+  
+  
+    1.0
+    2002-03-20
+    psa
+    Changed status to Active.
+  
+  
+    0.2
+    2002-03-06
+    psa
+    Minor revisions.
+  
+  
+    0.1
+    2002-02-24
+    psa
+    Initial release.
+  
+
+
+  The Jabber Software Foundation is an experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this JEP, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). The proposal contained in this JEP formalizes some conclusions reached during a weekly discussion forum held by the Jabber Software Foundation on 2002-01-23. A log of that discussion is available at http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html. Further discussion within the Standards JIG has been helpful in clarifying the argument presented here.
+
+
+  JEP-0002 URL: http://www.jabber.org/jeps/jep-0002.html defined a JIG as "a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a JIG is to "produce acceptable enhancements to the Jabber protocol (delivered in the form of Jabber Enhancement Proposals or JEPs) within a reasonably limited period of time". In early January of 2002, JEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).
+  Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,See http://www.jabber.org/jigs.html for the official list. eight of them over six months ago in July and August of 2001. Two of the special-purpose JIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose JIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in JEP-0002. Only the two "standing" JIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards JIG has assumed the role of discussion forum for JEPs before they are submitted to the Jabber Council.
+  In perhaps the best measure of success or failure, only one JIG has produced a JEP for submission to the Jabber Council, and that JEP (JEP-0009 URL: http://www.jabber.org/jeps/jep-0009.html for transporting XML-RPC over Jabber) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a JEP, or even starting work on one. With the possible exception of JEP-0009, all of the JEPs created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.
+  In other words, an honest assessment forces us to conclude that the JIGs are not working.
+
+
+  I see several possible solutions to the JIG problem:
+  
+    "Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce JEPs.
+    "Wait and see" -- immediately disband the JIGs that are clearly inactive but keep the existing JIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).
+    "Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to the Jabber protocols.  
+  
+  Given the lack of activity in the JIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing JIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the JIGs and find a better way of working.
+  But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating JEPs, because individually and in small, ad-hoc groups they have created quite a few.
+  I see several reasons why the JIGs are not working:
+  
+    The Jabber community right now is too small to be split up successfully into smaller interest groups.
+    We have tried to overlay too much structure too quickly. Jabber has traditionally been a fairly anarchic project (or set of projects), and creating ten JIGs right away was at odds with that successful lack of structure.
+    Good JEPs, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber forward.
+  
+  If we reflect on what is working, we see that JEPs are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.
+
+
+  My proposed solution takes into account everything we have learned to date about producing JEPs and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:
+  
+    Immediately disband all but the Standards JIG. In an earlier version of this JEP, I proposed that we retain the Security JIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards JIG, not in a separate Security JIG.
+    Rely on individuals and small, ad-hoc groups to create JEPs.
+    Continue to use the Standards JIG as the preferred forum for discussion of experimental JEPs before they are submitted to the Jabber Council.
+    If the Standards JIG cannot reach a working consensus on a given topic, let the JEP author(s) continue to rework their proposal informally outside the context of the Standards JIG. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). Unlike the current JIGs, such a list would be established on the initiative of the JEP author(s) and would not require any formal approval by the Jabber Council.
+  
+  There may be value in bringing back specialized JIGs in the future when the Jabber community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this JEP. Lest there be any concern that disbanding the JIGs is outside the power or purview of the Jabber Council, I note that Section 8.2 of the Bylaws of the Jabber Software Foundation states in part that "The Jabber Council or the Members of the Corporation may, by resolution, ... terminate a Jabber Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)
+
+
diff --git a/xep-0020.xml b/xep-0020.xml
new file mode 100644
index 00000000..f016e8d3
--- /dev/null
+++ b/xep-0020.xml
@@ -0,0 +1,296 @@
+
+
+%ents;
+]>
+
+
+
+  Feature Negotiation
+  This JEP defines a A protocol that enables two Jabber entities to mutually negotiate feature options.
+  &LEGALNOTICE;
+  0020
+  Draft
+  Standards Track
+  Standards JIG
+  
+    XMPP Core
+    JEP-0004
+  
+  
+  
+  feature-neg
+  
+    http://jabber.org/protocol/feature-neg/feature-neg.xsd
+  
+  &pgmillard;
+  &stpeter;
+  
+    1.4
+    2004-05-21
+    psa
+    Moved remaining feature negotiation text from JEP-0030 to this document.
+  
+  
+    1.3
+    2004-04-23
+    psa
+    Per Council discussion, changed root element from <query/> to <feature/> for the sake of consistency with using protocols; moved some text from JEP-0030 to this document.
+  
+  
+    1.2
+    2004-03-08
+    psa
+    Added XMPP error handling; clarified the text; corrected the examples; fixed an error in the schema; added numerous references.
+  
+  
+    1.1
+    2003-02-16
+    psa
+    Made corrections to the text; added security and IANA considerations; added schema.
+  
+  
+    1.0
+    2002-12-06
+    psa
+    Per a vote of the Jabber Council, revision 0.4 was advanced to Draft on 2002-12-06.
+  
+  
+    0.4
+    2002-11-17
+    pgm
+    Changed protocol to use jabber:x:data.
+  
+  
+    0.3
+    2002-10-01
+    pgm
+    Added some extra text to help clarify protocol & purpose.
+  
+  
+    0.2
+    2002-05-22
+    pgm
+    Changed examples.
+  
+  
+    0.1
+    2002-02-26
+    pgm
+    Initial version.
+  
+
+
+  A discovery protocol such as &jep0030; enables Jabber entities to query other entities regarding the features they support, but does not provide a means for the two entities to negotiate specific options related to the advertised features (e.g., specific methods of file transfer such as &jep0047; or &jep0065;).
+  The protocol defined herein enables Jabber entities to negotiate options for specific features. These features could be negotiated between any two endpoints on the Jabber network, such as two clients, a client and a component, two components, a client and a server, or two servers. The protocol is generic enough that it can be used whenever options need to be negotiated between two Jabber entities.
+
+
+  Features are negotiated though the exchange of &IQ; stanzas containing &QUERY; child elements qualified by the 'http://jabber.org/protocol/feature-neg' namespace. However, this &QUERY; element is simply a wrapper for structured data encapsulated in the &jep0004; protocol. Earlier versions of this JEP defined an structured data format to handle the feature negotiation workflow; versions later than 0.4 use Data Forms, i.e., the 'jabber:x:data' namespace.
+  In order to begin a negotation, the initiator sends an &IQ; stanza of type "get" to the recipient with a single <feature/> element containing a data form of type "form" which defines the available options for one or more features. Each feature is represented as an x-data "field", which MUST be of type "list-single" as specified in JEP-0004.
+  The recipient SHOULD examine each feature and the options provided. In order to indicate preferred options, the recipient then SHOULD specify one option for each feature and return a data form of type "submit" to the initiator in an &IQ; stanza of type "result".
+  The following examples show some likely scenarios for feature negotiation between entities. Further examples can be found in using protocols, such as &jep0096;.
+  
+    A typical negotiation flow is shown in the following example of two entities negotiating the time and place for a meeting.
+    
+  
+    
+      
+         
+         
+         
+      
+      
+         
+         
+         
+         
+      
+    
+  
+
+    ]]>
+    
+  
+    
+      
+        Secret Grotto
+      
+      
+        22:30
+      
+    
+  
+
+    ]]>
+    If the responding entity does not support one or more of the features, it MUST return a &feature; error, and SHOULD specify the feature(s) not implemented in the XMPP <text/> element.
+    
+  
+    
+    times-to-meet
+  
+
+    ]]>
+    If the responding entity supports none of the options offered for a certain feature, it MUST return a ¬acceptable; error, and SHOULD specify the relevant feature in the XMPP <text/> element.
+    
+  
+    
+    places-to-meet
+  
+
+    ]]>
+  
+  
+    If at least one feature offered by an entity is subject to &jep0020;, the entity's response to a service discovery information request MUST include <feature var='http://jabber.org/protocol/feature-neg'/> as one of the features.
+    
+  
+]]>
+    
+  
+    ...
+    
+    
+    ...
+  
+]]>
+    The using protocol (in these examples, &jep0045;) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the Jabber Registrar. However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.
+    
+  
+]]>
+    
+  
+    ...
+    
+    
+    ...
+  
+]]>
+    The using protocol (in these examples, JEP-0045) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the Jabber Registrar (see <http://www.jabber.org/registrar/disco-vars.html>). However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.
+    
+  
+    
+      
+    
+  
+]]>
+    If that feature is not negotiable, the responding entity MUST return a "Feature Not Implemented" error:
+    
+  
+    
+      
+        
+        
+        
+      
+    
+  
+  
+    
+  
+]]>
+    If that feature is negotiable, the responding entity MUST return an appropriate negotiation form:
+    
+  
+    
+      
+        
+        
+        
+      
+    
+  
+]]>
+    The requesting entity MAY then submit a data form containing the required information.
+  
+
+
+
+  Security considerations are the responsibility of the using protocol.
+
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+
+  In order for Jabber entities to adequately leverage Data Forms (e.g., by using machine-readable fields), it is RECOMMENDED to register standard x-data fields with the ®ISTRAR; via the mechanisms defined in &jep0068;. Whether to do so for any given features and options shall be determined by the using protocol.
+
+
+
+  
+
+
+
+  
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0020: http://www.jabber.org/jeps/jep-0020.html
+    
+  
+
+  
+    
+      
+        
+      
+    
+
+
+  ]]>
+
+
+  Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining author is thankful for Peter's work on this specification.
+
+
diff --git a/xep-0021.xml b/xep-0021.xml
new file mode 100644
index 00000000..86721741
--- /dev/null
+++ b/xep-0021.xml
@@ -0,0 +1,343 @@
+
+
+%ents;
+]>
+
+
+
+
+
+  Jabber Event Notification Service (ENS)
+  A generic publish-and-subscribe service for Jabber.
+  &LEGALNOTICE;
+  0021
+  Retracted
+  Standards Track
+  Standards
+  None
+  JEP-0060
+  None
+  
+    Robert
+    Norris
+    rob@cataclysm.cx
+    rob@cataclysm.cx
+  
+  
+    0.2
+    2003-04-22
+    psa
+    At the request of the author, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.1
+    2002-03-04
+    rn
+    Initial version
+  
+
+
+
+  The Jabber Event Notification Service (ENS) acts as a dispatcher and may be used by applications as a central point of collection for certain types of events that are of interest to them. Examples of events include:
+
+  
+   User has logged in
+   A new message has arrived
+   User's avatar has changed
+   The coffee machine is empty
+  
+  
+  In Jabber, the role of the ENS has traditionally been filled by overloading the <presence/> packet type. However, this method was never designed to be used as a general publish-and-subscribe mechanism, and so has the following problems:
+
+  
+   Dispatching of <presence/> packets is performed by the JSM (Jabber Session Manager), and so is not easily usable by components and other entities that don't connect via a client manager (c2s, CCM).
+   An entity cannot subscribe to the presence of a specific resource of another entity, only to any presence from that entity. This lack of granularity makes its difficult to use <presence/> in situations where large chunks of data must be dispatched to subscribers (eg avatars).
+  
+  
+  The protocol consists of two parts - the subscriber-to-ENS protocol, and the publisher-to-ENS protocol. Since there is no direct interaction between a publisher and a subscriber, it makes sense to seperate the two parts of the protocol.
+
+  The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.
+
+  A reference implementation is available at http://cataclysm.cx/jabber/ens.html.
+
+
+
+  Before we begin describing the protocol, is it necessary to define some terms, including the function and responsibilties of the entities that communicate with the ENS.
+
+  
+    An event can be defined as a change to the value of one or more properties of a resource.
+
+    In the ENS, an event type is referred to by a JID (Jabber IDentifier), including the JID resource. For example, consider a hypothetical publisher that is linked to an IMAP message store. It might notify the ENS of the fact the a message has arrived, deleted, or filed, using the following JIDs:
+
+    
+      rob@imap.cataclysm.cx/NewMessage
+      joe@imap.cataclysm.cx/DeletedMessage
+      jim@imap.cataclysm.cx/FiledMessage
+    
+
+    Alternatively, an end-user client that wanted to notify the ENS when its avatar changes might do so using a JID like "rob@cataclysm.cx/avatar"
+  
+
+  
+    A subscriber is a Jabber entity that receives notifications about events. Usually, a subscriber will be an end-user client, but it may be any Jabber entity.
+
+    As the name suggests, a subscriber can subscribe and unsubscribe to various events via the ENS. When it subscribes, the publisher responsible for the event it is subscribing to will be asked by the ENS to authorise the subscription request. To facilitate this, the subscriber may provide an XML fragment containing information that the publisher can use to authorise it. The use of this fragment is application specific.
+    
+
+    Once subscribed to an event, the subscriber will receive any notifications that the publisher sends about that event.
+  
+
+  
+    A publisher is the Jabber entity responsible for actually sending event notifications to the ENS. A notification contains the event type JID of the event that occured, and an optional "payload" XML fragment, that is passed untouched by the ENS to the subscriber. The contents of this payload is application-specific and can be used to provide detailed information about the event to the subscriber. For example, in the case of the NewMessage event above, the payload might contain the contents of the To:, From: and Subject: headers of the message.
+
+    Additionally, the publisher is responsible for deciding who may subscribe to events it publishes. When the ENS receives a subscription request, it will ask the publisher to decide whether or not the subscriber may subscribe to a particular event. This authorisation request may also contain an XML fragment from the subscriber containing information that may be used for authorisation.
+  
+
+
+
+
+
+  
+    To subscribe to a particular event, the subscriber sends a packet like of the following form to the ENS:
+
+    
+<iq id='sub1' type='set' from='subscriber-jid' to='ens-jid'>
+  <subscribe xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+</iq>
+    
+
+    
+      The subscriber may include an <auth-info/> XML fragment containing some (application-specific) information that the publisher can use to authorise it:
+
+      
+<iq id='sub2' type='set' from='subscriber-jid' to='ens-jid'>
+  <subscribe xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'>
+    <auth-info xmlns='jabber:iq:auth'>password</auth-info>
+  </subscribe>
+</iq>
+      
+    
+
+    
+      If it wishes, the subscriber may request a "reliable" subscription. This option guarantees that the subscriber will receive all notifications about this event (as far as the Jabber architecture guarantees delivery). This changes the semantics of the subscriber publish protocol - see section 3.6 for more details.
+
+      
+<iq id='sub2' type='set' from='subscriber-jid' to='ens-jid'>
+  <subscribe xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'>
+    <reliable/>
+  </subscribe>
+</iq>
+      
+    
+
+  
+
+  
+    Once subscribed, the ENS will return a packet of the following form to the subscriber:
+
+    
+<iq id='sub1' type='result' from='ens-jid' to='subscriber-jid'>
+  <subscribed xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+</iq>
+    
+
+    If an error occured during subscription (such as the publisher not allowing the subscriber to subscribe), an error packet will be returned to the subscriber:
+
+    
+<iq id='sub1' type='error' from='ens-jid' to='subscriber-jid'>
+  <subscribe xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+  <error code='401'>Unauthorized</error>
+</iq>
+    
+
+    The actual error fragment in the packet is a direct copy of the one returned by the publisher when it fails the authorisation request from the ENS. If the publisher does not provide one, error code 503 (Service Unavailable) will be returned instead. If the publisher does not respond to the authorisation request (after an implementation-specific timeout), error code (Remote Server Timeout) will be returned.
+  
+
+  
+    To unsubscribe from a particular event, the subscriber sends a packet like of the following form to the ENS:
+
+    
+<iq id='unsub1' type='set' from='subscriber-jid' to='ens-jid'>
+  <unsubscribe xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+</iq>
+    
+  
+
+  
+    Once unsubscribed, the ENS will return a packet of the following form to the subscriber:
+
+    
+<iq id='unsub1' type='result' from='ens-jid' to='subscriber-jid'>
+  <unsubscribed xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+</iq>
+    
+
+    No further notifications for the event will be received.
+  
+
+  
+    When a publisher publishes a notification to the ENS, the ENS will forward the notification to any subscribers for that event. A notification sent to a subscriber takes the following form:
+
+    
+<iq id='enspub1' type='set' from='ens-jid' to='subscriber-jid'>
+  <publish xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'/>
+</iq>
+    
+
+    A notification may also contain a (application-specific) "payload" XML fragment:
+    
+    
+<iq id='enspub2' type='set' from='ens-jid' to='subscriber-jid'>
+  <publish xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'>
+    <xml-payload/>
+  </publish>
+</iq>
+    
+
+    Section 4.1 has more information about the payload.
+
+    If the subscriber responds to the notification with an error, the subscriber will be automatically unsubscribed from the event by the ENS.
+  
+
+  
+    If the <reliable/> option was specified when the subscriber subscribed to the event, then the subscriber is expected to acknowledge a notification with a packet of the following form:
+
+    
+<iq id='enspub1' type='result' from='subscriber-jid' to='ens-jid'>
+  <published xmlns='http://xml.cataclysm.cx/jabber/ens/'/>
+</iq>
+    
+
+    If the subscriber does not respond, or responds with an error, the notification will be resent by the ENS after a (implementation-specific) timeout.
+  
+
+
+
+  
+    To publish a notification, the publisher sends a packet of the following form to the ENS:
+
+    
+<iq id='pub1' type='set' from='event-jid' to='ens-jid'>
+  <publish xmlns='http://xml.cataclysm.cx/jabber/ens/'/>
+</iq>
+    
+
+    A notification may also contain a (application-specific) "payload" XML fragment:
+    
+    
+<iq id='pub1' type='set' from='event-jid' to='ens-jid'>
+  <publish xmlns='http://xml.cataclysm.cx/jabber/ens/'>
+    <xml-payload/>
+  </publish>
+</iq>
+    
+
+    The payload can be any well-formed XML data. Everything inside the <publish/> tag will be forwarded untouched to the subscriber.
+  
+
+  
+    Once the ENS has dispatched the notification to subscribers, it will return a packet of the following form to the publisher:
+
+    
+<iq id='pub1' type='result' from='ens-jid' to='event-jid'>
+  <published xmlns='http://xml.cataclysm.cx/jabber/ens/'/>
+</iq>
+    
+  
+
+  
+    A publisher is required to approve subcription requests. When a subscriber attempts to subscribe to an event, the publisher will receive a packet of the following form from the ENS:
+
+    
+<iq id='ensauth1' type='get' from='ens-jid' to='event-jid'>
+  <authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/>
+</iq>
+    
+
+    The subscriber may include an <auth-info/> XML fragment containing some (application-specific) information that the publisher can use to authorise it:
+    
+    
+<iq id='ensauth1' type='get' from='ens-jid' to='event-jid'>
+  <authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'>
+    <auth-info xmlns='jabber:iq:auth'>password</auth-info>
+  </authorise>
+</iq>
+    
+
+  
+
+  
+    To signal to the ENS that a subscriber should be allowed to subscribe, the publisher should return a packet of the following form:
+    
+    
+<iq id='ensauth1' type='result' from='event-jid' to='ens-jid'>
+  <authorised xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/>
+</iq>
+    
+
+    To deny the subscription, the publisher should return an error packet, containing the appropriate <error/> fragment:
+
+    
+<iq id='ensauth1' type='error' from='event-jid' to='ens-jid'>
+  <authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/>
+  <error code='401'>Unauthorized</error>
+</iq>
+    
+
+    The <error/> fragment will be copied untouched into the error response sent back to the subscriber. See section 3.2 for more details.
+  
+
+
+
+  The ENS will respond with error code 400 (Bad Request) any time it receives a request that it cannot understand (a malformed packet, for example).
+
+  Other errors may occur, and they are described in the appropriate sections of the above protocol specification.
+
+
+
+  The following items should be discussed before this proposal is approved by the Council:
+
+  
+    The ENS, as described, works well. However, no provisions are made for a subscriber to find out which ENS a publisher is publishing to. It does a subscriber no good to subscribe to an event on the wrong ENS - the subscription would succeed (assuming the publisher allows it), but no notifications would ever be received.
+
+    There are several potential solutions, each with their problems:
+
+    
+      Leave it to the subscriber to find the appropriate ENS outside of the ENS framework itself. This might be via a browse to the publisher, or maybe just entering it into their client's configuration. Obviously, this is very application-specific.
+      Force the publisher to publish to multiple ENSs, as necessary. This would require additions to the protocol (to tell the publisher of new ENSs), and would require the publisher to maintain a list of JIDs it needs to publish to. This solution is pointless - if the publisher is going to publish to multiple JIDs and maintain its own list, it might as well publish direct to subscribers.
+      Have some sort of ENS-to-ENS protocol, and have ENSs proxy publishes for other ENSs. This does not fix the problem, it just moves it away from the subscriber and into the ENS. An ENS will still need to find out which ENS the publisher is publishing to.
+      Integrate ENS into the session manager. This leaves us with a glorified presence system, and makes the ENS basically unusable by non-session-manager-based server components.
+    
+    
+    This problem may be outside of the scope of this specification.
+  
+
+  
+    Currently, if a subscriber obtains a reliable subscription, and then disappears from the network (as an end-user client might), the ENS will continue to send notifications to it (ignoring errors) until it unsubscribes. If the subscriber never comes back, then ENS will send notifications forever (in theory).
+
+    At what point should even <reliable/> have its limits? Should we unsubscribe a reliable subscriber who bounces (ie. the Jabber server failed to deliver) more than, say, 10 publishes? Or maybe they should be unsubscribed if they do not respond (as in section 3.6) to anything for, say, 10 minutes?
+
+    <reliable/> is an interesting idea, but it may be that it is too problematic for its own good.
+  
+
+  
+    The topic of reliable subscriptions raises the question as to how long a subscription lasts. Should a subscription last forever (like <presence/> does), even across restarts of the server?
+
+    If end-user clients are to be subscribers, then under this scheme the ENS would have to subscribe to presence, so as to know when the client has disconnected. Since presence is a function of the session manager, this could have the effect of making the ENS less generic that we may like.
+  
+
+  
+    As I see it, basic presence will always be a function of the session manager, for the following reasons:
+
+    
+      No ENS discovery problems
+      Subscriptions are maintained across sessions
+      In very widespread use (ie. everywhere)
+    
+
+    I think the places where the ENS can boom will be in applications like avatars, and genuine event-based systems (like the kind described above - "you have new mail", "someone has scheduled a meeting with you in your online calendar", etc).
+  
+
+
+
diff --git a/xep-0022.xml b/xep-0022.xml
new file mode 100644
index 00000000..0f1feceb
--- /dev/null
+++ b/xep-0022.xml
@@ -0,0 +1,321 @@
+
+
+%ents;
+]>
+
+
+
+  Message Events
+  This JEP defines protocol extensions used to request and respond to events relating to the delivery, display, and composition of messages.
+  &LEGALNOTICE;
+  0022
+  Active
+  Historical
+  Standards JIG
+  
+    XMPP Core
+  
+  
+  
+  x-event
+  
+    http://jabber.org/protocol/x-event/x-event.xsd
+  
+  &jer;
+  
+    DJ
+    Adams
+    dj.adams@pobox.com
+    dj@gnu.mine.nu
+  
+  &stpeter;
+  
+    1.3
+    2004-01-06
+    psa
+    Added XML schema.
+  
+  
+    1.2
+    2003-02-11
+    psa
+    Attempted to clarify usage and business rules.
+  
+  
+    1.1
+    2003-01-26
+    psa
+    Added more detailed information and clarified a few points.
+  
+  
+    1.0
+    2002-05-08
+    psa
+    Changed status to Active.
+  
+  
+    0.2
+    2002-03-13
+    dja
+    Minor corrections and additions.
+  
+  
+    0.1
+    2002-03-05
+    dja
+    Initial draft.
+  
+
+
+
+  The 'jabber:x:event' namespace defines extensions used to request and respond to events relating to the delivery, display, and composition of messages.
+  By attaching a jabber:x:event extension to a &MESSAGE; element, the sender can track stages in the delivery of that message to its recipient.
+
+
+
+  There are four message events currently defined in this namespace:
+
+  
+    Indicates that the message has been stored offline by the intended recipient's server. This event is triggered only if the intended recipient's server supports offline storage, has that support enabled, and the recipient is offline when the server receives the message for delivery.
+  
+
+  
+    Indicates that the message has been delivered to the recipient. This signifies that the message has reached the recipient's Jabber client, but does not necessarily mean that the message has been displayed. This event is to be raised by the Jabber client.
+  
+
+  
+    Once the message has been received by the recipient's Jabber client, it may be displayed to the user. This event indicates that the message has been displayed, and is to be raised by the Jabber client. Even if a message is displayed multiple times, this event should be raised only once.
+  
+
+  
+    In threaded chat conversations, this indicates that the recipient is composing a reply to a message. The event is to be raised by the recipient's Jabber client. A Jabber client is allowed to raise this event multiple times in response to the same request, providing the original event is cancelled first.
+  
+
+
+
+
+  Extensions qualified by the jabber:x:event namespace may be used only in the context of &MESSAGE; elements. That is, event information should be requested, and given in response, in relation to &MESSAGE; elements only, and not &PRESENCE; or &IQ; elements.
+  Event information should only be sent in response to a request for that information. Unsolicited event information is illegal. In addition, a client should not request message event information from a correspondent if it is known (for example through the results of a previous browse request) that the correspondent does not support message events.
+  Any request for the offline event in a message that has been stored offline must be removed by the server before the message is forwarded to the Jabber client. This means that any <offline/> tag should be removed from the extension.
+
+  
+  Event notifications are requested by attaching an extension qualified by the jabber:x:event namespace to a &MESSAGE; element. A tag representing each event type requested for that message should be placed within the extension. Only one jabber:x:event extension may be attached to a &MESSAGE; element, but multiple event types may be requested within that one extension. The tags representing each of the event types are <offline/>, <delivered/>, <displayed/>, and <composing/>.
+  An example of a &MESSAGE; element with a jabber:x:event extension is shown here.
+  
+  Art thou not Romeo, and a Montague?
+  
+    
+    
+    
+  
+
+  ]]>
+  Here we see the sender wants to be notified if the message is stored offline (by the server), notified when the message is delivered (to the client), and notified if the recipient begins replying to the message. In this case, the sender will potentially receive three events based on this request.  The first if the recipient is offline and the message is stored on the server, the second when the recipient becomes available and the message is delivered, and the third if the recipient begins composing a reply to the message.
+  Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.
+  
+
+  
+  If the message is stored by the server, the server must raise the requested event (offline) by sending a message to the sender as shown in this example:
+  
+  
+    
+    message22
+  
+
+  ]]>
+  When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:
+    
+      The element must contain only a jabber:x:event extension. Standard message elements such as <subject/>, <body/>, MUST NOT be included.
+      The extension must contain one tag representing the event being raised.  For example, if the offline event is being raised, an <offline/> tag must be included. (The events are temporally exclusive, thus only one event tag should ever be included.)
+      The extension must also contain an <id/> tag. The contents of this tag MUST be the value of the 'id' attribute of the original message to which this event notification pertains. (If no 'id' attribute was included in the original message, then the <id/> tag must still be included with no CDATA.)
+      The message's from attribute should be set to the recipient of the original message for which the event is being raised. (This is an issue more relevant for the server, in responding to the offline event, because clients should rely on the server to stamp the elements that they send out with a from attribute.)
+      The link between the original message for which the event is being raised, and the message containing that raised event, is the <id/> tag in the jabber:x:event extension of the message containing that raised event, that points to the id attribute of the original message.
+    
+  
+
+  
+  The composing event is slightly different from the other events in that it can be raised and cancelled multiple times. This is to allow the reflection of what actually is happening when a user replies to a message; he may start composing a reply, which would trigger the composing event, get halfway through, and stop (by some definition of "stop", which may be implementation-specific). At this stage the event is no longer valid, or at least doesn't make much sense. So the client may send a cancellation for the composing event just raised.
+  The cancellation is raised by sending another jabber:x:event; however, in contrast to how the events are usually raised, no <composing/> tag is sent, just an <id/> tag, like this:
+  
+  
+    
+    message22
+  
+
+  ]]>
+  
+  
+    message22
+  
+
+  ]]>
+  The lack of an <composing/> tag (and any other event tag) signifies that the composing event, indicated previously by the id value, has been cancelled. In this example, the composing event being cancelled is that event that was previously raised with the id of message22.  After cancelling a composing event, a new one may be raised, following the same rules as before, when the typing of the reply is resumed.
+  
+
+
+
+  This section contains a number of examples to illustrate the full flow of messages, event notifications, and event cancellations for a fictional conversation.
+  
+      Art thou not Romeo, and a Montague?
+      
+        
+        
+        
+        
+      
+    
+  ]]>
+  Romeo temporarily loses his wireless connection in the Capulet's orchard and therefore his message is stored offline by the montague.net server, which generates the offline event and sends that notification to Juliet.
+  
+      
+        
+        message22
+      
+    
+  ]]>
+  Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.
+  
+      
+        
+        message22
+      
+    
+  ]]>
+  Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.
+  
+      
+        
+        message22
+      
+    
+  ]]>
+  Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.
+  
+      
+        
+        message22
+      
+    
+  ]]>
+  Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.
+  
+      
+        message22
+      
+    
+  ]]>
+  Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.
+  
+      
+        
+        message22
+      
+    
+  ]]>
+  Romeo finally sends his reply, and requests composing events related to it.
+  
+      Neither, fair saint, if either thee dislike.
+      
+        
+      
+    
+  ]]>
+
+
+
+  Compliant implementations SHOULD observe the following business rules:
+  
+    Every outgoing message sent from a compliant client should contain a request for event notifications (if such notifications are desired). The request for notifications cannot be sent just once in a conversation, since it applies to every message sent.
+    When a client receives a request for events from another entity, it should cache the most recent ID.
+    When a user begins replying to a message received from a contact, the user's client should check to see whether events have been requested by the contact for that message and set the CDATA of the <id/> element to the cached ID value.
+    The CDATA of the <id/> element MUST be the same as the value of the 'id' attribute of the notification request.
+  
+
+
+
+  There are no security features or concerns related to this proposal.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:x:event' is already a registered protocol namespace.
+
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0022: http://www.jabber.org/jeps/jep-0022.html
+    
+  
+
+  
+    
+      
+        
+        
+        
+        
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+    ]]>
+
+
+
+  
+    In a Standards Track JEP addressing event functionality, it would be desirable to have more cancellation methods for composing events than those defined in this Informational JEP. For instance, is someone still composing if they become unavailable? This example points to the fact that cancellation of a composing event can either be explicit (the default or desired scenario) or implicit (e.g., through a change in the availability state of a client or the existence of the session associated with the message composition).
+  
+
+
+
diff --git a/xep-0023.xml b/xep-0023.xml
new file mode 100644
index 00000000..a8618d43
--- /dev/null
+++ b/xep-0023.xml
@@ -0,0 +1,175 @@
+
+
+%ents;
+]>
+
+
+
+  Message Expiration
+  This JEP documents an historical protocol that was used to specify expiration dates for messages; this protocol has been deprecated in favor of JEP-0079: Advanced Message Processing.
+  &LEGALNOTICE;
+  0023
+  Deprecated
+  Historical
+  Standards JIG
+  
+    XMPP Core
+  
+  
+  
+    JEP-0079
+  
+  x-expire
+  
+    http://jabber.org/protocol/x-expire/x-expire.xsd
+  
+  &jer;
+  
+    DJ
+    Adams
+    dj.adams@pobox.com
+    dj@gnu.mine.nu
+  
+  
+    Harold
+    Gottschalk
+    heg@imissary.com
+    heg@imissary.com
+  
+  
+    1.2
+    2004-10-18
+    psa
+    Per a vote of the Jabber Council, changed status to Deprecated since message expiration functionality should be implemented via JEP-0079: Advanced Message Processing.
+  
+  
+    1.1
+    2004-01-06
+    psa
+    Added XML schema; added security, IANA, and Jabber Registrar considerations.
+  
+  
+    1.0
+    2002-07-15
+    psa
+    Changed status to Active.
+  
+  
+    0.9
+    2002-03-19
+    dja
+    Added remarks about client-end expiry.
+  
+  
+    0.1
+    2002-03-07
+    dja
+    Initial draft.
+  
+
+
+
+  Note Well: The protocol described herein has been deprecated by the &JSF;. The recommended protocol for implementing message expiration functionality is now &jep0079;.
+  It is sometimes helpful to indicate that a piece of information has a finite useful life or time-to-live (TTL). In the context of instant messaging, the main use of a TTL is to indicate that a message must or should be used by or read by a certain time, usually because the message has meaning or purpose only within a finite amount of time. In normal usage, such a message should be discarded after the specified time has passed if it has not been used or read by that time.
+  In Jabber, TTL functionality has been implemented informally using the jabber:x:expire namespace. Support for this namespace was added to the &jabberd; server as well as some clients and components in early 2001. Specifically, that support has involved the following two areas of responsibility:
+  
+    The sender of the message is responsible for attaching a jabber:x:expire extension to the XML stanza (usually a message).
+    Mechanisms involved in the store-and-forward of such a stanza
+The best-known example of a mechanism that handles storing and forwarding of XML stanzas is the Jabber Session Manager (JSM) within current Jabber server implementations, specifically the mod_offline module. However, expiration of an XML stanza could also be handled by a Jabber client.
+en route to its intended recipient are responsible for checking the remaining time to live and expiring (discarding) the XML stanza if necessary.
+  
+
+
+
+  An Endpoint can specify a TTL for an XML stanza that it wishes to send by attaching an <x/> extension qualified by the jabber:x:expire namespace. The extension contains no children, only a 'seconds' attribute that contains a value representing the stanza's TTL, in seconds.
+
+  
+SEND: <message to='sabine@gnu.mine.nu' id='msg811'>
+        <subject>Eccles cakes!</subject>
+        <body>
+          I've got some freshly made Eccles cakes here, come
+          round for one before they all disappear!
+        </body>
+        <x xmlns='jabber:x:expire' seconds='1800'/>
+      </message>
+  
+
+
+
+  Any mechanism that is involved in the storage, forwarding, and general handling of XML stanzas must check for the presence of such an extension and act accordingly, expiring (discarding) any stanzas that have exceeded their TTL lifetime.  The jabber:x:expire namespace allows for a further attribute inside the <x/> extension: 'stored'. Here, the mechanism can record a value representing when the stanza was committed to storage, so that when the stanza is eventually retrieved for forwarding to the intended recipient, the elapsed time of storage can be calculated. This is to prevent the stanza from being held in 'suspended animation'.
+  Here we see what the original message looks like after the stanza has been committed to storage and the time of storage recorded:
+  
+SEND: <message to='sabine@gnu.mine.nu' id='msg811'>
+        <subject>Eccles cakes!</subject>
+        <body>
+          I've got some freshly made Eccles cakes here, come
+          round for one before they all disappear!
+        </body>
+        <x xmlns='jabber:x:expire'
+           seconds='1800'
+           stored='912830221'/>
+      </message>
+  
+  When Sabine attempts to retrieve her offline messages, the store-and-forward mechanism (e.g., mod_offline) compares the current time against the stored attribute. If the 1800 seconds have passed, the mechanism should simply drop the message, without notifying either the sender or the intended recipient. No Eccles cakes for Sabine!
+
+  Although current usage of jabber:x:expire is most commonly seen in server implementations to address any TTL requirements of stored messages, Jabber clients can also be seen as handlers of messages that may contain expiration extension information. If a message is received by a Jabber client, and not immediately displayed to the user, the client must check for TTL information and expire the message (rather than display it to the user) if appropriate.
+
+
+
+
+  There are no security features or concerns related to this proposal.
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:x:expire' is already a registered protocol namespace.
+
+
+
+  
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0023: http://www.jabber.org/jeps/jep-0023.html
+    
+  
+
+  
+    
+      
+        
+          
+          
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+    ]]>
+
+
+
+  
+    The jabber:x:expire namespace is processed only for delayed messages and only by servers and subsystems which support this informational draft. Therefore it is possible or even likely that a TTL will not be properly handled from the user perspective.
+    A physical, time-based TTL is not implemented by this JEP, and would not be possible across systems without synchronized time.
+  
+
+
+
diff --git a/xep-0024.xml b/xep-0024.xml
new file mode 100644
index 00000000..75cf8ef1
--- /dev/null
+++ b/xep-0024.xml
@@ -0,0 +1,1132 @@
+
+
+%ents;
+]>
+
+
+
+  Publish/Subscribe
+  A publish--subscribe protocol for Jabber. 
+  This document has been placed in the public domain.
+  0024
+  Retracted
+  Standards Track
+  Standards
+  None
+  JEP-0060
+  None
+  
+    DJ
+    Adams
+    dj.adams@pobox.com
+    dj@gnu.mine.nu
+  
+  
+    Piers
+    Harding
+    piers@ompa.net
+    piers@gnu.mine.nu
+  
+  
+    0.2
+    2003-04-22
+    psa
+    At the request of the authors, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.1
+    2002-03-05
+    dja
+    Initial draft.
+  
+
+
+
+
+Pubsub ("publish/subscribe") is a technique for coordinating the efficient
+delivery of information from publisher to consumer. This specification
+An earlier draft of this specification can be found at http://www.pipetree.com/testwiki/JabberPubsubSpec.
+describes the use of pubsub within a Jabber context and is a result of
+two separate but related goals:
+
+
+
+to be able to exchange information _within_ a Jabber environment
+(for example continuously changing personal information between users)
+to be able to exchange information _using_ Jabber as a mechanism for
+
+organising that exchange
+providing transport for the information
+
+
+
+
+
+The specification details the use of the Jabber protocol elements and
+introduces a new namespace, jabber:iq:pubsub. 
+It also includes notes on actual implementation of such a
+mechanism in Jabber.
+
+
+
+
+
+
+
+It's clear that as Jabber is deployed over a wider spectrum of platforms
+and circumstances, more and more information will be exchanged. Whether
+that information is specific to Jabber (JSM) users, or components, we need
+an mechanism to be able to manage the exchange of this information in an
+efficient way. 
+
+
+
+For example, it is currently the trend to embed information about a
+particular client's circumstance inside presence packets, either in the
+<status/> tag or in an <x/> extension. One example that comes
+to mind is "song currently playing on my MP3 player" (to which I have to
+admit some responsibility for the meme in the first place). While embedding
+information inside presence packets and having that information diffused to
+the users who are subscribed to that user's presence has the desired effect,
+it has a couple of non-trivial drawbacks:
+
+
+
+the diffusion is inefficient, sending potentially huge amounts of data
+to recipients who aren't interested
+the distribution is tied to closely to presence subscription; any entity
+that wants to receive information must be subscribed to the source's presence,
+and there is no mechanism for specifying _what_ information they wish to
+receive. It is also arguably too closely tied to the JSM to be useful for
+_component_-based information exchange.
+
+
+
+This is above and beyond the simple fact that this overloading of presence
+packets and the presence subscription and diffusion mechanism can only end
+in tears.
+
+
+
+It would be far better to have a separate (sub-)protocol that enabled
+entities to take part in publish/subscribe relationships, and have a service
+that facilitated the efficient exchange of information. Not only would it
+relax the undue pressure on the presence mechanism, but it would also allow
+people to use Jabber, which is, after all, about exchanging structured content
+between endpoints, as a publish/subscribe _mechanism_ in its own right.
+
+
+
+This specification describes a publish/subscribe protocol in terms
+of IQ packets with payload data in a new namespace, jabber:iq:pubsub. The
+choice for this namespace is slightly arbitrary - it was the same namespace
+used in temas's original document, seems to fit well, and we need a namespace
+to focus on.It may well be that we will move to a URI-based namespace
+in the form of a URL pointing to this specification.
+
+
+
+The aim of the specification is to provide for a facility where Jabber
+entities can subscribe to (consume) and publish (emit) information in an
+efficient and organised way. These entities could be JSM users or components.
+
+
+
+Push technology is back with a vengeance. Jabber can play a fundamental
+part.
+
+
+
+
+
+
+
+The pubsub services will be typically provided by a component. In what
+follows, there are generally three parties involved:
+
+
+
+the subscriber
+the pubsub service
+the publisher
+
+
+
+Bear in mind that it is perfectly possible for a subscriber to be a
+publisher, and a publisher to be a subscriber, too.
+
+
+
+The pubsub traffic will be carried in info/query (IQ) packets. All of the
+data in these packets will be qualified by the jabber:iq:pubsub namespace.
+
+
+
+Pubsub scenarios can be seen in a subscribe (or unsubscribe) context or a
+publish context. In light of this, we will examine the IQ packets
+used in these contexts.
+
+
+
+
+
+A potential consumer, or recipient, of published information, needs to
+request that he be sent that published information. Requesting to receive,
+or be pushed, information is known as subscribing.
+
+
+
+A subscription request generally takes this form:
+
+
+
+SEND: <iq type='set' from='subscriber' to='pubsub' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe [to='publisher']>
+            [<ns>namespace:1</ns>
+             <ns>namespace:2</ns>
+             ...
+             <ns>namespace:N</ns>]
+          </subscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' to='subscriber' from='pubsub' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe [to='publisher']>
+            [<ns>namespace:1</ns>
+             <ns>namespace:2</ns>
+             ...
+             <ns>namespace:N</ns>]
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+Note - sections inside [...] are optional.
+
+
+
+
+
+Subscriptions can be specific to a publisher, in which case a to attribute
+is specified in the <subscribe/> tag:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+In this case, the namespaces specified will be added to any existing list
+of namespaces already recorded for that subscriber:publisher relationship.
+In other words, it's a relative, not an absolute, subscription request.
+
+
+
+It is also possible in a publisher-specific subscription to omit specific
+namespaces, if you want to be sent everything that particular publisher
+might publish:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'/>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'/>
+        </query>
+      </iq>
+
+
+
+This type of subscription should have the effect of absolutely replacing any
+previous namespace-specific subscription to the publisher specified.
+
+
+
+If a subscriber wishes to cancel a subscription from a particular publisher,
+he can send an unsubscribe like this:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe to='publisher'>
+            <ns>namespace:1</ns>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe to='publisher'>
+            <ns>namespace:1</ns>
+        </query>
+      </iq>
+
+
+
+This should have the effect of removing the subscription from that publisher
+for the namespaces specified.
+
+
+
+You can also send an unsubscribe without specifying any namespaces:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost' 
+             from='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe to='publisher'/>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe to='publisher'/>
+        </query>
+      </iq>
+
+
+
+This should have the effect of removing any subscription relationship with
+the publisher specified. Note, however, that this won't stop the subscriber
+being pushed information from that publisher if he's specified a
+"publisher-generic" subscription (see next section).
+
+
+
+
+
+
+
+As well as being able to subscribe to specific publishers, it is also
+possible to subscribe to receive data, according to namespace, regardless
+of publisher:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+This means that the subscriber wishes to be pushed information in the
+namespaces specified, regardless of who publishes it. Like the
+publisher-specific subscribe that specifies namespaces, this request is
+relative, in the namespaces are added to any existing namespaces already
+recorded for this generic subscription.
+
+
+
+Subscribing to everything from everyone is probably not a good idea and
+we should not allow this. (The format of the request is actually used in
+an IQ-get context - see later).
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe/>
+        </query>
+      </iq>
+
+RECV: <iq type='error' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe/>
+        </query>
+        <error code='405'>Not Allowed</error>
+      </iq>
+
+
+
+
+Likewise, you can unsubscribe from certain namespaces in this non-publisher-specific context like this:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost' 
+             from='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </unsubscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost' 
+             to='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </unsubscribe>
+        </query>
+      </iq>
+
+
+
+If there are any subscriptions to specific publishers for the namespaces
+specified here, they should be removed (for those namespaces) in addition
+to the removal from the 'all publishers' list.
+
+
+
+Finally, a subscriber can wipe the slate clean like this:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost' 
+             from='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe/>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost' 
+             to='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <unsubscribe/>
+        </query>
+      </iq>
+
+
+
+which should have the effect of removing all namespace subscriptions
+from everywhere.
+
+
+
+
+
+
+
+All the examples so far have shown actions on the subscriber's part, and
+have consisted of IQ-sets. In an IQ-set, within the jabber:iq:pubsub
+namespace, multiple children can exist in the query payload, but those
+children must be of the same type. In other words, you can send multiple
+<subscribe/>s, or multiple <unsubscribe/>s, but not a combination
+of the two.
+
+
+
+This is allowed:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisherA'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+          <subscribe to='publisherB'>
+            <ns>namespace:3</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisherA'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+          <subscribe to='publisherB'>
+            <ns>namespace:3</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+But this is not allowed:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisherA'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+          <unsubscribe to='publisherB'>
+            <ns>namespace:3</ns>
+          </unsubscribe>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='subscriber.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisherA'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+          <unsubscribe to='publisherB'>
+            <ns>namespace:3</ns>
+          </unsubscribe>
+        </query>
+        <error code='400'>
+          Bad Request: only subscribes or unsubscribes
+        </error>
+      </iq>
+
+
+
+In the case where multiple <subscribe/>s or <unsubscribe/>s
+appear in an action, each element will be processed in turn, as they appear
+in the payload.
+
+
+
+As well as actions, the subscriber can query his subscription using an
+IQ-get in the jabber:iq:pubsub namespace. This should return a list of
+the subscribers current subscriptions, like this:
+
+
+
+SEND: <iq type='get' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe/>
+        </query>
+      </iq>
+
+RECV: >iq type='result' from='pubsub.localhost'
+             to='subscriber@localhost/resource' id='s1'>
+        >query xmlns='jabber:iq:pubsub'>
+          >subscribe>
+            >ns>namespace:1>/ns>
+            >ns>namespace:2>/ns>
+          >/subscribe>
+          >subscribe to='publisherA'>
+            >ns>namespace:2>/ns>
+            >ns>namespace:4>/ns>
+          >/subscribe>
+          >subscribe to='publisherB'>
+            >ns>namespace:5>/ns>
+          >/subscribe>
+        >/query>
+      >/iq>
+
+
+
+Note the two references to namespace:2 - one inside the non-publisher-specific
+subscription list and one inside the subscription list specific to publisherA.
+This example implies that the non-publisher-specific and publisher-specific
+subscription information should be kept separately. This is designed to make
+it easier on the subscriber to manage his specific subscriptions over time.
+
+
+
+
+
+
+
+
+
+In contrast to the subscribe and unsubscribe context, the publishing
+context is a lot simpler to explain.
+
+
+
+A publisher can publish information within a certain namespace, like this:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='publisher@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='foo'/>
+            <foo xmlns='foo'>bar</foo>
+          </publish>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='publisher@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='foo'/>
+            <foo xmlns='foo'>bar</foo>
+          </publish>
+        </query>
+      </iq>
+
+
+
+It's also possible for a publisher to publish more than one item at once,
+like this:
+
+
+
+SEND: <iq type='set' to='pubsub.localhost'
+             from='publisher.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='foo'/>
+            <foo xmlns='foo'>bar</foo>
+          </publish>
+          <publish ns='jabber:x:oob'/>
+            <x xmlns='jabber:x:oob'>
+              <url>http://www.pipetree.com/jabber/</url>
+              <desc>Some stuff about Jabber</desc>
+            >
+          </publish>
+        </query>
+      </iq>
+
+RECV: <iq type='result' from='pubsub.localhost'
+             to='publisher.localhost' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='foo'/>
+            <foo xmlns='foo'>bar</foo>
+          </publish>
+          <publish ns='jabber:x:oob'/>
+            <x xmlns='jabber:x:oob'>
+              <url>http://www.pipetree.com/jabber/</url>
+              <desc>Some stuff about Jabber</desc>
+            >
+          </publish>
+        </query>
+      </iq>
+
+
+
+
+
+Each published item is wrapped in a <publish/> tag. This tag
+must contain the namespace of the item being publishes, in an ns 
+attribute, as shown. This is distinct from the xmlns attribute of
+the fragment of XML actually being published. It is theoretically
+none of the pubsub component's business to go poking around in the
+real published data, nor should it have to. It needs to know what
+namespace is qualifying the published information that has been 
+received, so that the list of appropriate recipients can be 
+determined.
+
+
+
+
+
+
+
+While it's the responsibility of the publishing entities to publish
+information, it's the responsibility of the pubsub
+component to push out that published data to the subscribers. The 
+list of recipient subscribers must be determined by the information
+stored by the pubsub component as a result of receiving subscription
+requests (which are described earlier).
+
+
+On receipt of an IQ-set containing published information, the pubsub
+entity must determine the list of subscribers to which that information
+should be pushed. If the IQ-set contains multiple <publish/>
+fragments, this process must be carried out for each one in turn.
+Whether a pubsub component implementation should be allowed to
+batch up individual published information fragments for one recipient
+as a result of a large, multi-part incoming publishing IQ-set, is not
+specified here, the choice is down to the implementer. Receiving entities
+should be able to cope with being pushed an IQ-set with multiple
+fragments of published data.
+
+
+Taking the earlier example of the publishing of data in the 'foo'
+namespace, the following example shows what the pubsub component
+must send to push this foo data out to a subscriber. 
+
+
+SEND: <iq type='set' to='subscriber@localhost/foosink'
+             from='pubsub.localhost' id='push1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='foo' from='publisher@localhost'/>
+            <foo xmlns='foo'>bar</foo>
+          </publish>
+        </query>
+      </iq>
+
+
+The recipient is _not_ required to send an 'acknowledgement' in the 
+form of an IQ-result; the idea that this _push_ of information is
+akin to how information is pushed in a live browsing context (see
+jabber:iq:browse documentation for more details).
+
+
+
+
+
+
+
+When a pubsub service receives a publish packet like the ones above, it
+needs to deliver (push) the information out according to the subscriptions
+that have been made. 
+
+
+
+However, we can introduce a modicum of sensitivity by using a presence
+subscription between the pubsub service and the subscriber(s). If the
+subscriber wishes only to receive information when he's online (this is
+a JSM-specific issue), then he needs to set up a presence subscription
+relationship with the pubsub service. The pubsub service should respond
+to presence subscriptions and unsubscriptions by 
+
+
+
+accepting the (un)subscription request
+reciprocating the (un)subscription request
+
+
+
+If the pubsub service deems that a published piece of information should
+be pushed to a subscriber, and there is a presence subscription relationship
+with that subscriber, the service should only push that information to the 
+subscriber if he is available. If he is not available, the information is not
+to be sent. 
+
+
+
+Thus the subscriber can control the sensitivity by initiating (or not) a
+presence relationship with the service. If the subscriber wishes to receive
+information regardless of availability, he should not initiate a (or cancel
+any previous) presence relationship with the service. 
+
+
+
+This loose coupling of presence relationships for sensitivity allows this
+specification to be used in the wider context of component-to-component
+publish/subscribe where presence is not a given.
+
+
+
+
+
+
+When in receipt of a pubsub subscription request from an entity 
+where a resource is specified in the JID, the pubsub component must
+honour the resource specified in the from attribute of the request.
+For example, here's a typical subscription request from a JSM user:
+
+
+RECV: <iq type='set' to='pubsub.localhost'
+             from='subscriber@localhost/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'>
+            <ns>namespace:1</ns>
+            <ns>namespace:2</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+When storing the subscriber/publisher/namespace relationship matrix for
+eventual querying when a publisher publishes some information, the 
+pubsub component must use the full JID, not just the username@host part.
+
+
+Similarly, in this example:
+
+
+RECV: <iq type='set' to='pubsub.localhost'
+             from='news.server/politics-listener' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher'>
+            <ns>news:politics:home</ns>
+            <ns>news:politics:foreign:usa</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+the full JID of the component subscriber - news.server/politics-listener,
+should be used to qualify the matrix.
+
+
+This is because it allows the subscribing entities to arrange the 
+receipt of pushed items by resource. In the case of a JSM user, it
+allows him to organise his clients, which may have different capabilities
+(some being able to handle the jabber:iq:pubsub data, others not) to
+receive the 'right' data. In the case of a component, it allows the
+component to associate component-specific data with incoming published
+namespace-qualified information.
+
+
+
+
+
+
+
+
+
+
+While the specification describes the fundamental building blocks of the
+pubsub protocol, there are ideas that are not discussed above but nonetheless
+may be incorporated into an implementation. There are other considerations
+that have to be made in the wider context of publish and subscribe. Some of
+the main ones are discussed briefly here too.
+
+
+
+
+There is no part of this pubsub specification that determines how a 
+potential subscriber might discover publishers. After all, there are
+no rules governing which pubsub component a publisher could or should
+publish to. And since pubsub subscriptions are specific to a pubsub
+component, there is an information gap - "how do I find out what 
+publishers there are, and through which pubsub components they're publishing
+information?"
+
+
+This problem domain should be solved using other methods, not with the
+actual jabber:iq:pubsub specific namespace. A combination of jabber:iq:browse
+usage (the magic ointment that heals all things) and perhaps a DNS style
+(or at least root-node-based) knowledge hierarchy might be the right
+direction.
+
+
+In the case where a server administrator wishes to facilitate pubsub
+flow between JSM users on a server, a pubsub component can be plugged
+into the jabberd backbone, and there is potentially no real issue with
+knowing which pubsub component to use, and where it is.
+But what about if the JSM users on one server wish to build pubsub
+relationships with JSM users on another server? (Note that this general
+question is not specific to JSM users, although that example will be used
+here). The next two sections look at how these things might pan out.
+
+
+
+
+
+When JSM users on server1 wish to subscribe to information published 
+by JSM users on server2 (let's say it's the mp3 player info, or avatars)
+then there are some issues that come immediately to mind:
+
+
+Does a JSM user on server1 (userA@server1) send his IQ-set subscription
+to the pubsub component on server2 (pubsub.server2), or server1
+(pubsub.server1)?
+If he sends it to pubsub.server2, can we expect 
+pubsub.server2 to always accept that subscription request, i.e. to 
+be willing to serve userA@server1 (if pubsub.server2 knows that 
+pubsub.server1 exists)?
+Will there be performance (or at least server-to-server traffic)
+implications if many subscription relationships exist between subscribers on
+server1 and publishers on server2?
+
+
+
+
+To reduce the amount of server-to-server traffic, we can employ the 
+concept of "proxy subscriptions". This is simply getting a pubsub component
+to act on behalf of a (server-local) subscriber. Benefit comes when a pubsub
+component acts on behalf of multiple (server-local) subscribers.
+
+
+Here's how such proxy subscriptions can work, to reduce the amount of
+server-to-server traffic:
+
+
+Step 1: Subscriber sends original subscription
+
+
+JSM users on server1 wish to subscribe to information published by an 
+entity on server2. Each of them sends a subscription request to the
+_local_ pubsub component:
+
+
+SEND: <iq type='set' to='pubsub.server1'
+             from='subscriber@server1/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+Step2: Pubsub component subscribes on subscriber's behalf
+
+
+The pubsub component knows about the publisher, and where (to which
+pubsub component) that publisher publishes information. It formulates
+a subscription request and sends it to the remote pubsub component:
+
+
+SEND: <iq type='set' to='pubsub.server2'
+             from='pubsub.server1' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+The remote pubsub component receives and acknowledges the subscription
+request, and the local pubsub component relays the response back to 
+the original requester:
+
+
+SEND: <iq type='result' from='pubsub.server1'
+             to='subscriber@server1/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+      </iq>
+
+
+
+If the remote pubsub server was unable or unwilling to accept the 
+subscription request, this should be reflected in the response:
+
+
+SEND: <iq type='error' from='pubsub.server1'
+             to='subscriber@server1/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+        <error code='406'>Not Acceptable</error>
+      </iq>
+
+
+
+Step3: Publisher publishes information
+
+
+The publisher, publisher.server2, publishes information in the 
+namespace:1 namespace, to the remote pubsub component pubsub.server2:
+
+
+SEND: <iq type='set' from='publisher.server2'
+             to='pubsub.server2' id='p1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='namespace;1'>
+            <stuff xmlns='namespace:1'>nonsense</stuff>
+          </publish>
+        </query>
+      </iq>
+
+
+
+
+Step4: Pubsub component receives published information
+
+
+The pubsub component pushes the published information to pubsub.server1,
+who has been determined to be a valid recipient:
+
+
+RECV: <iq type='set' from='pubsub.server2'
+             to='pubsub.server1' id='p1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='namespace;1' from='publisher.server2'>
+            <stuff xmlns='namespace:1'>nonsense</stuff>
+          </publish>
+        </query>
+      </iq>
+
+
+
+Step5: Pubsub component forwards published information to original subscriber
+
+
+The local pubsub component then diffuses the information received to the
+original subscriber:
+
+
+SEND: <iq type='set' from='pubsub.server1'
+             to='subscriber@server1/resource' id='p1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <publish ns='namespace;1' from='publisher.server2'>
+            <stuff xmlns='namespace:1'>nonsense</stuff>
+          </publish>
+        </query>
+      </iq>
+
+
+
+This way, only a single published element must travel between servers
+to satisfy a multiplex of subscribed entities at the delivery end.
+
+
+
+Of course, this mechanism will rely upon knowledge about pubsub components
+and where they're available; furthermore, it will require knowledge about
+where publisher entities publish their information.
+This knowledge, and the mechanisms to discover this sort of information,
+is not to be covered in this spec, which purely deals with the subscription
+and publishing of information. As SOAP is to UDDI (to use a slightly
+controversial pair of technologies), so is jabber:iq:pubsub to this 
+discovery mechanism as yet undefined. To include the definition of such
+a discovery mechanism in this specification is wrong on two counts:
+
+
+Discovery mechanisms by nature should not be tied to specific areas
+Trying to load too much onto jabber:iq:pubsub will only produce a 
+complex and hard-to-implement specification
+
+
+After all, the jabber:iq:pubsub spec as defined here is usable out of the
+box for the simple scenarios, and scenarios where discovery is not 
+necessary or the information can be exchanged in other ways.
+
+
+
+
+
+
+There are some situations where it might be appropriate for a pubsub
+component to refuse particular subscription requests. Here are two 
+examples:
+
+
+Where a pubsub component that's been designed, implemented, or
+configured to handle local-only pubsub traffic, and a subscription request
+is received, specifying a publisher that the local pubsub component knows
+to be one that publishes to a remote pubsub component under other
+circumstances, this would trigger a 'Proxy Subscription', as described earlier, if supported. In this case, the local pubsub component would be
+unwilling to provoke a server-to-server connection and therefore unwilling to 
+honour the request.
+Where a pubsub component receives a subscription request from a 
+remote subscriber, and that pubsub component knows that there's a 
+pubsub component local to the subscriber. In this case, the (administrator 
+of the) remote pubsub component might want to encourage proxy subscriptions.
+
+
+
+A refusal could take one of a number of guises:
+
+
+SEND: <iq type='error' from='pubsub.server2'
+             to='subscriber@server1/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+        <error code='406'>Local pubsub only</error>
+      </iq>
+
+
+SEND: <iq type='error' from='pubsub.server2'
+             to='subscriber@server1/resource' id='s1'>
+        <query xmlns='jabber:iq:pubsub'>
+          <subscribe to='publisher.server2'>
+            <ns>namespace:1</ns>
+          </subscribe>
+        </query>
+        <error code='302' jid='pubsub.server1'/>
+      </iq>
+
+This 302 redirect is not covered in the general protocol specification,
+but it's an interesting concept :-)
+
+
+
+
+
+
+
+The jabber:iq:pubsub specification makes no provision for 
+publishers to query a pubsub component to ask for a list of those entities
+that are subscribed to (namespaces) it (publishes). This is deliberate. 
+Do we wish to add to the specification to allow the publisher to discover
+this information? If so, it must be as an optional 'opt-in' (or 'opt-out')
+tag for the subscriber, to determine whether his JID will show up on the
+list. 
+Even if there is no provision for querying the subscribers, perhaps
+we should make a provision for the publisher to ask the pubsub component
+for a list of namespaces that have been subscribed to (for that publisher).
+
+
+
+Associated with this is the semi-reciprocal issue of acceptance? The 
+specification deliberately makes no provision for a subscription acceptance
+mechanism (where the publisher must first accept a subscriber's request,
+via the pubsub component). If we're to prevent the publishers knowing
+who is subscribing, ought we to give them the power of veto, to 'balance
+things out'?
+
+
+Note that if we do, the acceptance issue is not necessarily one for the
+pubsub specification to resolve; there are other ways of introducing 
+access control, at least in a component environment; use of a mechanism
+that the Jabber::Component::Proxy Perl module represents is one example:
+wedge a proxy component in front of a real (pubsub) component and have
+the ability to use ACLs (access control lists) to control who gets to 
+connect to the real component.
+
+
+
+
+
+
+
diff --git a/xep-0025.xml b/xep-0025.xml
new file mode 100644
index 00000000..0082ebf0
--- /dev/null
+++ b/xep-0025.xml
@@ -0,0 +1,386 @@
+
+
+%ents;
+]>
+
+
+  
+    Jabber HTTP Polling
+    This document defines a protocol that enables access to a Jabber server from behind firewalls which do not allow outgoing sockets on port 5222, via HTTP requests.
+    &LEGALNOTICE;
+    0025
+    Deprecated
+    Historical
+    Standards JIG
+    
+      XMPP Core
+    
+    
+    
+      JEP-0124
+    
+    httppoll
+    &hildjj;
+    
+      Craig
+      Kaes
+      ckaes@jabber.com
+      ckaes@corp.jabber.com
+    
+    
+      David
+      Waite
+      mass@akuma.org
+      mass@akuma.org
+    
+    
+      1.1
+      2006-07-26
+      psa
+      Per a vote of the Jabber Council, changed status to Deprecated.
+    
+    
+      1.0
+      2002-10-11
+      psa
+      Per a vote of the Jabber Council, advanced status to Active.
+    
+    
+      0.2
+      2002-09-23
+      dew
+      Changed format to allow socket-equivalent security.
+    
+    
+      0.1
+      2002-03-14
+      jjh
+      Initial version.
+    
+  
+  
+    Note Well: This protocol specified in this document has been superseded by the protocol specified in &jep0124;.
+    
+      This JEP documents a method to allow Jabber clients to access Jabber
+      servers from behind existing firewalls. Although several similar methods
+      have been proposed, this approach should work through all known firewall
+      configurations which allow outbound HTTP access.
+    
+  
+  
+    
+      In general, a firewall is a box that protects a network from outsiders,
+      by controlling the IP connections that are allowed to pass through the
+      box. Often, a firewall will also allow access outside only by proxy,
+      either explicit proxy support or implicit through Network Address
+      Translation (NAT).
+    
+    
+      In the interest of security, many firewall administrators do not allow
+      outbound connections to unknown and unused ports. Until Jabber becomes
+      more widely deployed, port 5222/tcp (for Jabber client connections) will
+      often be blocked.
+    
+    
+      The best solution for sites that are concerned about security is to run
+      their own Jabber server, either inside the firewall, or in a DMZ
+      
+        DMZ definition at
+        
+          searchwebmanagement.com
+        
+      
+      network. However, there are network configuration where an external
+      Jabber server must still be used and port 5222/tcp outbound cannot be
+      allowed. In these situations, different methods for connecting to a
+      Jabber server are required. Several methods exist today for doing this
+      traversal. Most rely on the fact that a most firewalls are configured to
+      allow access through port 80/tcp. Although some less-complicated
+      firewalls will allow any protocol to traverse this port, many will proxy,
+      filter, and verify requests on this port as HTTP. Because of this, a
+      normal Jabber connection on port 80/tcp will not suffice.
+    
+    
+      In addition, many firewalls/proxy servers will also not allow or not
+      honor HTTP Keep-alives (as defined in section 19.7.1.1 of &rfc2068;)
+      and will consider long-lived socket connections as security issues.
+      Because of this the traditional Jabber connection model, where one
+      socket is one stream is one session, will not work reliably.
+    
+    
+      In light of all of the ways that default firewall rules can interfere
+      with Jabber connectivity, a lowest-common denominator approach was
+      selected. HTTP is used to send XML as POST requests and receieve pending
+      XML within the responses. Additional information is prepended in the
+      request body to ensure an equivalent level of security to TCP/IP sockets.
+    
+  
+  
+    
+      The client makes HTTP requests periodically to the server. Whenever the
+      client has something to send, that XML is included in the body of the
+      request. When the server has something to send to the client, it must be
+      contained in the body of the response.
+    
+    
+      In some browser/platform combinations, sending cookies from the client is
+      not possible due to design choices and limitations in the
+      browser. Therefore, a work-around was needed to support clients based on
+      these application platforms.
+    
+    
+      All requests to the server are HTTP POST requests, with Content-Type:
+      application/x-www-form-urlencoded. Responses from the server have
+      Content-Type: text/xml. Both the request and response bodies are UTF-8
+      encoded text, even if an HTTP header to the contrary exists. All
+      responses contain a Set-Cookie header with an identifier, which is sent
+      along with future requests as described below. This identifier cookie
+      must have a name of 'ID'. The first request to a server always uses 0 as
+      the identifier. The server must always return a 200 response code,
+      sending any session errors as specially-formatted identifiers.
+    
+    
+      The client sends requests with bodies in the following format:
+      
+          identifier ; key [ ; new_key] , [xml_body]
+      
+      If the identifier is zero, key indicates an initial key. In this case,
+      new_key should not be specified, and must be ignored.
+      
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+      Identifier Purpose
identifier 
+            To uniquely identify the session server-side. This field is only
+            used to identify the session, and provides no security.
+          
key 
+            To verify this request is from the originator of the session. The
+            client generates a new key in the manner described below for each
+            request, which the server then verifies before processing the
+            request.
+          
new_key 
+            The key algorithm can exhaust valid keys in a sequence, which
+            requires a new key sequence to be used in order to continue the
+            session. The new key is sent along with the last used key in the
+            old sequence.
+          
xml_body 
+            The body of text to send. Since a POST must be sent in order for
+            the server to respond with recent messages, a client may send
+            a request without an xml_body in order to just retrieve new
+            incoming packets. This is not required to be a full XML document or
+            XML fragment, it does not need to start or end on element boundaries.
+          
+    
+    
+      The identifier is everything before the first semicolon, and must consist
+      of the characters [A-Za-z0-9:-]. The identifier returned from the first
+      request is the identifier for the session. Any new identifier that ends
+      in ':0' indicates an error, with the entire identifier indicating the
+      specific error condition. Any new identifier that does not end in ':0' is
+      a server programming error, the client should discontinue the
+      session. For new sessions, the client identifier is considered to be 0.
+    
+    
+      
+        Any identifier that ends in ':0' indicates an error. Any previous
+        identifier associated with this session is no longer valid.
+      
+      
+        
+          Server returns ID=0:0. The response body can contain a textual error
+          message.
+        
+      
+      
+        Server returns ID=-1:0
+      
+      
+        Server returns ID=-2:0
+      
+      
+        Server returns ID=-3:0
+      
+    
+    
+      The key is a client security feature to allow TCP/IP socket equivalent
+      security. It does not protect against intermediary attacks, but does
+      prevent a person who is capable of listening to the HTTP traffic from
+      sending messages and receiving incoming traffic from another machine.
+    
+    The key algorithm should be familiar with those with knowledge of Jabber zero-knowledge authentication.
+    
+        K(n, seed) = Base64Encode(SHA1(K(n - 1, seed))), for n > 0
+        K(0, seed) = seed, which is client-determined
+    
+    Note: Base64 encoding is defined in &rfc3548;. SHA1 is defined in &rfc3174;.
+    
+      No framing is implied by a single request or reply. A single request can
+      have no content sent, in which case the body contains only the identifier
+      followed by a comma. A reply may have no content to send, in which case
+      the body is empty. Zero or more XMPP packets may be sent in a single
+      request or reply, including partial XMPP packets.
+    
+    
+      The absense of a long-lived connection requires the server to consider
+      client traffic as a heartbeat to keep the session alive. If a
+      server-configurable period of time passes without a successful POST
+      request sent by the client, the server must end the client session. Any
+      client requests using the identifier associated with that now dead
+      session must return an error of '0:0'.
+    
+    
+      The maximum period of time to keep a client session active without an
+      incoming POST request is not defined, but five minutes is the recommended
+      minimum. The maximum period of time recommended for clients between
+      requests is two minutes; if the client has not sent any XML out for two
+      minutes, a request without an XML body should be sent. If a client is
+      disconnecting from the server, a closing <stream:stream> must be
+      sent to end the session. Failure to do this may have the client continue
+      to be represented to other users as available.
+    
+    
+      If the server disconnects the user do to a session timeout, the server
+      MUST bounce pending IQ requests and either bounce or store offline
+      incoming messages.
+    
+  
+  
+    
+      The following is the sequence used for client communication
+      

+        
+          The client generates some initial K(0, seed) and runs the algorithm
+          above 'n' times to determine the initial key sent to the server,
+          K(n, seed)
+        
+        
+          The client sends the request to the server to start the stream,
+          including an identifier with a value of zero and K(n, seed)
+        
+        
+          The server responds with the session identifier in the headers
+          (within the Set-Cookie field).
+        
+        
+          For each further request done by the client, the identifier from the
+          server and K(n - 1, seed) are sent along.
+        
+        
+          The server verifies the incoming value by generating
+          K(1, incoming_value), and verifying that value against the value sent
+          along with the last client request. If the values do not match, the
+          request should be ignored or logged, with an error code being
+          returned of -3:0. The request must not be processed, and must not
+          extend the session keepalive. 
+        
+        
+          The client may send a new key K(m, seed') at any point, but should
+          do this for n > 0 and must do this for n = 0. If K(0, seed) is
+          sent without a new key, the client will not be able to continue the
+          session.
+        
+      
+    
+    
+
+]]>
+ 
+    
+    
+
+
+]]>
+
+    
+    
+
+
+  
+    hildjj
+  
+]]>
+
+    
+    
+      K(0, "foo") = "foo"
+      K(1, "foo") = "C+7Hteo/D9vJXQ3UfzxbwnXaijM="
+      K(2, "foo") = "6UU8CDmH3O4aHFmCqSORCn721+M="
+      K(3, "foo") = "vFFYSOhGyaGUgLrldtMBX7x91Wc="
+      K(4, "foo") = "ZaDxCilBVTHS9dJfbBo1NsC2b+8="
+      K(5, "foo") = "moPFsvHytDGiJQOjp186AMXAeP0="
+      K(6, "foo") = "VvxEk07IFy6hUmG/PPBlTLE2fiA="
+    
+      
+
+]]>
+ 
+      
+      
+
+
+  
+    hildjj
+  
+]]>
+
+    
+    
+]]>
+    
+  
+  
+    
+      This method works over HTTPS, which is good from the standpoint of functionality, but bad in the sense that a massive amount of hardware would be needed to support reasonable polling intervals for non-trivial numbers of clients.
+    
+  
+
diff --git a/xep-0026.xml b/xep-0026.xml
new file mode 100644
index 00000000..2c0bebab
--- /dev/null
+++ b/xep-0026.xml
@@ -0,0 +1,209 @@
+
+
+%ents;
+]>
+
+
+
+	Internationalization (I18N)
+        NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.
+        &LEGALNOTICE;
+	0026
+	Retracted
+	Standards Track
+	Standards
+        None
+        None
+        XMPP Core
+        N/A
+	
+		Max
+		Horn
+		max@quendi.de
+		black_fingolfin@jabber.org
+	
+        
+          0.2
+          2003-11-05
+          psa
+          The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+        
+	
+		0.1
+		2002-03-14
+		mh
+		Initial version.
+	
+
+
+	 
+	 	Jabber is meant to allow people everywhere in the world to communicate
+		with each other. However, people converse in many different languages, not just
+		English. Many humans in fact don't even understand English. Hence,
+		Jabber should not be tied to  a particular language, but rather allow
+		usage of any language, be it English, Chinese, Inuit, or anything else.
+	
+	
+		One important step towards this goal is that Jabber is based upon
+		Unicode, allowing for many different languages. But that alone is not
+		enough. Jabber promotes a server-based system for many of its
+		components and services, like the JUD, or transports. Many of these have
+		to interact with users in some way. Currently, they do so in only one
+		fixed language (usually English). Even if the server admin is willing
+		to translate the messages, forms, etc. involved, there can only be one
+		localization active for a given server/component.
+	
+	
+		Hence, Jabber must support a way for clients to inform the server about
+		their preferred language. In addition, the server and other components
+		have to understand and honor this information. Only this way can we
+		ensure that Jabber is able to work in a multi-national, multi-lingual
+		environment.
+	
+	
+		Some examples on how this information could and should be used, include
+	
+	
+		Forms (e.g. for registration or searching, refer also to JEP-0004) can be localized, so that instructions and field labels are in the native language of the person who has to fill them out
+		Even if the form can't be sent in the proper language (e.g. simply because it hasn't yet been translated), the component still should tag its reply with the language being used
+		Incoming messages in a different language could be automatically translated (server-side or client-side)
+		Redirection of messages based on their language (think of a help desk which services world wide requests)
+		Transports to services which are not unicode based could use the language information as a hint at the best encoding (least lossage) for converted messages
+	
+
+
+
+	
+		The basic idea behind this proposal was to use existing standards where possible, and to make it fully backward compatible. Furthermore it was a goal to allow clients to support it now, even without any server support, while at the same time permitting improved functionality once servers start to implement this spec.
+	
+
+	
+		To encode the locale on any given XML packet, we use the xml:lang attribute, as defined in the XML specification. This in turn uses values as specified in RFC 1766 to encode languages and regions. This way, you can even distinguish between British and Australian English.
+		
+		
+<message to='friedrich@jabber.org' xml:lang='de-DE'>
+  <body'>Ich bin ein Berliner!</body'>
+</message>  
+		
+			An xml:lang tag can be put onto any XML element; for the purposes of this JEP, however, we will limit its usage to the four central Jabber elements: <stream/>, <message/>, <iq/> and <presence/>.
+		
+	
+	
+	
+		
+			A client claiming to support this JEP has to initiate server connection slightly differently by putting an xml:lang attribute in the initial <stream:stream> element.
+		
+		
+<?xml version="1.0" encoding="UTF-8" ?>
+<stream:stream to='jabber.org' xmlns='jabber:client'
+          xmlns:stream='http://etherx.jabber.org/streams' xml:lang='fr-CA'> 
+		
+			Servers not supporting this JEP will just ignore the additional attribute. Compliant server can be distinguished by the fact that their reply <stream:stream> element also contains an xml:lang attribute, indicating the main language of the server. A compliant client has to detect whether the server is compliant or not, and base its future behavior on this information.
+		
+		
+<stream:stream from='jabber.org' id='12345' xmlns='jabber:client'
+          xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'> 
+		
+			If the client thus determines that the server is compliant, then it doesn't have to do anything beyond this point. All its outgoing messages will automatically be flagged by the server with an xml:lang attribute if necessary. Thus writing a minimal compliant client is trivial.
+		
+		
+			If it is determined that the server does not support this JEP, and the client still wants to offer locale support, it may start flagging all its outgoing message/iq/presence elements with the xml:lang attribute, to ensure that other components/clients which do conform to this JEP can handle the localization despite the local server not doing so.
+		
+		
+			Finally, if for whatever reasons the client wants to flag particular messages with a different locale (e.g. if the user is bilingual), it can do so at any time by putting an appropriate xml:lang element in the outgoing data. This will override the previously set default locale for this message only.
+		
+	
+
+	
+	
+		
+			A compliant server must detect the xml:lang attribute in incoming <stream:stream> elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session. 
+		
+		
+			Additionally, a compliant server must attach an xml:lang attribute to the reply <stream:stream> element sent in response to a newly initiated connection. This attribute should reflect the default language of that server, and is used to indicate to clients that the server implements this JEP.
+		
+		
+			The server should not only allow user clients to specify a default language this way, but also server-side components, like the JUD should be allowed to do this.
+		
+		
+			Whenever a message leave the server, it has to tag the message automatically with the xml:lang attribute of the corresponding seesion, if any was specified, unless the message is already tagged this way. In that case, the already existing xml:lang attribute takes precedence, thus allowing for greater flexibility.
+		
+		
+			If a client send a message to another local client which uses the same xml:lang value, then no change is applied. But if the recipient uses a different xml:lang, and if the message has no xml:lang attribute attached yet, the xml:lang of the server has to be attached before delievey of the message.
+		
+	
+
+	
+	
+		
+			Jabber based services that wish to comply to this JEP have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on JEP-0004.
+		
+		
+<iq from='users.jabber.org' type='result' id='4' xml:lang='en'>
+  <query xmlns='jabber:iq:search'>
+    <instructions>
+        Fill in a field to search for any matching Jabber users.
+    </instructions>
+    <nick/>
+    <first/>
+    <last/>
+    <email/>
+
+    <x xmlns='jabber:x:data'>
+      <instructions>
+          To search for a user fill out at least one 
+          of the fields below and submit the form.
+      </instructions>
+      <field type='text-single' label='First (Given)' var='first'/>
+      <field type='text-single' label='Last (Family)' var='last'/>
+      <field type='text-single' label='Nick (Alias)' var='nick'/>
+      <field type='text-single' label='Email' var='email'/>
+    </x>
+  </query>
+</iq> 
+		
+			This way, a client could for example offer to translate the form since it now knows the language the form was written in. Previously it could just guess the language was English, which never was guaranteed.
+		
+     	
+     		To be able to tailor replies to the user's preferred language, the component has to know this information. This is simply inferred from any xml:lang attribute on incoming requests. If none is present, the default locale is assumed. If the client's default locale diverges from that of the component, it is the server's responsibility to tag the query with an appropriate xml:lang attribute (refer to the "Server support" section). If on the other hand the server is not compliant, then any interested client will manually tag its queries with an xml:lang attribute. Thus it is sufficient to check for this attribute.
+     	
+		
+<iq to='users.jabber.org' type='get' id='5' xml:lang='de'>
+  <query xmlns='jabber:iq:search'/>
+</iq> 
+		
+			A more sophisticated component supporting multiple localizations of its forms/messages could now honor the requested language and send this search form instead of the English one shown previously:
+		
+		
+<iq from='users.jabber.org' type='result' id='5' xml:lang='de'>
+  <query xmlns='jabber:iq:search'>
+    <instructions>
+        Füllen Sie ein Feld aus um nach einem beliebigen 
+        passenden Jabber-Benutzer zu suchen.
+    </instructions>
+    <nick/>
+    <first/>
+    <last/>
+    <email/>
+
+    <x xmlns='jabber:x:data'>
+      <instructions>
+          Um nach einem Benutzer zu suchen, füllen Sie mindestens eines 
+          der folgenden Felder aus und schicken dann das Formular ab.
+      </instructions>
+      <field type='text-single' label='Vorname' var='first'/>
+      <field type='text-single' label='Nachname' var='last'/>
+      <field type='text-single' label='Spitzname' var='nick'/>
+      <field type='text-single' label='Email' var='email'/>
+    </x>
+  </query>
+</iq> 
+		
+			If the component doesn't have the requested localization available, it replies with the default localization (but of course with the matching xml:lang attribute tagged to it, and not the one of the request).
+     	
+     
+	
+
+
+
diff --git a/xep-0027.xml b/xep-0027.xml
new file mode 100644
index 00000000..78199105
--- /dev/null
+++ b/xep-0027.xml
@@ -0,0 +1,183 @@
+
+
+%ents;
+]>
+
+
+
+  Current Jabber OpenPGP Usage
+  This document outlines the current usage of OpenPGP for messaging and presence.
+  &LEGALNOTICE;
+  0027
+  Active
+  Historical
+  Standards JIG
+  
+    XMPP Core
+  
+  
+  
+  openpgp
+  
+    jabber:x:encrypted
+    http://jabber.org/protocol/openpgp/x-encrypted.xsd
+  
+  
+    jabber:x:signed
+    http://jabber.org/protocol/openpgp/x-signed.xsd
+  
+  &temas;
+  
+      1.2
+      2004-03-08
+      psa
+      Clarified the text in several places; added several more security considerations and known issues.
+  
+  
+      1.1
+      2004-01-06
+      psa
+      Added XML schemas; added security, IANA, and Jabber Registrar considerations.
+  
+  
+      1.0
+      2002-04-23
+      psa
+      Changed status to Active.
+  
+  
+      0.2
+      2002-04-11
+      tjm
+      Merged DW's comments on key usage as well as more known issues.
+  
+  
+      0.1
+      2002-03-12
+      tjm
+      First draft.
+  
+
+
+  The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system.  Unfortunately, finding a consensus solution to the problem of end-to-end encryption during the community's younger days was not easy.  Eventually, early contributors created a quick solution using OpenPGP.  This JEP documents the OpenPGP solution as it is used today, so that others may interoperate with clients that support it.  This JEP is not intended to present a standard, because more complete solutions are being investigated.
+  All operations described here are done with standard OpenPGP software such as GnuPG.  All program output is US-ASCII armored output with the headers removed.  This allows for easy transportation of the program output directly in the XML.  All keys are exchanged using OpenPGP key servers, and usually are retrieved when a signed &PRESENCE; stanza is received (key retrieval does not happen in-band).
+
+
+  Signing enables a sender to verify that they sent a certain block of text.  In Jabber, signing uses the 'jabber:x:signed' namespace, and is primarily used with &PRESENCE;, but may also be used with &MESSAGE;.  Because signing requires a block of text, it creates new restrictions on the &PRESENCE; and &MESSAGE; stanzas:
+    
+      A &PRESENCE; stanza MUST have a <status> element containing XML character data.
+      A &MESSAGE; stanza MUST have a <body> element containing XML character data.
+    
+    These requirements are necessary so that there is always common text to sign and verify against.  When signing presence, the sender SHOULD sign the XML character data of the <status> element.  The sender SHOULD sign presence using the private key whose KeyID corresponds to the public key to be used in encrypting messages (see below).
+    
+<presence from='pgmillard@jabber.org/wj_dev2' to='jer@jabber.org'>
+  <status>Online</status>
+  <x xmlns='jabber:x:signed'>
+    iQA/AwUBOjU5dnol3d88qZ77EQI2JACfRngLJ045brNnaCX78ykKNUZaTIoAoPHI
+    2uJxPMGR73EBIvEpcv0LRSy+
+    =45f8
+  </x>
+</presence>
+    
+
+
+  Encryption enables the sender to encrypt a message to a specific recipient.  This is accomplished using the 'jabber:x:encrypted' namespace in conjunction with &MESSAGE; stanzas.  Because a block of text is necessary in order to have something to encrypt, &MESSAGE; stanzas intended to be encrypted have the same restrictions as signing (see above).  The data encrypted MUST be the XML character data of the <body> element.  The sender SHOULD encrypt the message body using the public key whose KeyID corresponds to the private key used in signing presence (see above).
+  
+<message to='reatmon@jabber.org/jarl' from='pgmillard@jabber.org/wj_dev2'>
+  <body>This message is encrypted.</body>
+  <x xmlns='jabber:x:encrypted'>
+    qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
+    WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
+    IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
+    AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
+    kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
+    w7R61cCPt8KSd8Vcl8K+StqOMZ5wkhosVjUqvEu8uJ9RupdpB/4m9E3gOQZCBsmq
+    OsX4/jJhn2wIsfYYWdqkbNKnuYoKCnwrlmn6I+wX72p0R8tTv8peNCwK9bEtL/XS
+    mhn4bCxoUkCITv3k8a+Jdvbov9ucduKSFuCBq4/l0fpHmPhHQjkFofxmaWJveFfF
+    619NXyYyCfoLTmWk2AaTHVCjtKdf1WmwcTa0vFfk8BuFHkdah6kJJiJ7w/yNwa/E
+    O6CMymuZTr/LpcKKWrWCt+SErxqmq8ekPI8h7oNwMxZBYAa7OJ1rXWKNgL9pDtNI
+    824Mf0mXj7q5N1eMHvX1QEoKLAda/Ae3TTEevOyeUK1DEgvxfM2KRZ11RzU+XtIE
+    My/bJk7EycAw8P/QKyeNlO1fxP58VEd6Gb8NCPqKOYn/LKh1O+c20ZNVEPFM4bNV
+    XA4hB4UtFF7Ao8kpdlrUqdKyw4lEtnmdemYQ6+iIIVPEarWl9PxOMY90KAnZrSAq
+    bt9uRY/1rPgelRaWblMKvxgpRO8++Y8VjdEyGgMOXxOiE851Ve72ftGzkSxDH8mW
+    TgY3pf2aATmBp3lagQ1COkGS/xupovT5AQPA3RzbCxDvc6s6eGYKmVVQVj5vmSj1
+    WULad5MB9KT1DzCm6FOSy063nWGBYYMWiejRvGLpo1j4eAnj0qOt7rTWmgv3RkYF
+    Oin0vDOhW7aC
+    =CvnG</x>
+</message>
+  
+  It is considered polite to include an unencrypted message <body/> explaining that the actual message body is encrypted.  This helps if the client experiences an error while decrypting the message, or if the user's a client that does not support encryption (although generally this should not happen, since the signed presence can be used to indicate that a client accepts encrypted messages).
+
+
+  The method defined herein has the following security issues:
+  
+    Key exchange relies on the web of trust model used on the OpenPGP keys network.
+    There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key.
+    When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages.
+    Replay of the signed &PRESENCE; status is possible.
+    It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of &IQ; stanzas, and it allows signing of the presence <status/> element and encryption of the message <body/> element only. Thus the method is not acceptable when signing or encryption of full stanzas is required.
+    It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.
+  
+
+
+  In addition to the security considerations listed above, there are several other known issues with this method:
+  
+    It is limited to PGP keys and does not support X.509 certificates, Kerberos, RSA keys, etc.
+    It does not include feature negotiation; instead, signed &PRESENCE; is used as an indicator of support.  Because of the lack of negotiation it is possible for encrypted &MESSAGE; elements to be stored offline and then read by a client that cannot support them.
+    It is verbose (the example encrypted &MESSAGE; is "Hi").
+  
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+  The ®ISTRAR; shall register the 'jabber:x:encrypted' and 'jabber:x:signed' namespaces as a result of this JEP.
+
+
+  
+    
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0027: http://www.jabber.org/jeps/jep-0027.html
+    
+  
+
+  
+
+
+    ]]>
+  
+  
+    
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0027: http://www.jabber.org/jeps/jep-0027.html
+    
+  
+
+  
+
+
+    ]]>
+  
+
+
diff --git a/xep-0028.xml b/xep-0028.xml
new file mode 100644
index 00000000..e301ed59
--- /dev/null
+++ b/xep-0028.xml
@@ -0,0 +1,13 @@
+
+
+%ents;
+]>
+
+
+
+  No Such JEP
+  This JEP was removed from the JSF website and source control at the request of the author.
+  0028
+
+
diff --git a/xep-0029.xml b/xep-0029.xml
new file mode 100644
index 00000000..cac9c8ab
--- /dev/null
+++ b/xep-0029.xml
@@ -0,0 +1,117 @@
+
+
+%ents;
+]>
+
+
+    
+        Definition of Jabber Identifiers (JIDs)
+        This document defines the exact nature of a Jabber Identifier (JID). Note well: this document is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.
+        &LEGALNOTICE;
+        0029
+        Retracted
+        Standards Track
+        Standards JIG
+        None
+        None
+        XMPP Core
+        N/A
+        
+            Craig
+            Kaes
+            craigk@jabber.com
+            craigk@jabber.com
+        
+        
+            1.1
+            2003-10-03
+            psa
+            Changed status to Retracted. This JEP is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.
+        
+        
+            1.0
+            2002-05-15
+            psa
+            Changed status to Draft.
+        
+        
+            0.2
+            2002-05-01
+            cak
+            
+                Added info on restricting resource identifier length; standardized nomenclature.
+            
+        
+        
+            0.1
+            2002-04-24
+            cak
+            Initial version
+        
+    
+    
+        Jabber Identifiers (JIDs) uniquely identify individual entities in the Jabber network. To date, their syntax has been defined by convention, existing implementations, and available documentation. As it exists, certain characters that are allowed in JIDs cause ambiguity, and the lack of a size limit on resources defies database schemas and causes some trivial JID operations to require dynamic memory allocation. This JEP seeks to both define and improve the existing JID syntax. This JEP will not explain the general usage or nature of JIDs, instead focusing on syntax.
+    
+    
+        JIDs consist of three main parts:
+          
+            The node identifier (optional)
+            The domain identifier (required)
+            The resource identifier (optional)
+          
+        JIDs are encoded UTF-8. A grammar will be presented first, followed by specific clarifying and further restricting remarks.
+        
+            
+                
+<JID> ::= [<node>"@"]<domain>["/"<resource>]
+<node> ::= <conforming-char>[<conforming-char>]*
+<domain> ::= <hname>["."<hname>]*
+<resource> ::= <any-char>[<any-char>]*
+<hname> ::= <let>|<dig>[[<let>|<dig>|"-"]*<let>|<dig>]
+<let> ::= [a-z] | [A-Z]
+<dig> ::= [0-9]
+<conforming-char> ::= #x21 | [#x23-#x25] | [#x28-#x2E] | 
+                      [#x30-#x39] | #x3B | #x3D | #x3F | 
+                      [#x41-#x7E] | [#x80-#xD7FF] | 
+                      [#xE000-#xFFFD] | [#x10000-#x10FFFF]
+<any-char> ::= [#x20-#xD7FF] | [#xE000-#xFFFD] | 
+               [#x10000-#x10FFFF]
+                
+            
+        
+        
+            A domain identifier is a standard DNS hostname as specified in RFC952 http://www.ietf.org/rfc/rfc952.txt and RFC1123. http://www.ietf.org/rfc/rfc1123.txt It is case-insensitive 7-bit ASCII and limited to 255 bytes.  It is the only required component of a JID.
+        
+        
+            Node identifiers are restricted to 256 bytes, They may contain any Unicode character higher than #x20 with the exception of the following:
+            
+                #x22 (")
+                #x26 (&) 
+                #x27 (')
+                #x2F (/)
+                #x3A (:) 
+                #x3C (<) 
+                #x3E (>) 
+                #x40 (@) 
+                #x7F (del)
+                #xFFFE (BOM) 
+                #xFFFF (BOM) 
+            
+            Case is preserved, but comparisons will be made in case-normalized canonical form.
+        
+        
+            Resources identifiers are case-sensitive and are limited to 256 bytes. They may include any Unicode character greater than #x20, except #xFFFE and #xFFFF.
+        
+        
+            To date, resource identifiers have not had a fixed limit on their length.  This JEP seeks to limit it to 256 bytes for the following reasons:
+            
+                In order to perform JID manipulations safely, one cannot use stack space if there is no limit.  This forces temporary calculations onto the heap which is unnecessarily costly.
+                As a fixed length character field, a resource identifier is more easily stored in, searched on, and retrieved from a database.  If an end user may store an encyclopedia's worth of information in their resource, then the only way it can be stored without truncating it is to store it as a large object (BLOB or CLOB).  Depending on the database used, that makes it either grossly inefficient or impossible to search on.
+                There exist denial of service attacks stemming from an unlimited resource length.
+            
+            In a worst-case encoding, such as Han ideographs, 256 bytes will provide enough storage space for 64 character points.  This provides a lower bound on the number of characters a node may have in its resource.
+            Specifying limits in terms of bytes instead of characters is somewhat arbitrary once a lower bound for characters is established.  This JEP proposes limits in terms of bytes mainly because doing so results in parsing efficiency; specifically, an implementation does not have to un-encode the UTF-8 string for the sole purpose of further restricting character sets that require fewer than four bytes per character point.  It is sufficient to have a lower bound on characters and an upper bound on bytes.
+        
+    
+
diff --git a/xep-0030.xml b/xep-0030.xml
new file mode 100644
index 00000000..f2b8a06c
--- /dev/null
+++ b/xep-0030.xml
@@ -0,0 +1,1032 @@
+
+
+%ents;
+]>
+
+
+  
+    Service Discovery
+    This JEP defines a protocol for discovering (1) information about Jabber entities and (2) the items associated with such entities.
+    &LEGALNOTICE;
+    0030
+    Final
+    Standards Track
+    Standards JIG
+    
+      XMPP Core
+    
+    
+      JEP-0011
+      JEP-0094
+    
+    
+    disco
+    
+      disco#info
+      http://jabber.org/protocol/disco/info.xsd
+    
+    
+      disco#items
+      http://jabber.org/protocol/disco/items.xsd
+    
+    
+    &hildjj;
+    &pgmillard;
+    &reatmon;
+    &stpeter;
+    
+      2.2
+      2006-01-24
+      psa
+      Further specified and clarified security considerations relating to server handling of requests sent to bare JIDs.
+    
+    
+      2.1
+      2005-03-03
+      psa
+      Added paragraph to implementation notes about server handling of requests sent to bare JIDs.
+    
+    
+      2.0
+      2004-07-20
+      psa
+      Per a vote of the Jabber Council, advanced status to Final.
+    
+    
+      1.10
+      2004-06-29
+      psa/jjh
+      Defined security considerations; changed extended presence example to use a fictitious protocol; further specified publish feature; defined registry submissions.
+    
+    
+      1.9
+      2004-05-27
+      psa
+      Clarified error conditions.
+    
+    
+      1.8
+      2004-05-21
+      psa
+      Moved remaining feature negotiation text to JEP-0020.
+    
+    
+      1.7
+      2004-05-13
+      psa
+      Added implementation note regarding flexibility of feature and item results; final editorial cleanup.
+    
+    
+      1.6
+      2004-05-11
+      psa
+      Corrected examples of publishing available items; further clarified nature of node hierarchies.
+    
+    
+      1.5
+      2004-05-10
+      psa
+      Added clarifying note about node hierarchies.
+    
+    
+      1.4
+      2004-05-07
+      psa
+      Clarified usage of "directory"; added section defining the relationship between an entity and its associated items.
+    
+    
+      1.3
+      2004-04-23
+      psa
+      Further clarified item-publication protocol; moved some feature negotiation text to JEP-0020; added information about registry of well-known service discovery nodes; added implementation notes regarding tree-walking and large result sets; incorporated additional Call for Experience suggestions.
+    
+    
+      1.2
+      2004-04-20
+      psa
+      Editorial cleanup; incorporated some Call for Experience suggestions.
+    
+    
+      1.1
+      2004-03-15
+      psa
+      Described requirements, syntax, and use cases in a more formal manner; corrected several errors in the examples and schemas; defined Jabber Registrar procedures; added a number of references; specified XMPP error handling.
+    
+    
+      1.0
+      2003-04-21
+      psa
+      Per a vote of the Jabber Council, advanced status to Draft; also added XML schemas.
+    
+    
+      0.13
+      2003-02-25
+      pgm
+      Added remarks about empty node attributes; described semantics regarding multiple identity elements.
+    
+    
+      0.12
+      2003-02-06
+      pgm
+      Added support for IQ-set; added example for disco#info to a specific node.
+    
+    
+      0.11
+      2002-12-17
+      psa
+      Added support for the 'node' attribute per discussion on the Standards-JIG list in order to support items that are not JID-addressable.
+    
+    
+      0.10
+      2002-11-21
+      psa
+      Changed <feature type='foo'/> to <feature var='foo'/> to track changes in feature negotiation (JEP-0020); added initial registry parameters.
+    
+    
+      0.9
+      2002-11-07
+      psa
+      Added support for empty result sets in disco#item.
+    
+    
+      0.8
+      2002-11-01
+      psa
+      Removed the max, start, and total attributes for item queries (this will be handled by a generic paging JEP); added "http://jabber.org/protocol/feature-neg" namespace as a feature to signal negotiability regarding one or more features.
+    
+    
+      0.7
+      2002-10-28
+      psa
+      Cleaned up the feature text and examples.
+    
+    
+      0.6
+      2002-10-27
+      psa
+      Added the 'category' attribute to the <feature/> element; added security, IANA, and Jabber Registrar considerations; added a number of examples.
+    
+    
+      0.5
+      2002-10-15
+      psa
+      Total overhaul and simplification.
+    
+    
+      0.4
+      2002-07-16
+      psa
+      Major additions and fixes, many more examples.
+    
+    
+      0.3
+      2002-05-30
+      psa
+      Re-organized around use cases, made some minor fixes.
+    
+    
+      0.2
+      2002-05-05
+      psa
+      Incorporated comments from co-authors and added notes.
+    
+    
+      0.1
+      2002-05-03
+      psa
+      Initial draft.
+    
+  
+
+  
+    The ability to discover information about entities on the Jabber network is extremely valuable. Such information might include features offered or protocols supported by the entity, the entity's type or identity, and additional entities that are associated with the original entity in some way (often thought of as "children" of the "parent" entity). While mechanisms for doing so are not defined in &xmppcore;, several protocols have been used in the past within the Jabber community for service discovery, specifically &jep0011; and &jep0094;. However, those protocols are perceived to be inadequate for several reasons:
+    
+      Neither Jabber Browsing nor Agent Information is easily extensible. For example, the categories and subcategories listed for JID-Types in JEP-0011 are explicitly defined as the only official categories, and any additions to the list of JID-Types would require a modification to JEP-0011. While the Jabber Browsing specification does allow for the use of unofficial categories and types prefixed with the string 'x-', this introduces migration issues. This lack of flexibility violates one of the Jabber community's core &jep0134;.
+      In Agent Information, there is no way to advertise supported features. While Jabber Browsing includes such a mechanism, the only way to express the availability of a feature is to advertise a supported protocol namespace. Yet some features may not be uniquely associated with a protocol namespace, which are one implementation of features but not the only one.
+      A Jabber Browsing result returns a combination of (1) namespaces supported by a Jabber Entity, (2) items associated with a Jabber Entity, and (3) namespaces supported by the associated items. This approach mixes information levels and requires parents to know everything about child nodes, thereby introducing significant confusion.
+      In both Jabber Browsing and Agent Information, items must be addressable as JIDs; however, this may not be possible in some applications.
+    
+    This JEP addresses the perceived weaknesses of both the Jabber Browsing and Agent Information protocols. The result is a standards-track protocol for service discovery (often abbreviated to "disco", as is familiar in protocols such as &w3soap;).
+  
+
+  
+    The authors have designed the service discovery protocol with the following requirements in mind:
+    
+      The protocol MUST support all functionality supported by the protocols it supersedes (Jabber Browsing and Agent Information).
+      
+        There are three kinds of information that need to be discovered about an entity:
+        
+          its basic identity (type and/or category)
+          the features it offers and protocols it supports
+          any additional items associated with the entity, whether or not they are addressable as JIDs
+        
+        All three MUST be supported, but the first two kinds of information relate to the entity itself whereas the third kind of information relates to items associated with the entity itself; therefore two different query types are needed.
+      
+      Discovering information about a child item MUST be accomplished by sending a separate discovery request to that item, not to the parent entity. (One result of this is that discovering complete information about an entire tree will require multiple request/response pairs in order to "walk the tree".)
+      The lists of identities and features MUST be flexible.
+      The protocol itself MUST be extensible.
+    
+  
+
+  
+    
+      A requesting entity may want to discover information about another entity on the network. The information desired generally is of two kinds:
+      
+        The target entity's identity. In disco, an entity's identity is broken down into its category (server, client, gateway, directory, etc.) and its particular type within that category (IM server, phone vs. handheld client, MSN gateway vs. AIM gateway, user directory vs. chatroom directory, etc.). This information helps requesting entities to determine the group or "bucket" of services into which the entity is most appropriately placed (e.g., perhaps the entity is shown in a GUI with an appropriate icon). An entity MAY have multiple identities. When multiple identity elements are provided, the name attributes for each identity element SHOULD have the same value.
+        
+        The features offered and protocols supported by the target entity. This information helps requesting entities determine what actions are possible with regard to this entity (registration, search, join, etc.), what protocols the entity supports, and specific feature types of interest, if any (e.g., for the purpose of feature negotiation).
+      
+      In order to discover such information, the requesting entity MUST send an IQ stanza of type "get", containing an empty <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, to the JID of the target entity (the 'to' address is REQUIRED and MUST contain a valid JID; a 'node' attribute on the &QUERY; element is OPTIONAL as described in the Info Nodes and Items Nodes section of this document):
+      
+  
+
+      ]]>
+      The target entity then MUST either return an IQ result, or return an error (see the Error Conditions section of this document). The result MUST contain a <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more <identity/> elements and one or more <feature/> elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.) Each <identity/> element MUST possess 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity. Each <feature/> element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity. Preferably, both the category/type values and the feature values will be registered in a public registry, as described in the Jabber Registrar Considerations section of this document.
+      
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
+    ]]>
+      If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an ¬found; error, unless doing so would violate the privacy and security considerations specified in XMPP Core and &xmppim; or local privacy and security policies (see also the Security Considerations of this document):
+      
+  
+  
+    
+  
+
+      ]]>
+      If privacy and security considerations or policies prevent the server or other authoritative entity from returning an ¬found; error, it SHOULD return a &unavailable; error instead:
+      
+  
+  
+    
+  
+
+      ]]>
+      When an entity sends a disco#info request to a bare JID (<account@domain.tld>) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the Security Considerations section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).
+      
+  
+
+      ]]>
+      Here we assume that shakespeare.lit is trusted by capulet.com and that the account <juliet@capulet.com> is a registered account:
+      
+  
+    
+  
+
+      ]]>
+      A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:
+      
+  
+
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+  
+]]>
+      Another example of this is sending a query to a specific connected resource for an IM user:
+      
+  
+
+
+
+  
+    
+    
+    
+  
+
+      ]]>
+    
+    
+      A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as Items Nodes rather than as info nodes:
+      
+  
+
+      ]]>
+      
+  
+    
+  
+
+      ]]>
+    
+  
+
+  
+    
+      In order for the requesting entity to discover the items associated with a Jabber Entity, it MUST send an IQ stanza of type "get" to the target entity, containing an empty <query/> element qualified by the 'http://jabber.org/protocol/disco#items' namespace:
+      
+  
+
+      ]]>
+      The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an <item/> child of a <query/> element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the <item/> child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):
+      
+  
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
+      ]]>
+      The <item/> element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.
+      If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:
+      
+  
+
+      ]]>
+      As with disco#info requests, when an entity sends a disco#items request to a bare JID (<account@domain.tld>) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the Security Considerations section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:
+      
+  
+
+      ]]>
+      Here we assume that shakespeare.lit is trusted by capulet.com and that the account <juliet@capulet.com> has two available resources:
+      
+  
+    
+    
+  
+
+      ]]>
+    
+    
+      It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &jep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &jep0060; component. In order to handle such items, the <item/> element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.
+      The value of the node attribute may or may not have semantic meaning; from the perspective of Service Discovery, a node is merely something that is associated with an entity. In order to discover more about the node, the requesting entity MUST query the entity's JID while specifying the node. If the value of the 'node' attribute has semantic meaning, that meaning is provided by the using protocol or application, not by the Service Discovery protocol. A node attribute SHOULD NOT be included unless it is necessary to provide or discover information about an entity that cannot be directly addressed as a JID (i.e., if the associated item can be addressed as a JID, do not include a node). The value of the 'node' attribute MUST NOT be null.
+      In the following example, a user requests all available items from an online catalog service:
+      
+  
+
+        ]]>
+        If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each <item/> element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):
+        
+  
+    
+    
+    
+  
+
+      ]]>
+      There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.
+      
+  
+
+      ]]>
+      The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.
+      
+  
+    
+    
+    
+    
+    .
+    .
+    .
+  
+
+      ]]>
+      The requesting entity can then query further if desired:
+      
+  
+
+      ]]>
+      
+  
+    
+    
+  
+
+      ]]>
+    
+    
+      The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.
+      If the hierarchy category is used, every node in the hierarchy MUST be identified as either a branch or a leaf; however, since a node MAY have multiple identities, any given node MAY also possess an identity other than "hierarchy/branch" or "hierarchy/leaf".
+      Therefore, a disco#info request to the "music/D" node shown above would yield <identity category='hierarchy' type='branch'/> while a disco#info request to the "music/D/dowland-firstbooke" node would yield <identity category='hierarchy' type='leaf'/> (and each node could yield additional identities as appropriate).
+    
+    
+      This section explains in greater detail the relationship between an entity and its associated items.
+      In general, the items returned by an entity in a disco#items result MUST be items over which the entity has some relationship of ownership -- either direct control over the item itself (e.g., Publish-Subscribe nodes owned by the entity) or at least the ability to provide or vouch for the item in a canonical way on the Jabber network (e.g., groupchat rooms directly hosted by a multi-user chat service or IRC channels to which a gateway provides access).
+      Such a relationship does not constrain the relationship between the owning entity's address and the address of the associated entity. In particular, any of the following scenarios is perfectly acceptable:
+      
+        Upon querying an entity (JID1) for items, one receives a list of items that can be addressed as JIDs; each associated item has its own JID, but no such JID equals JID1.
+        Upon querying an entity (JID1) for items, one receives a list of items that cannot be addressed as JIDs; each associated item has its own JID+node, where each JID equals JID1 and each NodeID is unique.
+        Upon querying an entity (JID1+NodeID1) for items, one receives a list of items that can be addressed as JIDs; each associated item has its own JID, but no such JID equals JID1.
+        Upon querying an entity (JID1+NodeID1) for items, one receives a list of items that cannot be addressed as JIDs; each associated item has its own JID+node, but no such JID+node equals JID1+NodeID1 and each NodeID is unique in the context of the associated JID.
+      
+      In addition, the results MAY also be mixed, so that a query to a JID or a JID+node could yield both (1) items that are addressed as JIDs and (2) items that are addressed as JID+node combinations.
+      Consider the case of an entity that owns multiple publish-subscribe nodes -- for example, a person who owns one such node for each of his music players. The following examples show what the disco#items query and result might look like (using the protocol defined in &jep0118;):
+      
+  
+
+      ]]>
+      The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service: 
+      
+  
+    
+    
+    
+  
+
+      ]]>
+    
+  
+
+  
+    The server handling rules defined in XMPP IM require that the server itself reply on behalf of the user if the 'to' attribute of an IQ get or set is of the form <user@host>. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in &jep0054;) in a way that makes it possible for other entities to retrieve that information even if the user is unavailable. The service discovery specification defined herein builds on that notion by enabling a user to publish some of its service discovery information to the server, which shall store that information in persistent storage and return that information when other entities request it from the user's "bare JID" (user@host), either alone or in combination with a particular node.
+    Implementations of service discovery that are built into instant messaging servers SHOULD allow users to publish items in this fashion, although they are not required to do so in order to conform to the service discovery specification. In order to discover whether his or her server supports this publish functionality, the user SHOULD send a disco#info request to his or her server:
+    
+  
+
+    ]]>
+    If the server supports service discovery publishing and the server wishes to disclose that fact to the user, it MUST include a feature of 'http://jabber.org/protocol/disco#publish' in its response.
+    
+  
+    
+    ...
+    
+    ...
+  
+
+    ]]>
+
+    In order to publish items, an entity uses an IQ-set transaction to its server, which is responsible for responding to requests on behalf of that entity. Each <item/> child element of the parent query MUST possess the following attributes:
+    
+      action -- specifies the action to be taken for the item
+      jid -- specifies the Jabber ID of the item "owner" or location
+    
+    The <item/> element MAY also possess the following attributes:
+    
+      name -- specifies a natural-language name for the item.
+      node -- specifies the particular node associated with the JID of the item "owner" or location
+    
+    The allowable values for the 'action' attribute are "update" and "remove"). If the action is "update", the server MUST either create a new entry (if the node and jid combination does not already exist) or overwrite an existing entry. If the action is "remove", the item MUST be removed from persistent storage.
+    The following example shows a user publishing a list of his biological children to a well-known (but fictitious) service discovery node.
+    
+  
+    
+    
+    
+  
+
+    ]]>
+
+    
+    ]]>
+
+    Subsequent queries to "jid='kinglear@shakespeare.lit'" and "node='jabber:iq:kids'" will yield the list shown above (absent the 'action' attributes).
+
+    If the server or service does not support persistent storage, it MUST respond to IQ-set requests with a &feature; error.
+
+    
+  
+    
+    
+    
+  
+  
+    
+  
+
+    ]]>
+
+  
+
+  
+    In order to retrieve full information about an entity and its associated items, the requesting application needs to "walk the tree" of items. Naturally, this can result in a large number of requests and responses. The requesting application SHOULD NOT send follow-up requests to all items associated with an entity if the list of such items is long (e.g., more than twenty items). Entities that will routinely host a large number of items (e.g., IRC gateways or NNTP services) SHOULD structure nodes into hierarchies and/or provide more robust searching capabilities, for example via &jep0055;; they SHOULD NOT return extremely large result sets via Service Discovery.
+    This JEP does not require that a responding entity must return the same results in response to the same request from different requesting entities (e.g., an entity could return a different list of items or features based on the degree to which it trusts the requesting entity, or based on the known capabilities of the requesting entity). However, the responding entity SHOULD return the same <identity/> element (category+type) to all disco#info requests sent to the same JID+node combination.
+  
+
+  
+    If a specific entity (JID or JID+node) does not support the disco namespace, refuses to return disco results to the specific requesting entity, or refuses to return disco results to any requesting entity, it SHOULD return an appropriate error message (such as &unavailable;, &forbidden;, or ¬allowed;, respectively). One example is shown below.
+    
+  
+  
+    
+  
+
+    ]]>
+    Other error conditions may be appropriate depending on the application.
+    The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &jep0086;).
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    Condition Cause
&feature; The sender has attempted to publish items but the server does not support the Publishing Available Items feature.
¬found; The JID or JID+NodeID of the specified target entity does not exist and that fact can be divulged in accordance with privacy and security considerations and policies.
&unavailable; The target entity does not support this protocol, or the specified target entity does not exist but that fact cannot be divulged because of pricacy and security considerations.
+    The other error conditions specified in XMPP Core MAY be returned as well (&forbidden;, ¬allowed;, ¬authorized;, etc.), including application-specific conditions.
+    As noted above, if an entity has no associated items, it MUST return an empty &QUERY; element (rather than an error) in response to a disco#items request.
+  
+
+  
+    Certain attacks may be made easier when an entity discloses (via disco#info responses) that it supports particular protocols or features; however, in general, service discovery introduces no new vulnerabilities, since a malicious entity could discover that the responding entity supports such protocols and features by sending requests specific to those protocols rather than by sending service discovery requests.
+    A responding entity is under no obligation to return the identical service discovery response when replying to service discovery requests received from different requesting entities, and MAY perform authorization checks before responding in order to determine how (or whether) to respond.
+    A server MUST carefully control access to any functionality that would enable directory harvesting attacks or that would leak information about connected or available resources; this functionality consists of the server's replies to disco#info and disco#items requests sent to bare JIDs (addresses of the form account@domain.tld) hosted on the server, since the server responds to such requests on behalf of the account. The following rules apply to the handling of service discovery requests sent to bare JIDs:
+    
+      
+        In response to a disco#info request, the server MUST return a &unavailable; error if one of the following is true:
+        
+          The target entity does not exist (no matter if the request specifies a node or not).
+          The requesting entity is not authorized to receive presence from the target entity (i.e., via a presence subscription of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network).
+        
+      
+      
+        In response to a disco#items request, the server MUST return an empty result set if:
+        
+          The target entity does not exist (no matter if the request specifies a node or not).
+          The request did not specify a node, the only items are available resources (as defined in RFC 3921), and the requesting entity is not authorized to receive presence from the target entity (i.e., via a presence subscription of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). However, the server MAY return items other than available resources (if any).
+        
+      
+    
+  
+  
+    This JEP requires no interaction with &IANA;.
+  
+  
+    
+      The ®ISTRAR; includes the 'http://jabber.org/protocol/disco#info' and 'http://jabber.org/protocol/disco#items' namespaces in its registry of protocol namespaces.
+    
+    
+      
+        The Jabber Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the <identity/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-categories.html>.
+        
+          ®PROCESS;
+          
+  the name of the category (all lower-case)
+  a natural-language description of the category
+  
+    the name of the specific type (all lower-case)
+    a natural-language description of the type
+    the document (e.g., JEP) in which this type is specified
+  
+
+          ]]>
+          The registrant may register more than one category at a time, each contained in a separate <category/> element. The registrant may also register more than one type at a time, each contained in a separate <type/> child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).
+        
+        
+          This JEP defines a "hierarchy" category that contains two and only two types: "branch" and "leaf"; the associated registry submission is as follows:
+          
+  hierarchy
+  
+    An entity that exists in the context of a 
+    service discovery node hierarchy.
+  
+  
+    branch
+    
+      A "container node" for other entities in a 
+      service discovery node hierarchy.
+    
+    JEP-0030
+  
+  
+    leaf
+    
+      A "terminal node" in a service discovery 
+      node hierarchy.
+    
+    JEP-0030
+  
+
+          ]]>
+        
+      
+      
+        The Jabber Registrar shall maintain a registry of features for use as values of the 'var' attribute of the <feature/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-vars.html>.
+        
+          ®PROCESS;
+          
+  a natural-language description of the feature
+  the document (e.g., JEP) in which this feature is specified
+]]>
+          The registrant may register more than one feature at a time, each contained in a separate <feature/> element.
+        
+        
+          This JEP defines a "publish" feature that is not associated with either of the protocol namespaces listed above; the registry submission for this feature is as follows:
+          
+  the service discovery "publish" feature
+  JEP-0030
+
+          ]]>
+        
+      
+      
+        A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the Jabber Registrar shall maintain a registry of well-known service discovery nodes; see <http://www.jabber.org/registrar/disco-nodes.html>.
+        
+          ®PROCESS;
+          
+  the name of the node
+  a natural-language description of the node
+  the document (e.g., JEP) in which this node is specified
+
+          ]]>
+          The registrant may register more than one node at a time, each contained in a separate <node/> element.
+        
+      
+    
+    
+      As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).
+      The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).
+      
+      
+  
+
+      ]]>
+      
+      
+  
+
+      ]]>
+      The following submission registers the "disco" querytype.
+      
+  disco
+  http://jabber.org/protocol/disco
+  enables interaction for the purpose of service discovery
+  JEP-0030
+  
+    
+      node
+      the (optional) service discovery node
+    
+    
+      request
+      the service discovery request type
+      
+        
+	  info
+          a service discovery information (disco#info) request
+        
+        
+	  items
+          a service discovery items (disco#items) request
+        
+      
+    
+    
+      type
+      the IQ type
+      
+        
+	  get
+          an IQ get
+        
+        
+	  set
+          an IQ set (disco publish)
+        
+      
+    
+  
+
+
+      ]]>
+    
+  
+  
+    
+      
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0030: http://www.jabber.org/jeps/jep-0030.html
+    
+  
+
+  
+    
+      
+        
+        
+      
+      
+    
+  
+
+  
+    
+      
+        
+          
+          
+          
+        
+      
+    
+  
+
+  
+    
+      
+        
+          
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+      ]]>
+    
+    
+      
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0030: http://www.jabber.org/jeps/jep-0030.html
+    
+  
+
+  
+    
+      
+        
+      
+      
+    
+  
+
+  
+    
+      
+        
+          
+            
+              
+                
+                
+              
+            
+          
+          
+          
+          
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+      ]]>
+    
+  
+
+  Peter Millard, a co-author of this specification from version 0.1 through version 2.2, died on April 26, 2006.
+
+
diff --git a/xep-0031.xml b/xep-0031.xml
new file mode 100644
index 00000000..51c3be61
--- /dev/null
+++ b/xep-0031.xml
@@ -0,0 +1,2328 @@
+
+
+%ents;
+]>
+
+
+
+
+
+
+
+A Framework For Securing Jabber Conversations
+
+
+
+Although the value and utility of contemporary instant messaging 
+systems, like Jabber, are now indisputable, current security 
+features to protect message data are generally inadequate for 
+many deployments; this is particularly true in security conscious 
+environments like large, commercial enterprises and government 
+agencies. These current features suffer from issues of 
+scalability, usability, and supported features. Furthermore, there is a 
+lack of standardization.
+
+We present a protocol to allow communities of Jabber users to 
+apply cryptographic protection to selected conversation data.
+
+
+
+0031
+
+
+
+Deferred
+
+
+
+Standards Track
+
+
+
+Standards
+
+
+
+
+Paul
+
+
+Lloyd
+
+
+paul_lloyd@hp.com
+
+
+paul_lloyd@jabber.hp.com (private)
+
+
+
+
+
+0.2
+
+
+2002-07-09
+
+
+PCL
+
+
+updated to reflect group consensus to incorporate XML Encryption, as well
+as other group comments from Draft 0.9.
+
+
+
+
+
+0.1
+
+
+2002-05-07
+
+
+PCL
+
+
+initial version
+
+
+
+
+
+
+
+
+
+Instant messaging has clearly crossed the chasm from experimental 
+to mainstream in a short amount of time. It is particularly 
+interesting to note the extent to which the employees and 
+affiliates of large enterprises have adopted instant messaging as 
+part of their daily professional lives. IM is no longer simply 
+used on Friday evening to select which movie to watch; it's now 
+used on Monday morning to select which company to acquire.
+
+
+
+While the benefits of IM are clear and compelling, the risks 
+associated with sharing sensitive information in an IM 
+environment are often overlooked. We need a mechanism that 
+permits communities of users to protect their IM conversations. 
+This document presents an extension protocol that can be 
+incorporated into the existing Jabber protocol to provide such a 
+mechanism. We hope that this protocol spurs both interest
+and further investigation into mechanisms to protect Jabber 
+conversations. We also hope that the Jabber community can 
+accelerate the adoption of standardized security mechanisms.
+
+
+
+In addition to its ability to protect traditional messaging data,
+the proposed protocol may also serve as a foundation for securing
+other data transported via other Jabber extensions.
+
+
+
+We use the following terms throughout this document to describe 
+the most relevant aspects of the IM environment that we wish to 
+address:
+
+
+
+
+
+user. A user is simply any Jabber user. Users are uniquely 
+identified by a JID; they connect to Jabber hosts using a 
+Jabber node.
+
+
+Users produce and consume information, and we wish to 
+provide them with mechanisms that can be used to protect 
+this information.
+
+
+
+
+community. A community is a collection of users who wish to 
+communicate via Jabber. No restrictions or assumptions are 
+made about the size of communities or the geographical, 
+organizational, or national attributes of the members. 
+Communities are assumed to be dynamic and ad-hoc. Users 
+typically join communities by the simple act of invitation. 
+All members of a community are assumed to be peers.
+
+
+The members of communities share information among 
+themselves, and we wish to provide them with mechanisms 
+that can permit information to only be shared by community 
+members.
+
+
+
+
+conversation. A conversation is the set of messages 
+that flows among the members of a community via some 
+network. Conversations consist of both the actual 
+conversation data produced and consumed by the various 
+users as well as the Jabber protocol elements that 
+transport it. Members participate in a conversation when 
+they are the source or destination of this traffic.
+
+
+In hostile network environments, like the Internet, 
+conversation data is vulnerable to a variety of well-known 
+attacks.
+
+
+
+
+
+Other Jabber and IM terms are used in a traditional, intuitive 
+fashion.
+
+
+
+
+
+
+
+The proposed protocol is designed to address the specific 
+requirements and considerations presented in this section.
+
+
+
+
+
+
+
+A secure IM system must permit conversation participants to 
+preserve the following properties of their conversation data:
+
+
+
+
+
+confidentiality. Conversation data must only be disclosed 
+to authorized recipients
+
+
+
+
+integrity. Conversation data must not be altered
+
+
+
+
+data origin authentication. Recipients must be able to 
+determine the identity of the sender and trust that the 
+message did, in fact, come from the sender. It is important 
+to note that this requirement does not include the 
+requirement of a durable digital signature on conversation 
+data.
+
+
+
+
+replay protection. Recipients must be able to detect and 
+ignore duplicate conversation data.
+
+
+
+
+      
+These are established, traditional goals of information security 
+applied to the conversation data. In the IM environment, these 
+goals protect against these attacks:
+
+
+
+
+
+eavesdropping, snooping, etc.
+
+
+
+
+masquerading as a conversation participant
+
+
+
+
+forging messages
+
+
+
+
+
+Preserving the availability of conversation data is not addressed 
+by this protocol.
+
+
+
+Preserving the anonymity of conversation participants is an 
+interesting topic which we defer for future exploration.
+
+
+
+Finally, note that this protocol does not concern any authentication
+between a Jabber node and a Jabber host.
+
+
+
+
+
+
+
+A secure IM system must support a data classification feature through the use
+of security labeling. Conversation participants must be
+able to associate a security label with each piece of 
+conversation data. This label may be used to specify a data 
+classification level for the conversation data.
+
+
+
+
+
+
+
+It is easy to imagine Jabber systems in which the servers play 
+active, fundamental roles in the protection of conversation 
+data. Such systems could offer many advantages, like:
+
+
+
+
+
+allowing the servers to function as credential issuing 
+authorities,
+
+
+
+
+allowing the servers to function as policy enforcement 
+points.
+
+
+
+
+
+Unfortunately, such systems have significant disadvantages when 
+one considers the nature of instant messaging:
+
+
+
+
+
+Many servers may be untrusted, public servers.
+
+
+
+
+In many conversation communities, decisions of trust and 
+membership can only be adequately defined by the members 
+themselves.
+
+
+
+
+In many conversation communities, membership in the 
+community changes in real time based upon the dynamics of 
+the conversation.
+
+
+
+
+In many conversation communities, the data classifaction of 
+the conversation changes in real time based upon the 
+dynamics of the conversation.
+
+
+
+
+
+Furthermore, the widespread use of gateways to external IM 
+systems is a further complication.
+
+
+
+Based on this analysis, we propose that security be entirely 
+controlled in an end to end fashion by the conversation 
+participants themselves via their user agent software.
+
+
+
+
+
+
+
+We believe that, ultimately, trust decisions are in the hands of 
+the conversation participants. A security protocol and 
+appropriate conforming user agents must provide a mechanism for them to make 
+informed decisions.
+
+
+
+
+
+
+
+One of the accepted axioms of security is that people must avoid 
+the temptation to start from scratch and produce new, untested 
+algorithms and protocols. History has demonstrated that such 
+approaches are likely to contain flaws and that considerable time 
+and effort are required to identify and address all of these 
+flaws. Any new security protocol should be based on existing, 
+established algorithms and protocols.
+
+
+
+
+
+
+
+
+
+Any new IM security protocol must integrate smoothly into the 
+existing IM environment, and it must also recognize the nature of 
+the transactions performed by conversation participants. These 
+considerations are especially important:
+
+
+
+
+
+dynamic communities. The members of a community are defined 
+in near real time by the existing members.
+
+
+
+
+dynamic conversations. Conversations may involve any 
+possible subset of the entire set of community members.
+
+
+
+
+
+Addressing these considerations becomes especially crucial when 
+selecting a conference keying mechanism.
+
+
+
+
+
+
+
+Given the requirement to place the responsibility for the 
+protection of conversation data in the hands of the participants, 
+it is imperative to address some fundamental usability issues:
+
+
+
+
+
+First, overall ease of use is a requirement. For protocol 
+purposes, one implication is that some form of 
+authentication via passphrases is necessary. While we 
+recognize that this can have appalling consequences, 
+especially when we realize that a passphrase may be shared 
+by all of the community members, we also recognize the 
+utility.
+
+
+
+
+PKIs are well established in many large organizations, and 
+some communities will prefer to rely on credentials issued
+from these authorities. To ensure ease of use, we must 
+strive to allow the use of existing PKI credentials and 
+trust models rather than impose closed, Jabber-specific 
+credentials.
+
+
+
+
+Finally, performance must not be negatively impacted; this 
+is particularly true if we accept that most communities are 
+composed of human users conversing in real time. For 
+protocol purposes, one obvious implication is the desire to 
+minimize computationally expensive public key operations.
+
+
+
+
+
+We note that, in practice, the design and construction of user 
+agents will also have a major impact on ease of use.
+
+
+
+
+
+
+
+To successfully integrate into the existing Jabber environment, 
+an extension protocol for security must satisfy the following:
+
+
+
+
+
+It must be an optional extension of the existing Jabber protocol.
+
+
+
+
+It must be transparent to existing Jabber servers.
+
+
+
+
+It must function gracefully in cases where some community 
+members are not running a user agent that supports the 
+protocol.
+
+
+
+
+It must make good use of XML.
+
+
+
+
+It must avoid encumbered algorithms.
+
+
+
+
+It must be straightforward to implement using widely 
+available cryptographic toolkits.
+
+
+
+
+It must not require a PKI.
+
+
+
+
+
+Failure to accommodate these will impede or prohibit adoption of 
+any security protocol.
+
+
+
+
+
+
+
+
+
+
+
+Ultimately, conversation data is protected by the application of 
+keyed cryptographic operations. One operation is used to provide 
+confidentiality, and a separate operation is used to provide 
+integrity and data origin authentication. The keys used to 
+parameterize these operations are called conversation keys. Each 
+conversation should have its own unique set of conversation keys 
+shared among the conversation participants.
+
+
+
+Conversation keys are transported among the conversation 
+participants within a negotiated security session. A security session allows 
+pairs of conversation participants to securely share conversation keys
+throught all participants in the conversation as required.
+
+
+
+
+
+
+
+The following terms are used throughout this specification:
+
+
+
+
+
+initiator. The initiator is the user who requested a security session
+negotiation. Initiator's are identified by their JID.
+
+
+
+
+responder. The responder is the user who responded to a security session
+negotiation request. Responder's are identified by their JID.
+
+
+
+
+hmac. This indicates the HMAC algorithm. The notation hmac (key, value)
+indicates the HMAC computation of value using key.
+
+
+
+
+concatentation operator. The '|' character is used in character or octet
+string expressions to indicate concatenation.
+
+
+
+
+security session ID. A character string that uniquely identifies a
+security session between two users. Security session IDs MUST only
+consist of Letters, Digits, and these characters: '.', '+', '-',
+'_', '@'. Security session IDs are case sensitive.
+
+
+
+
+SS. This term indicates the security session secret that is agreed to
+during a security session negotiation.
+
+
+
+
+SKc. This term indicates the keying material used within a security session
+to protect confidentiality. The SKc is derived from the security session secret, SS.
+
+
+
+
+SKi. This term indicates the keying material used within a security session
+to protect integrity and to provide authnetication. The SKi is derived from the
+security session secret, SS.
+
+
+
+
+conversation key ID. A character string that uniquely identifies a
+conversation key shared by a community of users. Conversation key IDs MUST only
+consist of Letters, Digits, and these characters: '.', '+', '-',
+'_', '@'. Conversation key IDs are case sensitive. Conversation key IDs SHOULD
+be generated from at least 128 random bits.
+
+
+
+
+passphrase ID. A character string that uniquely identifies a
+passphrase shared by a community of users. Passphrase IDs MUST only
+consist of Letters, Digits, and these characters: '.', '+', '-',
+'_', '@'. Passphrase IDs are case sensitive.
+
+
+
+
+
+
+
+
+
+Since cryptographic operations are applied to data that is 
+transported within an XML stream, the protocol defines a set of 
+rules to ensure a consistent interpretation by all conversation 
+participants.
+
+
+
+
+
+Binary data, such as the result of an HMAC, is always transported 
+in an encoded form; the two supported encoding schemes are base64 
+and hex.
+
+
+
+Senders MAY include arbitrary white space within the character 
+stream. Senders SHOULD NOT include any other characters outside 
+of the encoding set.
+
+
+
+Receivers MUST ignore all characters not in the encoding set.
+
+
+
+
+
+
+
+Encrypted data, including wrapped cryptographic keys, are always
+wrapped per XML Encryption.
+
+
+
+
+
+
+
+
+HMACs are computed over a specific collection of attribute values 
+and character data; when computing an HMAC the following rules 
+apply:
+
+
+
+
+
+All characters MUST be encoded in UTF-8.
+
+
+
+
+The octets in each character MUST be processed in network 
+byte order.
+
+
+
+
+For a given element, the attribute values that are HMACed 
+MUST be processed in the specified order regardless of the 
+order in which they appear in the element tag.
+
+
+
+
+For each attribute value, the computation MUST only include 
+characters from the anticipated set defined in this 
+specification; in particular, white space MUST always be 
+ignored.
+
+
+
+
+For character data that is represented in an encoded form, 
+such as base64 or hex, the computation MUST only include 
+valid characters from the encoding set.
+
+
+
+
+
+
+
+
+
+The following algorithm is used to encrypt a character string, such as
+an XML element:
+
+
+
+
+
+The character string MUST be encoded in UTF-8.
+
+
+
+
+The octets in each character MUST be processed in network byte order.
+
+
+
+
+Appropriate cryptographic algorithm parameters, such as an 
+IV for a block cipher, are generated.
+
+
+
+
+
+
+
+
+
+
+
+In order to integrate smoothly with the existing Jabber protocol, 
+this protocol utilizes a new XML namespace, jabber:security.
+
+
+
+
+
+
+
+
+
+A security session is a pair-wise relationship between two users 
+in which the users have achieved the following:
+
+
+
+
+
+They have mutually authenticated each other using credentials acceptable to both.
+
+
+
+
+They have agreed on a set of key material known only to both.
+
+
+
+
+
+Security sessions are identified by a 3-tuple consisting of the following items:
+
+
+
+
+
+initiator. This is the JID of the user who initiated the session.
+
+
+
+
+responder.  This is the JID of the user who responded to the initiator's request.
+
+
+
+
+sessionId.  A label generated by the initiator.
+
+
+
+
+
+Security sessions are used to transport conversation keys between the conversation participants.
+
+
+
+Scalabilty is an immediate, obvious concern with such an approach. We expect this
+approach to be viable in practice because:
+
+
+
+
+
+The number of participants in typical, interactive conversations is generally on the order of 10^1.
+
+
+
+
+New participants are usually invited to dynamically join a 
+conversation by being invited by an existing participant; 
+this existing participant is the only one who needs to 
+establish a security session with the new participant, 
+because this single security session can be used to 
+transport all of the required conversation keys.
+
+
+
+
+User agents can permit the lifetime of security sessions to 
+last long enough to allow transport of conversation keys 
+for a variety of converstions.
+
+
+
+
+Conversation keys can be established with a suitable lifetime.
+
+
+
+
+
+Other approaches, including the incorporation of more 
+sophisticated conference keying algorithms, are a topic for 
+future exploration.
+
+
+
+
+
+
+
+Security sessions are negotiated using an authenticated Diffie-Hellman key agreement 
+exchange. The two goals of the exchange are to perform the mutual authentication
+and to agree to a secret that is know only to each.
+
+
+
+The exchange also allows the parties to negotiate the various algorithms
+and authentication mechanisms that will be used.
+
+
+
+Once the pair agree on a shared secret, they each derive key material from the
+secret; this key material is used to securely transport the conversation keys,
+which are used to actually protect conversation data.
+
+
+
+The protocol data units (PDUs) that comprise the exchange are transported
+within existing Jabber protocol elements.
+
+
+
+
+
+
+
+
+<!ELEMENT session1
+          (nonce, keyAgreement, algorithms, authnMethods) >
+<!ATTLIST session1
+          version CDATA #REQUIRED
+          initiator CDATA #REQUIRED
+          responder CDATA #REQUIRED
+          sessionId CDATA #REQUIRED
+          hmac (hmac-sha1) #REQUIRED >
+
+<!ELEMENT nonce
+          (#PCDATA)* >
+<!ATTLIST nonce
+          encoding (base64 | hex) #REQUIRED >
+
+<!ELEMENT keyAgreement
+          (dh) >
+
+<!ELEMENT dh
+          (publicKey) >
+<!ATTLIST dh
+          group (modp1024 | modp2048 | modp4096 | modp8192) #REQUIRED >
+
+<!ELEMENT publicKey
+          (#PCDATA)* >
+<!ATTLIST publicKey
+          encoding (base64 | hex) #REQUIRED >
+
+<!ELEMENT algorithms
+          (algorithm)+ >
+
+<!ELEMENT algorithm
+          (confAlg, hmacAlg) >
+
+<!ELEMENT confAlg EMPTY >
+<!ATTLIST confAlg
+          cipher (3des-cbc | aes-128-cbc | aes-256-cbc) #REQUIRED >
+
+<!ELEMENT hmacAlg EMPTY >
+<!ATTLIST hmacAlg
+          alg (hmac-sha1 | hmac-md5) #REQUIRED>
+
+<!ELEMENT authnMethods
+          (authnMethod)+ >
+
+<!ELEMENT authnMethod
+          (digSig | passphrase) >
+
+<!ELEMENT digSig
+          (certificate+, caCertificate*) >
+<!ATTLIST digSig
+          alg (rsa) #REQUIRED>
+
+<!ELEMENT certificate
+          (#PCDATA)* >
+<!ATTLIST certificate
+          type (x509 | pkcs7) #REQUIRED
+          encoding (base64 | hex) #REQUIRED >
+
+<!ELEMENT caCertificate
+          (#PCDATA)* >
+<!ATTLIST caCertificate
+          type (x509 | pkcs7) #REQUIRED
+          encoding (base64 | hex) #REQUIRED >
+
+<!ELEMENT passphrase EMPTY >
+<!ATTLIST passphrase
+          passphraseId CDATA #REQUIRED >
+
+
+<!ELEMENT session2
+          (nonce, keyAgreement, algorithm, authnMethod, authenticator) >
+<!ATTLIST session2
+          version CDATA #REQUIRED
+          initiator CDATA #REQUIRED
+          responder CDATA #REQUIRED
+          sessionId CDATA #REQUIRED
+          hmac (hmac-sha1) #REQUIRED >
+
+<!ELEMENT authenticator
+          (#PCDATA)* >
+<!ATTLIST authenticator
+          encoding (base64 | hex) #REQUIRED>
+
+
+<!ELEMENT session3
+          (authenticator, keyTransport*) >
+<!ATTLIST session3
+          version CDATA #REQUIRED
+          initiator CDATA #REQUIRED
+          responder CDATA #REQUIRED
+          sessionId CDATA #REQUIRED
+          hmac (hmac-sha1) #REQUIRED >
+
+
+
+
+
+
+
+The initiator's user agent employs the following algorithm to generate the session1 PDU:
+
+
+
+
+
+Appropriate values for the version, initiator, responder, 
+sessionId, and hmac attributes are assembled. The version of 
+this specification is '1.0'. The values of initiator and 
+responder MUST be the JIDs of the two participants, 
+respectively.
+
+
+
+
+The nonce is prepared by first generating a string of 20 
+random octets (160 random bits). The octets are then 
+encoded into a string of 40 hex characters representing the 
+random string.
+
+
+
+
+A Diffie-Hellman group is selected. The appropriate values 
+for g and p will be used to generate the initiator's public 
+key.
+
+
+
+
+An ephemeral private key, x, is generated using g and p 
+for the selected group. This key MUST be generated using an 
+appropriate random number source. The corresponding public 
+key, g^x, is generated and encoded.
+
+
+
+
+The desired set of confidentiality and HMAC cryptographic 
+algorithms is selected. The manner in which these 
+algorithms are selected and all related policy issues are 
+outside the scope of this specification.
+
+
+
+
+The desired set of authentication algorithms is selected. 
+The manner in which these algorithms are selected and all 
+related policy issues are outside the scope of this 
+specification. When the digital signature form of 
+authentication is selected, the relevant end-entity 
+certificate and, optionally, a chain of CA certificates 
+representing a validation path, is assembled and encoded. A 
+set of trusted CA certificates MAY optionally be included 
+via caCertificate elements; if so, the set MUST include the 
+issuer of the initiator's end-entity certificate.
+
+
+
+
+
+These values are then used to prepare the XML session1 element; 
+this element is transmitted via the existing Jabber iq mechanism:
+
+
+
+<iq from="initiator's JID" to="responder's JID" type="get" id="whatever">
+   <query xmlns="jabber:security:session">
+      <session1>...</session1>
+   </query>
+</iq>
+
+
+
+
+
+
+
+The responder's user agent employs the following algorithm to process each session1 PDU:
+
+
+
+
+
+The version and hmac attributes are checked against the 
+values supported by the user agent. An unsupported version 
+results in an error code of 10000, and an unsupported hmac 
+results in an error code of 10001. The responder attribute MUST
+match the JID of the receiver; a mismatch results in an error code of 10009
+
+
+
+
+The nonce is decoded, and its length is checked. The nonce 
+may also be checked to detect replays. An invalid nonce 
+results in an error code of 10002.
+
+
+
+
+The Diffie-Hellman group is checked against the values 
+supported by the user agent. An unsupported group results 
+in an error code of 10003
+
+
+
+
+The desired confidentiality and HMAC cryptographic 
+algorithms are selected from the proposed set. The manner 
+in which these algorithms are selected and all related 
+policy issues are outside the scope of this specification. 
+If none of the proposed algorithms are supported, an error 
+code of 10004 occurs.
+
+
+
+
+The desired authentication algorithm is selected from the 
+proposed set. The manner in which this algorithm is 
+selected and all related policy issues are outside the 
+scope of this specification. In the digital signature case,
+the responder's end-entity 
+certificate MUST be issued by one of the trusted CAs listed 
+in the session1 PDU or by the same issuer as the 
+initiator's end-entity certificate. If none of the proposed 
+algorithms are supported, an error code of 10005 results. 
+If the responder does not have acceptable credentials, an 
+error code of 10006 occurs.
+
+
+
+
+
+If any errors occur during processing, the session negotiation 
+fails, and the error is communicated via the existing Jabber iq 
+mechanism:
+
+
+
+<iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
+   <error code="???">...</error>
+</iq>
+
+
+
+If no errors occur, then the responder's user agent proceeds with 
+the session2 PDU.
+
+
+
+
+
+
+
+The responder's user agent employs the following algorithm to generate the session2 PDU:
+
+
+
+
+
+Appropriate values for the version, initiator, responder, 
+sessionId, and hmac attributes are assembled. The version of 
+this specification is '1.0'. The values of initiator and 
+responder MUST be the JIDs of the two participants, 
+respectively. The sessionId and hmac values MUST match the 
+sessionId and hmac values contained in the session1 PDU.
+
+
+
+
+The nonce is prepared by first generating a string of 20 
+random octets (160 random bits). The octets are then 
+encoded into a string of 40 hex characters representing the 
+random string.
+
+
+
+
+An ephemeral private key, y, is generated using g and p 
+for the group indicated by the session1 PDU. This key MUST 
+be generated using an appropriate random number source. The 
+corresponding public key, g^y, is generated and encoded.
+
+
+
+
+The desired pair of confidentiality and HMAC cryptographic 
+algorithms is selected. The manner in which this pair is 
+selected and all related policy issues are outside the 
+scope of this specification.
+
+
+
+
+The desired authentication algorithm is selected. The 
+manner in which this algorithm is selected and all related 
+policy issues are outside the scope of this specification. 
+When the digital signature form of authentication is 
+selected, the relevant end-entity certificate and, 
+optionally, a chain of CA certificates representing a 
+validation path, is assembled and encoded.
+
+
+
+
+Based on the selected authentication algorithm, the 
+responder's authenticator is constructed. A digital signature algorithm
+requires calculating:
+
+
+
+
+HK  =  hmac (initiator's nonce | responder's nonce, g^xy)
+
+
+
+
+HASH_R  =  hmac (HK, version | sessionId | g^y | g^x | responder's JID)
+
+
+
+
+HASH_R is signed using the responder's private key and encoded in PKCS#1 format. 
+The PKCS#1 octets are then further encoded in base64 or hex.
+
+
+The passphrase algorithm requires calculating:
+
+
+
+
+HK  =  hmac (hash (passphrase), initiator's nonce | responder's nonce)
+
+
+
+
+HASH_R  =  hmac (HK, version | sessionId | g^y | g^x | responder's JID)
+
+
+
+
+The octets of HASH_R are simply encoded in base64 or hex.
+
+
+The manner in which the responder's user agent gains access 
+to the responder's credentials is outside the scope of this 
+specification.
+
+
+
+
+
+These values are then used to prepare the XML session2 element; 
+this element is transmitted via the existing Jabber iq mechanism:
+
+
+
+<iq from="responder's JID" to="initiator's JID" type="result" id="whatever">
+   <query xmlns="jabber:security:session">
+      <session2>...</session2>
+   </query>
+</iq>
+
+
+
+
+
+
+
+The initiator's user agent employs the following algorithm to process each session2 PDU:
+
+
+
+
+
+The attribute values are checked against the values sent in 
+the session1 PDU. A mismatch results in an error code of 
+10008.
+
+
+
+
+The nonce is decoded, and its length is checked. The nonce 
+may also be checked to detect replays. An invalid nonce 
+results in an error code of 10002.
+
+
+
+
+The Diffie-Hellman group is checked against the value sent 
+in the session1 PDU. A mismatch results in an error code of 10003
+
+
+
+
+The confidentiality and HMAC cryptographic algorithms are 
+validated against the set proposed in the session1 PDU. A 
+mismatch results in an error code of 10004.
+
+
+
+
+The authentication algorithm is validated against the set 
+proposed in the session1 PDU. A mismatch results in an 
+error code of 10005.
+
+
+
+
+The authenticator is verified. A failure results in an error code of 10007.
+
+
+
+
+
+If any errors occur during processing, the session negotiation 
+fails, and the error is communicated via the existing Jabber iq 
+mechanism:
+
+
+
+<iq from="initiator's JID" to="responder's JID" type="error" id="whatever">
+   <error code="???">...</error>
+</iq>
+
+
+
+If no errors occur, then the initiator's user agent proceeds with the session3 PDU.
+
+
+
+
+
+
+
+The initiator's user agent employs the following algorithm to generate the session3 PDU:
+
+
+
+
+
+Appropriate values for the version, initiator, responder, 
+sessionId, and hmac attributes are assembled. The version of 
+this specification is '1.0'. The values of initiator and 
+responder MUST be the JIDs of the two participants, 
+respectively. The sessionId and hmac values MUST match the 
+sessionId and hmac values contained in both the session1 and 
+session2 PDUs.
+
+
+
+
+Based on the selected authentication algorithm, the 
+initiator's authenticator is constructed. A digital signature algorithm
+requires calculating:
+
+
+
+
+HK  =  hmac (initiator's nonce | responder's nonce, g^xy)
+
+
+
+
+HASH_I  =  hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
+
+
+
+
+HASH_I is signed using the responder's private key and encoded in PKCS#1 format. 
+The PKCS#1 octets are then further encoded in base64 or hex.
+
+
+The passphrase algorithm requires calculating:
+
+
+
+
+HK  =  hmac (hash (passphrase), initiator's nonce | responder's nonce)
+
+
+
+
+HASH_I  =  hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
+
+
+
+
+The octets of HASH_I are simply encoded in base64 or hex.
+
+
+The manner in which the initiator's user agent gains access 
+to the initiator's credentials is outside the scope of this 
+specification.
+
+
+
+
+A set of conversation keys may optionally be included in 
+the response. This should typically be the case since 
+security sessions are negotiated for the sole purpose of 
+key transport. 
+
+
+
+
+
+These values are then used to prepare the XML session3 element; 
+this element is transmitted via the existing Jabber iq mechanism:
+
+
+
+<iq from="initiator's JID" to="responder's JID" type="result" id="whatever">
+   <query xmlns="jabber:security:session">
+      <session3>...</session3>
+   </query>
+</iq>
+
+
+
+
+
+
+
+The responder's user agent employs the following algorithm to process each session3 PDU:
+
+
+
+
+
+The attribute values are checked against the values sent in 
+the session2 PDU. A mismatch results in an error code of 
+10008.
+
+
+
+
+The authenticator is verified. A failure results in an error code of 10007.
+
+
+
+
+Any keys included in the PDU are processed and added to the user agent's key store.
+
+
+
+
+
+If any errors occur during processing, the session negotiation 
+fails, and the error is communicated via the existing Jabber iq 
+mechanism:
+
+
+
+<iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
+   <error code="???">...</error>
+</iq>
+
+
+
+
+
+
+
+TBA
+
+
+
+
+
+
+
+
+
+
+
+Conversation keys are used to protect conversation data.
+
+
+
+
+
+
+
+Conversation keys are transported using the symmetric key wrap feature of
+XML Encryption embedded in the keyTransport PDU.
+
+
+
+
+
+
+
+<!ELEMENT keyTransport
+          (convId, payload, hmac) >
+<!ATTLIST keyTransport
+          version CDATA #REQUIRED
+          initiator CDATA #REQUIRED
+          responder CDATA #REQUIRED
+          sessionId CDATA #REQUIRED >
+
+<!ELEMENT convId
+          (#PCDATA)* >
+
+<!-- These are actually instances of xenc:EncryptedKey -->
+<!ELEMENT payload
+          (confKey, hmacKey) >
+
+<!ELEMENT hmac
+          (#PCDATA)* >
+<!ATTLIST hmac
+          encoding (base64 | hex) #REQUIRED >
+
+
+
+
+
+
+
+The sender's user agent employs the following algorithm to generate the keyTransport PDU:
+
+
+
+
+
+Appropriate values for the version, initiator, responder, and 
+sessionId attributes are assembled. The version of 
+this specification is '1.0'. The values of initiator and 
+responder MUST be the JIDs of the two participants who negotiated the
+security session, respectively, and they
+MUST correspond to an existing security session.
+
+
+
+
+The key's identifier, convId, is assembled.
+
+
+
+
+The payload, which consists of the confidentiality key and the integrity key, is wrapped
+in instances of xenc:EncryptedKey as follows:
+
+
+
+
+
+The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
+
+
+
+
+The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT
+be present.
+
+
+
+
+The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute
+MUST indicate a valid symmetric key wrap algorithm. Furthermore, the
+algorithm MUST be the same as was negotiated for the security session.
+
+
+
+
+The ds:KeyInfo element MUST NOT be present. The key to use is SKc of the 
+security session.
+
+
+
+
+The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice.
+
+
+
+
+
+The HMAC is computed using SKi of the security session over the following values:
+
+
+
+
+the version attribute of the keyTransport element
+
+
+
+
+the initiator attribute of the keyTransport element
+
+
+
+
+the responder attribute of the keyTransport element
+
+
+
+
+the sessionId attribute of the keyTransport element
+
+
+
+
+the character string used to construct the body of the convId element
+
+
+
+
+
+
+
+These values are then used to prepare the XML keyTransport element; 
+this element is transmitted via the existing Jabber iq mechanism:
+
+
+
+<iq from="sender's JID" to="receiver's JID" type="set" id="whatever">
+   <query xmlns="jabber:security:keyTransport">
+      <keyTransport>...</keyTransport>
+   </query>
+</iq>
+
+
+
+
+
+
+
+The receiver's user agent employs the following algorithm to process each keyTransport PDU:
+
+
+
+
+
+The values of the version, initiator, responder, and sessionId are validated; initiator,
+responder, and sessionId MUST indicate an existing security session.
+A version mismatch results in an error code of 10000; an invalid security session
+results in an error of 10010.
+
+
+
+
+The payload, which consists of the confidentiality key and the intergrity key, is unwrapped.
+Any failures result in an error code of 10012.
+
+
+
+
+The body of the HMAC element is decoded into the actual HMAC octet string.
+
+
+
+
+The HMAC is validated. An invalid HMAC results in an error code of 10011.
+
+
+
+
+The keys are added to the user agent's key store.
+
+
+
+
+
+If any errors occur during processing, the error is communicated via the existing Jabber iq 
+mechanism:
+
+
+
+<iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
+   <error code="???">...</error>
+</iq>
+
+
+
+
+
+
+
+
+
+
+
+The ultimate goal is, of course, the protection of conversation data. The protocol exchanges
+described above allow the conversation participants to cryptographically protect their conversation data using the conversation keys that they share.
+
+
+
+
+
+
+
+A protected message is defined as a traditional Jabber message whose body content
+is extended to include the transport of a cryptographically protected message body.
+The two key features are
+
+
+
+
+
+First, the usual body element contains some arbitrary text. Those familiar with the
+evolution of email protocols will recognize this trick as the same one used
+when MIME was introduced.
+
+
+
+
+Second, the message contains a Jabber x element defining the Jabber:security:message
+namespace; this element transports the protected message.
+
+
+
+
+
+This mechanism has the advantages of allowing transparent integration with existing
+Jabber servers and existing Jabber clients.
+
+
+
+
+
+
+
+<!ELEMENT protectedMessage
+          (securityLabel?, payload, hmac) >
+<!ATTLIST protectedMessage
+          version CDATA #REQUIRED
+          from CDATA #REQUIRED
+          to CDATA #REQUIRED
+          convId #REQUIRED
+          seqNum #REQUIRED >
+
+<!ELEMENT securityLabel
+          (#PCDATA)* >
+
+<!-- this is actually an instance of xenc:EncryptedData -->
+<!ELEMENT payload
+          (#PCDATA)* >
+
+<!ELEMENT hmac
+          (#PCDATA)* >
+<!ATTLIST hmac
+          encoding (base64 | hex) #REQUIRED >
+
+
+
+
+
+
+
+The sender's user agent employs the following algorithm to generate the protectedMessage PDU:
+
+
+
+
+
+Appropriate values for the version, from, to, convId, and 
+seqNum attributes are assembled. The version of 
+this specification is '1.0'. The value of convId MUST correspond to an existing, valid key.
+
+
+
+
+The actual message body is encoded into a character string corresponding to a Jabber message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:
+
+
+
+
+
+The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
+
+
+
+
+The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT
+be present.
+
+
+
+
+The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute
+MUST indicate a valid block encryption algorithm.
+
+
+
+
+The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality
+key indicated by the convId attribute.
+
+
+
+
+The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice.
+
+
+
+
+
+Using the HMAC key indicated by the convId attribute, the HMAC is computed
+over the following values:
+
+
+
+
+the version attribute of the protectedMessage element
+
+
+
+
+the from attribute of the protectedMessage element
+
+
+
+
+the to attribute of the protectedMessage element
+
+
+
+
+the convId attribute of the protectedMessage element
+
+
+
+
+the seqNum attribute of the protectedMessage element
+
+
+
+
+any securityLabel element
+
+
+
+
+the character string used to construct the body of the payload element 
+
+
+
+
+
+
+
+These values are then used to prepare the XML protectedMessage element; 
+this element is transmitted via the existing Jabber message mechanism:
+
+
+
+<message from="sender's JID" to="reveiver's JID" id="whatever">
+   <body>The real body is protected.</body>
+   <x xmlns="jabber:security:message">
+      <protectedMessage>...</protectedMessage>
+   </x>
+</iq>
+
+
+
+
+
+
+
+The receiver's user agent employs the following algorithm to process each protectedMessage PDU:
+
+
+
+
+
+The values of the version, from, to, convId, and seqNum are validated.
+A version mismatch results in an error code of 10000. An unknown convId
+results in an error code of 10015. If replay protection is utilized, a
+duplicate seqNum results in an error code of 10016.
+
+
+
+
+The body of the HMAC element is decoded into the actual HMAC octet string.
+
+
+
+
+The payload, which consists of the actual message body, is unwrapped.
+Any failures result in an error code of 10012.
+
+
+
+
+The HMAC is validated. An invalid HMAC results in an error code of 10011.
+
+
+
+
+
+If any errors occur during processing, the error is communicated via the existing Jabber iq 
+mechanism:
+
+
+
+<iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
+   <error code="???">...</error>
+</iq>
+
+
+
+
+
+
+
+
+TBA
+
+
+
+
+
+
+The following block encryption algorithms are required, as
+specified by XML Encryption:
+
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#tripledes-cbc
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#aes128-cbc
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#aes256-cbc
+
+
+
+
+
+The following symmetric key wrap algorithms are required, as
+specified by XML Encryption:
+
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#kw-tripledes
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#kw-aes128
+
+
+
+
+http://www.w3.org/2001/04/xmlenc#kw-aes256
+
+
+
+
+
+
+
+
+
+
+
+This protocol makes use of the following Diffie-Hellman groups adopted from IKE.
+
+
+
+
+
+The hexidecimal value of the prime, p, is
+
+
+
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+FFFFFFFF FFFFFFFF
+
+
+
+The decimal value of the generator, g, is 2.
+
+
+
+
+
+
+
+The hexidecimal value of the prime, p, is
+
+
+
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
+
+
+
+The decimal value of the generator, g, is 2.
+
+
+
+
+
+
+
+The hexidecimal value of the prime, p, is
+
+
+
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
+ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
+ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
+F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
+43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
+88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
+2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
+287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
+1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
+93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
+FFFFFFFF FFFFFFFF
+
+
+
+The decimal value of the generator, g, is 2.
+
+
+
+
+
+
+
+The hexidecimal value of the prime, p, is
+
+
+
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
+ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
+ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
+F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
+43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
+88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
+2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
+287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
+1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
+93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD
+F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831
+179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B
+DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF
+5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6
+D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3
+23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328
+06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C
+DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE
+12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4
+38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300
+741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568
+3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
+22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B
+4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A
+062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36
+4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1
+B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
+4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47
+9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
+60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
+
+
+
+The decimal value of the generator, g, is 2.
+
+
+
+
+
+
+
+
+
+This entire document is about security.
+
+
+
+This version of the protocol deliberately incorporates only a minimal amount
+of cryptographic choice. Examples of possible choices that can readily
+added in future drafts include:
+
+
+
+
+
+Support for the Digital Signature Standard
+
+
+
+
+Support for Elliptic Curve Cryptography
+
+
+
+
+Additional symmetric algorithms
+
+

+
+Additional hash algorithms
+
+
+
+
+
+
+Furthermore, additional credential formats, such as OpenPGP, may be addressed
+in future drafts.
+
+
+
+This version of the protocol includes a mechanism that derives a cryptographic key from a
+passphrase shared by a community of users. It is impossible to overstate the security
+issues that such a mechanism raises.
+
+
+
+This version of the protocol does not include a specific rekeying capability. Data volumes
+in IM environments are expected to be small, and the protocol prefers to simply instantiate
+new conversation keys. It is straightforward to extend the security session protocol to
+enable negotiation of a new key.
+
+
+
+
+
+
+
+
+
+<iq from='initiator@some.tld'
+    to='responder@other.tld'
+    type='get'
+    id='whatever' >
+    <x xmlns='jabber:security:session>
+       <session1 version='1.0'
+                 initiator='initiator@some.tld'
+                 responder='responder@other.tld'
+                 sessionId='session11223344556677@some.tld'
+                 hmac='hmac-sha1'>
+         <nonce encoding='hex'>
+            ...
+         </nonce>
+         <keyAgreement>
+            <dh group='modp4096'>
+               <publicKey encoding='base64'>
+                  ...
+               </publicKey>
+            </dh>
+         </keyAgreement>
+         <algorithms>
+            <algorithm>
+               <confAlg cipher='3des-cbc'/>
+               <hmacAlg alg='hmac-sha1'/>
+            </algorithm>
+         </algorithms>
+         <authnMethods>
+            <authnMethod>
+               <digSig alg='rsa'>
+                  <certificate type='x509' encoding='base64'>
+                     ...
+                  </certificate>
+               </digSig>
+            </authnMethod>
+         </authnMethods>
+      </session1>
+   </x>
+</iq>
+
+<iq from='responder@other.tld'
+    to='initiator@some.tld'
+    type='result'
+    id='whatever' >
+    <x xmlns='jabber:security:session>
+       <session2 version='1.0'
+                 initiator='initiator@some.tld'
+                 responder='responder@other.tld'
+                 sessionId='session11223344556677@some.tld'
+                 hmac='hmac-sha1'>
+         <nonce encoding='hex'>
+            ...
+         </nonce>
+         <keyAgreement>
+            <dh group='modp4096'>
+               <publicKey encoding='base64'>
+                  ...
+               </publicKey>
+            </dh>
+         </keyAgreement>
+         <algorithm>
+            <confAlg cipher='3des-cbc'/>
+            <hmacAlg alg='hmac-sha1'/>
+         </algorithm>
+         <authnMethod>
+            <digSig alg='rsa'>
+               <certificate type='x509' encoding='base64'>
+                  ...
+               </certificate>
+            </digSig>
+         </authnMethod>
+         <authenticator encoding='base64'>
+            ...
+         </authenticator>
+      </session2>
+   </x>
+</iq>
+
+<iq from='initiator@some.tld'
+    to='responder@other.tld'
+    type='result'
+    id='whatever' >
+    <x xmlns='jabber:security:session>
+       <session3 version='1.0'
+                 initiator='initiator@some.tld'
+                 responder='responder@other.tld'
+                 sessionId='session11223344556677@some.tld'
+                 hmac='hmac-sha1'>
+         <authenticator encoding='base64'>
+            ...
+         </authenticator>
+      </session3>
+   </x>
+</iq>
+
+
+
+
+
+
+
+
+<iq type='set' >
+   <x xmlns='jabber:security:key>
+      <keyTransport version='1.0'
+                    initiator='initiator@some.tld'
+                    responder='responder@other.tld'
+                    sessionId='session11223344556677@some.tld'>
+         <convId>
+            44d2d2d2d2@some.tld
+         </convId>
+         <EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
+                        Type='http://www.w3.org/2001/04/xmlenc#Content'>
+            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
+            </EncryptionMethod>
+            <CipherData>
+               <CipherValue>
+                  ...
+               </CipherValue>
+            </CipherData>
+         </EncryptedKey>
+         <EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
+                        Type='http://www.w3.org/2001/04/xmlenc#Content'>
+            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
+            </EncryptionMethod>
+            <CipherData>
+               <CipherValue>
+                  ...
+               </CipherValue>
+            </CipherData>
+         </EncryptedKey>
+         <hmac encoding='hex'>
+            ...
+         </hmac>
+      </keyTransport>
+   </x>
+</iq>
+
+
+
+
+
+
+
+<message from='initiator@some.tld'
+         to='responder@other.tld'>
+   <body>
+      The real body is protected.
+   </body>
+   <x xmlns='jabber:security:message'>
+      <protectedMessage version='1.0'
+                        from='initiator@some.tld'
+                        to='responder@other.tld'
+                        convId='44d2d2d2d2@some.tld'
+                        seqNum='1'>
+         <securityLabel>
+            Confidential
+         </securityLabel>
+         <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
+                        Type='http://www.w3.org/2001/04/xmlenc#Element'>
+            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc>
+            </EncryptionMethod>
+            <CipherData>
+               <CipherValue>
+                  ...
+               </CipherValue>
+            </CipherData>
+         </EncryptedData>
+         <hmac encoding='hex'>
+            ...
+         </hmac>
+      </protectedMessage>
+   </x>
+</message>
+
+
+
+
+
+
+
+
+
+"XML Encryption Syntax and Processing"; http://www.w3.org/TR/xmlenc-core
+
+
+
+more to be added
+
+
+
+
+
diff --git a/xep-0032.xml b/xep-0032.xml
new file mode 100644
index 00000000..c8ce6585
--- /dev/null
+++ b/xep-0032.xml
@@ -0,0 +1,158 @@
+
+
+%ents;
+]>
+
+
+
+  Jabber URI Scheme
+  A URI scheme for Jabber communications.
+  &LEGALNOTICE;
+  0032
+  Retracted
+  Standards Track
+  Standards JIG
+  None
+  None
+  draft-saintandre-xmpp-uri
+  
+    Peter
+    Saint-Andre
+    stpeter@jabber.org
+    stpeter@jabber.org
+  
+  
+    Peter
+    Millard
+    me@pgmillard.com
+    pgmillard@jabber.org
+  
+  
+    0.4
+    2003-09-02
+    psa
+    Retracted the JEP, since it is superseded by draft-ietf-xmpp-uri, an Internet-Draft produced by the IETF's XMPP WG.
+  
+  
+    0.3
+    2002-10-16
+    psa
+    Changed 'jabber:' scheme to 'xmpp:' scheme; further specified use cases; removed references to official Jabber namespaces.
+  
+  
+    0.2
+    2002-05-10
+    psa
+    Added information about syntax, allowable characters, and potential conflict with official Jabber namespaces.
+  
+  
+    0.1
+    2002-05-08
+    psa
+    Initial version.
+  
+
+
+  It is widely acknowledged that it would be good to be able to express a Jabber Identifier (JID) Jabber Identifiers are formally defined in JEP-0029: http://www.jabber.org/jeps/jep-0029.html. as a Uniform Resource Identifier (see &rfc3986;). In addition, there would be value in being able to interact with a JID through a URI scheme (e.g., by sending a message or a presence update).
+  Although XMPP enables a wide range of functionality, the authors propose that a Jabber URI scheme needs to support only a limited subset of the possible Jabber functionality. In particular, we see the following as core functions that need to be supported:
+  
+    Sending of basic messages
+    Sending of basic presence
+    Sending of subscription requests
+  
+
+
+  The syntactic components of a Jabber URI are as follows:
+  <xmpp>:[<node-identifier>@]<domain-identifier>[?<query>]
+  This scheme is similar to the mailto URI scheme The mailto URI scheme is described in RFC 2368: http://www.ietf.org/rfc/rfc2368.txt.. One similarity is that a Jabber URI is, in the terminology of RFC 3986, not hierarchical but opaque. A URI that is hierarchical in nature uses the slash ("/") character in order to separate hierarchical components, as is familiar from HTTP and FTP URIs. By contrast, an opaque URI such as a mailto URI contains only the scheme (e.g., 'mailto'), a colon, an address (e.g., 'user@host'), and an optional query component.
+  Per the JID definition in JEP-0029, the node identifier is optional (i.e., a mere domain identifier is a valid JID). However, the proposed Jabber URI scheme forbids the inclusion of a resource identifier in the JID, even though JEP-0029 defines this as valid. This is partly because the authors see no compelling reason to include a resource identifier in the Jabber URI scheme, and also because including a resource would necessitate the inclusion of a slash character in an opaque URI, which is contrary to RFC 3986. Finally, the query component is optional.
+
+
+  RFC 3986 limits the characters included in a URI to US-ASCII characters, and further defines a number of US-ASCII characters as reserved or otherwise excluded. Reserved characters are special characters used as delimiters withing URIs and whose usage is limited to their reserved purpose as defined in RFC 3986 or a specific URI scheme. Excluded characters are control characters, spaces, and other common (non-URI-specific) delimiters such as angle brackets, double quotes, the number sign, and the percent sign. Reserved characters must be escaped if their usage in a specific context would conflict with their reserved purpose, and excluded characters must always be escaped. The set of disallowed charaacters for any specific URI component consists of the reserved and excluded characters for that component. These are defined below for each component of a Jabber URI.
+  
+    The scheme component for a Jabber URI is 'xmpp'. This component is delimited from the remainder of the URI by a colon character (':').
+  
+  
+    The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of JEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:
+    #x22 (") | #x26 (&) | #x27 (') | #x2F (/) | 
+#x3A (:) | #x3C (<) | #x3E (>) | #x40 (@) | 
+#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)
+    In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved: 
+    #x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)
+    Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:
+    #x23 (#) | #x25 (%)
+    Finally, because the generic URI syntax does not provide a way to specify a character encoding other than US-ASCII (see Section 2.1 of RFC 3986), the characters in the node identifier component of a Jabber URI must contain only US-ASCII characters.
+    Therefore, in order to ensure that a Jabber URI containing a node identifier is a valid URI, the characters disallowed by RFC 3986 (reserved, excluded, and non-ASCII characters) must be escaped in the node identifier component of a Jabber URI.
+  
+  
+    A domain identifier is a standard DNS hostname as specified in RFC 952 http://www.ietf.org/rfc/rfc952.txt.
+  
+  
+    The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:
+    #x22 (") | #x23 (#) | #x24 ($) | #x25 (%) | 
+#x26 (&) | #x27 (') | #x2B (+) | #x2C (,) | 
+#x2F (/) | #x3A (:) | #x3B (;) | #x3C (<) | 
+#x3D (=) | #x3E (>) | #x3F (?) | #x40 (@) | 
+#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)
+  
+
+
+    Thus the most basic Jabber URI is user@host (sometimes referred to as a "bare JID") prepended by 'xmpp:', as shown in the following example.
+    
+xmpp:user@host
+    
+    A URI containing bare JID and no query component should trigger an application to present a user with an appropriate interface to complete an action such as sending a message, sending presence, or managing a subscription. In order to make this possible, some basic queries must be included in the protocol.
+    The authors propose three allowable query types in a Jabber URI: message, presence, and subscribe These query types are URI queries as defined in RFC 3986 and are not to be confused with the <query/> element often included as the child of an <iq/> element in XMPP.. These three basic URIs are described below by way of use cases.
+  
+    If no parameters are passed along with the message query type, an application should present a user with an appropriate interface to complete the sending of a message.
+    
+xmpp:user@host?message
+    
+    The query component may include parameters that further specify the message to be sent to the intended recipient. The following parameters are allowed:
+    
+      body
+      subject
+      thread (for conversation tracking)
+    
+    
+xmpp:user@host?message&subject=hi&body=Hello%20World&thread=abc123
+    
+  
+  
+    If no parameters are passed along with the presence query type, an application should present a user with an appropriate interface to complete the act of sending presence.
+    
+xmpp:user@host?presence
+    
+    The query component may include parameters that further specify the presence to be sent to the intended recipient (e.g., a user-defined status message). The following parameters are allowed:
+    
+      type ('unavailable'; if not specified, the sender is defined to be online and available)
+      show (one of 'away', 'xa', 'dnd', or 'chat')
+      status (user-defined status message)
+      priority (a non-negative integer, with zero as the lowest priority)
+    
+    
+xmpp:user@host?presence&show=dnd&status=taking%20a%20nap
+    
+  
+  
+    If no parameters are passed along with the subscribe query type, an application should present a user with an appropriate interface to complete the subscription request.
+    
+xmpp:user@host?subscribe
+    
+    The query component may include parameters that further specify the subscription request to be sent to the intended recipient. Only the 'type' parameter is deemed useful in the limited Jabber URI spec, with valid values of 'subscribe', 'subscribed', 'unsubscribe', or 'unsubscribed'.
+    
+xmpp:user@host?subscribe&type=subscribe
+    
+    
+xmpp:user@host?subscribe&type=subscribed
+    
+    
+xmpp:user@host?subscribe&type=unsubscribe
+    
+    
+xmpp:user@host?subscribe&type=unsubscribed
+    
+  
+
+
diff --git a/xep-0033.xml b/xep-0033.xml
new file mode 100644
index 00000000..db839c06
--- /dev/null
+++ b/xep-0033.xml
@@ -0,0 +1,667 @@
+
+
+%ents;
+]>
+
+
+    
+        Extended Stanza Addressing 
+        This document specifies an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.
+        &LEGALNOTICE;
+        0033
+        Draft
+        Standards Track
+        Standards JIG
+        
+            XMPP Core
+            JEP-0030
+        
+        
+        
+        address
+        
+            http://jabber.org/protocol/address/address.xsd
+        
+        &hildjj;
+        &stpeter;
+
+        
+            1.1
+            2004-09-15
+            psa
+            Per list discussion, removed prohibition on multiple replyto and replyroom addresses, since this is allowed by RFC 822.
+        
+
+        
+            1.0
+            2004-05-10
+            psa
+            Per a vote of the Jabber Council, advanced status to Draft; also added Security Considerations in consultation with JEP author.
+        
+
+        
+            0.10
+            2004-03-18
+            psa
+            Disallowed <addresses/> as direct child 
+            of &IQ;.
+        
+
+        
+            0.9
+            2004-02-27
+            jjh
+            Added language note on desc attribute.  Ensured
+            that if uri attribute is used, node MUST NOT be.
+        
+
+        
+            0.8
+            2004-02-11
+            jjh
+
+            Editorial cleanups, rearrangement.  Allowed IQ's
+            in certain cases.  Clarified node rules.  Changed
+            delivered='yes' to delivered='true'.  Noreply shouldn't
+            imply no other addresses.  Clarified when authorization
+            checks take place.  Remove own address on reply.  Bad URI
+            error added.
+        
+
+        
+            0.7
+            2004-02-04
+            jjh
+
+            Clarified that a node attribute refers to a disco
+            node.
+        
+
+        
+            0.6
+            2004-02-04
+            jjh
+
+            Changed namespace to
+            'http://www.jabber.org/protocol/address', and removed one
+            level of nesting, since addresses are the only block left.
+            Made it clearer that the session manager can implement
+            multicast directly.  Removed infobits (needs to be a
+            separate JEP).  Reworked the examples to be more correct.
+            Added reply handling rules. Added schema.
+
+        
+        
+            0.5
+            2003-12-17
+            jjh
+
+            Replaced info with infobits, added noreply address
+            type.
+
+        
+        
+            0.4
+            2003-12-15
+            jjh
+
+            Removed trace; if you want that, use a different
+            namespace.  Required disco use, and removed agents/browse.
+            Added URI addressing.
+
+        
+        
+            0.3
+            2002-07-29
+            jjh
+            Made addresses extensible, added replyroom
+        
+        
+            0.2
+            2002-05-06
+            jjh
+            Re-worked to simpler/more structured XML.
+        
+        
+            0.1
+            2002-04-19
+            jjh
+            Initial version.
+        
+    
+    
+            On the existing Jabber network, there are many opportunities to optimize stanza traffic. For example, clients that want to send the same stanza to multiple recipients currently must send multiple stanzas. Similarly, when a user comes online the server sends many nearly-identical presence stanzas to remote servers.
+      
+            The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;.  As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' jabber:x:envelope - Message Envelope Information Extension proposal, which this JEP can supersede.
+    
+    
+        Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &jep0030;. A conforming server MUST respond to disco#info requests.
+        
+        
+            To determine if a server or service supports Extended Stanza Addressing, the requesting entity SHOULD send a disco#info request to it.
+
+           
+  
+]]>
+           
+            If the server supports Extended Stanza Addressing, it MUST include a "http://jabber.org/protocol/address" feature in the response.
+           
+  
+    ...
+    
+    ...
+  
+]]>
+           
+        
+
+        
+            The IM service MAY implement multicast directly, or it MAY delegate that chore to a separate service. A client can use the following approach to find a multicast-capable service hosted by its domain:
+            
+              Send a disco#info request to the IM server; if its reply includes the 'http://jabber.org/protocol/address' feature, then it is a multicast-capable service.
+              If the IM server is not a multicast-capable service, send a disco#items request to the IM server; the IM server will then return a list of associated services.
+              Send a disco#info request to each of the services associated with the IM server; if one of the replies includes the 'http://jabber.org/protocol/address' feature, then that service is a multicast-capable service.
+            
+
+            The multicast service MAY choose to limit which local users can use the service.  The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying).  In either case, if the server chooses to disallow the request, the server MUST return a Forbidden error (see the Error Conditions section below).  In the relaying case, the server SHOULD NOT deliver to any of the addresses (even the local ones) if the sender is disallowed.
+        
+
+        
+            Implementations MAY choose to cache the disco response.
+            Positive responses MAY be cached differently than negative
+            responses.  The result SHOULD NOT be cached for more than 24
+            hours, unless some sort of time-to-live information is
+            added to the Service Discovery protocol in the future.
+        
+    
+
+    
+        For multicast processing, the stanza containing an address header
+        (the 'outer stanza') MUST be addressed to the multicast service,
+        with no username or resource in the 'to' attribute.
+
+        When used for additional information in a one-to-one stanza
+        (e.g. using the 'node' attribute), the outer stanza SHOULD be
+        addressed directly to the recipient, not to the multicast
+        service.
+
+        A multicast service MUST NOT change the 'from' address on
+        the outer stanza.  Note that this will limit third-party
+        relaying across server-to-server connections as a side-effect.
+
+        Address headers MAY be included in message or presence
+        stanzas.  They MUST NOT be included as the direct child of an 
+        IQ stanza.
+    
+
+    
+        Address values are packaged together into an
+        <addresses/> element.
+
+        
+   
+       
+       
+   
+   Hello, world!
+]]>
+
+        
+    
+        
+        
+    
+]]>
+
+        
+        Each address to which the sender wants the stanza to be re-sent will show up as an <address/> in the <addresses/> element.  There are several different types of address, shown below.
+
+        An <address/> element MUST possess a 'type' attribute, and MUST possess at least one of the 'jid', 'uri', 'node', and 'desc' attributes. An <address/> element MUST NOT possess both a 'jid' attribute and a 'uri' attribute. If sending through a multicast service, an address MUST include a 'jid' or a 'uri' attribute, unless it is of type 'noreply'.
+
+        
+            The 'jid' attribute is used to specify a simple Jabber ID associated with this address.  If the 'jid' attribute is specified, the 'uri' attribute MUST NOT be specified. Support for the 'jid' attribute is REQUIRED.
+        
+
+        
+            The 'uri' attribute is used to specify an external system address, such as a sip:, sips:, or im: URI.  If the 'uri' attribute is specified, the 'jid' and 'node' attributes MUST NOT be specified.  These URIs MUST be formatted as specified in their respective RFCs, however with the characters & < > ' " replaced by their equivalent XML escapes, &amp; &lt; &gt; &apos; &quot;. If a receiving entity does not understand the given URI scheme, or if the URI is not formatted correctly, a "JID Malformed" error SHOULD be returned. Support for the 'uri' attribute is OPTIONAL.
+        
+
+        
+            The 'node' attribute is used to specify a sub-addressable unit at a particular JID, corresponding to a Service Discovery node.  A node attribute MAY be included if a 'jid' attribute is specified.  If a 'uri' attribute is specified, a 'node' attribute MUST NOT be specified. Support for the 'node' attribute is RECOMMENDED.
+        
+
+        
+            The 'desc' attribute is used to specify human-readable information for this address.  This data may be used by clients to provide richer address-book integration.  This information is in the language of the sender, which MAY be identified using the standard xml:lang rules from &xmppcore;. Support for the 'desc' attribute is RECOMMENDED.
+        
+
+        
+            When a multicast service delivers the stanza to a non-bcc address, it MUST add a delivered='true' attribute to the address element.  A multicast service MUST NOT deliver to an address that was marked with a delivered='true' attribute when the service received the stanza.  A multicast service SHOULD attempt to deliver to all addresses that are not marked with a delivered='true' attribute.  The delivered attribute is used to prevent loops.  See the Multicast Usage section below for more details. Support for the 'delivered' attribute is REQUIRED.
+        
+
+        
+            The 'type' attribute is used to specify the semantics of a particular address. Support for the 'type' attribute is REQUIRED.
+
+            
+                These addressees are the primary recipients of the stanza.
+            
+            
+                These addressees are the secondary recipients of the stanza.
+            
+            
+                These addressees should receive 'blind carbon copies' of the stanza.  This means that the server MUST remove these addresses before the stanza is delivered to anyone other than the given bcc addressee or the multicast service of the bcc addressee.
+            
+            
+                This is the address to which all replies are requested to be sent.  Clients SHOULD respect this request unless an explicit override occurs.  There MAY be more than one replyto or replyroom on a stanza, in which case the reply stanza MUST be routed to all of the addresses.
+            
+            
+                This is the JID of a &jep0045; room to which responses should be sent.  When a user wants to reply to this stanza, the client SHOULD join this room first.  Clients SHOULD respect this request unless an explicit override occurs. There MAY be more than one replyto or replyroom on a stanza, in which case the reply stanza MUST be routed to all of the addresses.
+            
+            
+                This address type contains no actual address information.  Instead, it means that the receiver SHOULD NOT reply to the message.  This is useful when broadcasting messages to many receivers.
+            
+        
+
+        
+            As specified herein, the <address/> element is empty.  Implementations or future protocols MAY extend the <address/> element for additional functionality, but any extensions are out of scope for this JEP. Such extensions SHOULD be appropriately qualified with a new namespace, and any extensions that are not understood by an implementation MUST be ignored.
+
+            
+  
+    
+      foo
+    
+    
+  
+]]>      
+        
+    
+
+    
+        The following usage scenario shows how messages flow through both address-enabled and non-address-enabled portions of the Jabber network.
+    
+        Note: the logic associated with how to perform the following tasks is purely informational.  A conforming service MUST generate output as if these rules had been followed, but need not (and probably will not) use this algorithm.
+
+        
+            User desires to send a stanza to more than one
+            recipient.
+      
+            Client determines the JID of a multicast service,
+            using Service Discovery.
+      
+            If no multicast service is found, the client MAY
+            choose to deliver each stanza individually, or it MAY
+            query each of the servers associated with desired
+            recipients, and batch stanzas to those servers
+            itself.
+
+            If a multicast service is found, the client constructs
+            a stanza with an address block, and sends it to the
+            multicast service. (Note: For the following rules, any 
+            address that was marked on the incoming address header 
+            with delivered='true' is never re-delivered.)
+
+            The server checks to see if it can deliver to all of
+            the specified addresses.  If not, the stanza is returned
+            with a "Forbidden" error, and processing stops.
+
+            The server adds a delivered='true' attribute to all
+            addresses.
+
+            The server removes all type='bcc' attributes.
+
+            The server delivers the stanza to all of the 'to',
+            'cc', and 'bcc' addresses from the original address header that
+            are being handled locally.  The server replaces the
+            'to' attribute on the outer stanza with the JID of each
+            addressee.  Each 'bcc' recipient MUST receive only the
+            <address type='bcc'/> associated with that
+            addressee.
+
+            For each non-local server (the 'target server') that
+            has addresses specified in 'to', 'cc', or 'bcc' addresses
+            in the original address header, the local server determines
+            whether the target server supports multicast, using Service
+            Discovery.
+      
+            If the target server does not support address headers, the
+            local server sends a copy of the stanza to each address,
+            with the 'to' attribute on the outer stanza set to the JID
+            of the given addressee.
+      
+            If the target server does support address headers, the server
+            removes the delivered='true' attributes on each of the
+            addresses bound for that server, and replaces the 'to'
+            attribute on the outer stanza with the adress of the
+            multicast service for the target server.  The 'bcc'
+            addresses for the target server from the original address header
+            are added back to the address header.  A single stanza is sent to
+            the target server.
+        
+    
+
+    
+        Assume for these examples that header1.org and header2.org
+        support address headers, and noheader.org does not.
+
+        
+  
+]]>
+
+        
+  
+    
+  
+]]>
+
+        
+   
+     
+     
+     
+     
+     
+     
+     
+     
+     
+   
+   Hello, World!
+]]>
+
+        
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+
+
+   
+     
+     
+     
+     
+     
+     
+   
+   Hello, World!
+
+
+   
+     
+     
+     
+     
+     
+     
+   
+   Hello, World!
+]]>
+
+        
+   
+
+]]>
+
+        
+  
+... no address feature ...
+  
+]]>
+
+        
+   
+
+]]>
+
+        
+  
+  
+]]>
+
+        
+   
+
+]]>
+
+        
+  
+    
+  
+]]>
+
+        
+   
+      
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+]]>
+         
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+
+
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+
+
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+]]>
+
+        
+  
+]]>
+
+        
+   
+... no address feature ...
+   
+]]>
+
+        
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+
+
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+
+
+   
+      
+      
+      
+      
+      
+      
+   
+   Hello, World!
+]]>
+    
+
+    
+        When replying to a message stanza that contains an extended
+        address, the following rules apply:
+
+        
+            If more than one replyto or replyroom address is
+            specified (bad protocol), or if a noreply address is
+            specified, a reply SHOULD NOT be generated. 
+
+            If a replyroom address is specified, the client SHOULD
+            join the specified chat room instead of replying directly
+            to the specified user.  No further extended address
+            processing is required.
+
+            If a replyto address is specified, the reply SHOULD go
+            to the specified address.  No further extended address
+            processing is required.  Any <thread/> element from
+            the initial message MUST be copied into the reply.
+
+            Otherwise, an extended-address aware client MUST copy
+            the address header from the original message into the reply,
+            removing any delivered attributes.  If the original sender
+            is not in the copied list, the original sender MUST be
+            added as a 'to' address.  The recipient's address SHOULD
+            be removed from the list.  The client then proceeds with
+            the rules from the Multicast Usage
+            section above for delivery of the message.
+        
+    
+
+    
+        The following error conditions are to be used by implementations (for further information regarding error syntax, see &jep0086;):
+        
+          
+            
+            
+          
+          
+            
+            
+          
+          
+            
+            
+          
+          
+            
+            
+          
+        XMPP Condition Purpose
<forbidden/> The sending user does not have permission to use this multicast service.
<jid-malformed/> A URI attribute was invalid or not understood (note that support for the 'uri' attribute is optional).
<not-acceptable/> Too many receiver fields were specified.  Servers MAY have configurable limits for this, but the limit MUST be at least 50.
+    
+
+  
+    A recipient SHOULD trust a stanza's extended addressing headers only as much as it trusts the sender of the stanza.
+    Furthermore, there exists the potential for abuse related to the 'replyto' and 'replyroom' features (e.g., an entity could send messages with 'replyroom' set to the address of a room that hosts salacious content or with 'replyto' set to the address of a spambot that harvests Jabber addresses). Therefore if a human user's receiving application receives a message with extended stanza addressing that specifies a 'replyto' or 'replyroom' address other than that of the sender, it SHOULD inform the user of that fact. (Naturally, the receiving application MAY also limit the entities to which the recipient can reply using privacy lists as specified in &xmppim;.)
+  
+  
+    This JEP requires no interaction with &IANA;.
+  
+  
+    The ®ISTRAR; shall include 'http://jabber.org/protocol/address' in its registry of protocol namespaces.
+  
+
+    
+        
+
+
+
+  
+    
+      The protocol documented by this schema is defined in
+      JEP-0033: http://www.jabber.org/jeps/jep-0033.html
+    
+  
+
+  
+     
+        
+           
+        
+     
+  
+
+  
+    
+      
+        
+          
+          
+          
+          
+          
+            
+              
+                
+                
+                
+                
+                
+                
+              
+            
+          
+          
+        
+      
+    
+  
+
+  
+    
+      
+    
+  
+
+
+        ]]>
+    
+
+    
+        Sections of this document were inspired by RFC 822.
+    
+
diff --git a/xep-0034.xml b/xep-0034.xml
new file mode 100644
index 00000000..a40ba03b
--- /dev/null
+++ b/xep-0034.xml
@@ -0,0 +1,249 @@
+
+
+%ents;
+]>
+
+
+
+
+
+  SASL Integration
+  NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.
+  &LEGALNOTICE;
+  0034
+  Retracted
+  Standards Track
+  Standards
+  None
+  None
+  XMPP Core
+  N/A
+  
+    Robert
+    Norris
+    rob@cataclysm.cx
+    rob@cataclysm.cx
+  
+  
+    Jeremie
+    Miller
+    jeremie@jabber.org
+    jer@jabber.org
+  
+  
+    Peter
+    Saint-Andre
+    stpeter@jabber.org
+    stpeter@jabber.org
+  
+  
+    1.1
+    2003-11-05
+    psa
+    The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    1.0
+    2002-08-13
+    psa
+    Changed status to Draft.
+  
+  
+    0.3
+    2002-07-26
+    rn
+    Reworked for server-to-server SASL; added jabber:iq:auth get (as in xmpp-im).
+  
+  
+    0.2
+    2002-06-05
+    rn
+    Fleshed out.
+  
+  
+    0.1
+    2002-06-03
+    psa
+    Initial version based on Jer's notes.
+  
+
+
+
+  The Simple Authentication and Security Layer (SASL) (see &rfc4422;) provides a generalized method for adding authentication support to connection-based protocols. This document describes a generic XML namespace profile for SASL, that conforms to section 4 of RFC 4422, "Profiling requirements".
+  
+  This profile may be used for both client-to-server and server-to-server connections. For client connections, the service name used is "jabber-client". For server connections, the service name used is "jabber-server". Both these names are registered in the IANA service registry.
+
+  The reader is expected to have read and understood the SASL specification before reading this document.
+
+
+
+
+  
+    In these examples, "client" refers to the remote entity that initiated the connection, either a Jabber client or a Jabber server. "Server" refers to the server that the remote entity is attempting to connect and authenticate to.
+
+    The steps involved for a SASL negotiation are as follows:
+
+    
+      Client requests SASL authentication
+      Server responds with list of available SASL authentication mechanisms
+      Client selects mechanism
+      Server sends a challenge
+      Client responds to challenge
+      Server sends more challenges, client sends more responses
+    
+
+    This series of challenge/response pairs continues until one of three things happens:
+
+    
+      Client aborts the handshake.
+      Server reports failure.
+      Server reports success.
+    
+
+    After authentication has completed, the client sends a packet to begin the session.
+    
+    The namespace identifier for this protocol is http://www.iana.org/assignments/sasl-mechanisms.
+
+    The following examples show the dialogue between a client [C] and a server [S].
+
+    
+    
+  
+
+  
+    The client begins by requesting SASL authentication as part of the normal Jabber stream negotiation. In the case of the remote entity being a server, the default namespace in the stream header will be "jabber:server". The server responds by sending the available authentication mechanisms to the client along with the stream information:
+
+    
+C: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  xmlns:sasl='http://www.iana.org/assignments/sasl-mechanisms'
+                  to='jabber.org'>
+S: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  xmlns:sasl='http://www.iana.org/assignments/sasl-mechanisms'
+                  id='12345678'>
+   <sasl:mechanisms>
+     <sasl:mechanism>PLAIN</sasl:mechanism>
+     <sasl:mechanism>DIGEST-MD5</sasl:mechanism>
+     <sasl:mechanism>EXTERNAL</sasl:mechanism>
+   <sasl:mechanisms>
+    
+  
+
+  
+    Next, the client selects an authentication mechanism:
+
+    
+C: <sasl:auth mechanism='PLAIN'/>
+    
+
+    The server responds with a mechanism-specific challenge, which the client must respond to. More than one challenge/response pair can take place; this is mechanism-specific.
+
+    Challenges and responses are Base64RFC 2045, section 6.8. encoded.
+
+    
+S: <sasl:challenge/>
+C: <sasl:response>cm9iAHNlY3JldA==</sasl:response>
+    
+
+    
+S: <sasl:challenge>
+     cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
+     xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
+   </sasl:challenge>
+C: <sasl:response>
+     dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik
+     9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w
+     MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX
+     NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0
+     M2FmNyxjaGFyc2V0PXV0Zi04
+   </sasl:response>
+S: <sasl:challenge>
+     cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
+   </sasl:challenge>
+C: <sasl:response/>
+    
+
+    For mechanisms that require the client to send data first (ie the first challenge from the server is empty), the client may optionally send its first response as part of the mechanism selection:
+
+    
+C: <sasl:auth mechanism='PLAIN'>cm9iAHNlY3JldA==</sasl:auth>
+    
+  
+
+  
+    The handshake continues until authentication completes successfully, authentication fails, or the client aborts the handshake:
+
+    
+S: <sasl:success/>
+    
+
+    
+S: <sasl:failure/>
+    
+
+    
+C: <sasl:abort/>
+    
+
+    Optionally, the server or client may send an informative message along with the success, failure or abort command:
+
+    
+S: <sasl:failure>Plaintext authentication failed (Incorrect username or password)</sasl:failure>
+    
+
+    Following a failure or client abort, the client may start a new handshake. Following a successful authentication, any further attempts by the client to begin a new authentication handshake will automatically result in the server sending a failure.
+  
+
+  
+    Note: that this section only applies to client-to-server connections.
+
+    Following successful authentication, the client must send a standard IQ set packet in the jabber:iq:auth namespace to start a session. The client must supply a username and resource for the session along with this packet.
+
+    
+C: <iq id="a1" type="get">
+     <query xmlns="jabber:iq:auth">
+       <username>rob</username>
+     </query>
+   </iq>
+S: <iq id="a1" type="result">
+     <query xmlns="jabber:iq:auth">
+       <username>rob</username>
+       <resource/>
+     </query>
+   </iq>
+C: <iq id="a2" type="set">
+     <query xmlns="jabber:iq:auth">
+       <username>rob</username>
+       <resource>laptop</resource>
+     </query>
+   </iq>
+S: <iq id="a2" type="result">
+     <query xmlns="jabber:iq:auth"/>
+   </iq>
+    
+
+    If the client attempts to start a session before authenticating, or the username given in the jabber:iq:auth packet does not match the username given in the authentication credentials (when the SASL mechanism supports it), the server will return a 401 (Unauthorized) error packet.
+  
+
+
+
+  Traditionally, Jabber servers have supported two authentication models - jabber:iq:auth for client-to-server authentication, and dialback for server-to-server authentication.
+
+  
+    Until SASL authentication is in widespread use, clients and servers may support both SASL and the legacy jabber:iq:auth authentication system for client-to-server connections. Note that neither the client nor the server are required to support legacy authentication; it is simply a courtesy to users until the majority of clients and servers support SASL authentication.
+
+    If a client connects and does not request the use of SASL (that is, the SASL profile namespace identifier does not appear in the stream initializer response), then the server should disable SASL for this connection; that is, it should not add the SASL profile namespace identifier to the stream initialization response, nor should it offer any SASL mechanisms.
+
+    If a client connects to a server that does not support SASL (identified by the lack of the SASL profile namespace identifier in the stream initializer response, even though the client requested it), the client may choose to fall back to use legacy authentication.
+  
+
+  
+    SASL authentication for server-to-server connections is not intended to replace dialback, as there are uses for both. Dialback is useful in an uncontrolled environment, such as the global Internet, where it is necessary to verify the identity of the remote server. SASL authentication has uses in a more controlled environment, where the administrator wishes to restrict access to a certain number of known remote servers.
+
+    To this end, the use of dialback is not deprecated. If a remote server connects and requests the use of dialback (by specifying the "jabber:server:dialback" namespace, the the local server shall not offer SASL authentication. Similarly, if the remote server connects and requests the use of SASL authentication, then the local server shall not offer dialback. In the event that the remote server requests both, the local server should terminate the stream immediately and close the connection. If the remote server requests neither, then the local server may choose to support the pre-dialback server-to-server stream, but it is recommended that the local server terminate the stream and close the connection.
+  
+
+
+
diff --git a/xep-0035.xml b/xep-0035.xml
new file mode 100644
index 00000000..233839cc
--- /dev/null
+++ b/xep-0035.xml
@@ -0,0 +1,129 @@
+
+
+%ents;
+]>
+
+
+
+
+
+  SSL/TLS Integration
+  NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.
+  &LEGALNOTICE;
+  0035
+  Retracted
+  Standards Track
+  Standards
+  None
+  None
+  XMPP Core
+  N/A
+  
+    Robert
+    Norris
+    rob@cataclysm.cx
+    rob@cataclysm.cx
+  
+  
+    0.2
+    2003-11-05
+    psa
+    The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.1
+    2002-06-14
+    rn
+    Initial version.
+  
+
+
+
+  The TLS protocol RFC 2246 (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for Jabber due to common connection eavesdropping and hijacking attacks. See RFC 1704, "On Internet Authentication."This paragraph adapted from RFC 2595, section 1.
+
+  Traditionally, Jabber servers has supported TLS by utilising a "wrapper" around the standard protocol stream. This wrapper usually listens on a port other than those listed in the IANA registry The Internet Assigned Numbers Authority defines jabber-client (port 5222) and jabber-server (port 5269) as the standard Jabber ports; see http://www.iana.org/assignments/port-numbers. (commonly 5223 for client-to-server communications and 5270 for server-to-server communications). In the case of client-to-server communications, clients must initiate a TLS session immediately after connecting, before beginning the normal XML stream. This method of utilising TLS is typical of many servers that implement stream-based protocols, but has a number of flaws, which are outlined in section 7 of RFC 2595. Accordingly, the use of port 5223 and port 5270 for secure sessions is deprecated.
+
+  This document describes an extension to the Jabber XML stream that provides a "STARTTLS" command which clients may invoke on an insecure stream to secure it. This extension is modelled on RFC 2595, which describes the STARTTLS extension for the IMAP RFC 2060, POP3 RFC 1939 and ACAP RFC 2244 protocols. A future document (or an addition to this document) will define TLS support within server-to-server streams.
+
+
+
+
+  
+    This protocol operates over the standard Jabber client connection on port 5222.
+
+    The namespace identifier for this protocol is http://www.ietf.org/rfc/rfc2595.txt.
+
+    The following examples show the dialogue between a client [C] and a server [S].
+
+    
+    
+  
+
+  
+    The client begins by requesting the use of STARTTLS as part of the normal Jabber stream negotiation. The server responds by informing the client whether or not it supports STARTTLS. It does this in the normal stream negotiation response:
+
+    
+C: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt'
+                  to='jabber.org'>
+S: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt'
+                  id='12345678'>
+    
+
+    In the event that a server does not support the STARTTLS extension, it will respond with the normal stream negotiation response:
+
+    
+C: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt'
+                  to='jabber.org'>
+S: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  id='12345678'>
+    
+  
+
+  
+    To begin the TLS negotiation, the client issues the STARTTLS command:
+
+    
+C: <tls:starttls/>
+    
+
+    When the server is ready to begin the TLS negotiation, it will close the XML stream, but will keep the underlying connection to the client open:
+
+    
+S: </stream:stream>
+    
+
+    The client now begins a normal TLS negotiation by sending the TLS ClientHello command. Upon completion of the TLS negotiation, the client reissues the XML stream initialization:
+
+    
+C: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  to='jabber.org'>
+S: <stream:stream xmlns='jabber:client'
+                  xmlns:stream='http://etherx.jabber.org/streams'
+                  id='12345678'>
+    
+
+    This is necessary, since any information about the stream presented by the server or the client may have been modified by an attacker.
+
+    Note that once the secure channel has been established, the server must not advertise or allow the use of the STARTTLS command.
+  
+
+
+
+
+  TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile JEP-0034 and the EXTERNAL mechanism.
+
+  If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See RFC 2222 and JEP-0034 for more information.
+  
+  Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.
+
+
+
diff --git a/xep-0036.xml b/xep-0036.xml
new file mode 100644
index 00000000..f3efee44
--- /dev/null
+++ b/xep-0036.xml
@@ -0,0 +1,126 @@
+
+
+%ents;
+]>
+
+
+
+  Pub-Sub Subscriptions
+  A proposal for the subscribe half of a publish-subscribe protocol within Jabber. 
+  &LEGALNOTICE;
+  0036
+  Retracted
+  Standards Track
+  Standards
+  None
+  JEP-0060
+  None
+  
+    Peter
+    Millard
+    pgmillard@jabber.org
+    pgmillard@jabber.org
+  
+  
+    Peter
+    Saint-Andre
+    stpeter@jabber.org
+    stpeter@jabber.org
+  
+  
+    0.2
+    2003-04-22
+    psa
+    At the request of the authors, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.1
+    2002-07-12
+    psa
+    Initial version based on discussions at JabberConf.
+  
+
+
+  The Jabber community needs a cohesive standard for publish-subscribe functionality. Certainly there is interest in developing such a standard, as witness the number of JEPs written on this topic. JEP-0021, JEP-0024, JEP-0028. Unfortunately, past discussion of this issue has been clouded by confusion over requirements and even terminology. This JEP seeks to clarify the situation somewhat and to provide a protocol for the subscribe half of publish-subscribe functionality within Jabber.
+
+
+  Traditional pub-sub consists of event notification. This makes it possible for entities to publish data and for other interested entities to receive notification when the data is published. The following are some likely applications of pub-sub functionality within Jabber:
+  
+    Auction and trading systems
+    Online catalogs
+    Document workflow systems
+    Network management systems
+    NNTP over Jabber
+    Groupchat
+  
+  In such systems, a subscriber would request to receive notifications about data the subscriber is interested in. We define a "topic" as an object that defines the relationship between a publisher and its subscribers. Specifically, a topic contains three essential collections of information:
+  
+    A description of the information that will be provided
+    A list of subscribers to items that fit the description
+    One or more items that fit the description
+  
+  We define an "item" as an instance of data published by the publisher that fits the description associated with a topic. Each item MAY possess a unique identifier that enables the data to be tracked. (NOTE: This JEP does not address the durability of items, i.e., data storage.)
+  A topic is addressed by means of a unique "topic ID". A topic ID is simply a string with no required semantic meaning. While a topic ID may have semantic meaning (e.g., '/instruments/guitars/electric' or 'rec.music.dylan'), such meaning is not necessary and a topic ID may be any random string (e.g., 'a1gh83jfn342092'). The only requirement is that a topic ID be unique within the context of a specific pub-sub domain (e.g., pubsub.jabber.org).
+
+
+
+  
+<iq type="set" from="pgm@jabber.org" to="pubsub.jabber.org" id="1">
+    <query xmlns="jabber:iq:pubsub">
+        <subscribe>
+            <topic id="12345"/>
+            <topic id="/presence/dizzyd@jabber.org"/>
+        </subscribe>
+    </query>
+</iq>
+
+<iq type="set" from="pgm@jabber.org" to="pubsub.jabber.org" id="1">
+    <query xmlns="jabber:iq:pubsub">
+        <unsubscribe>
+            <topic id="12345"/>
+        </unsubscribe>
+    </query>
+</iq>
+
+<iq type="set" to="pubsub.jabber.org" id="1">
+    <query xmlns="jabber:iq:pubsub">
+        <publish>
+            <topic id="12345">
+                <item>some kind of cdata goes here</item>
+            </topic>
+        </publish>
+    </query>
+</iq>
+
+<iq type="set" to="pubsub.jabber.org" id="1">
+    <query xmlns="jabber:iq:pubsub">
+        <createtopic>
+            <topic id="new_topic">
+                <profile>
+                    <!-- is this even remotely close?? -->
+                    <publisher>pgm@jabber.org</publisher>
+                    <publisher>dizzyd@jabber.org</publisher>
+                </profile>
+            </topic>
+            <topic id="another_topic>
+                <profile>
+                    <publisher/>
+                </profile>
+            </topic>
+        </createtopic>
+    </query>
+</iq>
+
+<iq type="set" to="pubsub.jabber.org" id="1">
+    <query xmlns="jabber:iq:pubsub">
+        <removetopic>
+            <topic id="12345"/>
+        </removetopic>
+    </query>
+</iq>
+  
+
+
+
+
diff --git a/xep-0037.xml b/xep-0037.xml
new file mode 100644
index 00000000..feb8299f
--- /dev/null
+++ b/xep-0037.xml
@@ -0,0 +1,848 @@
+
+
+%ents;
+]>
+
+
+  DSPS - Data Stream Proxy Service
+  A proposal for proxy support in Jabber.
+  This document has been placed in the public domain.
+  0037
+  Rejected
+  Standards Track
+  Standards JIG
+  
+    David
+    Sutton
+    
+    
+  
+  
+    "Bac9"
+    
+    bac9@bac9.yi.org
+    bac9@jabber.org
+  
+  
+    Version 0.8
+    2002-09-18
+    Bac9
+    Streamlined and enhanced handshake procedure, and cleaned up document.
+  
+  
+    Version 0.7
+    2002-08-20
+    Bac9
+    Added public connections and reduced number of tags.
+  
+  
+    Version 0.6
+    2002-08-11
+    Bac9
+    Added data tracking, inviting peer, auto-disconnect for slow peers, elaboration on protocol and suggested example of file transfer.
+  
+  
+    Version 0.5
+    2002-07-29
+    Bac9
+    Elaborated on some functionality and cleaned up XML protocol.
+  
+  
+    Version 0.4
+    2002-07-11
+    lw
+    Reformatted to JEP XML.
+  
+  
+    Version 0.3
+    2002-06-25
+    Bac9
+    Added support for HTTP, SSL and throughput logging. Changed relay behaviour.
+  
+  
+    Version 0.2
+    2002-06-21
+    Bac9
+    Revised, standardized and extended XML protocol structure.
+  
+  
+    Version 0.1
+    
+    rn
+    Initial version.
+  
+
+
+
+
+  Data Stream Proxy Service (DSPS) is designed to be a common stream protocol for multicast (unicast as special case) over P2S2P (P2P as special case) connections.
+
+
+
+
+
+  This document follows DSPS protocol version 0.5. Any XML data not explicitly defined or mentioned will be ignored without error. On startup, full fledged DSPS starts listening on port 5290 (and 80 if HTTP handshake implemented).
+
+
+
+
+
+  
+
+    (optional) Creating or modifying stream is done like so:
+
+
+<iq
+  id='dsps1'
+  type='get'
+  from='rob@nauseum.org/dspsclient' 
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a44'>
+  <query type='create' 
+    xmlns='jabber:iq:dsps'
+    minthroughput='1.5KB'
+    maxpublic='20'>
+    <peer port='5290'>
+      dsps.myjabber.net/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
+    </peer>
+    <comment>public comment</comment>
+  </query>
+</iq>
+
+
+    
+      "to" with resource implies reconnection to previous relay stream with previously supplied credentials and authentication as per section "DSPS relay setup", otherwise implies creation of new stream where creator is granted "master" rights.
+      "minthroughput" (optional) is minimum 16 second average throughput below which peers will be disconnected (but not dropped). Checked after every unit of outgoing transfer against the fourth value returned by "who" query for each peer. Legal only upon initial creation of stream. If omitted or negative, 0 is assumed.
+      "maxpublic" (optional) is maximum number of peers that can join without invitation. If omitted or negative, 0 is assumed. If positive, DSPS generates globally unique id for public peers to acknowledge, reported within "stats" message. Said id remains constant for life of stream.
+      <peer/> (optional) full JID of stream on another DSPS. Relay stream will be treated using "slave" rights. Legal only upon initial creation of stream. Multiple such blocks tried in series until successful connection. First successful (last if all failed) remembered by DSPS, all successive <peer/> ignored.. On connection, DSPS initiates handshake using peer's full JID and contents of block for destination's full JID to the relay destination as per section "Connecting to DSPS via default method". Authentication is done as per section "DSPS relay setup". Upon successful handshake, DSPS sends presence notification to peer as per section "Acknowledge of DSPS connection".
+      "port" (optional) for connecting to destination DSPS. If omitted, default is assumed.
+      <comment/> (optional) all such blocks reported in "stats" message. Multiple such blocks allowed. Block may contain a full XML stack of elements. No order implied for "stats" message.
+    
+
+    Possible failure messages:
+
+    
+      
+      
+      
+    Code Message Description
405 Method Not Allowed Attempt at reconnect to relay without existing credentials, relay still connected, <peer/> block present in reconnect request, or feature not supported
504 Gateway Timeout All destination DSPS are unreachable.
+
+  
+
+  
+
+    DSPS creates "id" (empty string is legal), used in "who" replies and notifies client of waiting connection like so:
+
+
+<iq
+  id='dsps1' 
+  type='result'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
+  to='rob@nauseum.org/dspsclient'>
+  <query type='create' xmlns='jabber:iq:dsps'
+    wait='10'
+    host='dsps.jabber.org'
+    port='5290'
+    minthroughput='1.5KB'
+    protocol='0.5'>
+    <feature type='http' version='1.1'/>
+    <feature type='ssl' version='3.0'/>
+  </query>
+</iq>
+
+
+    
+      "from" full JID of DSPS, internally globally unique. Used in handshake and every subsequent communication with stream. May differ with the one specified in "invite" message.
+      "wait" amount of time in milliseconds that DSPS will wait for client to initiate handshake. If timeout occurs, DSPS will totally forget prepared connection and act accordingly.
+      "host" (optional) for handshake and data stream. If omitted default from the "from" is assumed. Intended for P2P connections to be able to report alternate hostname or IP for connection.
+      "port" (optional) for handshake and data stream. If omitted default is assumed.
+      "minthroughput" value from "create".
+      "protocol" version this DSPS supports.
+      <feature/> (optional) supported by this DSPS. Type and version are properties and additional data stored in body. HTTP stream will not follow HTTP protocol. SSL handshake performed encrypted. Both HTTP and SSL connections are only between client and DSPS.
+    
+
+  
+
+  
+
+    Upon receipt of message as per section "Connection waiting", client can either ignore it and connection will timeout, or connect to the DSPS directly via any supported connection method or via relay. There may be a maximum of 1 (one) established connection to DSPS from any Client_full_JID + DSPS_full_JID pair, deviations are handles as per section "Connecting to DSPS via default method". DSPS will not discriminate method via which direct connection is made, even if prior to "disconnect" a different method was used. Any packet from an unauthorized connection is ignored without reporting an error.
+
+    
+
+      Client may request another DSPS to relay this connection as per section "Stream Creation/Relay", utilizing the "create" body. There is no limit on length of relay chain. Upon initiation of handshake with destination, DSPS reports key like so (message sequence unrelated to current DSPS handshake):
+
+
+<iq
+  id='dsps1'
+  type='get'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='rob@nauseum.org/dspsclient'>
+  <query type='create' xmlns='jabber:iq:dsps'>acDgH63I27Gb1</query>
+</iq>
+
+
+      
+        "get" denotes request for auth key.
+        "create" body contains key returned by destination.
+      
+
+      Client must send said key to destination as per section "Connecting to DSPS via default method" and send response to DSPS (which will be transmitted to destination) like so:
+
+
+<iq
+  id='dsps1'
+  type='result'
+  from='rob@nauseum.org/dspsclient'
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  <query type='create' xmlns='jabber:iq:dsps'>acDgH63I27Gb1</query>
+</iq>
+
+
+      
+        "result" denotes reply with auth key.
+        "create" body contains key returned by destination.
+      
+
+    
+
+    
+
+      Client must connect to DSPS on port 80 and initiate handshake. This may be attempted after "create" result received or "disconnect" occurred, and prior to "wait" timeout expiring, then send HTTP request like so:
+
+
+GET /DSPS/STREAM/ HTTP/1.0<CR>
+Host: dsps.server<CR>
+<CR>
+
+
+      And will receive reply from DSPS before the start of data stream, like so:
+
+
+HTTP/1.0 200 OK<CR>
+Content-Type: application/octet-stream<CR>
+<CR>
+
+
+      Upon completion, Client must resume DSPS handshake as per either section "Connecting to DSPS via default method" or section "Connecting to DSPS via SSL method" (if applicable). Subsequent data will not follow HTTP protocol. On error connection closed immediately with optional error messages.
+
+      Possible failure messages:
+
+      
+        
+        
+      Code Message Description
401 Unauthorized (optional) Returned if any error in HTTP handshake.
+
+    
+
+    
+
+      Client must connect to DSPS on specified port and initiate handshake. This may be attempted after "create" result received or "disconnect" occurred, and prior to "wait" timeout expiring, then send following on stream:
+      
+starttls<CR>
+
+      Next, regular TLS handshake is initiated. Upon completion, Client must resume DSPS handshake as per section "Connecting to DSPS via default method". On error connection closed immediately with optional error messages.
+
+      Possible failure messages:
+
+      
+        
+        
+      Code Message Description
401 Unauthorized (optional) Returned if any error in SSL handshake.
+
+    
+
+    
+
+      Client must connect to DSPS on specified port and initiate handshake. May be attempted after "create" result received or "disconnect" occurred, and prior to "wait" timeout expiring. Standard and SSL handshakes are identical in decrypted state and take the form of:
+
+Client_full_JID DSPS_full_JID<CR>
+
+      
+        "Client_full_JID" client full JID as supplied in either the "create" or "acknowledge" message.
+        "DSPS_full_JID" DSPS full JID as supplied in "from" field of "create" result message from section "Connection waiting"
+        <CR> regular carriage return, commonly referred to as the newline character.
+      
+
+      For example, the appropriate string for the above request would be:
+
+rob@nauseum.org/dspsclient dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
+
+      If Client_full_JID and DSPS_full_JID do not have an associated stream, are no longer valid, (e.g. timeout reached or client removed from stream), or connection from said Client_full_JID + DSPS_full_JID pair is in use (i.e. client is still connected to it), connection is closed immediately with possible optional error messages reported. Otherwise DSPS returns uniquely generated key followed by a <CR> like so:
+
+uGhhb74d21
+
+      Client must now send key to DSPS via XML stream like so:
+
+
+<iq
+  id='dsps1'
+  type='get'
+  from='rob@nauseum.org/dspsclient'
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'>
+  <query type='auth' xmlns='jabber:iq:dsps'>uGhhb74d21</query>
+</iq>
+
+
+      
+        "get" denotes request for next auth key.
+        "auth" body contains key returned by DSPS.
+      
+
+      DSPS will now check key, if not valid, close connection, report possible optional error message and resume waiting on original key. If valid, generate new key and send to client like so:
+
+
+<iq
+  id='dsps1'
+  type='result'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='rob@nauseum.org/dspsclient'
+  <query type='auth' xmlns='jabber:iq:dsps'>qgqB42Ij784</query>
+</iq>
+
+
+      
+        "result" denotes return of next auth key.
+        "auth" body contains key returned by DSPS.
+      
+
+      Client must now send received key to DSPS via the stream followed by a <CR>. Once received, DSPS checks key, on mismatch connection is closed immediately with possible optional error messages reported, waiting on key is resumed. Upon successful handshake a message is sent to members of the stream in accordance with the following rules; If the client had type "master" connection, all members of the stream get notified. If the client had type "slave" connection, only other type "master" members get notified. The message takes the form of:
+
+
+  <iq
+  id='dsps2'
+  type='set'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='foo@bar.com/resource'>
+  <query type='presence' xmlns='jabber:iq:dsps'>
+  <peer status='connect'>JID</peer>
+  </query>
+</iq>
+
+
+      
+        "presence" denotes presence change. Body may contain multiple <peer/> blocks where same JID peers must be placed in chronological order relative to each other from start to end of message.
+        <peer/> body is full JID of the joined peer unless peer of type "relay", in which case the resource is not reported.
+        "status" is new status of peer.
+      
+                                                    
+      Possible failure messages:
+
+
+      
+        
+        
+        
+      Code Message Description
401 Unauthorized (optional) Returned if the DSPS is not aware of said Client_full_JID + DSPS_full_JID pair. Where "from" contains DSPS_full_JID that was used in the handshake and "to" contains Client_full_JID that was used in the handshake.
409 Conflict (optional) Returned if connection from said full client JID and full DSPS JID is in use (i.e. client is still connected to it). Where "from" contains DSPS_full_JID that was used in the handshake and "to" contains Client_full_JID that was used in the handshake.
+
+    
+    
+  
+
+  
+
+    DSPS protocol allows multiple peers to use the same stream. Manipulation of the authorized peer list is done through admin functionality described in next several subsections. DSPS protocol allows for three types of peer connections: "master", "slave", and "relay". "master" peers get full control of the stream, "slave" peers get limited control of the stream, and "relay" are treated similar to "slave" except in reporting of JIDs where the resource must be omitted.
+
+    "master" peers are allowed to invite any other user to the stream and drop any peer registered with the stream, including themselves. "slave" peers are only allowed to drop themselves from the stream. Any administrative changes coming from a "slave" peer that are not for the peer's own connection are ignored. Dropping one's own connection is the preferred way of permanently disconnecting from the stream.
+
+    Any data received from a "master" gets copied to every other peer on the stream. Any data received from a "slave" peer gets copied to all "master" peers on the stream only.
+
+    Stream administration request looks like so:
+
+
+<iq
+  id='dsps3' 
+  type='set'
+  from='rob@nauseum.org/dspsclient' 
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'>
+  <query type='admin' xmlns='jabber:iq:dsps' expire='20' wait='10'>
+    <comment>welcome to the stream</comment>
+    <peer type='master'>someone@somewhere.net</peer>
+  </query>
+</iq>
+
+
+    
+      "admin" denotes administrative functions are to follow. Any properties within this block apply to this block alone. Multiple such blocks are allowed.
+      "expire" time DSPS should wait for the "acknowledge" message from any invited peer within block. An "expire" of 0 denotes no time limit. Actual value sent to peer as "expire" is minimum of this value and default value preset for DSPS. If value unparseable or not present, default is used.
+      "wait" time DSPS should wait for invited peer to connect to DSPS after "acknowledge" is received and message from section "Connection waiting". is sent. A "wait" of 0 denotes no time limit. Actual value sent to peer as "wait" is minimum of this value and default value preset for DSPS. If the value unparseable or not present, default is used.
+      <comment/> (optional) block sent to each of the peers. Multiple such blocks are allowed. Block may contain a full XML stack of elements. All such blocks are sent to each of the invited peers as is. No guarantee is made on their order in the <invite/> message.
+      <peer/> JID to execute action upon. If invitation then body will not necessarily be same full JID as one that would respond. Multiple such blocks allowed.
+      "type" type of action to do. "master" denotes invitation, granting master rights. "slave" denotes invitation, granting slave rights. "drop" denotes request to drop peer from stream. "relay" peers may not be invited but may be dropped using this method.
+    
+
+    Possible optional errors include the following:
+
+
+<iq
+  id='dsps3'
+  type='result'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='user@server.org/resource'>
+  <query type='admin' xmlns='jabber:iq:dsps'>
+    <peer acknowledge='expire'>abc@company.com/net</peer>
+    <peer acknowledge='reject'>friend@someplace.com/home</peer>
+    <peer acknowledge='timeout'>abd@company.com/net</peer>
+    <peer acknowledge='missing'>who@knows.org/winjab</peer>
+  </query>
+</iq>
+
+
+    
+      "admin" denotes admin response, sent to sender of "admin" request for every peer in block. Peers may be combined from multiple "admin" requests or peers from single "admin" request may be split over multiple "admin" replies.
+      <peer/> peer in question. For "expire" JID is one from invite request. For "reject" JID is one from which reject received. For "timeout" JID is one from invite request. For "missing" is one from drop request. After this DSPS will totally forget about this peer.
+      "acknowledge" reason for failure. "expire" denotes "expire" timeout sent, has ended. "reject" denotes peer rejected invite. "timeout" denotes "wait" timeout sent, has ended. "missing" denotes peer marked for drop not found registered on tis stream.
+    
+
+    Possible failure messages:
+
+    
+      
+      
+    Code Message Description
403 Forbidden (optional) Returned if peer with "slave" rights attempts to use "master" admin privileges.
+                                
+    
+
+      Upon invite DSPS will attempt to invite each of the peers like so:
+
+
+<iq
+  id='dsps4' 
+  type='get'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
+  to='foo@bar.com/resource'>
+  <query type='acknowledge' 
+    xmlns='jabber:iq:dsps'
+    status='master'
+    expire='20'>
+    <peer>rob@nauseum.org/dspsclient</peer>
+    <comment>some long comment block or structure</comment>
+  </query>
+</iq>
+
+
+      
+        "from" is unique JID/resource pair generated for this JID, not necessarily same as JID/resource pair specified in section "Connection waiting". It is used for identification of the "acknowledge" message.
+        "acknowledge" denotes request for invitation acknowledge.
+        "status" type of connection the client is granted. Same type as tag in invitation request.
+        "expire" time DSPS will wait for the "acknowledge" message.
+        <peer/> peer who initiated this invite. Multiple such blocks may exist if multiple distinct peers sent invitation that have not yet been received by the invitee.
+        <comment/> is <comment/> structure(s) sent in admin request, present if admin request contained it.
+      
+
+    
+
+    
+
+      Upon drop DSPS will immediately closes the connection to the dropped peer. It then will totally forget this peer right after sending it a notification message like so:
+
+
+<iq 
+  id='dsps5'
+  type='set' 
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='foo@bar.com/resource'>
+  <query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'>
+    <comment>some long comment block or structure</comment>
+  </query>
+</iq>
+
+
+      
+        "from" is the DSPS JID/resource pair which DSPS has associated with this connection.
+        "acknowledge" denotes drop notification. Despite the block name, this message does not require a reply.
+        "status" drop denotes a connection drop.
+        <comment/> is <comment/> structure(s) sent in admin request, preset if admin request contained it.
+      
+
+      For every successfully dropped peer a message is sent to all other stream members, following the rules stated for the "presence" message, and takes the form of:
+
+
+<iq
+  id='dsps6' 
+  type='set'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
+  to='foo@bar.com/resource'>
+  <query type='presence' xmlns='jabber:iq:dsps'>
+    <peer status='drop'>JID</peer>
+  </query>
+</iq>
+
+
+      
+        "from" is the DSPS JID/resource pair which DSPS has associated with the connection of the recipient of the message.
+        "presence" denotes presence change. Body may contain multiple <peer/> blocks where same JID peers must be placed in chronological order relative to each other from start to end of message.
+        <peer/> body is full JID of the dropped peer registered on the stream, unless peer is of type "relay", in which case the resource is not reported.
+        "status" is new status of peer.
+      
+
+    
+    
+  
+
+  
+
+    An invited peer has the option to accept or reject an invitation to a stream.
+    
+    
+
+      To accept an invitation to a stream, the peer must reply like so:
+
+
+<iq
+  id='dsps4' 
+  type='result'
+  from='foo@bar.com/moredsps' 
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33>
+  <query type='acknowledge' xmlns='jabber:iq:dsps' status='connect'/>
+</iq>
+
+
+      
+        "from" is the JID/resource pair which will be associated with this connection, only it will be allowed to connect to this stream as this user. A peer may be registered to multiple streams from the same full JID, hence all DSPS full JIDs linked to a given peer must be unique.
+        "to" contains the DSPS JID/resource pair which was the source in the original "acknowledge" message.
+        "acknowledge" denotes acknowledgment to invitation.
+        "status" connect denotes an acceptance of invitation.
+      
+
+      Upon receipt of this reply the DSPS creates a unique resource for this client JID/resource pair. It then prepares the "create" message as described in section "Connection waiting".
+
+    
+    
+    
+
+     Rejecting an invitation can be done in two ways. A peer can forget about the invitation and let the invitation "expire", or preferably a message can be sent like so:
+
+
+<iq
+  id='dsps4' 
+  type='result'
+  from='foo@bar.com/moredsps' 
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33>
+  <query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'/>
+</iq>
+
+
+      
+        "to" contains the DSPS JID/resource pair which was the source in the original "acknowledge" message.
+        "acknowledge" denotes acknowledgment to invitation.
+        "status" drop denotes an rejection of invitation.
+      
+
+      Regardless of the way a rejection was achieved a notification message is sent to the inviting peer, as was described in section "Stream administration". If unknown "type" is sent, it will be interpreted as a reject. A maximum of one "acknowledge" is allowed during the lifetime of an invitation. If multiple such tags are sent, the first tag takes precedence. Any rejection of a public connection will be ignored. 
+
+    
+    
+  
+
+  
+
+    If a peer ever disconnects without first dropping themselves, the following policy applies:
+
+    The peer may reconnect within the "wait" timeout provided in the "create" reply in section "Connection waiting". The peer may choose any supported mode of reconnection supplied in "create" reply, regardless of mode previously used. The "wait" timeout is not cumulative over multiple disconnects. After reconnect, peer will not receive any data that exists on the stream while it was disconnected.
+
+    Upon such disconnection DSPS notifies all other members of the stream, following the rules stated for the "presence" message, and takes the form of:
+
+
+<iq 
+  id='dsps7'
+  type='set' 
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='foo@bar.com/resource'>
+  <query type='presence' xmlns='jabber:iq:dsps'>
+    <peer status='waiting'>JID</peer>
+  </query>
+</iq>
+
+
+    
+      "from" is the DSPS JID/resource pair which DSPS has associated with the connection of the recipient of the message.
+      "presence" denotes presence change. Body may contain multiple <peer/> blocks where same JID peers must be placed in chronological order relative to each other from start to end of message.
+      <peer/> body is full JID of the disconnected peer registered on the stream, unless peer is of type "relay", in which case the resource is not reported.
+      "status" is new status of peer.
+    
+
+    Upon reaching "wait" timeout the procedure is the same if the peer dropped its own connection.
+
+  
+
+  
+
+    Permanent termination of connection can be done in two ways: peer may disconnect from the stream and let the "wait" timeout expire, or more preferably the peer will drop itself from the stream via an "admin" message. The "admin" is still allowed to contain multiple "peer" blocks.
+
+  
+
+  
+
+    The use policy for the stream follows the standard rules described in this document. Type and structure of the data must be negotiated by the peers separately (presumably via the normal XML message stream or within <comment/> blocks). The DSPS stream operates at the speed of the slowest connection (or slower if it is so configured in its internal configuration).
+
+    Data read from peer in a unit of transfer (decided by DSPS) is sent to other peers in a format like so:
+
+0<size><CR><id><CR><data>
+
+    
+      "0" at beginning for checking start of block.
+      <size> length in bytes including id and its trailing CR in form of [1-9][0-9]*[0-9A-Z], where last character is base 36 numerical equivalent power of 1024.
+      <id> id of the sender as per "who" query.
+      <data> data sent.
+      <CR> regular carriage return, commonly referred to as the newline character.
+    
+
+    For example, the appropriate string for the above block would be:
+
+
+0340<CR>
+010<CR>
+this is the data in ASCII form
+
+
+    First block received after connection will always be full block. If discrepancy occurs, receiving peer should disconnect and reconnect back to stream.
+
+  
+
+  
+
+    Two mechanisms exists to gain information about the stream configuration and its members. They are described within next few subsections.
+
+    
+
+      To retrieve listing of all registered peers of this stream and their respective connection status any registered peer sends a message like so:
+
+
+<iq
+  id='dsps8' 
+  type='get'
+  from='rob@nauseum.org/dspsclient' 
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'>
+  <query type='who' xmlns='jabber:iq:dsps'/>
+</iq>
+
+
+      
+        "to" has the usual meaning for this client when referring to this DSPS stream.
+        "who" denotes that this is a listing request. It may not contain a body or attributes, otherwise it will be ignored without error.
+      
+
+      The query follows the standard rules: query originating from a "master" peer will return listing of all registered peers and their associated statuses, query originating from a "slave" peer will only return listing of all registered "master" peers and their associated statuses. Returned results do not have any strict order. If multiple "who" queries were requested by a peer that have not yet received a reply, only one reply need be sent.
+
+      The query reply is formatted like so:
+
+
+<iq 
+  id='dsps8'
+  type='result' 
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='rob@nauseum.org/dspsclient'>
+  <query type='who' xmlns='jabber:iq:dsps'>
+    <peer 
+      type='master'
+      id='0'
+      status='connect'
+      throughput='1KB////4.8KB//3KB'>
+      rob@nauseum.org/dspsclient
+    </peer>
+  </query>
+</iq>
+
+
+      
+        "from" is unique DSPS JID/resource pair for the peer receiving the result.
+        <peer/> body is full JID of registered peer, unless peer is of type "relay", in which case the resource is not reported. A separate block exists for every viewable peer.
+        "type" the type of connection peer has. May contain value of "master", "slave", or "relay".
+        "id" id prepended to data coming from this peer.
+        "status" current status of peer. "connect" denotes peer able to receive data. "wait" denotes peer registered but not connected. "expire" denotes peer was invited but no reply was received yet.
+        "throughput" shows the average throughput to that peer per second in the units specified after the number (e.g. B, KB, MB, GB, TB, EB) in capital letters. Time is measured only during data transfer. Value contains multiple fields delimited by slash (/). Each field represents time span of power of two (2), relative to its position from start of the string. Each filled-in field contains the average throughput over that timespan. e.g. (1B per sec in last sec)/(1.1B per sec in last 2 sec)/(0.9B per sec in last 4 sec). Only fields representing power of zero (2^0 sec) and power of four (2^4 sec) are required. Last field must be filled-in.
+      
+
+    
+
+    
+
+      To retrieve listing of all stream configuration/statistics values or public streams, any registered peer sends a message like so:
+
+
+<iq 
+  id='dsps9'
+  type='get' 
+  from='rob@nauseum.org/dspsclient'
+  to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'>
+  <query type='stats' xmlns='jabber:iq:dsps'/>
+</iq>
+
+
+      
+        "to" if contains a resource, will return statistics for specified stream. Otherwise will return listing of public streams, i.e. any stream with "maxpublic" greater then 0.
+        "stats" denotes that this is a configuration/statistics request. It may not contain a body or attributes, otherwise it will be ignored without error.
+      
+
+      The query reply is formatted like so:
+
+
+<iq
+  id='dsps9' 
+  type='result'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
+  to='rob@nauseum.org/dspsclient'>
+  <query type='stats' xmlns='jabber:iq:dsps'
+    init='00000000000000'
+    protocol='0.5'
+    port='5290'
+    minthroughput='1.5KB'
+    expiredefault='150'
+    waitdefault='100'
+    wait='10'
+    public='5'
+    maxpublic='25'
+    mastercount='20'
+    slavecount='40'
+    relaycount='0'>
+    <feature type='http' version='1.1'/>
+    <feature type='ssl' version='3.0'/>
+    <peer>mydsps@jabber.org/8xd67f56df4f546fdgsfdg65f6g58f</peer>
+    <comment>some server comment</comment>
+  </query>
+</iq>
+
+
+      
+        "from" the DSPS JID/resource pair for the peer receiving the result.
+        "init" UNIX timestamp of the date this stream was initiated.
+        "protocol" protocol version this DSPS supports.
+        "port" default port this DSPS listens for connections on.
+        "minthroughput" as defined in "create".
+        "expiredefault" default time this DSPS will wait for an "acknowledge" response.
+        "waitdefault" default time this DSPS will wait for a connection to its default port after an invitation is accepted.
+        "wait" time this DSPS will wait for this particular client to reconnect if it ever gets disconnected. This is the same value as one sent in the "create" response.
+        "public" number of "slave" peers registered with stream without invitation.
+        "maxpublic" maximum number of "slave"peers allowed without invitation.
+        "mastercount" number of peers with a "master" connection registered on this stream.
+        "slavecount" number of peers with a "slave" connection registered on this stream.
+        "relaycount" number of peers with a "relay" connection registered on this stream.
+        <feature/> (optional) denotes a supported feature. All supported features must be listed.
+        <peer/> (optional) list of public stream connections where all reported statistics match. Present only if "to" in original request contained no resource. Multiple allowed where statistics match for all.
+        <comment/> (optional) parameter(s) with a comments from "create". This block may contain full XML stack of elements. Multiple such blocks are allowed.
+      
+
+      All "status" attributes are required. Any other undefined blocks with any multiplicity, are legal in this block as long as their tags are not identical to any tag within the protocol. Results returned do not have any strict order. If "to" in original request contained no resource, multiple "stats" blocks are allowed, where each contains at least one <peer/> block which has "maxpublic" greater than 0. To join a public stream a client must send message as per section "Accepting an invite".
+
+    
+    
+  
+
+  
+
+    Stream exists from its "create"ion time to the time when there are no more "master" peers registered with the stream. 
+
+    When last "master" peer is dropped from the stream, DSPS will make sure that all the data sent by all the "master" peers was actually copied to all the "slave" peers still present. For every remaining "slave" peer DSPS will initiate a drop event. Once stream is void of any peers it will be totally forgotten by the DSPS and all associated data is released.
+
+  
+
+  
+
+    Error messages look like so:  
+
+
+<iq
+  id='dsps9'
+  type='error'
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+  to='rob@nauseum.org/dspsclient'>
+  <error code='405'>Method Not Allowed</error>
+</iq>
+
+
+    
+      <error/> denotes error block where body is text description.
+      "code" denotes error code.
+    
+
+  
+
+
+
+
+
+  
+
+    File transfer can be easily accomplished over DSPS. Where one user invites another user to a DSPS stream. File details can be transfered in the invitation comment as such: <meta type='file' name='myfile.txt' size='500K' crc32='12345' sha1='23451' mime='application/octet-stream' timestamp='12345' date='20020412T00:00:00'/>. Where the "size" would be in bytes. All properties should reflect their appropriate values for this instance. Once the second peer has accepted, it can simply put a CR on the stream stating that transfer can begin. then the first party simply dumps the contents of file on the stream, closes the stream and "drop"s itself from the stream. DSPS will make sure the second party gets everything that the first party sent before closing the connection. If multiple recipients of the file are required, the sending client can save a lot of bandwidth and transmit only one copy if the file to the DSPS which in term will transmit the data over to all the other connected clients.
+
+  
+
+  
+
+    Same idea as the file transfer. However if more then two parties are involved, every party must have a "master" connection.
+
+  
+
+  
+
+    A server has a JID which it registers with a stream. Any client wishing to join the multicast sends an XML message to the server, which then invites the client with a "slave" connection. Thus everything the server sends is received by every client on the stream. If there are multiple back-up servers, they can be invited with a "master" connection, thus if one of them goes down, the others can take over.
+
+  
+
+  
+
+    It has long been discussed in many Jabber places that a file storage facility is desired. The communication with such a facility can be easily accommodated with DSPS, as such a facility would merely appear as a user to DSPS which can either be "invite"ed or "invite" other users onto personal streams to transfer files as described in 6.1.
+
+  
+
+
+
+
+
+  PASS has the following design flaws that make it unsuitable for its stated purpose of providing raw data-streams to all classes of users, including those behind firewalls or NAT.
+
+  
+
+    PASS requires the use of a large number of individual ports, which on a heavily loaded server can lead to the number of spare ports dropping to zero, causing connections to be refused.
+
+    This is also problematic if PASS is situated behind a firewall. Firewall administrators are typically loathe to allow incoming connections to a large range of ports.
+
+    DSPS only uses one port, and so resolves the first problem, while making the second almost a non-issue.
+
+  
+
+  
+
+    PASS requires the client to have some knowledge of IP, which immediately forces the assumption that the XML stream's underlying protocol is in fact, IP. While at the time of writing this is always the case, it may not always be this way.
+
+    DSPS uses the Jabber ID to do its routing, and so avoids these problems. And while DSPS does use the concept of a TCP connection and an IP port, this information is never actually used anywhere on the XML stream, making the actual connection to the DSPS implementation-defined.
+
+  
+
+  
+
+    PASS makes the IP address of the remote client available to the local client.  While it is rare that this is an actual problem, many users and administrators prefer that IP address information is never actually revealed.
+
+    DSPS never transmits IP address information across the XML stream, and so does not have this problem.
+
+  
+
+  
+
+    PASS requires a client to initiate a connection by opening a (proxied) listening socket, and then soliciting connections. However, TCP works by having the client connect to a remote resource directly. This difference can make the operation of PASS difficult to understand. Also, it is left to the client to distribute the information about this listening socket, which places an additional burden on the client.
+
+    DSPS, while it uses listening sockets to do its work, does all the work of setting up the connection after a client initiates it. All the initiating client has to do is request a connection, connect to the DSPS, and wait - everything else is handled automatically.
+
+  
+
+  
+
+    Due to the master/slave design, DSPS is already able to handle multicasts of streams or such, whilst PASS was only designed for simple p2p stream connections. This will becoming increasingly more important as more emphasis is made on streaming capabilities, for technologies such as audio and video conferencing.
+
+    Due to DSPS generality, the protocol can be easily used for either P2P or P2S2P needs. This eliminates the need for a separate protocol for each of the tasks.
+
+  
+
+
+
+
+
+    It is not mandated for DSPS to reside beside a Jabber server. It is entirely possible for any client to implement a stripped down version of such a server. In such a case the only sections that are required are any error reporting, invitation acknowledgment and statistical responses. Any other area of the protocol becomes optional since the recipient peer will not have the ability to use it anyway.
+
+    Any client may, but is not required to utilize the striped down functionality. When utilizing such functionality the serving client sends an invitation to the recipient client to join the serving client's DSPS stream. Thus the "create" message would list the serving client as the DSPS and would utilize the "host" attribute to tell the recipient client where to connect to the DSPS.
+
+    This ability is advantageous since the recipient client only needs to know one protocol for data transmission over P2P or P2S2P connections, and would not see a difference between the two. The proposed method is for one side to fist try serving a connection to the other. If that fails the other side may attempt to serve the connection. If the second attempt fails the clients may utilize an external DSPS server. The negotiation of who will serve is done outside DSPS protocol. DSPS has no functionality to decide when a P2P connection is possible or desirable, nor does it have enough information to do so reliably.
+
+
+
+
diff --git a/xep-0038.xml b/xep-0038.xml
new file mode 100644
index 00000000..791e5240
--- /dev/null
+++ b/xep-0038.xml
@@ -0,0 +1,365 @@
+
+
+%ents;
+]>
+
+
+
+  Icon Styles
+  A protocol for specifying exchangeable styles of emoticons and genicons within Jabber IM clients.
+  &LEGALNOTICE;
+  0038
+  Deferred
+  Standards Track
+  Standards JIG
+  None
+  None
+  None
+  None
+  Not yet assigned
+  
+    Adam
+    Theo
+    theo@theoretic.com
+    theo@theoretic.com
+  
+  
+    0.5
+    2003-06-02
+    at
+    Bent to public will on using a common object element and enveloping all meta information into a meta element.
+  
+  
+    0.4
+    2003-03-05
+    at
+    Added "format" back in. Refused to simplify to use "object" for everything. Fixed some typos.
+  
+  
+    0.3
+    2002-11-05
+    at
+    Simplified, even though it loses some flexibility. Should be the final version.
+  
+  
+    0.2
+    2002-07-24
+    at
+    Added feedback, still needs serious Schema work
+  
+  
+    0.1
+    2002-06-28
+    at
+    Initial version
+  
+
+
+
+  This proposal standardizes the use of graphical emoticons and "genicons" in Jabber IM clients to prevent confusion and competing conventions that will soon arise, enabling client developers to spend their energy on more important parts of their projects.
+  Emoticons are the text string 'smiley' or 'frowny' faces such as :-) and :-( that people often use in email or instant messaging to represent emotions. Genicons are a term being coined here to mean non-emotive text pictures (often called 'ASCII Art') that serve to replace typing the full word or to simply be cute or creative in the conversation.
+  Many new Internet users demand graphical emoticon and genicon support in their IM clients. We should satisfy their needs if we ever wish to see them use Jabber instead of another IM system.
+  While traditionally emoticons and genicons have been typed and displayed as text, the recent trend of using graphics, and sometimes sounds, instead of text to represent these pictures will be assumed for purposes of this proposal. Also, the term "icon" will be used in place of "emoticon" and "genicon" for purposes of convenience.
+
+
+
+  The following issues must be solved for in this specification.
+  
+    Here and Now: The convention should not rely on technologies such as feature negotiation or generic pub/sub which do not exist yet in Jabber in order to work properly. The convention should be a "here and now" solution, relying only on the current Jabber protocol.
+    Meaningful: The convention for creating the icons must be meaningful to users of clients without icon support, or even users on the other side of transports. Whatever method is used, it should not be cryptic or difficult to understand in text-only mode, in case the user does not have or want the capability to view the icons.
+    Component Friendly: In order for gateways, bots, and other "semi-intelligent" components to be able to convert or otherwise use the specification (such as to and from the MSN icon style, or use icons in conversations with Artificially Intelligent bots), a specific list of icons must be possible. Since these bots do not have an intelligent human behind them deciding their every action, they cannot deal with unlimited possibilities.
+    Protect Privacy: Sender-defined external data must not be required to properly display the icons because it can be used by the sender to track the user, circumventing their privacy. When the sender can define their own graphics or sounds to be used for the icons, they can use unique URLs and monitor when these unique URLs are accessed. External data may be allowed as long as it is not required for proper use of the icons, but it would be best to leave external data completely out of the system.
+    Conserve Bandwidth: The amount of markup used within the messages to define the icons should be kept to a minimum, as well as keeping the media files used for the icons from being transferred over the wire with the messages themselves. These easily consume too much bandwidth, a precious resource to most of the Internet.
+    Be Passive: The convention should not force transports or recipients to take any action to properly display the icons. Not only does it put extra strain on the components, but it would also unnecessarily break old clients. Transports and recieving clients may have the option of taking some actions, but they should not be forced to.
+    Internationalization: The convention must be inherently international in order to ease adoption of Jabber throughout the world and prevent later growing pains. The use of English must be kept to a minimum, restricted to "meta information" about the icons themselves, and must dynamically allow for non-English language sets.
+  
+  Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not allow external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components.
+
+
+
+  To find out if an entity supports Jabber Icon Styles, look for the feature category of http://jabber.org/protocol/icon-styles using jabber:iq:browse or http://jabber.org/protocol/disco. The same feature category can be used with feature negotiation.
+
+
+
+  Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not require external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components. How these icon styles are exchanged - as well as advertised - is out of the scope of this specification. The text strings representing the icons will be sent like any other text (this JEP doesn't require extra tags or attributes in the messages being sent).
+  All icons are created by defining each icon then grouping them together into "Icon Definition Files". These files, along with the object files associated with the icons, are called "icon styles". Icon styles may be traded and shared among users of all supporting clients like skins or themes, similar to WinAmp, XMMS, GNOME, and other customizable applications. This creates a platform-independent system, providing a great degree of customization for the user, and allowing client developers to focus on other features.
+
+  
+    Each icon in a style is defined and grouped together in an XML document, the "Icon Definition File". Each definition file for all styles is named "icondef.xml". There is only one such Icon Definition File per style. The W3C Schema for the Icon Definition File plus an example finished Icon Definition File can be found under Schema, below.
+  
+
+  
+    The meta elements contain information about the Icon Style itself, rather that the individual icons. They are contained within the <meta> element, which is directly under the root element. There is one and only one the <meta> element.
+    
+      Name: This is an arbitrary text string (spaces allowed) which is the full name of the Icon Style. Only one name can be included.
+      Version: This is an arbitrary text string (no spaces allowed) which is the version number of the Icon Style. Any version format is allowed, but the major.minor or major.minor.trivial formats are recommended. Only one version can be included.
+      Description: This is the full description of the Icon Style. It summarizes the look and types of the icons, and can be used for keywords in searching. This is optional, but recommended.
+      Author: This is the full name of the author. Multiple authors are allowed.
+      Creation: This is the date of the creation of this version of the Icon Style. The date is in the ISO 8601 standard format.
+      Home: This is the full HTTP web address of the Icon Style's homepage. This is optional.
+    
+  
+
+  
+    The <text/> element defines what text string(s) are recognized by the client as an icon. There may be multiple <text/> elements in an <icon/>, such as for different languages or simply for multiple text strings producing the same result (for example: :-) and :))
+
+    
+      Each may have an xml:lang attribute, as defined in Section 2.12 in the official XML 1.0 reference document. The xml:lang attribute allows for two-letter language codes, dialects, and custom "languages" to define foreign IM protocols, for example.
+    
+
+    
+      In order to be more accurate in recognizing text strings intended to be icons from those that are just coincidences in normal conversation, the client should follow the "whitespace rule" of making sure there is some form of whitespace on at least one side of the text string. This is only a guideline; individual clients can implement different rules as needed. A newline and tabs count as whitespace in addition to spaces. This is to make sure that chunks of code and URIs are not accidentally converted into graphical pictures. Also, text strings cannot include newlines or tabs. All characters must be on the same line with only spaces within the string, and extra spaces should not be ignored. This is to make it much easier on text parsers looking for these text strings.
+    
+
+    
+      The text strings must be case sensitive. This is a rule that compliant clients must follow. "Cat" cannot be used in place of "cat" or "CAT". All three are separate text strings, and therefore must have separate <text/> elements, although they may of course use the same objects.
+    
+  
+
+  
+    The <object/> element defines what multimedia objects are inserted into the displayed message, replacing the text string(s) defined in <text/>. An object may be a bitmap graphic, vector graphic, audio clip, rich text formatting rules, or any other media that can be stored in a separate file. The <object/> element is identical to the OBJECT element used in XHTML 2.0, and the specification used there should be used to govern the <object/> element here. Note that because the XHTML 2.0 OBJECT specification is quite complex (although very flexible and future-proof), client developers are encouraged to only implement compliant sub-sets of the OBJECT specification for their clients. There may be one or multiple <object/> elements in an <icon/>, such as for alternative file formats (such as 
+ GIF vs. PNG), or multiple objects to use at the same time (such as graphic and sound files).
+  
+
+  
+    The <x/> element allows any type of extensions to the icondef.xml file, such as to specify how the user's nickname can be colored in multi-user chat windows or defining additional data about the style or authors. Each must have an xmlns attribute with a namespace that the extension operates under. Multiple <x/> elements may be in the <icon/> or <icondef/> elements. This functionality is optional for clients to support, and clients should ignore all extensions they do not understand.
+  
+
+  
+    The icondef.xml file must all be located in the root directory, which is named after the style and version (example: ./happy_days-1.2 or ./gold_angelic-1.0.0). There is only one root directory per style. The object files may either be in the root directory as well, or be in sub-directories for categorization and easier maintenance reasons. If sub-directories are used, they must match the URIs used in the <object/> element in the icondef.xml file.
+
+
+./gold_angelic-1.0.0
+./gold_angelic-1.0.0/icondef.xml
+./gold_angelic-1.0.0/alert.ogg
+./gold_angelic-1.0.0/red-exclamation-mark.svg
+./gold_angelic-1.0.0/shocked.svg
+./gold_angelic-1.0.0/woman.svg
+./gold_angelic-1.0.0/pngs/happy.png
+./gold_angelic-1.0.0/pngs/sad.png
+./gold_angelic-1.0.0/pngs/man.png
+./gold_angelic-1.0.0/pngs/woman.png
+./gold_angelic-1.0.0/wavs/boohoo.wav
+./gold_angelic-1.0.0/wavs/choir.wav
+./gold_angelic-1.0.0/wavs/alert.wav
+
+  
+
+  
+    The icondef.xml file and all object files must be packaged in the ZIP format following the above hierarchy (the directory must exist in the package, with all files in it). The package must have the file extension .jisp (Jabber Icon Style Package), and the MIME type application/vnd.jisp as defined in the official IANA registration. This allows Jabber clients to automatically install icon styles through web browsers. When the client installs the package, it should probably be kept in the archived format, instead of unzipped. This not only saves disk space, but also makes the packages easier to manage and exchange.
+  
+
+
+
+  Icons styles should be easy to create, distribute, and most importantly, use. The packaging and official MIME type helps with the first steps, but it is ultimately up to the client developers to fully support the specification and make sure it is easy for users to manage.
+
+   
+     The procedure for using Jabber icons is simple and straightforward.
+     
+       The user installs and turns on ("activates") an icon style (using their client's GUI, most likely) they have received off the Internet or somewhere else.
+       The user selects the desired icon they wish to include in their message from their client's GUI (a drop-down list of installed icons, for example).
+       The client translates the selected icon into its main text string equivelent, which is found in the icon's <text> element. If there are multiple <text> elements, follow the procedure under "Text Strings", below.
+       The client sends the message with the text string to the intended recipient.
+       The recipient client receives the message with the text string.
+       If the recipient has an icon style activated that defines that text string, it is converted into the appropriate object. If there are multiple objects files for each icon, follow the procedure under "Object Files", below. If there are multiple icon styles installed which define that text string, follow the procedure under "Combining Styles", below. If the recipient does not have such an icon activated, then they simply see the text string without any changes.
+     
+   
+
+  
+    Because icons may have multiple text strings associated with them, clients need to be able to figure out which one to use when a user selects the desired icon from their GUI. This is ultimately completely up to the implementation, but here is a suggestion:
+    
+      First look for any text strings that are the same language as what the user is using (if the user is using english, then look for English text strings, ignoring languages like German or Simplified Chinese). Optionally, if the client is smart enough, it can instead look for text strings in the language that the intended recipient is using (using Browse/Disco or simply keeping track of languages used in an ongoing conversation). The language for text strings is found in the xml:lang attribute for <text/> elements.
+      If there are no text strings that match the user's language, then look for one that has no defined language.
+      If there are multiple options even after the above steps, select the one that comes first in the <icon/> element.
+      If there are no text strings that are in the user's language or no language defined at all, then it is probably best for the client to not even display the icon as a choice at all. But if the client still wants to allow it, then simply select the text string of any language that comes first in the <icon/> element.
+    
+  
+
+  
+    Like multiple text strings, icons can have multiple object data files associated with them, and therefore clients also need to be able to figure out which ones to use when a user selects the desired icon from their GUI. Here is a suggestion of how those files can be chosen among multiple options, although this is completely an implementation issue (as with multiple text strings).
+    
+      First look for any of these objects that are of MIME types the client can understand and use. For example, most clients could only use image/bmp and maybe audio/x-wav, but some newer clients may be able to support image/png, image/svg+xml and audio/x-ogg.
+      If there are still multiple object MIME types which the client can understand and use, then the client should rank the MIME types it can support, choosing its favorite.
+      If there are still multiple objects of the same MIME type, then the client should choose the first one in order in the <icon/> element.
+      If there are no files of any MIME type the client can understand, then it should ignore using any objects or even the entire icon.
+    
+    The Rules for processing objects in the XHTML 2.0 OBJECT specification may also be of help in coding the procedure of choosing an object to use, especially when it comes to nested and author-preferred objects.
+    The client should also take note of the file sizes. The client should set (possibly as a user-defined option) the maximum file size in kilobytes for object files. Anything above this amount implies the file will be too big to properly render, and the icon style developer is probably being abusive.
+    Also, if you are developing an icon style, please make sure the MIME types specified in your icondef.xml file are correct. And also make sure that the files you use are reasonable in any byte, pixel, and timelength size. And although any file format can be supported, try to use BMP, PNG, SVG, WAV, OGG formats because they are open, free, and becoming increasingly supported in developer tools and programming languages.
+  
+
+  
+    A client may permit the user to activate multiple icon styles at one time. This would be useful for styles which make use of different text strings, and the user wants them all. The client should force the user to rank the multiple styles for purposes of conflict resolution between icons. The highest ranking style gets preference over lower ranking styles. This ranking doesn't have to be anything more than simply dragging the style names into top-to-bottom rows, with the styles on top being higher ranked than those below.
+  
+
+  
+    Although any text string can be turned into an icon by defining it in an icondef.xml file, it is highly reccomended they either follow traditional ASCII Art (smileys and frownys, for example) or full keywords in simple markup such as double-colons. If you want to design icons, always keep in mind that not every Jabber user uses graphics to "translate" this to something visual, as explained in the "Meaningful" requirement, above. Here is a short list of recommended "core" icons that should be in most definitions, as well as possibly be used by transports:
+    
+      :-) and :) - A smiling face.
+      :-( and :( - A frowing face.
+      ;-) and ;) - A winking smiling face.
+      :'-( and :'( - A crying face.
+      >:-( and >:( - An angry face.
+      :yes: - A thumbs-up or checkmark.
+      :no: - A thumbs-down or a crossmark.
+      :wait: - An open hand, palm outstretched.
+      @->-- and :rose: - A rose flower.
+      :telephone: - A telephone.
+      :email: - An electronic-looking envelope.
+      :jabber: - Jabber's lightbulb logo.
+      :cake: - A birthday cake.
+      :kiss: - A pair of puckered lips.
+      :heart: and :love: - A heart.
+      :brokenheart: - A broken heart.
+      :music: - A musical note or instrument.
+      :beer: - A beer mug.
+      :coffee: - A cup of coffee.
+      :money: - A gold coin.
+      :moon: - A moon.
+      :sun: - A sun.
+      :star: - A star.
+    
+  
+
+
+
+  There are no security features or concerns related to this proposal.
+
+
+
+  The JSF shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as application/vnd.jisp and .jisp, respectively. The registration can be found at http://www.iana.org/assignments/media-types/application/vnd.jisp. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.
+  Also, this specification uses other MIME types that are maintained by IANA for the object and xml files that are included in the icon style packages.
+
+
+
+  JANA shall register the namespace http://jabber.org/protocol/icon-styles as an official feature category.
+  Also, JANA may choose to define IM-specific xml:lang "language codes" for use within Jabber (in addition to those defined in the XML specification). Such language codes would allow Jabber developers to support icons from MSN, Yahoo, and popular web message programs.
+
+
+
+  
+    
+
+
+  
+    
+      
+        
+          
+            
+            
+            
+            
+              
+                
+              
+            
+            
+          
+        
+        
+          
+            
+              
+                
+                  
+                
+              
+              
+                
+                  
+                
+              
+              
+                
+                  
+                
+              
+            
+          
+        
+        
+          
+            
+          
+        
+      
+    
+  
+
+    ]]>
+  
+
+  
+    
+
+  
+    Gold Angelic
+    1.0.0
+    Angelic faces and themes with gold highlights.
+    Adam Theo
+    Sebastiaan Deckers
+    Mattias Campe
+    2002-10-31
+    http://icon-styles.jabberstudio.org/Gold_Angelic
+  
+  
+    :-)
+    :)
+    
+    
+  
+  
+    :-(
+    :(
+    
+    
+  
+  
+    :-O
+    :O
+    
+  
+  
+    ::man::
+    ::mann::
+    ::muz::
+    (z)
+    
+  
+  
+    ::woman::
+    (x)
+    
+    
+  
+  
+    ::alert::
+    
+    
+    
+  
+
+    ]]>
+  
+
+
+
+  
+    This proposes a standard, simple, plaintext-based icon convention. It does not attempt to create a powerful XML-based convention wherein XML tags are used to extensibly represent the icons. However, this proposal isn't exclusive, and does not prevent such an XML-based convention from being created at a later date. It may also be possible to build such an extensible XML-based convention on top of this plaintext one.
+    The Icon Styles that the sender used to create the message may be of use to the recipient. A separate specification can be developed for the transferring of the name and version of the Icon Styles used by the sender. The recipient's client may then be smart enough to automatically use the same icons as the sender intended, possibly even fetching and downloading the icon styles as needed. This would likely require directory services, so has not been included in this proposal.
+    The functionality of the icondef.xml files may be useful for variable text strings. Text strings that may change from session to session, such as the user's nickname in a multi-user chat. A set of variables could be defined that represent these variable datas, therefore allowing them to be manipulated in the same way set text strings are.
+    This convention may be adopted beyond the scope of Jabber into web browsers, email clients, and Wiki sites. There is great potential for a generalized, exchangeable convention for emoticons and genicons.
+    A "SVG Transport" may be created to enable clients to send SVG icons to it and get back icons in another format of their choice, such as PNG or JPG. This would speed up the adoption of SVG within Jabber greatly.
+    An online Web- (or even Jabber-) based editor to create icon style packages from the individual components would be a great tool for developers. This would be a great project for JabberStudio or even the Ransom model.
+  
+
+
+
+
+
+
+
diff --git a/xep-0039.xml b/xep-0039.xml
new file mode 100644
index 00000000..d1d40fda
--- /dev/null
+++ b/xep-0039.xml
@@ -0,0 +1,426 @@
+
+
+%ents;
+]>
+
+
+  
+    Statistics Gathering
+    A protocol to enable gathering statistics from Jabber servers and components.
+    &LEGALNOTICE;
+    0039
+    Deferred
+    Standards Track
+    Standards
+    
+      Paul
+      Curtis
+      pcurtis@terrapin.com
+      pcurtis@www.terrapin.com
+    
+    
+      Russell
+      Davis  
+      ukscone@burninghorse.com
+      ukscone@burninghorse.com
+    
+    
+      Ryan
+      Eatmon
+      reatmon@jabber.org
+      reatmon@jabber.org
+    
+    
+      David
+      Sutton
+      dsutton@legend.co.uk
+      peregrine@legend.net.uk
+    
+    
+      0.6.0
+      2002-11-05
+      rkd
+      Corrected David Sutton's JID and email. It has been pointed out
+	to me by amoungst others Rob Norris that things such as lists of JIDs 
+	and lists in general are really the province of disco and browse and 
+	that at least one of the suggested 'core' statistics doesn't 
+	make sense for all components so removed these from the JEP. This namespace
+	was starting to become a generic data gathering namespace and we already 
+	have one of those, so i've reworked yet again hopefully for the 
+	final time it should now be simpler to implement and more consistent in
+	all cases.
+        
+    
+      0.5.0
+      2002-11-03
+      rkd
+      Heavily modified JEP according to suggestions from Matt Miller (linuxwolf). rkd had some additional thoughts on the name attribute, this version reflects those. Reorganized the description section.
+        
+    
+      0.4.2
+      2002-10-25
+      rkd
+      Changed rkd's email address and jid. Modified namespace to use http uri.
+        
+    
+      0.4.1
+      2002-08-20
+      rkd
+      Corrected error codes
+        
+    
+      0.4
+      2002-08-18
+      rkd
+      Fixed two silly typos that crept back in. Rewrote SNMP
+      to read better. Added the DTD
+        
+    
+      0.3
+      2002-08-16
+      rkd
+      Added <display/> so a server or component may
+      optionally return data in a human readable format. It is nothing
+      more than a bit of visual fluff but it has potential to be quite
+      useful. Renumbered the revisions to allow room for stpeter's new 
+      JEP numbering scheme, sorry if it is now confusing but I hadn't 
+      left much room to grow with the previous revision numbering. A 
+      little more prettying and judicious use of punctuation has occurred.
+    
+    
+      0.2.2
+      2002-08-15
+      rkd
+      Fixed some typos and generally prettied up
+    
+    
+      0.2.1
+      2002-08-14
+      rkd
+      I seem to have misunderstood one of Ryan Eatmon's
+      suggestions and didn't make this generic enough. I have  
+      fixed that now. Clarified error codes and reworked how errors
+      are indicated to work with the new generic
+      namespace. Rearranged the order of the sections a bit make this
+      JEP a more linear read.
+    
+    
+      0.2
+      2002-08-13
+      rkd
+      Complete reworking to take into account suggestions made
+      by Ryan Eatmon and others. Ryan Eatmon added to list of authors to
+      reflect his significant contribution to the current form of this
+      JEP. I have also received a few comments that this document
+      previously read like an IETF document. Whether that was a good or
+      bad thing I was unable to ascertain but I've tried to lighten the
+      tone a little.
+    
+    
+      0.1.5
+      2002-07-23
+      rkd
+      Changed data returned by <who/> as per comments by
+      psa
+    
+    
+      0.1.4
+      2002-07-23
+      rkd
+      Converted to XML as per JEP spec in preparation for
+      submission as experimental JEP.
+    
+    
+      0.1.3
+      2002-07-23
+      rkd
+      A numeric values unit type is now returned using an attribute
+      "units" rather than specifying that it be returned in the smallest
+      sensible unit type to produce an unsigned integer.
+    
+    
+      0.1.2
+      2002-07-23
+      rkd
+      Justify inclusion of the 501 (Not Implemented) error code
+      as per comments by Zion
+    
+    
+      0.1.1
+      2002-07-22
+      rkd
+      Fixed some typos
+    
+    
+      0.1
+      2002-07-21
+      rkd
+      Initial version.
+    
+    JEP-0053 (JANA)
+  
+  
+    As things currently stand it is not possible to obtain statistics
+    from a jabber component or server without resorting to parsing the 
+    various log files. This makes it extremely difficult to obtain statistics 
+    that are of any use in real world situations. This JEP attempts to 
+    rectify this situation by defining a new namespace that would be used 
+    to obtain statistics from a component or server so that they may be 
+    manipulated and used in a useful manner. For the purposes of this namespace
+    a statistic is anything that maybe expressed in a numeric form, such as the
+    uptime of a server, the number of registered users and the
+    number of packets sent. Things such as a list of currently online users or
+    a list of registered users are beyond the scope of this namespace and
+    properly belong within browse or disco.
+  
+  
+    
+      This is a pretty simple namespace. It consists of a <stat/> tag with
+	three attributes. name, units and value.
+      
+      <query xmlns='http://jabber.org/protocol/stats'>
+        <stat name='' units='' value=''/>
+      </query>
+      
+       There is one variation in the	case of an error invalidating one or 
+	more errors in a single returned query that does not actually
+	invalidate the whole query.
+      
+      <query xmlns='http://jabber.org/protocol/stats'>
+        <stat name=''><error code=''>...</error></stat>
+      </query>
+      
+    
+    
+      The name of the statistic. The format for this attribute is the
+	generic statistic type such as bandwidth, users, time etc. followed by
+	a '/' character and then then the name of the actual statistic. For 
+	example bandwidth/packets-in, time/uptime and users/online. This will 
+	be assigned and administered by JANASee Name Registration.
+    
+    
+      This is the units type of the statistic. As with the name attribute it
+        will be assigned and administered by JANASee Name
+        RegistrationIt is suggested that JANA use where appropriate
+        commonly accepted international standards when assigning unit types
+	i.e. seconds, grams, meters, bytes etc.
+    
+    
+      This is the actual returned value of the queried statistic. The value returned is in
+	multiples of the unit described by the units attribute.
+    
+    
+      To query a component or server a client sends an iq packet of
+      the type 'get' to the component or server. The component or
+      server responds with the list of statistics that it supports.
+
+      
+      send:     <iq type='get' to='component'>
+	          <query xmlns='http://jabber.org/protocol/stats'/>
+                </iq>
+      
+
+      recv:     <iq type='result' from='component'>
+                  <query xmlns='http://jabber.org/protocol/stats'>
+	            <stat name='time/uptime'/>
+	            <stat name='users/online'/>
+	                  .
+	                  .
+	                  .
+	            <stat name='bandwidth/packets-in'/>
+	            <stat name='bandwidth/packets-out'/>
+	          </query>
+                </iq>
+      
+      Once a client knows which statistics a component or server
+      supports it may now request the actual statistics by sending an iq
+      packet of the type 'get' containing a request for the specific
+      statistics and sending that to the component or server.
+
+      
+      send:     <iq type='get' to='component'>
+                  <query xmlns='http://jabber.org/protocol/stats'>
+	            <stat name='time/uptime'/>
+	            <stat name='users/online'/>
+	            <stat name='bandwidth/packets-in'/>
+	            <stat name='bandwidth/packets-out'/>
+	          </query>
+                </iq>
+
+
+      recv:     <iq type='result' from='component'>
+                  <query xmlns='http://jabber.org/protocol/stats'>
+                    <stat name='time/uptime' units='seconds'	value='3054635'/>
+	            <stat name='users/online' units='users' value='365'/>
+	            <stat name='bandwidth/packets-in' units='packets' value='23434'/> 
+	            <stat name='bandwidth/packets-out' units='packets' value='23422'/>      
+                  </query>
+                </iq>
+      
+
+    
+    
+      If an error occurs with one or more of the requests for
+      statistics the component or server should return one of the 
+      following error codes.
+      
+        
+        
+	
+        
+        
+      Code String Reason
401 Unauthorized Querying JID is not
+        authorized to perform that query
404 Not Found The statistic was not
+	found for some reason
501 Not Implemented Although statistic
+        is advertised as available it has not been implemented
503 Service Unavailable Statistic is
+        temporarily unavailable
+
+   
+      Because we wish to be able to collect groups of statistics
+      within a single returned packet errors must be handled in a two
+      tier way with authorization and core errors that would render 
+      all the statistics meaningless being indicated 
+      with a type='error' in the returned packet.
+
+      
+        <iq type='error' from='component'> 
+          <query xmlns='http://jabber.org/protocol/stats'>  
+            <error code='401'>Not Authorized</error>
+          </query>
+        </iq>
+      
+
+      Errors in a query that only invalidate one or more of the
+      requested statistics are indicated with an </error> tag
+      embedded inside the </stat> tag.
+      
+
+      
+        <iq type='result' from='component'>
+          <query xmlns='http://jabber.org/protocol/stats'>
+            <stat name='time/uptime units='seconds' value='4534'/>
+	    <stat name='bandwidth/packets-in'><error code='503'>Service Unavailable</error></stat>
+            <stat name='bandwidth/packets-out'><error code='503'>Service Unavailable</error></stat>
+          </query>
+        </iq>
+      
+    
+  
+  
+    
+      All statistic names, returned data units types and other
+	pertinent statistic information will be assigned and registered with
+	the Jabber Naming Authority in the category stat. 
+	Unfortunately at this time such a body does not exist so we will 
+	have to rely on component and server authors diligently
+	researching to ensure that their desired name is not already 
+	in use and that they adequately document the returned units
+	type and anything else that would normally be registered. 
+	Hopefully by the time this JEP is formally adopted
+	a central naming authority for the Jabber protocol will be in
+	place and functional and authors will be then able to register
+	their names.
+      
+      
+        
+	  
+	
+	
+	  
+	
+      Stat Description Returned Units
registered name description of
+	  statistic/reason unit type returned by
+	  query
+    
+    
+      
+        Although components and servers are free to support whichever statistics they
+        feel are justified for their particular component or server it is
+	suggested that the following set of three core statistics are
+	implemented by all components and servers.
+
+      
+	<stat name='time/uptime'/>
+	<stat name='bandwidth/packets-in'/>
+	<stat name='bandwidth/packets-out'/>
+      
+      
+        
+	  
+	
+	
+	  
+	
+	
+	  
+	
+	
+	  
+	
+      Stat Description Returned Units
time/uptime uptime of component or
+	  server Seconds
bandwidth/packets-in packets received by component or server packets
bandwidth/packets-out packets transmitted by component or server packets
+    
+    
+      For several reasons the
+	http://jabber.org/protocol/stats namespace does not
+	support human readable labels for the returned values. Generally the
+	application querying the statistic should already know what the
+	statistic is and in what units the value is returned. However if the
+	application really wants some form of human readable label for the
+	returned value although not an optimal solution or even recommended by
+	the authors of this JEP it should be safe for
+	it to convert the value of the units attribute into a string and use
+	that as a label for the returned statistic value.
+    
+    
+      In most cases the http://jabber.org/protocol/stats would be tied to the component or
+      servers admin JID so that only that JID may query the statistics
+      however there are advantages to having a three tier system where
+      some statistics are available to all JIDs, some to an arbitrary
+      JID listed in the configuration file and all available to the
+      listed admin JID. As the first case can be emulated by the
+      second I propose that when implemented the http://jabber.org/protocol/stats
+      namespace is configured to use the three tier method of
+      authorizing queries.
+    
+    
+      Supporting industry accepted standards and procedures
+      For more details on SNMP
+      and CIM within 
+      the Jabber protocol is highly desirable as long as it does not 
+      restrict the flexibility or functionality of Jabber. So while 
+      the http://jabber.org/protocol/stats namespace seems to fall within the domain of 
+      the SNMP and CIM standards amongst others and large jabber 
+      installations would find direct support an appealing prospect 
+      when tying jabber into their existing network information and 
+      management systems the jabber:iq:namespace will not do this. 
+      Because Jabber is an XML based protocol, conversion of 
+      the returned data to other formats including those required 
+      for SNMP, CIM etc. should be relatively simple. Not supporting
+      industry standards is not without advantages. By leaving the
+      http://jabber.org/protocol/stats as a pure jabber namespace we allow
+      ourselves to obtain not only commonly used statistics but also
+      some unusual ones as well. For example imagine a jabber enabled
+      vending machine, by remaining free of the encumberence and
+      limitations of SNMP etc. we can directly (if allowed by the
+      controlling component) query the fluid ounces dispensed, most
+      popular beverage and the amount of money that has been collected.
+      Finally although it is unlikely to occur by staying true to our
+      roots and avoiding direct SNMP support we avoid any possibility
+      of conflict with other network management agents such as net(ucd)-snmp.
+      
+    
+  
+  
+      TBD
+  
+  
+    
+      TBD
+        
+    
+      TBD
+    
+  
+
diff --git a/xep-0040.xml b/xep-0040.xml
new file mode 100644
index 00000000..534e1c5a
--- /dev/null
+++ b/xep-0040.xml
@@ -0,0 +1,270 @@
+
+
+%ents;
+]>
+
+
+   
+      Jabber Robust Publish-Subscribe
+      Note: This proposal has been superseded by JEP-0060; please refer to that document for the successor protocol.
+      &LEGALNOTICE;
+      0040
+      Retracted
+      Standards Track
+      Standards
+      None
+      None
+      JEP-0060
+      None
+      
+         Tim
+         Carpenter
+         tim.carpenter@in8limited.co.uk
+         
+      
+      
+        0.2
+        2004-07-26
+        psa
+        Formally retracted this proposal in favor of JEP-0060: Publish-Subscribe.
+      
+      
+         0.1
+         2002-08-02
+         tc
+         Initial Release For Comment
+      
+   
+   
+      Note: This JEP has been superseded by &jep0060;; please refer to that document for the successor protocol.
+      This document introduces and lays out a preliminary protocol for a robust form of publish-subscribe over the Jabber messaging environment -- Jabber Robust Publish Subscribe (JRPS).
+      Implementation issues in the environment are appended, covering Permissioning and Contributions. Both are likely to require separate JEPs, but need to be constructed sympathetically.
+      In creating this addition, I have an underlying philosophy to sustain a "fractal" world of publish-subscribe components, such that a subscriber to a pubsub component may well be a pubsub component in itself, representing its own community of subscribers. This will allow Jabber to support organic scalability found on other platforms.
+      
+         Publish-Subscribe and other messaging environments that exist are often classified as providing one or more of the following three levels of service.
+         
+         Best Try, where data may on rare occasions get lost. Small footprints and ultimate performance are the aim where the impact of occasional data loss in business, legal, confidential or other terms is not significant compared with the core priority of performance.
+         Robust, where non-delivery of data can be detected and recovered by recipients and that the sequence, integrity and completeness of data can be ascertained with a high level of confidence. Non-delivery of data would have a significant and lasting negative impact on the quality and integrity of the data.
+         Transactional, where there is an absolute, mission-critical need to ensure that all communication flow is guaranteed and if problems occur during a set of connected steps, then the situation can be rolled back (reversed) to the state before the operation commenced.
+         
+         This document concerns itself with level 2 Publish Subscribe -- "Robust".
+      
+      
+        JRPS is required in environments where there is a higher demand for guaranteed delivery in high throughput, low latency environments where data has value and can contain business intelligence, but does not demand a full transactional (e.g. 2-phase commit) strength environment.
+        Such environments often exercise business logic upon data received, so the notion of updates to all or part of data, the expression of the definitive, full compliment of a particular set of related data, the correction of data in full or in part and the notification that data is no longer valid needs to be supported. The existing type="set", though very suitable in a wide range of applications, does not provide suitable granularity in all environments.
+        Robust environments require that a receiver can tell when data has been lost and that a receiver also has the means to request the repair of any gaps efficiently. This must be done whilst keeping delay or disruption to ongoing data flow to a minimum. Jabber does not provide the means to detect or repair gaps, and traditional ACKing of each packet is slow and costly.
+        It would be advantageous to permit forms of permissioning and access control upon data that has value. Such permissioning and control should not be overly burdensome on the rapid transmission of data. It should allow a suitable level of abstraction to keep changes to a data item"s expression of permission coding/level to a minimum, to avoid the need for excessive changes to such codes. Abstraction will also permit permission coding to be kept compact, as it will, in effect, be tokenised.
+        JRPS then requires the ability to detect and repair gaps in the stream, to provide a means to convey richer information about the nature of the data in context to what has come before and to enable the publisher to have control over who sees what.
+        In addition, a pubsub component should be able to provide information and parameters about its implementation of JRPS to subscribers. Subscribers must inquire about such information from the pubsub component to gain the full benefit of a JRPS service.
+       
+         Identify the tasks that users can't complete because we are lacking this crucial piece of protocol. (Note: users are not just IM users, but any person, system, or application that could gain value from interacting with Jabber.)
+         Discuss other projects or protocols and how Jabber could interface with them because of your proposed protocol enhancement (e.g., XML-RPC, SOAP, DotGNU).
+         Compare Jabber to "the competition" (other IM systems or other messaging protocols) and point out holes in the Jabber protocol that need to be filled in order to offer similar functionality.
+         Review the relevant history of thinking within the Jabber community.
+       
+       JRPS is a layer on Jabber Publish-Subscribe (JEP0024, JEP0036) and should interoperate with them and support namespaces and topics. Included in this document is the capability for permission tokens. It is included as the author believes that such tokens should exist within the <publish> tag, being a means to identify data much as the namespace or topic does.
+       JRPS is different from other IM systems in that the publisher and pubsub components send out the data so that downstream entities can detect if problems occur. As a comparison, a sender in, say, MSN is told that the packet they sent cannot be delivered but in JRPS, the receiver knows that a packet or packets have not been delivered and can ask for retransmissions.  The sender need not normally know about such events as the intermediate components can usually cater for it. Thus JRPS has a future in areas such as Multicasting, large distributed and proxy-based environments where the end subscribers may be very remote from the publisher.
+       Existing commercial middlewares provide such facilities and it is especially necessary when data is pushed between applications and may not have an obvious "context" in the stream to data immediately before or after. Thus, JRPS may seem over-the-top for a chatroom world, but is a basic requirement for, say, distributing real-time process states, events or persistent, mutable data.
+     
+   
+   
+      This can be achieved by the use of packet sequence numbering and heartbeats whilst avoiding the necessity to positively ACK each packet.
+      
+         Multiple levels of sequence numbers are envisaged and will be used in different circumstances. Multiple levels allow a rapid repair of short "transient" breaks whilst catering for longer breaks, recoveries and resynchronisations without placing too great a burden on either subscriber or pubsub component. This discussion explains the use of a dual sequence number environment: link and source.
+         Sequence numbers will be sent in each publish thus:
+         
+<iq type="set" 
+    to="myclient@server.net"
+    from="pubsub.localhost">
+  <query xmlns="jabber:iq:pubsub">
+    <publish ns="data topics"
+        linkseq="57372"
+        sourceseq="7547392"
+        from="publisher.fromaplace">
+    </publish>
+    <publish ns="data topics"
+        linkseq="57373"
+        sourceseq="44211"
+        from="publisher.elsewhere">
+    </publish>
+  </query>
+</iq>
+
+         The above shows sequence numbers placed in the <publish/> node or element. This is to abstract the publishing from any packet construction algorithms that may occur and thus allow a recovery to make use of network capacity as it sees fit and to interleave recovery and ongoing publishing data.
+         The subscriber stub is responsible for ordering information and detecting and repairing any gaps to provide sequential data for consumption by the application, which should not concern itself with such issues.
+         The operation of LINK and SOURCE sequence numbers are described below.
+      
+      
+         This will concern itself with data sent on each channel. A 
+channel can be, but is not limited to the following:
+         
+           Socket connection between Subscriber (and/or resource within same) and the Jabber pubsub component.
+           Multicast datastream sent from a pubsub component but shared amongst 0..n subscribers.
+         
+         Each publish received should contain an incremental sequence number to the previous or Zero. Zero is used to reset (or resynchronise) the sequence numbering. Zero should not be used in the situation of sequence number wrapping/rollover, wherein the value1 should be used. Sequence numbering bit resolution should be ascertained by querying the pubsub component in an <iq/> before subscription requests are levied.
+         E.g., in a 16-bit sequence number resolution channel, the sequence numbers would run as follows
+         1, 2, 3, 65533, 65534, 65535, 1, 2,
+         For information on sequence number bit resolution, see section 4, Source Queries.
+      
+      
+         This will indicate the sequence number of messages sent from the publisher to the pubsub component. Should a link be lost, timeout or other such eventuality where the context of link sequence number be lost (e.g. the pubsub component decides the subscriber has disappeared and discards context), the pubsub component is still in a position to re-filter and retransmit data cached locally or even refer back to its source to maintain integrity and temporal ordering of data to the subscriber.
+         To repair larger gaps, the pubsub component may provide the capability to request upwards to the source using the source sequence number, or the pubsub component may draw upon local or remote journaling services to repair the gap. The source sequence number seen by the subscriber may be the link level sequence number between publisher and pubsub component, may be the ultimate publisher sequence number or even an internal sequence number given to the incoming published data to the pubsub component on a per source basis.
+         The subscriber need not know how the source sequencing operates, only notify from when the link last gave a contiguous datastream.
+         One can now see that the pubsub component's conversation to the source is akin to that of a subscriber to a pubsub component.
+      
+      
+         When a subscriber detects a gap on its link, it can request for the data to be resent thus:
+         
+<iq 
+    type="get" 
+    id="plugthegap1"
+    from="myclient@server.net"
+    to="pubsub.localhost">
+  <query xmlns="jabber:iq:pubsub">
+    <gap linkfrom="56737" linkto="56739">
+  </query>
+</iq>
+
+         The values represent the missed link sequence numbers. For a gap of 1, the linkfrom and linkto are the same.
+         Should the pubsub have lost the link context and thus is unable to plug the gaps it will return an error <iq/> packet.
+         All is not lost. The subscriber has a last-ditch repair scenario by sending last-received source sequence numbers. 
+         
+<iq 
+    type="get" 
+    id="plugthegap1"
+    from="myclient@server.net"
+    to="pubsub.localhost">
+  <query xmlns="jabber:iq:pubsub">
+    <gap ns="publisher.fromaplace" after="56737">
+    <gap ns="publisher.elsewhere" after="211234">
+  </query>
+</iq>
+
+         Due to the non-contiguous nature of source sequence numbers from the subscriber point of view, the values sent must represent not the gap, but the last valid sequence number received. Each source may have a separate sequence number stream. This allows the pubsub component to manage and, if necessary, request gaps itself from the publisher to resynchronise the subscriber. The pubsub or publishing source should have the ability to refuse a rebuild/resynchronise.
+         It should be possible for the subscriber to send the link and source sequence numbers in the initial request. However, if link information has been discarded by the pubsub component (e.g. the connection was dropped and presence set offline) the link sequence numbers will be reset to zero (re-synchronised) thus:
+         
+<iq 
+    type="set"
+    to="myclient@server.net"
+    from="pubsub.localhost">
+<query xmlns="jabber:iq:pubsub">
+    <publish 
+        ns="data topics"
+        linkseq="0"
+        sourceseq="7547392"
+        from="publisher.fromaplace">
+    </publish>
+    <publish 
+        ns="data topics"
+        linkseq="1"
+        sourceseq="44211"
+        from="publisher.elsewhere">
+    </publish>
+  </query>
+</iq>
+
+      
+      
+         During times of low traffic, an active circuit can be provided with regular heartbeat transmissions. Heartbeats will increment the link level sequence numbers. Subscribers missing or detecting overdue heartbeats will thus be able to detect gaps or delays even in low traffic scenarios. If the data is simply delayed, the subscriber stub is in a position to take action (and/or alert the application/user). If data is lost or heartbeats do not arrive in time, the subscriber can decide to request retransmission, disconnect or wait.
+         
+<iq 
+    type="set"
+    to="myclient@server.net"
+    from="pubsub.localhost">
+  <query xmlns="jabber:iq:pubsub">
+    <publish 
+        ns="link.heartbeat"
+        linkseq="57374"
+        from="pubsub.localhost">
+    </publish>
+  </query>
+</iq>
+
+         No source sequence numbering exists here, as it is purely a link-level entity.
+      
+   
+   
+      To be able to interpret published data in a more logical manner, more meaning needs to be given to data received.
+      When a publish packet arrives with a topic or data namespace, there is currently no way of knowing how to interpret the tags therein. Do they replace existing tag values seen? Should previously sent tags that are not  in the publish be kept or discarded? Are tag values being updated or was the previous value incorrect?
+      To resolve this a type field may be added to the <publish/> tag.
+      
+<iq 
+    type="set"
+    to="myclient@server.net"
+    from="pubsub.localhost">
+<query xmlns="jabber:iq:pubsub">
+    <publish 
+        ns="data topics"
+        linkseq="57372"
+        sourceseq="7547392"
+        from="publisher.fromaplace"
+        type="update">
+    </publish>
+    <publish 
+        ns="data topics"
+        linkseq="57373"
+        sourceseq="44211"
+        from="publisher.elsewhere"
+        type="correction">
+    </publish>
+</query>
+</iq>
+
+      This option is preferable to extending the <iq/> type field as there will then be no need to split <iq/> packets if <publish/> elements have different types.
+      
+         The following extensions would be used in environments where topic/namespaces define discrete sets of data items and/or data items changing over time, as opposed to only referring to a topic datastream consisting of atomic, unrelated data. Other types can be defined as the need arises.
+         'update' - partial update of data. Replaces the values of the fields of the topic/namespace it contains. Other fields held/cached downstream for this data item are still valid.
+         'correction' - previous data for contained fields was incorrect - e.g. paragraph in a news story, but, as per update, unsent items are still valid.
+         'image' - payload contains ALL the data for a data item/topic/namespace. All existing values should be dropped and replaced with the new data. Previously received fields not now contained within the image should be discarded. 
+         'drop' - namespace/topic item is now dead and all data in it should be deleted and purged from cache.
+         'snapshot' - requested by subscriber and is a request for data (an image if empty of granular topics/namespaces) and no further updates, as distinct from a get, which is an on-going subscription in pubsub world.
+         'add' - new topic/data item on publisher's feed. Note that an "image" publish for an item can be interpreted in the same way. Previous systems have had the ADD mechanism, but use of "add" has been discontinued, with the role taken up by the "image". (thoughts?)
+         The above states (except "add") are very important for downstream caches and for applications that apply business logic to the datastreams.
+      
+   
+   
+      As touched on above, subscribers should be able to enquire of the publisher regarding what capabilities it provides and what to expect. Some items of use for JRPS are as follows:
+      
+        Heartbeat. Integer milliseconds. Represents the interval between heartbeat messages. Useful for rapid detection of link level problems.
+        Link Sequence Resolution. Integer. Allows subscriber to predict link sequence number rollover. Zero would indicate that it is not supported.
+        Source Sequence Resolution. Integer. Allows a subscriber to predict source sequence number rollover. A zero would indicate that it is not supported.
+        Gap Support. Boolean. Used to indicate if the publisher supports gap filling.
+        Permissioning Scheme. There may be some standardisation of permissioning schemes so that common plugins or mechanisms can be adopted. The publisher should be able to define this.
+        Rebuild On Demand. If the pubsub can support a rebuild/refresh of the current values of all subscribed-to data on demand.
+        Refresh Cycle. It has been common practice to transmit a regular refresh cycle for all subscribed data. If a data item does not get an 'image' from the source for a period of time, the cache performs a logical 'drop'. Without this, intermediate caches would very soon balloon with stale data, or publishers would get every cache re-requesting or confirming if data is still alive. Zero would indicate that no refresh cycle exists for the source.
+
+   
+   
+      
+         Permissioning protocols should be open to permit a multitude of permissioning schemas. Data providers may wish to enforce their schemes in ways that suit their particular business models. The protocol should not bind or dictate such mechanisms.
+         The implementation of permissioning systems and regimes over time has repeatedly shown that it is especially dangerous to assume the behaviour of data and to disregard how information is used, protected, valued and owned or to force a scheme that is rigid and assumes a narrow problem domain. Thus the scheme should permit explicit and tokenised permissioning mechanisms.
+         Tokenised permissioning allows sets of data can be treated en masse. By permitting the concept of "grant" and "deny" permissions simultaneously (settings that define who CAN see something or defining who CANNOT) individual publishers can manage access both broadly and down to very fine granularity.
+         Permission tokens, if used, should be sent in-band with the data. This will allow data to change its coding online and thus immediately affect permissioning without a redistribution of the permissioning information.
+         
+<iq 
+    type="set"
+    to="myclient@server.net"
+    from="pubsub.localhost">
+  <query xmlns="jabber:iq:pubsub">
+    <publish 
+        ns="data topics"
+        type="update"
+        permtoken="6747"
+        linkseq="57372"
+        sourceseq="7547392"
+        from="publisher.fromaplace">
+    </publish>
+  </query>
+</iq>
+
+         This does not prevent namespace/topic permissioning systems from being applied, nor should the permtoken be compulsory1.
+         The pubsub systems should be able to <iq/> the publisher for the permissioning regime that applies.
+         The definition of the XML carrying permissioning tables/information should be regime specific.
+         Further information on why tokenised grant and deny permissioning is advantageous can be provided upon request.
+      
+         Contributions in this context are when a subscriber publishes to one or more sources for redistribution so that it may reach the communities that subscribe to that source. By doing this, the subscriber reaches large communities, focus on specific communities and can abstract itself from delivery issues.  The publisher gains information and broadens its appeal. Delivery abstraction is valuable, as a subscriber can then connect once to the publisher to gain access to all systems, networks, technologies, subscribers and media that the publisher and contributor agree upon. As you may guess, there is a need for content, flow control/throttling and ongoing permissioning to be specified and handled over time.
+         Contributions requires a separate JEP, but the issues are important to the implementation of pubsub and of its permissions (Contributors have specific, complex and business-critical reasons to tightly control who sees data -- e.g. only customers, not competition!)
+       
+   
+
diff --git a/xep-0041.xml b/xep-0041.xml
new file mode 100644
index 00000000..4aa78fca
--- /dev/null
+++ b/xep-0041.xml
@@ -0,0 +1,266 @@
+
+
+%ents;
+]>
+
+
+
+  Reliable Entity Link
+  Protocol for linking a bytestream between two Jabber entities.
+  &LEGALNOTICE;
+  0041
+  Retracted
+  Standards Track
+  Standards JIG
+  XMPP Core, JEP-0020, JEP-0030
+  None
+  JEP-0065
+  rel
+  
+    Justin
+    Karneges
+    justin@affinix.com
+    justin@andbit.net
+  
+  
+    0.2
+    2003-09-30
+    psa
+    At the request of the author, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0065. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.8
+    2003-06-26
+    jk
+    Refactored to old jidlink roots
+  
+  
+    0.7
+    2003-04-29
+    jk
+    Overhaul and rename
+  
+  
+    0.6
+    2002-11-23
+    jk
+    Reflect changes to DTCP
+  
+  
+    0.5
+    2002-10-10
+    jk
+    Table of stream transports
+  
+  
+    0.4
+    2002-10-10
+    jk
+    New name, cleaned up the text, added test mode.
+  
+  
+    0.3
+    2002-09-12
+    jk
+    Changed the implementation.
+  
+  
+    0.2
+    2002-08-16
+    jk
+    Fixed spelling errors, simplified the document.
+  
+  
+    0.1
+    2002-08-15
+    jk
+    Initial version.
+  
+
+
+
+Reliable Entity Link (or simply 'REL'), is a system for coordinating reliable bytestreams between two Jabber entities for the purpose of keeping applications (and application specifications) simple.  However, this proposal does not define any specific bytestream protocol.  It is expected that there will be multiple ways to obtain a bytestream between Jabber entities (thru-server and peer-to-peer are two methods that come to mind), but applications can refer to REL instead of some particular stream transport.
+
+
+
+A REL-compatible stream transport must have the following properties:
+
+  Provides a reliable bytestream between two Jabber entities, which means that the bytestream transport handles all data delivery issues, such that the application need not worry about them.
+  Has a the following link states:
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    Code Description
INIT Initiation
GOOD Successful initiation (connected)
BAD Unsuccessful initiation (stream is closed, no further state)
CLOS Successful closure after establishment (stream is closed, no further state)
ERR Link failure after establishment (stream is closed, no further state)
+  
+  Defines a stream identifier, which MUST have a unique ASCII representation. The stream protocol MUST be able to use any ASCII identifier chosen during REL negotiation, as long as the sending party doesn't use the same identifier more than once.
+
+The following stream transports that meet these guidelines are:
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+Short name Protocol
ibb &jep0047;
s5b &jep0065;
+
+
+
+
+
+
+Before using REL, ensure it is a supported service of the remote entity by using &jep0030;:
+
+
+  
+
+]]>
+
+The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this JEP.
+
+
+  
+    
+  
+
+]]>
+
+
+
+
+To use REL, the entities must obtain a REL Context ID (or cid) through some action.  A cid is simply an opaque alphanumeric string.  For example, perhaps the link is needed for a file transfer:
+
+
+  
+
+]]>
+
+
+  
+    
+  
+
+]]>
+
+All high-level protocols that use Reliable Entity Link MUST have a way of providing such a cid.  The cid must be unique among all other REL cids between the two entities.
+
+
+
+The next step is to ask the remote entity which stream method it would like to use.  We will use &jep0020; for this.  The streams are listed using the short names from the table of supported streams.
+
+
+  
+    
+      
+        
+          
+          
+        
+      
+    
+  
+
+]]>
+
+The keepAlive attribute indicates that the initiator is planning on trying another method if the one selected here is to fail.  An entity SHOULD use keepAlive for all attempts but the last for a given application.  If keepAlive is omitted, then it is considered false.
+
+The remote entity will then agree on a method:
+
+  
+    
+      
+        
+          s5b
+        
+      
+    
+  
+
+]]>
+
+Or maybe an error:
+
+  No supported protocols.
+
+]]>
+
+If the entity returns error, then the REL cid is invalidated and the application fails.  If a stream method has been chosen successfully, then now it must be initiated using the REL cid as the stream's identifier (the stream goes into INIT state).
+
+On GOOD: This indicates the stream is ready for use within the original context, and data exchanged over the stream is to be left up to the application.
+
+On BAD: If the keepAlive="true" attribute was specified, then the initiator MUST repeat this section over again to attempt with a different method.  If keepAlive was not specified, then the REL cid is invalidated and the application fails.
+
+On CLOS or ERR, the REL cid is invalidated.
+
+
+
+
+  There are no security considerations.
+
+
+
+  This JEP requires no interaction with &IANA;.
+
+
+
+  The ®ISTRAR; shall register the 'http://jabber.org/protocol/rel' namespace as a result of this JEP.
+
+
+
+  
+
+
+
+   
+     
+      
+      
+     
+   
+
+
+  ]]>
+
+
+
diff --git a/xep-0042.xml b/xep-0042.xml
new file mode 100644
index 00000000..3cdb02ce
--- /dev/null
+++ b/xep-0042.xml
@@ -0,0 +1,1075 @@
+
+
+%ents;
+]>
+
+
+
+  Jabber OOB Broadcast Service (JOBS)
+  A protocol for enabling uni-directional multicast data transfers out of band. 
+  &LEGALNOTICE;
+  0042
+  Retracted
+  Standards Track
+  Standards
+  JEP-0004 (OPTIONAL), JEP-0011 (RECOMMENDED) JEP-0029 (REQUIRED)
+  None
+  JEP-0065
+  JOBS
+  
+    Matthew
+    Miller
+    linuxwolf@outer-planes.net
+    linuxwolf@outer-planes.net
+  
+  
+    0.5
+    2003-04-11
+    psa
+    At the request of the JEP author, changed status to Retracted. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+  
+  
+    0.4
+    2002-10-22
+    lw
+    More restrictive on usage of "action" attributes; Reduced session information returned in most use-cases; Added action for retrieving session information; Added action for service ("proxy") invites
+  
+  
+    0.3
+    2002-10-20
+    lw
+    Complete overhaul (redesign to allow for peer-to-peer operation; reduced element-set; removed "session types"; reorganized into use-cases)
+  
+  
+    0.2
+    2002-08-20
+    lw
+    Added "detailed" description of OOB headers
+  
+  
+    0.1
+    2002-08-14
+    lw
+    Initial Release
+  
+
+
+  
+    Distributing data out-of-band (OOB) to one or more end-points is a requirement for many Jabber clients. The Jabber OOB Broadcast Service (JOBS) is a mechanism to allow end-points to open uni-directional data streams between each other, on top of which any number of applications can be built Possible applications include file transfer, audio/video streaming, and some gaming implementations..
+
+    The aim of this JEP is to define a process of connecting a sender to one or more receivers through a secondary TCP port.
+  
+  
+    As the name implies, JOBS is designed to enable multicast, uni-directional OOB connections. These connections are usually between a "sender" client, a JOBS "service", and one or more "receiver" clients. Each such set of connections is collectively called a session. JOBS is designed to allow a single service to handle multiple sessions over a single host/port combination.
+
+    To address a large number of typical uses efficiently, JOBS can multicast the data from a sender to multiple receivers. In order to keep the protcol as simple as possible, it only allows data to flow in one direction.
+
+    JOBS utilizes a "two-band" authentication mechanism. This allows the end-points to know practically nothing about each other, yet still be assured that the OOB connection is really to/from the Jabber entity its intended to be. The authentication system is then backed-up with explicit authorization requests.
+
+    For the OOB portion, clients connect to the host/address and port of the JOBS service for a given session. Once connected, a client-initiated handshake process occurs, and (if successful), then data is routed from the sender's connection to each receiver's connection. The only point at which any error information may be conveyed over the OOB connection is during the handshake process.
+    
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    Term Description
OOB Out-Of-Band. Any network connection that exists outside of the normal Jabber protocol traffic.
session A session registered with a "server" for clients to connect to.
client An end-point on a JOBS session.
service The JOBS Jabber component/server.
server A particular host/port of the JOBS service.
sender The client sending data.
receiver A client receiving data.
+  
+
+
+  
+    Discovering support for JOBS involves either "jabber:iq:browse"jabber:iq:browse -- http://www.jabber.org/jeps/jep-0011.html or "disco"http://jabber.org/protocol/disco -- http://www.jabber.org/jeps/jep-0030.html. This determines if the end-point understands the JOBS protocol.
+    
+      To determine support for JOBS via jabber:iq:browse, look for an item with a nested <ns/> with a value of "http://jabber.org/protocol/jobs":
+      
+  
+
+      ]]>
+      
+  ...
+  
+    http://jabber.org/protocol/jobs
+  
+  ...
+
+      ]]>
+    
+  
+  
+    The JOBS protocol supports various scenarios to create sessions. Most of these scenarios allow an entity to determine the possible parameters to create a session with. To actually create a session, the (would-be) sender sends an "iq-set" with a <session action="create"/>. This returns the details of the newly created session, including the ID and OOB host/port.
+    
+    This use-case can be completely ignored for true "peer-to-peer" systems.
+    
+    
+      The simplest create request is:
+    
+      
+  
+
+      ]]>
+      
+  
+
+      ]]>
+    
+      This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The <session/> element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID The exact value of the ID is left to JOBS implementations..
+    
+    
+      When creating a session, parameters to <session/> can be supplied, explicitly requesting that certain parameters be met (such as buffer size, time to expire, and receiver limit). Since these parameters have lower- and upper-bounds specific to the JOBS service, a sender may need to determine these limits.
+      
+      To determine the limits, the sender sends an "iq-get" with a <session action="create"/>:
+      
+      
+  
+
+      ]]>
+      
+  
+    
+    
+    
+    
+  
+
+      ]]>
+
+      The returned <session/> is also prefilled with default values for all known parameters.
+      
+      To create a session with specific parameters, the sender sends an "iq-set" as in the "simple" use-case, but then specifying the parameter values desired:
+      
+  
+
+      ]]>
+      
+  
+
+      ]]>
+    
+      The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.
+      
+      Any parameters that exceed the minimums/maximums causes an error.
+    
+    
+      In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a "jabber:x:data" formjabber:x:data -- http://www.jabber.org/jeps/jep-0004.html can be embedded in the <session/>.
+      
+      To create a session using forms, send a <session action="create"/> with an embedded <x xmlns="jabber:x:data"/>:
+      
+      
+  
+    
+  
+
+      ]]>
+      
+  
+    
+      Please specify values for the given fields.
+      
+        
+      
+      0
+      30
+      1
+    
+  
+
+      ]]>
+      
+      The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the <session/> attributes.
+      Using the form-based approach, the session is then created by sending a <session action='create'/> with a form submission (as defined for "jabber:x:data"):
+      
+      
+  
+    
+      jobs.domain:12676
+      0
+      300
+      1
+    
+  
+
+      ]]>
+      
+  
+
+      ]]>
+    
+  
+  
+    Once the session is created, the sender invites receivers to connect. The sender can invite receivers either directly, or via the JOBS service. Most invitations are distributed via <message/>.
+    
+    
+      The sender can invite receivers directly. This is done using a <message/>:
+      
+  Let's connect!
+  
+
+      ]]>
+      
+      When inviting directly, the <session/> MUST contain enough information for a receiver to connect OOB. The required information is:
+      
+        host
+        id
+        port
+      
+    
+    
+      Alternatively, a sender can invite receivers via the JOBS service. This is also done using a <message/>, with a <session action="notify"/> containing one or more <item action="invite" type="connection"/>:
+      
+  Let's connect!
+  
+    receiver@domain
+
+      ]]>
+      This results in the JOBS service sending the <message/> to each <item/>. Any additional elements (such as a <body/>) are passed onto those invited:
+      
+  Let's connect!
+  
+    
+
+      ]]>
+    
+  
+  
+    At any time, a client can request information about sessions for a JOBS service. The request can be directed for "all" sessions, or a specific sessionWho is allowed to perform this action is left up to the JOBS service implementation..
+
+    
+      A client can request all the sessions for a JOBS service by sending an "iq-get" containing a <session action="info"/> with no ID:
+      
+  
+
+      ]]>
+      The JOBS service responds with all the sessions within the "iq-result". This is the only case where a result can have more than one <session/>.
+      
+  
+    sender@domain/res
+  
+  
+
+      ]]>
+    
+    
+      Alternatively, a client can request the information for a specific session by sending an "iq-get" containing a <session action="info"/> with the ID:
+      
+  
+
+      ]]>
+      The service responds with an "iq-result" of just the requested session.
+      
+  
+    sender@domain/res
+  
+
+      ]]>
+    
+  
+  
+    
+      When a client connects (sender or receivers), a client-initiated handshake takes place. The purpose of this handshake is to authenticate the OOB connection, in relation to the client's JID. This authentication utilizes both in-band and OOB packets.
+    
+      To start the handshake, the client sends an "init" packet on its established connection:
+      
+      
+      
+      If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:
+      
+      
+      
+      Once received, the client then sends an "iq-set" containing a <session action="authenticate"/>, which itself contains an <item type='auth' action='confirm'/> with this confirm key:
+      
+      
+    
+      SID00001234
+    
+  hehe
+      ]]>
+    
+      The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a <session action="authenticate"/> containing a <item type="auth" action="accept"/> with the accept key:
+    
+      
+    
+      SID88884321
+    
+  
+    ]]>
+    
+      At this point, the client responds on the OOB data stream with an "auth-response" packet:
+    
+      
+    
+      If the connection is accepted, the JOBS service sends a "connected" packet:
+    
+      
+      and after this, the data transfer occurs. If this connection is the sender, they may start sending data now (regardless if receivers are connected). If this connection is a receiver, the sender's data immediately follows the terminating "newline".
+    
+    
+      Authenticating ensures the OOB connection matches a particular JID. Authorizing ensures to the service that receiver is allowed to be connected to the session. To determine if the session connection should be accepted or rejected, the JOBS service first checks if the JID matches the sender. This matches against the "full" JID, including node, domain, and resource. If this connection is the sender, it is allowed. Otherwise, the service confirms the connection with the sender.
+      
+      If a confirmation is required, the service sends an "iq-get" to the sender, with a <session action="authorize"/> containing an <item type"connection" action="confirm"/> with the full JID of the receiver:
+      
+      
+  
+    receiver@domain/res
+  
+
+      ]]>
+
+      One or more <item type="connection" action="confirm/> elements, each specifying a JID to accept/reject. To accept (or reject) a connection, the sender responds with an "iq-result", wrapping each JID in either an <item type="connection" action="accept"/> or <item type="connection" action="reject"/>.
+
+      
+  
+    receiver@domain/res
+  
+
+      ]]>
+      
+  
+    receiver@domain/res
+  
+
+      ]]>
+      
+      If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.
+    
+    
+      The sender may drop a connection at any time. To drop a connection, the sender sends an "iq-set" with the <session/> containing the "connection" to drop:
+      
+      
+  
+    receiver@domain/res
+  
+
+      ]]>
+      
+      If the connection is successfully dropped, the service returns an "iq-result":
+      
+      
+  
+
+      ]]>
+      
+      The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).
+    
+  
+  
+    Sessions are deleted either by timeout or explicitly. Sessions are deleted by timeout automatically under certain conditions. Sessions can also be deleted explicity by their senders, at any time. Regardless of the method of deletion, a notice is sent to all connected.
+    
+    This use-case can be completely ignored for true "peer-to-peer" systems.
+    
+      The exact conditions that expire a session are mostly up to the implementation. At a minimum, a session SHOULD be expired when there are less than two connections, and the "expires" time is reached.
+    
+    
+      To explictly delete a session, the sender sends an "iq-set" containing a <session action="delete"/>:
+  
+      
+  
+
+      ]]>
+      
+  
+
+      ]]>
+    
+  
+  
+    
+      When a connection is accepted, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a <item type='connection' action='accept'/>:
+      
+      
+  
+    
+  
+
+      ]]>
+      
+      If the notification is not about the recipient of the message, then the <item/> contains the JID this notification pertains to.
+    
+    
+      When a connection is rejected, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a <item type='connection' action='reject'/>:
+      
+      
+  
+    
+  
+
+      ]]>
+      
+      If the notification is not about the recipient of the message, then the <item/> contains the JID this notification pertains to.
+    
+    
+      When a connection is dropped, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a <item type='connection' action='drop'/>:
+      
+      
+  
+    
+  
+
+      ]]>
+      
+      If the notification is not about the recipient of the message, then the <item/> contains the JID this notification pertains to.
+    
+    
+      When a session is deleted, any clients connected to the session are immediately disconnected. The "notify" message is sent to the sender and any receivers still connected, with the <session action="notify"/> containing an <item type="status"/>:
+      
+      
+  
+    
+  
+
+      ]]>
+
+      
+  
+    
+  
+
+      ]]>
+      
+      The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.
+    
+  
+
+
+  
+    
+      
+
+
+
+
+
+
+
+
+
+
+      ]]>
+    
+    
+      The <session/> element is the core element to the protocol. This element provides both information about a session and the action applied to it. It has a large number of attributes, and contains zero or more <item/> elements, zero or more <connect/> elements, and zero or three <limit/> elements. It may also contain elements governed by other namespaces.
+      The "action" attribute specifies the action to apply or being applied to the session. From clients, this attribute MUST be specified. From the service this attribute MAY be specified (to prevent ambiguity). The value of "action" MUST be one of the following:
+      
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+      Value Description
authenticate Authenticating one or more connections.
authorize Authorizing one or more connections.
create Create a new session.
delete Delete an existing session.
notify Notification about the session.
+      The "status" attribute specifies the current status of the session. This attribute MUST NOT be present if the session does not have an identifier (i.e. does not yet exist). Only the service can provide this attribute. The value of "status" MUST be one of the following:
+      
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+      Value Description
active The session is active, but not yet in use.
closed The session has closed.
in-use The session is in use (e.g. data is being transferred).
pending The session is ready, but not yet active (e.g. not enough connections).
+      The "host" attribute specifies the OOB hostname for the session. This attribute SHOULD be specified when possible. The value of this attribute can either be the "raw" dotted-decimal address or a fully-qualified domain name.
+      The "id" attribute identifies the session. This attribute is required for all uses of <session/> except the request to create a session. This value is any string that the service and clients can use to uniquely identify it.
+      The "port" attribute specifies the OOB port number for the session. This attribute SHOULD be specified when possible.
+      The "sender" attribute specifies the JID of the sender. This attribute SHOULD be specified when possible. The value of this attribute MUST be the full JID of the sender, including node and resource (if possible).
+      The "buffer" attribute specifies the size of a temporary transfer buffer. This attribute MAY be present at any time, and SHOULD be presented by the service wherever possible. The value of this attribute MUST be a non-negative number. A value of 0 means there is no buffer. This value has limits defined by the "jobs:buffer" parameter statistic.
+      The "expires" attribute specifies the number of seconds before this session times out. This attribute MAY be present at any time, and SHOULD be presented by the service wherever possible. The value of this attribute MUST be either a positive number or -1. A value of -1 means this session does not expire. This value has limits defined by the "jobs:expires" parameter statistic.
+      The "receivers" attribute specifies the maximum number of receivers this session can have. this attribute MAY be present at any time, and SHOULD be presented by the service wherever possible. The value of this attribute MUST be either a positive number of -1. A value of -1 means this session can (theoretically) have any number of receivers. This value has limits defined by the "jobs:receivers" parameter statistic.
+    
+    
+      The <item/> element is used for detailed information about specific items of a session. It is used to contain authentication keys, to define connections, and provide more detailed status for a session. It has attributes for the type of item and the action associated with this item. This element contains only character data.
+      The "action" attribute specifies the action to apply or being applied to this item. From clients, this attribute SHOULD be specified. From the service, this attribute MUST be specified (to prevent ambiguity). The value of "action" MUST be one of the following:
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Value Description Notes
accept The item is accepted. This value MUST only be used when the type is "auth" or "connection".
confirm The item needs confirmation. This value MUST only be used when the type is "auth" or "connection".
delete The item is deleted. This value MUST only be used when the type is "status".
drop The item is dropped. This value MUST only be used when the type is "connection".
expire The item has expired. This value MUST only be used when the type is "status".
invite The item is invited to the session. This value MUST only be used when the type is "connection".
reject The item is rejected. This value MUST only be used when the type is "auth" or "connection".
+      The "type" attribute specifies the type of item. This attribute MUST be present. The value of "type" MUST be one of the following:
+      
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+      Value Description
auth The item pertains to authentication keys.
connection The item details a session connection. The CDATA is the JID that is connected.
status The item details a session status event.
+    
+    
+      The <connect/> element specifies a valid host/port combination for a session. An instance of this element MUST be present for each host/port combination possible. This element SHOULD only be present when information on creating sessions is requested. It has attributes to define the OOB hostname and port number. This element is empty.
+      The "host" attribute specifies the OOB hostname. This attribute MUST be present. The value is either the "raw" dotted-decimal IP address, or the fully-qualified domain name.
+      The "port" attribute specifies the OOB port number. This attribute MUST be present. The value MUST be a positive integer in the range (0 < port <= 1024).
+    
+    
+      The <limit/> element specifies a valid host/port combination for a session. An instance of this element MUST be present for each "type". This element SHOULD only be present when information on creating sessions is requested. It has attributes to define the type of limit, the default value, the minimum value, and the maximum value. This element is empty.
+      The "type" attribute specifies the type of limit. This attribute MUST be present. Each type corresponds to an attribute of <session/>. The value of "type" MUST be one of the following:
+      
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+      Value Description
buffer The buffer size limits. The units for "default", "max", and "min" are bytes.
expires The expires time limits. The units for "default", "max", and "min" are seconds.
receivers The receiver count limits. The units for "default", "max", and "min" are number of connections.
+      The "default" attribute specifies the default value for this limit. This attribute MUST be present. The value of "default" MUST be a number.
+      The "max" attribute specifies the maximum value for this limit. This attribute MUST be present. The value of "max" MUST be a number. A value of -1 means there is no maximum value.
+      The "min" attribute specifies the minimum value for this limit. This attribute MUST be present. The value of "min" MUST be a number. A value of -1 means there is no minimum value.
+    
+    
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Code Message Cause
400 Bad Request The JOBS service did not understand the request.
403 Forbidden The JOBS service cannot accept the authentication request from the requesting JID.
404 Not Found The JOBS service could not find the given session.
406 Not Acceptable The authentication is not valid.
+
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Code Message Cause
400 Bad Request The JOBS service did not understand the request.
403 Forbidden The JOBS service cannot accept the authorization request from the requesting JID.
404 Not Found The JOBS service could not find the given session.
406 Not Acceptable The authorization is not valid.
+
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Code Message Cause
400 Bad Request The JOBS service did not understand the request.
403 Forbidden The JOBS service cannot accept any creation requests from this JID.
406 Server Not Acceptable The JOBS service cannot accept any creation requests using the requested <server/> parameters.
406 Restrictions Not Acceptable The JOBS service cannot accept any creation requests using the requested <accept/>, <confirm/>, and/or <reject/> parameters.
503 Service Unavailable The JOBS service cannot accept any additional sessions at this time. Future requests may be accepted.
+  
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Code Message Cause
400 Bad Request The JOBS service did not understand the request.
403 Forbidden The JOBS service cannot accept deletion requests from the requesting JID.
404 Not Found The JOBS service could not find a given session.
+
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Code Message Cause
400 Bad Request The JOBS service did not understand the request.
403 Forbidden The JOBS service denied the connection for any reason.
404 Not Found The JOBS service could not find a given connection and/or JID.
406 Not Acceptable The JOBS service denied the notify for some reason.
504 Remote Server Timeout The JOBS connection timed out.
+    
+  
+  
+    The OOB protocol consists of a series of hanshaking headers, then the normal data transfer process. The syntax of the hanshake packets is similar to HTTP and SIP, in that it includes a "version and method" line, followed by zero or more "headers". The end of a packet is marked by two adjacent carriage returns (i.e. a single "empty" line). The primary difference is with the first line ("version and method"), where the protocol name and version precede the method.
+    
+OCTET :=            
+CTL :=              
+UALPHA :=           
+LALPHA :=           
+DIGIT :=            
+SP :=               
+CR :=               
+LF :=               
+BINDATA :=          
+      ]]>
+    
+      
+        
+          
+          
+        
+        
+          
+          
+        
+      Comand-line (example) jobs/0.4 init
Expected header-fields 
+            "session-id" - The JOBS session ID
+            "client-jid" - The (full) client JID
+          
+      
+        
+          
+          
+        
+        
+          
+          
+        
+      Comand-line (example) jobs/0.4 auth-challenge
Expected header-fields 
+            confirm - A unique <item type="auth" action="confirm"/> token
+          
+      
+        
+          
+          
+        
+        
+          
+          
+        
+      Comand-line (example) jobs/0.4 auth-response
Expected header-fields 
+            accept - A unique <item type="auth" action="accept"/> token
+          
+      
+        
+          
+          
+        
+        
+          
+          
+        
+      Comand-line (example) jobs/0.4 connected
Expected header-fields NONE
+      
+        
+          
+          
+        
+        
+          
+          
+        
+      Comand-line (example) jobs/0.4 error
Expected header-fields 
+            error-code - The HTTP-like error code
+            error-msg - Detailed error message
+          
+    
+    
+    
+  
+
+
diff --git a/xep-0043.xml b/xep-0043.xml
new file mode 100644
index 00000000..9491d6e6
--- /dev/null
+++ b/xep-0043.xml
@@ -0,0 +1,793 @@
+
+
+%ents;
+]>
+
+
+  
+    Jabber Database Access
+    Expose RDBM systems directly to the jabber network
+    &LEGALNOTICE;
+    0043
+    Retracted
+    Standards Track
+    Standards
+    
+      Justin
+      Kirby
+      justin@openaether.org
+      zion@openaether.org
+    
+    
+      0.2
+      2003-10-20
+      psa
+      At the request of the author, changed status to Retracted; interested parties should refer to <http://www.openaether.org/projects/jabber_database.html> for further information.
+    
+    
+      0.1
+      2002-08-21
+      jk
+      Initial public release
+    
+  
+  
+    Accessing a RDBMS in a generic fashion is a complex and difficult
+    task. Consequently, this will not be an attempt to XMLize a generic
+    Database API or query language. Instead, it will providing a
+    simple mechanism for a JID to read/write data that it has access to 
+    and specifying a model for those schemas to use in xml.
+  
+    This JEP has two aims.
+
+    
+      Be able to request the available schemas
+      Perform near SQL-like data manipulation
+    
+  
+    Although designed for use with an RDBMS this JEP is not
+    restricted to such uses. It may be used with any data storage 
+    system that can be broken down to a simple table, column/row 
+    format. for example comma delimited files.
+  
+  
+    To understand the following sections of this JEP the reader
+    must be aware of the following.
+
+    
+      The current namespace of http://openaether.org/projects/jabber_database.html 
+      will be used until this becomes a jep. Once officially accepted as
+      a jep and approved as final by the council, it will become 
+      http://www.jabber.org/jeps/jep-0043.html.
+    
+    
+      
+        version - specify the version of the protocol that the client/server supports
+        database - specify the database/catalog has the following attributes:
+        
+          name - name of the database/catalog
+          sql - embed native SQL queries directly
+        
+        
+          table - the element scopes the children into the table. has the following attributes:
+      
+        name - name of the table
+        permission - what the user can do with the data
+        col - describes the column. has the following attributes
+        
+          name - name of the column
+          type - SQL99 datatype of the column
+          size - size of the datatype if required
+          op - comparison operator, used only if child of where element
+        
+        where - scopes col elements into a 'sql-like' where clause
+        
+          col - see above
+        
+      
+      proc - element scopes the children into a procedure has the following attributes:
+      
+        name - name of the sproc
+        permission - what the user can do with the data
+        col - see above
+        result - indicated return value by running the procedure (restricted to integer)
+      
+        
+      
+    
+    
+      There are a limited subset of data types available:
+      
+        bit - a single 'bit', usually used to represent boolean values
+        tinyint - signed 8bit integer, has a range from   -128  to +127
+        integer - signed 32bit integer, has a range from -2147483648 to +2147483647
+        utinyint - unsigned 8bit integer, has a range from 0 to +255
+        uinteger - usigned 32bit integer, has a range from   0 to +4294967296
+        float - allowed values are -3.402823466E+38 to
+        -1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38 (can NOT be  unsigned)
+        numeric - unlimited size (some databases constrain this though)
+        date - resolution is one day. acceptable ranges vary (TODO: constrain minimal range to something)
+        datetime - a date and time combination (often has range dependencies)
+        timestamp - a datetime used most often to record events
+        time - a time in the format HH:MM:SS (TODO: specify valid range)
+        char - an unsigned byte representing a single character (ASCII)
+        vchar - a variable width char
+        text - an extremely large chunk of text
+        blob - an extremely large chunk of binary data (encode in MIME)
+      
+    
+    
+      All SQL/RDBMS units will be scoped in the xml hierarchy:
+
+      
+<database>
+  <table>
+    <col/>
+  </table>
+</database>
+      
+
+      All examples will assume the existence of the following rdbms setup. A 
+      database named 'testdb' with tables created with following SQL
+      script:
+  
+      
+        create table tbl_one 
+        ( 
+          a_int int, 
+          a_float float, 
+          a_char  char(10)  
+        )
+        create table tbl_two 
+        ( 
+          a_date datetime, 
+      a_numeric numeric(9,3) 
+        )
+      
+    
+      
+
+  
+      
+<iq id="001" to="db.host" type="get">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+</iq>
+      
+  
+      This is a simple request to discover what tables/procedures
+      exist on the database testdb. And what permissions are available 
+      to the user. All schema requests will respond within the scope that 
+      was asked for. This is to prevent unnecessary data from flooding
+      the network. So the response for the above request would look
+      something like:                                     
+  
+      
+<iq id="001" type="result" from="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one" permission="both"/>
+      <table  name="tbl_two" permission="read"/>
+  </database>
+</iq>
+      
+  
+      The response is scoped to only the 'children' of the request. 
+      Since the request was for the testdb database, only the tables 
+      within that database were returned in the result. The reason for 
+      the limitation is to prevent excessively large packets from filling 
+      the network from large schemas.
+   
+      The response indicates that the user has both read and write
+      permissions on the table 'tbl_one' and only read permissions on 
+      the table 'tbl_two'. Consequently, the user may only perform get 
+      requests on 'tbl_two'.
+   
+      
+<iq id="002" type="get" to="db.host"> 
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one"/>
+  </database>
+</iq>
+      
+   
+      The response would look like:
+
+      
+<iq id="002" type="result" from="db.host">             
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one"    permission="both"> 
+     <col name="a_int" type="int"/>
+      <col name="a_float" type="float"/>
+      <col name="a_char" type="char" size="10"/>
+    </table>
+  </database>
+</iq> 
+      
+   
+      The schema response for tbl_one is quite intuitive. Three
+      columns exist, one called a_int of type int (integer), another 
+      a_float of type float and  a third called a_char of type char 
+      with a size of ten characters.
+    
+
+    
+
+    
+  
+      Manipulation of data (select, insert, update, delete) will
+      definitely not be elegant or easy. SQL allows for some fairly 
+      complex queries on any fully  functional RDBMS. Consequently, 
+      the data manipulation will be  relatively limited since it is 
+      not a goal to translate SQL into xml.
+    
+      
+        To indicate a select like query, specify an <iq> of
+        type get. The table that the query is to be performed against 
+        must be specified. The columns   that are to be returned in 
+        the result set must be scoped within  the relative   table. 
+        Any attribute on the <col> element besides name will be 
+        ignored.  e.g. it is not required nor recommended to specify 
+        the data types  or the  sizes while performing a get.
+      
+        
+<iq id="003" type="get" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_int"/>
+      <col name="a_float"/>
+      <col name="a_char"/>
+    </table>
+  </database>
+</iq>
+
+      SQL Syntax:
+        select a_int, a_float, a_char
+        from tbl_one
+        
+      
+       It is also possible to specify a limit on the number of rows 
+       returned in the result set by specifying a value for the limit 
+       attribute.
+     
+       
+<iq id="003" type="get" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one"  limit="2">
+      <col name="a_int"/>
+      <col name="a_float"/>
+      <col name="a_char"/>
+      </table>
+  </database>
+</iq>
+       
+
+       In this case a limit of two rows will be returned in the result set.
+    
+        The result set which is returned will contain all the rows
+       that met the criteria of the select. There is no schema
+       information beyond the column names included in the result set. 
+       Each 'row' in the result set is scoped within the corresponding 
+       <table> element. This allows for queries on multiple
+       tables to be used in one <iq> packet.
+
+       
+<iq id="003" type="result" from="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_int">1234</col>
+      <col name="a_float">123.45</col>
+      <col name="a_char">onetwothre</col>
+    </table>
+    <table  name="tbl_one">
+      <col name="a_int">2345</col>
+      <col name="a_float">234.56</col>
+      <col name="a_char">twothreefo</col>
+    </table>
+  </database>
+</iq>
+       
+     
+
+     
+       It would be impractical to request the entire contents of the 
+       table every time you needed one row or a subset of the data. You 
+       can constrain the result set by specifying a where clause.
+
+       
+<iq id="004" type="get" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_int"/>
+      <col name="a_float"/>
+      <col name="a_char"/>
+      <where>
+        <col name="a_int" op="eq">1234</col>
+        <col name="a_float" op="lt" conj="and">200.00</col>
+      </where>
+    </table>
+  </database>
+</iq>
+
+         SQL Syntax:
+         select a_int, a_float, a_char from tbl_one
+         where   a_int = 1234 and a_float < 200.00
+       
+      
+       Attributes only used in the <col> element within a 
+       <where> element are the op (for operator) and conj for 
+       (conjunction). The op is used for comparison operators such 
+       as <, >, =, <>, <=, >=
+
+       

+     eq - equivalent =
+     neq - not-equivalent <>
+     lt - less than <
+     gt - greater than >
+     let - less than or equivalent <=
+     get - greater than or equivalent >=
+     null - IS NULL (the column is null in  the   database  sense of the word)
+       
+      
+
+      The conjuction attribute is used to combined constraints in the where clause
+
+      

+        not - to negate a result
+    or - logical OR ||
+    and - logical AND &&
+            
+      
+
+      Result
+
+      
+<iq id="003" type="result" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_int">1234</col>
+      <col name="a_float">123.45</col>
+      <col name="a_char">onetwothre</col>
+    </table>
+  </database>
+</iq>
+      
+    
+
+    
+      Inserting or altering the stored data in anyway requires
+      setting the type attribute to a value of set. This indicates 
+      that the user wants to perform a 'insert/update'. The
+      differentiating factor between an insert and an update operation 
+      is whether a <where> element is used. If there is no
+<where> element then it must be interpreted as an insert. 
+      If a <where> element does exist, then it must be
+      interpreted as an update.
+
+      
+<iq id="004" type="set" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_int">3456</col>
+      <col name="a_float">345.67</col>
+      <col name="a_char">threefour</col>
+    </table>
+    <table  name="tbl_two">
+      <col name="a_date">02/16/2002</col>
+      <col name="a_numeric">123456789123.123</col>
+    </table>
+  </database>
+</iq>
+
+SQL syntax:
+insert tbl_one (a_int, a_float,a_char)VALUES(3456,   345.67, 'threefour')
+insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
+      
+
+      Result
+
+       If there is no result set for the query, as in an update,
+      insert, delete, then the response must indicate success or 
+      failure within the <table> element scope. An empty
+<table> element indicates success, and a <table> 
+      element containing an <error> element indicates a failure.
+
+      
+<iq id="004" type="result" from="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one"/>
+    <table name="tbl_two">
+      <error code="380">permission denied on table</error>
+    </table>
+  </database>
+</iq>
+      
+      
+       The insert into tbl_one succeeded since the response has an 
+      empty <table> element. However, the insert into tbl_two 
+      failed with a permission denied error. Which is indicated with a 
+      non-empty <table> element.
+    
+
+    
+
+       As stated previously, if the type attribute has a value of
+      set and a <where> element exists, then it must be interpreted as an update.
+
+      
+<iq id="005" type="set" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table  name="tbl_one">
+      <col name="a_char">aaaaaaaaaa</col>
+      <where>
+        <col name=c"a_int">1234</col>
+      </where>
+    </table>
+  </database>
+</iq>
+
+        SQL Syntax:
+    update tbl_one 
+    set a_char = 'aaaaaaaaaa'
+    where a_int = 1234
+      
+
+      Result
+
+       Again, if there is no result set returned by the query, then
+      success or failure must be indicated.
+
+      
+<iq id="005" type="result" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one"/>
+  </database>
+</iq>
+      
+    
+
+    
+
+     If the type attribute has a value of set and there are no
+    <col> elements scoped within the <table> element, 
+    then the query must be interpreted as a delete.
+
+    
+<iq id="006" type="set"  to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one">
+      <where>
+        <col name="a_int" op="eq">1234</col>
+      </where>
+    </table>
+    </database>
+</iq>
+
+      SQL Syntax:
+      delete from tbl_one where a_int = 1234
+    
+
+    Result
+    
+    Again, if a result set is not generated by a query, then
+    success or failure must be indicated by the <table> element
+
+    
+<iq id="006" type="result"    to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one"/>
+  </database>
+</iq>
+    
+    
+  
+  
+
+   Procedures, or stored procedures Apparently procedures 
+  are not as common in RDBMS as I thought. Postgres and MySQL have 
+  functions, but not procedures. So until I, or someone else, 
+  researches this issue this feature is on hold.  
+, are often handy to make frequently used sql queries execute faster. 
+  These are simply queries stored in a precompiled form and given a 
+  name with a list of parameters. Each RDBMS handles procedures 
+  differently, but the common characteristics are that they are 
+  stored server side and have in/out parameters.
+
+   The <proc> element will be used to indicate a procedure. 
+  It has similar characteristics to the <table> element. The 
+  core differences are that the <col> elements have permissions 
+  and a <result> element can be used to indicate the value 
+  returned by the procedure.
+
+   The permission attribute on a <col> element is used to 
+  indicate whether the parameter is in (read), out (write) or in/out (both). 
+  
+   The only result set acceptable from a procedure is that of the 
+  parameters or <col> element. If the procedure produces a
+  result set outside of the parameters this should be ignored.
+
+  
+  
+
+   The server must be able to let the client know when an error 
+  occurs, instead of just being silent.
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  Code Message Description
399 Invalid Database Name Returned when the client has requested information from a
+      database which does not exist according to the component.
398 Invalid Table Name Returned when the client has requested information from a 
+      table/procedure which does not exist according to the component.
397 Invalid Column Name Returned when the client has requested information from a 
+      column which does not exist according to the component.
380 Permission Denied on Table Returned when the requested action is not allowed for the 
+      user on the table
401 Access Denied Returned when the user does not have permission to use the 
+      component.
+
+  If the user requests an action on a table which they do not have 
+  permission to do the following should be returned
+  
+  
+<iq id="004" type="error" from="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_two">
+      <error code="380">permission denied on table</error>
+    </table>
+</database>
+    </iq>  
+  
+
+  If the user is not allowed to access the component the following should be returned
+
+  
+<iq id="004" type="error" from="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <error code="401">Access Denied</error>
+  </database>
+</iq>
+  
+
+  
+  
+   There are requirements which can be provided by other jabber 
+  components/namespaces, namely the jabber:iq:browse namespace 
+  in-place of Version Negotiation. Due to the inherent limitations 
+  of the above data retrieval mechanisms more sophisticated querying 
+  techniques might be desired. The <query> element will extend 
+  the functionality 
+
+  
+     The abilities described in the Basics section are just that, 
+    basic. To provide more flexibility and allow for the full power 
+    of SQL without xmlifying everything, a <sql> element may 
+    be implemented to provide this feature.
+    
+     The <sql> element must be scoped within the <database> element.
+
+    
+<iq id="007" type="get" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <sql> select a_int, a_float from tbl_one </sql>
+  </database>
+</iq>
+    
+
+    Result
+
+    
+<iq id="007" type="result" to="db.host">
+  <database 
+      name="testdb"
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+    <table name="tbl_one" permission="both">
+      <col name="a_int" type="integer"/>
+      <col name="a_float" type="float"/>
+    </table>
+    <table name="tbl_one">
+      <col name="a_int">1234</col>
+      <col name="a_float">123.45</col>
+    </table>
+    <table name="tbl_one">
+      <col name="a_int">2345</col>
+      <col name="a_float">234.56</col>
+    </table>
+  </database>
+</iq>
+    
+
+     Since SQL is so flexible, the result set schema is not known 
+    until it is returned as a result of the query. Consequently, it 
+    must be sent as the first 'row' of the returned result. Each 
+    following row will be the actual data queried for.
+
+     If multiple tables are used within one SQL statement, then 
+    then name attribute within the <table> element can not be 
+    accurately denoted with a single table name. The best way to deal 
+    with this situation is to simply use a unique identifier within 
+    the scope of the <database> element. This will allow for 
+    multiple <sql> results to be scoped within the same result.
+
+      
+    
+
+    It is expected that this protocol will grow and be extended 
+    to meet various demands. Therefore, version
+    negotiationVersion Negotiation is being killed since browsing, feature 
+    negotiation, or disco will be able to perform this function, 
+    however it might be useful as an optional feature for clients 
+    that don't implement these yet, especially considering none 
+    of these have been standardized. will be 
+    incorporated up front.
+    
+    When the connection initiator, client end-user or
+    server/transport, starts a session, it must first send 
+    the version number it expects to use, otherwise, behavior 
+    is undefined.
+
+    
+<iq id="000" type="get" to="db.host">
+  <database 
+      xmlns="http://openaether.org/projects/jabber_database.html">
+      <version>0.1</version>
+    </database>
+</iq>
+    
+
+    Three responses are possible from the server.
+        
+      It supports that version number and responds with:
+      
+<iq id="000" type="result" from="db.host">
+  <database 
+      xmlns="http://openaether.org/projects/jabber_database.html">
+    <version>0.1</version>
+    </database>
+</iq>
+      
+      The type of 'result' indicates that the version request was
+      successful and if the client is satisfied with the version number, 
+      may continue with schema requests or whatever.
+    
+      It does not support that version number and responds with:
+      
+<iq id="000" type="error" from="db.host">
+  <database 
+      xmlns="http://openaether.org/projects/jabber_database.html"/>
+</iq>
+      
+      The type of 'error' indicates a failure in conforming to the
+      desired version number. The server may optionally send an
+      alternative option.
+      
+<iq id="000" type="error" from="db.host">
+  <database 
+      xmlns="http://openaether.org/projects/jabber_database.html">
+      <version>0.2</version>
+    </database>
+</iq>
+      
+      If the server has no idea what the client is talking
+      about it should send the appropriate Jabber error code.
+    
+    
+  
+
+
+
+  
+    No joins, roll ups, cubes
+    Views are not differentiated from tables
+    provides basic sql-like functionality only
+    Utilizes lowest common denominator approach
+  
+
+
+
+  
+    define procedures; what they are and how they work
+    determine value of adding administration features
+  
+
+
+
+  Thanks to Russell Davis (ukscone) for fine tuning the layout and wording of this jep. It would probably have been unreadable if it wasn't for him.
+
+
+
+  
+    
+<!ELEMENT version (#PCDATA)>
+<!ELEMENT error (#PCDATA)>
+<!ELEMENT sql(#PCDATA)>
+<!ELEMENT database (table | sproc | sql | error)*>
+<!ELEMENT table (col | where | error)*>
+<!ELEMENT where (col+)>
+<!ELEMENT col (#PCDATA)>
+<!ELEMENT proc(col | result | error)*>
+<!ELEMENT result (#PCDATA)>
+<!ATTLIST error code CDATA #IMPLIED>
+<!ATTLIST database name CDATA #IMPLIED>
+<!ATTLIST table 
+name CDATA #IMPLIED 
+    permission (read | write | both) #IMPLIED 
+    limit CDATA #IMPLIED
+>
+<!ATTLIST proc name CDATA #IMPLIED>
+<!ATTLIST col 
+    name CDATA #IMPLIED 
+    size CDATA #IMPLIED 
+    op (eq | neq | lt | gt | let | get | null) #IMPLIED 
+    conj (not | or | and ) #IMPLIED 
+    permission (read | write | both) #IMPLIED 
+    type (bit | tinyint | integer | utinyint | uinteger | 
+          float | numeric | date | datetime | timestamp | 
+          time | char | vchar | text | blob) #IMPLIED 
+>
+    
+  
+  
+    Anyone care to do this?
+  
+
+
diff --git a/xep-0044.xml b/xep-0044.xml
new file mode 100644
index 00000000..46b97299
--- /dev/null
+++ b/xep-0044.xml
@@ -0,0 +1,172 @@
+
+
+%ents;
+]>
+
+
+
+
+
+  Full Namespace Support for XML Streams
+  A description of the use of namespaces within Jabber.
+  &LEGALNOTICE;
+  0044
+  Deferred
+  Standards Track
+  Standards
+  
+    Robert
+    Norris
+    rob@cataclysm.cx
+    rob@cataclysm.cx
+  
+  
+    0.1
+    2002-08-26
+    rn
+    Initial version.
+  
+
+
+
+  Jabber has traditionally supported a subset of the XML Namespaces specification http://www.w3.org/TR/REC-xml-names. The protocol has been restricted to using specific namespace prefixes.
+
+  This is convenient for client and server implementors, since they only need to check the element name to determine both the name and the context of the element. However, these restrictions mean that developers are unable to take advantage of some of the features that namespaces provide.
+
+  Many developers have expressed an interest in having Jabber fully support namespaces - a desire which is likely to increase as time goes on. This support consists of allowing any namespace prefix to be used with any namespace, and also to allow namespace prefixes to be pre-declared on the stream root.
+
+  This document outlines the semantics required for servers and clients to support namespaces fully, and also discusses implementation techniques and methods for providing compatibility with older "fixed-prefix" implementations.
+
+
+
+
+  A typical XML stream is a pair of XML documents, one for each direction of communication between the two peers. An simple example of these might look like this:
+  
+  
+RECV: 
+SEND: 
+        
+      
+RECV: 
+        
+          jsm
+          1.4.2
+          Linux 2.4.19
+        
+      ]]>
+   
+
+  Note that there may also be additional namespaces specified in the stream header, to select or inform of various server features:
+
+  
+RECV: 
+      
+        PLAIN
+        DIGEST-MD5
+        EXTERNAL
+      
+SEND: 
+        
+      
+RECV: 
+        
+          jsm
+          1.4.2
+          Linux 2.4.19
+        
+      ]]>
+  
+
+  Currently, the prefix for each namespace is fixed; it cannot vary at all, since implementations use it for matching. The desire is to be able to use arbitrary prefixes:
+ 
+  
+RECV: 
+SEND: 
+        
+      
+RECV: 
+        
+          jsm
+          1.4.2
+          Linux 2.4.19
+        
+      ]]>
+  
+
+  Also, since there exist streams in both directions, it should be possible for prefixes to differ between the two streams:
+
+  
+RECV: 
+SEND: 
+        
+      
+RECV: 
+        
+          jsm
+          1.4.2
+          Linux 2.4.19
+        
+      ]]>
+  
+
+  Additionally, it should be possible to declare namespaces on the stream header so that they don't need to be declared later:
+
+  
+RECV: 
+SEND: 
+        
+      
+RECV: 
+        
+          jsm
+          1.4.2
+          Linux 2.4.19
+        
+      ]]>
+  
+
+  And of course, any combinations of these should be valid, as long as they conform to the XML Namespaces specification.
+
+
+
+
+
+  In order to implement namespaces correctly, implementations will need to check both the namespace of an element (or attribute), and its namespace, in order to match it. An implementation will need to maintain some sort of mapping between prefixes and namespaces, though some parsers, such as recent versions of Expat, can do this for the implementor.
+
+  Implementations should, wherever possible, adhere to the IETF maxim "be liberal in what you accept, and conservative in what you send". This means accepting any valid namespace prefix, but using only the traditional prefixes (i.e. "stream" for "http://etherx.jabber.org/streams", "sasl" for "http://www.iana.org/assignments/sasl-mechanisms", and no prefix for the application namespace). For servers, this has the added benefit of getting compatibility with non-namespace-aware clients for free.
+
+  In server components that may have to forward packets received from one stream to another stream, it may be necessary for the application namespace to be rewritten before the packet is forwarded. Examples of this are client-to-server and server-to-server components, which must convert "jabber:client" and "jabber:server" components, respectively, into "jabber:component:accept" packets before they are forwarded to the router.
+
+
+
+
diff --git a/xep-0045.xml b/xep-0045.xml
new file mode 100644
index 00000000..4b5b1649
--- /dev/null
+++ b/xep-0045.xml
@@ -0,0 +1,5206 @@
+
+
+%ents;
+
+
+]>
+
+
+
+  Multi-User Chat
+  This document defines an XMPP protocol extension for multi-user text conferencing.
+  &LEGALNOTICE;
+  0045
+  Draft
+  Standards Track
+  Standards JIG
+  
+    XMPP Core
+    XMPP IM
+    JEP-0004
+    JEP-0030
+    JEP-0068
+    JEP-0082
+    JEP-0128
+  
+  
+  
+  muc
+  
+    muc
+    http://jabber.org/protocol/muc/muc.xsd
+  
+  
+    muc#admin
+    http://jabber.org/protocol/muc/admin.xsd
+  
+  
+    muc#owner
+    http://jabber.org/protocol/muc/owner.xsd
+  
+  
+    muc#unique
+    http://jabber.org/protocol/muc/unique.xsd
+  
+  
+    muc#user
+    http://jabber.org/protocol/muc/user.xsd
+  
+  
+  &stpeter;
+  
+    1.21
+    2006-09-13
+    psa
+    
+      
+        Clarified that inclusion of MUC extension in room join/create request triggers Data Forms flow but that absence of MUC extension leads to automatic room creation for backwards compatibility with older groupchat 1.0 protocol.
+        Specified use of <not-acceptable/> error on nickname change if nicks are locked down.
+        Required clients to discover room configuration prior to entering room and specified related security considerations, including use of privacy-related status codes 170, 171, 172, 173, and 174.
+        Specified use of <not-acceptable/> error if room configuration options cannot be processed or violate service policies.
+        Made explicit that roomnicks must not consist only of spaces.
+        Moved all service discovery use cases into dedicated section.
+        Changed jabber:x:delay support from SHOULD to MUST.
+        Clarified that _whois room configuration option specifies room type.
+        Defined JEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.
+        Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.
+        Added internationalization consideration about localization of field labels for various data forms.
+        Specified that implementations may persist roles across visits and should do so for moderated rooms.
+        Added protocol and service discovery feature for requesting a unique room name prior to room creation.
+        Further clarified nature of reserved room nicknames and nickname lockdown.
+        Defined data forms for requesting voice and approving voice requests.
+        Added multiple invitee example for XMPP URI.
+        Clarified order of presence, discussion history, etc.
+        Added status codes for occupant's own roomnick, service-modified roomnick, and warning that room discussion is publicly logged.
+        Clarified privacy and anonymity considerations regarding room logging and non-anonymous rooms.
+      
+    
+  
+  
+    1.20
+    2005-09-08
+    psa
+    Harmonized ability to kick and ban users, and clarified that a user cannot be kicked or banned by a moderator or admin with a lower affiliation.
+  
+  
+    1.19
+    2005-04-21
+    psa
+    Specified how to send multiple invitations simultaneously; corrected some errors regarding consistency of affiliation state changes; changed message events prohibition from MUST NOT to SHOULD NOT; corrected error handling related to the #traffic disco node; allowed <password/> as a child of <destroy/>; changed max users error from ¬allowed; to &unavailable;; specified that the maxchars attribute counts characters in complete XML stanzas; added disco features for FORM_TYPEs; defined registry for status codes; split Create Instant Room into separate use case for protocol compliance purposes; adjusted XML schemas to reflect the foregoing changes; re-wrote the introduction; clarified small textual matters throughout.
+  
+  
+    1.18
+    2004-11-02
+    psa
+    Corrected several errors in the affiliation state chart and in the examples (wrong FORM_TYPE values); mentioned /me command.
+  
+  
+    1.17
+    2004-10-04
+    psa
+    Added text about allowable extension namespaces and related service discovery mechanisms; specified well-known service discovery nodes; added conformance terms to clarify some descriptions; modified affiliation state chart to allow more flexible state changes; per list dicussion, added ability to convert a one-to-one chat into a conference, including sending of history; specified error to use when max users limit is reached; specified form for admin approval of user registration requests and modified FORM_TYPE from http://jabber.org/protocol/muc#user to http://jabber.org/protocol/muc#register; modified FORM_TYPE for room configuration from http://jabber.org/protocol/muc#owner to http://jabber.org/protocol/muc#roomconfig.
+  
+  
+    1.16
+    2004-06-30
+    psa
+    Added example and registry submission for service discovery extension.
+  
+  
+    1.15
+    2004-06-24
+    psa
+    Removed jabber:iq:browse references; clarified order of presence stanzas sent to new occupant on entering room; specified format of in-room messages (type='groupchat', from='room@service'); clarified allowable attributes in various list-related operations; made admin/owner revocation text and examples consistent with state chart; clarified ownership revocation conflict scenarios; changed the 'muc#roomconfig_inviteonly' field to 'muc#roomconfig_membersonly'; changed attribute order in examples to match XML canonicalization rules; corrected several errors in the schemas.
+  
+  
+    1.14
+    2004-05-03
+    psa
+    Corrected discovery of registered roomnicks; added note about error to return if nicks are locked down.
+  
+  
+    1.13
+    2004-03-31
+    psa
+    Fixed an error in the muc#user schema.
+  
+  
+    1.12
+    2004-03-01
+    psa
+    Corrected a few errors in the examples; added IQ results in order to clarify workflows.
+  
+  
+    1.11
+    2004-02-05
+    psa
+    Clarified JID matching rules (same as for privacy lists in XMPP IM).
+  
+  
+    1.10
+    2004-01-07
+    psa
+    Added XMPP error handling; fully specified all conformance terms.
+  
+  
+    1.9
+    2003-12-14
+    psa
+    Removed protocol for requesting voice in a moderated room (should be performed using Ad-Hoc Commands).
+  
+  
+    1.8
+    2003-12-04
+    psa
+    Added protocol for requesting voice in a moderated room; added (informational) mapping of IRC commands to MUC protocols.
+  
+  
+    1.7
+    2003-10-21
+    psa
+    Added room configuration option for restricting presence broadcast to certain roles.
+  
+  
+    1.6
+    2003-10-03
+    psa
+    Added history management protocol on entering a room.
+  
+  
+    1.5
+    2003-09-11
+    psa
+    Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per JEP-0068; defined Jabber Registrar submissions; added schema locations.
+  
+  
+    1.4
+    2003-02-16
+    psa
+    Added XML schemas.
+  
+  
+    1.3
+    2003-02-11
+    psa
+    Added reference to nodeprep Internet-Draft.
+  
+  
+    1.2
+    2003-01-30
+    psa
+    Commented out revision history prior to version 1.0 (too long); clarified business rules regarding when nicks, full JIDs, and bare JIDs are used in reference to roles and affiliations; consistently specified that extended presence information in the muc#user namespace must include the full JID as the value of the 'jid' attribute in all cases; cleaned up text and examples throughout; added open issue regarding syntax of room nicknames.
+  
+  
+    1.1
+    2002-12-16
+    psa
+    Added protocol for declining an invitation; replaced <created/> element with status code 201; modified the destroy room protocol so that <destroy/> is a child of <query/>; clarified usage of 'nick' attribute when adding members; prohibited use of message events.
+  
+  
+    1.0
+    2002-11-21
+    psa
+    Per a vote of the Jabber Council, revision 0.23 was advanced to Draft on 2002-11-21. (For earlier revision history, refer to XML source.)
+  
+  
+    0.23
+    2002-11-06
+    psa
+    Added examples for disco#items queries sent to a room; prohibited 'type' attribute on invite messages sent from client to room; added dependencies for JEPs 11 and 30; changed 'room user' to 'occupant'; fixed many small errors throughout.
+  
+  
+    0.22
+    2002-11-04
+    psa
+    Added example for disco#items; added support for cancellation of room configuration using type='cancel' from JEP-0004; noted 403 error for invites sent by non-admins in members-only room.
+  
+  
+    0.21
+    2002-11-01
+    psa
+    Clarified several small ambiguities; made <body/> optional on invites sent from the service to the invitee; added error scenarios for changing nickname and for destroying the room; specified that the service must return the full member list for a members-only room (not only the members in the room); updated the disco examples to track protocol changes.
+  
+  
+    0.20
+    2002-10-29
+    psa
+    Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the JSF IPR policy.
+  
+  
+    0.19
+    2002-10-28
+    psa
+    Added ability to create an instant room within MUC (not by using gc-1.0 protocol); cleaned up disco examples.
+  
+  
+    0.18
+    2002-10-27
+    psa
+    Added experimental support for disco; added sections for security, IANA, and JANA considerations; corrected typographical errors; cleaned up some DocBook formatting.
+  
+  
+    0.17
+    2002-10-23
+    psa
+    Added the optional <actor/> element (with 'jid' attribute) to <item/> elements inside presence stanzas of type "unavailable" that are sent to users who are kicked or banned, as well as within IQs for tracking purposes; reverted all list editing use cases (ban, voice, member, moderator, admin, owner) to use of MUC format rather than 'jabber:x:data' namespace; added several guidelines regarding generation and handling of XML stanzas; cleaned up the change room subject use case; changed several ambiguous uses of 'would', 'can', and 'will' to 'should', 'may', or 'must'; fixed several small errors in the text, examples, and DTDs.
+  
+  
+    0.16
+    2002-10-20
+    psa
+    Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <invitor/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking administrative privileges; adjusted DTD to track all changes.
+  
+  
+    0.15
+    2002-10-18
+    psa
+    Fully incorporated the change to affiliations + roles; moved a number of admin use cases to a new section for moderator use cases; added participant use case for requesting membership; added admin use cases for adding members, removing members, granting and revoking moderator privileges, and modifying the moderator list; organized the sections in a more logical manner.
+  
+  
+    0.14
+    2002-10-17
+    psa
+    Significantly modified the privileges model by distinguishing between in-room "roles" and long-lived "affiliations"; specified the privileges of the various roles and affiliations; included state transition charts for both roles and affiliations; removed use of MUC protocol for editing ban, voice, and admin lists (but not for the actions of banning users and granting/revoking voice); added delivery rule regarding IQ stanzas; changed kick so that the action is based on changing the role to "none".
+  
+  
+    0.13
+    2002-10-16
+    psa
+    Corrected the change nickname examples (newnick sent on unavailable, no nick sent on available).
+  
+  
+    0.12
+    2002-10-16
+    psa
+    Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by invitor).
+  
+  
+    0.11
+    2002-10-16
+    psa
+    Changed 'participant' to 'room user' and 'discussant' to 'participant'; clarified presence rule about client generation of extended presence information; added role of 'none'.
+  
+  
+    0.10
+    2002-10-15
+    psa
+    Fixed extended presence on entering or creating a room (plain '...muc' with no fragment); harmonized #user with #admin regarding the use of the <item/> element and associated attributes (jid, nick, etc.), and added 'role' attribute; modified management of voice, ban, admin, and member lists to use <query/> wrapper and new <item/> structure; changed the 'member' role to 'discussant', added 'outcast' role for banned users, and added new 'member' role to enable management of member lists; changed invitation-only rooms to members-only rooms and made appropriate adjustments to apply member lists to both members-only rooms and open rooms; modified nickname change protocol slightly to send the old nickname in the unavailable presence and the new nickname in the available presence; removed prohibition on members-only rooms that are password-protected; removed the <query/> wrapper for the <destroy/> element; updated the DTDs.
+  
+  
+    0.9
+    2002-10-13
+    psa
+    Added extended presence ('...#user') on entering a room for MUC clients; changed namespace on room creation request to '...#owner'; added a service discovery example using jabber:iq:browse; added information about discussion history; made small fixes to several examples; further defined the presence rules; transferred all implementation notes to a dedicated section; added a Terminology section.
+  
+  
+    0.8
+    2002-10-10
+    psa
+    Made further changes to the room creation workflow (finally correct); removed feature discovery use case (this needs to be addressed by a real service discovery protocol!); added ability for room owners to edit the admin list; removed <body/> from invitations generated by the service; removed messages sent to kicked and banned users (handled by unavailable presence with status code); added a number of implementation notes; converted all examples to Shakespeare style.
+  
+  
+    0.7.6
+    2002-10-09
+    psa
+    Fixed the room creation workflow; changed some terminology ("join" to "enter" and "leave" to "exit").
+  
+  
+    0.7.5
+    2002-10-08
+    psa
+    Specified and improved the handling of invitation-only rooms. In particular, added the ability for room admins to edit the invitation list and added a configuration option that limits the ability to send invitations to room admins only.
+  
+  
+    0.7.4
+    2002-10-07
+    psa
+    Changed namespaces from http://jabber.org/protocol/muc/owner etc. to http://jabber.org/protocol/muc#owner etc. per Jabber Council discussion.
+  
+  
+    0.7.3
+    2002-10-07
+    psa
+    Changed namespaces to HTTP URIs; left role handling up to the implementation; further clarified presence rules.
+  
+  
+    0.7.2
+    2002-10-06
+    psa
+    Disallowed kicking, banning, and revoking voice with respect to room admins and room owners; replaced <x/> with <query/> in the Discovering Room Features and Destroying a Room use cases; corrected some small errors and made many clarifications throughout.
+  
+  
+    0.7.1
+    2002-10-04
+    psa
+    Removed <whois/> command (unnecessary since participants with appropriate privileges receive the full JID of all participants in presence stanzas); completed many small fixes throughout.
+  
+  
+    0.7
+    2002-10-03
+    psa
+    More clearly delineated participant roles and defined the hierarchy thereof (owner, admin, member, visitor); replaced <voice/> element in extended presence with <item role='member'/>; changed initial room configuration to use IQ rather than message; adjusted presence rules (especially regarding extended presence information); cleaned up examples throughout; updated DTD to track changes.
+  
+  
+    0.6
+    2002-09-21
+    psa
+    More clearly defined the scope; removed fully anonymous rooms; changed meaning of semi-anonymous rooms and of non-anonymous rooms; added mechanism for notification of full JIDs in non-anonymous rooms; replaced the <admin/> element in extended presence with a <role/> element (more extensible); changed room passwords to cleartext; added status codes for various messages received from the service; added lists of valid error and status codes associated with the 'http://jabber.org/protocol/muc#user' namespace; added a <reason/> element for invitations; made kick and ban reasons child elements rather than attributes; replaced stopgap feature discovery mechanism with jabber:iq:negotiate; added extended presence element to room creation request and clarified the room creation process; specified presence reflection rules; added method for destroying a room; adjusted DTDs to track all changes.
+  
+  
+    0.5.1
+    2002-09-20
+    psa
+    Added DTDs; changed feature discovery to use <x/> element rather than query and made service response come in IQ result; fixed reference to JEP 29; changed 'grant' to 'add' and 'revoke' to 'remove' for consistency in the item attributes; made several other small changes.
+  
+  
+    0.5
+    2002-09-19
+    psa
+    Changed the kick, ban, and voice protocols; added a few more configuration options; specified the restrictions for roomnicks; and added a stopgap service discovery protocol.
+  
+  
+    0.4
+    2002-09-18
+    psa
+    Changed all non-GC-1.0 use cases to jabber:gc:* namespaces or jabber:x:data; added use cases for ban list management and room moderation; added protocol for sending notice of admin and voice privileges in presence; cleaned up text and many examples.
+  
+  
+    0.3
+    2002-09-17
+    psa
+    Changed admin use cases; cleaned up participant and owner use cases.
+  
+  
+    0.2
+    2002-09-12
+    psa
+    Broke content out into three actors (participant, owner, and admin) and added more detail to owner and admin use cases.
+  
+  
+    0.1
+    2002-09-09
+    psa
+    Initial version.
+  
+
+
+  Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types. These extensions are implemented using protocol elements qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).
+
+
+  This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in &rfc1459; and its successors).
+  This document explicitly does not address the following:
+  
+    Relationships between rooms (e.g., hierarchies of rooms)
+    Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname)
+    Moderation of individual messages
+    Security and encryption at the level of a room or service
+    Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio chat services
+    Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)
+  
+  This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by Jabber client and component developers alike. Future specifications may of course address the topics mentioned above.
+
+
+  This document addresses the minimal functionality provided by existing multi-user chat services in Jabber. For the sake of backwards-compatibility, this document uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:
+  
+    Each room is identified as &ROOM; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.
+    Each occupant in a room is identified as &ROOMJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.
+    A user enters a room (i.e., becomes an occupant) by sending presence to &ROOMJID;.
+    Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants.
+    An occupant can change his or her room nickname and availability status within the room by sending presence information to <room@service/newnick>.
+    An occupant exits a room by sending presence of type "unavailable" to its current &ROOMJID;.
+  
+  The additional features and functionality addressed in this document include the following:
+  
+    native conversation logging (no in-room bot required)
+    enabling users to request membership in a room
+    enabling occupants to view an occupant's full JID in a non-anonymous room
+    enabling moderators to view an occupant's full JID in a semi-anonymous room
+    allowing only moderators to change the room subject
+    enabling moderators to kick participants and visitors from the room
+    enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room, and to manage the voice list
+    enabling admins to grant and revoke moderator privileges, and to manage the moderator list
+    enabling admins to ban users from the room, and to manage the ban list
+    enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room
+    enabling owners to limit the number of occupants
+    enabling owners to specify other owners
+    enabling owners to grant and revoke administrative privileges, and to manage the admin list
+    enabling owners to destroy the room
+  
+  In addition, this document provides protocol elements for supporting the following room types:
+  
+    public or hidden
+    persistent or temporary
+    password-protected or unsecured
+    members-only or open
+    moderated or unmoderated
+    non-anonymous or semi-anonymous
+  
+
+
+  
+    Affiliation -- a long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", and "outcast" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.
+    Ban -- to remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".
+    Bare JID -- the <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Room JID.
+    Full JID -- the <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.
+    GC -- the minimal "groupchat 1.0" protocol http://www.jabber.org/protocol/groupchat.html developed within the Jabber community in 1999; MUC is backwards-compatible with GC.
+    History -- a limited number of message stanzas sent to a new occupant to provide the context of current discussion.
+    Invitation -- a special message sent from one user to another asking the recipient to join a room.
+    IRC -- Internet Relay Chat.
+    Kick -- to temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".
+    Logging -- storage of discussions that occur within a room for public retrieval outside the context of the room.
+    Member -- a user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".
+    Moderator -- a room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has an role of "moderator".
+    MUC -- the multi-user chat protocol for text-based conferencing specified in this document.
+    Occupant -- any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).
+    Outcast -- a user who has been banned from a room. An outcast has an affiliation of "outcast".
+    Participant -- an occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".
+    Private Message -- a message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).
+    Role -- a temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.
+    Room -- a virtual space that Jabber users figuratively enter in order to participate in real-time, text-based conferencing with other users.
+    Room Administrator -- a user empowered by the room owner to perform administrative functions such as banning users; however, is not allowed to change defining room features. An admin has an affiliation of "admin".
+    Room ID -- the node identifier portion of a Room JID, which may be opaque and thus lack meaning for human users (see Business Rules for syntax); contrast with Room Name.
+    Room JID -- the &ROOMJID; by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.
+    Room Name -- a user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.
+    Room Nickname -- the resource identifier portion of a Room JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.
+    Room Owner -- the Jabber user who created the room or a Jabber user who has been designated by the room creator or owner as someone with owner privileges (if allowed); is allowed to change defining room features as well as perform all administrative functions. An owner has an affiliation of "owner".
+    Room Roster -- a Jabber client's representation of the occupants in a room.
+    Server -- a Jabber server that may or may not have associated with it a text-based conferencing service.
+    Service -- a host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org).
+    Subject -- a temporary discussion topic within a room.
+    Visit -- a user's "session" in a room, beginning when the user enters the room (i.e., becomes an occupant) and ending when the user exits the room.
+    Visitor -- in a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".
+    Voice -- in a moderated room, the privilege to send messages to all occupants.
+  
+  
+    Fully-Anonymous Room -- a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.
+    Hidden Room -- a room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.
+    Members-Only Room -- a room that a user cannot enter without being on the member list; antonym: Open Room.
+    Moderated Room -- a room in which only those with "voice" may send messages to all occupants; antonym: Unmoderated Room.
+    Non-Anonymous Room -- a room in which an occupant's full JID is exposed to all other occupants, although the occupant may choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.
+    Open Room -- a room that anyone may enter without being on the member list; antonym: Members-Only Room.
+    Password-Protected Room -- a room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.
+    Persistent Room -- a room that is not destroyed if the last occupant exits; antonym: Temporary Room.
+    Public Room -- a room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.
+    Semi-Anonymous Room -- a room in which an occupant's full JID can be discovered by room admins only; contrast with Fully-Anonymous Room and Non-Anonymous Room.
+    Temporary Room -- a room that is destroyed if the last occupant exits; antonym: Persistent Room.
+    Unmoderated Room -- a room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.
+    Unsecured Room -- a room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.
+  
+  
+    Most of the examples in this document use the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's Macbeth, represented here as the "darkcave@macbeth.shakespeare.lit" chatroom. The characters are as follows:
+    
+      
+        
+        
+        
+      
+      
+        
+        
+        
+      
+      
+        
+        
+        
+      
+      
+        
+        
+        
+      
+    Room Nickname Full JID Affiliation
firstwitch crone1@shakespeare.lit/desktop Owner
secondwitch wiccarocks@shakespeare.lit/laptop Admin
thirdwitch hag66@shakespeare.lit/pda None
+  
+
+
+  There are two dimensions along which we can measure a user's connection with or position in a room. One is the user's long-lived affiliation with a room -- e.g., a user's status as an owner or an outcast. The other is a user's role while an occupant of a room -- e.g., an occupant's position as a moderator with the ability to kick visitors and participants. These two dimensions are distinct from each other, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.
+  
+    There are four defined roles that an occupant may have:
+    
+      Moderator
+      Participant
+      Visitor
+      None (the absence of a role)
+    
+    Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).
+    There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).
+    A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants.
+    Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.
+    Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants.
+    
+      For the most part, roles exist in a hierarchy. For instance, a participant can do anything a visitor can do, and a moderator can do anything a participant can do. Each role has privileges not possessed by the next-lowest role; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).
+      
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+      Privilege None Visitor Participant Moderator
Present in Room No Yes Yes Yes
Receive Messages No Yes Yes Yes
Change Availability Status No Yes Yes Yes
Change Room Nickname No Yes* Yes Yes
Send Private Messages No Yes* Yes Yes
Invite Other Users No Yes* Yes* Yes
Send Messages to All No No** Yes Yes
Modify Subject No No* Yes* Yes
Kick Participants and Visitors No No No Yes
Grant Voice No No No Yes
Revoke Voice No No No Yes***
+      * Default; configuration settings MAY modify this privilege.
+      ** An implementation MAY grant voice by default to visitors in unmoderated rooms.
+      *** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.
+    
+    
+      The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants. Role changes and their triggering actions are specified in the following table.
+      
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+      > None Visitor Participant Moderator
None -- Enter moderated room Enter unmoderated room Admin or owner enters room
Visitor Exit room or be kicked by a moderator -- Moderator grants voice Admin or owner grants moderator privileges
Participant Exit room or be kicked by a moderator Moderator revokes voice -- Admin or owner grants moderator privileges
Moderator Exit room Admin or owner changes role to visitor * Admin or owner changes role to participant or revokes moderator privileges * --
+      * A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.
+      Note: Certain roles are typically implicit in certain privileges. For example, an admin or owner is automatically a moderator, so if an occupant is granted admin status then the occupant will by that fact be granted moderator privileges; similarly, when an occupant is made a member in a moderated room, the occupant automatically has a role of participant. However, the loss of admin status does not necessarily mean that the occupant is no longer a moderator (since a "mere" participant can be a moderator). Therefore, the roles that are gained when an occupant is granted a certain affiliation are stable, whereas the roles that are lost when an occupant loses a certain affilitation are no hardcoded and are left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both admin/owner privileges and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change.
+    
+  
+  
+    There are five defined affiliations that a user may have in relation to a room:
+    
+      Owner
+      Admin
+      Member
+      Outcast
+      None (the absence of an affiliation)
+    
+    These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID.
+    If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).
+    The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved in the room).
+    An outcast is a user who has been banned from a room and who is not allowed to enter the room.
+    Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.
+    
+      For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.
+      
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+      Privilege Outcast None Member Admin Owner
Enter Open Room No Yes* Yes Yes Yes
Register with an Open Room No Yes N/A N/A N/A
Enter Members-Only Room No No Yes* Yes Yes
Ban Members and Unaffiliated Users No No No Yes Yes
Edit Member List No No No Yes Yes
Edit Moderator List No No No Yes** Yes**
Edit Admin List No No No No Yes
Edit Owner List No No No No Yes
Change Room Definition No No No No Yes
Destroy Room No No No No Yes
+      * As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.
+      ** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.
+    
+    
+      The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants. Affiliation changes and their triggering actions are specified in the following table.
+      
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+          
+        
+      > Outcast None Member Admin Owner
Outcast -- Admin or owner removes ban Admin or owner adds user to member list Owner adds user to admin list Owner adds user to owner list
None Admin or owner applies ban -- Admin or owner adds user to member list, or user registers as member (if allowed) Owner adds user to admin list Owner adds user to owner list
Member Admin or owner applies ban Admin or owner changes affiliation to "none" -- Owner adds user to admin list Owner adds user to owner list
Admin Owner applies ban Owner changes affiliation to "none" Owner changes affiliation to "member" -- Owner adds user to owner list
Owner Owner applies ban Owner changes affiliation to "none" Owner changes affiliation to "member" Owner changes affiliation to "admin" --
+    
+  
+
+
+  A MUC implementation MUST support &jep0030;.
+  
+    A Jabber entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID:
+    
+  
+
+    ]]>
+    The service MUST return its identity and the features it supports:
+    
+  
+    
+    
+  
+
+    ]]>
+    Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC service SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result.
+  
+  
+    The service discovery items ("disco#items") protocol enables a user to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.
+    
+  
+
+    ]]>
+    The service SHOULD return a full list of the rooms it hosts.
+    
+  
+    
+    
+    
+    
+  
+
+    ]]>
+    If the full list of rooms is large (see JEP-0030 for details), the service MAY return only a partial list of rooms.
+  
+  
+    Using the disco#info protocol, a user may also query a specific chat room for more detailed information about the room. A user SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the Security Considerations for details).
+    
+  
+
+    ]]>
+    The room MUST return its identity and SHOULD return the features it supports:
+    
+  
+    
+    
+    
+    
+    
+    
+    
+    
+  
+
+    ]]>
+    Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the Jabber Registrar; see also the Jabber Registrar section of this document).
+    A chatroom MAY return more detailed information in its disco#info response using &jep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:
+    
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+        http://jabber.org/protocol/muc#roominfo
+      
+      
+        The place for all good witches!
+      
+      
+        true
+      
+      
+        crone1@shakespeare.lit
+      
+      
+        Spells
+      
+      
+        3
+      
+      
+        en
+      
+      
+        http://www.shakespeare.lit/chatlogs/darkcave/
+      
+      
+        xmpp:pubsub.shakespeare.lit?node=chatrooms/darkcave
+      
+    
+  
+
+    ]]>
+    Some extended room information may be dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration) whereas other information may be based on the room configuration.
+    Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document.
+  
+  
+    A user MAY also query a specific chat room for its associated items:
+    
+  
+
+    ]]>
+    An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.
+    
+  
+    
+    
+  
+
+    ]]>
+    Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example.
+    
+  
+
+    ]]>
+  
+  
+    If a non-occupant attempts to send a disco request to an address of the form &ROOMJID;, a MUC service SHOULD return the request to the entity and specify a &badrequest; error condition. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the Implementation Guidelines section of this document for details.
+  
+  
+    A Jabber user may want to discover if one of the user's contacts supports the Multi-User Chat protocol. This is done using Service Discovery.
+    
+  
+
+    ]]>
+    The client SHOULD return its identity and the features it supports:
+    
+  
+    
+    ...
+    
+    ...
+  
+
+    ]]>
+    A user may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID (<user@host/resource>) while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms':
+    
+  
+
+    ]]>
+    
+  
+    
+    
+  
+
+    ]]>
+    Optionally, the contact MAY include its roomnick as the value of the 'name' attribute:
+    
+    ...
+    ]]>
+  
+
+
+  The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:
+  
+    existing "groupchat 1.0" protocol for minimal functionality
+    straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types
+    additional protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace
+  
+  Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal Jabber router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.
+  
+    
+      In order to participate in the discussions held in a multi-user chat room, a Jabber user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:
+      
+      ]]>
+      In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "darkcave" on the "macbeth.shakespeare.lit" chat service with a room nickname of "thirdwitch".
+      If the user does not specify a room nickname, the service SHOULD return a &badjid; error:
+      
+  
+    
+  
+
+      ]]>
+    
+    
+      Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any Jabber client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):
+      
+  
+
+      ]]>
+      Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.
+    
+    
+      If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate:
+      
+  
+    
+  
+
+
+
+  
+    
+  
+
+      ]]>
+      In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).
+      The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant):
+      
+  
+    
+  
+
+
+
+  
+    
+  
+
+
+
+  
+    
+    
+  
+
+      ]]>
+      In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant. As shown in the last stanza, the presence sent by the room to a user from itself as an occupant SHOULD include a status code of 110 so that the user knows this presence refers to itself as an occupant.
+      The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.
+      
+  
+    
+    
+    
+  
+
+      ]]>
+      Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster".
+      After sending the presence broadcast (and only after doing so), the service may then send discussion history, live messages, presence updates, and other in-room traffic.
+    
+    
+      The following table summarizes the initial default roles that a service should set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).
+      
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+        
+          
+          
+          
+          
+          
+        
+      Room Type None Member Admin Owner
Moderated Visitor Participant Moderator Moderator
Unmoderated Participant Participant Moderator Moderator
Members-Only N/A * Participant Moderator Moderator
Open Participant Participant Moderator Moderator
+      * Entry is not permitted.
+    
+    
+      If the room is non-anonymous, the service MUST send the new occupant's full JID to all occupants using extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID:
+      
+  
+    
+  
+
+.
+.
+.
+      ]]>
+      If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. This SHOULD be done by including a status code of "100" in the initial presence that the room sends to the new occupant:
+      
+  
+    
+    
+    
+    
+  
+
+      ]]>
+      However, it MAY done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":
+      
+  This room is not anonymous.
+  
+    
+  
+
+      ]]>
+      The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality).
+    
+    
+      If the room is semi-anonymous, the service MUST send the new occupant's full JID in the format shown above only to those occupants with a role of "moderator".
+      (Note: All subsequent examples include the 'jid' attribute for each <item/> element, even though this information is not sent to non-moderators in semi-anonymous rooms.)
+    
+    
+      If the room requires a password and the user did not supply one (or the password provided is incorrect), the service MUST deny access to the room and inform the user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a ¬authorized; error:
+      
+  
+    
+  
+
+      ]]>
+      Passwords SHOULD be supplied with the presence stanza sent when entering the room, contained within an <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace and containing a <password/> child. Passwords are to be sent as cleartext; no other authentication methods are supported at this time, and any such authentication or authorization methods shall be defined in a separate specification (see the Security Considerations section of this document).
+      
+  
+    cauldronburn
+  
+
+      ]]>
+    
+    
+      If the room is members-only but the user is not on the member list, the service MUST deny access to the room and inform the user that they are not allowed to enter the room; this is done by returning a presence stanza of type "error" specifying a ®istration; error condition:
+      
+  
+    
+  
+
+      ]]>
+    
+    
+      If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that he or she is banned; this is done by returning a presence stanza of type "error" specifying a &forbidden; error condition:
+      
+  
+    
+  
+
+      ]]>
+    
+    
+      If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:
+      
+  
+    
+  
+
+      ]]>
+      However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).
+    
+    
+      If the room has reached its maximum number of users, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:
+      
+  
+    
+  
+
+      ]]>
+      Alternatively, the room could kick an "idle user" in order to free up space. Also, a room MUST always allow entry by a room admin or owner.
+    
+    
+      If a user attempts to enter a room while it is "locked" (i.e., before the room creator provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an ¬found; error to the user:
+      
+  
+    
+  
+
+      ]]>
+    
+    
+      If the room does not already exist when the user seeks to enter it, the service SHOULD create it; however, this is not required, since an implementation or deployment MAY choose to restrict the privilege of creating rooms. For details, see the Creating a Room section of this document.
+    
+    
+      If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged. This SHOULD be done by including a status code of "170" in the initial presence that the room sends to the new occupant:
+      
+  
+    
+    
+    
+    
+    
+  
+
+      ]]>
+    
+    
+      After sending initial presence as shown above, a room MAY send discussion history to the new occupant. (The room MUST NOT send any discussion history before it finishes sending room presence as specified in the Presence Broadcast section of this document.) Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment.
+      
+  Thrice the brinded cat hath mew'd.
+  
+
+
+
+  Thrice and once the hedge-pig whined.
+  
+
+
+
+  Harpier cries 'Tis time, 'tis time.
+  
+
+      ]]>
+      Discussion history messages MUST be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &jep0091;) to indicate that they are sent with delayed delivery and specify the times at which they were originally sent. The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (the 'from' attribute SHOULD be set to the room JID in semi-anonymous rooms). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.
+    
+    
+      A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:
+      
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+        
+          
+          
+          
+        
+      Attribute Datatype Meaning
maxchars int Limit the total number of characters in the history to "X" (where the character count is the characters of the complete XML stanzas, not only their XML character data).
maxstanzas int Limit the total number of messages in the history to "X".
seconds int Send only the messages received in the last "X" seconds.
since dateTime Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &jep0082;).
+      The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).
+      The following examples illustrate the use of this protocol.
+      
+  
+    
+  
+
+      ]]>
+      
+  
+    
+  
+
+      ]]>
+      
+  
+    
+  
+
+      ]]>
+      Obviously the service SHOULD NOT return all messages sent in the room since the beginning of the Unix era, and SHOULD appropriately limit the amount of history sent to the user based on service or room defaults.
+      
+  
+    
+  
+
+      ]]>
+    
+  
+  
+    In order to exit a multi-user chat room, an occupant sends a presence stanza of type "unavailable" to the &ROOMJID; it is currently using in the room.
+    
+    ]]>
+    The service MUST then send presence stanzas of type "unavailable" from the departing occupant's room JID to the full JIDs of the departing occupant and of the remaining occupants:
+    
+  
+    
+  
+
+
+  
+    
+  
+
+
+  
+    
+  
+
+    ]]>
+    Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations, and MAY also contain normal <status/> information (which enables occupants to provide custom exit messages if desired).
+    
+  gone where the goblins go
+
+    ]]>
+    Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the &ROOMJID; to which the user's client has sent directed presence.
+    If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.
+  
+  
+    A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).
+    
+    ]]>
+    The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname. The unavailable presence MUST contain the new nickname and an appropriate status code (namely 303) as extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace so that Jabber clients are able to provide relevant hints to occupants regarding the nickname change if desired.
+    
+  
+    
+    
+  
+
+
+  
+    
+    
+  
+
+
+  
+    
+    
+  
+
+
+
+  
+    
+  
+
+
+  
+    
+  
+
+
+  
+    
+  
+
+    ]]>
+    If the user attempts to change his or her room nickname to a room nickname that is already in use by another user (or that is reserved by another user affiliated with the room, e.g., a member or owner), the service MUST deny the nickname change request and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:
+    
+  
+    
+  
+
+    ]]>
+    However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the Nickname Conflict section of this document for details.
+    If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a ¬acceptable; error condition:
+    
+  
+    
+  
+
+    ]]>
+    The use SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.
+  
+  
+    In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.
+    
+  xa
+  gone where the goblins go
+
+    ]]>
+    The service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:
+    
+  xa
+  gone where the goblins go
+  
+    
+  
+
+.
+.
+.
+    ]]>
+  
+  
+    It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST NOT possess a 'type' attribute; the service MAY ignore or reject invites that possess a 'type' attribute):
+    
+  
+    
+      
+        Hey Hecate, this is the place for all good witches!
+      
+    
+  
+
+    ]]>
+    The &ROOM; itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID (or, optionally, the room JID) of the invitor and send the invitation to the invitee captured in the 'to' address (the service SHOULD include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):
+    
+  You have been invited to darkcave@macbeth by crone1@shakespeare.lit.
+  
+    
+      
+        Hey Hecate, this is the place for all good witches!
+      
+    
+    cauldronburn
+  
+
+    ]]>
+    If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the Modifying the Member List section of this document.)
+    If the invitor supplies a non-existent JID, the room SHOULD return an ¬found; error to the invitor.
+    The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOM; itself:
+
+    
+  
+    
+      
+        Sorry, I'm too busy right now.
+      
+    
+  
+
+    ]]>
+    
+  
+    
+      
+        Sorry, I'm too busy right now.
+      
+    
+  
+
+    ]]>
+    It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.
+  
+  
+    Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process flow is shown in the following examples.
+    First, two users begin a one-to-one chat.
+    
+  Thrice the brinded cat hath mew'd.
+
+
+
+  Thrice and once the hedge-pig whined.
+
+    ]]>
+    Now the first person decides to include a third person in the discussion, so she (or, more precisely, her client) does the following:
+    
+      Creates a new room
+      Optionally sends history of the one-to-one chat to the room
+      Sends an invitation to the second person and the third person, including a <continue/> flag. 
+    
+    Note: The new room SHOULD be non-anonymous, MAY be an instant room as specified in the Creating an Instant Room section of this document, and MAY have a unique room name received from the service as specified in the Requesting a Unique Room Name section of this document.
+    
+  
+
+
+
+  
+    
+  
+
+    ]]>
+    
+  Thrice the brinded cat hath mew'd.
+  
+
+
+
+  Thrice and once the hedge-pig whined.
+  
+
+    ]]>
+    Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute). The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.
+    
+  
+    
+      This coven needs both wiccarocks and hag66.
+      
+    
+    
+      This coven needs both wiccarocks and hag66.
+      
+    
+  
+
+    ]]>
+    Note: Since the invitor's client knows the full JID of the person with whom the invitor was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in the invitation.
+    The invitations are delivered to the invitees:
+    
+    to='wiccarocks@shakespeare.lit/laptop'>
+  
+    
+      This coven needs both wiccarocks and hag66.
+      
+    
+  
+
+
+
+    to='hag66@shakespeare.lit'>
+  
+    
+      This coven needs both wiccarocks and hag66.
+      
+    
+  
+
+    ]]>
+    When the client being used by <wiccarocks@shakespeare.lit/laptop> receives the invitation, it SHOULD auto-join the room or prompt the user whether to join (subject to user preferences) and then seamlessly convert the existing one-to-one chat window into a multi-user conferencing window:
+    
+  
+
+
+
+  
+    
+  
+
+
+
+  
+    
+  
+
+
+
+  Thrice the brinded cat hath mew'd.
+  
+
+
+
+  Thrice and once the hedge-pig whined.
+  
+
+    ]]>
+    Note: The fact that the messages come from the &ROOM; itself rather than &ROOMJID; is a clue to the receiving client that these messages are prior chat history, since any message from a room occupant will have a 'from' address equal to the sender's room JID.
+  
+  
+    If allowed in accordance with room configuration, a mere occupant MAY be allowed to change the subject in a room. For details, see the Modifying the Room Subject section of this document.
+  
+  
+    Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).
+    
+  I'll give thee a wind.
+
+    ]]>
+    The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.
+    
+  I'll give thee a wind.
+
+    ]]>
+    If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:
+    
+  I'll give thee a wind.
+
+
+
+  I'll give thee a wind.
+  
+    
+  
+
+    ]]>
+    If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an ¬found; error to the sender.
+    If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.
+  
+  
+    An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the &ROOM; itself (a service MAY ignore or reject messages that do not have a type of "groupchat"). In a moderated room, this privilege is restricted to occupants with a role of participant or higher.
+    
+  Harpier cries: 'tis time, 'tis time.
+
+    ]]>
+    If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.
+    
+  Harpier cries: 'tis time, 'tis time.
+
+
+  Harpier cries: 'tis time, 'tis time.
+
+
+  Harpier cries: 'tis time, 'tis time.
+
+    ]]>
+    If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a ¬acceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.
+  
+  
+    An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). In particular, it is not possible to join a members-only room without being on the member list, so an entity may need to request membership in order to join such a room.
+    If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &jep0077;:
+    
+  
+
+    ]]>
+    If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in JEP-0077. If the room does not exist, the service MUST return an ¬found; error.
+    Otherwise, the room MUST then return a Data Form to the user (as described in &jep0004;). The information required to register MAY vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:
+    
+  
+    
+      To register on the web, visit http://shakespeare.lit/
+    
+    
+      Dark Cave Registration
+      
+        Please provide the following information
+        to register with this room.
+      
+      
+        http://jabber.org/protocol/muc#register
+      
+      
+        
+      
+      
+        
+      
+      
+        
+      
+      
+      
+      
+    
+  
+
+    ]]>
+    The user SHOULD then submit the form:
+    
+  
+    
+      
+        http://jabber.org/protocol/muc#register
+      
+      
+        Brunhilde
+      
+      
+        Entwhistle-Throckmorton
+      
+      
+        thirdwitch
+      
+      
+        http://witchesonline/~hag66/
+      
+      
+        hag66@witchesonline
+      
+      
+        Just another witch.
+      
+    
+  
+
+    ]]>
+    If the desired room nickname is already reserved for that room, the room MUST return a &conflict; error to the user:
+    
+  
+    
+  
+
+    ]]>
+    If the room or service does not support registration, it MUST return a &unavailable; error to the user:
+    
+  
+    
+  
+
+    ]]>
+    If the user did not include a valid data form, the room MUST return a &badrequest; error to the user:
+    
+  
+    
+  
+
+    ]]>
+    Otherwise, the room MUST inform the user that the registration request was successfully received:
+    
+    ]]>
+    After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document) or MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member". If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".
+    
+  
+    
+  
+
+.
+.
+.
+    ]]>
+    If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a ¬acceptable; error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).
+  
+  
+    A user MAY have a reserved room nickname, for example through explicit room registration, database integration, or nickname "lockdown". A user SHOULD discover his or her reserved nickname before attempting to enter the room. This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".
+    
+  
+
+    ]]>
+    It is OPTIONAL for a multi-user chat service to support the foregoing service discovery node. If the room or service does not support the foregoing service discovery node, it MUST return a &feature; error to the user. If it does and the user has a registered nickname, it MUST return the nickname to the user as the value of the 'name' attribute of a Service Discovery <identity/> element (for which the category/type SHOULD be "conference/text"):
+    
+  
+    
+  
+
+    ]]>
+    If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with JEP-0030).
+    Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a ¬acceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as described above.
+    If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.
+  
+  
+    It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where data form contains only a 'muc#role' field with a value of "participant".
+    
+  
+    
+      http://jabber.org/protocol/muc#request
+    
+    
+      participant
+    
+  
+
+    ]]>
+    The service then SHOULD forward the request to the room moderator(s) as described in the Approving Voice Requests section of this document.
+  
+
+
+  A moderator has privileges to perform certain actions within the room (e.g., to change the roles of some occupants) but does not have rights to change persistent information about affiliations (which may be changed only by an admin or owner) or defining information about the room. Exactly which actions may be performed by a moderator is subject to configuration. However, for the purposes of the MUC framework, moderators are stipulated to have privileges to perform the following actions:
+  
+    discover an occupant's full JID in a semi-anonymous room (occurs by default as shown above)
+    modify the subject
+    kick a participant or visitor from the room
+    grant or revoke voice in a moderated room
+    modify the list of occupants who have voice in a moderated room
+  
+  These features shall be implemented with a request/response exchange using <iq/> elements that contain children qualified by the 'http://jabber.org/protocol/muc#admin' namespace. The examples below illustrate the protocol interactions to implement the desired functionality. (Except where explicitly noted below, any of the following administrative requests MUST be denied if the <user@host> of the 'from' address of the request does not match the bare JID portion of one of the moderators; in this case, the service MUST return a &forbidden; error.)
+  
+    A common feature of multi-user chat rooms is the ability to change the subject within the room. By default, only users with a role of "moderator" SHOULD be allowed to change the subject in a room (although this SHOULD be configurable, with the result that a mere participant or even visitor may be allowed to change the subject if desired). The subject is changed by sending a message of type "groupchat" to the &ROOM;, containing no body but a <subject/> that specifies the new subject:
+    
+  Fire Burn and Cauldron Bubble!
+
+    ]]>
+    If a MUC service receives such a message, it MUST reflect the message to all other occupants with a 'from' address equal to the room JID that corresponds to the sender of the subject change:
+    
+  Fire Burn and Cauldron Bubble!
+
+.
+.
+.
+    ]]>
+    In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room.
+    A MUC client that receives such a message MAY choose to display an in-room message, such as the following:
+    
+    If someone without appropriate privileges attempts to change the room subject, the service MUST return a message of type "error" specifying a &forbidden; error condition:
+    
+  Fire Burn and Cauldron Bubble!
+  
+    
+  
+
+    ]]>
+  
+  
+    A moderator has permissions kick certain kinds of occupants from a room (which occupants are "kickable" depends on service provisioning, room configuration, and the moderator's affiliation -- see below). The kick is normally performed based on the occupant's room nickname (though it MAY be based on the full JID) and is completed by setting the role of a participant or visitor to a value of "none".
+    
+  
+    
+      Avaunt, you cullion!
+    
+  
+
+    ]]>
+    The service MUST remove the kicked occupant by sending a presence stanza of type "unavailable" to each kicked occupant, including status code 307 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the kick.
+    
+  
+    
+      
+      Avaunt, you cullion!
+    
+    
+  
+
+    ]]>
+    The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the kicked user to understand why he or she was kicked, and by whom if the kicked occupant would like to discuss the matter. Some commentors have complained that this opens room owners and administrators up to potential abuse; unfortunately, with great power comes great responsibility.
+    After removing the kicked occupant(s), the service MUST then inform the moderator of success:
+    
+    ]]>
+    After informing the moderator, the service MUST then inform all of the remaining occupants that the kicked occupant is no longer in the room by sending presence stanzas of type "unavailable" from the individual's roomnick (&ROOMJID;) to all the remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor.
+    
+  
+    
+    
+  
+
+.
+.
+.
+    ]]>
+    A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a participant attempts to kick an admin or a moderator who is a participant or admin attempts to kick an owner, the service MUST deny the request and return a ¬allowed; error to the sender:
+    
+  
+    
+      Be gone!
+    
+  
+  
+    
+  
+
+    ]]>
+    If a moderator attempts to kick himself, the service MAY deny the request and return a &conflict; error to the sender. (Although the act of kicking oneself may seem odd, it is common in IRC as a way of apologizing for one's actions in the room.)
+  
+  
+    In a moderated room, a moderator may want to manage who does and does not have "voice" in the room (i.e., the ability to send messages to all occupants). Voice is granted based on the visitor's room nickname, which the service will convert into the visitor's full JID internally. The moderator grants voice to a visitor by changing the visitor's role to "participant" (the <reason/> element is optional):
+    
+  
+    
+      A worthy witch indeed!
+    
+  
+
+    ]]>
+    The service MUST then inform the moderator of success:
+    
+    ]]>
+    The service MUST then send updated presence from this individual's &ROOMJID; to all occupants, indicating the addition of voice privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".
+    
+  
+    
+      A worthy witch indeed!
+    
+  
+
+.
+.
+.
+    ]]>
+  
+  
+    In a moderated room, a moderator may want to revoke a participant's privileges to speak. The moderator can revoke voice from a participant by changing the participant's role to "visitor":
+    
+  
+    
+  
+
+    ]]>
+    The service MUST then inform the moderator of success:
+    
+    ]]>
+    The service MUST then send updated presence from this individual to all occupants, indicating the removal of voice privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "visitor".
+    
+  
+    
+  
+
+.
+.
+.
+    ]]>
+    A moderator MUST NOT be able to revoke voice from a user whose affiliation is at or above the moderator's level. In addition, a service MUST NOT allow the voice privileges of an admin or owner to be removed by anyone. If a moderator attempts to revoke voice privileges from such a user, the service MUST deny the request and return a ¬allowed; error to the sender along with the offending item(s):
+    
+  
+    
+  
+  
+    
+  
+
+    ]]>
+  
+  
+    A moderator in a moderated room may want to modify the voice list. To do so, the moderator first requests the voice list by querying the room for all occupants with a role of 'participant'.
+    
+  
+    
+  
+
+    ]]>
+    The service MUST then return the voice list to the moderator; each item MUST include the 'nick' and 'role' attributes and SHOULD include the 'affiliation' and 'jid' attributes:
+    
+  
+    
+    
+    
+  
+
+    ]]>
+    The moderator MAY then modify the voice list. In order to do so, the moderator MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'nick' attribute and 'role' attribute (normally set to a value of "participant" or "visitor") but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as owner rather than the participant role):
+    
+  
+    
+    
+      A worthy fellow.
+    
+    
+      A worthy fellow.
+    
+  
+
+    ]]>
+    The service MUST then inform the moderator of success:
+    
+    ]]>
+    The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in voice privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.
+    As noted, voice privileges cannot be revoked from a room owner or room admin, nor from any user with a higher affiliation than the moderator making the request. If a room admin attempts to revoke voice privileges from such a user by modifying the voice list, the service MUST deny the request and return a ¬allowed; error to the sender:
+    
+  
+    
+  
+  
+    
+  
+
+    ]]>
+  
+  
+    As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). To do so, the service SHOULD send a &MESSAGE; stanza to the room moderator(s), where the &MESSAGE; stanza contains a data form asking for approval or denial of the request, as shown below.
+    
+  
+    Voice request
+    
+      To approve this request for voice, select 
+      the "Grant voice to this person?"
+      checkbox and click OK. To skip this request, 
+      click the cancel button.
+    
+    
+        http://jabber.org/protocol/muc#request
+    
+    
+      participant
+    
+    
+      false
+    
+  
+
+    ]]>
+    In order to approve the request, a moderator shall submit the form:
+    
+  
+    
+        http://jabber.org/protocol/muc#request
+    
+    
+      participant
+    
+    
+      true
+    
+  
+
+

Category	Type	Description
application/		Specific applications running as a resource on a user@host
	bot	Automated conversations
	calendar	Calendaring and scheduling service
	editor	Collaborative editor
	fileserver	Available files
	game	Multi-player game
	whiteboard	Whiteboard tool
conference/		Nodes of this category provide multi-user chat facilities (a.k.a. conference rooms).
	irc	IRC rooms (note: this enables Jabber users to connect to Internet Relay Chat rooms)
	list	Mailing-list-style conferences
	private	Private, dynamically-generated conference rooms
	public	Public, permanent conference rooms
	topic	Topic-based conferences
	url	Website-hosted conferences
headline/		Recognize different sources of headlines, GUI hints
	logger	Log messages (usually presented in a scrolling GUI)
	notice	Alerts and warnings (usually presented as popup messages)
	rss	Rich Site Summary syndication
	stock	Stock market information by symbol (ticker)
keyword/		Keyword-based lookup services (search engines, etc.)
	dictionary	Dictionary lookup service
	dns	DNS resolver
	software	Software search
	thesaurus	Thesaurus lookup service
	web	Web search
	whois	Whois query service
render/		Automated translation services
	en2fr	English to French
	2	Other language to language (using standard language codes)
	tts	Text to Speech
service/		Nodes of this category provide a link to another Instant Messaging network or messaging gateway. The 'jabber:iq:register' namespace can be used to gain access to such networks, and the 'jabber:iq:search' namespace may also be available.
	aim	AIM transport
	icq	ICQ transport
	irc	IRC gateway (note: this enables IRC users to connect to Jabber)
	jabber	A Jabber server which conforms to the specification for the 'jabber:client' namespace
	jud	Jabber User Directory
	msn	MSN transport
	pager	Pager gateway
	serverlist	A list of servers. It is assumed that this node has service/* children
	sms	SMS gateway
	smtp	SMTP gateway
	yahoo	Yahoo! transport
user/		Nodes of this category are Jabber users, typically implementing enough of the 'jabber:client' namespace to be compliant.
	client	A standard or fully-featured Jabber client compliant with the 'jabber:client' namespace
	forward	A forward alias
	inbox	An alternate inbox
	portable	A portable device implementing some of the 'jabber:client' namespace
	voice	A node providing phone or voice access
validate/		Validation services
	grammar	Grammar-checking tool
	spell	Spell-checking tool
	xml	XML validator

Type	Description
message-list	The node for the offline message queue; valid only for the node "http://jabber.org/protocol/offline".
message-node	A node for a specific offline message if service discovery is provided for messages.

Identifier	Purpose
identifier	+ To uniquely identify the session server-side. This field is only + used to identify the session, and provides no security. +
key	+ To verify this request is from the originator of the session. The + client generates a new key in the manner described below for each + request, which the server then verifies before processing the + request. +
new_key	+ The key algorithm can exhaust valid keys in a sequence, which + requires a new key sequence to be used in order to continue the + session. The new key is sent along with the last used key in the + old sequence. +
xml_body	+ The body of text to send. Since a POST must be sent in order for + the server to respond with recent messages, a client may send + a request without an xml_body in order to just retrieve new + incoming packets. This is not required to be a full XML document or + XML fragment, it does not need to start or end on element boundaries. +

Condition	Cause
&feature;	The sender has attempted to publish items but the server does not support the Publishing Available Items feature.
¬found;	The JID or JID+NodeID of the specified target entity does not exist and that fact can be divulged in accordance with privacy and security considerations and policies.
&unavailable;	The target entity does not support this protocol, or the specified target entity does not exist but that fact cannot be divulged because of pricacy and security considerations.

XMPP Condition	Purpose
<forbidden/>	The sending user does not have permission to use this multicast service.
<jid-malformed/>	A URI attribute was invalid or not understood (note that support for the 'uri' attribute is optional).
<not-acceptable/>	Too many receiver fields were specified. Servers MAY have configurable limits for this, but the limit MUST be at least 50.

Code	Message	Description
405	Method Not Allowed	Attempt at reconnect to relay without existing credentials, relay still connected, <peer/> block present in reconnect request, or feature not supported
504	Gateway Timeout	All destination DSPS are unreachable.

Code	Message	Description
401	Unauthorized	(optional) Returned if the DSPS is not aware of said Client_full_JID + DSPS_full_JID pair. Where "from" contains DSPS_full_JID that was used in the handshake and "to" contains Client_full_JID that was used in the handshake.
409	Conflict	(optional) Returned if connection from said full client JID and full DSPS JID is in use (i.e. client is still connected to it). Where "from" contains DSPS_full_JID that was used in the handshake and "to" contains Client_full_JID that was used in the handshake.

Code	String	Reason
401	Unauthorized	Querying JID is not + authorized to perform that query
404	Not Found	The statistic was not + found for some reason
501	Not Implemented	Although statistic + is advertised as available it has not been implemented
503	Service Unavailable	Statistic is + temporarily unavailable

Stat	Description	Returned Units
time/uptime	uptime of component or + server	Seconds
bandwidth/packets-in	packets received by component or server	packets
bandwidth/packets-out	packets transmitted by component or server	packets

Code	Description
`INIT`	Initiation
`GOOD`	Successful initiation (connected)
`BAD`	Unsuccessful initiation (stream is closed, no further state)
`CLOS`	Successful closure after establishment (stream is closed, no further state)
`ERR`	Link failure after establishment (stream is closed, no further state)

Term	Description
OOB	Out-Of-Band. Any network connection that exists outside of the normal Jabber protocol traffic.
session	A session registered with a "server" for clients to connect to.
client	An end-point on a JOBS session.
service	The JOBS Jabber component/server.
server	A particular host/port of the JOBS service.
sender	The client sending data.
receiver	A client receiving data.

Value	Description
authenticate	Authenticating one or more connections.
authorize	Authorizing one or more connections.
create	Create a new session.
delete	Delete an existing session.
notify	Notification about the session.

Value	Description
active	The session is active, but not yet in use.
closed	The session has closed.
in-use	The session is in use (e.g. data is being transferred).
pending	The session is ready, but not yet active (e.g. not enough connections).

Value	Description	Notes
accept	The item is accepted.	This value MUST only be used when the type is "auth" or "connection".
confirm	The item needs confirmation.	This value MUST only be used when the type is "auth" or "connection".
delete	The item is deleted.	This value MUST only be used when the type is "status".
drop	The item is dropped.	This value MUST only be used when the type is "connection".
expire	The item has expired.	This value MUST only be used when the type is "status".
invite	The item is invited to the session.	This value MUST only be used when the type is "connection".
reject	The item is rejected.	This value MUST only be used when the type is "auth" or "connection".

Value	Description
auth	The item pertains to authentication keys.
connection	The item details a session connection. The CDATA is the JID that is connected.
status	The item details a session status event.

Value	Description
buffer	The buffer size limits. The units for "default", "max", and "min" are bytes.
expires	The expires time limits. The units for "default", "max", and "min" are seconds.
receivers	The receiver count limits. The units for "default", "max", and "min" are number of connections.

Code	Message	Cause
400	Bad Request	The JOBS service did not understand the request.
403	Forbidden	The JOBS service cannot accept the authentication request from the requesting JID.
404	Not Found	The JOBS service could not find the given session.
406	Not Acceptable	The authentication is not valid.

Comand-line (example)	`jobs/0.4 init`
Expected header-fields	+ "session-id" - The JOBS session ID + "client-jid" - The (full) client JID +

Comand-line (example)	`jobs/0.4 auth-challenge`
Expected header-fields	+ confirm - A unique <item type="auth" action="confirm"/> token +

Comand-line (example)	`jobs/0.4 auth-response`
Expected header-fields	+ accept - A unique <item type="auth" action="accept"/> token +

Comand-line (example)	`jobs/0.4 connected`
Expected header-fields	NONE

Comand-line (example)	`jobs/0.4 error`
Expected header-fields	+ error-code - The HTTP-like error code + error-msg - Detailed error message +

Code	Message	Description
399	Invalid Database Name	Returned when the client has requested information from a + database which does not exist according to the component.
398	Invalid Table Name	Returned when the client has requested information from a + table/procedure which does not exist according to the component.
397	Invalid Column Name	Returned when the client has requested information from a + column which does not exist according to the component.
380	Permission Denied on Table	Returned when the requested action is not allowed for the + user on the table
401	Access Denied	Returned when the user does not have permission to use the + component.

Room Nickname	Full JID	Affiliation
firstwitch	crone1@shakespeare.lit/desktop	Owner
secondwitch	wiccarocks@shakespeare.lit/laptop	Admin
thirdwitch	hag66@shakespeare.lit/pda	None

Privilege	None	Visitor	Participant	Moderator
Present in Room	No	Yes	Yes	Yes
Receive Messages	No	Yes	Yes	Yes
Change Availability Status	No	Yes	Yes	Yes
Change Room Nickname	No	Yes*	Yes	Yes
Send Private Messages	No	Yes*	Yes	Yes
Invite Other Users	No	Yes*	Yes*	Yes
Send Messages to All	No	No**	Yes	Yes
Modify Subject	No	No*	Yes*	Yes
Kick Participants and Visitors	No	No	No	Yes
Grant Voice	No	No	No	Yes
Revoke Voice	No	No	No	Yes***

>	None	Visitor	Participant	Moderator
None	--	Enter moderated room	Enter unmoderated room	Admin or owner enters room
Visitor	Exit room or be kicked by a moderator	--	Moderator grants voice	Admin or owner grants moderator privileges
Participant	Exit room or be kicked by a moderator	Moderator revokes voice	--	Admin or owner grants moderator privileges
Moderator	Exit room	Admin or owner changes role to visitor *	Admin or owner changes role to participant or revokes moderator privileges *	--

Privilege	Outcast	None	Member	Admin	Owner
Enter Open Room	No	Yes*	Yes	Yes	Yes
Register with an Open Room	No	Yes	N/A	N/A	N/A
Enter Members-Only Room	No	No	Yes*	Yes	Yes
Ban Members and Unaffiliated Users	No	No	No	Yes	Yes
Edit Member List	No	No	No	Yes	Yes
Edit Moderator List	No	No	No	Yes**	Yes**
Edit Admin List	No	No	No	No	Yes
Edit Owner List	No	No	No	No	Yes
Change Room Definition	No	No	No	No	Yes
Destroy Room	No	No	No	No	Yes

>	Outcast	None	Member	Admin	Owner
Outcast	--	Admin or owner removes ban	Admin or owner adds user to member list	Owner adds user to admin list	Owner adds user to owner list
None	Admin or owner applies ban	--	Admin or owner adds user to member list, or user registers as member (if allowed)	Owner adds user to admin list	Owner adds user to owner list
Member	Admin or owner applies ban	Admin or owner changes affiliation to "none"	--	Owner adds user to admin list	Owner adds user to owner list
Admin	Owner applies ban	Owner changes affiliation to "none"	Owner changes affiliation to "member"	--	Owner adds user to owner list
Owner	Owner applies ban	Owner changes affiliation to "none"	Owner changes affiliation to "member"	Owner changes affiliation to "admin"	--

Room Type	None	Member	Admin	Owner
Moderated	Visitor	Participant	Moderator	Moderator
Unmoderated	Participant	Participant	Moderator	Moderator
Members-Only	N/A *	Participant	Moderator	Moderator
Open	Participant	Participant	Moderator	Moderator

Attribute	Datatype	Meaning
maxchars	int	Limit the total number of characters in the history to "X" (where the character count is the characters of the complete XML stanzas, not only their XML character data).
maxstanzas	int	Limit the total number of messages in the history to "X".
seconds	int	Send only the messages received in the last "X" seconds.
since	dateTime	Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &jep0082;).