Correct. Remoting needs a strong guarentee. The main issue is future revs of remoting need to be validated before being incorporated into jms.

As far as versioning goes, I can't really take the same approach as jms (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76752) where write out version as first byte to wire. This is because a remoting client or server can be used with other thirdparty components (i.e. http remoting client talking to 3rd party web server). Therefore, the best I can do is implement versioning in the externalizing of the remoting objects I expect to pass over the wire (and there are a lot these).

As for features, older features should be usable in future versions (so can use old clients with newer servers). However, newer clients won't necessarily work with older servers (at least the new features won't be supported by the server).

What matters is that remoting can be configured to the requirements of jms, otherwise jms cannot rely on remoting for its stable transport layer. Although a specific wire format may not be a requirement, one should be able to take control of it. In the case of the http transport, we should be able to map a format version to a header, or first byte of the post content, etc.