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

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Fri, 24 May 2013 17:02 UTC

Return-Path: <jhildebr@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3387F21F8E8F for <apps-discuss@ietfa.amsl.com>; Fri, 24 May 2013 10:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qorhpjc86TTN for <apps-discuss@ietfa.amsl.com>; Fri, 24 May 2013 10:02:20 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AED4E21F8EB1 for <apps-discuss@ietf.org>; Fri, 24 May 2013 10:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2709; q=dns/txt; s=iport; t=1369414938; x=1370624538; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Fr1QXt8IHpvPjyHfHQ1U1G8HG1fYBLogH6z0l8EE1wI=; b=DuqSxZ42mAj/I5d79bbg8xPi5jG7ZNx3raBD8WMBjKykyZSzv3BmyHLQ blDbI9uEaAc6+O7gHo6uTxgi0HuSsDnkgfLO9N7bIqR3jehqgiAQO6PfU XfhW5uXsRzfZ+WU5T0aiEgnWlY6laNKFNSl2xtW8b0KqihhvoGxe6CJik Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAAecn1GtJV2a/2dsb2JhbABagwjCWoEGFnSCJQEEOjECDBIBCCIUQiUCBAENDQyHeboXjmwxB4JzYQOoe4MPgiY
X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="214700506"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 24 May 2013 17:02:18 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4OH2IfB007781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 17:02:18 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 24 May 2013 12:02:17 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Phillip Hallam-Baker <hallam@gmail.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR)
Thread-Index: AQHOVvuXjViEyQFpgUacoTb2ksDBA5kSkkeAgAAeFgCAAIvQgIAADVEAgAAK8oCAABH0AIAACBwAgAANpQCAAA3qAIAA+BeA
Date: Fri, 24 May 2013 17:02:16 +0000
Message-ID: <A723FC6ECC552A4D8C8249D9E07425A70FC0DB40@xmb-rcd-x10.cisco.com>
In-Reply-To: <CAMm+LwiWYLBS+H6oKCfByUJVXL8bk293WuFY_M2fnBM2iuvxGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [10.129.24.242]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FCE9F608A14736409432D633163C1439@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 17:02:26 -0000

Paul said:

>Just a note that this is one of the only ones that people are groaning
>about that has an Internet Draft and might go through the IETF consensus
>process. Carsten and I (maybe naively) thought that doing this in this
>environment, instead of say posting ephemeral
> specs on a web page and not having it be clear where the community fit
>it, was a good thing.

PHB said:

>I don't remember you being appointed to address the issue.

Who appoints people to do anything at the IETF?  MsgPack is one of the
best of the formats in this space.  When that group was approached with an
opportunity to have help standardizing their format, they reacted
completely rationally:

- What value would having a standard add?  We already interop in practice.
- Doing anything at the IETF is incredibly painful and slow.  See this
conversation for an example.
- The IETF doesn't have any interesting expertise in this space.
- We want to maintain change control in our community.
- Why would we want our spec to be ugly like an RFC? (I added that on
their behalf, but they would have come to it eventually)

I would expect anyone doing work above layer 4 to have similar issues.

>Since almost all the response to your proposal has been that people don't
>like your design choices, and since you make it abundantly clear that you
>are not interested in our input, I can't quite see where a consensus is
>going to come. Unless that
> is the consensus is that your proposal sucks.

I haven't seen that much reaction to the proposal that says it sucks.
I've seen a couple of people say "that looks like it would work".  I've
seen people wonder if it's needed.  I've seen proposed changes that were
greeted with thoughtful responses.  Your assertion that the authors aren't
interested in our input seems hyperbolic at best.  At worst, it's somewhat
hurtful for no apparent reason.

There are some things I don't like about it, but it solves one of my
biggest problem with JSON, which is sending unformatted octet strings.

I'm the mystery person that wrote a JavaScript implementation.  Granted,
it's in node.js, not for browsers, but I didn't see anything that was
un-implementable in a browser that has typed arrays.  The biggest PITA was
learning enough about half-floats to get them to work.  Appendix D now has
the information needed so that a later implementer won't have as much of a
problem.

>My experience of coding ASN.1 DER (in C and javascript) leads me to
>reject any counted scheme as a non starter.

I've read the whole thread, and didn't see adequate justification for that
worldview.  Could you reiterate it, please?

-- 
Joe Hildebrand