To Do
Binding to a Transport Layer
What should be mentioned is that nodes that use two different transport layers cannot interoperate, so in order to achieve the goal of a single interoperable Ripple network, one transport layer must be standardized.
Right now, SCTP seems like the best choice, although other options are XMPP over TCP or BEEP over TCP.
Message Syntax
XML is admittedly verbose. Other textual options are:
These are all probably more suited for private data interchange between two nodes than XML. It's not like Ripple messages will ever be consumed in unknown ways by arbitrary numbers of users. If that was the case, a REST-style design would be more fitting for Ripple (tried it and junked it).
Out of them all, JSON is probably the simplest and therefore fastest to parse. There are JSON tools for nearly every programming language. It is sufficient for our purpose. I (Ryan) nominate JSON. The JSON spec says that JSON is encoded in "Unicode". Maybe we should specify UTF-8 only?
And then of course, the binary options:
Binary encoding offers better processing speed, however with the availability of cheap processing power, this probably shouldn't be the main consideration. Besides, routing calculations will likely be a far more onerous burden on the CPU of any Ripple host. The choice should probably be dictated by what we are most comfortable with.
To add: Message Signing
Need a format for signed messages. Something like:
{ signed-message: { "content": { [Ripple message] }, "algorithm": { "hash": [algorithm used to create message digest], "sign": [algorithm used to encrypt message digest], } "signature": [base64-encoded signature], }
All characters between the "content" braces would be included in the data to be signed/verified.
Or maybe just use OpenPGP standard format?
Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format... Although, parsing base64 to binary is a trivial transformation.
To add: Error Codes