Subject: [Cbor] Unwrapping byte strings?

From: John Mattsson <[email-masked]>
Date: Tue, 4 Sep 2018 08:49:43 +0000

Hi,

I really like the << >> notation, very useful for wrapping things in byte strings (which is used heavily in e.g. COSE).

Would it be possible to allow the use of the "unwrap" operator ~ also on byte strings?

----------------------------------------------------------
basic-header-group = (
  field1: int,
  field2: text,
)

basic-header-bstr = << basic-header-group >>

advanced-header = [
  ~basic-header-bstr,
  field3: bytes,
]
----------------------------------------------------------
<<1>>             h'01'
~<<1>>           1
~h'02'	          2	
----------------------------------------------------------
var1: float
var2 = bytes .cbor [ var1 ]
var3 = ~~var2
----------------------------------------------------------

This would of course not work for all byte strings as not all byte strings are sequences of CBOR-encoded items, e.g. h'1e' and h'41'.

Cheers,
John

---

From: Jim Schaad <[email-masked]>
Date: Tue, 4 Sep 2018 10:14:33 -0700

I don't understand what you think you are doing here with this.  The << >>
notation is for display purposes and is not part of any language.  It is to
make things easier to see when you dump an object out.  How would you use
the "unwrap" operation in this type of process or are you looking at
expanding the usage into a completely different area?

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of John Mattsson
> Sent: Tuesday, September 4, 2018 1:50 AM
> To: [email-masked]
> Subject: [Cbor] Unwrapping byte strings?
> 
> Hi,
> 
> I really like the << >> notation, very useful for wrapping things in byte
strings
> (which is used heavily in e.g. COSE).
> 
> Would it be possible to allow the use of the "unwrap" operator ~ also on
byte
> strings?
> This would of course not work for all byte strings as not all byte strings
are
> sequences of CBOR-encoded items, e.g. h'1e' and h'41'.
> 
> Cheers,
> John
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Sep 2018 20:50:44 +0100

As Jim said -- <<>> are (extended) diagnostic notation; .cbor is the way to specify something like this in CDDL. Doing an unwrap on a control is an interesting idea. Would we always want the rhs?

Sent from mobile

> On 4. Sep 2018, at 09:49, John Mattsson <[email-masked]> wrote:
> 
> Hi,
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 5 Sep 2018 10:29:33 +0000

Thanks!

True, I see now that I mixed CDDL and the diagnostic notation. In fact, I failed to notice that draft-ietf-cbor-cddl-05 defines both CDDL and extended diagnostic notation. I think it would be good if draft-ietf-cbor-cddl-05 mentioned that it specifies extensions to the diagnostic notation in the abstract and/or introduction. Also, any reason why the extended diagnostic notation is not in draft-ietf-cbor-7049bis? 

With this updated understanding, I have somewhat different questions (hopefully with correct notation this time....):

/John

------------------------------------------

The diagnostic notation let me easily create notation for various CBOR byte strings:

<< [ "leaves", 69105 ] >>
<< { "item": "leaves", "number": 69105 } >>
<< "leaves", 69105 >>

The third variant is useful in constrained environments as it reduces the number of bytes. Review comments from 6tisch on OSCORE, EDHOC, and ACE has been along the lines of: "Great! But is it possible to save a few more bytes?"

The first two byte strings are easy to write CDDL for 

infocom = (
   item: text,
   number: int,
)

definition1 = bstr .cbor [ infocom ]
definition2 = bstr .cbor { infocom }

Is it correct that CDDL does not allow me to define anything more specific for the third byte string than:

definition3 = bstr

or am I missing some CDDL grammar?

------------------------------------------

Unwrap for byte strings would be nice in CDDL, to enable things like

mytype = bstr .cbor [
   field1: int,
   field2: text,
]

mytype2 = [
   ~mytype
   field3: bytes,
]

without having to specify a group.

------------------------------------------

I noticed that http://cbor.me does not accept any of the following diagnostic notations:

b32''
h32''
b64'00 00'
"" ""
'' ''
0x1p0
0x1.8
(_ '' )
(_ <<>> )
(_ b64'' )

I assume the 7 first are just not implemented yet. The three last examples might require some update to 7049bis or draft-ietf-cbor-cddl. 7049bis says

"byte strings of indefinite length can be notated in the form (_ h'0123', h'4567')"

I assume the intention is that all diagnostic notations for byte strings should be allowed inside (_ ), or?

Also, as there is diagnostic notation for a definite-length byte string wrapping any sequence of CBOR data items

<< "leaves", 69105 >>

why is one of the following notations not allowed for an indefinite-length byte string wrapping the same CBOR data items

 (_ "leaves", 69105 )
<<_ "leaves", 69105 >>

Also, arrays and maps have very similar diagnostic notation for definite and indefinite encodings, while byte strings have completely different notation....

[ ]     vs [_ ]
{ }     vs {_ }
<< >>   vs (_ )
 
------------------------------------------

On 2018-09-04, 21:51, "Carsten Bormann" <mailto:[email-masked]> wrote:

On 4. Sep 2018, at 09:49, John Mattsson <mailto:[email-masked]> wrote:
Hi,

advanced-header = [
 ~basic-header-bstr,
 field3: bytes,
]

Cheers,
John

mailto:[email-masked]

---

From: John Mattsson <[email-masked]>
Date: Wed, 5 Sep 2018 10:37:10 +0000

Correction, should have been:

mytype2 = [
   ~~mytype
   field3: bytes,
]

On 2018-09-05, 12:29, "John Mattsson" <[email-masked]> wrote:

Thanks!

/John

infocom = (
   item: text,
   number: int,
)

definition3 = bstr

mytype = bstr .cbor [
   field1: int,
   field2: text,
]

mytype2 = [
   ~mytype
   field3: bytes,
]

b32''
h32''
b64'00 00'
"" ""
'' ''
0x1p0
0x1.8
(_ '' )
(_ <<>> )
(_ b64'' )

<< "leaves", 69105 >>

 (_ "leaves", 69105 )
<<_ "leaves", 69105 >>

[ ]     vs [_ ]
{ }     vs {_ }
<< >>   vs (_ )

advanced-header = [
 ~basic-header-bstr,
 field3: bytes,
]

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Sep 2018 13:44:43 +0100

Quick answer to the first question: CDDL already defines .cborseq

Sent from mobile

> On 5. Sep 2018, at 11:29, John Mattsson <[email-masked]> wrote:
> 
> Thanks!
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 5 Sep 2018 13:02:21 +0000

Thanks, so would the following CDDL

definition3 = bstr .cborseq [ item: text, number: int ]

then match the CBOR encoding of << "leaves", 69105 >> 

I think it would be good with some examples using concrete types in Section 3.8.4 of draft-ietf-cbor-cddl. We had different internal interpretations of how to interpret the .cborseq operator.

/John

On 2018-09-05, 12:37, "John Mattsson" <[email-masked]> wrote:

mytype2 = [
   ~~mytype
   field3: bytes,
]

Thanks!

/John

infocom = (
   item: text,
   number: int,
)

definition3 = bstr

mytype = bstr .cbor [
   field1: int,
   field2: text,
]

mytype2 = [
   ~mytype
   field3: bytes,
]

b32''
h32''
b64'00 00'
"" ""
'' ''
0x1p0
0x1.8
(_ '' )
(_ <<>> )
(_ b64'' )

<< "leaves", 69105 >>

 (_ "leaves", 69105 )
<<_ "leaves", 69105 >>

[ ]     vs [_ ]
{ }     vs {_ }
<< >>   vs (_ )

advanced-header = [
 ~basic-header-bstr,
 field3: bytes,
]

Cheers,
John