NetworkStructureWorkPage

To Do

mechanism to limit messages per unit time per connection
message signing

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:

S-expressions
YAML
JSON

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:

ASN.1

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

Unsupported field: Field name not supported. Should give path to erroneous field in message, eg, "/offer/nodes[0]/elephant" would indicate that the field name "elephant" in the first node in the "nodes" array of a received offer message is unsupported. Note that this sort of path representation implies that Ripple field names should not contain the slash character, "/".
Missing field: A required field is missing from the message. Should give path to missing field.
Bad value: Should specify the path to the field with the bad value. Note that there may be more specific error messages than this in certain cases, but that this error should be used when no more specific error is available.
Request withdrawn: Error in reply to an affirmative response to an earlier request that the requesting node no longer wishes to be fulfilled. Should include request ID.
Unrecognized request ID: Recipient does not recognize the request ID of a message in response to a request.
Message must be signed: Recipient of an unsigned message requires that the message be signed by sender.