IETF Logo Mail Archive

[Cbor] Question about CBOR padding

Matt Vollrath <matt@endpoint.com> Tue, 06 November 2018 21:58 UTC

Return-Path: <matt@endpoint.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA82126CC7 for <cbor@ietfa.amsl.com>; Tue, 6 Nov 2018 13:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=endpoint.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9nl7BRIDVXG for <cbor@ietfa.amsl.com>; Tue, 6 Nov 2018 13:58:20 -0800 (PST)
Received: from mail.endcrypt.com (mail.endcrypt.com [IPv6:2607:f0d0:1301:23::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BD91288BD for <cbor@ietf.org>; Tue, 6 Nov 2018 13:58:20 -0800 (PST)
Received: from [192.168.1.8] (96-33-3-51.dhcp.jcsn.tn.charter.com [96.33.3.51]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.endcrypt.com (Postfix) with ESMTPSA id 6A4B7833F2 for <cbor@ietf.org>; Tue, 6 Nov 2018 21:58:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=endpoint.com; s=mail; t=1541541499; bh=cTnfLhX53NobyRCbOIivieZHPZv/DVHzJ3vC1VhhtkM=; h=To:From:Subject:Date:From; b=q0R5INGH4f3JBu0TtOBRqXKY/TpNdzkXP5j/+taea1GYGNg7nWZXoJHCTMo4nZR/A muY34xsIbQxSpVP3rF+mgWcJ+QZxsAVg43fLXMxcr4eaqckKMqQIYZP2DdD2DUw66i jaLcTdnBIok84xwGjJqHYzEmyQf6O58dyXgMkDkfnUPAVY0RBq1ZTMu0W/SaFtNk4u U3Bw9WlIOXCtLvHn6e+3XPeLfwSoNNcOYzXUm+HLSdoojYPwhYupIkMG1pWB5GtrIg YGsuffKPaSP6oYgEoJxF3qYasQCPPsAQByWe9EtfAjyqedrMSCIHx+kJ0qMx+OAIHH NGXmIkGnpenyQ==
To: cbor@ietf.org
From: Matt Vollrath <matt@endpoint.com>
Message-ID: <299e007c-10e5-d4cc-afd6-aac45fc3c54a@endpoint.com>
Date: Tue, 06 Nov 2018 16:58:18 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/HQFDIA2XcMaUNKbiy89sQpgVmSI>
Subject: [Cbor] Question about CBOR padding
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: Tue, 06 Nov 2018 22:00:43 -0000

Hello list,

I'm finding CBOR extremely useful for moving large binary blobs 
(specifically: ROS point clouds) into browsers via WebSocket. While 
hacking on a CBOR integration, I ran into something that the spec 
doesn't seem to cover.

How should CBOR data be padded, if I were to do something weird like 
pack it into a PNG?  Believe it or not, the previous implementation 
packed JSON into PNG with \n padding to complete the last pixel.  I 
didn't see anything in the spec about padding, except the mention that 
UBJSON has an explicit noop code.

I don't intend to wrap CBOR in PNG (per-message deflate is a much better 
way to get the same compression over ws), but thought the lack of an 
explicit padding solution was worth asking about.

Thanks and keep up the good work,
Matt Vollrath
End Point Corp

v2.23.0 | Report a Bug | By Email