[Cbor] An Information-based CBOR schema language?

David Kemp <dk190a@gmail.com> Wed, 21 August 2019 14:22 UTC

Return-Path: <dk190a@gmail.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48463120033 for <cbor@ietfa.amsl.com>; Wed, 21 Aug 2019 07:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CTs4CcxnsMRD for <cbor@ietfa.amsl.com>; Wed, 21 Aug 2019 07:22:11 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E3C12024E for <cbor@ietf.org>; Wed, 21 Aug 2019 07:22:11 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id o6so1678195oic.9 for <cbor@ietf.org>; Wed, 21 Aug 2019 07:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zInazjfo64JDRWf64Mog1FnBhbCaC4QdypnZlo6aaQk=; b=J+UI710gKlhVlk2Hd7sPHrdF2p+N6+n85k7HsnszVsBRna8LD3Ypvniw+3QglUeOGT ZZhj3JzsJwA3jx7ttJxrUkNaEWJntZccXs76CvC5lQoCTtZ9wTfMeEdLrdD0ua+DcDMg 5LHaH6RNOu6TZ46nc4EqNPMgNOnxaeqKNNAdBeDU9e8QDJcGVeRBkaqNXNQsoZ6akNBu MWWepmVWVQpmrv79mi/+Uyt7ye45Xb12RRqd3fSXkLQdnXBjo0IXujGMgd0YwXWZUVuK Bnyb3/hlLHm0qJU3B3NHg23neybap4/BYrMM1ia5e61PT6388cAWPxcS9mqzKzQ4lub4 1DZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zInazjfo64JDRWf64Mog1FnBhbCaC4QdypnZlo6aaQk=; b=c8US9vdAmbtWYBlqfRleJQiNHa7lrLNGFMFzA8eg7cbGL5c8V3CVRewaOP7QIA8tQO ZOg4xGcAAs+o1iJO6U94O7cW7krkL1jPBolThVO2aN2lPDWZi8GV3+F0RqQOpHKB0HPc zgZUh+Yb+SvK5jhk3mu85LAl61srxjrYjAFNHvpNVaofNeSUIwOOP8ECj+yElSi9ttPQ FqCu9TzxdsFqSPjzba3+wNryifavgJXqqDXsYRLfTTnThnAATYGqbbRnopDxvKBzhSAH 12vr3srkp30UdxO1Qzi8AC/jF/UqAZrf6eHYastZWxlH37+lKferfonex9Fevtjvr7ys wKyw==
X-Gm-Message-State: APjAAAWzumYqFzrK44hI5Nnsb/x/qdEDm9IZjRdd7arFwFEV0wnVVbn2 +bGxJbeqoFjaudD0Z1hC4p8CsHIs1GB2p4XIx8TpWZYh
X-Google-Smtp-Source: APXvYqw9u5taw+ryLh65hkx/a039lIyLBhGzamRJDXqFZjMwhPar/yTJbggRM2BuGpktTzeBO6ZVDq126pEK41yTvwo=
X-Received: by 2002:a54:478d:: with SMTP id o13mr210807oic.54.1566397330424; Wed, 21 Aug 2019 07:22:10 -0700 (PDT)
MIME-Version: 1.0
From: David Kemp <dk190a@gmail.com>
Date: Wed, 21 Aug 2019 10:19:45 -0400
Message-ID: <CAE5tNmpeZh6UA0Uz6QBJNZ4HwmAyyh_2ZvQTZTUBTRYonEwrgA@mail.gmail.com>
To: cbor@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007508360590a14c72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/4aoKsPkyYgpJ5EBMF4FMkJdYl6k>
Subject: [Cbor] An Information-based CBOR schema language?
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 14:22:13 -0000

CBOR-bis describes the need to specify document content without needing the
specification to parse the document:

  "Of course, in real-world implementations, the encoder and the decoder
   will have a shared view of what should be in a CBOR data item.  For
   example, an agreed-to format might be "the item is an array whose
   first value is a UTF-8 string, second value is an integer, and
   subsequent values are zero or more floating-point numbers" or "the
   item is a map that has byte strings for keys and contains at least
   one pair whose key is 0xab01".

CDDL is a schema language for CBOR.   JADN (JSON Abstract Data Notation) is
another.  JADN differs from CDDL in that it:
  1) Specifies an Information Model rather than a Data Model (RFC 3444), and
  2) Is itself structured data (JSON or CBOR) rather than text that
requires parsing

JADN was created as the schema language for the OpenC2 security automation
protocol (
but there is now a need to separate the schema language from any particular
application protocol.   There is currently a draft in OASIS format (
but it seems possible that the IETF is a more appropriate venue to develop
an Information Model standard.

This message is to gauge interest in creating a JADN Internet Draft and to
either initiate a BOF or adopt the draft as a work product of an existing
WG.  If you are interested in working on such a spec, or have suggestions
for where it should be worked, please let me know.