control-spec.txt 2.1 [says](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=795420240305a6d67c0f4322993a65da4c7b6f2f#n110): > === 2.1. Description format === > We use the following nonterminals from RFC 2822: `atom`, `qcontent` > ... > `QuotedString = DQUOTE *qcontent DQUOTE` > ... > === 2.1.1. Notes on an escaping bug === > `CString = DQUOTE *qcontent DQUOTE` RFC 2822 [defines](https://tools.ietf.org/html/rfc2822#section-3.2.5) `qcontent` thus: ``` qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair ``` where `NO-WS-CTL` [expands to](https://tools.ietf.org/html/rfc2822#section-3.2.1) ``` NO-WS-CTL = %d1-8 / ; US-ASCII control characters %d11 / ; that do not include the %d12 / ; carriage return, line feed, %d14-31 / ; and white space characters %d127 ``` In short, `qcontent` does not include the space character (ascii 32), and so according to a strict reading of the spec, anything that produces a QuotedString or CString has to escape spaces as `\ ` or `\040`. The reason why RFC 2822 does not require space to be escaped is that the definition of `quoted-string` is not `DQUOTE *qcontent DQUOTE` as in control-spec.txt, but also allows whitespace as part of the `[FWS]` production: ``` quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] ``` I notice that tor doesn't escape the space character (in `esc_for_log` and `unescape_string` for example). IMO tor is doing the right, expected thing and the spec should be clarified.