From nobody Wed Aug 3 09:32:14 2016 Return-Path: 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 C131712D099 for ; Wed, 3 Aug 2016 09:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGPkzPGHo5DA for ; Wed, 3 Aug 2016 09:32:08 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 6C09812D151 for ; Wed, 3 Aug 2016 09:32:08 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id x185so14753092qkc.2 for ; Wed, 03 Aug 2016 09:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=gCvHgQwMgttNFHBAWi4Ij3buvALkRm4dTAnPA606Hz0=; b=AqDaFkTeHe0SosV5Kwy7QdHvGc3z1gpHOupj19YYfASNcIGV6KEORU88tw1b61IX6M 29qJBBQgdMVqEcMnSHyY1jKV+csB+LLUVKA6VNbKiyQriz88ALkoFLtd4BDl1MLMjHUv 3j/pweLGhTNL97CSvS6d2TlAdmrppErB/cfy3a1ctvtbxhCcxRVJLs7+nhK6r0ed0Wds DUP4pMwCuXWjp/3VD2VL8Wzp02PWIW0DuqDuXRWRlyh60jMgGQybVyOQzy2Ii2icfTqt PPehDd/q41aqor6FYiNKDhKpuqW+1BcjqAymxPreog5NOWbJM0NpaoUUr+QhrmUg3KfP 94WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=gCvHgQwMgttNFHBAWi4Ij3buvALkRm4dTAnPA606Hz0=; b=hFr41CobNDse581Xks1jNcBWwNmh/pmZy68FAKRwcIJFxVwclqKBvUGl2iFQcEWTbb d+cy9HmQsQtkeW9cW+nLFaPEXEbREgia9VRsAz5cD5zsRbBjQMEvIHe2U+oLf8TxhB3m DT7W9TpPZXiQ3wtGz5Me5lBFD5YY7vm+VFP5N8NsWy/xQ0BhdQ7y63SPQgtsMNVuSf6q czNRRz7W+P8L9Jfv9nNWwrMDEjoL8K9cDISxhPGVrF7TsHKXygg0R/QUR6YxBElY7NvE y7PPbgERA/dYhJwojqi/wZ9zB6d+ZlL0aD+8Y4nY8qp+IB4gisf48zzLdyAyFtQsIfgZ vjFw== X-Gm-Message-State: AEkooutxad2ScT5WgOIqfIngu31W5iy1u4Q/v+75l6Ed/+h5vfQ43KFiR26KqtngLB0yEw== X-Received: by 10.55.201.200 with SMTP id m69mr841765qkl.235.1470241927480; Wed, 03 Aug 2016 09:32:07 -0700 (PDT) Received: from mindcandy ([172.79.206.138]) by smtp.googlemail.com with ESMTPSA id t1sm4559916qtt.25.2016.08.03.09.32.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Aug 2016 09:32:06 -0700 (PDT) Message-ID: <1470241923.1200.99.camel@gmail.com> From: Johnathan Roatch To: Sean Leonard , Carsten Bormann , glenn_engel@keysight.com Date: Wed, 03 Aug 2016 12:32:03 -0400 In-Reply-To: <3306456d-17d4-dfbb-9940-e304f5f73c61@seantek.com> References: <04EFF12F483FA149B07653989B86861F217A069F@wcosexch01k.cos.is.keysight.com> <577416B1.3090308@tzi.org> <577ED54A.3050705@tzi.org> <3306456d-17d4-dfbb-9940-e304f5f73c61@seantek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.4 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: cbor@ietf.org, draft-jroatch-cbor-tags@tools.ietf.org Subject: Re: [Cbor] draft-jroatch-cbor-tags-04 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:32:13 -0000 On Thu, 2016-07-28 at 18:09 -0700, Sean Leonard wrote: > Section 2. Typed Arrays > > Okay; makes sense. However, the mismatch between [u/s]int8 and > binary16  > is jarring. It would seem a lot better if  > uint16/sint16/binary16..uint128/sint128/binary128. When I initially made up the scheme, my primary goal was to pack in any possible gaps. I agree now that byte sizes should definitely be aligned, especially to include 128-bit integers. > In contrast, I don't see a lot of value to tagging an array as > uint8...that would be called a plain old "byte string" by any > definition of the term. Good insight here. I confused myself thinking that a JavaScript ArrayBuffer could been used without a uint8 view. The uint8 tag can definitely be dropped to make room for byte size alignment. Implementations should then use un-tagged byte strings for uint8 arrays. > For the case of uint8 and sint8, I propose that you allocate four > tags in approximately 0b001111_c_s, where c = clamped, and s = > signed. If the uint8 is gone then all we have left here is sint8. clamped arithmetic isn't as critical to fit into some bit pattern as it's really just a hint on how to process numbers and not a number format on it's own. Now that I think of it, clamped arithmetic can actually be it's own tag that can apply to any integer or integer array. > If you want parity with the bit positions in the other tags, I would > propose rearranging the 0b010_f_s_e_ll to: 0b010_ll_f_e_s I put float and signed together to form the collective bit field of number type, and those bits were made the most significant so that there would be less gaps in the list of tags. We have 3 types of numbers in a field that can hold 4. Maybe a fourth type of number should fill in those gaps. Are the IEEE 754-2008 decimal formats used enough to include them? After playing around with possible arrangements a bit this would be what I would do: 0b01_lll_f_s_e. "lll" is the used as "2**(lll)" for calculating the number of bytes. All tags of a single byte size, except sint8, are unreserved. This will make is simple to compute, as all it would take on most platforms is a bit-mask and a couple shifts. the unreserved space will also be a good place to put related tags such as Homogeneous and Multi-dimensional Arrays. "f_s" is the number format: [uintN, sintN, IEEE 754 binaryN, IEEE 754 decimalN]. "e" is big or little endianness. In this formulation, uint8 is no tag, uint16-LE is tag 0x49, IEEE 754 binary32-LE is tag 0x55, uint128-LE is 0x61, and I guess sint8 can be tag 0x42. > I would also like to suggest using tags in the 2-byte space, such as  > 0x0220-0x0237 (or 0x021C - 0x0237). Since there's already implementations that follow the old drafts, going to the 2 byte tag space might be necessary for backwards compatibility of those implementations. If we are going to reuse the original range, now is the time to have a breaking change. > I suppose that you have thought of this already. I am less concerned > about low-byte "pollution"; About "low-byte pollution", I've heard criticism about how endianness takes up too many tags. While I thought about separating out endianness to it's own tag, it's doesn't make much sense outside of the context of typed arrays. If we include IEEE 754-2008 decimal while fixing up the byte size aliment as I wrote above, the total amount of tags will increase from 24 to 32. Forcing everything to be little-endian will reduce that amount to 16. It really depends on how important having big endianness is. > it has more to do with the need for expansion of typed arrays in the > future. If you want to add binary256, int256, etc., For now, I think we should limit ourselves to 128 bit arrays. > Section 7. Security Considerations > > ... > > I consider an irregular-length array to be a coding error; that is > with my security hat on. Yes. Would it be right to say that in the case of such a coding error, the implementation should either terminate processing or treat the byte string as if there were no TypeArray tag applied to it (as uint8)? -- Johnathan Roatch https://jroatch.nfshost.com/ From nobody Wed Aug 3 15:22:13 2016 Return-Path: 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 8683D12D8BE for ; Wed, 3 Aug 2016 15:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 DLlVxqTh6lCu for ; Wed, 3 Aug 2016 15:22:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 5E06512D8A3 for ; Wed, 3 Aug 2016 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u73MM4Lv025637; Thu, 4 Aug 2016 00:22:04 +0200 (CEST) Received: from nar-3.local.mail (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3s4SGz4SZ8zDCjQ; Thu, 4 Aug 2016 00:22:03 +0200 (CEST) Date: Thu, 4 Aug 2016 00:22:02 +0200 From: Carsten Bormann To: glenn_engel@keysight.com, Johnathan Roatch , Sean Leonard Message-ID: In-Reply-To: References: <04EFF12F483FA149B07653989B86861F217A069F@wcosexch01k.cos.is.keysight.com> <577416B1.3090308@tzi.org> <577ED54A.3050705@tzi.org> <3306456d-17d4-dfbb-9940-e304f5f73c61@seantek.com> X-Mailer: Airmail (382) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="57a26e8a_4dadee93_385a" Archived-At: Cc: cbor@ietf.org, draft-jroatch-cbor-tags@tools.ietf.org Subject: Re: [Cbor] draft-jroatch-cbor-tags-04 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:22:12 -0000 --57a26e8a_4dadee93_385a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm, I=E2=80=99m not sure I agree with either the criticism or the conclu= sions below. As the draft stands, it is closely mirroring the typed array functionalit= y that has been defined in several environments including JavaScript. =C2= =A0Why would we be chasing some form of symmetry instead of following wha= t the users seem to need=3F uint8/sint8 arrays are arrays of integers, which is different from untagg= ed byte strings. =C2=A0Hence the tags. I=E2=80=99m not aware of a use case for IEEE 754 decimal at this point. =C2= =A0Sure, one can be constructed, but the objective is not to cover everyt= hing that has been invented under the sun, but what is actually needed. In summary, I continue to believe that the draft is all good as it stands= ; nothing should be changed. Gr=C3=BC=C3=9Fe, Carsten On 3 August 2016 at 18:57:07, Johnathan Roatch (jroatch=40gmail.com) wrot= e: On Thu, 2016-07-28 at 18:09 -0700, Sean Leonard wrote: =20 > Section 2. Typed Arrays =20 > =20 > Okay; makes sense. However, the mismatch between =5Bu/s=5Dint8 and =20 > binary16=C2=A0 =20 > is jarring. It would seem a lot better if=C2=A0 =20 > uint16/sint16/binary16..uint128/sint128/binary128. =20 When I initially made up the scheme, my primary goal was to pack in any =20 possible gaps. I agree now that byte sizes should definitely be =20 aligned, especially to include 128-bit integers. =20 > In contrast, I don't see a lot of value to tagging an array as =20 > uint8...that would be called a plain old =22byte string=22 by any =20 > definition=C2=A0of the term. =20 Good insight here. I confused myself thinking that a JavaScript =20 ArrayBuffer could been used without a uint8 view. The uint8 tag can =20 definitely be dropped to make room for byte size alignment. =20 Implementations should then use un-tagged byte strings for uint8 =20 arrays. =20 > =46or the case of uint8 and sint8, I propose that you allocate four =20 > tags=C2=A0in approximately 0b001111=5Fc=5Fs, where c =3D clamped, and s= =3D =20 > signed. =20 If the uint8 is gone then all we have left here is sint8. clamped =20 arithmetic isn't as critical to fit into some bit pattern as it's =20 really just a hint on how to process numbers and not a number format on =20 it's own. Now that I think of it, clamped arithmetic can actually be =20 it's own tag that can apply to any integer or integer array. =20 > If you want parity with the bit positions in the other tags, I would =20 > propose rearranging the 0b010=5Ff=5Fs=5Fe=5Fll to: 0b010=5Fll=5Ff=5Fe=5F= s =20 I put float and signed together to form the collective bit field of =20 number type, and those bits were made the most significant so that =20 there would be less gaps in the list of tags. We have 3 types of =20 numbers in a field that can hold 4. Maybe a fourth type of number =20 should fill in those gaps. =20 Are the IEEE 754-2008 decimal formats used enough to include them=3F =20 After playing around with possible arrangements a bit this would be =20 what I would do: 0b01=5Flll=5Ff=5Fs=5Fe. =20 =22lll=22 is the used as =222**(lll)=22 for calculating the number of byt= es. =20 All tags of a single byte size, except sint8, are unreserved. This will =20 make is simple to compute, as all it would take on most platforms is a =20 bit-mask and a couple shifts. the unreserved space will also be a good =20 place to put related tags such as Homogeneous and Multi-dimensional =20 Arrays. =20 =22f=5Fs=22 is the number format: =5BuintN, sintN, IEEE 754 binaryN,=C2=A0= IEEE =20 754=C2=A0decimalN=5D. =20 =22e=22 is big or little endianness. =20 In this formulation, uint8 is no tag, uint16-LE is tag 0x49,=C2=A0IEEE 75= 4 =20 binary32-LE is tag 0x55, uint128-LE is 0x61, and I guess sint8 can be =20 tag 0x42. =20 > I would also like to suggest using tags in the 2-byte space, such as=C2= =A0 =20 > 0x0220-0x0237 (or 0x021C - 0x0237). =20 Since there's already implementations that follow the old drafts, going =20 to the 2 byte tag space might be necessary for backwards compatibility =20 of those implementations. =20 If we are going to reuse the original range, now is the time to have a =20 breaking change. =20 > I suppose that you have thought of this already. I am less concerned =20 > about low-byte =22pollution=22; =20 About =22low-byte pollution=22, I've heard criticism about how endianness= =20 takes up too many tags. While I thought about separating out endianness =20 to it's own tag, it's doesn't make much sense outside of the context of =20 typed arrays. =20 If we include IEEE 754-2008 decimal while fixing up the byte size =20 aliment as I wrote above, the total amount of tags will increase from =20 24 to 32. =46orcing everything to be little-endian will reduce that =20 amount to 16. It really depends on how important having big endianness =20 is. =20 > it has more to do with the need for expansion of typed arrays in the =20 > future. If you want to add binary256, int256, etc., =20 =46or now, I think we should limit ourselves to 128 bit arrays. =20 > Section 7. Security Considerations =20 > =20 > ... =20 > =20 > I consider an irregular-length array to be a coding error; that is =20 > with my security hat on. =20 Yes. =20 Would it be right to say that in the case of such a=C2=A0coding error, th= e =20 implementation should either terminate processing or treat the byte =20 string as if there were no TypeArray tag applied to it (as uint8)=3F =20 -- =20 Johnathan Roatch =20 https://jroatch.nfshost.com/ =20 --57a26e8a_4dadee93_385a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline