Subject: [Teep] JSON/JOSE vs. CBOR/COSE

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Feb 2020 10:16:27 +0000

Hi all,

With the impression from the Hackathon in mind I am wondering whether we should make a decision about the encoding of the TEEP protocol messages. Today, the spec allows two types of encodings, namely JSON and CBOR (with their security mechanisms).

It is obviously a pain to implement both encodings. The spec supports two encodings because the OTrP design was based on JSON / JOSE and it felt logical to "inherit" this encoding. Then, we added CBOR and COSE for use with constrained devices.

I believe we should only have one encoding.

CBOR and COSE appear to be the better choice (although I have been working on an implementation of JSON and JOSE at the Hackathon). While JSON/JOSE is easier to debug the TEEP protocol is actually quite simple. The use of CBOR/COSE will allow us to keep the trusted computing base smaller considering that SUIT manifests as well as EAT tokens are/can be encoded in CBOR and protected by COSE.

With this email I wanted to kick-off a discussion. What do you think?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 20 Feb 2020 11:50:58 +0100

Hi Hannes,

> I believe we should only have one encoding.

+1

The use of CBOR/COSE will allow us to keep the trusted computing base
> smaller

+1 for keeping things small when possible.

Cheers,

Emmanuel

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 13:21:26 +0100

> With the impression from the Hackathon in mind I am wondering whether
    > we should make a decision about the encoding of the TEEP protocol
    > messages. Today, the spec allows two types of encodings, namely JSON
    > and CBOR (with their security mechanisms).

    > It is obviously a pain to implement both encodings. The spec supports
    > two encodings because the OTrP design was based on JSON / JOSE and it
    > felt logical to "inherit" this encoding. Then, we added CBOR and COSE
    > for use with constrained devices.

    > CBOR and COSE appear to be the better choice (although I have been

I also agree.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 20 Feb 2020 07:27:44 -0500

Hi Hannes,
hi all,

I agree with this statement wrt to teep and beyond.

Viele Grüße,

Henk

On 20.02.20 05:16, Hannes Tschofenig wrote:
> Hi all,
> 
> With the impression from the Hackathon in mind I am wondering whether we 
> should make a decision about the encoding of the TEEP protocol messages. 
> Today, the spec allows two types of encodings, namely JSON and CBOR 
> (with their security mechanisms).
> 
> felt logical to “inherit” this encoding. Then, we added CBOR and COSE 
> working on an implementation of JSON and JOSE at the Hackathon). While 
> JSON/JOSE is easier to debug the TEEP protocol is actually quite simple. 
> smaller considering that SUIT manifests as well as EAT tokens are/can be 
> encoded in CBOR and protected by COSE.
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.
> 
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 20 Feb 2020 15:22:35 +0100

I believe I suggested exactly this a while ago...

Anders

---

From: Nicolae Paladi <[email-masked]>
Date: Thu, 20 Feb 2020 14:26:13 +0000

On 20 Feb 2020, at 11:16, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

It is obviously a pain to implement both encodings. The spec supports two encodings because the OTrP design was based on JSON / JOSE and it felt logical to “inherit” this encoding. Then, we added CBOR and COSE for use with constrained devices.

I agree, better to focus on one format.

Best regards,
Nicolae

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 20 Feb 2020 09:22:01 -0800

I agree we move forward TEEP protocol with one mandatory format: CBOR /
COSE, and focus on specifying only one for now. Thanks, Ming

On Thu, Feb 20, 2020 at 6:26 AM Nicolae Paladi <[email-masked]> wrote:

>
>
> On 20 Feb 2020, at 11:16, Hannes Tschofenig <[email-masked]>
> wrote:
>
> Hi all,
>
> Today, the spec allows two types of encodings, namely JSON and CBOR (with
> their security mechanisms).
>
> It is obviously a pain to implement both encodings. The spec supports two
> encodings because the OTrP design was based on JSON / JOSE and it felt
> logical to “inherit” this encoding. Then, we added CBOR and COSE for use
> with constrained devices.
>
> CBOR and COSE appear to be the better choice (although I have been working
> on an implementation of JSON and JOSE at the Hackathon). While JSON/JOSE is
> easier to debug the TEEP protocol is actually quite simple. The use of
> CBOR/COSE will allow us to keep the trusted computing base smaller
> considering that SUIT manifests as well as EAT tokens are/can be encoded in
> CBOR and protected by COSE.
>
>
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> <https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
>
>
> https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 21 Feb 2020 09:43:44 +0000

The protocol draft can discuss either CBOR to JSON conversion or diagnostic notation discussed in https://tools.ietf.org/html/rfc7049#section-6 to ease debugging.

-Tiru

From: TEEP <[email-masked]> On Behalf Of Mingliang Pei
Sent: Thursday, February 20, 2020 10:52 PM
To: Nicolae Paladi <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] JSON/JOSE vs. CBOR/COSE

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I agree we move forward TEEP protocol with one mandatory format: CBOR / COSE, and focus on specifying only one for now. Thanks, Ming

On Thu, Feb 20, 2020 at 6:26 AM Nicolae Paladi <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Best regards,
Nicolae

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep<https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 21 Feb 2020 04:48:45 -0500

Hi Tiru,

I'd stay in the scope of CBOR and use cbor-diag. As cbor-diag can be 
directly translated into CBOR data items, that is the notation I am 
working with on a daily basis.

If needed, a JSON data item can be derived from cbor-diag quite easily.

Viele Grüße,

Henk

On 21.02.20 04:43, Konda, Tirumaleswar Reddy wrote:
> The protocol draft can discuss either CBOR to JSON conversion or 
> diagnostic notation discussed in 
> https://tools.ietf.org/html/rfc7049#section-6 to ease debugging.
> 
> -Tiru
> 
> *From:* TEEP <[email-masked]> *On Behalf Of * Mingliang Pei
> *Sent:* Thursday, February 20, 2020 10:52 PM
> *To:* Nicolae Paladi <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; [email-masked]
> *Subject:* Re: [Teep] JSON/JOSE vs. CBOR/COSE
> 
> *CAUTION*:External email. Do not click links or open attachments unless 
> you recognize the sender and know the content is safe.
> 
> ------------------------------------------------------------------------
> 
>         On 20 Feb 2020, at 11:16, Hannes Tschofenig
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
> 
>         Hi all,
> 
>         With the impression from the Hackathon in mind I am wondering
>         whether we should make a decision about the encoding of the TEEP
>         protocol messages. Today, the spec allows two types of
>         encodings, namely JSON and CBOR (with their security mechanisms).
> 
>         It is obviously a pain to implement both encodings. The spec
>         supports two encodings because the OTrP design was based on JSON
>         / JOSE and it felt logical to “inherit” this encoding. Then, we
>         added CBOR and COSE for use with constrained devices.
> 
>         CBOR and COSE appear to be the better choice (although I have
>         been working on an implementation of JSON and JOSE at the
>         Hackathon). While JSON/JOSE is easier to debug the TEEP protocol
>         is actually quite simple. The use of CBOR/COSE will allow us to
>         keep the trusted computing base smaller considering that SUIT
>         manifests as well as EAT tokens are/can be encoded in CBOR and
>         protected by COSE.
> 
>         IMPORTANT NOTICE: The contents of this email and any attachments
>         are confidential and may also be privileged. If you are not the
>         intended recipient, please notify the sender immediately and do
>         not disclose the contents to any other person, use it for any
>         purpose, or store or copy the information in any medium. Thank
>         you. _______________________________________________
>         TEEP mailing list
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Feb 2020 12:29:34 +0100

On 2020-02-21, at 10:48, Henk Birkholz <[email-masked]> wrote:
> use cbor-diag

Just in case this term is not well-known:
CBOR diagnostic notation was originally defined in Section 6 of RFC 7049 and has been extended in Appendix G of RFC 8610.

https://tools.ietf.org/html/rfc7049#section-6
https://tools.ietf.org/html/rfc8610#appendix-G

Every JSON text also is an instance of CBOR diagnostic notation, i.e., CBOR diagnostic notation is a strict superset of JSON.

A few tools support CBOR diagnostic notation, e.g.,

	gem install cbor-diag

… and then convert for example with

	diag2cbor.rb foo.diag >foo.cbor

(See below for more info.)

There is also support in https://crates.io/crates/cbor-diag-cli

Grüße, Carsten

gem install cbor-diag

gives you the tools:

cbor2diag.rb
cbor2json.rb
cbor2pretty.rb
cbor2yaml.rb
diag2cbor.rb
diag2pretty.rb
json2cbor.rb
json2pretty.rb

which do pretty much what you would expect them to do, given these
definitions:

"cbor" is binary CBOR.
"diag" is CBOR's diagnostic notation.
"json" is JSON.
"pretty" is the pretty-printed representation of binary CBOR as used by
cbor.me.).
"yaml" is YAML.

Output is to stdout, input from stdin or files given as command line
arguments). (json2cbor.rb also has a -v option.)

---

From: Akira Tsukamoto <[email-masked]>
Date: Mon, 24 Feb 2020 22:01:02 +0900

I mistakenly dropped many addresses when I pressed button gmail, this
is resend which I sent to Henk only.

>         manifests as well as EAT tokens are/can be encoded in CBOR and

The Hackathon at  Berlin was really productive and thanks.

I personally do not mind if the protocol spec becomes having only
CBOR/COSE and drop JSON/JOSE.

I think we have two discussion on this topic, one is completing the
draft and other is whether the TAM
implementation must support support both CBOR and JSON.

It is very good to have some kind of reference implementation of TEEP
along side with the spec draft,
so I would prefer having the current implementation started on JSON to
be finished and fill out the
details in the spec for what we have discussed during the Hakathon.

The sequences of TEEP in JSON which I was wroking on at the Hackathon
are still not mature.
https://github.com/ietf-teep/teep-protocol/issues/7
The suit representation is not there yet either.

These are the links I would like to reflect on the draft before the
next IETF hackathon.
https://github.com/ietf-teep/architecture/issues/151
https://github.com/ietf-teep/teep-protocol/issues/6
https://github.com/ietf-teep/teep-protocol/issues/5
https://github.com/ietf-teep/teep-protocol/issues/4 <- we had
conclusion at the Hakathon on this

Otherwise I am bit concerned many people having different
interpretation from reading the draft and
many implementation suffering interoperability.
Once the details is addressed in the JSON then having CBOR
representation in the spec is fine.
The cbor-diag tool mentioned by Carsten at the other thread is great.
It is good if somebody starts CBOR implementation in the time being.

My thought was that switching to CBOR only and no JSON now for the
Hackathon is that the
TAM side is possible to talk CBOR relatively easy since there is "npm
install cbor" to use cbor
library with javascript, but for the implementation on TEEP device
side, there are cn-cbor and
tiny-cbor for c language which is not so easy for try and error and
changing the message
formats while the draft is also moving.

The other topic of requiring the TAM to support both JSON and CBOR in the draft,
I do not feel that it should have to support both.
TAM talking otrp with json or/either teep with cbor is fine for me.

-Akira

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Feb 2020 13:12:39 +0000

Thanks, Akira.

If we decide to only use CBOR/COSE for the TEEP protocol then the draft becomes simpler. It still make sense to put examples with CBOR diagnostic format into the draft. That's something we should certainly do.

I am pushing for a decision about this topic because
* the draft needs to be updated in time for the IETF submission deadline,
* the reference implementations need to progress, and
* making a decision gives us clarity about the direction we are heading.

For the reference implementation I am wondering whether it makes sense to re-use QCBOR and an enhanced version* of t_cose. Hackathon participants were quite impressed with QCBOR and t_cose.

Ciao
Hannes

*: I am speaking about an enhanced version because t_cose implements only verifying digital signatures. The sign functionality is missing. (At least that's my understanding.)

-----Original Message-----
From: Akira Tsukamoto <[email-masked]>
Sent: Monday, February 24, 2020 2:01 PM
To: Henk Birkholz <[email-masked]>
Cc: Konda Tirumaleswar Reddy <[email-masked]>; Mingliang Pei <mingliang.pei=[email-masked]>; Nicolae Paladi <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Fwd: [Teep] JSON/JOSE vs. CBOR/COSE

I mistakenly dropped many addresses when I pressed button gmail, this is resend which I sent to Henk only.

I personally do not mind if the protocol spec becomes having only CBOR/COSE and drop JSON/JOSE.

I think we have two discussion on this topic, one is completing the draft and other is whether the TAM implementation must support support both CBOR and JSON.

It is very good to have some kind of reference implementation of TEEP along side with the spec draft, so I would prefer having the current implementation started on JSON to be finished and fill out the details in the spec for what we have discussed during the Hakathon.

The sequences of TEEP in JSON which I was wroking on at the Hackathon are still not mature.
https://github.com/ietf-teep/teep-protocol/issues/7
The suit representation is not there yet either.

These are the links I would like to reflect on the draft before the next IETF hackathon.
https://github.com/ietf-teep/architecture/issues/151
https://github.com/ietf-teep/teep-protocol/issues/6
https://github.com/ietf-teep/teep-protocol/issues/5
https://github.com/ietf-teep/teep-protocol/issues/4 <- we had conclusion at the Hakathon on this

Otherwise I am bit concerned many people having different interpretation from reading the draft and many implementation suffering interoperability.
Once the details is addressed in the JSON then having CBOR representation in the spec is fine.
The cbor-diag tool mentioned by Carsten at the other thread is great.
It is good if somebody starts CBOR implementation in the time being.

My thought was that switching to CBOR only and no JSON now for the Hackathon is that the TAM side is possible to talk CBOR relatively easy since there is "npm install cbor" to use cbor library with javascript, but for the implementation on TEEP device side, there are cn-cbor and tiny-cbor for c language which is not so easy for try and error and changing the message formats while the draft is also moving.

The other topic of requiring the TAM to support both JSON and CBOR in the draft, I do not feel that it should have to support both.
TAM talking otrp with json or/either teep with cbor is fine for me.

-Akira

On Fri, Feb 21, 2020 at 6:49 PM Henk Birkholz <[email-masked]> wrote:
> > *CAUTION*:External email. Do not click links or open attachments
> > unless you recognize the sender and know the content is safe.
> >
> > I agree we move forward TEEP protocol with one mandatory format:
> > CBOR / COSE, and focus on specifying only one for now. Thanks, Ming
> >
> > <https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3
> > A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
> >
> > https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A
> > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
> >
> >

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 24 Feb 2020 14:24:00 +0100

Hi all,

while I am of course in favor of using cbor-diag, please mind that would 
be a CBOR instance example. In general, the message structure (that the 
cbor-diag is an example of) should be illustrated (or specified, 
depending on the nature of the document) in CDDL.

I do not object to start with JSON and then finalizing with CBOR only, 
in principle. The only caveat here is that a lot of the benefits by 
using CBOR only that were highlighted in this thread are lost for the 
most part of the way, if you start with JSON.

Viele Grüße,

Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Feb 2020 13:39:43 +0000

My idea was to use
* CDDL to describe the protocol messages (as it is already done in the spec).
* the CBOR diagnostic format for examples.
* CBOR for the over-the-wire encoding.
* COSE as the security-wrapper for the protocol messages.

I believe this is also inline with your thinking. Correct?

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: Monday, February 24, 2020 2:24 PM
To: Hannes Tschofenig <[email-masked]>; Akira Tsukamoto <[email-masked]>
Cc: Konda Tirumaleswar Reddy <[email-masked]>; Mingliang Pei <mingliang.pei=[email-masked]>; Nicolae Paladi <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] JSON/JOSE vs. CBOR/COSE

Hi all,

while I am of course in favor of using cbor-diag, please mind that would be a CBOR instance example. In general, the message structure (that the cbor-diag is an example of) should be illustrated (or specified, depending on the nature of the document) in CDDL.

I do not object to start with JSON and then finalizing with CBOR only, in principle. The only caveat here is that a lot of the benefits by using CBOR only that were highlighted in this thread are lost for the most part of the way, if you start with JSON.

Viele Grüße,

Henk

On 24.02.20 08:12, Hannes Tschofenig wrote:
> *: I am speaking about an enhanced version because t_cose implements
> only verifying digital signatures. The sign functionality is missing.
> (At least that's my understanding.)
>
> Cc: Konda Tirumaleswar Reddy <[email-masked]>;
> Mingliang Pei <mingliang.pei=[email-masked]>; Nicolae
> Paladi <[email-masked]>; Hannes Tschofenig
> <[email-masked]>; teep <[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 24 Feb 2020 14:44:15 +0100

Yes, absolutely. +4 on all four points.

I just wanted to highlight Akira's comment that was:

On 24.02.20 07:09, Akira Tsukamoto wrote:
> I would prefer having the current implementation started on JSON to
> be finished and fill out the details in the spec for what we have discussed during the Hakathon.

This approach would deduct from the benefits that were illustrated in 
this thread. I am not in favor of this approach, but there might be 
necessities that I am unaware of?

Viele Grüße,

Henk

---

From: 塚本明 <[email-masked]>
Date: Tue, 25 Feb 2020 08:37:26 +0000

On 2020/02/24 22:44, Henk Birkholz wrote:
> This approach would deduct from the benefits that were illustrated in this thread. I am not in favor of this approach, but there might be necessities that I am unaware of?

I am not sure which is beneficial or not, but I just did not see comments for the teep draft
from the implementation perspective from who have tried CBOR on teep at the moment,
so I felt that being able to start early with JSON was a good thing.

Also, during the hackathon at Berlin, we did have a code to show the contents of
teem messages in the sources but at the end we had to use WireShark to debug
when we could not figure out why it is giving some of the parsing errors for received message,
so having text representation in the binary packet helped the prototyping.

I am ok for CBOR only after everything is smoothed out, just wanted to make things forward.

-Akira

>>> My thought was that switching to CBOR only and no JSON now for the Hackathon is that the TAM side is possible to talk CBOR relatively easy since there is "npm install cbor" to use cbor library with javascript, but for the implementation on TEEP device 
>>> side, there are cn-cbor and tiny-cbor for c language which is not so easy for try and error and changing the message formats while the draft is also moving.
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for 
>>> any purpose, or store or copy the information in any medium. Thank you.
>>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any 
>> purpose, or store or copy the information in any medium. Thank you.
>>
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Feb 2020 09:40:39 +0100

> so having text representation in the binary packet helped the prototyping.

Wireshark has a CBOR dissector.
Maybe we should collect some information about how to best use tools like Wireshark for debugging and diagnostics.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Feb 2020 08:41:02 +0000

I believe it is fine for anyone to start coding the messages in JSON for a prototype, as we did at the Hackathon, but another thing to describe two encodings in the spec. This does create a fair amount of interoperability problems later on. FWIW I am going to change my code to CBOR/COSE

-----Original Message-----
From: 塚本明 <[email-masked]>
Sent: Tuesday, February 25, 2020 9:37 AM
To: Henk Birkholz <[email-masked]>; Hannes Tschofenig <[email-masked]>
Cc: Konda Tirumaleswar Reddy <[email-masked]>; Nicolae Paladi <[email-masked]>; teep <[email-masked]>; Mingliang Pei <mingliang.pei=[email-masked]>
Subject: Re: [Teep] JSON/JOSE vs. CBOR/COSE

> This approach would deduct from the benefits that were illustrated in this thread. I am not in favor of this approach, but there might be necessities that I am unaware of?

I am not sure which is beneficial or not, but I just did not see comments for the teep draft from the implementation perspective from who have tried CBOR on teep at the moment, so I felt that being able to start early with JSON was a good thing.

Also, during the hackathon at Berlin, we did have a code to show the contents of teem messages in the sources but at the end we had to use WireShark to debug when we could not figure out why it is giving some of the parsing errors for received message, so having text representation in the binary packet helped the prototyping.

-Akira

>> Paladi <[email-masked]>; teep <[email-masked]>
>> while I am of course in favor of using cbor-diag, please mind that
>> would be a CBOR instance example. In general, the message structure (that the cbor-diag is an example of) should be illustrated (or specified, depending on the nature of the document) in CDDL.
>>
>>> It is very good to have some kind of reference implementation of
>>> TEEP along side with the spec draft, so I would prefer having the current implementation started on JSON to be finished and fill out the details in the spec for what we have discussed during the Hakathon.
>>>
>>> Hackathon is that the TAM side is possible to talk CBOR relatively easy since there is "npm install cbor" to use cbor library with javascript, but for the implementation on TEEP device side, there are cn-cbor and tiny-cbor for c language which is not so easy for try and error and changing the message formats while the draft is also moving.
>>>
>>>> I'd stay in the scope of CBOR and use cbor-diag. As cbor-diag can
>>>> be directly translated into CBOR data items, that is the notation I
>>>> am working with on a daily basis.
>>>>
>>>>> ------------------------------------------------------------------
>>>>> --
>>>>> ----
>>>>>
>>>>> On Thu, Feb 20, 2020 at 6:26 AM Nicolae Paladi
>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>           With this email I wanted to kick-off a discussion. What
>>>>> do you
>>>>>           think?
>>>>>
>>>>>           Ciao
>>>>>
>>>>>           Hannes
>>>>>
>>>>> <https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https
>>>>> %3 A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
>>>>>
>>>>> https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%
>>>>> 3A %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>>>>>
>>>>>
>>> confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>
>> confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>
>

---

From: 塚本明 <[email-masked]>
Date: Tue, 25 Feb 2020 08:49:08 +0000

> Maybe we should collect some information about how to best use tools like Wireshark for debugging and diagnostics.

Wow, I did not know the Wireshark has a CBOR dissector. It seems to be a good topic at the next hackathon.

-Akira