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

Peter Millard me at pgmillard.com
Mon Mar 4 04:44:10 UTC 2002

----- Original Message -----
>From: "Mike Lin" <mikelin at MIT.EDU>
> I agree that it will probably be useful to define at least a rough
> top-level namespace that can be used for feature negotiation. But I
> don't think it is realistic that we will define this one namespace that
> will be satisfactory for all (or even most) negotiation requirements.

I'm not sure why you don't think such a simple protocol would be sufficient
for negotiation of just about any kind of features. Also, my examples in the
JEP are exactly that: examples.. I'm not proposing we build a ful
crypto-system using this JEP by itself, but it's just to be used as a
starting point.

> I even question whether JEP-0020 in its present form is adequate for
> building a cryptosystem, which is its stated initial purpose. For
> example, say one uses it to determine that both interested parties
> support AES. Now you also have to agree on: 1) key exchange algorithm;
> 2) actual public key exchange; 3) symmetric key length; 3) cipher block
> mode; 4) cryptographic encoding (PKCS/OpenPGP/X.509); 5) wire encoding
> (base64) 6) initialization vector; and so on. Do you do this in a dozen
> sepearate negotiations? Or do you maybe break it down so that you agree
> on rsa-openpgp-radix64 and aes-cbc-128 options, then perform key/IV
> exchange? This has to be worked out between developers, and it's clearly
> not something that can be extended to be useful for applications beyond
> cryptosystems.

These types of answers would have to be answered via another JEP that
explicitly defines the various options for a crypto system. The negotiation
that would take place would allow the clients to determine which options
they both support for each one of your fields, and as the JEP states, all
"related" options should be enclosed in a single iq exchange. In a crypto
system, the actual mechanics (the actual key exchange, etc..) would take
place in other iq exchanges in the negotiated namespace.

> I think this is another really interesting problem, and I think JEP-0020
> is useful to at least have a starting point for those
> developer-negotiations. Pending a few details (like who makes up the
> <option>s), I'd vote it in. I just hope we're not too over-optimistic
> about the kinds of problems it will solve.

The options for each specific namespace should be expressed in other JEPs
for each namespace. This JEP isn't proposing specific options for specific
namespaces, it's just proposing a FRAMEWORK for exchanging these options.

Here's another non-crypto example of feature negotiation for negotiating
file transfers. The sender supports receiving files (it can't send since the
client application knows that it's behind a firewall), doing a PASS
connection, and doing WebDAV.

<iq type="get" id="1" to="d at jabber.org/gabber">
  <query xmlns="jabber:iq:negotiate">
    <feature type="jabber:iq:oob">

The recipient client would know that it's NOT behind a firewall, so it can
initiate the p2p socket connection, so it responds with appropriate option

<iq type="result" id="1" to="p at jabber.org/foo">
  <query xmlns="jabber:iq:negotiate">
    <feature type="jabber:iq:oob">

Since the recipient would ALSO need to send back the IP address of it's
client so the sender can start sending the file, THAT information would be
sent back to the sender in another iq using the jabber:iq:oob namespace.

<iq type="set" id="2" to="p at jabber.org/foo">
  <query xmlns="jabber:iq:oob">
    <peer type="server">

Obviously, these children are not in the jabber:iq:oob namespace (it would
need to be appended) but this is the basic idea. The whole idea of JEP 20,
is to give the clients some kind of framework for negotiating the info that
they need to exchange. The actual exchange of the info occurs in another
namespace. As we continue to grow and expand the Jabber protocol to
encompass other applications (not just IM), this type of negotiation will
become a lot more important. The jabber:iq:browse namespace already gives us
a way to determine if a client SUPPORTS a specific namespace, but it gives
applications no way of specifying OPTIONS for that namespace.

Peter M.

More information about the Standards mailing list