Specific details for UTF-8 Strings

Add the following to section 2.1.2 The encoded data must be well-formed UTF-8 as defined by the Unicode spec [Unicode] , and restated in RFC 3629 [RFC 3629] . In particular the encoded data MUST NOT include encodings of codepoints between U+D800 and U+DFFF. If a receiver (server or client) receives a control packet containing ill-formed UTF-8 it MUST close the network connection. The data MUST NOT include an encoding of the null character U+0000. If a receiver (server or client) receives a control packet containing U+0000 it MUST close the network connection. The data SHOULD NOT include encodings of the Unicode codepoints listed below. If a receiver (server or client) receives a control packet containing any of them it MAY close the network connection. U+0001..U+001F control characters U+007F..U+009F control characters Codepoints defined in the Unicode spec to be noncharacters (for example U+0FFFF) The UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO WIDTH NO-BREAK SPACE") wherever it appears in a string and must never be skipped over or stripped off by a packet receiver. Add the following to section 4.7.3 When it performs subscription matching the server does not perform any normalization of Topic Names/Filters, or any modification or substitution of unrecognised characters. Each non-wildcarded level in the Topic Filter has to match the corresponding level in the Topic Name character for character for the match to succeed. Non-normative comment. The UTF-8 encoding rules mean that the comparison of Topic Filter and Topic Name could be performed either by comparing the encoded UTF-8 bytes, or by comparing decoded Unicode characters Update the normative reference (in section 1.3) to Unicode 6.3