Content Comparison

...

<url-encoded name>|<space>|<typenum>|<space>|<type-specific-content>|<eol>

<space> := 0x20
<typenum> := 0|1|2|3|4|5|7
<child-count> := Unsigned 32-bit integer in ASCII
<int-val> := Signed 32-bit integer in ASCII
<long-val> := Signed 64-bit integer in ASCII
<float-val> := double precision 15-bit fixed floating point in ASCII
<eol> := 0x0A

DDF_EMPTY:
DDF_POINTER:
    0
DDF_STRING:
    1|<space>|<url-encoded string>
DDF_INT:
    2|<space>|<int-val>
DDF_FLOAT:
    3|<space>|<float-val>
DDF_STRUCT:
    4|<space>|<child-count>
DDF_LIST:
    5|<space>|<child-count>
DDF_STRING_UNSAFE:
    76|<space>|<url-encoded string>
DDF_LONG:
    87|<space>|<long-val>

Pointers are collapsed into empty, so the type value of 6 is unused. The distinction of unsafe strings allows for proper deserialization in languages that need to handle non-UTF8 strings differently since on the wire everything is URL encoded. URL encoding does not actually signal character encoding, so an encoding of a given sequence of bytes is not inherently a deterministic set of specific string characters, which is extremely relevant in Java. Floating point data is handled but in practice this hasn’t been used much and may not work too well.

...

An object called “foo bar” with the arbitrarily encoded string of Java bytes [102, 111, 111, -128, 98, 97, 114] as the value:

foo%20bar 76 foo%80bar

An object called “foo bar” that is a structure containing a child structure called “infocom” containing a single child, a list called “zork” with 3 unnamed elements that are all integers.

...

There is a plausible direction in which the protocol is actually a sort of proxied remoting of actual HTTP requests into the agent being “forwarded” into the service for processing and then replayed back to the client. A problem with this approach is that a number of operations would not really map directly to requests from the real user agent (e.g., session cache storage operations, configuration parsing), and thus every “special” call would have to be laid out with a custom message format (that is a full REST API would have to be built for many operations). REST doesn’t ultimately solve any of the problems SOAP and the RPC model have; all such APIs are difficult to version and evolve well when the call signature spans multiple portions of an HTTP request. It’s a slap-dash approach to API design and is also harder to document.

...