moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

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

60
xep-0050.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>Ad-Hoc Commands</title>
<abstract>This JEP defines protocol for reporting and executing ad-hoc, human-oriented commands in Jabber/XMPP.</abstract>
<abstract>This document defines an XMPP protocol extension for reporting and executing ad-hoc, human-oriented commands.</abstract>
&LEGALNOTICE;
<number>0050</number>
<status>Draft</status>
@ -15,14 +15,14 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec dep='SHOULD'>JEP-0004</spec>
<spec>JEP-0030</spec>
<spec dep='SHOULD'>XEP-0004</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>commands</shortname>
<schemaloc>
<url>http://jabber.org/protocol/commands/commands.xsd</url>
<url>http://www.xmpp.org/schemas/commands.xsd</url>
</schemaloc>
&linuxwolf;
<revision>
@ -95,7 +95,7 @@
<version>0.7</version>
<date>2003-01-22</date>
<initials>lw</initials>
<remark>Added disco node syntax for commands; Expanded "Jabber Registrar" section.</remark>
<remark>Added disco node syntax for commands; Expanded "XMPP Registrar" section.</remark>
</revision>
<revision>
<version>0.6</version>
@ -113,7 +113,7 @@
<version>0.4</version>
<date>2002-11-05</date>
<initials>lw</initials>
<remark>Fixed minor errors with examples; Changed position of DTD to be more consistent with other JEPs by this author; Added details for "disco" support; Added section on "Security Considerations", "IANA Considerations", and "JANA Considerations".</remark>
<remark>Fixed minor errors with examples; Changed position of DTD to be more consistent with other XEPs by this author; Added details for "disco" support; Added section on "Security Considerations", "IANA Considerations", and "JANA Considerations".</remark>
</revision>
<revision>
<version>0.3</version>
@ -135,17 +135,17 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP specifies a protocol for an entity to initiate a command session, where there is no preferred namespace. It also specifies a protocol for describing the types of ad hoc sessions, similar in concept to a menu.</p>
<p>This document specifies an XMPP protocol extension that enables an entity to initiate a command session where there is no preferred namespace. It also specifies a protocol extension for describing the types of ad hoc sessions, similar in concept to a menu.</p>
<section2 topic='Motivation' anchor='motivation'>
<p>The motivation for such a protocol comes from the desire to expand Jabber outside the domain of instant messaging. Similar to web applications, these "Jabber applications" are systems in which, via a compliant Jabber client, a user (or automated process) can interact with the application. The client need not be specially-written in order to take advantage of this Jabber application.</p>
<p>The motivation for such a protocol comes from the desire to expand Jabber technologies outside the domain of instant messaging. Similar to web applications, these "Jabber applications" are systems in which, via a compliant Jabber client, a user (or automated process) can interact with the application. The client need not be specially-written in order to take advantage of this Jabber application.</p>
<p>This mechanism allows for a larger base of Jabber entities to participate as part of larger application architectures. Although specialized clients would be preferred in many environments, this protocol allows for applications to have a wider audience (i.e., any compliant Jabber client).</p>
</section2>
<section2 topic='Concepts' anchor='concepts'>
<p>The namespace governing this protocol is "http://jabber.org/protocol/commands" (hereafter referred to as x-commands). This namespace relies on the &IQ; element for execution, and can use the &MESSAGE; element for announcing command lists. This protocol depends on &jep0030; for reporting and announcing command lists. This namespace is intended to complement &jep0004; (jabber:x:data), but is not necessarily dependent upon it.</p>
<p>The namespace governing this protocol is "http://jabber.org/protocol/commands" (hereafter referred to as x-commands). This namespace relies on the &IQ; element for execution, and can use the &MESSAGE; element for announcing command lists. This protocol depends on &xep0030; for reporting and announcing command lists. This namespace is intended to complement &xep0004; (jabber:x:data), but is not necessarily dependent upon it.</p>
</section2>
<section2 topic='Prerequisites' anchor='prerequisites'>
<p>Support of x-commands implies support for "jabber:x:data" (although this requirement may be replaced and/or amended with a requirement to support &jep0020; by performing the appropriate negotations before executing commands). x-commands provides a bootstrap for performing ad-hoc "jabber:x:data" processes, while the data itself is conveyed using "jabber:x:data".</p>
<p>The x-commands namespace is not designed to replace machine-to-machine oriented RPC systems such as &jep0009;, where the two entities fully understand the command's purpose and behavior prior to execution. x-commands is oriented more for human interaction, where the user agent (such as a compliant Jabber client) most likely has no prior knowledge of the command's purpose and behavior.</p>
<p>Support of x-commands implies support for "jabber:x:data" (although this requirement may be replaced and/or amended with a requirement to support &xep0020; by performing the appropriate negotations before executing commands). x-commands provides a bootstrap for performing ad-hoc "jabber:x:data" processes, while the data itself is conveyed using "jabber:x:data".</p>
<p>The x-commands namespace is not designed to replace machine-to-machine oriented RPC systems such as &xep0009;, where the two entities fully understand the command's purpose and behavior prior to execution. x-commands is oriented more for human interaction, where the user agent (such as a compliant Jabber client) most likely has no prior knowledge of the command's purpose and behavior.</p>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
@ -318,7 +318,7 @@
</iq>
]]></example>
</section3>
<p>The above example shows the command execution resulting in a "jabber:x:data" form. It is also possible that one or more URLs (specified via &jep0066;) could be returned.</p>
<p>The above example shows the command execution resulting in a "jabber:x:data" form. It is also possible that one or more URLs (specified via &xep0066;) could be returned.</p>
<section3 topic='Multiple Stages' anchor='execute-multiple'>
<p>If the command requires more interaction, the responder sends a result &IQ; that contains the command information and the form to be filled out:</p>
<example caption='Execute command request (stage 1)'><![CDATA[
@ -488,13 +488,13 @@
<p>All commands used in the above examples are for illustrative purposes only. There are no predefined or required commands.</p>
</section2>
<section2 topic='Command Nodes' anchor='impl-nodes'>
<p>Each command is identified by its 'node' attribute. This matches the 'node' attribute from the service discovery &lt;item/&gt; element. Service Discovery requires that all 'node' values be unique within a given JID. This JEP requires that the 'node' value used in &lt;command/&gt; exactly match the value used in the &lt;item/&gt; element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID.</p>
<p>Each command is identified by its 'node' attribute. This matches the 'node' attribute from the service discovery &lt;item/&gt; element. Service Discovery requires that all 'node' values be unique within a given JID. This document requires that the 'node' value used in &lt;command/&gt; exactly match the value used in the &lt;item/&gt; element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID.</p>
</section2>
<section2 topic='Session Lifetime' anchor='impl-session'>
<p>The execution of a command exists within the concept of a session. Each session is identified by the 'sessionid' attribute, and SHOULD be valid only between one requester/responder pair. The responder is responsible for determining the session lifetime, with some help from the requester.</p>
<p>The requester starts a new session for a command by simply sending a &lt;command/&gt; with the 'node' attribute (and optionally the 'status' attribute with a value of "execute"). Once the 'sessionid' attribute is given to the requester, it is the requester's responsibility to maintain it for the session's lifetime. A session ends when the responder sends a &lt;command status='completed'/&gt; or the requester sends a &lt;command action='cancel'/&gt; with the provided 'sessionid' value.</p>
<p>Once a session has ended, its 'sessionid' value SHOULD NOT be used again. It is the responder's responsibility to ensure that each 'sessionid' value is unique.</p>
<p>It may be possible for a requester to be executing more than one session of the same command with a given responder. If the responder does not allow more than one session of the same command with the same requester, the responder MUST return a &notallowed; error (see &jep0086;).</p>
<p>It may be possible for a requester to be executing more than one session of the same command with a given responder. If the responder does not allow more than one session of the same command with the same requester, the responder MUST return a &notallowed; error (see &xep0086;).</p>
</section2>
<section2 topic='Command Actions' anchor='impl-actions'>
<p>The result for each stage (other than the last) of a command's execution SHOULD include an &lt;actions/&gt; element. The user-agent can use this information to present a more-intelligent user interface, such as a "druid" or "wizard".</p>
@ -523,7 +523,7 @@
</section2>
<section2 topic='Command Payloads' anchor='impl-payloads'>
<p>On its own, the &lt;command/&gt; has very little usefulness. It relies on its payload to give full meaning to its use. The payload can be elements in any namespace that makes sense and is understood (such as "jabber:x:data"), and/or one or more &lt;note/&gt; elements. Any namespaced elements can be used within a &lt;command/&gt;. The only limitations are that the elements not require certain parent elements (such as &IQ;), or specifically allow for &lt;command/&gt; qualified by the "http://jabber.org/protocol/commands" namespace as a possible parent element.</p>
<p>As a general rule, the payload is provided only by the responder. The primary exception to this rule is with the "jabber:x:data" extension (and other namespaces with similar semantics). In this case, if the responder provides a form to submit, the requester SHOULD respond with the submitted data (using the semantics from JEP-0004).</p>
<p>As a general rule, the payload is provided only by the responder. The primary exception to this rule is with the "jabber:x:data" extension (and other namespaces with similar semantics). In this case, if the responder provides a form to submit, the requester SHOULD respond with the submitted data (using the semantics from XEP-0004).</p>
<p>When the precedence of these payload elements becomes important (such as when both "jabber:x:data" and "jabber:x:oob" elements are present), the order of the elements SHOULD be used. Those elements that come earlier in the child list take precedence over those later in the child list. The requester SHOULD consider those elements qualified by the same namespace as having an equivalent precedence (such as if multiple "jabber:x:oob" elements are included).</p>
<section3 topic='Use of Data Forms' anchor='impl-forms'>
<p>When the payload is "jabber:x:data", there are certain conditions applied. The requester SHOULD NOT use a "jabber:x:data" type other than "submit". Responders SHOULD consider any &lt;x type='cancel'/&gt; to be &lt;x type='submit'/&gt;.</p>
@ -776,18 +776,18 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='sec'>
<p>Determining when a command can be executed based on permissions or rights is considered outside the scope of this JEP. Although such mechanisms are considered specific to the application and/or implementation of this JEP, future JEPs may address these concerns.</p>
<p>Determining when a command can be executed based on permissions or rights is considered outside the scope of this document. Although such mechanisms are considered specific to the application and/or implementation of this document, future specifications may address these concerns.</p>
<p>When processing reported commands, the requester SHOULD consider any command node that does not match the JID of the responder to be suspicious, and ignore those command nodes. Responders MUST report their own command nodes only, and not the command nodes of other entities. This can help prevent limited cases of spoofing and "social engineering".</p>
</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/commands' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Service Discovery Identities' anchor='registrar-disco-identity'>
<p>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 category has the following types:</p>
<p>The XMPP Registrar includes "automation" in its registry of Service Discovery categories for use for any entities and nodes that provide automated or programmed interaction. This category has the following types:</p>
<table caption='Types for Category "automation"'>
<tr>
<th>Type</th>
@ -810,21 +810,21 @@
<type>
<name>command-list</name>
<desc>The node for a list of commands; valid only for the node "http://jabber.org/protocol/commands"</desc>
<doc>JEP-0050</doc>
<doc>XEP-0050</doc>
</type>
<type>
<name>command-node</name>
<desc>A node for a specific command; the 'node' attribute uniquely identifies the command</desc>
<doc>JEP-0050</doc>
<doc>XEP-0050</doc>
</type>
</category>
]]></code>
</section2>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'>
<p>The Jabber Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.</p>
<p>The XMPP Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.</p>
</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>
<p>The "command" querytype is defined herein for interaction with entities that support the ad-hoc command protocol, with keys of "action" and "node".</p>
<example caption='Command Action: IRI/URI'><![CDATA[
xmpp:montague.net?command;node=stats
@ -840,7 +840,7 @@ xmpp:montague.net?command;node=stats
<name>command</name>
<proto>http://jabber.org/protocol/commands</proto>
<desc>enables completion of ad-hoc commands</desc>
<doc>JEP-0050</doc>
<doc>XEP-0050</doc>
<keys>
<key>
<name>action</name>
@ -890,7 +890,7 @@ xmpp:montague.net?command;node=stats
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0050: http://www.jabber.org/jeps/jep-0050.html
XEP-0050: http://www.xmpp.org/extensions/xep-0050.html
</xs:documentation>
</xs:annotation>
@ -980,4 +980,4 @@ xmpp:montague.net?command;node=stats
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

10
xep-0051.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>
@ -269,4 +269,4 @@ A: &lt;/iq&gt;
</section1>
</jep>
</xep>

24
xep-0052.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>File Transfer</title>
<abstract>A protocol for transferring a file between two Jabber IDs.</abstract>
@ -13,9 +13,9 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>XMPP Core, XMPP IM, JEP-0004, JEP-0020, JEP-0030</dependencies>
<dependencies>XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0095, JEP-0096</supersededby>
<supersededby>XEP-0095, XEP-0096</supersededby>
<shortname>N/A</shortname>
<author>
<firstname>Thomas</firstname>
@ -39,13 +39,13 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0095 and JEP-0096. 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 authors, the status of this document has been changed to Retracted since it has been superseded by XEP-0095 and XEP-0096. This document 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.1</version>
<date>2002-12-03</date>
<initials>tjm</initials>
<remark>Initial version, based on original JEP-0052 revision 0.1.</remark>
<remark>Initial version, based on original XEP-0052 revision 0.1.</remark>
</revision>
</header>
@ -55,7 +55,7 @@
namespace, which is used for offering and transferring files from one Jabber
ID to another. It tries to expand the basic method (iq:oob) that currently
exists to allow for numerous stream methods, and more detailed file
information before accepting an offer. This JEP only describes the
information before accepting an offer. This document only describes the
negotiation method and suggests how streams could link back to the
negotiated information.
</p>
@ -63,7 +63,7 @@
<section1 topic='Use Cases'>
<p>
This JEP covers one use case of sending a file to another user. Future JEPs
This document covers one use case of sending a file to another user. Future JEPs
may enhance this to include searching and offering.
</p>
@ -283,7 +283,7 @@
]]></code>
</section2>
<section2 topic='&lt;file/&gt; Element'>
<p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt;<note>JEP-0020: "Feature Negotiation" -- <link url='http://www.jabber.org/jeps/jep-0020.html'>http://www.jabber.org/jeps/jep-0020.html</link></note> elements.</p>
<p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt; (&xep0020;) elements.</p>
<p>The "id" attribute specifies the identifier for this particular file transfer. This attribute MUST be present at all times. There are no value requirements other than it MUST be unique between the sender and receiver.</p>
<p>The "action" attribute specifies the action to undertake with the given file. This attribute SHOULD be present in most cases. If not present, the value "offer" is implied. The value of "action" MUST be one of the following:</p>
<table caption='Possible "action" values'>
@ -384,4 +384,4 @@
</p>
</section1>
</jep>
</xep>

6
xep-0053.xml
View File

@ -19,6 +19,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.2</version>
<date>2006-10-04</date>
<initials>psa</initials>
<remark><p>As approved by the members of the Jabber Software Foundation, changed Jabber Registrar to XMPP Registrar.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2004-05-20</date>

20
xep-0054.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>vcard-temp</title>
<abstract>This specification provides canonical documentation of the vCard-XML format currently in use within the Jabber community.</abstract>
@ -46,7 +46,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>This specification documents the vCard-XML format currently in use within the Jabber community. A future JEP will recommend a standards-track protocol to supersede this informational document.</p>
<p>This specification documents the vCard-XML format currently in use within the Jabber community. A future specification will recommend a standards-track protocol to supersede this informational document.</p>
<p>The basic functionality is for a user to store and retrieve an XML representation of his or her vCard using the data storage capabilities native to all existing Jabber server implementations. This is done by by sending an &lt;iq/&gt; of type "set" (storage) or "get" (retrieval) to one's Jabber server containing a &lt;vCard/&gt; child scoped by the 'vcard-temp' namespace, with the &lt;vCard/&gt; element containing the actual vCard-XML elements as defined by the vCard-XML DTD. Other users may then view one's vCard information.</p>
</section1>
<section1 topic='History'>
@ -161,14 +161,14 @@
<p>There are no security features or concerns related to this proposal.</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' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
<p>The &REGISTRAR; includes the 'vcard-temp' namespace in its registry of official namespaces (see &NAMESPACES;).</p>
</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>
<p>The "vcard" querytype is registered as a vCard-related action.</p>
<example caption='vCard Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?vcard
@ -184,7 +184,7 @@ xmpp:romeo@montague.net?vcard
<name>vcard</name>
<proto>vcard-temp</proto>
<desc>enables retrieval of an entity's vCard data</desc>
<doc>JEP-0054</doc>
<doc>XEP-0054</doc>
</querytype>
]]></code>
</section2>
@ -521,4 +521,4 @@ PARTICULAR PURPOSE.
<!-- ==== -->
]]></code>
</section1>
</jep>
</xep>

24
xep-0055.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 Search</title>
<abstract>This specification provides canonical documentation of the 'jabber:iq:search' namespace currently in use within the Jabber community.</abstract>
@ -21,7 +21,7 @@
<supersededby/>
<shortname>iq-search</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-search/iq-search.xsd</url>
<url>http://www.xmpp.org/schemas/iq-search.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -51,7 +51,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This specification documents a protocol currently used to search information repositories on the Jabber network. To date, the jabber:iq:search protocol has been used mainly to search for people who have registered with user directories (e.g., the "Jabber User Directory" hosted at users.jabber.org). However, the jabber:iq:search protocol is not limited to user directories, and could be used to search other Jabber information repositories (such as chatroom directories) or even to provide a Jabber interface to conventional search engines.</p>
<p>The basic functionality is to query an information repository regarding the possible search fields, to send a search query, and to receive search results. Note well that there is currently no mechanism for paging through results or limiting the number of "hits", and that the allowable search fields are limited to those defined in the XML schema; however, extensibility MAY be provided via the &jep0004; protocol, as described below.</p>
<p>The basic functionality is to query an information repository regarding the possible search fields, to send a search query, and to receive search results. Note well that there is currently no mechanism for paging through results or limiting the number of "hits", and that the allowable search fields are limited to those defined in the XML schema; however, extensibility MAY be provided via the &xep0004; protocol, as described below.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic="Searching" anchor='usecases-search'>
@ -133,7 +133,7 @@
</section1>
<section1 topic='Extensibility' anchor='extensibility'>
<p>The fields defined in the 'jabber:iq:search' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <strong>Data Forms</strong> SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via <strong>Data Forms</strong> is RECOMMENDED, but is not required for compliance with this JEP.</p>
<p>The extensibility mechanism for searching makes use of a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &jep0068;. Implementations supporting this extensibility mechanism SHOULD support field standardization as well.</p>
<p>The extensibility mechanism for searching makes use of a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;. Implementations supporting this extensibility mechanism SHOULD support field standardization as well.</p>
<example caption='Entity Requests Search Fields from Service'><![CDATA[
<iq type='get'
from='juliet@capulet.com/balcony'
@ -241,13 +241,13 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall include the following information in its registries.</p>
<section2 topic='Protocol Namespaces' anchor='registrar-namespaces'>
<p>The Jabber Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.</p>
<p>The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'>
<p>The following fields are reserved for use within jabber:x:data forms scoped by a FORM_TYPE of 'jabber:iq:search'; additional fields MAY be added via the Jabber Registrar's normal registration process but are outside the scope of this JEP.</p>
<p>The following fields are reserved for use within jabber:x:data forms scoped by a FORM_TYPE of 'jabber:iq:search'; additional fields MAY be added via the XMPP Registrar's normal registration process but are outside the scope of this JEP.</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>jabber:iq:search</name>
@ -289,7 +289,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0055: http://www.jabber.org/jeps/jep-0055.html
XEP-0055: http://www.xmpp.org/extensions/xep-0055.html
</xs:documentation>
</xs:annotation>
@ -324,4 +324,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

14
xep-0056.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>Business Data Interchange</title>
<abstract>This JEP defines a way to transmit ebXML messages, ANSI X.11, EDIFACT/UN, and SAP iDoc over Jabber/XMPP.</abstract>
<abstract>This document defines a way to transmit ebXML messages, ANSI X.11, EDIFACT/UN, and SAP iDoc over Jabber/XMPP.</abstract>
&LEGALNOTICE;
<number>0056</number>
<status>Deferred</status>
@ -43,7 +43,7 @@
<section1 topic='Introduction'>
<p>
ANSI X.12, EDIFACT/UN and ebXML are all standards. This JEP describes a fundamental approach to transmit messages that conform to these standards.
ANSI X.12, EDIFACT/UN and ebXML are all standards. This document describes a fundamental approach to transmit messages that conform to these standards.
</p>
</section1>
@ -178,4 +178,4 @@ SAP Systems can create IDocs as receipts of transactions. These receipts can be
]]></example>
</section2>
</section1>
</jep>
</xep>

14
xep-0057.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>Extended Roster</title>
<abstract>This JEP defines a way to handle extended roster items.</abstract>
@ -51,7 +51,7 @@
<section1 topic="Where to store">
<p>Using <tt>jabber:iq:private</tt> as in JEP-0048 <note><link url='http://www.jabber.org/jeps/jep-0048.html'>http://www.jabber.org/jeps/jep-0048.html</link></note> for storing this information has one big problem: it is hard to mantain roster data in two separate places. When a client is online, then the client application can handle <tt>jabber:iq:roster</tt> changes and make similar changes in private storage, but when the user is online with a few different resources, or when he is offline, then making the information consistent is very hard task (a roster can be changed when user offline, e.g. if someone is making an account transfer).</p>
<p>Using <tt>jabber:iq:private</tt> as in &xep0048; for storing this information has one big problem: it is hard to mantain roster data in two separate places. When a client is online, then the client application can handle <tt>jabber:iq:roster</tt> changes and make similar changes in private storage, but when the user is online with a few different resources, or when he is offline, then making the information consistent is very hard task (a roster can be changed when user offline, e.g. if someone is making an account transfer).</p>
<p>But we have a place where this problem does not exist: <tt>jabber:iq:roster</tt>. We can store it in <tt>&lt;item/&gt;</tt> subtags. Existing server implementation MUST NOT remove <tt>&lt;x/&gt;</tt> tags from it. In this case all information always relates to its JID and disappears when this JID removed.</p>
</section1>
@ -63,7 +63,7 @@
type="text">]]></example>
</section2>
<section2 topic="Server-side information">
<p>This information is implementation-dependent, so to provide flexibility for it, the <tt>jabber:x:data</tt> namespace defined in JEP-0004 <note><link url='http://www.jabber.org/jeps/jep-0004.html'>http://www.jabber.org/jeps/jep-0004.html</link></note> must be used. The client can set these parameters by setting this item with this form with <tt>type='submit'</tt>.</p>
<p>This information is implementation-dependent, so to provide flexibility for it, the <tt>jabber:x:data</tt> namespace defined in &xep0004; must be used. The client can set these parameters by setting this item with this form with <tt>type='submit'</tt>.</p>
<example><![CDATA[<item jid="romeo@montague.net"
name="Romeo"
subscription="both">
@ -179,4 +179,4 @@
</section2>
</section1>
</jep>
</xep>

14
xep-0058.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>Multi-User Text Editing</title>
<abstract>This JEP defines how several people may simultaneously edit text.</abstract>
<abstract>This document defines how several people may simultaneously edit text.</abstract>
&LEGALNOTICE;
<number>0058</number>
<status>Deferred</status>
@ -28,7 +28,7 @@
</header>
<section1 topic="Introduction">
This JEP defines a protocol for editing one text document by several people.
This document defines a protocol for editing one text document by several people.
This can be useful when several people write different parts of one single document, or
one person edits the text and other people can see the changes. The advantage of
using this protocol in compared to using a version control systems is that all
@ -170,4 +170,4 @@
<!ELEMENT patch (#PCDATA)>
<!ELEMENT text (#PCDATA)>]]></example>
</section1>
</jep>
</xep>

30
xep-0059.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>Result Set Management</title>
<abstract>This document defines an XMPP protocol extension to enable entities to page through and otherwise manage the receipt of large result sets.</abstract>
@ -16,13 +16,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>rsm</shortname>
<schemaloc>
<url>http://jabber.org/protocol/rsm/rsm.xsd</url>
<url>http://www.xmpp.org/schemas/rsm.xsd</url>
</schemaloc>
&ianpaterson;
&stpeter;
@ -115,7 +115,7 @@
<version>0.2</version>
<date>2005-12-22</date>
<initials>psa/vm</initials>
<remark><p>Revived and renamed the JEP; modified syntax; added use case for getting number of items; defined XML schema.</p></remark>
<remark><p>Revived and renamed the XEP; modified syntax; added use case for getting number of items; defined XML schema.</p></remark>
</revision>
<revision>
<version>0.1</version>
@ -125,7 +125,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>In &jep0055;, &jep0030;, &jep0060;, &jep0136;, and probably other future XMPP extensions, it is possible to receive large dynamic result sets in response to information requests (e.g., a user directory search on a common first name or a service discovery items request sent to a &jep0045; service). This XMPP protocol extension enables the following functionality for use by other XMPP protocols:</p>
<p>In &xep0055;, &xep0030;, &xep0060;, &xep0136;, and probably other future XMPP extensions, it is possible to receive large dynamic result sets in response to information requests (e.g., a user directory search on a common first name or a service discovery items request sent to a &xep0045; service). This XMPP protocol extension enables the following functionality for use by other XMPP protocols:</p>
<ol>
<li>Limit the number of items returned.</li>
<li>Page forwards or backwards through a result set by retrieving the items in smaller subsets.</li>
@ -264,7 +264,7 @@
</query>
</iq>
]]></example>
<p>If there are no items whatsoever in the <em>full</em> result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both <cite>JEP-0055</cite> and <cite>JEP-0030</cite>, that means the responding entity shall return an empty &QUERY; element; for <cite>JEP-0060</cite>, that means the responding entity shall return an empty &lt;pubsub/&gt; element; for <cite>JEP-0136</cite>, that means the responding entity shall return an empty &lt;list/&gt; or &lt;store/&gt; element.</p>
<p>If there are no items whatsoever in the <em>full</em> result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both <cite>XEP-0055</cite> and <cite>XEP-0030</cite>, that means the responding entity shall return an empty &QUERY; element; for <cite>XEP-0060</cite>, that means the responding entity shall return an empty &lt;pubsub/&gt; element; for <cite>XEP-0136</cite>, that means the responding entity shall return an empty &lt;list/&gt; or &lt;store/&gt; element.</p>
</section2>
<section2 topic='Paging Backwards Through a Result Set' anchor='backwards'>
<p>The requesting entity MAY ask for the previous page in a result set by including in its request the UID of the <em>first</em> item from the page that has already been received (encapsulated in a &lt;before/&gt; element), along with the maximum number of items to return.</p>
@ -425,7 +425,7 @@
</section2>
</section1>
<section1 topic='Examples' anchor='examples'>
<p>The foregoing examples show the use of result set management in the context of <cite>Jabber Search</cite>. In the following examples we show the use of this protocol in the context of <cite>Service Discovery</cite>. <cite>JEP-0136</cite> ("Message Archiving") includes more examples. A future version of this document may also include examples from <cite>Publish-Subscribe</cite> and other XMPP protocol extensions.</p>
<p>The foregoing examples show the use of result set management in the context of <cite>Jabber Search</cite>. In the following examples we show the use of this protocol in the context of <cite>Service Discovery</cite>. <cite>XEP-0136</cite> ("Message Archiving") includes more examples. A future version of this document may also include examples from <cite>Publish-Subscribe</cite> and other XMPP protocol extensions.</p>
<example caption='Requesting a Limit to the Result Set'><![CDATA[
<iq type='get' from='stpeter@jabber.org/roundabout' to='conference.jabber.org' id='ex2'>
<query xmlns='http://jabber.org/protocol/disco#items'>
@ -501,12 +501,12 @@
<p>Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given using protocol is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given using protocol is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the using protocol namespace.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Security considerations are the responsibility of the using ("wrapper") protocol, such as <cite>JEP-0030</cite> for the 'http://jabber.org/protocol/disco#items' namespace, <cite>JEP-0055</cite> for the 'jabber:iq:search' namespace, and <cite>JEP-0136</cite> for the 'http://jabber.org/protocol/archive' namespace.</p>
<p>Security considerations are the responsibility of the using ("wrapper") protocol, such as <cite>XEP-0030</cite> for the 'http://jabber.org/protocol/disco#items' namespace, <cite>XEP-0055</cite> for the 'jabber:iq:search' namespace, and <cite>XEP-0136</cite> for the 'http://jabber.org/protocol/archive' namespace.</p>
</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/rsm' in its registry of protocol namespaces.</p>
</section2>
@ -524,7 +524,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0059: http://www.jabber.org/jeps/jep-0059.html
XEP-0059: http://www.xmpp.org/extensions/xep-0059.html
</xs:documentation>
</xs:annotation>
@ -558,4 +558,4 @@
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Olivier Goffart, Jon Perlow, and Andrew Plotkin for their feedback.</p>
</section1>
</jep>
</xep>