Original text:
Only the UTF-8 form of JSON is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. <del> Characters in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </del>  Systems receiving measurements MUST be able to process the range of floating point numbers that are representable as an IEEE double value, it has exactly the same value as the original Number.  For the version number, only an unsigned integer is allowed.  For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; 7. A SenML Pack or Stream can also be represented in XML format as <del> defined in this section.  The following example shows an XML example for the same sensor measurement as in co-ex. </del>  The SenML Stream is represented as a sensml tag that contains a series of senml tags for each SenML Record.  The SenML Fields are

Reviewer comments:
I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian
Indeed, characters should be called characters, and bytes should be called bytes. (In C, bytes are represented as uint8_t :-). s/can be/are/ (they are!)
Have a read of the PR I put in for this. I think it resolves the issue
Looks good to me (with the one typo fix)
typo fix

Revised text:
Only the UTF-8 form of JSON is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159.  <ins> Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </ins> Systems receiving measurements MUST be able to process the range of floating point numbers that are representable as an IEEE double value, it has exactly the same value as the original Number.  For the version number, only an unsigned integer is allowed. <ins> Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using a definite length byte string (type 2) . </ins> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; 7. A SenML Pack or Stream can also be represented in XML format as  <ins> defined in this section. Only the UTF-8 form of XML is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. The following example shows an XML example for the same sensor measurement as in co-ex. </ins> The SenML Stream is represented as a sensml tag that contains a series of senml tags for each SenML Record.  The SenML Fields are