moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-23 08:08:53 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@32 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-03 23:03:58 +00:00
parent 86cfa475f3
commit 462ac0b137
10 changed files with 166 additions and 166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0040.xml
View File

@ -1,13 +1,13 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type="text/xsl" href="../jep.xsl"?>
<jep>
<?xml-stylesheet type="text/xsl" href="xep.xsl"?>
<xep>
<header>
<title>Jabber Robust Publish-Subscribe</title>
<abstract>Note: This proposal has been superseded by JEP-0060; please refer to that document for the successor protocol.</abstract>
<abstract>Note: This proposal has been superseded by XEP-0060; please refer to that document for the successor protocol.</abstract>
&LEGALNOTICE;
<number>0040</number>
<status>Retracted</status>
@ -15,7 +15,7 @@
<jig>Standards</jig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0060</supersededby>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
<author>
<firstname>Tim</firstname>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2004-07-26</date>
<initials>psa</initials>
<remark>Formally retracted this proposal in favor of JEP-0060: Publish-Subscribe.</remark>
<remark>Formally retracted this proposal in favor of XEP-0060: Publish-Subscribe.</remark>
</revision>
<revision>
<version>0.1</version>
@ -37,9 +37,9 @@
</revision>
</header>
<section1 topic="Introduction">
<p><em>Note: This JEP has been superseded by &jep0060;; please refer to that document for the successor protocol.</em></p>
<p><em>Note: This XEP has been superseded by &xep0060;; please refer to that document for the successor protocol.</em></p>
<p>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).</p>
<p>Implementation issues in the environment are appended, covering Permissioning and Contributions. Both are likely to require separate JEPs, but need to be constructed sympathetically.</p>
<p>Implementation issues in the environment are appended, covering Permissioning and Contributions. Both are likely to require separate XEPs, but need to be constructed sympathetically.</p>
<p>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.</p>
<section2 topic="Background">
<p>Publish-Subscribe and other messaging environments that exist are often classified as providing one or more of the following three levels of service.</p>
@ -63,7 +63,7 @@
<li>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.</li>
<li>Review the relevant history of thinking within the Jabber community.</li>
</ol>
<p>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 &lt;publish&gt; tag, being a means to identify data much as the namespace or topic does.</p>
<p>JRPS is a layer on Jabber Publish-Subscribe (XEP0024, XEP0036) 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 &lt;publish&gt; tag, being a means to identify data much as the namespace or topic does.</p>
<p>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.</p>
<p>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.</p>
</section2>
@ -264,7 +264,7 @@ channel can be, but is not limited to the following:</p>
<p>Further information on why tokenised grant and deny permissioning is advantageous can be provided upon request.</p></section2>
<section2 topic="Contributions">
<p>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.</p>
<p>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!)</p>
<p>Contributions requires a separate XEP, 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!)</p>
</section2>
</section1>
</jep>
</xep>

32
xep-0041.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Reliable Entity Link</title>
<abstract>Protocol for linking a bytestream between two Jabber entities.</abstract>
@ -13,9 +13,9 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>XMPP Core, JEP-0020, JEP-0030</dependencies>
<dependencies>XMPP Core, XEP-0020, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0065</supersededby>
<supersededby>XEP-0065</supersededby>
<shortname>rel</shortname>
<author>
<firstname>Justin</firstname>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>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.</remark>
<remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
</revision>
<revision>
<version>0.8</version>
@ -125,11 +125,11 @@
</tr>
<tr>
<td>ibb</td>
<td>&jep0047;</td>
<td>&xep0047;</td>
</tr>
<tr>
<td>s5b</td>
<td>&jep0065;</td>
<td>&xep0065;</td>
</tr>
</table>
@ -138,7 +138,7 @@
<section1 topic='Usage'>
<section2 topic='Service discovery'>
<p>Before using REL, ensure it is a supported service of the remote entity by using &jep0030;:</p>
<p>Before using REL, ensure it is a supported service of the remote entity by using &xep0030;:</p>
<example caption='Requesting disco information'><![CDATA[
<iq type="get" to="joe@blow.com/Home" id="sd_1">
@ -146,7 +146,7 @@
</iq>
]]></example>
The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this JEP.
The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.
<example caption='Response'><![CDATA[
<iq type="result" from="joe@blow.com/Home" id="sd_1">
@ -179,7 +179,7 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace
</section2>
<section2 topic='Selecting a Stream'>
<p>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.</p>
<p>The next step is to ask the remote entity which stream method it would like to use. We will use &xep0020; for this. The streams are listed using the short names from the table of supported streams.</p>
<example caption='Selecting a stream'><![CDATA[
<iq type="get" id="rel_1" to="joe@blow.com/Home">
@ -235,11 +235,11 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/rel' namespace as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/rel' namespace as a result of this document.</p>
</section1>
<section1 topic='XML Schema'>
@ -263,4 +263,4 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace
]]></code>
</section1>
</jep>
</xep>

14
xep-0042.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber OOB Broadcast Service (JOBS)</title>
<abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
@ -107,7 +107,7 @@
</section1>
<section1 topic='Use Cases'>
<section2 topic='Discovering the Service'>
<p>Discovering support for JOBS involves either "jabber:iq:browse"<note>jabber:iq:browse -- <link url='http://www.jabber.org/jeps/jep-0011.html'>http://www.jabber.org/jeps/jep-0011.html</link></note> or "disco"<note>http://jabber.org/protocol/disco -- <link url='http://www.jabber.org/jeps/jep-0030.html'>http://www.jabber.org/jeps/jep-0030.html</link></note>. This determines if the end-point understands the JOBS protocol.</p>
<p>Discovering support for JOBS involves either &xep0011; or &xep0030;. This determines if the end-point understands the JOBS protocol.</p>
<section3 topic='"jabber:iq:browse"'>
<p>To determine support for JOBS via jabber:iq:browse, look for an item with a nested &lt;ns/&gt; with a value of "http://jabber.org/protocol/jobs":</p>
<example caption='Browse request'><![CDATA[
@ -225,7 +225,7 @@
<p>Any parameters that exceed the minimums/maximums causes an error.</p>
</section3>
<section3 topic='Form-based'>
<p>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" form<note>jabber:x:data -- <link url='http://www.jabber.org/jeps/jep-0004.html'>http://www.jabber.org/jeps/jep-0004.html</link></note> can be embedded in the &lt;session/&gt;.</p>
<p>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 &xep0004; form can be embedded in the &lt;session/&gt;.</p>
<p>To create a session using forms, send a &lt;session action="create"/&gt; with an embedded &lt;x xmlns="jabber:x:data"/&gt;:</p>
@ -1072,4 +1072,4 @@ BINDATA := <Arbitrary Binary Data>
</section3>
</section2>
</section1>
</jep>
</xep>

10
xep-0043.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Database Access</title>
<abstract>Expose RDBM systems directly to the jabber network</abstract>
@ -790,4 +790,4 @@ name CDATA #IMPLIED
<p><strong>Anyone care to do this?</strong></p>
</section2>
</section1>
</jep>
</xep>

10
xep-0044.xml
View File

@ -1,11 +1,11 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>Full Namespace Support for XML Streams</title>
@ -169,4 +169,4 @@ RECV: <iq type='result' from='jabber.org'>
</section1>
</jep>
</xep>

140
xep-0045.xml
View File

@ -1,12 +1,12 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ROOM "&lt;room@service&gt;">
<!ENTITY ROOMJID "&lt;room@service/nick&gt;">
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Multi-User Chat</title>
<abstract>This document defines an XMPP protocol extension for multi-user text conferencing.</abstract>
@ -18,34 +18,34 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0004</spec>
<spec>JEP-0030</spec>
<spec>JEP-0068</spec>
<spec>JEP-0082</spec>
<spec>JEP-0128</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0068</spec>
<spec>XEP-0082</spec>
<spec>XEP-0128</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>muc</shortname>
<schemaloc>
<ns>muc</ns>
<url>http://jabber.org/protocol/muc/muc.xsd</url>
<url>http://www.xmpp.org/schemas/muc.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#admin</ns>
<url>http://jabber.org/protocol/muc/admin.xsd</url>
<url>http://www.xmpp.org/schemas/muc-admin.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#owner</ns>
<url>http://jabber.org/protocol/muc/owner.xsd</url>
<url>http://www.xmpp.org/schemas/muc-owner.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#unique</ns>
<url>http://jabber.org/protocol/muc/unique.xsd</url>
<url>http://www.xmpp.org/schemas/muc-unique.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#user</ns>
<url>http://jabber.org/protocol/muc/user.xsd</url>
<url>http://www.xmpp.org/schemas/muc-user.xsd</url>
</schemaloc>
<registry/>
&stpeter;
@ -63,7 +63,7 @@
<li>Moved all service discovery use cases into dedicated section.</li>
<li>Changed jabber:x:delay support from SHOULD to MUST.</li>
<li>Clarified that _whois room configuration option specifies room type.</li>
<li>Defined JEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.</li>
<li>Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.</li>
<li>Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.</li>
<li>Added internationalization consideration about localization of field labels for various data forms.</li>
<li>Specified that implementations may persist roles across visits and should do so for moderated rooms.</li>
@ -171,7 +171,7 @@
<version>1.5</version>
<date>2003-09-11</date>
<initials>psa</initials>
<remark><p>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.</p></remark>
<remark><p>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 XEP-0068; defined XMPP Registrar submissions; added schema locations.</p></remark>
</revision>
<revision>
<version>1.4</version>
@ -213,7 +213,7 @@
<version>0.22</version>
<date>2002-11-04</date>
<initials>psa</initials>
<remark><p>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.</p></remark>
<remark><p>Added example for disco#items; added support for cancellation of room configuration using type='cancel' from XEP-0004; noted 403 error for invites sent by non-admins in members-only room.</p></remark>
</revision>
<revision>
<version>0.21</version>
@ -828,7 +828,7 @@
</section2>
</section1>
<section1 topic='Entity Use Cases' anchor='entity'>
<p>A MUC implementation MUST support &jep0030;.</p>
<p>A MUC implementation MUST support &xep0030;.</p>
<section2 topic='Discovering Component Support for MUC' anchor='disco-component'>
<p>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:</p>
<example caption='User Queries Chat Service for MUC Support via Disco'><![CDATA[
@ -884,7 +884,7 @@
</query>
</iq>
]]></example>
<p>If the full list of rooms is large (see <cite>JEP-0030</cite> for details), the service MAY return only a partial list of rooms.</p>
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms.</p>
</section2>
<section2 topic='Querying for Room Information' anchor='disco-roominfo'>
<p>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 <link url='#secrity'>Security Considerations</link> for details).</p>
@ -917,8 +917,8 @@
</query>
</iq>
]]></example>
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a &lt;feature var='gc-1.0'/&gt; 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 <link url='#registrar'>Jabber Registrar</link> section of this document).</p>
<p>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:</p>
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a &lt;feature var='gc-1.0'/&gt; 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 XMPP Registrar; see also the <link url='#registrar'>XMPP Registrar</link> section of this document).</p>
<p>A chatroom MAY return more detailed information in its disco#info response using &xep0128;, 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:</p>
<example caption='Room Returns Extended Disco Info Results'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='disco3a'
@ -1396,7 +1396,7 @@
stamp='20021013T23:58:49'/>
</message>
]]></example>
<p>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.</p>
<p>Discussion history messages MUST be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &xep0091;) 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.</p>
</section3>
<section3 topic='Managing Discussion History' anchor='enter-managehistory'>
<p>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 &lt;history/&gt; child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:</p>
@ -1424,7 +1424,7 @@
<tr>
<td>since</td>
<td>dateTime</td>
<td>Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &jep0082;).</td>
<td>Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &xep0082;).</td>
</tr>
</table>
<p>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).</p>
@ -1933,7 +1933,7 @@
</section2>
<section2 topic='Registering with a Room' anchor='register'>
<p>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.</p>
<p>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;:</p>
<p>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 &xep0077;:</p>
<example caption='User Requests Registration Requirements'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
id='reg1'
@ -1942,8 +1942,8 @@
<query xmlns='jabber:iq:register'/>
</iq>
]]></example>
<p>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 &notallowed; 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 &lt;register/&gt; element as described in <cite>JEP-0077</cite>. If the room does not exist, the service MUST return an &notfound; error.</p>
<p>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 <link url="#registrar-formtype">Field Standardization</link> section of this document). The following can be taken as a fairly typical example:</p>
<p>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 &notallowed; 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 &lt;register/&gt; element as described in <cite>XEP-0077</cite>. If the room does not exist, the service MUST return an &notfound; error.</p>
<p>Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). 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 <link url="#registrar-formtype">Field Standardization</link> section of this document). The following can be taken as a fairly typical example:</p>
<example caption='Service Returns Registration Form'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='reg1'
@ -2114,7 +2114,7 @@
</query>
</iq>
]]></example>
<p>If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with <cite>JEP-0030</cite>).</p>
<p>If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with <cite>XEP-0030</cite>).</p>
<p>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 &notacceptable; 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.</p>
<p>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.</p>
</section2>
@ -2628,7 +2628,7 @@
<li>&lt;domain/resource&gt; (only that resource matches)</li>
<li>&lt;domain&gt; (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)</li>
</ol>
<p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see &jep0133;).</p>
<p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see &xep0133;).</p>
</section2>
<section2 topic='Granting Membership' anchor='grantmember'>
<p>An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):</p>
@ -3049,12 +3049,12 @@
</message>
]]></example>
<p>If the admin approves the registration request, the service shall register the user with the room.</p>
<p>More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &jep0050; as is done in &jep0060;) are out of scope for this document.</p>
<p>More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.</p>
</section2>
</section1>
<section1 topic='Owner Use Cases' anchor='owner'>
<p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <link url='#reqs'>Requirements</link> section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.</p>
<p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>JEP-0004</cite>) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
<p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
<p>Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (profanity filters, setting the default language for a room, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.</p>
<section2 topic='Creating a Room' anchor='createroom'>
<section3 topic='General Considerations' anchor='createroom-general'>
@ -3168,7 +3168,7 @@
<query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>
]]></example>
<p>If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the Jabber Registrar; see the <link url="#registrar">Jabber Registrar Considerations</link> section of this document.)</p>
<p>If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the XMPP Registrar; see the <link url="#registrar">XMPP Registrar Considerations</link> section of this document.)</p>
<example caption='Service Sends Configuration Form'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='create1'
@ -4061,7 +4061,7 @@
</section1>
<section1 topic='Error and Status Codes' anchor='errorstatus'>
<section2 topic='Error Codes' anchor='errorcodes'>
<p>The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &jep0086;; implementations SHOULD support both legacy and XMPP error handling.</p>
<p>The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &xep0086;; implementations SHOULD support both legacy and XMPP error handling.</p>
<table caption='Error Codes for http://jabber.org/protocol/muc#user Namespace'>
<tr>
<th>Code</th>
@ -4130,7 +4130,7 @@
<p>This document does not stipulate text strings (i.e., values of the XMPP &lt;text/&gt; element) associated with the foregoing error conditions.</p>
</section2>
<section2 topic='Status Codes' anchor='statuscodes'>
<p>Multi-User Chat uses a &lt;status/&gt; element (specifically, the 'code' attribute of the &lt;status/&gt; element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the JEP author. Therefore, these codes are now documented in a registry maintained by the Jabber Registrar. For details, refer to the <link url='#registrar-statuscodes'>Status Codes Registry</link> section of this document.</p>
<p>Multi-User Chat uses a &lt;status/&gt; element (specifically, the 'code' attribute of the &lt;status/&gt; element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the author. Therefore, these codes are now documented in a registry maintained by the XMPP Registrar. For details, refer to the <link url='#registrar-statuscodes'>Status Codes Registry</link> section of this document.</p>
<p>Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in &rfc2616; and &rfc1893; (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).</p>
<p>Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in <cite>RFC 3920</cite>.</p>
</section2>
@ -4155,12 +4155,12 @@
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; includes the following information in its registries.</p>
<section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
<p>The Jabber Registrar includes the following MUC-related namespaces in its registry of protocol namespaces:</p>
<p>The XMPP Registrar includes the following MUC-related namespaces in its registry of protocol namespaces:</p>
<ul>
<li>http://jabber.org/protocol/muc</li>
<li>http://jabber.org/protocol/muc#admin</li>
@ -4178,82 +4178,82 @@
<var>
<name>http://jabber.org/protocol/muc#register</name>
<desc>Support for the muc#register FORM_TYPE</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>http://jabber.org/protocol/muc#roomconfig</name>
<desc>Support for the muc#roomconfig FORM_TYPE</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>http://jabber.org/protocol/muc#roominfo</name>
<desc>Support for the muc#roominfo FORM_TYPE</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_hidden</name>
<desc>Hidden room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_membersonly</name>
<desc>Members-only room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_moderated</name>
<desc>Moderated room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_nonanonymous</name>
<desc>Non-anonymous room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_open</name>
<desc>Open room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_passwordprotected</name>
<desc>Password-protected room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_persistent</name>
<desc>Persistent room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_public</name>
<desc>Public room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_rooms</name>
<desc>List of MUC rooms (each as a separate item)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_semianonymous</name>
<desc>Semi-anonymous room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_temporary</name>
<desc>Temporary room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_unmoderated</name>
<desc>Unmoderated room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
<var>
<name>muc_unsecured</name>
<desc>Unsecured room in Multi-User Chat (MUC)</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
</var>
]]></code>
</section2>
@ -4263,12 +4263,12 @@
<p>The well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are three uses of such forms: room registration within muc#user, room configuration within muc#owner, and service discovery extensions for room information. The reserved fields are defined below.</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are three uses of such forms: room registration within muc#user, room configuration within muc#owner, and service discovery extensions for room information. The reserved fields are defined below.</p>
<section3 topic='muc#register FORM_TYPE' anchor='registrar-formtype-register'>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/muc#register</name>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
<desc>
Forms enabling user registration with a
Multi-User Chat (MUC) room or admin approval
@ -4309,7 +4309,7 @@
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/muc#roomconfig</name>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
<desc>
Forms enabling creation and configuration of
a Multi-User Chat (MUC) room.
@ -4393,7 +4393,7 @@
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/muc#roominfo</name>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
<desc>
Forms enabling the communication of extended service discovery
information about a Multi-User Chat (MUC) room.
@ -4428,7 +4428,7 @@
</section2>
<section2 topic='Status Codes Registry' anchor='registrar-statuscodes'>
<section3 topic='Process' anchor='registrar-statuscodes-process'>
<p>The Jabber Registrar maintains a registry of values for the 'code' attribute of the &lt;status/&gt; element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p>
<p>The XMPP Registrar maintains a registry of values for the 'code' attribute of the &lt;status/&gt; element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p>
&REGPROCESS;
<code><![CDATA[
<statuscode>
@ -4566,7 +4566,7 @@
</section3>
</section2>
<section2 topic='URI Query Types' anchor='registrar-querytypes'>
<p>As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<section3 topic='join' anchor='registrar-querytypes-join'>
<p>The "join" querytype is registered as a MUC-related action, with an optional key of "password".</p>
<example caption='Join Action: IRI/URI'><![CDATA[
@ -4595,7 +4595,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?join;password=cauldronburn
<name>join</name>
<proto>http://jabber.org/protocol/muc</proto>
<desc>enables joining a multi-user chat room</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
<keys>
<key>
<name>password</name>
@ -4658,7 +4658,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<name>invite</name>
<proto>http://jabber.org/protocol/muc</proto>
<desc>enables simultaneously joining a groupchat room and inviting others</desc>
<doc>JEP-0045</doc>
<doc>XEP-0045</doc>
<keys>
<key>
<name>jid</name>
@ -4684,7 +4684,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<li><p>If a MUC service receives a message directed to the room or to a single occupant from a Jabber user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.</p></li>
<li><p>If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an &notfound; error.</p></li>
<li><p>A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A MUC client MAY generate extensions that conform to the &jep0022; or &jep0085; specification; however, a MUC service MAY disallow these extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
</ol>
</section2>
<section2 topic='Presence' anchor='bizrules-presence'>
@ -4713,7 +4713,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<p>The following guidelines may assist client and component developers in creating MUC implementations.</p>
<section2 topic='Services' anchor='impl-service'>
<ol start='1'>
<li><p>In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in <cite>JEP-0004</cite>) is out of scope for this document.</p></li>
<li><p>In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in <cite>XEP-0004</cite>) is out of scope for this document.</p></li>
<li><p>It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (&ROOM;) rather than a specific occupant (&ROOMJID;). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room &lt;message/&gt; to an occupant who is kicked or banned, and MAY broadcast an in-room &lt;message/&gt; to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room &lt;message/&gt; if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a &lt;body/&gt; element describing the affiliation change, and MUST contain a status code of 101.</p></li>
@ -4724,11 +4724,11 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
<li><p>A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (remote server unreachable, user not found, etc.).</p></li>
<li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the &lt;show/&gt;, &lt;status/&gt;, and &lt;priority/&gt; child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &jep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked down nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
</ol>
<section3 topic='Allowable Traffic' anchor='impl-service-traffic'>
<p>As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one &lt;feature/&gt; element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in <cite>JEP-0030</cite>. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.</p>
<p>As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one &lt;feature/&gt; element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in <cite>XEP-0030</cite>. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.</p>
<p>The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces.</p>
<example caption='User Queries Service Regarding Allowable Namespaces'><![CDATA[
<iq from='wiccarocks@shakespeare.lit/laptop'
@ -4890,7 +4890,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0045: http://www.jabber.org/jeps/jep-0045.html
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
@ -4938,7 +4938,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0045: http://www.jabber.org/jeps/jep-0045.html
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
@ -5063,7 +5063,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0045: http://www.jabber.org/jeps/jep-0045.html
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
@ -5141,7 +5141,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0045: http://www.jabber.org/jeps/jep-0045.html
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
@ -5190,7 +5190,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0045: http://www.jabber.org/jeps/jep-0045.html
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
@ -5203,4 +5203,4 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.</p>
</section1>
</jep>
</xep>

14
xep-0046.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>DTCP</title>
<abstract>Direct TCP connection between two Jabber entities.</abstract>
@ -15,7 +15,7 @@
<jig>Standards</jig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0065</supersededby>
<supersededby>XEP-0065</supersededby>
<shortname>None</shortname>
<author>
<firstname>Justin</firstname>
@ -27,7 +27,7 @@
<version>0.8</version>
<date>2003-04-11</date>
<initials>psa</initials>
<remark>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.</remark>
<remark>At the request of the author, changed status to Retracted. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
</revision>
<revision>
<version>0.7</version>
@ -213,4 +213,4 @@
</section1>
</jep>
</xep>

30
xep-0047.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>In-Band Bytestreams (IBB)</title>
<abstract>This JEP defines a protocol for bytestreaming data in band between any two entities over Jabber/XMPP.</abstract>
<abstract>This document defines an XMPP protocol extension for bytestreaming data in band between any two entities over Jabber/XMPP.</abstract>
&LEGALNOTICE;
<number>0047</number>
<status>Draft</status>
@ -15,12 +15,12 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0079</spec>
<spec>XEP-0079</spec>
</dependencies>
<supersedes/>
<supersededby/>
<schemaloc>
<url>http://jabber.org/protocol/ibb/ibb.xsd</url>
<url>http://www.xmpp.org/schemas/ibb.xsd</url>
</schemaloc>
<shortname>ibb</shortname>
&infiniti;
@ -40,7 +40,7 @@
<version>0.7</version>
<date>2003-05-23</date>
<initials>jk</initials>
<remark>Use IQ for shutdown, remove JEP-0022 dependency, loop the counter</remark>
<remark>Use IQ for shutdown, remove XEP-0022 dependency, loop the counter</remark>
</revision>
<revision>
<version>0.6</version>
@ -85,7 +85,7 @@
</section1>
<section1 topic='Uses'>
<p>IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &jep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.</p>
<p>IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &xep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.</p>
</section1>
<section1 topic='Implementation'>
@ -129,7 +129,7 @@
</section2>
<section2 topic='Sending data'>
<p>Data is sent using message stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the message stanza, must be no larger than the 'block-size' determined in the stream negotiation. All packets are to be addressed to the FULL JID of the bytestream peer. In order to keep track of stanzas sent and any errors received, the sender SHOULD include the 'id' attribute on stanzas sent to the recipient. Note that &jep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.</p>
<p>Data is sent using message stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the message stanza, must be no larger than the 'block-size' determined in the stream negotiation. All packets are to be addressed to the FULL JID of the bytestream peer. In order to keep track of stanzas sent and any errors received, the sender SHOULD include the 'id' attribute on stanzas sent to the recipient. Note that &xep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.</p>
<example caption='Sending data'><![CDATA[
<message from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony' id='msg1'>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
@ -220,12 +220,12 @@
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<section2 topic='Protocol Namespaces'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/ibb' namespace as a result of this JEP.</p>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/ibb' namespace as a result of this document.</p>
</section2>
</section1>
@ -242,7 +242,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0047: http://www.jabber.org/jeps/jep-0047.html
XEP-0047: http://www.xmpp.org/extensions/xep-0047.html
</xs:documentation>
</xs:annotation>
@ -288,4 +288,4 @@
]]></code>
</section1>
</jep>
</xep>

30
xep-0048.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Bookmark Storage</title>
<abstract>This specification documents a protocol for the storage of bookmarks to conference rooms and other entities in a Jabber user's account.</abstract>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0049</spec>
<spec>XEP-0049</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>bookmarks</shortname>
<schemaloc>
<url>http://jabber.org/protocol/bookmarks/bookmarks.xsd</url>
<url>http://www.xmpp.org/schemas/bookmarks.xsd</url>
</schemaloc>
<author>
<firstname>Rachel</firstname>
@ -56,8 +56,8 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and webpages) as 'bookmarks' which can be displayed in the user's client. Several Jabber clients have already agreed on and implemented a method to provide this service; that informal agreement is documented and expanded upon in this JEP.</p>
<p>&jep0049; provides us with a convenient method for storing user data on the server using jabber:iq:private; all we need to do is define a namespace and schema for storing this sort of information. To this end, we introduce the 'storage' element, and the 'storage:bookmarks' to handle this data.</p>
<p>For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and webpages) as 'bookmarks' which can be displayed in the user's client. Several Jabber clients have already agreed on and implemented a method to provide this service; that informal agreement is documented and expanded upon in this document.</p>
<p>&xep0049; provides us with a convenient method for storing user data on the server using jabber:iq:private; all we need to do is define a namespace and schema for storing this sort of information. To this end, we introduce the 'storage' element, and the 'storage:bookmarks' to handle this data.</p>
</section1>
<section1 topic='The storage:bookmarks Namespace'>
<p>A storage element marked by the storage:bookmarks namespace will contain a collection of child elements, each representing a 'bookmark' to be displayed in the client. At present, only two sub-elements are defined, 'conference' for conference rooms and 'url' for normal URLs.</p>
@ -80,7 +80,7 @@
</section2>
<section2 topic='The conference element'>
<p>One of the most common uses of bookmarks will likely be to bookmark conference rooms on various Jabber servers. It is this aspect of the bookmark system which is used today by existing clients such as Exodus <note>Exodus, see &lt;<link url='http://exodus.jabberstudio.org/'>http://exodus.jabberstudio.org/</link>&gt;.</note> and Rival Messenger <note>Rival Messenger, see &lt;<link url='http://rival.chote.net'>http://rival.chote.net/</link>&gt;.</note>. In addition to the required 'jid' attribute, the conference element also possesses an 'autojoin' attribute, which determines whether or not the client should automatically join that conference room on login; this attribute is of type xs:boolean (see &w3xmlschema2;) and the default value is "false". &BOOLEANNOTE;</p>
<p>The conference element MAY also contain 'nick' and 'password' sub-elements; the XML character data from these elements should be used when joining the room from the bookmark. Password is, of course, important for joining potentially password-protected &jep0045; rooms.</p>
<p>The conference element MAY also contain 'nick' and 'password' sub-elements; the XML character data from these elements should be used when joining the room from the bookmark. Password is, of course, important for joining potentially password-protected &xep0045; rooms.</p>
<example caption='An example of the conference element'><![CDATA[
<iq type='result' id='2'>
<query xmlns='jabber:iq:private'>
@ -99,13 +99,13 @@
</section2>
</section1>
<section1 topic='Security Considerations'>
<p>Security considerations related to private XML storage are described in JEP-0049.</p>
<p>Security considerations related to private XML storage are described in XEP-0049.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -120,7 +120,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0048: http://www.jabber.org/jeps/jep-0048.html
XEP-0048: http://www.xmpp.org/extensions/xep-0048.html
</xs:documentation>
</xs:annotation>
@ -168,4 +168,4 @@
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 1.0, died on April 26, 2006.</p>
</section1>
</jep>
</xep>

28
xep-0049.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Private XML Storage</title>
<abstract>This specification provides canonical documentation of the 'jabber:iq:private' namespace currently in common usage.</abstract>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>iq-private</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-private/iq-private.xsd</url>
<url>http://www.xmpp.org/schemas/iq-private.xsd</url>
</schemaloc>
&stpeter;
<author>
@ -39,7 +39,7 @@
<version>1.1</version>
<date>2004-01-06</date>
<initials>psa</initials>
<remark>Added XML schema; specified XMPP error handling; added security, IANA, and Jabber Registrar considerations.</remark>
<remark>Added XML schema; specified XMPP error handling; added security, IANA, and XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>1.0</version>
@ -80,11 +80,11 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The 'jabber:iq:private' namespace has previously been documented in the Jabber Programmers Guide, but not in a canonical form such as the Internet-Drafts or a JEP. This specification documents the existing usage of jabber:iq:private.</p>
<p>The 'jabber:iq:private' namespace has previously been documented in the Jabber Programmers Guide, but not in a canonical form such as the Internet-Drafts or a XEP. This specification documents the existing usage of jabber:iq:private.</p>
</section1>
<section1 topic='jabber:iq:private Namespace'>
<section2 topic='Description'>
<p>A Jabber client can store any arbitrary XML on the server side by sending an &IQ; stanza of type "set" to the server with a &QUERY; child scoped by the 'jabber:iq:private' namespace. The &QUERY; element MAY contain any arbitrary XML fragment as long as the root element of that fragment is scoped by its own namespace. The data can then be retrieved by sending an &IQ; stanza of type "get" with a &QUERY; child scoped by the 'jabber:iq:private' namespace, which in turn contains a child element scoped by the namespace used for storage of that fragment. Using this method, Jabber entities can store private data on the server and retrieve it whenever necessary. The data stored might be anything, as long as it is valid XML. One typical usage for this namespace is the server-side storage of client-specific preferences; another is &jep0048;.</p>
<p>A Jabber client can store any arbitrary XML on the server side by sending an &IQ; stanza of type "set" to the server with a &QUERY; child scoped by the 'jabber:iq:private' namespace. The &QUERY; element MAY contain any arbitrary XML fragment as long as the root element of that fragment is scoped by its own namespace. The data can then be retrieved by sending an &IQ; stanza of type "get" with a &QUERY; child scoped by the 'jabber:iq:private' namespace, which in turn contains a child element scoped by the namespace used for storage of that fragment. Using this method, Jabber entities can store private data on the server and retrieve it whenever necessary. The data stored might be anything, as long as it is valid XML. One typical usage for this namespace is the server-side storage of client-specific preferences; another is &xep0048;.</p>
</section2>
<section2 topic='Methods'>
<table caption='Description of Acceptable Methods'>
@ -95,7 +95,7 @@
</table>
</section2>
<section2 topic='Elements'>
<p>The root element of this namespace is query. At least one child element with a proper namespace MUST be included; otherwise the server MUST respond with a "Not Acceptable" error (see &jep0086; for information about error conditions). A client MUST NOT query for more than namespace in a single IQ get request. However, an IQ set or result MAY contain multiple elements qualified by the same namespace.</p>
<p>The root element of this namespace is query. At least one child element with a proper namespace MUST be included; otherwise the server MUST respond with a "Not Acceptable" error (see &xep0086; for information about error conditions). A client MUST NOT query for more than namespace in a single IQ get request. However, an IQ set or result MAY contain multiple elements qualified by the same namespace.</p>
<example caption='Client Stores Private Data'><![CDATA[
CLIENT:
@ -216,10 +216,10 @@ SERVER (optional error):
<p>A server MUST NOT allow any entity other than an authorized resource of the user to create, update, or delete private XML stored on behalf of that user.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:private' is already a registered namespace.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:iq:private' is already a registered namespace.</p>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -234,7 +234,7 @@ SERVER (optional error):
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0049: http://www.jabber.org/jeps/jep-0049.html
XEP-0049: http://www.xmpp.org/extensions/xep-0049.html
</xs:documentation>
</xs:annotation>
@ -249,4 +249,4 @@ SERVER (optional error):
</xs:schema>
]]></code>
</section1>
</jep>
</xep>