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

[Joseph Salowey <[e-mail]>]

I think the intent is that the playbook is communicated is in JSON format
because format is this common to many of the tools and protocols in this
domain.  When we get to the point of specifying actions it seems that
action types in another native format such as yang could be represented in
the other native format and encapsulated within the JSON playbook.

On Thu, Jun 20, 2019 at 6:21 AM Bret Jordan <[e-mail]> wrote:

> In regards to the timestamp, please understand I was just giving an
> example, not _actual_ spec text. I could see us defining a “timestamp” type
> and then saying that the “timestamp” type is an ISO 8601 / RFC 3339
> timestamp that follows some very specific rules.  Just as an example.  Then
> in the property tables we should use “timestamp” instead of “strings”.
>
> I am not against also building a CDDL definition for this in an appendix
> or separate document.  But as of yet CDDL is not used en mass and there are
> not very many tools (other than your really cool ruby tools).  So for now
> it would be best to use property tables since that is what people
> understand today.
>
>
> 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 20, 2019, at 2:44 PM, Carsten Bormann <[e-mail]> wrote:
>
> On Jun 20, 2019, at 14:06, Bret Jordan <[e-mail]> wrote:
>
>
> The data model will consist of a series of property tables that are
> defined using JSON data types.
>
>
> JSON does not define that many data types (copied exactly from RFC 8259:
>   3.  Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>   4.  Objects . . . . . . . .. . . . . . . . . . . . . . . . . . . .   6
>   5.  Arrays  . . . . . . . . . . . . . . . . . . . .. . . . . . . .   7
>   6.  Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
>   7.  Strings . . . . . . . .. . . . . . . . . . . . . . . . . . . .   8
> “Values” includes the “three literal names” false, null, and true beyond
> the other four).
>
> The example you just gave already shows that this is a bit limited:
>
> Example:
>
> Property Name              | Type    | Description
> name (required)            | string  | The name of this action
> created (required)         | string  | The time that this action was
> created in RFC 3339
> sequence_number (optional) | integer | The number …..
>
>
> There is no such thing as an integer in JSON, so that is your own
> extension (JSON only has numbers).  If you think integers in JSON are a
> thing, you’ll be unpleasantly surprised at some point (the large number of
> surprises in this space led to RFC 7493).
>
> Also, you seem to feel a need to qualify the second string as “RFC 3339”,
> which pollutes the “description” column with type information.
> (And what you wrote is very inexact, compare with “format described by the
> `date-time` production in {{RFC3339}}, as refined by Section 3.3 of
> {{RFC4287}}”, which is what turned out we needed to write in a similar
> context.)
>
> If you want to stick with tables instead of machine-readable form, I’m not
> going to argue against that right now(*).
> I would still propose that you at least define the types used in these
> tables in a more well-defined way.  (RFC 8610 would work just about right
> for me here, but my point is more general: you want to have more structured
> information about the types employed, and you don’t want to mix it in, in
> an uncontrolled way, into the description.)
>
> Grüße, Carsten
>
> (*) In the long run, you will generate these tables from machine readable
> form.
> But this discussion isn’t at that level of detail right now…
>
>
> --
> Cacao mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cacao
>