[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)

Chris Mullins cmullins at winfessor.com
Wed Mar 17 04:50:14 UTC 2004

[search vs. disco]

As an implementer on both the client side and on the server side for
disco and several other related JEPS, I do NOT interpret the disco and
search jeps the way several people in this thread are. 

While it's certainly true that the various jeps don't mandate disco to
return (for example) a complete list of MUC rooms, this is how I
interpret it. This is obviously how others (Ian, et al) are also
interpreting them. 

If other behavior is to be expected in the high-load case, this behavior
should be spelled out somewhere. This is especially true if some
combination of Disco and Search should be supported on the client side,
otherwise interoperability is going to be very difficult, and we'll end
up with whatever defacto standard the first server-side implementer

I was under the impression that IQ:Search was well along the path to

Chris Mullins

-----Original Message-----
From: Ian Paterson [mailto:ian.paterson at clientside.co.uk] 
Sent: Tuesday, March 16, 2004 4:20 PM
To: Jabber protocol discussion list
Subject: RE: [Standards-JIG] UPDATED: JEP-0030 (Service Discovery)

> Returning smaller sets of data from a huge sample size is
> exactly what jabber:iq:search is for.. AND it already
> allows you use jabber:x:data to embed whatever information
> you want into the results

Great. That would do it. :)

It's just that JEP-55 gave me a very clear impression that
is now only supposed to be used for JUD, and that it will be depricated
soon. I have carefully avoided using it for anything except JUD.

> AFAIK, JEP-45 does not MANDATE that clients can disco
> to get an entire list of the rooms.

JEP-45 does not even mention jabber:iq:search exists. :(

Perhaps we need to add something to JEP-45 to make things clear? Even if
is only to mention that although jabber:iq:search should currently be
to obtain a smaller set of rooms, it will be superseded by an upcoming
standards-track protocol.

Thanks again for your attention to this.

- Ian

More information about the Standards mailing list