Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited?

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 May 2018 10:33:19 +1200

On 01/05/2018 08:43, Burt Harris wrote:
> After reading RFC 7049, it seemed apparent to me that the JSON string type would generally be encoded in CBOR as major type 3 (text string).   
> 
> However reviewing section 4.2, which is specifically about converting JSON to CBOR, nowhere does this rule seem stated explicitly.   I would normally not have considered this a problem, but I encountered examples in one of the tag definition documents <http://cbor.schmorp.de/stringref> uses where the author seems to interpret the RFC as saying that CBOR major type 2 (byte string) may be used as an alternative.  
> 
> Take for example, the 3-charactar JSON content "1" (with quotes included in the JSON.)     I've been surprised about how adamant the other author has been that this may be encoded as 41 31, when it seemed clear to me that 61 31 was the canonical encoding.   
> 
> I therefor wonder if it might be a good idea to add language to the CBOR bis document saying that JSON strings should always be encoded as CBOR major type 3, and that in general major type 2 would be unexpected in the result of a JSON to CBOR translation.

That statement seems OK. However, "explicitly prohibited" sounds wrong to me, because there might be cases where it was reasonable to send a piece of text that just happens to be JSON as plain text. In that case there is no "translation" from JSON to CBOR; the application is just using CBOR to transport a piece of text.

   Brian

---

From: Burt Harris <[email-masked]>
Date: Wed, 2 May 2018 15:04:03 +0000

On 2018-05-01 Brian Carpenter wrote:

> That statement seems OK. However, "explicitly prohibited" sounds wrong to me, because there might be cases where it was reasonable to send a piece of text that just happens to be JSON as plain text. 
> In that case there is no "translation" from JSON to CBOR; the application is just using CBOR to transport a piece of text.

Thanks Brian, yes my attempt to summarize in the subject line could use refinement, using language defined in RFC 2119.   I think we have the same idea in mind.   What I'm suggesting is adding a sentence to RFC 7049 section 4.2 **Converting from JSON to CBOR** saying:

    JSON strings MUST be represented as CBOR text strings (major type 2) and SHOULD be represented in the shortest form allowed.

What "plain text" means in your comment seems a bit ambiguous.   If someone *encodes text* as CBOR and that happens to be valid JSON, e.g. three characters `[1]`, the CBOR output SHOULD be the following 4 bytes:

    63        # text(3)
       5B315D # "[1]" 

While if someone *converts* the same 3-character  JSON to CBOR, the expected bytes would be:

  81    # array(1)
     01 # unsigned(1)

What MUST NOT be output would be:

    43        # bytes(3)
       5B315D # "[1]"
 
Because the input was specified to be text (not bytes.)

-----Original Message-----
From: Brian Carpenter <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Tuesday, May 1, 2018 3:33 PM
To: Burt Harris <[email-masked]>; [email-masked]
Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited?

On 01/05/2018 08:43, Burt Harris wrote:
> However reviewing section 4.2, which is specifically about converting JSON to CBOR, nowhere does this rule seem stated explicitly.   I would normally not have considered this a problem, but I encountered examples in one of the tag definition documents <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcbor.schmorp.de%2Fstringref&data=02%7C01%7C%7C5d56b249df454ac7a64b08d5afb38cf8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636608108049523728&sdata=CKgwjnm21k%2F7%2BPKgNPYHFa%2BsRlWLVIGBgyY4PJKGLu8%3D&reserved=0> uses where the author seems to interpret the RFC as saying that CBOR major type 2 (byte string) may be used as an alternative.  
> 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 May 2018 14:07:13 +1200

Yes, I think we agree.

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 May 2018 11:19:13 +0200

Hi Burt,

thank you for pointing out the need for a clarification here.
Have you had some conversation with the author of the 256/25 tag spec?

>    JSON strings MUST be represented as CBOR text strings (major type 2) and SHOULD be represented in the shortest form allowed.

4.2 assumes that this is all obvious, except for numbers.
Maybe we should add a table providing the mapping for all types, not just for text strings?

The recommendation for the shortest form also applies to the other types, as well, no?

Note that the entirety of Section 4 is meant to be non-normative, so using RFC 2119 language would be confusing.

Grüße, Carsten

---

From: Burt Harris <[email-masked]>
Date: Thu, 3 May 2018 15:26:59 +0000

Yes I have.   I've also invited him to participate here.

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Thursday, May 3, 2018 2:19 AM
To: Burt Harris <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited?

Hi Burt,

Grüße, Carsten