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

Ashvil ashvil at i3connect.net
Fri Mar 1 03:57:07 UTC 2002

> A pervasive mentality in Jabber seems to be to overload functionality and
> namespaces whenever possible to. I still haven't figured this out :)

This is the stuff about Jabber that I like because I come from the OOP
world. I would agree that it should be defined in a much better fashion. But
I like the concept of objects (namespaces) and querying them via iq.

I agree 100% that Feature Negotiation is very important and we need to
figure this out soon.

If I understand Peter and David's point, they want a standard method to
query an client for features that it supports, whereas the Jabber protocol
leans towards querying an object (namespace). I also agree with Peter's
point that Explicit functions is much easier to code for.

What we need is a way to define that an object to support standard methods
and define feature negotiation as one of the standard methods.

We can query each object for the features it supports.

<iq type='get' to='jid2'>
    <query xmlns='jabber:crypto:keyexchange'>

<iq type='result' to='jid2'>
    <query xmlns='jabber:crypto:keyexchange'>

Does the above example make sense?

Anyway, the reason I want to query each individual object and not at the
client level is due to Vista (our Jabber client). Vista supports the concept
of extensible addons and each addon defines it's own namespace. So for me it
works out better if after finding out what addons are installed, the feature
negotiations are handled on request. If there is a global feature
negotiation, then Vista would have to query all it's addons and send
information that may not be relevant to the other side.


More information about the Standards mailing list