Re: [apps-discuss] Concise Binary Object Representation (CBOR)

Dave Cridland <> Thu, 23 May 2013 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A831D21E804D for <>; Thu, 23 May 2013 07:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hu2XVLE6WsoW for <>; Thu, 23 May 2013 07:21:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22f]) by (Postfix) with ESMTP id CBF2621E804C for <>; Thu, 23 May 2013 07:21:35 -0700 (PDT)
Received: by with SMTP id xn12so722599obc.34 for <>; Thu, 23 May 2013 07:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hYEm7IuJlwftsIvqv8Ducm/X/AECCUQtMBUX+Xw4ulk=; b=EHtJOwO72fEVgrNpfEKZm0s92dV45kB1sHTllJ8mEy85x2lqpCp7B7s5uUDxneUK0I 9Zi933FakmM1rDEy4Q/ElT8fbIZeoe4G6r0VaCCVt0iLrZ/tuZSB0etk8TpeGi7oXKFX qD6vUbaSw2wmZd8qbihtbv0jFwZx/EqypUF30=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hYEm7IuJlwftsIvqv8Ducm/X/AECCUQtMBUX+Xw4ulk=; b=GfhHJhBRjrT5FRnoznt/O7VyJ1qGajB9OVFmQQ62Oy0dBISj4MU6vWlaCWITTZI1TS OihN7lQpIBZfPE/RNR4S8hiwJScmS7TcsGgSdLWu/UZKBxbA70iUDJm3wjvI3SvCzlTY z1OoeLYbIS0l2B85df7+NWYNlr0OYaWHgJq97/NCU1nZO7qgUbCgJ5XZwt//XPpmrmiR BAmLTep7Qkx22S5qrePZ/ge45XAZ59O+Q3cMbuUTjJO4xl4DzQ/j2cEaTdoBYHWSkpHz qcJHJpKRLs1fidfx+Pk4Ig0UU8LlIEhhE41wLz5knEpwyd5AuoxM7EKCqNl+r2YLCXq+ H9zA==
MIME-Version: 1.0
X-Received: by with SMTP id f10mr8560331oez.32.1369318895153; Thu, 23 May 2013 07:21:35 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 07:21:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <002201ce5781$5ee92b20$1cbb8160$> <> <>
Date: Thu, 23 May 2013 15:21:34 +0100
Message-ID: <>
From: Dave Cridland <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary="089e0111b71c54d87404dd6366b7"
X-Gm-Message-State: ALoCoQmBBkHkglSNvC58uFVIMhfJ1bHMmv6Px6OtfGHDYXeLwrJN9OSKzAmfVT1Ef1P4BoOxKUdd
Cc: Paul Hoffman <>, IETF Apps Discuss <>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 14:21:36 -0000

On Thu, May 23, 2013 at 2:52 PM, Dave Crocker <> wrote:

>      How does/should the differences in data model affect the choices in
> encoding scheme?  I'm looking for the (relatively) short answer.

EXI makes certain assumptions about the data model in order to achieve the
most efficient encoding. EXI specifically can take into account not only
the generalized DOM, but also the schema of the XML encoded. Any encoding
scheme with domain knowledge embedded in it, as it were, can get more
efficient encoding (since it's effectively encoding that domain information
implicitly in its mere use rather than transmitting the model explicitly).
Of course, it doesn't mean that any domain-specific encoding will
automatically be better than a generalized one...

Another example, and one that you may be familiar with, is the way that
IMAP set syntax uses its knowledge of the data domain to make very compact
representations, which can be seen clearly in the difference between a
standard RFC 3501 SEARCH response and the RFC 4731 ESEARCH response, which
(can) carry the same information in different representations - the latter
using considerably fewer octets on the wire in all but degenerate cases.

In any case, this means that given a particular data model, selecting a
suitably apt encoding scheme will yield better results.

(This all said, you could pick an XML representation of the JSON model, and
then EXI encode that one, since the DOM is a superset of the JSON model - I
think. Not saying that's even remotely sensible...)