The issues can best be seen from a client perspective. Given that compact format is specified as well formed XML, a client is most likely using an off the shelf XML parser. Upon receiving the data from the XML parser, the client must decode the data as per RPC-035, if it is encoded. And finally, the client must then parse the data again to split the data at the delimiters. This means that a client must perform up to three passes over the data to correctly parse it. The server is also affected as it must encode data, first substituting XML entities, and then optionally encoding as per RFC-035. This change proposal keeps the bandwidth used to transfer data small, while allowing a client to parse the data in a single pass.

compact-data = *data-row
data-row = interpretation 1*(HT data) CRLF
interpretation = *1(token)
data = text
text = *(TEXT)

To include control characters inside data, the following backslash escapes are recognized:

Escape Sequence	ASCII Equivalent
\a	7 (BEL)
\b	8 (BS)
\t	9 (HT)
\n	10 (LF)
\v	11 (VT)
\f	12 (FF)
\r	13 (CR)
\\	134 ("\", backslash)
\(octal)	Character whose ASCII encoding is "octal"
\u(hex)	Character whose Unicode encoding is "hex"

The interpretation rule provides context information to a data row. The currently known interpretations are as follows:

Token Value	Token Meaning
"RETS"	The first data element is the reply code, and the second element is the reply text.
"Columns"	This row's data specifies column names.
"Count"	This first data element is the total number of data rows returned.
"Error"	Contains four data elements: field name, error-num, error-offset, and error-text as defined in Section 10.5.
"" (no token)	This row's data specifies actual uninterpreted data.

Here is an example of the new compact format:

"RETS" HT "0" HT "Success" CR LF
"Columns" HT "STATUS" HT "OWNER" CR LF
"Count" HT "3" CR LF
HT "A" HT "Joe Schmoe" CR LF
HT "X" HT "Mary Jane" CR LF
HT "Z" HT "John\tMcCormick" CR LF