Re: [Cacao] [EXT] Re: [EXT] RE: Charter

[<[e-mail]>]

Hi Bret,

You didn’t answered my question : “Are you referring to application encoding or data modelling part?”.

In your reply, you are suggesting that versions can be considered … which implies that handling versioning will be a requirement. The data model should allow for such feature + easily allow to augment whatever initial version of that module. YANG, used for data modelling, makes a lot of sense here.

You also suggest that future encodings may be defined…which suggests that whatever solution that will be specified will need to handle such capability.

Cheers,
Med

De : Bret Jordan [mailto:[e-mail]]
Envoyé : mercredi 19 juin 2019 14:07
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bret Jordan; Allan Thomson; [e-mail]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

The initial version needs to be done in JSON, if we want the market as a whole to adopt this. I have walked the floor at RSA and Blackhat for the past 2 years talking to all of the vendors that would potentially implement this.  They all say the same thing.  If it was JSON, they could easily do it.  If it is something else, well, maybe, maybe not.  We would then be reliant on market pressure and consumers to influence vendors to adopt.  That can take 10 years or more. Usually by then, the standard is failed and the market has moved on.  Let us not be yet another standard on the dusty shelves of of the SDO Library.

Further, anything not JSON would require the Web2.0 world of products and APIs to support something totally different.  CBOR may take off at some point.  YANG my take off at some point.  XML may come back from the dead. But right now, today, JSON is the model that the developers of products use and know. Adding additional hurtles for the solution to be adopted is not a good idea for this first version.

Overtime, once we get our first versions done and out the door and they get adopted, we can make changes or add functionality based on market demand.  If the market comes back and says, hey, we really need this done in a binary format like Protobuf, then great.  We can write a binding for that.



Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."


On Jun 19, 2019, at 1:41 PM, [e-mail]<mailto:[e-mail]> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Bret Jordan [mailto:[e-mail]]
Envoyé : mercredi 19 juin 2019 13:26
À : BOUCADAIR Mohamed TGI/OLN
Cc : Allan Thomson; Bret Jordan; [e-mail]<mailto:[e-mail]>
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

I fundamentally do not support the idea of not using JSON for this work.
[Med] Are you referring to application encoding or data modelling part?

 Over time we may write a binding document for some other serialization.  But we need something that can be implemented and have guaranteed interoperability.
[Med] Why CBOR wouldn’t be an option here? BTW, there might be other requirements such as compactness (that may be worth when actions are enriched/augmented on-path). As a group, we don’t have yet the full set of requirements to make a design choice.

In order to gain mass adoption, we need a solution that can be used by the existing eco system.

Bret
Sent from my Commodore 128D