[Standards] RSM and order

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Feb 10 22:01:39 UTC 2012

On Friday, February 10, 2012 01:23:30 PM Guus der Kinderen wrote:
> Hello,
> Was it a deliberate choice not to include an explicit attribute that
> relates to 'order' in XEP-0059 - Result Set Management?
> XEP-0059 RSM is oriented towards a GUI that contains a scrollable list (in
> which order is often implied, I guess). A different common GUI element is
> that of a paginated table. That would work well with RSM (as long as you do
> not relax the requirement of accuracy on the 'index' value). A common
> feature of such tables is the ability to sort data by column - which is how
> I noticed that any form of 'ordering' is missing from the XEP.
> Any form of iteration (using more than one request) depends on the fact
> that each request uses a result set that's ordered in the same way. There
> is no reference to such ordering in the XEP at all. Strictly speaking, I
> think the XEP could use (well, it's been in use for years and no-one missed
> it, but hey) a reference to ordering, even if its to be implicit.
> If functionality could be added that can be used to define ordering of a
> result set, the XEP becomes a lot more flexible. I'm not advocating that a
> lot more flexibility should be added - although I'm not denying that it
> could have considerable added value.

My feeling is that different orderings should be the responsibility of the 
protocol encapsulating RSM.  For example, if you're retrieving data from a 
user directory, then it would be the job of the jabber:iq:search protocol to 
offer fields (and directionality) to sort by.  RSM is just traversal of "some" 

We could extend RSM to allow passing sorting information, if we think it would 
be useful to genericize that aspect of the exchange.  Either way though, which 
sorting fields/criteria are supported would still be determined by the parent 


More information about the Standards mailing list