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

Mike Lin mikelin at MIT.EDU
Mon Mar 4 05:06:28 UTC 2002


Peter, I agree with almost everything you're saying. I think the point
of what I originally wrote was not sufficiently clear, so I'd like to
explain it in more detail. This also goes back a bit to temas' previous
email, which is similar in theme.

I wrote out the example of the options that would be needed to negotiate
options for a cryptosystem to illustrate that JEP-0020 defines a rough
syntax for negotiation, but nothing more. There is still a lot of work
that needs to be done between developers to usefully perform negotiation
based upon it; the options have to be specified in a JEP, and so forth.

Now, you'd never use JEP-0020 to negotiate features between two
namespaces (like jabber:iq:crypto and jabber:iq:oob). That just doesn't
make sense; their options are unrelated.

So what you have, really, are two semantically distinct protocols, which
never mix with each other, but which happen to use the same syntax. You
could use a different syntax for each, and lose no functionality
whatsoever.

Of course, it's probably a good thing to use consistent syntax, which is
why I like JEP-0020. I would just like to see it more explicitly spelled
out in the JEP that it defines a syntax only. For example, I don't think
the statement that jabber:iq:negotiate "would enable Jabber entities to
exchange packets to agree on feature options" captures this. We can do
that anyway, obviously, since Ashvil is already doing it. JEP-0020
simply defines a useful syntactic starting point for defining different
negotiation protocols.

-Mike


On Sun, 2002-03-03 at 23:44, Peter Millard wrote:
> 
> ----- 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">
>       <option>peer-receive</option>
>       <option>pass</option>
>       <option>webdav</option>
>     </feature>
>   <query>
> </iq>
> 
> 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
> (peer-receive).
> 
> <iq type="result" id="1" to="p at jabber.org/foo">
>   <query xmlns="jabber:iq:negotiate">
>     <feature type="jabber:iq:oob">
>       <option>peer-receive</option>
>     </feature>
>   </query>
> </iq>
> 
> 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">
>       <ip>111.222.333.444</ip>
>       <port>8698</port>
>     </peer>
>   </query>
> </iq>
> 
> 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.
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 





More information about the Standards mailing list