From 7a35010424292635ee51f8ce671829eb4e6b1bf4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 3 Oct 2006 23:14:23 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@33 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0050.xml | 60 ++++++++++++++++++++++++++-------------------------- xep-0051.xml | 10 ++++----- xep-0052.xml | 24 ++++++++++----------- xep-0053.xml | 6 ++++++ xep-0054.xml | 20 +++++++++--------- xep-0055.xml | 24 ++++++++++----------- xep-0056.xml | 14 ++++++------ xep-0057.xml | 14 ++++++------ xep-0058.xml | 14 ++++++------ xep-0059.xml | 30 +++++++++++++------------- 10 files changed, 111 insertions(+), 105 deletions(-) diff --git a/xep-0050.xml b/xep-0050.xml index b2b99005..897e4cdb 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Ad-Hoc Commands - This JEP defines protocol for reporting and executing ad-hoc, human-oriented commands in Jabber/XMPP. + This document defines an XMPP protocol extension for reporting and executing ad-hoc, human-oriented commands. &LEGALNOTICE; 0050 Draft @@ -15,14 +15,14 @@ Standards JIG XMPP Core - JEP-0004 - JEP-0030 + XEP-0004 + XEP-0030 commands - http://jabber.org/protocol/commands/commands.xsd + http://www.xmpp.org/schemas/commands.xsd &linuxwolf; @@ -95,7 +95,7 @@ 0.7 2003-01-22 lw - Added disco node syntax for commands; Expanded "Jabber Registrar" section. + Added disco node syntax for commands; Expanded "XMPP Registrar" section. 0.6 @@ -113,7 +113,7 @@ 0.4 2002-11-05 lw - 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". + 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". 0.3 @@ -135,17 +135,17 @@
-

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.

+

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.

-

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.

+

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.

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).

 -

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.

+

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.

 -

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".

-

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.

+

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".

+

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.

 @@ -318,7 +318,7 @@ ]]> -

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.

+

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.

If the command requires more interaction, the responder sends a result &IQ; that contains the command information and the form to be filled out:

All commands used in the above examples are for illustrative purposes only. There are no predefined or required commands.

-

Each command is identified by its 'node' attribute. This matches the 'node' attribute from the service discovery <item/> element. Service Discovery requires that all 'node' values be unique within a given JID. This JEP requires that the 'node' value used in <command/> exactly match the value used in the <item/> element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID.

+

Each command is identified by its 'node' attribute. This matches the 'node' attribute from the service discovery <item/> element. Service Discovery requires that all 'node' values be unique within a given JID. This document requires that the 'node' value used in <command/> exactly match the value used in the <item/> element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID.

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.

The requester starts a new session for a command by simply sending a <command/> 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 <command status='completed'/> or the requester sends a <command action='cancel'/> with the provided 'sessionid' value.

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.

-

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 ¬allowed; error (see &jep0086;).

+

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 ¬allowed; error (see &xep0086;).

The result for each stage (other than the last) of a command's execution SHOULD include an <actions/> element. The user-agent can use this information to present a more-intelligent user interface, such as a "druid" or "wizard".

@@ -523,7 +523,7 @@

On its own, the <command/> 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 <note/> elements. Any namespaced elements can be used within a <command/>. The only limitations are that the elements not require certain parent elements (such as &IQ;), or specifically allow for <command/> qualified by the "http://jabber.org/protocol/commands" namespace as a possible parent element.

-

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).

+

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).

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).

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 <x type='cancel'/> to be <x type='submit'/>.

@@ -776,18 +776,18 @@ -

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.

+

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.

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".

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The ®ISTRAR; includes 'http://jabber.org/protocol/commands' in its registry of protocol namespaces.

 -

The Jabber Registrar includes "automation" in its registry of Service Discovery categories for use for any entities and nodes that provide automated or programmed interaction. This category has the following types:

+

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:

@@ -810,21 +810,21 @@ command-list The node for a list of commands; valid only for the node "http://jabber.org/protocol/commands" - JEP-0050 + XEP-0050 command-node A node for a specific command; the 'node' attribute uniquely identifies the command - JEP-0050 + XEP-0050 ]]> -

The Jabber Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.

+

The XMPP Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.

 -

As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

+

As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

The "command" querytype is defined herein for interaction with entities that support the ad-hoc command protocol, with keys of "action" and "node".

command http://jabber.org/protocol/commands enables completion of ad-hoc commands - JEP-0050 + XEP-0050 action @@ -890,7 +890,7 @@ xmpp:montague.net?command;node=stats 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 @@ -980,4 +980,4 @@ xmpp:montague.net?command;node=stats ]]> - + diff --git a/xep-0051.xml b/xep-0051.xml index 3060374d..95be388a 100644 --- a/xep-0051.xml +++ b/xep-0051.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
@@ -269,4 +269,4 @@ A: </iq> - + diff --git a/xep-0052.xml b/xep-0052.xml index 988d1eb3..8bbe0788 100644 --- a/xep-0052.xml +++ b/xep-0052.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
File Transfer A protocol for transferring a file between two Jabber IDs. @@ -13,9 +13,9 @@ Retracted Standards Track Standards JIG - XMPP Core, XMPP IM, JEP-0004, JEP-0020, JEP-0030 + XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030 None - JEP-0095, JEP-0096 + XEP-0095, XEP-0096 N/A Thomas @@ -39,13 +39,13 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 2002-12-03 tjm - Initial version, based on original JEP-0052 revision 0.1. + Initial version, based on original XEP-0052 revision 0.1.
@@ -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.

@@ -63,7 +63,7 @@

- 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.

@@ -283,7 +283,7 @@ ]]> -

The <file/> 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 <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/>JEP-0020: "Feature Negotiation" -- http://www.jabber.org/jeps/jep-0020.html elements.

+

The <file/> 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 <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.

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.

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:

Type
@@ -384,4 +384,4 @@

- + diff --git a/xep-0053.xml b/xep-0053.xml index e5a6b7cc..31acdc4c 100644 --- a/xep-0053.xml +++ b/xep-0053.xml @@ -19,6 +19,12 @@ N/A &stpeter; + + 1.2 + 2006-10-04 + psa +

As approved by the members of the Jabber Software Foundation, changed Jabber Registrar to XMPP Registrar.

 + 1.1 2004-05-20 diff --git a/xep-0054.xml b/xep-0054.xml index ec037486..38550ac0 100644 --- a/xep-0054.xml +++ b/xep-0054.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
vcard-temp This specification provides canonical documentation of the vCard-XML format currently in use within the Jabber community. @@ -46,7 +46,7 @@
-

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.

+

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.

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 <iq/> of type "set" (storage) or "get" (retrieval) to one's Jabber server containing a <vCard/> child scoped by the 'vcard-temp' namespace, with the <vCard/> element containing the actual vCard-XML elements as defined by the vCard-XML DTD. Other users may then view one's vCard information.

 @@ -161,14 +161,14 @@

There are no security features or concerns related to this proposal.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The ®ISTRAR; includes the 'vcard-temp' namespace in its registry of official namespaces (see &NAMESPACES;).

 -

As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

+

As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

The "vcard" querytype is registered as a vCard-related action.

vcard vcard-temp enables retrieval of an entity's vCard data - JEP-0054 + XEP-0054 ]]> @@ -521,4 +521,4 @@ PARTICULAR PURPOSE. ]]> - + diff --git a/xep-0055.xml b/xep-0055.xml index 697333ae..c61fc80f 100644 --- a/xep-0055.xml +++ b/xep-0055.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Jabber Search This specification provides canonical documentation of the 'jabber:iq:search' namespace currently in use within the Jabber community. @@ -21,7 +21,7 @@ iq-search - http://jabber.org/protocol/iq-search/iq-search.xsd + http://www.xmpp.org/schemas/iq-search.xsd &stpeter; @@ -51,7 +51,7 @@

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.

-

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.

+

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.

 @@ -133,7 +133,7 @@

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, Data Forms SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via Data Forms is RECOMMENDED, but is not required for compliance with this JEP.

-

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.

+

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.

This JEP requires no interaction with &IANA;.

 - +

The ®ISTRAR; shall include the following information in its registries.

-

The Jabber Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.

+

The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.

 -

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.

+

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.

jabber:iq:search @@ -289,7 +289,7 @@ 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 @@ -324,4 +324,4 @@ ]]> - + diff --git a/xep-0056.xml b/xep-0056.xml index 57e6fc4b..db3faa54 100644 --- a/xep-0056.xml +++ b/xep-0056.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Business Data Interchange -This JEP defines a way to transmit ebXML messages, ANSI X.11, EDIFACT/UN, and SAP iDoc over Jabber/XMPP. +This document defines a way to transmit ebXML messages, ANSI X.11, EDIFACT/UN, and SAP iDoc over Jabber/XMPP. &LEGALNOTICE; 0056 Deferred @@ -43,7 +43,7 @@

-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.

@@ -178,4 +178,4 @@ SAP Systems can create IDocs as receipts of transactions. These receipts can be ]]> - + diff --git a/xep-0057.xml b/xep-0057.xml index 32de49ff..22a97473 100644 --- a/xep-0057.xml +++ b/xep-0057.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Extended Roster This JEP defines a way to handle extended roster items. @@ -51,7 +51,7 @@ -

Using jabber:iq:private as in JEP-0048 http://www.jabber.org/jeps/jep-0048.html 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 jabber:iq:roster 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).

+

Using jabber:iq:private 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 jabber:iq:roster 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).

But we have a place where this problem does not exist: jabber:iq:roster. We can store it in <item/> subtags. Existing server implementation MUST NOT remove <x/> tags from it. In this case all information always relates to its JID and disappears when this JID removed.

 @@ -63,7 +63,7 @@ type="text">]]> -

This information is implementation-dependent, so to provide flexibility for it, the jabber:x:data namespace defined in JEP-0004 http://www.jabber.org/jeps/jep-0004.html must be used. The client can set these parameters by setting this item with this form with type='submit'.

+

This information is implementation-dependent, so to provide flexibility for it, the jabber:x:data namespace defined in &xep0004; must be used. The client can set these parameters by setting this item with this form with type='submit'.

@@ -179,4 +179,4 @@ - + diff --git a/xep-0058.xml b/xep-0058.xml index 774a310b..29a8a6fe 100644 --- a/xep-0058.xml +++ b/xep-0058.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Multi-User Text Editing - This JEP defines how several people may simultaneously edit text. + This document defines how several people may simultaneously edit text. &LEGALNOTICE; 0058 Deferred @@ -28,7 +28,7 @@
- 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 @@ ]]> - + diff --git a/xep-0059.xml b/xep-0059.xml index 1feda0f3..48e84684 100644 --- a/xep-0059.xml +++ b/xep-0059.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Result Set Management This document defines an XMPP protocol extension to enable entities to page through and otherwise manage the receipt of large result sets. @@ -16,13 +16,13 @@ XMPP Core XMPP IM - JEP-0030 + XEP-0030 rsm - http://jabber.org/protocol/rsm/rsm.xsd + http://www.xmpp.org/schemas/rsm.xsd &ianpaterson; &stpeter; @@ -115,7 +115,7 @@ 0.2 2005-12-22 psa/vm -

Revived and renamed the JEP; modified syntax; added use case for getting number of items; defined XML schema.

 +

Revived and renamed the XEP; modified syntax; added use case for getting number of items; defined XML schema.

 0.1 @@ -125,7 +125,7 @@
-

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:

+

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:

  1. Limit the number of items returned.
  2. Page forwards or backwards through a result set by retrieving the items in smaller subsets.
    3. @@ -264,7 +264,7 @@ ]]> -

    If there are no items whatsoever in the full 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 JEP-0055 and JEP-0030, that means the responding entity shall return an empty &QUERY; element; for JEP-0060, that means the responding entity shall return an empty <pubsub/> element; for JEP-0136, that means the responding entity shall return an empty <list/> or <store/> element.

    +

    If there are no items whatsoever in the full 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 XEP-0055 and XEP-0030, that means the responding entity shall return an empty &QUERY; element; for XEP-0060, that means the responding entity shall return an empty <pubsub/> element; for XEP-0136, that means the responding entity shall return an empty <list/> or <store/> element.

    The requesting entity MAY ask for the previous page in a result set by including in its request the UID of the first item from the page that has already been received (encapsulated in a <before/> element), along with the maximum number of items to return.

    @@ -425,7 +425,7 @@     -

    The foregoing examples show the use of result set management in the context of Jabber Search. In the following examples we show the use of this protocol in the context of Service Discovery. JEP-0136 ("Message Archiving") includes more examples. A future version of this document may also include examples from Publish-Subscribe and other XMPP protocol extensions.

    +

    The foregoing examples show the use of result set management in the context of Jabber Search. In the following examples we show the use of this protocol in the context of Service Discovery. XEP-0136 ("Message Archiving") includes more examples. A future version of this document may also include examples from Publish-Subscribe and other XMPP protocol extensions.

    @@ -501,12 +501,12 @@

    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.

     -

    Security considerations are the responsibility of the using ("wrapper") protocol, such as JEP-0030 for the 'http://jabber.org/protocol/disco#items' namespace, JEP-0055 for the 'jabber:iq:search' namespace, and JEP-0136 for the 'http://jabber.org/protocol/archive' namespace.

    +

    Security considerations are the responsibility of the using ("wrapper") protocol, such as XEP-0030 for the 'http://jabber.org/protocol/disco#items' namespace, XEP-0055 for the 'jabber:iq:search' namespace, and XEP-0136 for the 'http://jabber.org/protocol/archive' namespace.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes 'http://jabber.org/protocol/rsm' in its registry of protocol namespaces.

     @@ -524,7 +524,7 @@ 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 @@ -558,4 +558,4 @@

    Thanks to Olivier Goffart, Jon Perlow, and Andrew Plotkin for their feedback.

     - +