Re: [Cbor] πŸ”” WGLC on draft-ietf-cbor-array-tags-03

Laurence Lundblade <lgl@island-resort.com> Fri, 08 March 2019 15:43 UTC

Return-Path: <lgl@island-resort.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 2DB07124B91 for <cbor@ietfa.amsl.com>; Fri, 8 Mar 2019 07:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eOyVl4BaK-uo for <cbor@ietfa.amsl.com>; Fri, 8 Mar 2019 07:43:33 -0800 (PST)
Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (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 A94FC120106 for <cbor@ietf.org>; Fri, 8 Mar 2019 07:43:33 -0800 (PST)
Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 2HelhPAWNlS8J2Hemh2nZP; Fri, 08 Mar 2019 08:43:33 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com>
Date: Fri, 08 Mar 2019 07:43:31 -0800
Cc: "cbor@ietf.org" <cbor@ietf.org>, "draft-ietf-cbor-array-tags@ietf.org" <draft-ietf-cbor-array-tags@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com>
References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfBPtSIf8VQZXgQ1yKUP7lWLzIYP2Y9Y+hm2sDgBXu7rfEAV/eK9itDpIhf8BRxJP/2s8VAcWXrvg3HD79P3Li6nTyCS4/mwBEm0tLo0ZEbryV7dWRci0 4RWOzFy+oVIqoeJexwnlhm2Hbw6sWUHYXJWhjyXFcIAmr11RrzwjkzsDUQ81beVO9fs6LB4BgDU+vIDmSTLurZe1DSUvEcgvO4xkAPEEVRdVXCFt2X6iz+j5 mBn2u/zCWKNmLUErfZpFKKqzkNTfFbF2RuwFzO8I00g=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/lbYPkGeZa8us4OR2S0bPdHsq2io>
Subject: Re: [Cbor] πŸ”” WGLC on draft-ietf-cbor-array-tags-03
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: Fri, 08 Mar 2019 15:43:36 -0000

In addition to what I said before, a deterministic encoding should be specified (formerly known as canonical) in the specification and that should probably be network / big endian.

To go on a bit more about detailed implementation...

In a native implementation there is also memory access alignment issue on the decode side, but not the encode side. Memory alignment is an issue on some Arm CPUs, though not on Intel CPUs as far as I know. So on some Arm CPUs, it won’t be possible to just return pointers to the bytes that came off the wire. Because non-string and non-aggregate CBOR data items can be 1, 2, 3, 5 and 9 bytes long, there can be no guarantee of alignment of the incoming encoded CBOR bytes. 
A portable decoder implementation will have to allocate aligned memory for the array and copy it. The decoder can byte-swap while it is copying so it lines up OK with the decoder having to do most of the work to achieve interop.

There’s no alignment issue on the encode side.

The only other thing I’ve encountered in CBOR that needs copying of data is indefinite length strings. 

LL



> On Mar 7, 2019, at 7:15 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Comments in my usual vein…
> 
> Because of the big/little endian option, it seems like this needs a discussion about design protocols with it, about preferred encoding / decoding and about interop.
> 
> Probably it should say decoders should support both big and little and the encoder can do what is natural. It seems like there might be an option for both sides to support only one endianness, which will likely often be little endian because it is common.
> 
> LL
> 
> 
>> On Mar 6, 2019, at 4:53 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:
>> 
>> CBOR WG,
>> 
>> The chairs believe the array-tags document is ready for WGLC: https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03
>> 
>> The WGLC will end by *20th of March*, please make sure to send your comments to the list before then.
>> 
>> Best regards,
>> Francesca & Barry
>> 
>> ο»ΏOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" <cbor-bounces@ietf.org on behalf of cabo@tzi.org> wrote:
>> 
>>   -03 reflects the fact that IANA has made the allocations.
>> 
>>   From this author’s point of view, we are ready for WGLC.
>> 
>>   Grüße, Carsten
>> 
>> 
>>> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.
>>> 
>>>      Title           : Concise Binary Object Representation (CBOR) Tags for Typed Arrays
>>>      Authors         : Johnathan Roatch
>>>                        Carsten Bormann
>>> 	Filename        : draft-ietf-cbor-array-tags-03.txt
>>> 	Pages           : 14
>>> 	Date            : 2019-03-05
>>> 
>>> Abstract:
>>> The Concise Binary Object Representation (CBOR, RFC 7049) is a data
>>> format whose design goals include the possibility of extremely small
>>> code size, fairly small message size, and extensibility without the
>>> need for version negotiation.
>>> 
>>> The present document makes use of this extensibility to define a
>>> number of CBOR tags for typed arrays of numeric data, as well as two
>>> additional tags for multi-dimensional and homogeneous arrays.  It is
>>> intended as the reference document for the IANA registration of the
>>> CBOR tags defined.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03
>>> https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-array-tags-03
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> 
>> 
>>   _______________________________________________
>>   CBOR mailing list
>>   CBOR@ietf.org
>>   https://www.ietf.org/mailman/listinfo/cbor
>> 
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor