[standards-jig] [jepnews] JEP-0020: Client Feature Negotiation

Julian Missig julian at jabber.org
Sun Mar 3 23:28:45 UTC 2002

On Sun, 2002-03-03 at 12:57, DJ Adams wrote:
> On Thu, Feb 28, 2002 at 01:10:16PM +0530, Ashvil wrote:
> >
> > I am not sure why we we need a new feature negotiation namespace. I would
> > love to know, why querying the existing namespaces was not considered.
> >
> > We should be able to query the namespaces that the client returns to figure
> > out what features it supports like this
> >
> > <iq type='get' to='jid2'>
> >     <query xmlns='namespace to be queried'>
> >     </query>
> > </iq>
> Well, there has already been a lot of good discussion on this, but I
> thought I'd throw in another 2p as my wallet is still open ...
> Not that the above example is going to be used anyway, but I thought
> I'd point something out: an IQ-get on a specific namespace means
> something -- implies a response -- _within_ the context of that
> particular namespace. What is being suggested here is that the response
> to this IQ-get should be a level above - sort of a meta-information
> reply. I can't see how this can work - how the two possible responses
> can co-exist.
> For a somewhat simple and made-up example, when you send an IQ-get
> qualified by the jabber:iq:search namespace, you're expecting a response
> showing you the fields that you can search on. This is an iq:search-context
> response, which is "correct".
> If we were to expect some result in a 'higher' context, say, what *sort*
> of search features were available, then I don't see how this sort of
> response could co-exist with the 'standard' response.
> I may have mis-read something somewhere, so apologies if I have.
> Just my 2p :-)

Yeah, you're right. What should be used is an iq:browse-esque
<ns>namespace:to:be:queried</ns> or something like it.

email: julian at jabber.org
jabber:julian at jabber.org

More information about the Standards mailing list