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

DJ Adams dj.adams at pobox.com
Sun Mar 3 17:57:21 UTC 2002


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

cheerio for now
dj




More information about the Standards mailing list