An XMPP extension to handle generic limit specifying metadata.
WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.
Status: Deferred
Type: Standards Track
Number: 0059
Version: 0.1
Last Updated: 2002-11-12
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name:
Wiki Page: <http://wiki.jabber.org/index.php/Limiting and Paging Extension (JEP-0059)>
Email: jean-louis.seguineau@antepo.com
JID: jlseguineau@im.antepo.com
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
There is a generic need in the protocol for specifying granular limit metadata to limit the amount of data held in a reply sent by a service. The interpretation of the metadata is entirely context specific, and outside the scope of this document. Such limits may be applied in cases like:
This extension sould be embedable in any XMPP packet to represent limiting metadata.
A user has issued the relevant info query to a search service to discover what search fields are supported by the service.
The user may then submit a search request, specifying values for any desired fields, and addding the limit metadata that it deem appropriate. In the following case we want to limit the number of returned results:
Example 1. Upper Limiting a Search Request
<iq type='set' to='users.jabber.org' id='search2'>
<query xmlns="jabber:iq:search">
<first>peter</first>
<x xmlns='xmpp:x:limit' >
<limit type="max">20</limit>
</x>
</query>
</iq>
The service should then return a list of search results that match the values provided, but not more than 20 results
It could also be intersting to provide a way to specify a pagination behaviour for the result. In this case the user will issue its search request by specifying a starting point in the result set and a number of item to be returned in addition to the maximum number of items.
Example 2. Specifying Pagination into a Search Request
<iq type='set' to='users.jabber.org' id='search2'>
<query xmlns="jabber:iq:search">
<first>peter</first>
<x xmlns='xmpp:x:limit' >
<limit type="max">100</limit>
<limit type="start">0</limit>
<limit type="count">10</limit>
</x>
</query>
</iq>
Subsequent requests could then be sent to the search service to change the returned items window.
Example 3. Paginating into a Search Request
<iq type='set' to='users.jabber.org' id='search2'>
<query xmlns="jabber:iq:search">
<x xmlns='xmpp:x:limit' >
<limit type="start">30</limit>
<limit type="count">10</limit>
</x>
</query>
</iq>
One can imagine a monitoring service, with several instruments that need to have their reading characteristics set once and a while.
A user may submit a setting instruction, specifying minimum and maximum recording values as well as sampling interval for a measuring instrument in a way similar to:
Example 4. Setting a measuring instrument
<presence to='gage@monitor.jabber.org'>
<x xmlns='xmpp:x:limit' >
<limit type="min">0</limit>
<limit type="max">1000</limit>
<limit type="count">60</limit>
</x>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT x (limit*)>
<!ATTLIST x
xmlns (xmpp:x:limit) #REQUIRED
>
<!ELEMENT limit (#PCDATA)>
<!ATTLIST limit
type (count | min | max | start | stop) #IMPLIED
>
There are no security features or concerns related to this proposal.
This JEP requires no interaction with the IANA.
The namespaces needs to be registered with JANA as a result of this JEP. See Jabber Assigned Names Authority (JANA) [1]
As required, the namespace is easily integrated into any existing high level element of the XMPP protocol. Again, it is only intended to provide a generic way to convey metadata that will influence or limit the behaviour of another XMPP namespace. The meaning and behaviour of the receiving service is entirely implementation dependent.
END