From nobody Mon Jul 1 04:11:12 2019 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 9E84A120220; Mon, 1 Jul 2019 04:11:10 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.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 XYaiw-bk4ur2; Mon, 1 Jul 2019 04:11:09 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 2D67612008A; Mon, 1 Jul 2019 04:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+8jbLU9057dv9V1kQ9bmwRjaZfTWUvgrEIhHD+rMqNE=; b=Mh29IkSsSjehD9CyN8p/zaMzO sxHTfqP8PU/+SuPyjqPRmHTTUEv61gBMKIi1AmVueujO4DUe9XwII73GA3+hIPWZl/oGqGhvwHjlv K96/FbgJPeh9xs/50iBCz4pBN/xjzr66LgCrb9wW8J4S9EV4jl6uvkRzePKlXvUGaK85GiHTKjMVJ uketrC9jx0II68bBTDPSKuhcNf5kdoDoaKdNBHYankzuAWsshpDpkqwl40cNlsXxrEbaxeLpxMJYy +eKqWtXn1Uz7d0fkLbMk0n5kFVKisGzSBmNEYHcWZcx4uDuj0ppfTGFDWRRYk0wmMv6YxlewxQimT wL9kAn5Tg==; Received: from [149.248.87.38] (port=50212 helo=felipes-mbp.lan) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hhuDB-009kGD-Rl; Mon, 01 Jul 2019 06:11:06 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Felipe Gasper In-Reply-To: <0eb801d52faa$f118fc70$d34af550$@augustcellars.com> Date: Mon, 1 Jul 2019 07:11:05 -0400 Cc: draft-bormann-cbor-sequence@ietf.org, cbor@ietf.org, Carsten Bormann Content-Transfer-Encoding: quoted-printable Message-Id: <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com> References: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> <0e8901d52f6c$08291060$187b3120$@augustcellars.com> <4AF53D16-C6AE-4D53-9A3A-DF442D827D86@felipegasper.com> <0eb801d52faa$f118fc70$d34af550$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 11:11:11 -0000 Sorry, I was asking a more general question about the proposed CBOR = sequence format rather than engaging your point. I realize I should have started a new thread--my apologies for the = confusion. I=E2=80=99m just a bit surprised that CBOR sequences are (proposed to = be) defined this way. It seems to me that CBOR has no real need for such = a standard, precisely because of the indefinite-length arrays that the = format itself includes. I would have thought it more logical to define a = specific tag that indicates such a structure; thus, a CBOR sequence = would itself also be a valid CBOR data object. Thank you! -FG > On Jun 30, 2019, at 9:18 PM, Jim Schaad = wrote: >=20 > This is the text I was referring to >=20 > An > implementation may be able to recover from some errors in a sequence > of bytes that is almost, but not entirely a well-formed encoded CBOR > data item. >=20 > -----Original Message----- > From: CBOR On Behalf Of Felipe Gasper > Sent: Sunday, June 30, 2019 2:56 PM > To: Jim Schaad > Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org; Carsten = Bormann > Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence >=20 > What is the advantage of defining a CBOR data sequence as a simple = concatenation versus a tagged CBOR array of indefinite length? >=20 > Thank you! >=20 > -FG >=20 >> On Jun 30, 2019, at 1:48 PM, Jim Schaad = wrote: >>=20 >> See below. >>=20 >> -----Original Message----- >> From: Carsten Bormann >> Sent: Sunday, June 23, 2019 9:53 AM >> To: Jim Schaad >> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org >> Subject: Re: Review of draft-bormann-cbor-sequence >>=20 >> Hi Jim, >>=20 >> except for items 3 and 5 below, where I don=E2=80=99t quite agree, I = believe I have addressed all your comments as well as the other items = that popped up for -00 in Prague and on the mailing list. >>=20 >> Please enjoy at: >>=20 >> Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/ >> Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-sequence >> Diff2: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-sequence-01.txt >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On May 15, 2019, at 04:56, Jim Schaad = wrote: >>>=20 >>> [=E2=80=A6] >>> 3. Section 2 - I think that I would remove the parenthesis in the=20= >>> third paragraph. This is almost the entire paragraph. >>=20 >> I believe that is useful information, so I don=E2=80=99t think the = parenthesis should be removed. >>=20 >> [JLS] I am not suggesting that the sentence be removed, just the = parenthesis characters. >>=20 >>> [=E2=80=A6] >>> 5. Section 2 - A program, not the decoder, may also be able to=20 >>> recover by decoding individual fields looking for a pattern that=20 >>> matches an expected structure. As an example, looking for a byte=20 >>> which corresponds to an array of 3 items and then test decoding to=20= >>> see if it works and continue from that point. >>=20 >> The specific recovery actions are out of scope (and the text says = so). >> I don=E2=80=99t think we should give advice here for diagnostic tools = beyond what is needed for a true decoder. >>=20 >> [JLS] The problem I have with this argument is that you are actually = giving an example - should that example then be deleted? >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Mon Jul 1 09:42:03 2019 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 E030E120638 for ; Mon, 1 Jul 2019 09:42:00 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SDbU8kwQWfSt for ; Mon, 1 Jul 2019 09:41:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F336512062F for ; Mon, 1 Jul 2019 09:41:51 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jul 2019 09:41:45 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <156105542347.2980.12150350559185537715.idtracker@ietfa.amsl.com> <3328CAA8-0D9A-4F6E-AFC3-E22814D41DA2@tzi.org> In-Reply-To: <3328CAA8-0D9A-4F6E-AFC3-E22814D41DA2@tzi.org> Date: Mon, 1 Jul 2019 12:41:44 -0400 Message-ID: <0f7c01d5302b$dfa9c5b0$9efd5110$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F7D_01D5300A.5898E900" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIneZrf6OrtX0izkm+WnayJN8dyIgGUWusGpgTBVvA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Fwd: New Version Notification for draft-ietf-cbor-array-tags-05.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:42:01 -0000 ------=_NextPart_000_0F7D_01D5300A.5898E900 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As a commentator =E2=80=93 It appears that all of my comments have been = addressed. =20 As a co-chair =E2=80=93 Francesca and I had a chat this morning and we = do not believe that a new WGLC is needed. =20 Jim =20 =20 From: CBOR On Behalf Of Carsten Bormann Sent: Thursday, June 20, 2019 2:36 PM To: cbor@ietf.org Subject: [Cbor] Fwd: New Version Notification for = draft-ietf-cbor-array-tags-05.txt =20 I believe array-tags-05 addresses the WGLC comments. Commenters: Please check whether your comments were addressed. Chairs: Please check whether a second WGLC is needed or this can = progress. =20 Gr=C3=BC=C3=9Fe, Carsten =20 Begin forwarded message: =20 From: internet-drafts@ietf.org =20 Subject: New Version Notification for draft-ietf-cbor-array-tags-05.txt Date: June 20, 2019 at 20:30:23 GMT+2 To: "Carsten Bormann" > =20 A new version of I-D, draft-ietf-cbor-array-tags-05.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository. Name: draft-ietf-cbor-array-tags Revision: 05 Title: Concise Binary Object Representation (CBOR) = Tags for Typed Arrays Document date: 2019-06-20 Group: cbor Pages: 15 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cbor-array-tags-05.txt = = =20 Status: = https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cbor-array-tags-05 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-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. 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 = . The IETF Secretariat =20 ------=_NextPart_000_0F7D_01D5300A.5898E900 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

As a = commentator =E2=80=93 It appears that all of my comments have been = addressed.

 

As a co-chair =E2=80=93 Francesca and I had a chat = this morning and we do not believe that a new WGLC is = needed.

 

Jim

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Carsten = Bormann
Sent: Thursday, June 20, 2019 2:36 PM
To: = cbor@ietf.org
Subject: [Cbor] Fwd: New Version Notification = for draft-ietf-cbor-array-tags-05.txt

 

I believe = array-tags-05 addresses the WGLC comments.

Commenters: Please check whether your comments were = addressed.

Chairs: Please = check whether a second WGLC is needed or this can = progress.

 

Gr=C3=BC=C3=9Fe, Carsten

 



Begin forwarded message:

 

Subject: New Version = Notification for = draft-ietf-cbor-array-tags-05.txt

Date: June 20, 2019 at 20:30:23 = GMT+2

To: "Carsten Bormann" = <cabo@tzi.org>

 


A new version of = I-D, draft-ietf-cbor-array-tags-05.txt
has been successfully = submitted by Carsten Bormann and posted to the
IETF = repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-ietf-cbor-array-tags
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 05
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Concise Binary Object Representation (CBOR) Tags for Typed = Arrays
Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2019-06-20
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = cbor
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-cbor-array-tags-0= 5.txt
Status:         htt= ps://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/
Htmlized= :       https:= //tools.ietf.org/html/draft-ietf-cbor-array-tags-05
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags
= Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-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.




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.

The IETF = Secretariat

 

------=_NextPart_000_0F7D_01D5300A.5898E900-- From nobody Tue Jul 2 07:38:06 2019 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 5E0F212008C; Tue, 2 Jul 2019 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ah9fxpqj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=00GFsGvf 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 f9f3YCvvVMqN; Tue, 2 Jul 2019 07:38:02 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2405512000E; Tue, 2 Jul 2019 07:38:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F0C46220BA; Tue, 2 Jul 2019 10:38:00 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Tue, 02 Jul 2019 10:38:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=hV9hh LZnlazrHH9Mf2H64sHs+d4rqzwvQcAU/VvTrM4=; b=ah9fxpqjLMMcAoBKKaj7C PnSYLbwesuX55b4wkBik4DPC/x4mxA/sqLXBvhdIp36YMqBxz3fkskJXo0fEcCDb OPoFzDcAuoVpxQZfAjUBWzNIGSNgG7rmtB+lxJMhDFzfZXmV+/Fwh61HD9sEupLV 118Mww0DVuT8GyvIxtN8yDD6Ix00S3PII2QtVTeMho8Sdw2+bqo1IVhcbP8U6SpJ jjQp/uzPwFk4SuBioHAcv0Wcw/qU+TP+B5l79WYRfEp08F6NQ3vZUkABnM4pYMo0 h4NotzJfZsQ19S7vl6XX5UIifvzs+y/fjGkE4y/uU3y/TjO3qPU6cIJe1OCM22eA g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=hV9hhLZnlazrHH9Mf2H64sHs+d4rqzwvQcAU/VvTr M4=; b=00GFsGvfFGfjcq/c0C1reJfLr56mC9PXedfsBHS6vCA7lqauhHHpDBZYQ Olbcg3qtRWLbxMCydzmKSdG3ss/eYKfTb8PwImfSiP35JzKGYT7tZ2Mrb+FxD5kT fdkxsbtXXMzsER0uro1kcjzFvvwx+q5SwJmOkil0mFscfOnF7U3hWgQOKVK+Cg1f 4lioeDqVBB5hyDkzdO3yfaaqpTvr/GMOJJXqK2zPcwnip2h0nYPxJKWmBAzb/uRV PhERhmAmwf4DgagBLczQb+m9mc1Huj8cujChQW0xImzFSo+L7vxTSX9WBefct4f1 MqIzgSdgOwsvSc2/VDzc8KNJ5Ud+w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhho mheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DFC69C200A6; Tue, 2 Jul 2019 10:37:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <156152155760.31137.14743795939001646314.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2019 15:37:45 +0100 From: "Alexey Melnikov" To: "Carsten Bormann" , "Adam Roach" Cc: cbor@ietf.org, "The IESG" , cbor-chairs@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] =?utf-8?q?Adam_Roach=27s_Block_on_charter-ietf-cbor-01-01?= =?utf-8?q?=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 14:38:05 -0000 On Wed, Jun 26, 2019, at 6:53 AM, Carsten Bormann wrote: > Hi Adam, >=20 > these are very good questions indeed. >=20 > As you may have noticed, the rescoping beyond IoT is not just happenin= g=20 > to CDDL. > CBOR is now being used in a wide variety of specifications that have=20= > varying aspects of IoTness to them, e.g., consider WebAuthn and CTAP2.= =20 > This is also visible in the set of people who are contributing. > So I don=E2=80=99t think the rechartered CBOR WG as proposed will be a= n obscure=20 > IoT only working group. I agree that use of CBOR is not limited to IoT space. I struggle to make= this any clearer in the charter text. Adam, do you think anything needs= to change/ can be improved here? > Of the three jobs of the rechartered WG, the CBORbis part has the=20 > shortest timeline. > Once that is finished, we are left with CDDL and the Tags documents=20= > (and occasional media type documents). While Tags are specific to=20 > CBOR, they also could be viewed as a component model that will=20 > increasingly be used in CDDL as well. The more general purpose (or=20= > internet-wide) Tags documents that would be worked on by the WG would=20= > flow together with the desire to componentize CDDL. >=20 > With respect to the broader field of =E2=80=9Cschema languages=E2=80=9D= , the extreme=20 > version of your proposal would be to merge into one WG the existing=20= > netmod WG (the work on YANG), the CDDL work of the CBOR WG, and the=20= > various approaches to data modeling being discussed on the JSON WG=20 > mailing list right now. Clearly, data modeling has become an importan= t=20 > aspect of the field of protocol development. But that does not mean=20= > all that work needs to be in one WG. The constituents are overlapping= ,=20 > but mostly distinct: operations and management, application layer and=20= > security protocol design, application API development. >=20 > Creating a new =E2=80=9Cdata modeling for JSON and friends=E2=80=9D WG= would send a=20 > signal that we take the data modeling area more seriously. But it=20 > would also defocus from the evolution of CDDL as one description=20 > technique in this space; it seems to me that the current approach of=20= > evolving a number of coherent designs in a competitive manner is=20 > ultimately more productive. >=20 > A pure CDDL working group would certainly work, but would leave the=20= > work on Tags on the sidelines =E2=80=94 keeping a CBOR working group j= ust for=20 > the Tags work (once CBORbis is completed) doesn=E2=80=99t seem to make= a lot of=20 > sense, and we want to achieve a higher degree of integration between=20= > components work and language work anyway. Considering size of the WG, people involved and the fact that CBOR model= is more complex than JSON, so it is more likely to affect CDDL, I think= it makes sense to keep both CBOR and any possible CDDL extensions in on= e place. > So I think the charter proposal has it about right, with the possible=20= > exception of the need for a signal that this WG is not just about IoT=20= > any more. But that signal can be outside the charter. Agreed. Best Regards, Alexey > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Jun 26, 2019, at 05:59, Adam Roach via Datatracker wrote: > >=20 > > Adam Roach has entered the following ballot position for > > charter-ietf-cbor-01-01: Block > >=20 > > When responding, please keep the subject line intact and reply to al= l > > email addresses included in the To and CC lines. (Feel free to cut t= his > > introductory paragraph, however.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-cbor/ > >=20 > >=20 > >=20 > > --------------------------------------------------------------------= -- > > BLOCK: > > --------------------------------------------------------------------= -- > >=20 > > This is a "DISCUSS-discuss" style block, in the spirit of backing up= and making > > sure we're making the right overall decision here. > >=20 > > I'd like us to have a short conversation about whether it makes sens= e for the > > CDDL work to continue in the CBOR working group. Given that it has b= een > > rescoped and renamed to be a more general-purpose schema language co= vering not > > just CBOR, but the much broader JSON universe, it seems that this wo= rk is > > extremely likely to have a broad constituency outside of those peopl= e who > > typically participate in working groups that focus on IoT use-cases.= Keeping it > > part of CBOR does not seem to serve that community well. > >=20 > > Should we consider splitting the CDDL update and maintenance work of= f into a > > separate working group, rather than rechartering CBOR with the rathe= r > > significant expansion considered in this charter proposal? > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > >=20 >=20 > From nobody Tue Jul 2 07:45:15 2019 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 997F112009E; Tue, 2 Jul 2019 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=MeXuGd8g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LBhBzmXx 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 IECpmswGKZL1; Tue, 2 Jul 2019 07:45:04 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F5312007A; Tue, 2 Jul 2019 07:45:04 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E265B22265; Tue, 2 Jul 2019 10:45:03 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Tue, 02 Jul 2019 10:45:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=e0R4U qzhEd477UvHtOTR/J423iH3oLy5AHETnaBk2iE=; b=MeXuGd8gvgEkmtMGF4IB/ IeyBFyc1jVoAzIdzO7gJzma5WKHsVztREqnHP/zScQheT+Bw6R1m/gLbNiZNFPSi Tf9tbSUNA2qMj1hTAIMg9os0GkTm9creR6zOy3G+YtZzZstiJjqb05WclYnZWkd8 5n7pRRN5mf2LCA9b43IaUlYcAVk9fYfzLDBOPsmXnpqqGfrJ8rwKEaKKSyPZSKhf wCXdQk2z5smSmAxdSrM0rybJ7LFiLwqqaEk05KPjc9WKXQ93QzfoSfpwGDKCuYbq rgmPvixgCJrNTR7WXjXF195A6dlo4JqtDDiK/+upzRtSXby8mnIxf0Bi/kUv+alg g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=e0R4UqzhEd477UvHtOTR/J423iH3oLy5AHETnaBk2 iE=; b=LBhBzmXxqlyW9lSscf8cV4t7GF7HpjaFOx7bkFcMP2HFWrbS3GQ42gBLa cPhe9lTRNXKBFkdvJxnUhsskvUiLiyb+zcYCsEmrnDIJ4I+3vn0+atj++PoMaxIV qtzye7KDntJpIxbU67oWWX10nbNCnpWN81aKhLmThmvN79bW6eTiavH/n32O0bqj egS1/WOmcCgjTzK6AHWMLbu4SZFVfJstafkh425MVQfYj/2z8eJFtQpHYT3up9n8 GL9A4NKjmeSEPughyBZV9YqVlnENdZ58MStAVM0b2LnG7hL1b2sTA3/GLOClqr0i 1f+G8jqpNsxwC6nW33+xdNA3pUeag== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E61F3C200A4; Tue, 2 Jul 2019 10:45:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2019 15:44:45 +0100 From: "Alexey Melnikov" To: "Carsten Bormann" , "Mirja Kuehlewind" Cc: cbor@ietf.org, "The IESG" , cbor-chairs@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 14:45:07 -0000 Hi Mirja, On Wed, Jun 26, 2019, at 5:46 PM, Carsten Bormann wrote: > Hi Mirja, >=20 > good points. Details below. >=20 > > On Jun 26, 2019, at 17:27, Mirja K=C3=BChlewind via Datatracker wrote: > > --------------------------------------------------------------------= -- > > BLOCK: > > --------------------------------------------------------------------= -- > >=20 > > Not sure if my two points justify a block, so I'm happy to change my= position > > if other ADs tell me to, but I'm also not certain if I want to go fo= r "No > > Objection". > >=20 > > Here are my points: > >=20 > > 1) First on this: > > "After that, the CBOR working group will monitor issues found with t= he CBOR > > specification and, if needed, will produce an updated document." Thi= s intention > > seems to contradict the idea of an Internet Standard in RFC2026 a bi= t: > > "A specification for which significant implementation and successf= ul > > operational experience has been obtained may be elevated to the > > Internet Standard level. An Internet Standard (which may simply b= e > > referred to as a Standard) is characterized by a high degree of > > technical maturity and by a generally held belief that the specifi= ed > > protocol or service provides significant benefit to the Internet > > community." > > Maybe this is nit-picking but if the group is not sure if there are = further > > issue, one should probably simply not push for Internet Standard=E2=80= =A6 >=20 > Of course the group is sure about that!!!1one >=20 > Some STD documents do have updates (say, RFC 791 is updated by RFC1349= ,=20 > RFC2474, RFC6864), but I would actually also feel better without=20= > this apparent escape hatch. We do want to get this right! Ok, I suggest we remove "After that, the CBOR working group will monitor= issues found with the CBOR specification and, if needed, will produce an updated document." This would always rem= ain a future possibility, even if the document is an Internet Standard. > > 2) I find the later part of the charter rather generic (starting whi= ch "There > > are a number of additional CBOR tagged types..."). I also don't real= ly > > understand the difference of "General purpose" and "Internet-wide". = These are > > two different aspects for me that don't exclude each other. I would = rather like > > to see a charter that actually limits the technical scope rather tha= n talking > > about a generic process (that may or could be or is applied in other= groups as > > well). Are you suggesting that the Charter should just list specific documents = and require rechartering once the work is done? > My fault. This was specifically about CBOR Tag definitions, until we=20= > noticed that we might be having some glue/housekeeping like the CBOR=20= > sequence document. But really, this is almost all about CBOR Tag=20 > definitions. >=20 > General purpose vs. Internet-wide: Not all usage of CBOR occurs on the= =20 > Internet, so there is a difference, but yes, these generally will=20 > overlap. (Example for non-Internet usage: CBOR can be a great log fil= e=20 > format.) >=20 > So when is a Tag spec in scope: When we expect a general purpose=20 > and/or Internet-wide usage of the Tag (or other CBOR specific=20 > housekeeping document like a media type definition). Is any clarification needed on this point? Best Regards, Alexey From nobody Tue Jul 2 08:52:57 2019 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 E7F361200E5; Tue, 2 Jul 2019 08:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 mJrcdYvcxAoI; Tue, 2 Jul 2019 08:52:54 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E5A6E1200DF; Tue, 2 Jul 2019 08:52:53 -0700 (PDT) Received: from 200116b82c0abb008104c3e4d35e4aa2.dip.versatel-1u1.de ([2001:16b8:2c0a:bb00:8104:c3e4:d35e:4aa2]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hiL5Q-0008Jt-7q; Tue, 02 Jul 2019 17:52:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 2 Jul 2019 17:52:51 +0200 Cc: Carsten Bormann , cbor@ietf.org, The IESG , cbor-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net> References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562082773;2c9c7156; X-HE-SMSGID: 1hiL5Q-0008Jt-7q Archived-At: Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:52:56 -0000 Hi Carsten, See inline. > On 2. Jul 2019, at 16:44, Alexey Melnikov = wrote: >=20 > Hi Mirja, >=20 > On Wed, Jun 26, 2019, at 5:46 PM, Carsten Bormann wrote: >> Hi Mirja, >>=20 >> good points. Details below. >>=20 >>> On Jun 26, 2019, at 17:27, Mirja K=C3=BChlewind via Datatracker = wrote: >=20 >>> = ---------------------------------------------------------------------- >>> BLOCK: >>> = ---------------------------------------------------------------------- >>>=20 >>> Not sure if my two points justify a block, so I'm happy to change my = position >>> if other ADs tell me to, but I'm also not certain if I want to go = for "No >>> Objection". >>>=20 >>> Here are my points: >>>=20 >>> 1) First on this: >>> "After that, the CBOR working group will monitor issues found with = the CBOR >>> specification and, if needed, will produce an updated document." = This intention >>> seems to contradict the idea of an Internet Standard in RFC2026 a = bit: >>> "A specification for which significant implementation and = successful >>> operational experience has been obtained may be elevated to the >>> Internet Standard level. An Internet Standard (which may simply be >>> referred to as a Standard) is characterized by a high degree of >>> technical maturity and by a generally held belief that the = specified >>> protocol or service provides significant benefit to the Internet >>> community." >>> Maybe this is nit-picking but if the group is not sure if there are = further >>> issue, one should probably simply not push for Internet Standard=E2=80= =A6 >>=20 >> Of course the group is sure about that!!!1one >>=20 >> Some STD documents do have updates (say, RFC 791 is updated by = RFC1349,=20 >> RFC2474, RFC6864), but I would actually also feel better without=20= >> this apparent escape hatch. We do want to get this right! >=20 > Ok, I suggest we remove "After that, the CBOR working group will = monitor issues found with the CBOR specification > and, if needed, will produce an updated document." This would always = remain a future possibility, even if the document is an Internet = Standard. I think that makes sense. Thanks! >=20 >>> 2) I find the later part of the charter rather generic (starting = which "There >>> are a number of additional CBOR tagged types..."). I also don't = really >>> understand the difference of "General purpose" and "Internet-wide". = These are >>> two different aspects for me that don't exclude each other. I would = rather like >>> to see a charter that actually limits the technical scope rather = than talking >>> about a generic process (that may or could be or is applied in other = groups as >>> well). >=20 > Are you suggesting that the Charter should just list specific = documents and require rechartering once the work is done? Yes, I think that would actually be the better approach, where document = should not be specific drafts but specific work items. >=20 >> My fault. This was specifically about CBOR Tag definitions, until we=20= >> noticed that we might be having some glue/housekeeping like the CBOR=20= >> sequence document. But really, this is almost all about CBOR Tag=20 >> definitions. >>=20 >> General purpose vs. Internet-wide: Not all usage of CBOR occurs on = the=20 >> Internet, so there is a difference, but yes, these generally will=20 >> overlap. (Example for non-Internet usage: CBOR can be a great log = file=20 >> format.) >>=20 >> So when is a Tag spec in scope: When we expect a general purpose=20 >> and/or Internet-wide usage of the Tag (or other CBOR specific=20 >> housekeeping document like a media type definition). >=20 > Is any clarification needed on this point? I think my confusion is about listing hem as separate items on the = implication on the decision. However, if the group decided to rather = list specific items instead, I guess this part is not needed anymore. Mirja >=20 > Best Regards, > Alexey >=20 >=20 From nobody Tue Jul 2 09:17:36 2019 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 E08EF120394; Tue, 2 Jul 2019 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 3oT3WK1PO0DJ; Tue, 2 Jul 2019 09:17:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4F1F112047D; Tue, 2 Jul 2019 09:17:13 -0700 (PDT) Received: from [IPv6:2607:fb90:408a:cc9e:d887:fc1:944a:77d0] ([172.58.169.78]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x62GGtSd090148 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jul 2019 11:17:04 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562084226; bh=HSxQt3H/2lF9xlAQa0/ksMknVejo6NlehFoZF+r8oek=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NpCMXL5eaN5RTGfrsfA2fx8ow6++PF/tfMTc+zQQ++/o4s6UioOj5JvZEHD68xCvE wdwS0HA+3GMKIfEsiW0wmhxs31kPxmREKVANU1EDxOnJT9Sm46PaxnCu7GLkOcRv3I +w9+VRpBgn6gWJBFTTtFR6eXBWEgW7VeJWOQRs28= X-Authentication-Warning: raven.nostrum.com: Host [172.58.169.78] claimed to be [IPv6:2607:fb90:408a:cc9e:d887:fc1:944a:77d0] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Tue, 2 Jul 2019 12:16:48 -0400 Cc: Carsten Bormann , cbor@ietf.org, The IESG , cbor-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156152155760.31137.14743795939001646314.idtracker@ietfa.amsl.com> To: Alexey Melnikov Archived-At: Subject: Re: [Cbor] Adam Roach's Block on charter-ietf-cbor-01-01: (with BLOCK) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 16:17:34 -0000 Okay =E2=80=94 I=E2=80=99m happy with the level of consideration that=E2=80=99= s happened here. I merely wanted to ensure the possibility had been consider= ed. I=E2=80=99ll clear. /a > On Jul 2, 2019, at 10:37, Alexey Melnikov wrote: >=20 >> On Wed, Jun 26, 2019, at 6:53 AM, Carsten Bormann wrote: >> Hi Adam, >>=20 >> these are very good questions indeed. >>=20 >> As you may have noticed, the rescoping beyond IoT is not just happening=20= >> to CDDL. >> CBOR is now being used in a wide variety of specifications that have=20 >> varying aspects of IoTness to them, e.g., consider WebAuthn and CTAP2. =20= >> This is also visible in the set of people who are contributing. >> So I don=E2=80=99t think the rechartered CBOR WG as proposed will be an o= bscure=20 >> IoT only working group. >=20 > I agree that use of CBOR is not limited to IoT space. I struggle to make t= his any clearer in the charter text. Adam, do you think anything needs to ch= ange/ can be improved here? >=20 >> Of the three jobs of the rechartered WG, the CBORbis part has the=20 >> shortest timeline. >> Once that is finished, we are left with CDDL and the Tags documents=20 >> (and occasional media type documents). While Tags are specific to=20 >> CBOR, they also could be viewed as a component model that will=20 >> increasingly be used in CDDL as well. The more general purpose (or=20 >> internet-wide) Tags documents that would be worked on by the WG would=20 >> flow together with the desire to componentize CDDL. >>=20 >> With respect to the broader field of =E2=80=9Cschema languages=E2=80=9D, t= he extreme=20 >> version of your proposal would be to merge into one WG the existing=20 >> netmod WG (the work on YANG), the CDDL work of the CBOR WG, and the=20 >> various approaches to data modeling being discussed on the JSON WG=20 >> mailing list right now. Clearly, data modeling has become an important=20= >> aspect of the field of protocol development. But that does not mean=20 >> all that work needs to be in one WG. The constituents are overlapping,=20= >> but mostly distinct: operations and management, application layer and=20 >> security protocol design, application API development. >>=20 >> Creating a new =E2=80=9Cdata modeling for JSON and friends=E2=80=9D WG wo= uld send a=20 >> signal that we take the data modeling area more seriously. But it=20 >> would also defocus from the evolution of CDDL as one description=20 >> technique in this space; it seems to me that the current approach of=20 >> evolving a number of coherent designs in a competitive manner is=20 >> ultimately more productive. >>=20 >> A pure CDDL working group would certainly work, but would leave the=20 >> work on Tags on the sidelines =E2=80=94 keeping a CBOR working group just= for=20 >> the Tags work (once CBORbis is completed) doesn=E2=80=99t seem to make a l= ot of=20 >> sense, and we want to achieve a higher degree of integration between=20 >> components work and language work anyway. >=20 > Considering size of the WG, people involved and the fact that CBOR model i= s more complex than JSON, so it is more likely to affect CDDL, I think it ma= kes sense to keep both CBOR and any possible CDDL extensions in one place. >=20 >> So I think the charter proposal has it about right, with the possible=20 >> exception of the need for a signal that this WG is not just about IoT=20 >> any more. But that signal can be outside the charter. >=20 > Agreed. >=20 > Best Regards, > Alexey >=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Jun 26, 2019, at 05:59, Adam Roach via Datatracker = wrote: >>>=20 >>> Adam Roach has entered the following ballot position for >>> charter-ietf-cbor-01-01: Block >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-cbor/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >>>=20 >>> This is a "DISCUSS-discuss" style block, in the spirit of backing up and= making >>> sure we're making the right overall decision here. >>>=20 >>> I'd like us to have a short conversation about whether it makes sense fo= r the >>> CDDL work to continue in the CBOR working group. Given that it has been >>> rescoped and renamed to be a more general-purpose schema language coveri= ng not >>> just CBOR, but the much broader JSON universe, it seems that this work i= s >>> extremely likely to have a broad constituency outside of those people wh= o >>> typically participate in working groups that focus on IoT use-cases. Kee= ping it >>> part of CBOR does not seem to serve that community well. >>>=20 >>> Should we consider splitting the CDDL update and maintenance work off in= to a >>> separate working group, rather than rechartering CBOR with the rather >>> significant expansion considered in this charter proposal? >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>=20 >>=20 From nobody Tue Jul 2 10:45:17 2019 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 A1C111206AF; Tue, 2 Jul 2019 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Z4MECweY0T_C; Tue, 2 Jul 2019 10:45:04 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BCE120731; Tue, 2 Jul 2019 10:45:02 -0700 (PDT) Received: from [192.168.217.110] (p5089AF7E.dip0.t-ipconnect.de [80.137.175.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dWph2CdmzyWj; Tue, 2 Jul 2019 19:45:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net> Date: Tue, 2 Jul 2019 19:44:59 +0200 Cc: Alexey Melnikov , cbor@ietf.org, The IESG , cbor-chairs@ietf.org X-Mao-Original-Outgoing-Id: 583782297.497997-cc1f21878659cf9b9d87f0a083321d6e Content-Transfer-Encoding: quoted-printable Message-Id: <7ACCCA75-39DC-499E-A108-CE392D0889B6@tzi.org> References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 17:45:08 -0000 Hi Mirja, On Jul 2, 2019, at 17:52, Mirja Kuehlewind wrote: >=20 >> Are you suggesting that the Charter should just list specific = documents and require rechartering once the work is done? >=20 > Yes, I think that would actually be the better approach, where = document should not be specific drafts but specific work items. We did that in the previous (current) charter, and it was a mistake. Tags are the most prominent defined extension point for CBOR, defined so = there is a low threshold to actually making an =E2=80=9Cextension=E2=80=9D= (defining a tag), mostly done by third parties via IANA registrations. = It does make sense to coordinate some of this from the WG and pick some = strategic tags for WG attention. It makes more sense when this can be = done flexibly and quickly. The current charter from 2.5 years ago lists a couple of tag documents, = one of which we chose not to progress right now after all and one that = did move forward (WGLC completed). There are a couple other documents = that are de facto WG documents but can=E2=80=99t be officially. That = just serves to slow down work. It=E2=80=99s a bit as if the DHC working = group needed to be rechartered for each new DHCP option. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 2 17:00:09 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0B12008B; Tue, 2 Jul 2019 17:00:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <156211200767.23941.9272616289623504188@ietfa.amsl.com> Date: Tue, 02 Jul 2019 17:00:07 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-06.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 00:00:08 -0000 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) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-06.txt Pages : 64 Date : 2019-07-02 Abstract: The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-06 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/ From nobody Tue Jul 2 17:05:29 2019 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 109FD1200E7 for ; Tue, 2 Jul 2019 17:05:28 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ANdfuRm_1JoJ for ; Tue, 2 Jul 2019 17:05:26 -0700 (PDT) Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A8B120044 for ; Tue, 2 Jul 2019 17:05:26 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Jul 2019 17:05:24 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.004; Tue, 2 Jul 2019 17:05:23 -0700 From: Paul Hoffman To: "cbor@ietf.org" Thread-Topic: draft-ietf-cbor-7049bis-06 Thread-Index: AQHVMTMCefbI2TDiXkiAZlyaW7V0kg== Date: Wed, 3 Jul 2019 00:05:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cbor] draft-ietf-cbor-7049bis-06 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 00:05:28 -0000 On 2 Jul 2019, at 17:00, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Concise Binary Object Representation Mai= ntenance and Extensions WG of the IETF. > > Title : Concise Binary Object Representation (CBOR) > Authors : Carsten Bormann > Paul Hoffman > Filename : draft-ietf-cbor-7049bis-06.txt > Pages : 64 > Date : 2019-07-02 > > Abstract: > The Concise Binary Object Representation (CBOR) 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. These design goals make it different from > earlier binary serializations such as ASN.1 and MessagePack. > > This document obsoletes RFC 7049. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-7049bis-06 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-06 As you can see from the diffs, this draft makes a *lot* of changes from the= -05. We hope y'all carefully review the diffs looking for anything that we= have made worse.=20 At this point, there are no open pull requests in the repo, but there are s= till many open issues. We hope to work on those in the coming weeks. --Paul Hoffman= From nobody Tue Jul 2 21:24:24 2019 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 E667E12014B for ; Tue, 2 Jul 2019 21:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 yKJyOPZkHOnX for ; Tue, 2 Jul 2019 21:24:20 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7605120044 for ; Tue, 2 Jul 2019 21:24:20 -0700 (PDT) Received: from [192.168.217.110] (p5089AF7E.dip0.t-ipconnect.de [80.137.175.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dp0L3tHSzyWG; Wed, 3 Jul 2019 06:24:18 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583820655.872244-2854ab8bf5934f4238684cf6c5adb565 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Jul 2019 06:24:17 +0200 Message-Id: <4247F407-1047-4220-9289-584D7A68DFB5@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Tag validity: embedded MIME vs. embedded CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 04:24:23 -0000 In 7049bis -06, there are several embedded formats that can be tagged. Quoting: * Tag 36 is for MIME messages (including all headers), as defined in {{RFC2045}}. A text string that isn't a valid MIME message is invalid. [=E2=80=A6] Tag 24 (CBOR data item) can be used to tag the embedded byte string as a data item encoded in CBOR format. Contained items that aren't byte strings are invalid. Any contained byte string is valid, even if it encodes an invalid or ill-formed CBOR item. What is our position on embedded formats? Why is MIME validity-checked = and CBOR not? I would expect a consistent answer here, one that also = can guide new tag definitions. Given that Tag validity checking is optional in a generic decoder (which = we still need to properly write up; currently only the security = considerations are clear about that), we can be a bit strict on the = definition of validity here: I=E2=80=99m leaning towards making CBOR = well-formedness (or validity?) a prerequisite of tag 24 validity. (Now https://github.com/cbor-wg/CBORbis/issues/86 .) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 2 22:04:20 2019 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 3A7D5120191 for ; Tue, 2 Jul 2019 22:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KzvGc1jJ3JEh for ; Tue, 2 Jul 2019 22:04:16 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 423B612018D for ; Tue, 2 Jul 2019 22:04:16 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id a93so525792pla.7 for ; Tue, 02 Jul 2019 22:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=diwKwGg84u8onNKi4P/F4YwUTKg+ccrU4H+IzTKGy+8=; b=elrIAZBIn/k1aEpi0TmKJk0RMAyOZzaQFrggM6vuiyeFyndo1wfgTiDWKddCx+OCTs idYZu1hE7yL1u/FkfiZ+sfg3/ovpF8KPYl4cpngaWm4r2/WFhWNLlFuldyE99yLoVT99 5orHaR/jg4ivj+jnFo+r71pN7A5Gn+Mbrdc/qGBJx+MxM2GMlFo7SHrB1ZRzJ3cBz7LT wDCzSJP2XMgDMVqNwtOwPOho5A8HmHbiq8aR7PCb1Z+eb8mYIjGP4qDpRanRnf3luz09 LG+tZH0TTYvqjlMxD6O9LZzjvwcE/AJx31sXKqokw0Lj2A9f0C8LqX5BMveYqnvcKD6B WJNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=diwKwGg84u8onNKi4P/F4YwUTKg+ccrU4H+IzTKGy+8=; b=Q2Jy/mvgfpV/1Xpfg5KGFWyHYiJe3hAV0XrFlzyQhfMTFSA9mFrPOBszX2lNFi1kJK JnX4wlSWK0ZkMrucM/1pXt1Va8sxRWvuKEmCShWnhrmL5dqfftto8OBMHsqiNJmLH0DT pFBa7em4nEliQER5H2YTK2LcQviRx0b44ZE9BTjp25AWsUVFTEnhT67zeif1WupSLuPz jGZ/p2JrLf2iGHos4k8tai3kMlAR4uWR+A5ySPndjb/y4woLjSCE9E/TxOfRVEFCM1Ta crXtG8VHgv4AFC6hMVJQqv2JG7jrG1fTXMXLDwW8wPEKe1dadZ6+nFP1x9XcW6L0A6W6 jiqw== X-Gm-Message-State: APjAAAW9GNuGFsH7U/kXiy0hwY0Nonx3TMCxvCLw4pMzO19nM4nju22n DA0RdF+MOJnnDafAF23ga6/Us40l X-Google-Smtp-Source: APXvYqyD281MlOX+oDDIFCW3o4GxjNxRiSFR0Lm4xHBU+iKnttnoVchuKdBeVi91vSLMu9Rj2/7Hqg== X-Received: by 2002:a17:902:ac88:: with SMTP id h8mr40149239plr.12.1562130255596; Tue, 02 Jul 2019 22:04:15 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id z20sm1098888pfk.72.2019.07.02.22.04.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 22:04:14 -0700 (PDT) To: Carsten Bormann References: <4247F407-1047-4220-9289-584D7A68DFB5@tzi.org> From: Brian E Carpenter Cc: cbor@ietf.org Message-ID: Date: Wed, 3 Jul 2019 17:04:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <4247F407-1047-4220-9289-584D7A68DFB5@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Tag validity: embedded MIME vs. embedded CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 05:04:18 -0000 On 03-Jul-19 16:24, Carsten Bormann wrote: > In 7049bis -06, there are several embedded formats that can be tagged. > Quoting: >=20 > * Tag 36 is for MIME messages (including all headers), as defined in > {{RFC2045}}. A text string that isn't a valid MIME message is > invalid. >=20 > [=E2=80=A6] >=20 > Tag 24 (CBOR data item) can be used to tag the > embedded byte string as a data item encoded in CBOR format. Contained > items that aren't byte strings are invalid. Any contained byte string > is valid, even if it encodes an invalid or ill-formed CBOR item. >=20 > What is our position on embedded formats? Why is MIME validity-checked= and CBOR not? I would expect a consistent answer here, one that also ca= n guide new tag definitions. However, Tag 24 is always going to be a slightly special case, isn't it? = A CBOR implementation is surely able to check whether the embedded CBOR i= s valid. But a validator for some other embedded format may not even be a= vailable in a particular implementation. > Given that Tag validity checking is optional in a generic decoder (whic= h we still need to properly write up; currently only the security conside= rations are clear about that), we can be a bit strict on the definition o= f validity here: I=E2=80=99m leaning towards making CBOR well-formedness= (or validity?) a prerequisite of tag 24 validity. Looking at the code I wrote for Tag 24 encoded values in GRASP objectives= , I see that I effectively enforced that rule at the encoding stage, to a= void the risk of an exception at the decoding stage. So I think I agree w= ith you. Brian >=20 > (Now https://github.com/cbor-wg/CBORbis/issues/86 .) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Wed Jul 3 01:19:53 2019 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 2F1B61207AD; Wed, 3 Jul 2019 01:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 e5tujRalLeCV; Wed, 3 Jul 2019 01:19:31 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220BD120784; Wed, 3 Jul 2019 01:19:31 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dvCj0bQjzyXp; Wed, 3 Jul 2019 10:19:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mao-Original-Outgoing-Id: 583834767.013062-bdf4889171780bfa535d450990982355 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Jul 2019 10:19:28 +0200 Message-Id: To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 08:19:39 -0000 From nobody Wed Jul 3 01:39:18 2019 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 7E51B120691; Wed, 3 Jul 2019 01:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 NxBvF5fFf-i6; Wed, 3 Jul 2019 01:39:07 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B851202E3; Wed, 3 Jul 2019 01:39:07 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dvDl2NLzzyTX; Wed, 3 Jul 2019 10:20:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583834821.1630419-43cd4d155cf509da54f578df08c885de Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 3 Jul 2019 10:20:23 +0200 To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 08:39:11 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF105. Remember that, even though this will now go to the printers, there is still some potential for changes. Conflicts that meet the eye: COSE/TEEP stays; ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. LAKE and LOOPS have been disentangled, thank you. I have put in some side meetings, but that picture may still change (and I don't understand the timezone logic of that system, so it may be all wrong). All times are EDT (Eastern Daylight Time) =3D=3D UTC -4 hours. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, July 19, 2019 -- OMA/T2TRG Work Meeting - @ Ericsson Montreal Office (St-Laurent) SATURDAY/SUNDAY, July 20/21, 2019 -- Hackathon (including various interops) - Centre Ville SUNDAY, July 21, 2019 -- Sun 1700-1900 Welcome Reception - Place du Canada -- Sun 1800-2000 Hot RFC Lightning Talks - Viger MONDAY, July 22, 2019 1000-1200 Morning Session I Van Horne SEC acme Automated Certificate Management = Environment WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Laurier TSV loops Local Optimizations on Path Segments BOF 1330-1530 Afternoon Session I St-Catherine INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Place du Canada SEC secdispatch Security Dispatch WG Van Horne TSV taps Transport Services WG 1550-1750 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG St-Catherine OPS v6ops IPv6 Operations WG Van Horne SEC *** lake Lightweight Authenticated Key Exchange = BOF 1810-1910 Afternoon Session III Laurier ART dispatch Dispatch WG - Joint with ARTAREA TUESDAY, July 23, 2019 0830-0945 Side Meetings / Open Time C2 (21st Floor) IoT Onboarding and MUD (0900..1030?) Place du Canada IETF tdd Technology Deep Dive - How NICs Work = Today 1000-1200 Morning Session I St-Catherine ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG - 1000-1130 St-Catherine INT ipwave IP Wireless Access in Vehicular = Environments WG - 1130-1200 Notre Dame IRTF icnrg Information-Centric Networking Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG Van Horne SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Centre Ville OPS anima Autonomic Networking Integrated Model = and Approach WG 1520-1650 Afternoon Session II Duluth INT intarea Internet Area Working Group WG Place du Canada IRTF irtfopen IRTF Open Meeting Van Horne SEC oauth Web Authorization Protocol WG Collier CoRAL side meeting (1500..1700?) 1710-1810 Afternoon Session III Duluth ART *** core Constrained RESTful Environments WG Laurier INT 6man IPv6 Maintenance WG Place du Canada SEC tls Transport Layer Security WG WEDNESDAY, July 24, 2019 1000-1200 Morning Session I Van Horne IRTF*** dinrg Decentralized Internet Infrastructure St-Catherine RTG *** roll Routing Over Low power and Lossy = networks WG Viger SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1530 Afternoon Session I Place du Canada GEN netrqmts IETF Meeting Network = Requirements BOF Laurier IRTF pearg Privacy Enhancements and Assessments = Research Group Viger IRTF*** t2trg Thing-to-Thing St-Catherine RTG bier Bit Indexed Explicit Replication WG Centre Ville RTG detnet Deterministic Networking WG 1550-1650 Afternoon Session II St-Catherine RTG babel Babel routing protocol WG Centre Ville RTG detnet Deterministic Networking WG Van Horne SEC *** rats Remote ATtestation ProcedureS WG THURSDAY, July 25, 2019 1000-1200 Morning Session I Duluth ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Laurier TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Viger IRTF coinrg Computing in the Network Proposed = Research Group Laurier IRTF panrg Path Aware Networking RG Place du Canada SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT 6man IPv6 Maintenance WG Place du Canada IRTF cfrg Crypto Forum Van Horne RTG rift Routing In Fat Trees WG St-Catherine SEC *** rats Remote ATtestation ProcedureS WG Centre Ville TSV tsvarea Transport Area Open Meeting 1740-1910 Afternoon Session III Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** ace Authentication and Authorization for = Constrained Environments WG Place du Canada SEC mls Messaging Layer Security WG St-Catherine TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 26, 2019 1000-1200 Morning Session I Notre Dame ART ice Interactive Connectivity Establishment = WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Laurier SEC mls Messaging Layer Security WG Duluth SEC oauth Web Authorization Protocol WG 1220-1350 Afternoon Session I Van Horne SEC *** cose CBOR Object Signing and Encryption WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Place du Canada TSV tsvwg Transport Area Working Group WG From nobody Wed Jul 3 01:43:23 2019 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 2AC61120186 for ; Wed, 3 Jul 2019 01:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gfNH6DVJh4fk for ; Wed, 3 Jul 2019 01:43:19 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074A1120183 for ; Wed, 3 Jul 2019 01:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6tic0IguTRGfN8gnp/wt25DHw1JUyf5gWnD36yqRAbc=; b=UU6z86EoEDRaNMhrbThxlpioY1d1Es5k8iVZ+qcRU/TkeKgPv5ufuemHM5vw36H7EvXfA6nr3nmfSGxbGwzaUh5oiwWjcxnMfm6PIpkSSxdAq+VrlrSlZJoA1lGW8aTUrgDOhmeIqpUmr9kzaMGuU3DlqkfDRTRJQoKNP+qClmM= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.9; Wed, 3 Jul 2019 08:43:16 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2052.010; Wed, 3 Jul 2019 08:43:16 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Reminder: CBOR Interim: 2019-07-03 Thread-Index: AQHVMXtb3Ge/xMFsREGx/Kmay2qkkQ== Date: Wed, 3 Jul 2019 08:43:16 +0000 Message-ID: <223C7599-D306-4483-9ACF-3B0B7D8661BF@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 291000b6-d72a-4fbd-3569-08d6ff927df7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2859; x-ms-traffictypediagnostic: HE1PR0701MB2859: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(189003)(199004)(497574002)(53754006)(66946007)(76116006)(2501003)(73956011)(71200400001)(71190400001)(86362001)(186003)(236005)(44832011)(66616009)(64756008)(66556008)(66476007)(66446008)(7736002)(68736007)(3846002)(5660300002)(4001150100001)(6116002)(6486002)(6512007)(5640700003)(316002)(25786009)(54896002)(6306002)(6436002)(81166006)(81156014)(8676002)(486006)(2616005)(476003)(66066001)(53936002)(99936001)(36756003)(606006)(1730700003)(966005)(8936002)(19627405001)(102836004)(2351001)(33656002)(14444005)(256004)(2906002)(26005)(14454004)(478600001)(6916009)(99286004)(6506007)(53546011)(16799955002)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2859; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HXsfcuI4pB4jrx1gAU158NxdB9ADCK+/mKpjLq/+AhobCjJEtmmMvneZW2U+i3melhTq2LZj5Zkh5Fhq9oYVtM+30nhqei1hONKatxZ4/KmNqDkMDulVgLKgM3k1VPYYTWT1xkwFe4lLYDZ+E+UDG7lvGcPsyEM1CPc4FxZHxED6IPgy3nVmX+C+wRXow9zXQg5TekARjDpnavFjx4QZNa2aVz7L6yEDdgsM1uNJKxJkZiYF4DwHmX1tsMU+OGi2rYQoq5RMbHx87nNQJixqr0Nc8LoAJqksD4xaaAaF7hBY0wxvF+cO68fEqRee+iMo9aa89C7K49RBvEssUPMympMLTtNnLM6Y2viNo3swWsbTOBLn0hdiTt8lc/dYa7npwx8ivfEii1u+YnFATmmLnxtA/KGX55o8W2Vyavaa6eI= Content-Type: multipart/mixed; boundary="_004_223C7599D30644839ACF3B0B7D8661BFericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 291000b6-d72a-4fbd-3569-08d6ff927df7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 08:43:16.1365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2859 Archived-At: Subject: [Cbor] Reminder: CBOR Interim: 2019-07-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 08:43:22 -0000 --_004_223C7599D30644839ACF3B0B7D8661BFericssoncom_ Content-Type: multipart/alternative; boundary="_000_223C7599D30644839ACF3B0B7D8661BFericssoncom_" --_000_223C7599D30644839ACF3B0B7D8661BFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpIZXJlIGFyZSB0aGUgZGV0YWlscyBmb3IgdG9kYXnigJlzIGludGVyaW06DQoN CiogV2ViZXg6IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4 MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNQ0KKiBBZ2VuZGE6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2Jvci0xMC9tYXRlcmlhbHMvYWdlbmRhLWlu dGVyaW0tMjAxOS1jYm9yLTEwLXNlc3NhLnR4dA0KKiBUaW1lOiBodHRwczovL3d3dy53b3JsZHRp bWVidWRkeS5jb20vP3FtPTEmbGlkPTEyLDEwMCw1LDgmaD0xMDAmZGF0ZT0yMDE5LTctMyZzbG49 MTUtMTYNCg0KDQpUYWxrIHRvIHlvdSBzb29uLA0KRnJhbmNlc2NhDQpGcm9tOiBDQk9SIFdvcmtp bmcgR3JvdXAgPG1lc3NlbmdlckB3ZWJleC5jb20+DQpSZXBseS1UbzogImNib3ItY2hhaXJzQGll dGYub3JnIiA8Y2Jvci1jaGFpcnNAaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCAyMSBNYXkgMjAx OSBhdCAxMTo0Nw0KVG86ICJjYm9yLWNoYWlyc0BpZXRmLm9yZyIgPGNib3ItY2hhaXJzQGlldGYu b3JnPg0KU3ViamVjdDogKEZvcndhcmQgdG8gb3RoZXJzKSBXZWJleCBtZWV0aW5nIGludml0YXRp b246IENCT1IgV0cgQ29uZmVyZW5jZSBDYWxsDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNA aWV0Zi5vcmc+DQpSZXNlbnQtVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+ LCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4N ClJlc2VudC1EYXRlOiBUdWVzZGF5LCAyMSBNYXkgMjAxOSBhdCAxMTo0Mg0KDQpZb3UgY2FuIGZv cndhcmQgdGhpcyBpbnZpdGF0aW9uIHRvIG90aGVycy4NCg0KSGVsbG8sDQpDQk9SIFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuDQoNCg0KDQpDQk9S IFdHIENvbmZlcmVuY2UgQ2FsbA0KT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkg ZWZmZWN0aXZlIFdlZG5lc2RheSwgTWF5IDIyLCAyMDE5IHVudGlsIFdlZG5lc2RheSwgTm92ZW1i ZXIgNiwgMjAxOSBmcm9tIDU6MDAgUE0gdG8gNjowMCBQTSwgKFVUQyswMTowMCkgQW1zdGVyZGFt LCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hDQo1OjAwIHBtICB8ICBFdXJv cGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UKzAyOjAwKSAgfCAgMSBocg0KDQpNZWV0aW5n IG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDEgNzYwIDE1Nw0KDQpNZWV0aW5nIHBhc3N3b3JkOiBV UEF0OXJCbg0KDQoNCg0KQWRkIHRvIENhbGVuZGFyPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW0xZDA2MzYwNjlhMjhiZDdjOGNjMDkwZTc0MTU2NWM4Yz4NCldoZW4gaXQn cyB0aW1lLCBqb2luIHRoZSBtZWV0aW5nPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNT4uDQoNCg0KDQpKb2luIGJ5 IHBob25lDQoxLTY1MC00NzktMzIwODx0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDE3NjAx NTclMjMlMjMqMDEqPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQpDYW4n dCBqb2luIHRoZSBtZWV0aW5nPyA8aHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20v YXJ0aWNsZS9XQlgwMDAwMjkwNTU+DQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg== --_000_223C7599D30644839ACF3B0B7D8661BFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4093DF61C04DEB48BCA7A447AC7845C2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojNjY2 NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToi QXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzY2NjY2NiIgdmxpbms9IiM2NjY2NjYiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+SGkgYWxsLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczog YXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+SGVyZSBhcmUgdGhlIGRldGFpbHMgZm9yIHRvZGF54oCZcyBpbnRlcmltOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1 dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KiBX ZWJleDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEyMzdhOTgxMjQx MTFkZTNhNGM0ZTYxZGZhY2EwNWQ1Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tMTIzN2E5ODEyNDExMWRlM2E0YzRlNjFkZmFjYTA1ZDU8L3Nw YW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQoqIEFnZW5kYTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy9pbnRlcmltLTIwMTktY2Jvci0xMC9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAxOS1jYm9y LTEwLXNlc3NhLnR4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9tZWV0aW5nL2ludGVyaW0tMjAxOS1jYm9yLTEwL21hdGVyaWFscy9hZ2VuZGEtaW50ZXJpbS0y MDE5LWNib3ItMTAtc2Vzc2EudHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KiBUaW1lOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cud29ybGR0aW1lYnVkZHkuY29tLz9xbT0xJmFtcDtsaWQ9MTIsMTAwLDUsOCZhbXA7 aD0xMDAmYW1wO2RhdGU9MjAxOS03LTMmYW1wO3Nsbj0xNS0xNiI+aHR0cHM6Ly93d3cud29ybGR0 aW1lYnVkZHkuY29tLz9xbT0xJmFtcDtsaWQ9MTIsMTAwLDUsOCZhbXA7aD0xMDAmYW1wO2RhdGU9 MjAxOS03LTMmYW1wO3Nsbj0xNS0xNjwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRhbGsgdG8geW91 IHNvb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkNCT1IgV29ya2luZyBHcm91cCAmbHQ7bWVz c2VuZ2VyQHdlYmV4LmNvbSZndDs8YnI+DQo8Yj5SZXBseS1UbzogPC9iPiZxdW90O2Nib3ItY2hh aXJzQGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgMjEgTWF5IDIwMTkgYXQgMTE6NDc8YnI+DQo8Yj5UbzogPC9iPiZx dW90O2Nib3ItY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yLWNoYWlyc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+KEZvcndhcmQgdG8gb3RoZXJzKSBXZWJleCBtZWV0aW5n IGludml0YXRpb246IENCT1IgV0cgQ29uZmVyZW5jZSBDYWxsPGJyPg0KPGI+UmVzZW50LUZyb206 IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwv Yj5KaW0gU2NoYWFkICZsdDtpZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OywgRnJhbmNlc2NhIFBh bG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+ UmVzZW50LURhdGU6IDwvYj5UdWVzZGF5LCAyMSBNYXkgMjAxOSBhdCAxMTo0MjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3 aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMuNzVwdCAw Y20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43 NXB0O21hcmdpbi1sZWZ0OjMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9Indp ZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPllvdSBjYW4gZm9yd2FyZCB0aGlzIGlu dml0YXRpb24gdG8gb3RoZXJzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM0RDRENEQiPkhlbGxvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ny41cHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzRENEQ0RCI+Q0JPUiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpv aW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0 RDRENEQiPkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM0RDRENEQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjYiPk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gV2VkbmVzZGF5IGVmZmVjdGl2ZSBXZWRu ZXNkYXksIE1heSAyMiwgMjAxOSB1bnRpbCBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkgZnJv bSA1OjAwIFBNIHRvIDY6MDAgUE0sIChVVEMmIzQzOzAxOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwg QmVybiwgUm9tZSwgU3RvY2tob2xtLA0KIFZpZW5uYSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+NTowMCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtF dXJvcGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UJiM0MzswMjowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MSBocg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQxIDc2MCAxNTcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9y dGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgcGFzc3dvcmQ6IFVQQXQ5ckJuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJv ZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTtiYWNr Z3JvdW5kOiMwNDhDQkY7Ym9yZGVyOnNvbGlkICMwNDhDQkYgMS41cHQ7d2lkdGg6YXV0byFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjEw LjVwdCAxNS4wcHQgMTAuNXB0IDE1LjBwdDt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6 IDE4NnB4IWltcG9ydGFudCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tMWQwNjM2MDY5YTI4YmQ3YzhjYzA5MGU3NDE1NjVjOGMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTUuMHB0O2NvbG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5BZGQg dG8gQ2FsZW5kYXI8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i MCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHgh aW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAxMi4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4NnB4IWltcG9ydGFudCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5XaGVuIGl0J3MgdGltZSwNCjxhIGhyZWY9Imh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2 MWRmYWNhMDVkNSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246 bm9uZSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+PGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNzYwMTU3 JTIzJTIzKjAxKiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYT48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+DQogQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJo ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhy ZWY9Imh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5 MDU1Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Q2Fu J3Qgam9pbiB0aGUgbWVldGluZz8NCjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7 ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBz dHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6Ny41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6Ny41cHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTBBMEEwIj5JTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n DQogdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_223C7599D30644839ACF3B0B7D8661BFericssoncom_-- --_004_223C7599D30644839ACF3B0B7D8661BFericssoncom_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6673; creation-date="Wed, 03 Jul 2019 08:43:15 GMT"; modification-date="Wed, 03 Jul 2019 08:43:15 GMT" Content-ID: <1341544B0B56E64FBAC12EF0A9914F92@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8vRXVyb3BlL0Ftc3RlcmRhbQ0KWC1MSUMtTE9DQVRJT046RXVyb3BlL0Ftc3RlcmRhbQ0K QkVHSU46REFZTElHSFQNClRaT0ZGU0VURlJPTTorMDEwMA0KVFpPRkZTRVRUTzorMDIwMA0KVFpO QU1FOkNFU1QNCkRUU1RBUlQ6MTk4MTAzMjlUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1P TlRIPTM7QllEQVk9LTFTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRG Uk9NOiswMjAwDQpUWk9GRlNFVFRPOiswMTAwDQpUWk5BTUU6Q0VUDQpEVFNUQVJUOjE5OTYxMDI3 VDAzMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMDtCWURBWT0tMVNVDQpFTkQ6U1RB TkRBUkQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAwMTkzMg0KVFpPRkZTRVRUTzor MDAxOTMyDQpUWk5BTUU6QU1UDQpEVFNUQVJUOjE4MzUwMTAxVDAwMDAwMA0KUkRBVEU6MTgzNTAx MDFUMDAwMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006KzAw MTkzMg0KVFpPRkZTRVRUTzorMDExOTMyDQpUWk5BTUU6TlNUDQpEVFNUQVJUOjE5MTYwNTAxVDAw MDAwMA0KUkRBVEU6MTkxNjA1MDFUMDAwMDAwDQpSREFURToxOTE3MDQxNlQwMjAwMDANClJEQVRF OjE5MTgwNDAxVDAyMDAwMA0KUkRBVEU6MTkxOTA0MDdUMDIwMDAwDQpSREFURToxOTIwMDQwNVQw MjAwMDANClJEQVRFOjE5MjEwNDA0VDAyMDAwMA0KUkRBVEU6MTkyMjAzMjZUMDIwMDAwDQpSREFU RToxOTIzMDYwMVQwMjAwMDANClJEQVRFOjE5MjQwMzMwVDAyMDAwMA0KUkRBVEU6MTkyNTA2MDVU MDIwMDAwDQpSREFURToxOTI2MDUxNVQwMjAwMDANClJEQVRFOjE5MjcwNTE1VDAyMDAwMA0KUkRB VEU6MTkyODA1MTVUMDIwMDAwDQpSREFURToxOTI5MDUxNVQwMjAwMDANClJEQVRFOjE5MzAwNTE1 VDAyMDAwMA0KUkRBVEU6MTkzMTA1MTVUMDIwMDAwDQpSREFURToxOTMyMDUyMlQwMjAwMDANClJE QVRFOjE5MzMwNTE1VDAyMDAwMA0KUkRBVEU6MTkzNDA1MTVUMDIwMDAwDQpSREFURToxOTM1MDUx NVQwMjAwMDANClJEQVRFOjE5MzYwNTE1VDAyMDAwMA0KUkRBVEU6MTkzNzA1MjJUMDIwMDAwDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAxMTkzMg0KVFpPRkZT RVRUTzorMDAxOTMyDQpUWk5BTUU6QU1UDQpEVFNUQVJUOjE5MTYxMDAxVDAwMDAwMA0KUkRBVEU6 MTkxNjEwMDFUMDAwMDAwDQpSREFURToxOTE3MDkxN1QwMzAwMDANClJEQVRFOjE5MTgwOTMwVDAz MDAwMA0KUkRBVEU6MTkxOTA5MjlUMDMwMDAwDQpSREFURToxOTIwMDkyN1QwMzAwMDANClJEQVRF OjE5MjEwOTI2VDAzMDAwMA0KUkRBVEU6MTkyMjEwMDhUMDMwMDAwDQpSREFURToxOTIzMTAwN1Qw MzAwMDANClJEQVRFOjE5MjQxMDA1VDAzMDAwMA0KUkRBVEU6MTkyNTEwMDRUMDMwMDAwDQpSREFU RToxOTI2MTAwM1QwMzAwMDANClJEQVRFOjE5MjcxMDAyVDAzMDAwMA0KUkRBVEU6MTkyODEwMDdU MDMwMDAwDQpSREFURToxOTI5MTAwNlQwMzAwMDANClJEQVRFOjE5MzAxMDA1VDAzMDAwMA0KUkRB VEU6MTkzMTEwMDRUMDMwMDAwDQpSREFURToxOTMyMTAwMlQwMzAwMDANClJEQVRFOjE5MzMxMDA4 VDAzMDAwMA0KUkRBVEU6MTkzNDEwMDdUMDMwMDAwDQpSREFURToxOTM1MTAwNlQwMzAwMDANClJE QVRFOjE5MzYxMDA0VDAzMDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZT RVRGUk9NOiswMTE5MzINClRaT0ZGU0VUVE86KzAxMjANClRaTkFNRTorMDEyMA0KRFRTVEFSVDox OTM3MDcwMVQwMDAwMDANClJEQVRFOjE5MzcwNzAxVDAwMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJ TjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMTIwDQpUWk9GRlNFVFRPOiswMDIwDQpUWk5BTUU6 KzAwMjANCkRUU1RBUlQ6MTkzNzEwMDNUMDMwMDAwDQpSREFURToxOTM3MTAwM1QwMzAwMDANClJE QVRFOjE5MzgxMDAyVDAzMDAwMA0KUkRBVEU6MTkzOTEwMDhUMDMwMDAwDQpFTkQ6U1RBTkRBUkQN CkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006KzAwMjANClRaT0ZGU0VUVE86KzAxMjANClRa TkFNRTorMDEyMA0KRFRTVEFSVDoxOTM4MDUxNVQwMjAwMDANClJEQVRFOjE5MzgwNTE1VDAyMDAw MA0KUkRBVEU6MTkzOTA1MTVUMDIwMDAwDQpFTkQ6REFZTElHSFQNCkJFR0lOOkRBWUxJR0hUDQpU Wk9GRlNFVEZST006KzAwMjANClRaT0ZGU0VUVE86KzAyMDANClRaTkFNRTpDRVNUDQpEVFNUQVJU OjE5NDAwNTE2VDAwMDAwMA0KUkRBVEU6MTk0MDA1MTZUMDAwMDAwDQpFTkQ6REFZTElHSFQNCkJF R0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFN RTpDRVQNCkRUU1RBUlQ6MTk0MjExMDJUMDMwMDAwDQpSREFURToxOTQyMTEwMlQwMzAwMDANClJE QVRFOjE5NDMxMDA0VDAzMDAwMA0KUkRBVEU6MTk0NDEwMDJUMDMwMDAwDQpSREFURToxOTQ1MDkx NlQwMzAwMDANClJEQVRFOjE5NzcwOTI1VDAzMDAwMA0KUkRBVEU6MTk3ODEwMDFUMDMwMDAwDQpS REFURToxOTc5MDkzMFQwMzAwMDANClJEQVRFOjE5ODAwOTI4VDAzMDAwMA0KUkRBVEU6MTk4MTA5 MjdUMDMwMDAwDQpSREFURToxOTgyMDkyNlQwMzAwMDANClJEQVRFOjE5ODMwOTI1VDAzMDAwMA0K UkRBVEU6MTk4NDA5MzBUMDMwMDAwDQpSREFURToxOTg1MDkyOVQwMzAwMDANClJEQVRFOjE5ODYw OTI4VDAzMDAwMA0KUkRBVEU6MTk4NzA5MjdUMDMwMDAwDQpSREFURToxOTg4MDkyNVQwMzAwMDAN ClJEQVRFOjE5ODkwOTI0VDAzMDAwMA0KUkRBVEU6MTk5MDA5MzBUMDMwMDAwDQpSREFURToxOTkx MDkyOVQwMzAwMDANClJEQVRFOjE5OTIwOTI3VDAzMDAwMA0KUkRBVEU6MTk5MzA5MjZUMDMwMDAw DQpSREFURToxOTk0MDkyNVQwMzAwMDANClJEQVRFOjE5OTUwOTI0VDAzMDAwMA0KRU5EOlNUQU5E QVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAw DQpUWk5BTUU6Q0VTVA0KRFRTVEFSVDoxOTQzMDMyOVQwMjAwMDANClJEQVRFOjE5NDMwMzI5VDAy MDAwMA0KUkRBVEU6MTk0NDA0MDNUMDIwMDAwDQpSREFURToxOTQ1MDQwMlQwMjAwMDANClJEQVRF OjE5NzcwNDAzVDAyMDAwMA0KUkRBVEU6MTk3ODA0MDJUMDIwMDAwDQpSREFURToxOTc5MDQwMVQw MjAwMDANClJEQVRFOjE5ODAwNDA2VDAyMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFS RA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMTAwDQpUWk5BTUU6Q0VUDQpEVFNU QVJUOjE5NzcwMTAxVDAwMDAwMA0KUkRBVEU6MTk3NzAxMDFUMDAwMDAwDQpFTkQ6U1RBTkRBUkQN CkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDE5MDUyMVQwOTQyNTFaDQpB VFRFTkRFRTtDTj0iQ0JPUiBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQ PVRSVUU6TUFJTFRPOmNib3ItY2hhaXJzQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkNCT1IgV29y a2luZyBHcm91cCI6TUFJTFRPOmNib3ItY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9RXVy b3BlL0Ftc3RlcmRhbToyMDE5MDUyMlQxNzAwMDANCkRURU5EO1RaSUQ9RXVyb3BlL0Ftc3RlcmRh bToyMDE5MDUyMlQxODAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0K VFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU1ODQzMTc3MQ0KVUlEOjAyNmY1ZDFmLTRhYTUtNDA2 OS1hNWI3LWJlY2I5ZmVjZmRlOQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJ Tkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMjM3YTk4MTI0MTEx ZGUzYTRjNGU2MWRmYWNhMDVkNVxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDc2 MCAxNTdcbk1lZXRpbmcgcGFzc3dvcmQ6IFVQQXQ5ckJuXG5cblxuXG5KT0lOIEJZIFBIT05FXG4x LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0 byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSo2NDE3NjAxNTclMjMlMjMqMDEqXG5cblxuXG5cbkNhbid0IGpv aW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRp Y2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQg dGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2Vu dCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3Zl cmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0 b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25z ZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9z dCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQv aHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+XG4JCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW0xMjM3YTk4MTI0MTExZGUzYTRjNGU2MWRmYWNhMDVkNSI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYmV4IG1lZXRpbmc8L0ZPTlQ+PC9hPlxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2 NDEgNzYwIDE1NzwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJ CVxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5VUEF0OXJCbjwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cbgkJPC9GT05UPlxuPGJyPjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZP TlQ+PGJyPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+ PC9GT05UPlxuXG5cbiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MTc2MDE1NyUyMyUyMyow MSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz4xLTY1MC00 NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZP TlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG5cblxuCSZuYnNwOzxCUj5cbgk8YSBocmVmPSJodHRw czovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSI+XG4J PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRo ZSBtZWV0aW5nPzwvRk9OVD48L2E+XG4JJm5ic3A7PEJSPiZuYnNwOzxCUj5cblxuPEZPTlQgQ09M T1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPlxuPC9GT05U PlxuDQpTVU1NQVJZOkNCT1IgV0cgQ29uZmVyZW5jZSBDYWxsDQpQUklPUklUWTo1DQpDTEFTUzpQ VUJMSUMNClJSVUxFOkZSRVE9V0VFS0xZO1dLU1Q9U1U7VU5USUw9MjAxOTExMDY7SU5URVJWQUw9 MjtCWURBWT1XRQ0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0K REVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5E QVINCg== --_004_223C7599D30644839ACF3B0B7D8661BFericssoncom_-- From nobody Wed Jul 3 06:24:22 2019 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 346F8120043; Wed, 3 Jul 2019 06:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 QNnL-FL-2ida; Wed, 3 Jul 2019 06:24:12 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 EC46D120603; Wed, 3 Jul 2019 06:23:17 -0700 (PDT) Received: from ip-109-42-2-15.web.vodafone.de ([109.42.2.15] helo=2-10.mgmt.ericsson.se); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hifE9-0006QV-Hr; Wed, 03 Jul 2019 15:23:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <7ACCCA75-39DC-499E-A108-CE392D0889B6@tzi.org> Date: Wed, 3 Jul 2019 15:23:12 +0200 Cc: Alexey Melnikov , cbor@ietf.org, The IESG , cbor-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7F06504B-0C4B-4E18-85FF-407808792F46@kuehlewind.net> References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net> <7ACCCA75-39DC-499E-A108-CE392D0889B6@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562160198;41453d10; X-HE-SMSGID: 1hifE9-0006QV-Hr Archived-At: Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 13:24:15 -0000 Hi Carsten, Having a more open charter is fine as well, if you see this as going = into maintenance mode. However, I don=E2=80=99t really see the value in = defining this additional process with these three categories (which are = also not completely clear to everybody and therefore probably not always = straight forward to map). I would recommend to discuss every proposed = tag separately and have a wg call to add a milestone for a tag if = accepted in the group. I=E2=80=99d otherwise even be afraid that having = these categories might focus any adoption discussion too much on the = scope only and may end up not being very unconstructive. Therefore I = still recommend to remove that part from the charter. Maybe say = something other like: "The working group will evaluate such proposal individually and decide = about addition of a respective milestone. Proposals that are deemed to = be out of scope for the working group, e.g. because they are too narrow = purpose specifications, may still be published as individual submission = or in another groups if there is a specific need. The cbor group will = review these proposals on request.=E2=80=9D Or something similar=E2=80=A6 Mirja > On 2. Jul 2019, at 19:44, Carsten Bormann wrote: >=20 > Hi Mirja, >=20 > On Jul 2, 2019, at 17:52, Mirja Kuehlewind = wrote: >>=20 >>> Are you suggesting that the Charter should just list specific = documents and require rechartering once the work is done? >>=20 >> Yes, I think that would actually be the better approach, where = document should not be specific drafts but specific work items. >=20 > We did that in the previous (current) charter, and it was a mistake. >=20 > Tags are the most prominent defined extension point for CBOR, defined = so there is a low threshold to actually making an =E2=80=9Cextension=E2=80= =9D (defining a tag), mostly done by third parties via IANA = registrations. It does make sense to coordinate some of this from the = WG and pick some strategic tags for WG attention. It makes more sense = when this can be done flexibly and quickly. >=20 > The current charter from 2.5 years ago lists a couple of tag = documents, one of which we chose not to progress right now after all and = one that did move forward (WGLC completed). There are a couple other = documents that are de facto WG documents but can=E2=80=99t be = officially. That just serves to slow down work. It=E2=80=99s a bit as = if the DHC working group needed to be rechartered for each new DHCP = option. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 From nobody Wed Jul 3 07:28:30 2019 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 F1FE3120230; Wed, 3 Jul 2019 07:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 AAQ9hBsyGgnp; Wed, 3 Jul 2019 07:28:27 -0700 (PDT) Received: from gabriel-vm-2.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2814012008F; Wed, 3 Jul 2019 07:28:27 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.uni-bremen.de (Postfix) with ESMTPSA id 45f3PP0LCFz14Vx; Wed, 3 Jul 2019 16:28:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <7F06504B-0C4B-4E18-85FF-407808792F46@kuehlewind.net> Date: Wed, 3 Jul 2019 16:28:37 +0200 Cc: cbor@ietf.org, cbor-chairs@ietf.org, The IESG , Alexey Melnikov X-Mao-Original-Outgoing-Id: 583856916.1106811-6f1f25bff06aa5ad9dc04b50431dd237 Content-Transfer-Encoding: quoted-printable Message-Id: <25AD5BFD-743B-4C0B-9BDF-FD7855A05480@tzi.org> References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net> <7ACCCA75-39DC-499E-A108-CE392D0889B6@tzi.org> <7F06504B-0C4B-4E18-85FF-407808792F46@kuehlewind.net> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 14:28:29 -0000 Hi Mirja, these are good points. > On Jul 3, 2019, at 15:23, Mirja Kuehlewind = wrote: >=20 > Hi Carsten, >=20 > Having a more open charter is fine as well, if you see this as going = into maintenance mode. However, I don=E2=80=99t really see the value in = defining this additional process with these three categories (which are = also not completely clear to everybody and therefore probably not always = straight forward to map). I would recommend to discuss every proposed = tag separately and have a wg call to add a milestone for a tag if = accepted in the group. I=E2=80=99d otherwise even be afraid that having = these categories might focus any adoption discussion too much on the = scope only and may end up not being very unconstructive. I can imagine that, too (even if I think that the composition of the WG = so far wouldn=E2=80=99t fall for that, the composition can of course = change). > Therefore I still recommend to remove that part from the charter. = Maybe say something other like: >=20 > "The working group will evaluate such proposal individually and decide = about addition of a respective milestone. Proposals that are deemed to = be out of scope for the working group, e.g. because they are too narrow = purpose specifications, may still be published as individual submission = or in another groups if there is a specific need. The cbor group will = review these proposals on request.=E2=80=9D Works for me. I could imagine that the WG will get used over time to an evaluation = process that does make use of the two dimensions, broad vs. narrow, and = application development vs. Internet usage. But we can let the WG = evolve that process (e.g., in an informal way) on its own, without = having to touch the charter again on every step of that evolution. > Or something similar=E2=80=A6 I think we can discuss the details further in 35 minutes in our virtual = WG interim=E2=80=A6 Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 3 09:21:31 2019 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 9DDEC1202E1 for ; Wed, 3 Jul 2019 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bSRtj52G4AHz for ; Wed, 3 Jul 2019 09:21:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130040.outbound.protection.outlook.com [40.107.13.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF66120384 for ; Wed, 3 Jul 2019 09:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xAGM6arGHNDP8l7OTIQ8ZAZkYOlYwzR2s0QpH9eWdZ8=; b=mIsQJatnRPV+0fJ4Fudn1O9Q4QVSiC6XaZhBfVaV4iwZqOCb1ETOY1o3Cn59kc/F93vR5i2g+jQJOgBoU7U616Kiepnp7Zdd4IbEqBuadBIkwjGynvdrOMyUiEXdpQ5MalK17ldDYDnH68+Ud5nYGKCZGY3ItXH5YyVWSf9FXz4= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2684.eurprd07.prod.outlook.com (10.168.183.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.15; Wed, 3 Jul 2019 16:21:18 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2052.010; Wed, 3 Jul 2019 16:21:18 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Minutes interim 03-07-2019 Thread-Index: AQHVMbtXa7px6+Bom0KDPi1C6aVfnQ== Date: Wed, 3 Jul 2019 16:21:17 +0000 Message-ID: <01930853-9EB8-49A7-A4B6-276AEDF6D1DA@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [95.192.252.208] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df005657-d4a0-439f-a895-08d6ffd27a70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2684; x-ms-traffictypediagnostic: HE1PR0701MB2684: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(366004)(376002)(53754006)(199004)(189003)(66446008)(6436002)(54896002)(2501003)(5640700003)(3846002)(36756003)(6306002)(33656002)(99286004)(476003)(2616005)(606006)(6116002)(53936002)(86362001)(236005)(6512007)(478600001)(2351001)(4744005)(256004)(5660300002)(6486002)(486006)(81166006)(6506007)(64756008)(66476007)(26005)(44832011)(102836004)(186003)(68736007)(2906002)(7736002)(8676002)(8936002)(25786009)(6916009)(71190400001)(81156014)(1730700003)(66556008)(316002)(966005)(66066001)(66946007)(71200400001)(76116006)(73956011)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2684; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2moKRANDy/X1apb1yWXYvnQRZ4APLs1DVY+iTzT9k5IMc1ltpcWhkf1baLTHc7cqslSF+wbWB/tXZl4CwM2EBf+y7R/YDH4esZYfFnokZdQLxspOi0VeEWruYSKo8ZKurrR3v+hjfz/h6G5nf6jhetBvo1B/m9Ec5+uoWd8Gfkw265+tfsWW1GKwzt+8lii3nN5P2WL6SIxNRlajlBbzk5EwA1CpI9iN2ZSmJk7Y5hvKjM+S46JxqMSa5M0S67M3Ux1yjafi6JR8Ah1phSaHWB1pg0H2cBoLixb/bdOJHobdm7IOYtlah4M3vBDUgUZTP6HHOjMd3sZ74aXIz7lBcU6WaGKauNP2JbMf9iw5KG/LdC6lj8VOAsglBulGI3jFty+v6y+rbb1GaZFOwhz7w2LSrJKfxHT1Vv7gOPfbl/Y= Content-Type: multipart/alternative; boundary="_000_019308539EB849A7A4B6276AEDF6D1DAericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: df005657-d4a0-439f-a895-08d6ffd27a70 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 16:21:18.0173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2684 Archived-At: Subject: [Cbor] Minutes interim 03-07-2019 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 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 Jul 2019 16:21:30 -0000 --_000_019308539EB849A7A4B6276AEDF6D1DAericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpIZXJlIGFyZSB0aGUgbWludXRlcyBmcm9tIHRvZGF54oCZcyBpbnRlcmltOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LWNib3ItMTAv bWF0ZXJpYWxzL21pbnV0ZXMtaW50ZXJpbS0yMDE5LWNib3ItMTAtMjAxOTA3MDMxNTAwLnR4dA0K V2UgZG9u4oCZdCBoYXZlIGEgd2ViZXggcmVjb3JkaW5ncyBhcyB3ZSBydW4gb3V0IG9mIHNwYWNl LCBzb3JyeSBhYm91dCB0aGF0Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBuZXh0IHR3byBpbnRl cmltcyBhcmUgY2FuY2VsbGVkIChKdWx5IDE3IGFuZCBKdWx5IDMxKSwgbmV4dCBpbnRlcmltIHdp bGwgYmUgYWZ0ZXIgSUVURjEwNSwgQXVndXN0IDE0dGguDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K --_000_019308539EB849A7A4B6276AEDF6D1DAericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SGVyZSBhcmUgdGhlIG1pbnV0ZXMgZnJvbSB0b2RheeKAmXMgaW50ZXJpbToN Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50 ZXJpbS0yMDE5LWNib3ItMTAvbWF0ZXJpYWxzL21pbnV0ZXMtaW50ZXJpbS0yMDE5LWNib3ItMTAt MjAxOTA3MDMxNTAwLnR4dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2lu dGVyaW0tMjAxOS1jYm9yLTEwL21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAxOS1jYm9yLTEw LTIwMTkwNzAzMTUwMC50eHQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2UgZG9u4oCZdCBoYXZlIGEgd2ViZXgg cmVjb3JkaW5ncyBhcyB3ZSBydW4gb3V0IG9mIHNwYWNlLCBzb3JyeSBhYm91dCB0aGF0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIG5vdGUgdGhhdCB0 aGUgbmV4dCB0d28gaW50ZXJpbXMgYXJlIGNhbmNlbGxlZCAoSnVseSAxNyBhbmQgSnVseSAzMSks IG5leHQgaW50ZXJpbSB3aWxsIGJlIGFmdGVyIElFVEYxMDUsIEF1Z3VzdCAxNDxzdXA+dGg8L3N1 cD4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_019308539EB849A7A4B6276AEDF6D1DAericssoncom_-- From nobody Fri Jul 5 06:04:33 2019 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 164581200B3; Fri, 5 Jul 2019 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Z3aARxFwwfzT; Fri, 5 Jul 2019 06:04:24 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60081.outbound.protection.outlook.com [40.107.6.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F06120074; Fri, 5 Jul 2019 06:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TLLrYPFO4p7i875HZM4r0LapIUOIDJONI+G9J/VWv6s=; b=fiNMjiMdJaidqix/epkQkTaAeXHTOu/f0PlbXTZJu2WJd9ZZG6VQX8Ot48jj3yznyVji1mKeM1Dlol8Gr7M9wKeZUim9T/ub7rRSA108lx+LREPiUfEbtc81OeoPy/q5JK+duCvf/lBKDFoNdh6/r1yOV64vT1lgraN8d1omHhU= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2507.eurprd07.prod.outlook.com (10.168.129.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.14; Fri, 5 Jul 2019 13:04:21 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2052.019; Fri, 5 Jul 2019 13:04:21 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot request for IETF105 Thread-Index: AQHVMzIp/IGrf2ASDEaeZzOJlB9gag== Date: Fri, 5 Jul 2019 13:04:21 +0000 Message-ID: <32081BB0-6B39-47E0-A518-4DA1916F486E@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe988a7c-4bcf-4750-ddd8-08d701494bec x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2507; x-ms-traffictypediagnostic: HE1PR0701MB2507: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(53754006)(199004)(189003)(256004)(6436002)(1730700003)(14444005)(2501003)(8676002)(5640700003)(2906002)(6486002)(316002)(6916009)(966005)(66556008)(33656002)(4326008)(6306002)(66476007)(68736007)(8936002)(73956011)(486006)(71200400001)(53936002)(66946007)(44832011)(66446008)(14454004)(71190400001)(64756008)(7736002)(81166006)(305945005)(81156014)(76116006)(2616005)(476003)(6506007)(66066001)(86362001)(99286004)(6116002)(450100002)(3846002)(2351001)(36756003)(25786009)(6512007)(102836004)(5660300002)(478600001)(186003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2507; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wxwAb+2tYcUNMXrlUnytFVfDtvsE0nVP6e6X5GKt+BvTrGF3Vpwg4wy4VrkR/xbDXTyH56SpAl6FvYVors+tVl3KxxI62LXKTYMS0uLS2EzHZFealjx15AVBHeWb0Xq0Nb0C3uC3tdLWIJmntNGO2H0IFEgNsHF2FHq8gBtXxflsHS3Bhw2BR5/AXmfpXnCSUD8Yojf3c3kdgj3dQlQTLv8MHoId2HfrYSV13S1uXXQHyzKtLCfT9Gy4mCrIfUeELGgWp52j8qWJgDuNa8lCf3DUuuFJ66yaZvvknJFkg1DRHv2xsmMzoaSfgKLPNCgqHYpc4xF211iDKm807w11K3xpE+LeRvoa9dngUGRsYiBj2YL15fayLtN+4by8e/LteYTpoy21rGXier1c8cgQDVJm9JqLPlH6ZvaF9lFJufA= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe988a7c-4bcf-4750-ddd8-08d701494bec X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 13:04:21.2400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2507 Archived-At: Subject: [Cbor] Slot request for IETF105 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 13:04:27 -0000 SGkgYWxsLA0KDQpJZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIGEgcHJlc2VudGF0aW9uIHNsb3Qg ZHVyaW5nIG91ciBtZWV0aW5nIGluIE1vbnRyZWFsLCBwbGVhc2UgbGV0IHRoZSBjaGFpcnMga25v dy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDI5LzA2LzIwMTksIDAwOjU4LCAiIklF VEYgU2VjcmV0YXJpYXQiIiA8YWdlbmRhQGlldGYub3JnPiB3cm90ZToNCg0KICAgIERlYXIgRnJh bmNlc2NhIFBhbG9tYmluaSwNCiAgICANCiAgICBUaGUgc2Vzc2lvbihzKSB0aGF0IHlvdSBoYXZl IHJlcXVlc3RlZCBoYXZlIGJlZW4gc2NoZWR1bGVkLg0KICAgIEJlbG93IGlzIHRoZSBzY2hlZHVs ZWQgc2Vzc2lvbiBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieQ0KICAgIHRoZSBvcmlnaW5hbCByZXF1 ZXN0LiANCiAgICANCiAgICANCiAgICAgICAgY2JvciBTZXNzaW9uIDEgKDE6MzAgcmVxdWVzdGVk KQ0KICAgICAgICBUdWVzZGF5LCAyMyBKdWx5IDIwMTksIE1vcm5pbmcgU2Vzc2lvbiBJIDEwMDAt MTIwMA0KICAgICAgICBSb29tIE5hbWU6IFNhaW50ZS1DYXRoZXJpbmUgc2l6ZTogMTAwDQogICAg ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0K ICAgIFNwZWNpYWwgTm90ZTogMTAwMC0xMTMwDQogICAgDQogICAgaUNhbGVuZGFyOiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA1L3Nlc3Npb25zL2Nib3IuaWNzDQogICAg DQogICAgUmVxdWVzdCBJbmZvcm1hdGlvbjoNCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBXb3JraW5n IEdyb3VwIE5hbWU6IENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiBNYWludGVu YW5jZSBhbmQgRXh0ZW5zaW9ucw0KICAgIEFyZWEgTmFtZTogQXBwbGljYXRpb25zIGFuZCBSZWFs LVRpbWUgQXJlYQ0KICAgIFNlc3Npb24gUmVxdWVzdGVyOiBGcmFuY2VzY2EgUGFsb21iaW5pDQog ICAgDQogICAgTnVtYmVyIG9mIFNlc3Npb25zOiAxDQogICAgTGVuZ3RoIG9mIFNlc3Npb24ocyk6 ICAxLjUgSG91cnMNCiAgICBOdW1iZXIgb2YgQXR0ZW5kZWVzOiA1MA0KICAgIENvbmZsaWN0cyB0 byBBdm9pZDogDQogICAgIEZpcnN0IFByaW9yaXR5OiBzYWFnIGFjZSBjb3JlIGxhbXBzIGNvc2UN CiAgICAgU2Vjb25kIFByaW9yaXR5OiBlbXUgY2ZyZyBzZWNkaXNwYXRjaCB0bHMgdDJ0cmcgc3Vp dCBvYXV0aCByYXRzDQogICAgIFRoaXJkIFByaW9yaXR5OiBhbmltYSB0ZWVwIDZ0aXNjaCBjdXJk bGUgaHR0cGJpcyBkdG4gZG90cw0KICAgIA0KICAgIA0KICAgIFBlb3BsZSB3aG8gbXVzdCBiZSBw cmVzZW50Og0KICAgICAgQ2Fyc3RlbiBCb3JtYW5uDQogICAgICBBbGV4ZXkgTWVsbmlrb3YNCiAg ICAgIEppbSBTY2hhYWQNCiAgICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkNCiAgICANCiAgICBSZXNv dXJjZXMgUmVxdWVzdGVkOg0KICAgIA0KICAgIFNwZWNpYWwgUmVxdWVzdHM6DQogICAgICBQbGVh c2UgYXZvaWQgY29sbGlzaW9uIHdpdGggYW55IFNlYyBhbmQgSW9ULXJlbGF0ZWQgQm9Gcw0KICAg IA0KICAgIFBsZWFzZSBhdm9pZCBjb2xsaXNpb24gd2l0aCBsYWtlIChMaWdodHdlaWdodCBBS0Up DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgDQogICAgDQoNCg== From nobody Fri Jul 5 11:52:24 2019 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 EA40612010E for ; Fri, 5 Jul 2019 11:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 rFtcOa3LCtD5 for ; Fri, 5 Jul 2019 11:52:20 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (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 8CD57120105 for ; Fri, 5 Jul 2019 11:52:20 -0700 (PDT) Received: from [10.180.0.42] ([45.56.150.121]) by :SMTPAUTH: with ESMTPA id jTJjhhOv9oEnbjTJjhULzT; Fri, 05 Jul 2019 11:52:19 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_687FBF51-5BF8-450A-B2A3-41717CE89648" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <4276BFA8-D986-4145-97F2-D502F5EBE949@island-resort.com> References: <156222457028.12217.255889850248264885@ietfa.amsl.com> To: cbor@ietf.org Date: Fri, 5 Jul 2019 11:52:19 -0700 X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfDuZVx7a2dRTL4/gvXsBFpKpDMaALMk6jO1AS0CyX+NmLL3cWuUTFDvtyMtW7TJ17+wI/KT4c1WsEZiaejJUvOJK6jB2+itVP3WAqKpRySu8O9H4vXpA RzlwWstDjOadvYa7WlzTZKyWFdfKeNej4ETGb5S8o9D180w3G0QgLkNV Archived-At: Subject: [Cbor] New EAT draft using CDDL for information model X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 18:52:23 -0000 --Apple-Mail=_687FBF51-5BF8-450A-B2A3-41717CE89648 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This separates the information model from the data model. The = information model is described using CDDL. I used a CDDL group for each = claim. Hopefully this is a good way to do it. In later sections the = extra details needed for CBOR and JSON syntax are given. I=E2=80=99m not = so much after conversion between them. What is important that they both = be able to express the same claims so you don=E2=80=99t have a situation = where =E2=80=9Cyou have to use CBOR if you want claim XXX=E2=80=9D (or = vice versa). LL > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [Rats] I-D Action: draft-ietf-rats-eat-01.txt > Date: July 4, 2019 at 12:16:10 AM PDT > To: > > Cc: rats@ietf.org > Reply-To: rats@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Remote ATtestation ProcedureS WG of = the IETF. >=20 > Title : The Entity Attestation Token (EAT) > Authors : Giridhar Mandyam > Laurence Lundblade > Miguel Ballesteros > Jeremy O'Donoghue > Filename : draft-ietf-rats-eat-01.txt > Pages : 28 > Date : 2019-07-04 >=20 > Abstract: > An Entity Attestation Token (EAT) provides a signed (attested) set = of > claims that describe state and characteristics of an entity, > typically a device like a phone or an IoT device. These claims are > used by a relying party to determine how much it wishes to trust the > entity. >=20 > An EAT is either a CWT or JWT with some attestation-oriented claims. > To a large degree, all this document does is extend CWT and JWT. >=20 > Contributing >=20 > TBD >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rats-eat-01 > https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rats-eat-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats >=20 --Apple-Mail=_687FBF51-5BF8-450A-B2A3-41717CE89648 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This = separates the information model from the data model. The information = model is described using CDDL. I used a CDDL group for = each claim. Hopefully this is a good way to do it. In later sections the = extra details needed for CBOR and JSON syntax are given. I=E2=80=99m not = so much after conversion between them. What is important that they both = be able to express the same claims so you don=E2=80=99t have a situation = where =E2=80=9Cyou have to use CBOR if you want claim XXX=E2=80=9D (or = vice versa).

LL


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = [Rats] I-D = Action: draft-ietf-rats-eat-01.txt
Date: = July 4, 2019 at 12:16:10 AM = PDT
To: = <i-d-announce@ietf.org>
Cc: rats@ietf.org
Reply-To: = rats@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Remote = ATtestation ProcedureS WG of the IETF.

=        Title =           : The Entity = Attestation Token (EAT)
=        Authors =         : Giridhar Mandyam
=             &n= bsp;           &nbs= p;Laurence Lundblade
=             &n= bsp;           &nbs= p;Miguel Ballesteros
=             &n= bsp;           &nbs= p;Jeremy O'Donoghue
Filename =        : = draft-ietf-rats-eat-01.txt
Pages =           : 28
= Date =            : = 2019-07-04

Abstract:
=   An Entity Attestation Token (EAT) provides a signed = (attested) set of
  claims that describe state = and characteristics of an entity,
  typically a = device like a phone or an IoT device.  These claims are
  used by a relying party to determine how much it = wishes to trust the
  entity.

  An EAT is either a CWT or JWT with some = attestation-oriented claims.
  To a large = degree, all this document does is extend CWT and JWT.

Contributing

  TBD


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-rats-eat-01
https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-01
A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rats-eat-01


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/

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats


= --Apple-Mail=_687FBF51-5BF8-450A-B2A3-41717CE89648-- From nobody Fri Jul 5 13:40:34 2019 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 55E13120152 for ; Fri, 5 Jul 2019 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 C2mABerkgdzl for ; Fri, 5 Jul 2019 13:40:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0CB12015C for ; Fri, 5 Jul 2019 13:40:23 -0700 (PDT) Received: from client-0017.vpn.uni-bremen.de (client-0017.vpn.uni-bremen.de [134.102.107.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45gRYd22yKzyTK; Fri, 5 Jul 2019 22:40:21 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 584052018.873126-4bb5845f07a098907442d4fd8b36971c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 5 Jul 2019 22:40:20 +0200 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] 60 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 20:40:33 -0000 Last weekend, a member of my family turned 60. Good reminder to update the list of CBOR implementations: https://cbor.io/impls.html There are now also a few more spec links at: https://cbor.io/spec.html Tools page is next=E2=80=A6 Suggestions, as always, are welcome. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 9 08:09:57 2019 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 41E0F12023E for ; Tue, 9 Jul 2019 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ztrZUx8EZQfe for ; Tue, 9 Jul 2019 08:09:47 -0700 (PDT) Received: from mail.conjury.org (prime.conjury.org [IPv6:2607:f2f8:a938::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50A73120452 for ; Tue, 9 Jul 2019 08:09:46 -0700 (PDT) Received: from [IPv6:2607:f598:b0b2:cf00:c64:2262:782f:a640] (unknown [IPv6:2607:f598:b0b2:cf00:c64:2262:782f:a640]) by mail.conjury.org (Postfix) with ESMTPSA id 33D74E0404 for ; Tue, 9 Jul 2019 08:06:11 -0700 (PDT) From: j h woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_C2D3171D-23C5-4B79-B7BA-13FFD4B8B8C6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 9 Jul 2019 08:09:45 -0700 References: To: cbor@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Cbor] 60 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:09:53 -0000 --Apple-Mail=_C2D3171D-23C5-4B79-B7BA-13FFD4B8B8C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 5, 2019, at 13:40, Carsten Bormann wrote: >=20 > Last weekend, a member of my family turned 60. > Good reminder to update the list of CBOR implementations: Please pass along my happy birthday wishes. And thanks for listing my = Orsetto implementation for OCaml. I=E2=80=99m kinda proud of it, and I = hope it will emerge as the obvious choice for using CBOR in that = programming language. --james woodyatt --Apple-Mail=_C2D3171D-23C5-4B79-B7BA-13FFD4B8B8C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 5, 2019, at 13:40, Carsten Bormann <cabo@tzi.org> = wrote:

Last weekend, a member of my family turned 60.
Good reminder to update the list of CBOR = implementations:

Please pass along my happy birthday = wishes. And thanks for listing my Orsetto implementation for OCaml. = I=E2=80=99m kinda proud of it, and I hope it will emerge as the obvious = choice for using CBOR in that programming language.


--james woodyatt = <jhw@conjury.org>




= --Apple-Mail=_C2D3171D-23C5-4B79-B7BA-13FFD4B8B8C6-- From nobody Thu Jul 11 16:24:36 2019 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 BC91C1200B8 for ; Thu, 11 Jul 2019 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arlut.utexas.edu 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 aWl3xlRbs-IW for ; Thu, 11 Jul 2019 16:24:32 -0700 (PDT) Received: from esa1.arlut.utexas.edu (esa1.arlut.utexas.edu [146.6.211.15]) (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 BEDA5120041 for ; Thu, 11 Jul 2019 16:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arlut.utexas.edu; i=@arlut.utexas.edu; q=dns/txt; s=default; t=1562887471; x=1594423471; h=from:mime-version:subject:message-id:date:to; bh=v2ETH2FBp+hegyv6mHYQFzjwMoCdTKrP1xDbnjTNZhs=; b=mJ89qHoiiO+uGEq0+w8OiluXVQ0kbSIebXgOb0CVRGZataN+8n4pnDpF VRZKYNDsKefrKgw6Bn8N1byRnZ9jyIn0jOZy+dwdE9ogUUS6kZogpMukc CR/4uXzymh9VHbgo+f3IayVriwd9ReRrENRFdx2qkpUTArr2tlqawQpGy OoOKu/vl85gmWhfE7Z4D2jS63AH1rdC49C0PXqEOrs/bKSYZUiDzItQhk ihqWkeuHBzRJzCHF4rPvkQ5MaJhANBmcgDHvn3s9KFZzuFtQUZ6sTVNXT A7BZT7yatolYnQFfb1026e8bCsScQxTXMGUnsK/uGJjDuklZrW3nlkRyz g==; IronPort-SDR: /As3wrDYK5I/FMwRIP1v2wl2QhhgKiV+u9sWieg3eNsuhMV51gmUKr7dii+6xdwULL6JNsgABz yE185y0lcEp8gP9K3Lbmb6oKOw2Daj27FGxhJfIh6PsljDO8KUb1ukTEgvNPBiRwyJ1MaelMeX i5akfBj2tBccU97byyTaENsGcMyyJAAW/wwrmY9Cuv9KX9tKvA2jDdiprQAGuR4NHvsGwZ3r7M iWGlc15noMG0PkIqyqF85eNxx9f5QaCe7aPlg3cTn9IcgLYhyBJZX6I97OPhlQPFJKm4i/97Ys EA0= X-IronPort-AV: E=McAfee;i="6000,8403,9315"; a="7286823" X-IronPort-AV: E=Sophos; i="5.63,480,1557205200"; d="p7s'?scan'208"; a="7286823" Received: from intpfx1.arlut.utexas.edu ([10.14.8.87]) by esa1.arlut.utexas.edu with ESMTP; 11 Jul 2019 18:24:30 -0500 Received: from intesa1.arlut.utexas.edu (intesa1.arlut.utexas.edu [10.14.8.10]) by intpfx1.arlut.utexas.edu (Postfix) with ESMTP id 4C962BC0DE for ; Thu, 11 Jul 2019 18:24:30 -0500 (CDT) X-IronPort-AV: E=McAfee;i="6000,8403,9315"; a="2580538" X-IronPort-AV: E=Sophos; i="5.63,480,1557205200"; d="p7s'?scan'208"; a="2580538" Received: from syrinx.arlut.utexas.edu ([10.14.104.95]) by mail.arlut.utexas.edu with ESMTP; 11 Jul 2019 18:24:30 -0500 From: Gregory Allen Content-Type: multipart/signed; boundary="Apple-Mail=_0DBEB03F-C0BF-4F02-95ED-51D828417255"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> Date: Thu, 11 Jul 2019 18:24:29 -0500 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] typed arrays for complex numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:24:34 -0000 --Apple-Mail=_0DBEB03F-C0BF-4F02-95ED-51D828417255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m glad to see the proposal for typed homogeneous arrays in = CBOR, and have a question. How would one markup complex data? Similarly, how would one markup other = compound types such as quaternion, RGB, or RGBA data? Note that there is some disagreement out there as to approaches for = this. NumPy defines new types for complex numbers (e.g. complex64). HDF5 = describes complex numbers as structs containing re and im. I believe that complex numbers are an important and widely used class of = data for CBOR to be able to contain. I could imaging a =E2=80=9Ccomplex=E2=80=9D tag, that=E2=80=99s a = modifier for a dataType, so that one could do: multi-dim([dim, complex(ta-float32le(bstr)) ]) However, that doesn=E2=80=99t scale well to having several different = compound types such as those mentioned above. What are your thoughts on containing this kind of data? Thanks, -Greg Gregory E. Allen, PhD, Sr Engineering Scientist Applied Research Laboratories: The University of Texas at Austin 512-835-3487 --Apple-Mail=_0DBEB03F-C0BF-4F02-95ED-51D828417255 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMEDCCBdYw ggS+oAMCAQICEDJ9xYTYotb/AlxArHU/SegwDQYJKoZIhvcNAQELBQAwgbAxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQKEyFUaGUgVW5pdmVyc2l0eSBv ZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9uIFNlY3VyaXR5IE9mZmljZTEx MC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluIFJTQSBDQTAeFw0xODAy MDEwMDAwMDBaFw0yMzAyMDEyMzU5NTlaMIHaMQ4wDAYDVQQREwU3ODcxMzEiMCAGA1UECxMZQVBJ IC0gUy9NSU1FIFByb3Zpc2lvbmluZzEqMCgGA1UEChMhVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMg YXQgQXVzdGluMQ0wCwYDVQQJEwROb25lMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMQsw CQYDVQQGEwJVUzEWMBQGA1UEAxMNR3JlZ29yeSBBbGxlbjEmMCQGCSqGSIb3DQEJARYXZ2FsbGVu QGFybHV0LnV0ZXhhcy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc3ap97VIi z5nKeswSHTtqym8Rd8iYLwDNXBJG/GBDD045AHzZwcJJuNNI7EFJLV6aYXbgGg4V2c/46Zq/dIBd +pMfVCy9txkPAhitAejLhnXNZfr4pyiQS8YkJZUN7UuKeH9EFS3YMgYyMumckftQAO6wlt1NOLhf vZ5EPQEPxgThdayEV8pZWqzL/w3N1CQAg/rtn2Ad2W9sPJppiMJSF0IaAown+4kQOMHGhAEncD3c mbiBWZ8C0aVR15s/e33X+opgglmW1XsC4mIZh2mMWkY5nylTJNdJknlw0+UuKekkFXPagRiy+Xn2 y8Bi2eRrrV40FB4sDRvaib1fgmSFAgMBAAGjggG+MIIBujAfBgNVHSMEGDAWgBQqq14umcirdcC8 uayIWXlkMCh1hzAdBgNVHQ4EFgQUSrod7D+wSAyyEt/jI62OHGV+A1YwDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEIGA1UdIAQ7MDkw NwYMKwYBBAGyMQECAiQCMCcwJQYIKwYBBQUHAgEWGWh0dHBzOi8vY3BzLnVzZXJ0cnVzdC5jb20w TwYDVR0fBEgwRjBEoEKgQIY+aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1RoZVVuaXZlcnNpdHlv ZlRleGFzYXRBdXN0aW5SU0FDQS5jcmwwgYEGCCsGAQUFBwEBBHUwczBKBggrBgEFBQcwAoY+aHR0 cDovL2NydC51c2VydHJ1c3QuY29tL1RoZVVuaXZlcnNpdHlvZlRleGFzYXRBdXN0aW5SU0FDQS5j cnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wIgYDVR0RBBswGYEXZ2Fs bGVuQGFybHV0LnV0ZXhhcy5lZHUwDQYJKoZIhvcNAQELBQADggEBAAr7KMq5OTW9lzr/JAXNO030 IrnI8ovIoIjID6d1LTP85r/RUkWRPIoAXmfkD5+sdG6bqX3cOAzDxzoj5AaHO3jdS5/YA/hV8Ji/ xmAIweq2L8anAXZ/q8fqxS7PFobY0KXw91NqXpWDQ2MGyamceL1/gw11kPZtF5zEnT8PTK5Xbszy iWN0/3JU9lM4RdETlbeYWmKl03yrgG8pMBFcFGcE2leuDRaAfbiWnjZ1zWCSVyYvHyZP9QRW8BFJ 0SM9h9uO6oT89RLPcgyTa+E+X/gFJdrS/tcaQt8cqKDmLZPqmaJVZQlZ3zFEjlZUVITwywjKUYdB O09vj9RKWw3SGBQwggYyMIIEGqADAgECAhBzZHotj0biQbfb6Ecqqz5PMA0GCSqGSIb3DQEBDAUA MIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJT QSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xNTAyMjcwMDAwMDBaFw0yNTAyMjYyMzU5NTla MIGwMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3RpbjEqMCgGA1UEChMh VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluMSQwIgYDVQQLExtJbmZvcm1hdGlvbiBT ZWN1cml0eSBPZmZpY2UxMTAvBgNVBAMTKFRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIGF0IEF1c3Rp biBSU0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZhYpkAz7tSIrPJUuwsL/ E/DijRXy3vOA1y0aPPdsfPihLOP83DLfrCcLmsyg8cChR0XqIeFzCSLIUlIeUt/ceD2uJtyyO/R3 3S9eUo7VeOcuQlv7Kut2fvNlpj+vth9v96x4fqxoFJFMx+hX3eqSnFtA+BR9ltn3A9jSz3Bwl88Q lQ9z6rYoLsdTWHodN0jb5j7wnC0Ujo1jamh7vweYZPQZW9tHc4+igQ/mEbPUVExZXtBvEI8jxvn+ dE1bNapnO9pZjrgK1GqdG2LBYavUdmlTi6Ft+26UC9I4GumvQaq9VjLJlBz+/iqLJPtRiTB2AMGA K9jAJS6BD3vn5Rg/AgMBAAGjggFsMIIBaDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNm yzAdBgNVHQ4EFgQUKqteLpnIq3XAvLmsiFl5ZDAodYcwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB /wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBkGA1UdIAQSMBAwDgYM KwYBBAGyMQECAiQCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9V U0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgwPwYI KwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENB LmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAMpNoN+kNosyjltiOWSeEzifGzEjW6VMSLWhBStGGvVeW1obi9rn0Ts5jPzObF5ybl/8U hh5VpSQzWtCzIsGtcljJhMu2sGVHpgyO756vf/0vKAOTJ0UVfzXTcMcaXWzeDo9aQUUBfDkySQ8G 2qeQ3ZZd3j2ZU830cRemxrZGFtziaNCOjxA5jkLD0LngFs7J7IMbkoBteDkt3MH5Wg61U7XtJ+MI cyUcmK4uAvpE+SgQDOhJSsMvb3VCUHz6x2SWP9eT460ofWVGoQXDg63hv5juO2gkwfI4myBX1cOb gyHma72a/EaQF52OucdafprSdy84q8Zcd+MeEYjcTDddqM8U2+VAmQojgeXieQc0nCF7naAO40/O nPIjmZU76+NgyZO3VNCiXrq7Y0Qa9yGFK9YZDHLbr8LOGakRhr2hS6PonDIlUVxleumxLmJHiu21 kGQj0y8TT/O96DroGhfoBY0WZNSx1dbEzkRrk3xohw6HlUUwtC3GChpApCR7Q3/mPj34hjTkfYgP Y2uLKvRjoD//FZvmxR2xKFn2LbgSziadGhl+MaEsjR+lqHcSfEsJeCJl5WtiF8OjIoTp0kFyLhiA 2KKsS0GId+HPclL94uqln35aIwT87ISY7D6J4BBLmwoWz463YjcHLlJOJEFa0tebRwWyC4GrZEIV GBIzRtAxggQCMIID/gIBATCBxTCBsDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlRYMQ8wDQYDVQQH EwZBdXN0aW4xKjAoBgNVBAoTIVRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIGF0IEF1c3RpbjEkMCIG A1UECxMbSW5mb3JtYXRpb24gU2VjdXJpdHkgT2ZmaWNlMTEwLwYDVQQDEyhUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBhdCBBdXN0aW4gUlNBIENBAhAyfcWE2KLW/wJcQKx1P0noMAkGBSsOAwIaBQCg ggIRMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcxMTIzMjQz MFowIwYJKoZIhvcNAQkEMRYEFCr8aKtwoG3/9eVaKGjWrpeIJ0NXMIHWBgkrBgEEAYI3EAQxgcgw gcUwgbAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQK EyFUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9u IFNlY3VyaXR5IE9mZmljZTExMC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVz dGluIFJTQSBDQQIQMn3FhNii1v8CXECsdT9J6DCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQKEyFUaGUgVW5p dmVyc2l0eSBvZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9uIFNlY3VyaXR5 IE9mZmljZTExMC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluIFJTQSBD QQIQMn3FhNii1v8CXECsdT9J6DANBgkqhkiG9w0BAQEFAASCAQA8ATzViVs54TSOBUMVVDDbM53x gzy4Kkupa28kiQOg3cXjWj1VPVzfs4AAG4Xp7uGZfZhwWXdLsozb2UhcYWLr339h6ZMHRd9rzPr3 YFsxC7KdzyCIbCK7EW6BlsqcmlCB4olMiK3hHrfViGJ/0DgPpgjqIZOTq9/OKfUGudldLMokZSDz J4gsXPwvE++RDJXLlJofB+4BXO4mn4lDNtCf+oGbxvNfL2dDL5RPqRZh/8pcLRoqEX5/hEt76//5 eyQNYP5A3Tb6UuKZar8WKZt1DxNVcpGm88RsSNfyDRaQ08P2Ub66NYct/wGYRPQY95Fk8MGBFe3L i1VMEaOyQBpPAAAAAAAA --Apple-Mail=_0DBEB03F-C0BF-4F02-95ED-51D828417255-- From nobody Thu Jul 11 17:23:30 2019 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 E2888120086 for ; Thu, 11 Jul 2019 17:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Hk45wa9cgUhd for ; Thu, 11 Jul 2019 17:23:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152FF12007A for ; Thu, 11 Jul 2019 17:23:26 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45lDDC6Drlzyh5; Fri, 12 Jul 2019 02:23:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> Date: Fri, 12 Jul 2019 02:23:23 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 584583801.480399-2297a0d453ac56443ddfadc7f4402199 Content-Transfer-Encoding: quoted-printable Message-Id: <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org> References: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> To: Gregory Allen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] typed arrays for complex numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:23:28 -0000 On Jul 12, 2019, at 01:24, Gregory Allen = wrote: >=20 > I could imaging a =E2=80=9Ccomplex=E2=80=9D tag, that=E2=80=99s a = modifier for a dataType, so that one could do: >=20 > multi-dim([dim, complex(ta-float32le(bstr)) ]) >=20 > However, that doesn=E2=80=99t scale well to having several different = compound types such as those mentioned above. Well, it requires a new tag for each of these compound types, but if = these are indeed different types, then tags are cheap (as long as they = don=E2=80=99t have to come out of the 1+1 space :-). So if this helps, we could indeed define tags (for complex, quaternion, = octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, 3, = 4 elements out of an array (tagged or classical CBOR). (Well, RGB is a bit weird, because there are so many color spaces. = Maybe just have tags for three- and four-dimensional color spaces.) Alternatively, supplying the group size separately maybe can do all of = these at omce, but then cannot distinguish quaternions from RGBA or = CMYK. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 12 07:17:24 2019 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 301C2120119 for ; Fri, 12 Jul 2019 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 R0Hkivhf3gMy for ; Fri, 12 Jul 2019 07:17:19 -0700 (PDT) Received: from smtp.jeffnet.31bits.net (josefsipek.net [71.174.113.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1F31200F3 for ; Fri, 12 Jul 2019 07:17:19 -0700 (PDT) Received: from meili (unknown [172.27.0.163]) by smtp.jeffnet.31bits.net (Postfix) with ESMTPSA id C62B317D7A; Fri, 12 Jul 2019 14:17:17 +0000 (UTC) Date: Fri, 12 Jul 2019 10:17:07 -0400 From: Josef 'Jeff' Sipek To: Carsten Bormann Cc: Gregory Allen , cbor@ietf.org Message-ID: <20190712141659.GA1505@meili> References: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org> User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: Re: [Cbor] typed arrays for complex numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:17:22 -0000 On Fri, Jul 12, 2019 at 02:23:23 +0200, Carsten Bormann wrote: > On Jul 12, 2019, at 01:24, Gregory Allen wrote: > > > > I could imaging a “complex” tag, that’s a modifier for a dataType, so that one could do: > > > > multi-dim([dim, complex(ta-float32le(bstr)) ]) > > > > However, that doesn’t scale well to having several different compound types such as those mentioned above. > > Well, it requires a new tag for each of these compound types, but if these are indeed different types, then tags are cheap (as long as they don’t have to come out of the 1+1 space :-). > > So if this helps, we could indeed define tags (for complex, quaternion, > octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, 3, 4 > elements out of an array (tagged or classical CBOR). > (Well, RGB is a bit weird, because there are so many color spaces. Maybe > just have tags for three- and four-dimensional color spaces.) I'm far from a color expert, but as far as I know even for RGB color spaces the values aren't always stored in one order. At the very least there are RGBA and ARGB. Currently my best idea amounts to: color(["RGB", [R1, G1, B1, R2, ...]) color(["RGBA", [R1, G1, B1, A1, R2, ...]) color(["CMYK", [C1, M1, Y1, K1, C2, ...]) I don't know if using a text string to identify the color component names and order is an anti-pattern in CBOR but it is similar to the currency related tags discussed some months ago. This could even be extended to support planar formats (where the values for each component are clumped together to allow better compression) and chroma subsampling (where there aren't the same number of samples for each component). With either: color(["RGB", [R1, R2, ...], [G1, G2, ...], [B1, B2, ...]) color(["YUV420", [Y1, Y2, ...], [U1, U2, ...], [V1, V2, ...]) or: color(["RGB", [R1, R2, ..., G1, G2, ..., B1, B2, ...]) color(["YUV420", [Y1, Y2, ..., U1, U2, ..., V1, V2, ...]) I suppose the second would need to identify the number or ratio of values for each component to support chroma subsampling, so the first would probably be better. Going down the rabbit hole of storing color data, there are also CCDs which red/blue pixels. Anyway, beware I know just enough about this to be dangerous :) I'd probably stay away from defining tags for colors until an actual expert comes along. Jeff. > Alternatively, supplying the group size separately maybe can do all of these at omce, but then cannot distinguish quaternions from RGBA or CMYK. > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor -- My public PGP key can be found at https://www.josefsipek.net/pgp/ From nobody Mon Jul 15 07:55:27 2019 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 51C3A1201A3 for ; Mon, 15 Jul 2019 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arlut.utexas.edu 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 nxCkXTd_OapI for ; Mon, 15 Jul 2019 07:55:23 -0700 (PDT) Received: from esa1.arlut.utexas.edu (esa1.arlut.utexas.edu [146.6.211.15]) (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 F2873120172 for ; Mon, 15 Jul 2019 07:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arlut.utexas.edu; i=@arlut.utexas.edu; q=dns/txt; s=default; t=1563202523; x=1594738523; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=yvzwuowTl5GlZe3FTheg5crZBn3TqJMSpeF130x3u6E=; b=D8W/DXR+tB+4L+i4HPy4Z4d1hqSRDcE6HjfZZJZApnseasgwMDV6Yj6/ YnDq/cUKWOaM4IKCa/G6oLd53q4jRwSKo6QyiJvutwUej4Dx+CIZZfMDa okUdo48lDm04YkdewvUNCB4DuDEF5NDCcdze+G0viLPKPUVVUbI97Eg4L MOkAaQ8vhKaWr5LBScALNDVQJVFgp2OtHnfLsjP8HQQ/X1qI+DMkQcHnB cnffRggs94iybqIz0KhE70IeDDPQtJ+x+oCluYo4aATVIXLThCzrgMhWc moh2AAxkse79adIWkyOtriKg89lTKcQUhWO6niwKPPuQAklydrbPMCufR Q==; IronPort-SDR: v9EAmfgLppKbMh2uFC8oZqMy+OeOMTvlQZbod8AYkwj1QvRyAJbJ3661t0Jotf9Ebof8WYRn4O rwNSRK/1Hh22+ao83yDIxul7ZA3eSqE2WLPfz90I0uOVNMSfG69YySc/mW9zcv+KTrnIzitXjC KPWe3uiwJDuxgeew5/exQBfl92rygFsXE0U5feD8OzAP5ikNEkND3Lz84bc38w8/oNwCf41TfN 6Wl+RRBIvO6bPq5+QhA+sf++Z/eIFJCIO/vdEb/APNIScEnU0VQ8zUAEGRTwxerDPbaYBQXRL7 LoE= X-IronPort-AV: E=McAfee;i="6000,8403,9319"; a="7296499" X-IronPort-AV: E=Sophos; i="5.63,493,1557205200"; d="p7s'?scan'208"; a="7296499" Received: from intpfx1.arlut.utexas.edu ([10.14.8.87]) by esa1.arlut.utexas.edu with ESMTP; 15 Jul 2019 09:55:22 -0500 Received: from intesa1.arlut.utexas.edu (intesa1.arlut.utexas.edu [10.14.8.10]) by intpfx1.arlut.utexas.edu (Postfix) with ESMTP id 11BA678ED5 for ; Mon, 15 Jul 2019 09:55:22 -0500 (CDT) X-IronPort-AV: E=McAfee;i="6000,8403,9319"; a="2587370" X-IronPort-AV: E=Sophos; i="5.63,493,1557205200"; d="p7s'?scan'208"; a="2587370" Received: from syrinx.arlut.utexas.edu ([10.14.104.95]) by mail.arlut.utexas.edu with ESMTP; 15 Jul 2019 09:55:22 -0500 From: Gregory Allen Message-Id: <328EA863-7747-4723-983E-5B1EF248A2A1@arlut.utexas.edu> Content-Type: multipart/signed; boundary="Apple-Mail=_D268AD3F-EA69-4CE3-ABE1-B69CA691B932"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 15 Jul 2019 09:55:21 -0500 In-Reply-To: <20190712141659.GA1505@meili> Cc: Carsten Bormann , cbor@ietf.org To: Josef 'Jeff' Sipek References: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org> <20190712141659.GA1505@meili> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] typed arrays for complex numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 14:55:26 -0000 --Apple-Mail=_D268AD3F-EA69-4CE3-ABE1-B69CA691B932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perhaps =E2=80=9Ccomplex=E2=80=9D deserves a special tag because it=E2=80=99= s so common, but it=E2=80=99s easy to see how a tag for each type of = compound data doesn=E2=80=99t scale well. Following Jeff=E2=80=99s line of reasoning could lead to something like = structured data types in NumPy = [https://docs.scipy.org/doc/numpy/user/basics.rec.html]. HDF5 supports = similar constructs. The idea is that one describes the type, and then an array can contain = elements of the user-defined type. This can be used to describe blobs = containing homogeneous arrays of arbitrary structures. For example (from NumPy): cymk_type =3D [(=E2=80=98c=E2=80=99, np.uint8), (=E2=80=98y=E2=80=99, = np.uint8), (=E2=80=98m=E2=80=99, np.uint8), (=E2=80=98k=E2=80=99, = np.uint8)] # list of (name, type) pairs x =3D np.zeros([640, 480], dtype=3Dcymk_type) I didn=E2=80=99t propose this before because it=E2=80=99s obviously much = greater in scope than adding a =E2=80=9Ccomplex=E2=80=9D tag. It=E2=80=99s= not even clear to me what approach I would want to take to add this to = CBOR. Thanks, -Greg > On Jul 12, 2019, at 9:17 AM, Josef 'Jeff' Sipek = wrote: >=20 > On Fri, Jul 12, 2019 at 02:23:23 +0200, Carsten Bormann wrote: >> On Jul 12, 2019, at 01:24, Gregory Allen = wrote: >>>=20 >>> I could imaging a =E2=80=9Ccomplex=E2=80=9D tag, that=E2=80=99s a = modifier for a dataType, so that one could do: >>>=20 >>> multi-dim([dim, complex(ta-float32le(bstr)) ]) >>>=20 >>> However, that doesn=E2=80=99t scale well to having several different = compound types such as those mentioned above. >>=20 >> Well, it requires a new tag for each of these compound types, but if = these are indeed different types, then tags are cheap (as long as they = don=E2=80=99t have to come out of the 1+1 space :-). >>=20 >> So if this helps, we could indeed define tags (for complex, = quaternion, >> octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, = 3, 4 >> elements out of an array (tagged or classical CBOR). >> (Well, RGB is a bit weird, because there are so many color spaces. = Maybe >> just have tags for three- and four-dimensional color spaces.) >=20 > I'm far from a color expert, but as far as I know even for RGB color = spaces > the values aren't always stored in one order. At the very least there = are > RGBA and ARGB. >=20 > Currently my best idea amounts to: >=20 > color(["RGB", [R1, G1, B1, R2, ...]) > color(["RGBA", [R1, G1, B1, A1, R2, ...]) > color(["CMYK", [C1, M1, Y1, K1, C2, ...]) >=20 > I don't know if using a text string to identify the color component = names > and order is an anti-pattern in CBOR but it is similar to the currency > related tags discussed some months ago. >=20 > This could even be extended to support planar formats (where the = values for > each component are clumped together to allow better compression) and = chroma > subsampling (where there aren't the same number of samples for each > component). With either: >=20 > color(["RGB", [R1, R2, ...], [G1, G2, ...], [B1, B2, ...]) > color(["YUV420", [Y1, Y2, ...], [U1, U2, ...], [V1, V2, ...]) >=20 > or: >=20 > color(["RGB", [R1, R2, ..., G1, G2, ..., B1, B2, ...]) > color(["YUV420", [Y1, Y2, ..., U1, U2, ..., V1, V2, ...]) >=20 > I suppose the second would need to identify the number or ratio of = values > for each component to support chroma subsampling, so the first would > probably be better. >=20 > Going down the rabbit hole of storing color data, there are also CCDs = which > red/blue pixels. >=20 >=20 > Anyway, beware I know just enough about this to be dangerous :) I'd > probably stay away from defining tags for colors until an actual = expert > comes along. >=20 > Jeff. >=20 >> Alternatively, supplying the group size separately maybe can do all = of these at omce, but then cannot distinguish quaternions from RGBA or = CMYK. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > --=20 > My public PGP key can be found at https://www.josefsipek.net/pgp/ --Apple-Mail=_D268AD3F-EA69-4CE3-ABE1-B69CA691B932 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMEDCCBdYw ggS+oAMCAQICEDJ9xYTYotb/AlxArHU/SegwDQYJKoZIhvcNAQELBQAwgbAxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQKEyFUaGUgVW5pdmVyc2l0eSBv ZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9uIFNlY3VyaXR5IE9mZmljZTEx MC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluIFJTQSBDQTAeFw0xODAy MDEwMDAwMDBaFw0yMzAyMDEyMzU5NTlaMIHaMQ4wDAYDVQQREwU3ODcxMzEiMCAGA1UECxMZQVBJ IC0gUy9NSU1FIFByb3Zpc2lvbmluZzEqMCgGA1UEChMhVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMg YXQgQXVzdGluMQ0wCwYDVQQJEwROb25lMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMQsw CQYDVQQGEwJVUzEWMBQGA1UEAxMNR3JlZ29yeSBBbGxlbjEmMCQGCSqGSIb3DQEJARYXZ2FsbGVu QGFybHV0LnV0ZXhhcy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc3ap97VIi z5nKeswSHTtqym8Rd8iYLwDNXBJG/GBDD045AHzZwcJJuNNI7EFJLV6aYXbgGg4V2c/46Zq/dIBd +pMfVCy9txkPAhitAejLhnXNZfr4pyiQS8YkJZUN7UuKeH9EFS3YMgYyMumckftQAO6wlt1NOLhf vZ5EPQEPxgThdayEV8pZWqzL/w3N1CQAg/rtn2Ad2W9sPJppiMJSF0IaAown+4kQOMHGhAEncD3c mbiBWZ8C0aVR15s/e33X+opgglmW1XsC4mIZh2mMWkY5nylTJNdJknlw0+UuKekkFXPagRiy+Xn2 y8Bi2eRrrV40FB4sDRvaib1fgmSFAgMBAAGjggG+MIIBujAfBgNVHSMEGDAWgBQqq14umcirdcC8 uayIWXlkMCh1hzAdBgNVHQ4EFgQUSrod7D+wSAyyEt/jI62OHGV+A1YwDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEIGA1UdIAQ7MDkw NwYMKwYBBAGyMQECAiQCMCcwJQYIKwYBBQUHAgEWGWh0dHBzOi8vY3BzLnVzZXJ0cnVzdC5jb20w TwYDVR0fBEgwRjBEoEKgQIY+aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1RoZVVuaXZlcnNpdHlv ZlRleGFzYXRBdXN0aW5SU0FDQS5jcmwwgYEGCCsGAQUFBwEBBHUwczBKBggrBgEFBQcwAoY+aHR0 cDovL2NydC51c2VydHJ1c3QuY29tL1RoZVVuaXZlcnNpdHlvZlRleGFzYXRBdXN0aW5SU0FDQS5j cnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wIgYDVR0RBBswGYEXZ2Fs bGVuQGFybHV0LnV0ZXhhcy5lZHUwDQYJKoZIhvcNAQELBQADggEBAAr7KMq5OTW9lzr/JAXNO030 IrnI8ovIoIjID6d1LTP85r/RUkWRPIoAXmfkD5+sdG6bqX3cOAzDxzoj5AaHO3jdS5/YA/hV8Ji/ xmAIweq2L8anAXZ/q8fqxS7PFobY0KXw91NqXpWDQ2MGyamceL1/gw11kPZtF5zEnT8PTK5Xbszy iWN0/3JU9lM4RdETlbeYWmKl03yrgG8pMBFcFGcE2leuDRaAfbiWnjZ1zWCSVyYvHyZP9QRW8BFJ 0SM9h9uO6oT89RLPcgyTa+E+X/gFJdrS/tcaQt8cqKDmLZPqmaJVZQlZ3zFEjlZUVITwywjKUYdB O09vj9RKWw3SGBQwggYyMIIEGqADAgECAhBzZHotj0biQbfb6Ecqqz5PMA0GCSqGSIb3DQEBDAUA MIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJT QSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xNTAyMjcwMDAwMDBaFw0yNTAyMjYyMzU5NTla MIGwMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3RpbjEqMCgGA1UEChMh VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluMSQwIgYDVQQLExtJbmZvcm1hdGlvbiBT ZWN1cml0eSBPZmZpY2UxMTAvBgNVBAMTKFRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIGF0IEF1c3Rp biBSU0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZhYpkAz7tSIrPJUuwsL/ E/DijRXy3vOA1y0aPPdsfPihLOP83DLfrCcLmsyg8cChR0XqIeFzCSLIUlIeUt/ceD2uJtyyO/R3 3S9eUo7VeOcuQlv7Kut2fvNlpj+vth9v96x4fqxoFJFMx+hX3eqSnFtA+BR9ltn3A9jSz3Bwl88Q lQ9z6rYoLsdTWHodN0jb5j7wnC0Ujo1jamh7vweYZPQZW9tHc4+igQ/mEbPUVExZXtBvEI8jxvn+ dE1bNapnO9pZjrgK1GqdG2LBYavUdmlTi6Ft+26UC9I4GumvQaq9VjLJlBz+/iqLJPtRiTB2AMGA K9jAJS6BD3vn5Rg/AgMBAAGjggFsMIIBaDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNm yzAdBgNVHQ4EFgQUKqteLpnIq3XAvLmsiFl5ZDAodYcwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB /wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBkGA1UdIAQSMBAwDgYM KwYBBAGyMQECAiQCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9V U0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgwPwYI KwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENB LmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAMpNoN+kNosyjltiOWSeEzifGzEjW6VMSLWhBStGGvVeW1obi9rn0Ts5jPzObF5ybl/8U hh5VpSQzWtCzIsGtcljJhMu2sGVHpgyO756vf/0vKAOTJ0UVfzXTcMcaXWzeDo9aQUUBfDkySQ8G 2qeQ3ZZd3j2ZU830cRemxrZGFtziaNCOjxA5jkLD0LngFs7J7IMbkoBteDkt3MH5Wg61U7XtJ+MI cyUcmK4uAvpE+SgQDOhJSsMvb3VCUHz6x2SWP9eT460ofWVGoQXDg63hv5juO2gkwfI4myBX1cOb gyHma72a/EaQF52OucdafprSdy84q8Zcd+MeEYjcTDddqM8U2+VAmQojgeXieQc0nCF7naAO40/O nPIjmZU76+NgyZO3VNCiXrq7Y0Qa9yGFK9YZDHLbr8LOGakRhr2hS6PonDIlUVxleumxLmJHiu21 kGQj0y8TT/O96DroGhfoBY0WZNSx1dbEzkRrk3xohw6HlUUwtC3GChpApCR7Q3/mPj34hjTkfYgP Y2uLKvRjoD//FZvmxR2xKFn2LbgSziadGhl+MaEsjR+lqHcSfEsJeCJl5WtiF8OjIoTp0kFyLhiA 2KKsS0GId+HPclL94uqln35aIwT87ISY7D6J4BBLmwoWz463YjcHLlJOJEFa0tebRwWyC4GrZEIV GBIzRtAxggQCMIID/gIBATCBxTCBsDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlRYMQ8wDQYDVQQH EwZBdXN0aW4xKjAoBgNVBAoTIVRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIGF0IEF1c3RpbjEkMCIG A1UECxMbSW5mb3JtYXRpb24gU2VjdXJpdHkgT2ZmaWNlMTEwLwYDVQQDEyhUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBhdCBBdXN0aW4gUlNBIENBAhAyfcWE2KLW/wJcQKx1P0noMAkGBSsOAwIaBQCg ggIRMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcxNTE0NTUy MVowIwYJKoZIhvcNAQkEMRYEFMM2VIytsMFPemmDjrnZ2pD/hiOpMIHWBgkrBgEEAYI3EAQxgcgw gcUwgbAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQK EyFUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9u IFNlY3VyaXR5IE9mZmljZTExMC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVz dGluIFJTQSBDQQIQMn3FhNii1v8CXECsdT9J6DCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJUWDEPMA0GA1UEBxMGQXVzdGluMSowKAYDVQQKEyFUaGUgVW5p dmVyc2l0eSBvZiBUZXhhcyBhdCBBdXN0aW4xJDAiBgNVBAsTG0luZm9ybWF0aW9uIFNlY3VyaXR5 IE9mZmljZTExMC8GA1UEAxMoVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluIFJTQSBD QQIQMn3FhNii1v8CXECsdT9J6DANBgkqhkiG9w0BAQEFAASCAQCctsgEdocuXcs30rGHewMD4yLO SyFsQrp1ml8La33XUtv3MtFLDtYcSH/KHef3gLrU/U+/5CtRPerDXIoSe5xQoF7GEFPkp+9XS3Rd meMjrUutoHb1iKe5JT4Y97ucWcO/xkoTV8YVoVhdR99c+Qzl7lwPOj5LC5EOdduOtVjF1Ybh95Pz Q8z44aPBeImSLoGVW/uP9gbLNdVdtyJcKmON+quWIah30AegLNR+CJtkOfz+7Uhc4iu6250+f0mc qorVTnN3ZAmVDIHhP7HmvGYNUf0Mv6UBRx+5onnT/EiIWd2ILh6n1VkIhlmSmqiICY6DCzhWg1l0 Pn4WbxEVcjQGAAAAAAAA --Apple-Mail=_D268AD3F-EA69-4CE3-ABE1-B69CA691B932-- From nobody Thu Jul 18 04:36:29 2019 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 DA2781201E2 for ; Thu, 18 Jul 2019 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 5a94U_IrLmLF for ; Thu, 18 Jul 2019 04:36:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB591201CA for ; Thu, 18 Jul 2019 04:36:26 -0700 (PDT) Received: from [10.21.164.206] (unknown [89.248.140.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45qBt04CQCzyf9; Thu, 18 Jul 2019 13:36:24 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 585142604.2759579-78157b18eb785b45c725e7a9ef3a620f Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 18 Jul 2019 13:36:47 +0200 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Decoding embedded CBOR with cbor-diag and on the playground X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 11:36:28 -0000 Peter Vanderstok was kind enough to push me into implementing a feature = for the diagnostic tools I had wanted to do for a while: Looking at = each byte string and trying if that happens to decode as a (non-empty) = CBOR sequence; if yes, show that as embedded CBOR instead of showing the = byte string. In some formats, this creates tons of false positives, so that behavior = is an option. * Programmatic: =E2=80=9Cgem update cbor-diag=E2=80=9D, and then try: set the option :try_decode_embedded to true, as in puts "000=E2=80=9D.b.cbor_diagnostic(try_decode_embedded: true) << -17, -17, -17 >> puts "Bad".b.cbor_diagnostic(try_decode_embedded: true) << << =E2=80=9Cd=E2=80=9D >> >> puts =E2=80=9CbadBad".b.cbor_diagnostic(try_decode_embedded: true) << =E2=80=9Cad", << "d" >> >> puts "Eatbad".b.cbor_diagnostic(try_decode_embedded: true) << << =E2=80=9Ct", "ad" >> >> puts "EatBad".b.cbor_diagnostic(try_decode_embedded: true) << << "t", << "d" >> >> >> * Playground: Try: http://cbor.me/?bytes=3D43(010203) Then set the =E2=80=9Cemb cbor=E2=80=9D checkbox, and try decoding = again. (Or go straight to http://cbor.me/?bytes=3D43(010203)&embcbor=3Dyes .) * To do: make that option available for the cbor diagnostic command line = tools, too. * Later to do: set this flag locally if a tag 24 is seen. Gr=C3=BC=C3=9Fe aus Amsterdam, Carsten From nobody Thu Jul 18 06:51:35 2019 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 1DF8112027C for ; Thu, 18 Jul 2019 06:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 V8c09AgFjllE for ; Thu, 18 Jul 2019 06:51:31 -0700 (PDT) Received: from smtp.jeffnet.31bits.net (josefsipek.net [71.174.113.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6279212028C for ; Thu, 18 Jul 2019 06:51:31 -0700 (PDT) Received: from meili (unknown [172.27.0.163]) by smtp.jeffnet.31bits.net (Postfix) with ESMTPSA id 728221AE49; Thu, 18 Jul 2019 13:51:30 +0000 (UTC) Date: Thu, 18 Jul 2019 09:51:18 -0400 From: Josef 'Jeff' Sipek To: Gregory Allen Cc: Carsten Bormann , cbor@ietf.org Message-ID: <20190718135118.GA1561@meili> References: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org> <20190712141659.GA1505@meili> <328EA863-7747-4723-983E-5B1EF248A2A1@arlut.utexas.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <328EA863-7747-4723-983E-5B1EF248A2A1@arlut.utexas.edu> User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: Re: [Cbor] typed arrays for complex numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 13:51:34 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2019 at 09:55:21 -0500, Gregory Allen wrote: > Perhaps =E2=80=9Ccomplex=E2=80=9D deserves a special tag because it=E2=80= =99s so common, My instinct is telling me that you are correct. If someone ever comes up with a more generic way to store vectors in arbitrary n-dimensional spaces, they can always say that complex numbers should use this other tag. > but it=E2=80=99s easy to see how a tag for each type of compound data doe= sn=E2=80=99t > scale well. >=20 > Following Jeff=E2=80=99s line of reasoning could lead to something like s= tructured > data types in NumPy > [https://docs.scipy.org/doc/numpy/user/basics.rec.html]. HDF5 supports > similar constructs. >=20 > The idea is that one describes the type, and then an array can contain > elements of the user-defined type. This can be used to describe blobs > containing homogeneous arrays of arbitrary structures. >=20 > For example (from NumPy): >=20 > cymk_type =3D [(=E2=80=98c=E2=80=99, np.uint8), (=E2=80=98y=E2=80=99,= np.uint8), (=E2=80=98m=E2=80=99, np.uint8), (=E2=80=98k=E2=80=99, np.uint8= )] # list of (name, type) pairs > x =3D np.zeros([640, 480], dtype=3Dcymk_type) >=20 > I didn=E2=80=99t propose this before because it=E2=80=99s obviously much = greater in scope > than adding a =E2=80=9Ccomplex=E2=80=9D tag. It=E2=80=99s not even clear = to me what approach I > would want to take to add this to CBOR. Interesting. I'd definitely want to leave this to someone who knows more about this / actually cares about this :) (That may be you, for all I know!) Jeff. >=20 > Thanks, > -Greg >=20 > > On Jul 12, 2019, at 9:17 AM, Josef 'Jeff' Sipek = wrote: > >=20 > > On Fri, Jul 12, 2019 at 02:23:23 +0200, Carsten Bormann wrote: > >> On Jul 12, 2019, at 01:24, Gregory Allen wro= te: > >>>=20 > >>> I could imaging a =E2=80=9Ccomplex=E2=80=9D tag, that=E2=80=99s a mod= ifier for a dataType, so that one could do: > >>>=20 > >>> multi-dim([dim, complex(ta-float32le(bstr)) ]) > >>>=20 > >>> However, that doesn=E2=80=99t scale well to having several different = compound types such as those mentioned above. > >>=20 > >> Well, it requires a new tag for each of these compound types, but if t= hese are indeed different types, then tags are cheap (as long as they don= =E2=80=99t have to come out of the 1+1 space :-). > >>=20 > >> So if this helps, we could indeed define tags (for complex, quaternion, > >> octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, 3= , 4 > >> elements out of an array (tagged or classical CBOR). > >> (Well, RGB is a bit weird, because there are so many color spaces. Ma= ybe > >> just have tags for three- and four-dimensional color spaces.) > >=20 > > I'm far from a color expert, but as far as I know even for RGB color sp= aces > > the values aren't always stored in one order. At the very least there = are > > RGBA and ARGB. > >=20 > > Currently my best idea amounts to: > >=20 > > color(["RGB", [R1, G1, B1, R2, ...]) > > color(["RGBA", [R1, G1, B1, A1, R2, ...]) > > color(["CMYK", [C1, M1, Y1, K1, C2, ...]) > >=20 > > I don't know if using a text string to identify the color component nam= es > > and order is an anti-pattern in CBOR but it is similar to the currency > > related tags discussed some months ago. > >=20 > > This could even be extended to support planar formats (where the values= for > > each component are clumped together to allow better compression) and ch= roma > > subsampling (where there aren't the same number of samples for each > > component). With either: > >=20 > > color(["RGB", [R1, R2, ...], [G1, G2, ...], [B1, B2, ...]) > > color(["YUV420", [Y1, Y2, ...], [U1, U2, ...], [V1, V2, ...]) > >=20 > > or: > >=20 > > color(["RGB", [R1, R2, ..., G1, G2, ..., B1, B2, ...]) > > color(["YUV420", [Y1, Y2, ..., U1, U2, ..., V1, V2, ...]) > >=20 > > I suppose the second would need to identify the number or ratio of valu= es > > for each component to support chroma subsampling, so the first would > > probably be better. > >=20 > > Going down the rabbit hole of storing color data, there are also CCDs w= hich > > red/blue pixels. > >=20 > >=20 > > Anyway, beware I know just enough about this to be dangerous :) I'd > > probably stay away from defining tags for colors until an actual expert > > comes along. > >=20 > > Jeff. > >=20 > >> Alternatively, supplying the group size separately maybe can do all of= these at omce, but then cannot distinguish quaternions from RGBA or CMYK. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >> _______________________________________________ > >> CBOR mailing list > >> CBOR@ietf.org > >> https://www.ietf.org/mailman/listinfo/cbor > >=20 > > --=20 > > My public PGP key can be found at https://www.josefsipek.net/pgp/ >=20 --=20 You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists. - Abbie Hoffman --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZaFgAMhruIJk7gQkg+EmTxQj4jkFAl0weVMACgkQg+EmTxQj 4jmRBQ//UwA2TSQx156F/3Cq/xsvUa/fN+wPSPx26reH5G9K6bL0862/pmJVKb0U Ze8PE+j5ddRiQknVdqArUr2V1+epglBTLSyZ4xpt0RhA9dYOdd/kRCuwqz54lj9V DZxj3r4qioqi5cx6F8vKPKNVo4X8gvCqv8/9tuaeJXP/HSLFTIani53pJvgFairf i+LPIE9DXFomW9FcB/FDzHSwICGyoK7QIk/V84FwOMoBXZeeDiL3/jz8lrM822oD Jr4HXMuWncpV6hCbu5ry44aOS4EWQtLQ9dAURDGZSfOkXhwciROtSeVoVVjrQYjB 7SV/qGT1EFLlIXGp+GzVqkYb2LUe0gAe9L0A+kSOkzZQzfYrVMhF9SV0eR1iXIRY Ud+AcfQlxgVx33JkMZYDWT8FoRX4mxMsBfKxVUBH3bFKJgp3pbjO+AlGlOa/qqW3 ncwbWvhIwR3PFMsqVNrB5LiVtSOqG5Cx6WLiTLcv4bABykpS8SxVw3BAfNLSXn70 MY/MjEz7mEwhbvfykWtYjJO9T96r/RUsN2RXdfFF5RGzU1eTxC9OGxXMQhfAPbnB zz4/pV8NoSHBhB0K6ifaH5aH6nWRFZLeeanHIvobuzvl2o1s7f2foq+Td7azTzx8 iLGMIUtStM5FKpWGYSfPR/BI4epJbTY3qYYfylSUb00pDnYyCqk= =UgQ6 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From nobody Sat Jul 20 14:09:12 2019 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 6E7BC1200F8 for ; Sat, 20 Jul 2019 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 TjXFYYSTq8_T for ; Sat, 20 Jul 2019 14:09:08 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D769120048 for ; Sat, 20 Jul 2019 14:09:08 -0700 (PDT) Received: from dhcp-80d9.meeting.ietf.org (dhcp-80d9.meeting.ietf.org [31.133.128.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45rgTs6Nh2zyT6; Sat, 20 Jul 2019 23:09:05 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 585349741.460566-810de80994e814f3584baf98dc9a6fc3 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 20 Jul 2019 17:09:03 -0400 Message-Id: <9D882C89-839C-456A-8FA7-5D6F40B2AF5C@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] CDDL conversion utilities X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 21:09:10 -0000 First fruit of the hackathon today: cddlc. $ echo =E2=80=9Cfoo =3D true / 3" | cddlc - ["cddl", ["=3D", ["name", "foo"], ["tcho", ["name", "true"], ["number", = "3"]]]] README (https://github.com/cabo/cddlc) below. Gr=C3=BC=C3=9Fe, Carsten # CDDL conversion utilities This little set of tools provides a number of command line utilities for converting to and from [cddl][RFC8610]. ## Installation `gem install cddlc` ## Formats cddlc knows the following formats: * .cddl: CDDL as defined in [RFC8610][] * .cddlj: JSON form of CDDL (the YIN to the YANG) * .cddly: The same JSON form, but serialized in YAML. [RFC8610]: http://tools.ietf.org/html/rfc8610 These targets are identified by `-t cddl`, `-t json` (with `-t neat` = invoking a different prettyprinter), `-t yaml`. These can be abbreviated (but don't do that in scripts). The current version only can transform from input CDDL to one of the JSON/YAML formats of CDDL. ## Command line utilities * `cddlc foo.cddl > foo.cddlj` * `cddlc -tyaml foo.cddl > foo.cddly` * `cddlc -ty foo.cddl > foo.cddly` Output is to stdout, input from one or more files given as command line arguments (use `-` for standard input). From nobody Mon Jul 22 06:52:14 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58204120059; Mon, 22 Jul 2019 06:52:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: cbor-chairs@ietf.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156380353235.28007.18061784159371403692.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2019 06:52:12 -0700 Archived-At: Subject: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charte?= =?utf-8?q?r-ietf-cbor-01-04=3A_=28with_COMMENT=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:52:13 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-cbor-01-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my block! From nobody Mon Jul 22 13:22:18 2019 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 4ACCF12008F for ; Mon, 22 Jul 2019 13:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 fSw92FW8m3V9 for ; Mon, 22 Jul 2019 13:22:14 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D0012008C for ; Mon, 22 Jul 2019 13:22:14 -0700 (PDT) Received: from client-0062.vpn.uni-bremen.de (client-0062.vpn.uni-bremen.de [134.102.107.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45stLr27fqzysL; Mon, 22 Jul 2019 22:22:12 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 585519728.3367029-1ff688b3953ee4ea362f5529be8c92e6 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 22 Jul 2019 16:22:10 -0400 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] CDDL 2.0 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 20:22:16 -0000 During the completion of CDDL (RFC 8610), we have put a number of = feature requests into a freezer. Now is the time to thaw some of these, = for CDDL 1.1 or 2.0. I have submitted a new version of the freezer document, which now = includes some feature requests that became known since we froze CDDL = 1.0. If you want to prepare for tomorrow morning=E2=80=99s CDDL 2.0 = discussion, this might be a starting point to consult. It is not a long = document. https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer = https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-cddl-freezer-02.t= xt Comments and discussion are of course welcome, even before tomorrow = morning! Gr=C3=BC=C3=9Fe, Carsten (Extra credits to those who find the bug in the CDDLJ CDDL in section = 8.) From nobody Mon Jul 22 14:06:26 2019 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 0F8491200A3 for ; Mon, 22 Jul 2019 14:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 ddyvA2tbqnnt for ; Mon, 22 Jul 2019 14:06:22 -0700 (PDT) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743631200B8 for ; Mon, 22 Jul 2019 14:06:22 -0700 (PDT) X-Originating-IP: 174.65.80.226 Received: from [192.168.122.118] (ip174-65-80-226.sd.sd.cox.net [174.65.80.226]) (Authenticated sender: sean@seantek.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 591671BF205; Mon, 22 Jul 2019 21:06:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Sean Leonard In-Reply-To: Date: Mon, 22 Jul 2019 14:06:16 -0700 Cc: Burt Harris , "cbor@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Cbor] draft-bormann-cbor-sequence-00 and Big Data X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:06:25 -0000 I agree with Carsten that =E2=80=9CCBOR sequence=E2=80=9D is fine as-is. I think it is inspired by JSON sequences, with the same semantics: the = order is the order that the sender put them in as the sender was = outputting them into the data item. I.e., =E2=80=9Cpreserve the = sequence=E2=80=9D at zero cost. Whether there is some greater meaning = depends on the application. The order is something that should be preserved from one sequence to = another sequence (streaming in, streaming out), but I do not believe = that this needs to be called out in the draft. If you reorder the = elements in the sequence, the hash of the cbor-sequence would be = expected to change. Sean > On Jun 22, 2019, at 10:43 PM, Carsten Bormann wrote: >=20 > Hi Burt, >=20 > thanks for your kind words on RFC 8610 and CBOR sequences! >=20 > Whether the sequence-preserving property of CBOR sequences is useful = for your application or not depends on the application. CBOR sequences = do not take a position on this, they just preserve the sequence (because = they can, at approximately zero cost). This is exactly as with CBOR = arrays, where it also depends on the application whether the actual = sequence means something or not. For serialization, they need to be in = a specific sequence, so we might as well make that available to the = application. There are applications that use CBOR sequences in a way = that cannot really be called a stream, so I think we are better off with = the =E2=80=9Csequence=E2=80=9D name. >=20 > Tagging a CBOR sequence as such is a bit difficult because logically a = CBOR tag would be tagging the first item in the sequence. CBOR = sequences are best used in a context where it is clear what they are = (e.g., via a media type); I tend to think of them like CBOR arrays that = have been taken out of their package=E2=80=A6 >=20 > Any special split markers can be provided by simply putting CBOR data = items for those markers into the CBOR sequence. And, yes, such an = application might be a good reason to allocate a CBOR Simple value or = two. We don=E2=80=99t need an equivalent for YAML =E2=80=9C=E2=80=A6=E2=80= =9D, though, because the CBOR data items themselves are self-delimiting. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Jul 22 14:15:55 2019 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 BA84E1202D1; Mon, 22 Jul 2019 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 JkaMkR9d0vd8; Mon, 22 Jul 2019 14:15:47 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCEE120143; Mon, 22 Jul 2019 14:15:46 -0700 (PDT) X-Originating-IP: 174.65.80.226 Received: from [192.168.122.118] (ip174-65-80-226.sd.sd.cox.net [174.65.80.226]) (Authenticated sender: sean@seantek.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 36B5AC0004; Mon, 22 Jul 2019 21:15:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Sean Leonard In-Reply-To: <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com> Date: Mon, 22 Jul 2019 14:15:39 -0700 Cc: Jim Schaad , draft-bormann-cbor-sequence@ietf.org, cbor@ietf.org, Carsten Bormann Content-Transfer-Encoding: quoted-printable Message-Id: <1A00546C-1EC9-4D80-A6E4-7479D2D6B16F@seantek.com> References: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> <0e8901d52f6c$08291060$187b3120$@augustcellars.com> <4AF53D16-C6AE-4D53-9A3A-DF442D827D86@felipegasper.com> <0eb801d52faa$f118fc70$d34af550$@augustcellars.com> <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com> To: Felipe Gasper X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:15:54 -0000 Basically, I believe it=E2=80=99s because you want to enable simple = concatenation semantics to add more stuff to the sequence. A sequence is = potentially multiple CBOR items strung together. An indefinite-length = CBOR array with a terminating byte is a single CBOR item; it can=E2=80=99t= be augmented by streaming more data at the end (then, naturally, the = data becomes multiple CBOR items). You can turn a CBOR sequence into a single CBOR data item by prepending = the array tag of definite length, or prepending the array tag of = indefinite length and appending the terminating byte. This is cheap = because it=E2=80=99s just part of =E2=80=9Cinitializing=E2=80=9D and = =E2=80=9Cfinalizing=E2=80=9D the decoder. But when the data is coming = across ad infinitum on the wire, you never actually want that = terminating byte in the data stream. (At the same time, once you get a = single CBOR data item, you want to fork off processing of that single = data item rather than keeping the top-level decoder running, looking for = said terminating byte.) Sean > On Jul 1, 2019, at 4:11 AM, Felipe Gasper = wrote: >=20 > Sorry, I was asking a more general question about the proposed CBOR = sequence format rather than engaging your point. >=20 > I realize I should have started a new thread--my apologies for the = confusion. >=20 > I=E2=80=99m just a bit surprised that CBOR sequences are (proposed to = be) defined this way. It seems to me that CBOR has no real need for such = a standard, precisely because of the indefinite-length arrays that the = format itself includes. I would have thought it more logical to define a = specific tag that indicates such a structure; thus, a CBOR sequence = would itself also be a valid CBOR data object. >=20 > Thank you! >=20 > -FG >=20 >> On Jun 30, 2019, at 9:18 PM, Jim Schaad = wrote: >>=20 >> This is the text I was referring to >>=20 >> An >> implementation may be able to recover from some errors in a sequence >> of bytes that is almost, but not entirely a well-formed encoded CBOR >> data item. >>=20 >> -----Original Message----- >> From: CBOR On Behalf Of Felipe Gasper >> Sent: Sunday, June 30, 2019 2:56 PM >> To: Jim Schaad >> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org; Carsten = Bormann >> Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence >>=20 >> What is the advantage of defining a CBOR data sequence as a simple = concatenation versus a tagged CBOR array of indefinite length? >>=20 >> Thank you! >>=20 >> -FG >>=20 >>> On Jun 30, 2019, at 1:48 PM, Jim Schaad = wrote: >>>=20 >>> See below. >>>=20 >>> -----Original Message----- >>> From: Carsten Bormann >>> Sent: Sunday, June 23, 2019 9:53 AM >>> To: Jim Schaad >>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org >>> Subject: Re: Review of draft-bormann-cbor-sequence >>>=20 >>> Hi Jim, >>>=20 >>> except for items 3 and 5 below, where I don=E2=80=99t quite agree, I = believe I have addressed all your comments as well as the other items = that popped up for -00 in Prague and on the mailing list. >>>=20 >>> Please enjoy at: >>>=20 >>> Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/ >>> Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-sequence >>> Diff2: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-sequence-01.txt >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>> On May 15, 2019, at 04:56, Jim Schaad = wrote: >>>>=20 >>>> [=E2=80=A6] >>>> 3. Section 2 - I think that I would remove the parenthesis in the=20= >>>> third paragraph. This is almost the entire paragraph. >>>=20 >>> I believe that is useful information, so I don=E2=80=99t think the = parenthesis should be removed. >>>=20 >>> [JLS] I am not suggesting that the sentence be removed, just the = parenthesis characters. >>>=20 >>>> [=E2=80=A6] >>>> 5. Section 2 - A program, not the decoder, may also be able to=20 >>>> recover by decoding individual fields looking for a pattern that=20 >>>> matches an expected structure. As an example, looking for a byte=20= >>>> which corresponds to an array of 3 items and then test decoding to=20= >>>> see if it works and continue from that point. >>>=20 >>> The specific recovery actions are out of scope (and the text says = so). >>> I don=E2=80=99t think we should give advice here for diagnostic = tools beyond what is needed for a true decoder. >>>=20 >>> [JLS] The problem I have with this argument is that you are actually = giving an example - should that example then be deleted? >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Jul 22 14:35:33 2019 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 4987E1200A3; Mon, 22 Jul 2019 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.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 Gp6Pjq5fqFJi; Mon, 22 Jul 2019 14:35:28 -0700 (PDT) Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (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 B057412001B; Mon, 22 Jul 2019 14:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/ooiJjFZ1HiXhNGOSuU5d+2Uw3b8aFGG/RVM6z4DBLY=; b=faZTdtwcf0yVdmdXJLLeqNvX2 MzeQ/yOQZc99XtmUXRxilU1Anc9leP53PXx22/krFNRpTFcu2xBBm0MJ1WPDFDzZOoQ9+LJF2cqD4 GSIl57lIzaVdTdBAlNajCavOA68X2Cr7zJM1J40DmGUStPs5KNpr5gkCEC9LrK+js4aC2EELKRF4w tlVQv2VOE0OdO4af5etn+6JW0rO5jStyHNu8aQZCCxlKyW85PGaKWUlu8SDHSfJ21QDuNs6bp/XJe Hlwx0M+Y1wFxYWo1FI9fNp64PtS44q/OdxbpOHIfEhc1UeOgxKZM0wGgWk7IlTM+F4a4C/d+JbhCn 8mUFyB1qA==; Received: from [208.54.86.229] (port=21859 helo=[26.52.81.1]) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpfxt-00CraG-Bw; Mon, 22 Jul 2019 16:35:26 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Felipe Gasper X-Mailer: iPhone Mail (16F203) In-Reply-To: <1A00546C-1EC9-4D80-A6E4-7479D2D6B16F@seantek.com> Date: Mon, 22 Jul 2019 17:35:24 -0400 Cc: Jim Schaad , draft-bormann-cbor-sequence@ietf.org, cbor@ietf.org, Carsten Bormann Content-Transfer-Encoding: quoted-printable Message-Id: <0ACC3867-2495-48E1-981C-78DEC6D23869@felipegasper.com> References: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> <0e8901d52f6c$08291060$187b3120$@augustcellars.com> <4AF53D16-C6AE-4D53-9A3A-DF442D827D86@felipegasper.com> <0eb801d52faa$f118fc70$d34af550$@augustcellars.com> <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com> <1A00546C-1EC9-4D80-A6E4-7479D2D6B16F@seantek.com> To: Sean Leonard X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.siteocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - felipegasper.com X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:35:32 -0000 Given that, as you observe, simple concatenation differs from an indefinite-= length array only in the leading/trailing bytes, I still don=E2=80=99t see t= he use case for a stream of CBOR items that doesn=E2=80=99t indicate either a= start or an end. It seems like it would be analogous to WebSocket without a= close handshake: what is the advantage, versus having a built-in mechanism t= hat defines the end of the stream? An advantage of defining sequences as merely a special case of indefinite-le= ngth arrays (maybe with a tag) is that an ordinary CBOR encoder and decoder c= an then parse/encode the stream: either per item if it=E2=80=99s capable, or= as a single blob otherwise. The same workflow as for an indefinite-length a= rray=E2=80=94fork off processing per item in the decoder, chunked output in t= he encoder=E2=80=94will serve the sequence use case. -F > On Jul 22, 2019, at 17:15, Sean Leonard wrote: >=20 > Basically, I believe it=E2=80=99s because you want to enable simple concat= enation semantics to add more stuff to the sequence. A sequence is potential= ly multiple CBOR items strung together. An indefinite-length CBOR array with= a terminating byte is a single CBOR item; it can=E2=80=99t be augmented by s= treaming more data at the end (then, naturally, the data becomes multiple CB= OR items). >=20 > You can turn a CBOR sequence into a single CBOR data item by prepending th= e array tag of definite length, or prepending the array tag of indefinite le= ngth and appending the terminating byte. This is cheap because it=E2=80=99s j= ust part of =E2=80=9Cinitializing=E2=80=9D and =E2=80=9Cfinalizing=E2=80=9D t= he decoder. But when the data is coming across ad infinitum on the wire, you= never actually want that terminating byte in the data stream. (At the same t= ime, once you get a single CBOR data item, you want to fork off processing o= f that single data item rather than keeping the top-level decoder running, l= ooking for said terminating byte.) >=20 > Sean >=20 >> On Jul 1, 2019, at 4:11 AM, Felipe Gasper wrote= : >>=20 >> Sorry, I was asking a more general question about the proposed CBOR seque= nce format rather than engaging your point. >>=20 >> I realize I should have started a new thread--my apologies for the confus= ion. >>=20 >> I=E2=80=99m just a bit surprised that CBOR sequences are (proposed to be)= defined this way. It seems to me that CBOR has no real need for such a stan= dard, precisely because of the indefinite-length arrays that the format itse= lf includes. I would have thought it more logical to define a specific tag t= hat indicates such a structure; thus, a CBOR sequence would itself also be a= valid CBOR data object. >>=20 >> Thank you! >>=20 >> -FG >>=20 >>> On Jun 30, 2019, at 9:18 PM, Jim Schaad wrote: >>>=20 >>> This is the text I was referring to >>>=20 >>> An >>> implementation may be able to recover from some errors in a sequence >>> of bytes that is almost, but not entirely a well-formed encoded CBOR >>> data item. >>>=20 >>> -----Original Message----- >>> From: CBOR On Behalf Of Felipe Gasper >>> Sent: Sunday, June 30, 2019 2:56 PM >>> To: Jim Schaad >>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org; Carsten Bormann= >>> Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence >>>=20 >>> What is the advantage of defining a CBOR data sequence as a simple conca= tenation versus a tagged CBOR array of indefinite length? >>>=20 >>> Thank you! >>>=20 >>> -FG >>>=20 >>>> On Jun 30, 2019, at 1:48 PM, Jim Schaad wrote:= >>>>=20 >>>> See below. >>>>=20 >>>> -----Original Message----- >>>> From: Carsten Bormann >>>> Sent: Sunday, June 23, 2019 9:53 AM >>>> To: Jim Schaad >>>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org >>>> Subject: Re: Review of draft-bormann-cbor-sequence >>>>=20 >>>> Hi Jim, >>>>=20 >>>> except for items 3 and 5 below, where I don=E2=80=99t quite agree, I be= lieve I have addressed all your comments as well as the other items that pop= ped up for -00 in Prague and on the mailing list. >>>>=20 >>>> Please enjoy at: >>>>=20 >>>> Status: https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/= >>>> Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-sequence >>>> Diff2: https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-sequ= ence-01.txt >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>>=20 >>>>> On May 15, 2019, at 04:56, Jim Schaad wrote: >>>>>=20 >>>>> [=E2=80=A6] >>>>> 3. Section 2 - I think that I would remove the parenthesis in the=20 >>>>> third paragraph. This is almost the entire paragraph. >>>>=20 >>>> I believe that is useful information, so I don=E2=80=99t think the pare= nthesis should be removed. >>>>=20 >>>> [JLS] I am not suggesting that the sentence be removed, just the parent= hesis characters. >>>>=20 >>>>> [=E2=80=A6] >>>>> 5. Section 2 - A program, not the decoder, may also be able to=20 >>>>> recover by decoding individual fields looking for a pattern that=20 >>>>> matches an expected structure. As an example, looking for a byte=20 >>>>> which corresponds to an array of 3 items and then test decoding to=20 >>>>> see if it works and continue from that point. >>>>=20 >>>> The specific recovery actions are out of scope (and the text says so). >>>> I don=E2=80=99t think we should give advice here for diagnostic tools b= eyond what is needed for a true decoder. >>>>=20 >>>> [JLS] The problem I have with this argument is that you are actually gi= ving an example - should that example then be deleted? >>>>=20 >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Mon Jul 22 15:09:08 2019 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 4C0131200B9; Mon, 22 Jul 2019 15:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 4qB5aaODe7GX; Mon, 22 Jul 2019 15:09:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9661200B8; Mon, 22 Jul 2019 15:09:04 -0700 (PDT) Received: from client-0195.vpn.uni-bremen.de (client-0195.vpn.uni-bremen.de [134.102.107.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45swk602k4zyXT; Tue, 23 Jul 2019 00:09:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <0ACC3867-2495-48E1-981C-78DEC6D23869@felipegasper.com> Date: Mon, 22 Jul 2019 18:09:00 -0400 Cc: Sean Leonard , draft-bormann-cbor-sequence@ietf.org, cbor@ietf.org, Jim Schaad X-Mao-Original-Outgoing-Id: 585526138.540789-4c12ccaa1f736d1d3c767da0e34bf4cb Content-Transfer-Encoding: quoted-printable Message-Id: <9051844B-893F-404C-B531-811317CE3BC0@tzi.org> References: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> <0e8901d52f6c$08291060$187b3120$@augustcellars.com> <4AF53D16-C6AE-4D53-9A3A-DF442D827D86@felipegasper.com> <0eb801d52faa$f118fc70$d34af550$@augustcellars.com> <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com> <1A00546C-1EC9-4D80-A6E4-7479D2D6B16F@seantek.com> <0ACC3867-2495-48E1-981C-78DEC6D23869@felipegasper.com> To: Felipe Gasper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:09:07 -0000 On Jul 22, 2019, at 17:35, Felipe Gasper = wrote: >=20 > Given that, as you observe, simple concatenation differs from an = indefinite-length array only in the leading/trailing bytes, I still = don=E2=80=99t see the use case for a stream of CBOR items that doesn=E2=80= =99t indicate either a start or an end. It seems like it would be = analogous to WebSocket without a close handshake: Exactly. (It also saves a byte or two, which may be interesting in some = applications.) > what is the advantage, versus having a built-in mechanism that defines = the end of the stream? >=20 > An advantage of defining sequences as merely a special case of = indefinite-length arrays (maybe with a tag) is that an ordinary CBOR = encoder and decoder can then parse/encode the stream: Yes. So we don=E2=80=99t have to do anything =E2=80=94 this can already = be done by application/cbor and application/=E2=80=A6+cbor (as, e.g. = SenML does). The cbor-sequence draft is for the cases that could benefit from the = abbreviated/unpacked version. > either per item if it=E2=80=99s capable, or as a single blob = otherwise. The same workflow as for an indefinite-length array=E2=80=94for= k off processing per item in the decoder, chunked output in the = encoder=E2=80=94will serve the sequence use case. Applications will continue to be able to opt for this, and I=E2=80=99m = sure many will do. Gr=C3=BC=C3=9Fe, Carsten >=20 > -F >=20 >> On Jul 22, 2019, at 17:15, Sean Leonard wrote: >>=20 >> Basically, I believe it=E2=80=99s because you want to enable simple = concatenation semantics to add more stuff to the sequence. A sequence is = potentially multiple CBOR items strung together. An indefinite-length = CBOR array with a terminating byte is a single CBOR item; it can=E2=80=99t= be augmented by streaming more data at the end (then, naturally, the = data becomes multiple CBOR items). >>=20 >> You can turn a CBOR sequence into a single CBOR data item by = prepending the array tag of definite length, or prepending the array tag = of indefinite length and appending the terminating byte. This is cheap = because it=E2=80=99s just part of =E2=80=9Cinitializing=E2=80=9D and = =E2=80=9Cfinalizing=E2=80=9D the decoder. But when the data is coming = across ad infinitum on the wire, you never actually want that = terminating byte in the data stream. (At the same time, once you get a = single CBOR data item, you want to fork off processing of that single = data item rather than keeping the top-level decoder running, looking for = said terminating byte.) >>=20 >> Sean >>=20 >>> On Jul 1, 2019, at 4:11 AM, Felipe Gasper = wrote: >>>=20 >>> Sorry, I was asking a more general question about the proposed CBOR = sequence format rather than engaging your point. >>>=20 >>> I realize I should have started a new thread--my apologies for the = confusion. >>>=20 >>> I=E2=80=99m just a bit surprised that CBOR sequences are (proposed = to be) defined this way. It seems to me that CBOR has no real need for = such a standard, precisely because of the indefinite-length arrays that = the format itself includes. I would have thought it more logical to = define a specific tag that indicates such a structure; thus, a CBOR = sequence would itself also be a valid CBOR data object. >>>=20 >>> Thank you! >>>=20 >>> -FG >>>=20 >>>> On Jun 30, 2019, at 9:18 PM, Jim Schaad = wrote: >>>>=20 >>>> This is the text I was referring to >>>>=20 >>>> An >>>> implementation may be able to recover from some errors in a = sequence >>>> of bytes that is almost, but not entirely a well-formed encoded = CBOR >>>> data item. >>>>=20 >>>> -----Original Message----- >>>> From: CBOR On Behalf Of Felipe Gasper >>>> Sent: Sunday, June 30, 2019 2:56 PM >>>> To: Jim Schaad >>>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org; Carsten = Bormann >>>> Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence >>>>=20 >>>> What is the advantage of defining a CBOR data sequence as a simple = concatenation versus a tagged CBOR array of indefinite length? >>>>=20 >>>> Thank you! >>>>=20 >>>> -FG >>>>=20 >>>>> On Jun 30, 2019, at 1:48 PM, Jim Schaad = wrote: >>>>>=20 >>>>> See below. >>>>>=20 >>>>> -----Original Message----- >>>>> From: Carsten Bormann >>>>> Sent: Sunday, June 23, 2019 9:53 AM >>>>> To: Jim Schaad >>>>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org >>>>> Subject: Re: Review of draft-bormann-cbor-sequence >>>>>=20 >>>>> Hi Jim, >>>>>=20 >>>>> except for items 3 and 5 below, where I don=E2=80=99t quite agree, = I believe I have addressed all your comments as well as the other items = that popped up for -00 in Prague and on the mailing list. >>>>>=20 >>>>> Please enjoy at: >>>>>=20 >>>>> Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/ >>>>> Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-sequence >>>>> Diff2: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-sequence-01.txt >>>>>=20 >>>>> Gr=C3=BC=C3=9Fe, Carsten >>>>>=20 >>>>>=20 >>>>>> On May 15, 2019, at 04:56, Jim Schaad = wrote: >>>>>>=20 >>>>>> [=E2=80=A6] >>>>>> 3. Section 2 - I think that I would remove the parenthesis in = the=20 >>>>>> third paragraph. This is almost the entire paragraph. >>>>>=20 >>>>> I believe that is useful information, so I don=E2=80=99t think the = parenthesis should be removed. >>>>>=20 >>>>> [JLS] I am not suggesting that the sentence be removed, just the = parenthesis characters. >>>>>=20 >>>>>> [=E2=80=A6] >>>>>> 5. Section 2 - A program, not the decoder, may also be able to=20= >>>>>> recover by decoding individual fields looking for a pattern that=20= >>>>>> matches an expected structure. As an example, looking for a byte=20= >>>>>> which corresponds to an array of 3 items and then test decoding = to=20 >>>>>> see if it works and continue from that point. >>>>>=20 >>>>> The specific recovery actions are out of scope (and the text says = so). >>>>> I don=E2=80=99t think we should give advice here for diagnostic = tools beyond what is needed for a true decoder. >>>>>=20 >>>>> [JLS] The problem I have with this argument is that you are = actually giving an example - should that example then be deleted? >>>>>=20 >>>>> _______________________________________________ >>>>> CBOR mailing list >>>>> CBOR@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cbor >>>>=20 >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Wed Jul 24 05:17:45 2019 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 2F28412082D for ; Wed, 24 Jul 2019 05:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 7x5GEBm9CoW9 for ; Wed, 24 Jul 2019 05:17:37 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C52812086C for ; Wed, 24 Jul 2019 05:17:36 -0700 (PDT) Received: from client-0221.vpn.uni-bremen.de (client-0221.vpn.uni-bremen.de [134.102.107.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45tvVk6YC2zydM; Wed, 24 Jul 2019 14:17:34 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_6A4966E8-F85B-401E-8F0A-E7167CBC6F7D" X-Mao-Original-Outgoing-Id: 585663451.217185-cdf341a550f38d88fee5b6006d8ae5b5 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Jul 2019 08:17:33 -0400 Message-Id: <5C3DFCD3-81CF-4BCB-9677-D2DC1547D36D@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Fwd: [dtn] First BPbis packets in space? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 12:17:44 -0000 --Apple-Mail=_6A4966E8-F85B-401E-8F0A-E7167CBC6F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 CBOR in space=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Marius Feldmann > Subject: [dtn] First BPbis packets in space? > Date: July 24, 2019 at 03:13:59 GMT-4 > To: dtn@ietf.org > Archived-At: = >=20 > Hi, >=20 > last Thursday we had a successful field test for the ESA-supported > project "COLDSUN". >=20 > In this field test we transmitted data taken by underwater sensors = (e.g. > pH value, pressure) via a buoy system to the Internet. The space link = to > the Internet was provided via Orbcomm IDP. Data was encapsulated in > BPbis bundles and routed via uPCN. >=20 > I guess this is the first time, BPbis has been used in a field test? >=20 > Here are some selected photos: >=20 > https://upcn.eu/COLDSUN_1.jpg >=20 > https://upcn.eu/COLDSUN_2.jpg >=20 > https://upcn.eu/COLDSUN_3.jpg >=20 > The next step on our road map is usage of BPbis on a Cubesat - = hopefully > in the end of 2019. >=20 > Marius >=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 --Apple-Mail=_6A4966E8-F85B-401E-8F0A-E7167CBC6F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 CBOR = in space=E2=80=A6

Gr=C3=BC=C3=9Fe, Carsten


Begin forwarded message:

From: = Marius Feldmann <marius.feldmann@d3tn.com>
Subject: = [dtn] First BPbis = packets in space?
Date: July 24, 2019 at 03:13:59 GMT-4
To: dtn@ietf.org
Archived-At: = <https://mailarchive.ietf.org/arch/msg/dtn/h5cXXeFJ-ouG4xA8fpmX2= mxF6lg>

Hi,

last = Thursday we had a successful field test for the ESA-supported
project "COLDSUN".

In this field = test we transmitted data taken by underwater sensors (e.g.
pH value, pressure) via a buoy system to the Internet. The = space link to
the Internet was provided via Orbcomm IDP. = Data was encapsulated in
BPbis bundles and routed via = uPCN.

I guess this is the first time, BPbis = has been used in a field test?

Here are = some selected photos:

https://upcn.eu/COLDSUN_1.jpg

https://upcn.eu/COLDSUN_2.jpg

https://upcn.eu/COLDSUN_3.jpg

The = next step on our road map is usage of BPbis on a Cubesat - hopefully
in the end of 2019.

Marius


_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn


= --Apple-Mail=_6A4966E8-F85B-401E-8F0A-E7167CBC6F7D-- From nobody Wed Jul 24 13:01:53 2019 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 9BC7B12051B for ; Wed, 24 Jul 2019 13:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 t4eJTUrfe1Hr for ; Wed, 24 Jul 2019 13:01:48 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 631B01204DC for ; Wed, 24 Jul 2019 13:01:48 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id r9so45685471ljg.5 for ; Wed, 24 Jul 2019 13:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BvPDtmn+dmUCqj4YrNhp6Zye8+NjpwcxNSvu3mG562I=; b=UviXlB8FyTo3CI2cl9jWhze2OIcby81HDMec1I5tqC0F4y0uTbhyHqkpMu447oayBb /DVMlMZUZhcxQSp3CbuA35ucWMlkxVmzJsF9/YkZ0Gvx3dyHfO1AaNMb+D8rE2cg0Hz1 /DQLYN2Ds5Gjn+U1HuWzZyZyF0U/wd25YJQjMDqyGTIEBBYDVpPcbv1zcl7RAqRpf3Ny hIukF66dnWoobpTQsk9m6Z2gF7cH69hZsW3rSsaQWZStUalkpbbZa+x6CgG4fGiHKcq/ dUWlT+uYo+1tdnavQoZCErbZ8LBMGAvZbqErMM/5YFoiqpPc4PWlTNDLKjWNYOrz/iK7 yGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BvPDtmn+dmUCqj4YrNhp6Zye8+NjpwcxNSvu3mG562I=; b=hSQQZq59n+JVUuLRRc2xD2jBrocunrgLDJr7Lx9HyVd/GATta9L/GM+bykW2cFYkIa NCtGiRMYk8ZFeIuFZTPjp3brlCAlmaZgna8/XGHXZsZ5t/v5GyJ7TpmqDuOdQGz2xhQf wy5mMBMY9VAWHckWcONA3D/m6m1kWLmafNiStuPLEPM3JDy2vYTXBl+hfXtYa4DI3/GP gcKpHaQ2jFoZErAYCe/oFsbYgM0LkcC93lhJpOqaIYfIDFHIusRwebX6l7Lvyv+xJpfl EkhA759My3jCCFlPaEwf9PNzVL0CgWpRYNI9O09+sxmJSbJemAoIhuwBX+osIMVUNzau q9xQ== X-Gm-Message-State: APjAAAVtCYXYuS4wPHgBenJROK3IbD1bs2IEfMOh7V/QwjAXDQWzTKRI Z//y87xvzMFXTHTMh5v3z/2R1pvIKNjy+Qx4LKs/x4ROgOhQVA== X-Google-Smtp-Source: APXvYqwg46Thcwemqy7kns7SHauBQK1OvGUxIPTjIUKeADVyMQjKW4gYqWzzVxtLkx26K6rOaMmoKryJyxxekkeu+Zw= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr18682174ljc.56.1563998505989; Wed, 24 Jul 2019 13:01:45 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Wed, 24 Jul 2019 16:01:35 -0400 Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 20:01:51 -0000 In https://github.com/cbor-wg/array-tags/issues/6 I complained that tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is a property of further processing rather than the data encoded in CBOR. I worried that we might introduce security issues by allowing a potentially-malicious sender to decide how the recipient processes the received data. More abstractly, I believe this is the only tag in the document that extends the CBOR generic data model. I don't think the current text adequately describes when a recipient should create a Uint8ClampedArray from potentially-untrusted input data. But I 1) didn't object during the last call and 2) don't think this is a big enough issue to try to hold up the process if other folks think it's fine. So, how do other folks feel about the marker for clamped uint8 arrays? Thanks, Jeffrey From nobody Wed Jul 24 13:41:05 2019 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 07DA0120637 for ; Wed, 24 Jul 2019 13:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Mjlof0Ijr-Zl for ; Wed, 24 Jul 2019 13:41:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3673412060C for ; Wed, 24 Jul 2019 13:41:01 -0700 (PDT) Received: from client-0200.vpn.uni-bremen.de (client-0200.vpn.uni-bremen.de [134.102.107.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45v6gb373RzySy; Wed, 24 Jul 2019 22:40:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 24 Jul 2019 16:40:58 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 585693656.0601619-3afde280af40025ceb734ea1c3809f42 Content-Transfer-Encoding: quoted-printable Message-Id: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 20:41:04 -0000 To make sure that we don=E2=80=99t create a trap for generations to fall = into, a paragraph could be added to the security considerations. Generally speaking, an implementation that wants to perform operations = on input data will need to validate that to be appropriate for that = beforehand. The potential trap here might be that a Uint8ClampedArray = might feel a lot more like a Uint8Array than other types do to each = other so the validator would be misled. So don=E2=80=99t do that=E2=80=A6= Gr=C3=BC=C3=9Fe, Carsten > On Jul 24, 2019, at 16:01, Jeffrey Yasskin = wrote: >=20 > In https://github.com/cbor-wg/array-tags/issues/6 I complained that > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is > a property of further processing rather than the data encoded in CBOR. > I worried that we might introduce security issues by allowing a > potentially-malicious sender to decide how the recipient processes the > received data. >=20 > More abstractly, I believe this is the only tag in the document that > extends the CBOR generic data model. >=20 > I don't think the current text adequately describes when a recipient > should create a Uint8ClampedArray from potentially-untrusted input > data. But I 1) didn't object during the last call and 2) don't think > this is a big enough issue to try to hold up the process if other > folks think it's fine. >=20 > So, how do other folks feel about the marker for clamped uint8 arrays? >=20 > Thanks, > Jeffrey >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Wed Jul 24 15:18:06 2019 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 520AD1202C5 for ; Wed, 24 Jul 2019 15:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Jw-P3x6fMtqC for ; Wed, 24 Jul 2019 15:18:01 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 845431202C3 for ; Wed, 24 Jul 2019 15:18:01 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id h28so32999329lfj.5 for ; Wed, 24 Jul 2019 15:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3/u4Rh35h9JVpyAsY5GAykiANOvq2V+HMgcDR4ciX8A=; b=edX8FqFJyvAaPYvIUKIltDIVn1uPrRsTyvAqAyJWmCKmlKBvzNrAa0XwjJ7bItv4rW JFkE5/P1DwfROs0CeEIVtTkkqgJDLFVbsOWEA60jR5zCMxss6ojQyE/JYIHLcoA10VPx IVHnUIhh4kZZvmHuWRvVN+u+XLtjpmqM2YNT5f/Pa/+n9RUI1o7UDVm99YjXZnvBfI27 ikZgsH5cDc/rqmgYkashmANjzpBxE9SWx08UHA4n5RV6876pZWvUzyCKl/tT3t5yfNXg JcZelkE/sxk9DiBnFuRb7nljDYgFPVOUo8ePMo617GXY5csxzaw0caU6NI5PgIGTBsak OMtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/u4Rh35h9JVpyAsY5GAykiANOvq2V+HMgcDR4ciX8A=; b=lLSjW4y6d9GxMEBlwQiwmc6Ufc3tR8qKqpAzPMzrrUnlOnMEig7dQk8N45N9tF6n7s rDSEfCDMcz2QXUThWcUmJiFTsV21E69o+puRbQCqH16KWe/lNQD2fheLIGfwQOST/fp3 R6Wiz7FiSFdWhpWBiBJnRTqbaxmxlG1zjf2QHSQIz5GIFsiZOhoNytMHse9Jx8+cvkUW SJ1IVMTOYktaCA84A92mvPg0UXz6xUUz9dadwgE247Ka4vDOZXLrrbm8/U9t89FKrQrf bD/lezaffrJ5uRQr+LIkhLEdHjXsP5lqja+SwLCw/rHwZsPDpBaV+RH7c+Y0fMA31YDT HACA== X-Gm-Message-State: APjAAAVl9UjFittGWhUyDeOaQk0SiZHGFp1Uf2MA1GtdR14Fa5iV7FD6 yu+qKr6aQ+85wP8jDPWR7Ah9GiQ3c0myB1cFTxog/CdLuwc= X-Google-Smtp-Source: APXvYqxI32MesqzOedfFBnUwt3zYvWHd2JHWi0A/ZzJ/7R3nHvn/LdW+69zTNhR2eDidgvDQ8X06AUWnx8/3EJQznW0= X-Received: by 2002:a19:750b:: with SMTP id y11mr3742741lfe.16.1564006679196; Wed, 24 Jul 2019 15:17:59 -0700 (PDT) MIME-Version: 1.0 References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> In-Reply-To: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> From: Jeffrey Yasskin Date: Wed, 24 Jul 2019 18:17:46 -0400 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a8dd8058e74aee0" Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:18:04 -0000 --0000000000008a8dd8058e74aee0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann wrote: > To make sure that we don=E2=80=99t create a trap for generations to fall = into, a > paragraph could be added to the security considerations. > That sounds like a good idea. Jeffrey > > Generally speaking, an implementation that wants to perform operations on > input data will need to validate that to be appropriate for that > beforehand. The potential trap here might be that a Uint8ClampedArray > might feel a lot more like a Uint8Array than other types do to each other > so the validator would be misled. So don=E2=80=99t do that=E2=80=A6 > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Jul 24, 2019, at 16:01, Jeffrey Yasskin 40google.com@dmarc.ietf.org> wrote: > > > > In https://github.com/cbor-wg/array-tags/issues/6 I complained that > > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is > > a property of further processing rather than the data encoded in CBOR. > > I worried that we might introduce security issues by allowing a > > potentially-malicious sender to decide how the recipient processes the > > received data. > > > > More abstractly, I believe this is the only tag in the document that > > extends the CBOR generic data model. > > > > I don't think the current text adequately describes when a recipient > > should create a Uint8ClampedArray from potentially-untrusted input > > data. But I 1) didn't object during the last call and 2) don't think > > this is a big enough issue to try to hold up the process if other > > folks think it's fine. > > > > So, how do other folks feel about the marker for clamped uint8 arrays? > > > > Thanks, > > Jeffrey > > > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > > > --0000000000008a8dd8058e74aee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <cabo@tzi.org> wrote:
To make sure that we don=E2=80=99t create a trap for generati= ons to fall into, a paragraph could be added to the security considerations= .

That sounds like a good idea.

Jeffrey

Generally speaking, an implementation that wants to perform operations on i= nput data will need to validate that to be appropriate for that beforehand.= =C2=A0 The potential trap here might be that a Uint8ClampedArray might feel= a lot more like a Uint8Array than other types do to each other so the vali= dator would be misled.=C2=A0 So don=E2=80=99t do that=E2=80=A6

Gr=C3=BC=C3=9Fe, Carsten


> On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=3D40g= oogle.com@dmarc.ietf.org> wrote:
>
> In https://github.com/cbor-wg/array-ta= gs/issues/6 I complained that
> tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is<= br> > a property of further processing rather than the data encoded in CBOR.=
> I worried that we might introduce security issues by allowing a
> potentially-malicious sender to decide how the recipient processes the=
> received data.
>
> More abstractly, I believe this is the only tag in the document that > extends the CBOR generic data model.
>
> I don't think the current text adequately describes when a recipie= nt
> should create a Uint8ClampedArray from potentially-untrusted input
> data. But I 1) didn't object during the last call and 2) don't= think
> this is a big enough issue to try to hold up the process if other
> folks think it's fine.
>
> So, how do other folks feel about the marker for clamped uint8 arrays?=
>
> Thanks,
> Jeffrey
>
> _______________________________________________
> CBOR mailing list
> = CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor=
>

--0000000000008a8dd8058e74aee0-- From nobody Wed Jul 24 16:53:24 2019 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 95FB8120098 for ; Wed, 24 Jul 2019 16:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Eqcjp_xzupQF for ; Wed, 24 Jul 2019 16:53:19 -0700 (PDT) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA9F1200B1 for ; Wed, 24 Jul 2019 16:53:19 -0700 (PDT) Received: from dhcp-96ed.meeting.ietf.org (dhcp-96ed.meeting.ietf.org [31.133.150.237]) (Authenticated sender: sean@seantek.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 36400100004; Wed, 24 Jul 2019 23:53:15 +0000 (UTC) From: Sean Leonard Message-Id: <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F06424C-2980-4745-8026-B010D44C421B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 24 Jul 2019 19:53:11 -0400 In-Reply-To: Cc: Carsten Bormann , cbor@ietf.org To: Jeffrey Yasskin References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 23:53:23 -0000 --Apple-Mail=_3F06424C-2980-4745-8026-B010D44C421B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I find round-tripping with ES6 TypedArray to be a sufficiently = compelling use case, that it should stay in. That being said, the fact that typed arrays is prompted by and mirrors = ES6 TypedArrays=E2=80=94a non-CBOR standard=E2=80=94also prompts me to = call for having the tags assigned in the > 255 space. If more TypedArray = types are defined in that spec, it is easier to assign the tags to CBOR = in a larger block of numbers. That issue, I feel, was never actually resolved on the merits. I believe = that the assignment of tags in the 1-byte space (40-255) provides less = flexibility and extensibility than assigning them in the 2-byte space = (256-65535).* The case in point illustrates that between = draft-ietf-cbor-array-tags-00 and draft-ietf-cbor-array-tags-03, the tag = 1040 got introduced seemingly came out of nowhere and broke up the nice = block of numbers. Since 1040 has been introduced anyway, that is a = strong indication that everything should be in the 256-65535 space. Sean *or they could be called 2-byte space and 3-byte space: it=E2=80=99s not = clear if there is a consistent definition that we have been using. > On Jul 24, 2019, at 6:17 PM, Jeffrey Yasskin = wrote: >=20 > On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann > wrote: > To make sure that we don=E2=80=99t create a trap for generations to = fall into, a paragraph could be added to the security considerations.. >=20 > That sounds like a good idea. >=20 > Jeffrey >=20 > Generally speaking, an implementation that wants to perform operations = on input data will need to validate that to be appropriate for that = beforehand. The potential trap here might be that a Uint8ClampedArray = might feel a lot more like a Uint8Array than other types do to each = other so the validator would be misled. So don=E2=80=99t do that=E2=80=A6= >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Jul 24, 2019, at 16:01, Jeffrey Yasskin = > wrote: > >=20 > > In https://github.com/cbor-wg/array-tags/issues/6 = I complained that > > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness = is > > a property of further processing rather than the data encoded in = CBOR. > > I worried that we might introduce security issues by allowing a > > potentially-malicious sender to decide how the recipient processes = the > > received data. > >=20 > > More abstractly, I believe this is the only tag in the document that > > extends the CBOR generic data model. > >=20 > > I don't think the current text adequately describes when a recipient > > should create a Uint8ClampedArray from potentially-untrusted input > > data. But I 1) didn't object during the last call and 2) don't think > > this is a big enough issue to try to hold up the process if other > > folks think it's fine. > >=20 > > So, how do other folks feel about the marker for clamped uint8 = arrays? > >=20 > > Thanks, > > Jeffrey > >=20 > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor = > >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_3F06424C-2980-4745-8026-B010D44C421B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = find round-tripping with ES6 TypedArray to be a sufficiently compelling = use case, that it should stay in.

That being said, the fact that typed arrays is prompted by = and mirrors ES6 TypedArrays=E2=80=94a non-CBOR standard=E2=80=94also = prompts me to call for having the tags assigned in the > 255 space. = If more TypedArray types are defined in that spec, it is easier to = assign the tags to CBOR in a larger block of numbers.

That issue, I feel, was = never actually resolved on the merits. I believe that the assignment of = tags in the 1-byte space (40-255) provides less flexibility and = extensibility than assigning them in the 2-byte space (256-65535).* The = case in point illustrates that = between draft-ietf-cbor-array-tags-00 = and draft-ietf-cbor-array-tags-03, the tag 1040 got introduced = seemingly came out of nowhere and broke up the nice block of numbers. = Since 1040 has been introduced anyway, that is a strong indication that = everything should be in the 256-65535 space.

Sean

*or they could be called 2-byte space = and 3-byte space: it=E2=80=99s not clear if there is a consistent = definition that we have been using.

On Jul = 24, 2019, at 6:17 PM, Jeffrey Yasskin <jyasskin=3D40google.com@dmarc.ietf.org> = wrote:

On Wed, Jul 24, 2019, 4:41 PM Carsten = Bormann <cabo@tzi.org> wrote:
To make sure that we don=E2=80=99t create a trap = for generations to fall into, a paragraph could be added to the security = considerations..

That sounds = like a good idea.

Jeffrey

Generally speaking, an implementation that wants to perform operations = on input data will need to validate that to be appropriate for that = beforehand.  The potential trap here might be that a = Uint8ClampedArray might feel a lot more like a Uint8Array than other = types do to each other so the validator would be misled.  So = don=E2=80=99t do that=E2=80=A6

Gr=C3=BC=C3=9Fe, Carsten


> On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=3D40google.com@dmarc.ietf.org> = wrote:
>
> In https://github.com/cbor-wg/array-tags/issues/6 I = complained that
> tag 68, marking clamped-uint8 data, is weird, in that clamped-ness = is
> a property of further processing rather than the data encoded in = CBOR.
> I worried that we might introduce security issues by allowing a
> potentially-malicious sender to decide how the recipient processes = the
> received data.
>
> More abstractly, I believe this is the only tag in the document = that
> extends the CBOR generic data model.
>
> I don't think the current text adequately describes when a = recipient
> should create a Uint8ClampedArray from potentially-untrusted = input
> data. But I 1) didn't object during the last call and 2) don't = think
> this is a big enough issue to try to hold up the process if = other
> folks think it's fine.
>
> So, how do other folks feel about the marker for clamped uint8 = arrays?
>
> Thanks,
> Jeffrey
>
> _______________________________________________
> 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

= --Apple-Mail=_3F06424C-2980-4745-8026-B010D44C421B-- From nobody Wed Jul 24 21:50:48 2019 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 51FE61201EB for ; Wed, 24 Jul 2019 21:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vOOy6VaC2CKR for ; Wed, 24 Jul 2019 21:50:44 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85ADC12001E for ; Wed, 24 Jul 2019 21:50:44 -0700 (PDT) Received: from dhcp-9abf.meeting.ietf.org (dhcp-9abf.meeting.ietf.org [31.133.154.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vKXf5774zyff; Thu, 25 Jul 2019 06:50:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> Date: Thu, 25 Jul 2019 00:50:41 -0400 Cc: Jeffrey Yasskin , cbor@ietf.org X-Mao-Original-Outgoing-Id: 585723039.095157-c0ade9c7b68e6269f5118c8e2a13c40d Content-Transfer-Encoding: quoted-printable Message-Id: References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 04:50:46 -0000 On Jul 24, 2019, at 19:53, Sean Leonard wrote: >=20 > having the tags assigned Too late, they already are assigned. (If you think this shouldn=E2=80=99t have happened, please consider the = WG=E2=80=99s current stance on changing the IANA considerations on 1+1 = tags away from specification required.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 25 13:17:52 2019 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 6A8341201EC for ; Thu, 25 Jul 2019 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 awyeb1CzSJzo for ; Thu, 25 Jul 2019 13:17:48 -0700 (PDT) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357B71201E3 for ; Thu, 25 Jul 2019 13:17:48 -0700 (PDT) X-Originating-IP: 31.133.157.10 Received: from dhcp-9d0a.meeting.ietf.org (dhcp-9d0a.meeting.ietf.org [31.133.157.10]) (Authenticated sender: sean@seantek.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 7AE2B1BF20E; Thu, 25 Jul 2019 20:17:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Sean Leonard In-Reply-To: Date: Thu, 25 Jul 2019 16:17:43 -0400 Cc: Jeffrey Yasskin , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:17:51 -0000 > On Jul 25, 2019, at 12:50 AM, Carsten Bormann wrote: >=20 > On Jul 24, 2019, at 19:53, Sean Leonard wrote: >>=20 >> having the tags assigned >=20 > Too late, they already are assigned. >=20 > (If you think this shouldn=E2=80=99t have happened, please consider = the WG=E2=80=99s current stance on changing the IANA considerations on = 1+1 tags away from specification required.) Recognizing the lateness of the comment, and that they have already been = assigned, I will not pursue it further=E2=80=94it=E2=80=99s fine. This thread raises an interesting point, namely, using CBOR tags to = identify the type of object in protocol that exists elsewhere in an = object oriented system, such as in other standards or other = implementations. =E2=80=9CUint8ClampedArray=E2=80=9D does not exist in = JSON, but it exists in JavaScript/ES6 (which is both a standard and is = backed by multiple conforming implementations.) I think this is a good = design pattern and should be liberally employed with more CBOR tag use. Sean= From nobody Thu Jul 25 13:37:00 2019 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 6BF731201EF for ; Thu, 25 Jul 2019 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uqRG0YPfgLCy for ; Thu, 25 Jul 2019 13:36:55 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 4FB3E1201DB for ; Thu, 25 Jul 2019 13:36:55 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id i21so49309625ljj.3 for ; Thu, 25 Jul 2019 13:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cGox2Jfh4pZfRVJG8qR0sJDZaTQPamSV07Rrlt5u42M=; b=TML7DOaycr2CekrzNAFfF564h7kHB0ZHbQh0KQIO2Ff2vICEqzCWfGMYW8IXOXBVl9 gp4UtWmOyWV/CHfUjsSXR1CeeO1yUZdNb3X/9dk9nmT9MeJxPYVXHkqvfuftLonQjIHK 8N5lBExD30G2O6PHMqCOcO/1/BdpT7EZx9MZTKQbqqVnE3CtytIPEAt5Ohg6Buy1wKdQ /CZ6cBhSy67oXSiH43Wsrr9SAu7wkY5c7ZTGxmv4Pwl5V9zAahKzTM8ffynrYzAw3/zr wvoxHkNQqmMdGZF3UK1iBxEN/sloX6xK42DVY8m8sPD5co87XI2nD9UPJJSSfkBj1uHg M/aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cGox2Jfh4pZfRVJG8qR0sJDZaTQPamSV07Rrlt5u42M=; b=OPWyw+KGjwraxwtOt7yzybB3utYy7azedOprLsuwOqS7guTH8w7LIAPmOX2wIZLBuJ m+uyk+iNkDJvkP0OI+3viZ5oy2gxKEsxE6KRsM+WLSx+Sr3lt5o4KiHFpG8M3MGFsYBJ q1rMSXBV4khuRg5ZuwEkhZfCfJy/+vkuFhh46wr1Z851Hl55+7H5IMcQzfVIja6hLmQ3 e79vcXXyodkHTMwBvpjRYgXhkBi69mHmucytV+BbyKZeSw9TrpfAjQJj1JFBwgP3KrJP imJgECvtHfQ+AQS+NRoNskTph0o8a0O2W7mgFCNUxwTQkQ21QyTLHPpRgRNfBe/bIXKi z9XA== X-Gm-Message-State: APjAAAVHVKJ7wnwVhS+pkm5z+EcT15vj+hfSDL591n5xePf3sqEK6ofY AyUzvzogix3AL9TadrPq98GO81wVjTbLIgDN91Ddog== X-Google-Smtp-Source: APXvYqwPkAflqrU/INaLJSRAu5YyTzkuAWjJyj/u/5/rTcttCRCSht7R20xiJRstl50X0SMMz3L5xBgm/HyAcgCdLKQ= X-Received: by 2002:a2e:8e90:: with SMTP id z16mr25432228ljk.4.1564087013142; Thu, 25 Jul 2019 13:36:53 -0700 (PDT) MIME-Version: 1.0 References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> In-Reply-To: <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> From: Jeffrey Yasskin Date: Thu, 25 Jul 2019 16:36:40 -0400 Message-ID: To: Sean Leonard Cc: Carsten Bormann , cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:36:58 -0000 On Thu, Jul 25, 2019 at 4:17 PM Sean Leonard wrote: > This thread raises an interesting point, namely, using CBOR tags to ident= ify the type of object in protocol that exists elsewhere in an object orien= ted system, such as in other standards or other implementations. =E2=80=9CU= int8ClampedArray=E2=80=9D does not exist in JSON, but it exists in JavaScri= pt/ES6 (which is both a standard and is backed by multiple conforming imple= mentations.) I think this is a good design pattern and should be liberally = employed with more CBOR tag use. > I think that's a good description of the disagreement. I remain uncomfortable with having a serialization format describe behaviors that the data had or should have when it was or is loaded into a program. The serialization should instead describe the meaning of the data. That will correlate with the types of objects that store the data inside a program, but it shouldn't directly determine the types. That said, it seems unlikely that web platform uses of CBOR will use tags, so this doesn't affect me enough to make me care that much. Jeffrey From nobody Thu Jul 25 13:38:54 2019 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 B0A3F1201F1 for ; Thu, 25 Jul 2019 13:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 gRkC7mZcWCiF for ; Thu, 25 Jul 2019 13:38:46 -0700 (PDT) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FE9120293 for ; Thu, 25 Jul 2019 13:38:45 -0700 (PDT) X-Originating-IP: 31.133.157.10 Received: from dhcp-9d0a.meeting.ietf.org (dhcp-9d0a.meeting.ietf.org [31.133.157.10]) (Authenticated sender: sean@seantek.org) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id E988C24000C for ; Thu, 25 Jul 2019 20:38:43 +0000 (UTC) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> Date: Thu, 25 Jul 2019 16:38:41 -0400 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:38:53 -0000 Hi WG, what is the current stance on changing the IANA Considerations = for tag registration? I find the RFC 7049 tag registration scheme (0-31 =3D standards action, = 32-255 =3D specification required, 256+ =3D FCFS) to be acceptable. However, I think that maybe we want to encourage more tag registration, = while also having a bigger space for more review and publication. I read = the minutes and am not sure if there is a current stance or a group = sense on the matter, at least within the past 12 months. Thanks, Sean= From nobody Thu Jul 25 14:19:51 2019 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 9110B1201FA for ; Thu, 25 Jul 2019 14:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 WJ-JwAERGSH6 for ; Thu, 25 Jul 2019 14:19:48 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 19CF51201F2 for ; Thu, 25 Jul 2019 14:19:48 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2019 14:19:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,308,1559545200"; d="scan'208";a="369332161" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 25 Jul 2019 14:19:47 -0700 Received: from tjmaciei-mobl1.localnet (10.54.75.134) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 14:19:47 -0700 From: Thiago Macieira To: CC: Sean Leonard Date: Thu, 25 Jul 2019 14:19:47 -0700 Message-ID: <10096467.9kdZcmANtY@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.54.75.134] Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 21:19:50 -0000 On Thursday, 25 July 2019 13:38:41 PDT Sean Leonard wrote: > Hi WG, what is the current stance on changing the IANA Considerations for > tag registration? > > I find the RFC 7049 tag registration scheme (0-31 = standards action, 32-255 > = specification required, 256+ = FCFS) to be acceptable. > > However, I think that maybe we want to encourage more tag registration, > while also having a bigger space for more review and publication. I read > the minutes and am not sure if there is a current stance or a group sense > on the matter, at least within the past 12 months. Could we get 32-255 to be slightly stricter but not to the level of standards action? I was thinking of publication of a draft to this WG and allow for a 2- week comment period. This could both spur ideas from other passive watchers and ensure high quality of the ones that do get published. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Thu Jul 25 14:26:08 2019 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 586D612023B for ; Thu, 25 Jul 2019 14:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZRTvC59jxl25 for ; Thu, 25 Jul 2019 14:26:00 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 11C8012028B for ; Thu, 25 Jul 2019 14:26:00 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id j6so10442005ybm.7 for ; Thu, 25 Jul 2019 14:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ypuSF9g3/MRm/zOoHZgWhWZldhud24QAlB6VTssRnnw=; b=Fr9S531+72xKL/lpa8/GuLR7cGNFGnnmt5iFL6NLHskfuCutdiV3BqKanZ60ttNd41 W+8puWYeYk4G+azka64B6HnQyKAhzKLSLvoV5EcJCPyHo7lAVz3iRArFTgMqdqNnfZGX FykLI+iPA7A/kYMbfFfGu9vuDkJNgmTuu4cONUv1M4oNbF9iRmVj0uIXDAeb0nZ8OpTV QKvizr9Atn+RjFbvI+ySpx5LFbnX+T//LTOc1zXKnycMiDSbsWRlYY14xtHjJypxQ881 e+THBiztBWGMdgm2hbW0A+vfXLYeprTzzmi60Smv+5BWgX0qBDgvrm/PVzz+02zhJwuT ri3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ypuSF9g3/MRm/zOoHZgWhWZldhud24QAlB6VTssRnnw=; b=G0hywCL81Z5keNZJcywyOPAxXhP+BZJredU4R+FwS30i0I52l6Qkf1EljHS/iI7jsK 6m5qN9QT5lEoyWKtNi+ts1xFWbe10SMQ6TOL1cJ/gSZO3dZzkIB1Tpj6UUsSgnjJXtwK 8t1ejPNYtQWPVmlI/o6qRq/tTPDeh9BZx7ImxAHBsVzjJEOUvVIY7JoHe9N39ZKDjNa/ 4dxvNWAsqj8Mp/Pm+X8XMDxWu6WPdliNqISaAzLBbWLfp37tOloTXreiJh+XaV6XsMXb cbIIndsWUSuJDc8ObW6x8HL7IfFq8Zmm0+EsaK8v5xxPWVyWoPOC292tP46gnTMIxmYJ a3eA== X-Gm-Message-State: APjAAAWrTXrWt+8JIwAZOwH5gu9vdDqerHOJPncG/vcymmJq+fxeAHBp rnXMeayARst20EvhAjlRUuWo+UGLmVlCygkh8nI= X-Google-Smtp-Source: APXvYqzhhip/WAr43XQ3aZhsq9ubjTuGe4dCKC4BYYxkJFieKNzShqR1ig4jRtdJc/V1U/8mFPinX//DbN9/SBxwmK0= X-Received: by 2002:a25:1283:: with SMTP id 125mr57108014ybs.55.1564089959112; Thu, 25 Jul 2019 14:25:59 -0700 (PDT) MIME-Version: 1.0 References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <10096467.9kdZcmANtY@tjmaciei-mobl1> In-Reply-To: <10096467.9kdZcmANtY@tjmaciei-mobl1> From: Ira McDonald Date: Thu, 25 Jul 2019 17:25:48 -0400 Message-ID: To: Thiago Macieira , Ira McDonald Cc: cbor@ietf.org, Sean Leonard Content-Type: multipart/alternative; boundary="00000000000068e3ed058e881259" Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 21:26:07 -0000 --00000000000068e3ed058e881259 Content-Type: text/plain; charset="UTF-8" Hi, (possibly putting foot in mouth) I think it's a bad practice to lower a previous IANA requirement for any number range in a registry (especially from specification required to one instance of Internet-Draft and two weeks of silent approval). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Jul 25, 2019 at 5:19 PM Thiago Macieira wrote: > On Thursday, 25 July 2019 13:38:41 PDT Sean Leonard wrote: > > Hi WG, what is the current stance on changing the IANA Considerations for > > tag registration? > > > > I find the RFC 7049 tag registration scheme (0-31 = standards action, > 32-255 > > = specification required, 256+ = FCFS) to be acceptable. > > > > However, I think that maybe we want to encourage more tag registration, > > while also having a bigger space for more review and publication. I read > > the minutes and am not sure if there is a current stance or a group sense > > on the matter, at least within the past 12 months. > > Could we get 32-255 to be slightly stricter but not to the level of > standards > action? I was thinking of publication of a draft to this WG and allow for > a 2- > week comment period. This could both spur ideas from other passive > watchers > and ensure high quality of the ones that do get published. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --00000000000068e3ed058e881259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

(possibly putting foot i= n mouth)

I think it's a bad practice to lower = a previous IANA requirement for any number
range in a registry (e= specially from specification required to one instance of
Internet= -Draft and two weeks of silent approval).

Cheers,<= /div>
- Ira

Ira McDonald (Musi= cian / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG<= /div>
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Prin= ter Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG=
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / Hig= h North Inc
http://sites.google.com/site/bl= ueroofmusic
http://sites.google.com/site= /highnorthinc
mailto: blueroofmusic@gmail.com
PO Box 221=C2=A0 Grand Marais= , MI 49839=C2=A0 906-494-2434

=
=


On Thu, Jul 25, 2019 at 5:19 PM Thiago Maciei= ra <thiago.macieira@intel.c= om> wrote:
intel.com
=C2=A0 Software Architect - Intel System Software Products



_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--00000000000068e3ed058e881259-- From nobody Thu Jul 25 15:19:18 2019 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 C7B991201DB for ; Thu, 25 Jul 2019 15:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 ZF3txMAxSrkk for ; Thu, 25 Jul 2019 15:19:15 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7973F1201D1 for ; Thu, 25 Jul 2019 15:19:14 -0700 (PDT) X-Originating-IP: 31.133.157.10 Received: from dhcp-9d0a.meeting.ietf.org (dhcp-9d0a.meeting.ietf.org [31.133.157.10]) (Authenticated sender: sean@seantek.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1DBB460005; Thu, 25 Jul 2019 22:19:10 +0000 (UTC) From: Sean Leonard Message-Id: <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A2EF3D5B-C9B3-47CE-823F-BD81EB5F79A8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 25 Jul 2019 18:19:09 -0400 In-Reply-To: Cc: Thiago Macieira , cbor@ietf.org To: Ira McDonald References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <10096467.9kdZcmANtY@tjmaciei-mobl1> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 22:19:18 -0000 --Apple-Mail=_A2EF3D5B-C9B3-47CE-823F-BD81EB5F79A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay so it sounds like there are more than crickets on the topic, so we = can discuss it=E2=80=A6 My intuition is as follows: 0-23 =3D standards action =3D no change 24-255 =3D RFC Required 256-65535 OR 256-32767 =3D specification required 65536+ OR 32767+ =3D FCFS =3D no change This was my intuition based on tags being proposed, and the relative = value of smaller tag numbers. However, I would want to make it more = rigorous than just a feeling. RFC 8126 =E2=80=9CGuidelines for Writing an IANA Considerations Section = in RFCs=E2=80=9D defines the levels of review. RFC Required is one notch = higher than Specification Required. Hence it is the smallest incremental = bump. It would provide no difference in outcome to *most* stuff in = 32-255 at present, but I checked and there are about 10 allocations in = 24-255 (including about 5 in the low range, 24-29) that would have been = excluded because the specs are not RFCs. The space 32-255 is already = nearly half exhausted. Specification required should be in place for the 1+2 byte range, since, = well, we want public specs. In my mind, it is hard to justify = restricting anything in the 1+4 byte space (32 bits) since they have = equal performance characteristics. There has been a good amount of discussion about constrained CBOR = platforms that do not natively do 64-bit integers. However, is it fair = to say that even the most resource-constrained devices these days are = 32-bit capable without a lot of hassle? Splitting the baby in half at the 16th bit allows half of the space to = have more review, while the upper half can still be FCFS and get the = same performance. =E2=80=9C32,768 numbers is enough for everybody!=E2=80=9D= =E2=80=94 or is it? I wonder if we should bump 256-4095 or so to a higher level of review = than specification required. It still leaves 28,000 values that have the = same performance characteristics. Sean > On Jul 25, 2019, at 5:25 PM, Ira McDonald = wrote: >=20 > Hi, >=20 > (possibly putting foot in mouth) >=20 > I think it's a bad practice to lower a previous IANA requirement for = any number > range in a registry (especially from specification required to one = instance of > Internet-Draft and two weeks of silent approval). >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Co-Chair - TCG Metadata Access Protocol SG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic = > http://sites.google.com/site/highnorthinc = > mailto: blueroofmusic@gmail.com > PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 >=20 > On Thu, Jul 25, 2019 at 5:19 PM Thiago Macieira = > wrote: > On Thursday, 25 July 2019 13:38:41 PDT Sean Leonard wrote: > > Hi WG, what is the current stance on changing the IANA = Considerations for > > tag registration? > >=20 > > I find the RFC 7049 tag registration scheme (0-31 =3D standards = action, 32-255 > > =3D specification required, 256+ =3D FCFS) to be acceptable. > >=20 > > However, I think that maybe we want to encourage more tag = registration, > > while also having a bigger space for more review and publication. I = read > > the minutes and am not sure if there is a current stance or a group = sense > > on the matter, at least within the past 12 months. >=20 > Could we get 32-255 to be slightly stricter but not to the level of = standards=20 > action? I was thinking of publication of a draft to this WG and allow = for a 2- > week comment period. This could both spur ideas from other passive = watchers=20 > and ensure high quality of the ones that do get published. >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products >=20 >=20 >=20 > _______________________________________________ > 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 --Apple-Mail=_A2EF3D5B-C9B3-47CE-823F-BD81EB5F79A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay = so it sounds like there are more than crickets on the topic, so we can = discuss it=E2=80=A6

My= intuition is as follows:

0-23 =3D standards action =3D no change
24-255 =3D RFC Required
256-65535 OR = 256-32767 =3D specification required
65536+ OR = 32767+ =3D FCFS =3D no change

This was my intuition based on tags = being proposed, and the relative value of smaller tag numbers. However, = I would want to make it more rigorous than just a feeling.

RFC 8126 =E2=80=9CGuidelin= es for Writing an IANA Considerations Section in RFCs=E2=80=9D defines = the levels of review. RFC Required is one notch higher than = Specification Required. Hence it is the smallest incremental bump. It = would provide no difference in outcome to *most* stuff in 32-255 at = present, but I checked and there are about 10 allocations in 24-255 = (including about 5 in the low range, 24-29) that would have been = excluded because the specs are not RFCs. The space 32-255 is already = nearly half exhausted.

Specification required should be in place for the 1+2 byte = range, since, well, we want public specs. In my mind, it is hard to = justify restricting anything in the 1+4 byte space (32 bits) since they = have equal performance characteristics.

There has been a good amount of = discussion about constrained CBOR platforms that do not natively do = 64-bit integers. However, is it fair to say that even the most = resource-constrained devices these days are 32-bit capable without a lot = of hassle?

Splitting the baby in half at the 16th bit allows half of the = space to have more review, while the upper half can still be FCFS and = get the same performance. =E2=80=9C32,768 numbers is enough for = everybody!=E2=80=9D =E2=80=94 or is it?

I wonder if we should bump 256-4095 or = so to a higher level of review than specification required. It still = leaves 28,000 values that have the same performance = characteristics.

Sean

On Jul 25, 2019, at 5:25 PM, = Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

(possibly putting foot in = mouth)

I think = it's a bad practice to lower a previous IANA requirement for any = number
range in a registry (especially from = specification required to one instance of
Internet-Draft and two weeks of silent approval).

Cheers,
- Ira

Ira McDonald = (Musician / Software Architect)
Co-Chair - TCG Trusted = Mobility Solutions WG
Co-Chair - TCG Metadata = Access Protocol SG
Chair = - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO = Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet = Printing Protocol WG
IETF Designated Expert - IPP & = Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
PO = Box 221  Grand Marais, MI 49839  906-494-2434


On Thu, Jul 25, 2019 at 5:19 PM Thiago = Macieira <thiago.macieira@intel.com> wrote:
On Thursday, 25 July 2019 13:38:41 = PDT Sean Leonard wrote:
> Hi WG, what is the current stance on changing the IANA = Considerations for
> tag registration?
>
> I find the RFC 7049 tag registration scheme (0-31 =3D standards = action, 32-255
> =3D specification required, 256+ =3D FCFS) to be acceptable.
>
> However, I think that maybe we want to encourage more tag = registration,
> while also having a bigger space for more review and publication. I = read
> the minutes and am not sure if there is a current stance or a group = sense
> on the matter, at least within the past 12 months.

Could we get 32-255 to be slightly stricter but not to the level of = standards
action? I was thinking of publication of a draft to this WG and allow = for a 2-
week comment period. This could both spur ideas from other passive = watchers
and ensure high quality of the ones that do get published.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



_______________________________________________
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

= --Apple-Mail=_A2EF3D5B-C9B3-47CE-823F-BD81EB5F79A8-- From nobody Thu Jul 25 15:25:32 2019 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 754A91201F1 for ; Thu, 25 Jul 2019 15:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 vg4fBqKUdq3U for ; Thu, 25 Jul 2019 15:25:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F6A1201D1 for ; Thu, 25 Jul 2019 15:25:28 -0700 (PDT) Received: from dhcp-80d9.meeting.ietf.org (dhcp-80d9.meeting.ietf.org [31.133.128.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vmxd2bpMz10BM; Fri, 26 Jul 2019 00:25:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> Date: Thu, 25 Jul 2019 18:25:23 -0400 Cc: Ira McDonald , Thiago Macieira , cbor@ietf.org X-Mao-Original-Outgoing-Id: 585786321.596122-00360be2b0c4581f61e2cc9816fda0e5 Content-Transfer-Encoding: quoted-printable Message-Id: <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <10096467.9kdZcmANtY@tjmaciei-mobl1> <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 22:25:30 -0000 On Jul 25, 2019, at 18:19, Sean Leonard wrote: >=20 > 24-255 =3D RFC Required I like that. (That includes the independent stream. But there is a level of quality = checking in publishing an RFC, so only high quality specifications will = get these. Of course, the designated expert *could* do the same quality = checking, but there may be a slightly higher tendency to just give in = among us weaker DEs.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 25 17:06:25 2019 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 C759B120265 for ; Thu, 25 Jul 2019 17:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 47nGLv7rWrth for ; Thu, 25 Jul 2019 17:06:21 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 AF06C120224 for ; Thu, 25 Jul 2019 17:06:21 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2019 17:06:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,308,1559545200"; d="scan'208";a="369369227" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 25 Jul 2019 17:06:21 -0700 Received: from tjmaciei-mobl1.localnet (10.54.75.134) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 17:06:20 -0700 From: Thiago Macieira To: Carsten Bormann , Date: Thu, 25 Jul 2019 17:06:21 -0700 Message-ID: <15044986.HgQyyibD5o@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.54.75.134] Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 00:06:24 -0000 On Thursday, 25 July 2019 15:25:23 PDT Carsten Bormann wrote: > On Jul 25, 2019, at 18:19, Sean Leonard wrote: > > 24-255 = RFC Required > > I like that. > (That includes the independent stream. But there is a level of quality > checking in publishing an RFC, so only high quality specifications will get > these. Of course, the designated expert *could* do the same quality > checking, but there may be a slightly higher tendency to just give in among > us weaker DEs.) The problem is less the quality checking and more the time required to write an RFC, with the overhead required of it. For example, I am sitting on a bunch of simple types I wanted to recommend, but never had the time to review, much less write RFCs for. https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/ serialization/cbor-tags-geometry.rst https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/ serialization/cbor-tag-bitarray.rst As you can see from the tag numbers, I wrote them a while ago but never told anyone about them. I find that those are generically useful types that probably should exist in the 32-255 range, but I'd like the community to agree with me. And if we conclude that the range is correct, then I probably won't find the time. Nor do I think that an RFC is required to define a couple of tags for 2D and 3D geometry types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Thu Jul 25 18:58:07 2019 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 25E87120295 for ; Thu, 25 Jul 2019 18:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 bkeG6FqYTztd for ; Thu, 25 Jul 2019 18:58:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B3D1202B3 for ; Thu, 25 Jul 2019 18:57:59 -0700 (PDT) Received: from client-0001.vpn.uni-bremen.de (client-0001.vpn.uni-bremen.de [134.102.107.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vsfs485zzyvb; Fri, 26 Jul 2019 03:57:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <15044986.HgQyyibD5o@tjmaciei-mobl1> Date: Thu, 25 Jul 2019 21:57:55 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 585799073.9781801-1c038b4b868527043a937fa5210fbd71 Content-Transfer-Encoding: quoted-printable Message-Id: References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> <15044986.HgQyyibD5o@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 01:58:06 -0000 Hi Thiago, there was a bit of a logjam as the old charter of CBOR WG limited us to = two specific tags documents specified in the charter. Rechartering is = imminent, and I=E2=80=99d sure like the WG to look at your documents. = Maybe I can help you a bit to progress them to RFC, or maybe we want to = work together on a slightly wider =E2=80=9Ccommon tags=E2=80=9D = document. Let=E2=80=99s talk about that after the IETF. Gr=C3=BC=C3=9Fe, Carsten PS.: RFC 8610 has been published last month and the data definition = language is now called Concise Data Definition Language (CDDL); after = all, it also covers JSON, and implicitly most of YAML, TOML, etc. > On Jul 25, 2019, at 20:06, Thiago Macieira = wrote: >=20 > On Thursday, 25 July 2019 15:25:23 PDT Carsten Bormann wrote: >> On Jul 25, 2019, at 18:19, Sean Leonard wrote: >>> 24-255 =3D RFC Required >>=20 >> I like that. >> (That includes the independent stream. But there is a level of = quality >> checking in publishing an RFC, so only high quality specifications = will get >> these. Of course, the designated expert *could* do the same quality >> checking, but there may be a slightly higher tendency to just give in = among >> us weaker DEs.) >=20 > The problem is less the quality checking and more the time required to = write=20 > an RFC, with the overhead required of it. >=20 > For example, I am sitting on a bunch of simple types I wanted to = recommend,=20 > but never had the time to review, much less write RFCs for. >=20 > https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/ > serialization/cbor-tags-geometry.rst > https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/ > serialization/cbor-tag-bitarray.rst >=20 > As you can see from the tag numbers, I wrote them a while ago but = never told=20 > anyone about them. I find that those are generically useful types that=20= > probably should exist in the 32-255 range, but I'd like the community = to agree=20 > with me. >=20 > And if we conclude that the range is correct, then I probably won't = find the=20 > time. Nor do I think that an RFC is required to define a couple of = tags for 2D=20 > and 3D geometry types. >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Thu Jul 25 19:06:37 2019 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 7DDD412025D for ; Thu, 25 Jul 2019 19:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 w1Fu8mlO2OXx for ; Thu, 25 Jul 2019 19:06:34 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205C2120256 for ; Thu, 25 Jul 2019 19:06:34 -0700 (PDT) Received: from client-0001.vpn.uni-bremen.de (client-0001.vpn.uni-bremen.de [134.102.107.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vsrm1Fj4z10D5; Fri, 26 Jul 2019 04:06:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jul 2019 22:06:30 -0400 Cc: Sean Leonard , cbor@ietf.org X-Mao-Original-Outgoing-Id: 585799588.995239-7b597da1af8679cd0c42664a2d6d95b0 Content-Transfer-Encoding: quoted-printable Message-Id: <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org> References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 02:06:36 -0000 On Jul 25, 2019, at 16:36, Jeffrey Yasskin wrote: >=20 > I remain > uncomfortable with having a serialization format describe behaviors > that the data had or should have when it was or is loaded into a > program. I don=E2=80=99t know how to avoid that. If the input is an array, in = most generic decoders I get an array to work from. If the input is = instead a map, I get a map (or a JavaScript object); that has quite = different behavior. So the supplier of the input already has a lot of = control over the data structures that are input to my system. = Uint8ClampedArray just adds a slight twist to that as it might look too = much like a Uint8Array. None of this relieves an application of validating its input =E2=80=94 = with a standard serialization format and a robust generic decoder, this = can now simply be done on a higher level. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 26 05:22:07 2019 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 85D391202E0 for ; Fri, 26 Jul 2019 05:22:05 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 lEjFAjKdtB8s for ; Fri, 26 Jul 2019 05:22:03 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA3312029A for ; Fri, 26 Jul 2019 05:22:03 -0700 (PDT) Received: from Jude (31.133.136.216) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jul 2019 05:21:56 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Sean Leonard' CC: 'Thiago Macieira' , 'Ira McDonald' , References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <10096467.9kdZcmANtY@tjmaciei-mobl1> <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> In-Reply-To: <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> Date: Fri, 26 Jul 2019 08:21:53 -0400 Message-ID: <045601d543ac$b79f3d40$26ddb7c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI1+RqtKmMqPa99WI8bvfzd2IMJ1QHaPyU6AaIhjlIC19vEzQKJvFsIpdR2lvA= Content-Language: en-us X-Originating-IP: [31.133.136.216] Archived-At: Subject: Re: [Cbor] CBOR tag range IANA allocation policy X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 12:22:06 -0000 I think that RFC Required might be overkill. As this is a specification = required, there is already a requirement for Expert Review as well. The = easier thing might be to add language to the reviewer instructions along = the lines of: Reviewers should be reluctant to assign code points in the 24-255 range = to specifications that are not RFC documents. In the event that it is = deemed wise to assign such a point anyway the CBOR working group mailing = list should be advised of this and allowed to give input over a short = period of time (in the order of 3-5 days). Jim -----Original Message----- From: CBOR On Behalf Of Carsten Bormann Sent: Thursday, July 25, 2019 6:25 PM To: Sean Leonard Cc: Thiago Macieira ; Ira McDonald = ; cbor@ietf.org Subject: Re: [Cbor] CBOR tag range IANA allocation policy On Jul 25, 2019, at 18:19, Sean Leonard wrote: >=20 > 24-255 =3D RFC Required I like that. (That includes the independent stream. But there is a level of quality = checking in publishing an RFC, so only high quality specifications will = get these. Of course, the designated expert *could* do the same quality = checking, but there may be a slightly higher tendency to just give in = among us weaker DEs.) Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Jul 26 07:08:50 2019 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 D664D120044 for ; Fri, 26 Jul 2019 07:08:47 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 9ijNjnwkNnI5 for ; Fri, 26 Jul 2019 07:08:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923D0120072 for ; Fri, 26 Jul 2019 07:08:21 -0700 (PDT) Received: from Jude (31.133.136.216) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jul 2019 07:08:14 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Jeffrey Yasskin' CC: , 'Sean Leonard' References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org> In-Reply-To: <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org> Date: Fri, 26 Jul 2019 10:08:11 -0400 Message-ID: <046501d543bb$90f52d30$b2df8790$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK/Tufj5AbRSJa8nmBSWNHNjScWbwIJz96mAaxsNKwB0TlobgLRCBxtAvmG4zUCPt//8wGfgnXfpI9UHVA= Content-Language: en-us X-Originating-IP: [31.133.136.216] Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 14:08:48 -0000 Chairs: We are expecting that Carsten will provide a pull request with the = suggested Security Considerations changes to deal with this issue: As Individual:=20 See below. -----Original Message----- From: CBOR On Behalf Of Carsten Bormann Sent: Thursday, July 25, 2019 10:07 PM To: Jeffrey Yasskin Cc: cbor@ietf.org; Sean Leonard Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 = arrays? On Jul 25, 2019, at 16:36, Jeffrey Yasskin wrote: >=20 > I remain > uncomfortable with having a serialization format describe behaviors=20 > that the data had or should have when it was or is loaded into a=20 > program. I don=E2=80=99t know how to avoid that. If the input is an array, in = most generic decoders I get an array to work from. If the input is = instead a map, I get a map (or a JavaScript object); that has quite = different behavior. So the supplier of the input already has a lot of = control over the data structures that are input to my system. = Uint8ClampedArray just adds a slight twist to that as it might look too = much like a Uint8Array. None of this relieves an application of validating its input =E2=80=94 = with a standard serialization format and a robust generic decoder, this = can now simply be done on a higher level. [JLS] In many respects I kind of agree with Carsten on this. When I = look at this I have a hard time distinguishing between this case and = some of the other cases where similar rules are also being required. = For example, if you tag something as UTF-8 or as MIME, the sender is = controlling how both the generic decoder and the application are = supposed to handle this information. If I created a tag which defined = a subset of UTF-8 then this would be even more true. For my = application both Uint8ClampedArray and Uint8Array would be placed in the = same data structure type as I don't have a native type for clamped = arrays. There are then rules on how I manipulate the data. The same is = true for the subset of UTF-8. This is going to be put into a native = format for my machine - maybe UTF16 since that is the native C# data = type - but there are still rules on what can be done with the data and = how it can be changed. The application is not permitted to place items = in the string which do not match the legal subset of strings allowed. Jim Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Jul 26 07:25:29 2019 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 0CF9312009C for ; Fri, 26 Jul 2019 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZLd8VOLuTzBo for ; Fri, 26 Jul 2019 07:25:26 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 97F1C12004A for ; Fri, 26 Jul 2019 07:25:26 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id f9so54614292wre.12 for ; Fri, 26 Jul 2019 07:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=g70KB5NXKdaKW1Od+1/8BX7/yDYNCTEsiPfETuRA0hc=; b=EJw1ts9GdeZFpv4TB6YY4QGO8iOPoMkhDA1NfOGzLusDlZ5Wg8ym4f3q9wrFVMeZRO YvX77b3zVpKS8FrXDKeAd0ZJhMmGi78KWaqsw0+vF8iSPz6+ByQ9mPofc93PmHx59lQQ GXXr8i+CFGthQQxXgQ/feMKqNo9k1IBL75kSL2kU6WmOR8VYeu2p84rfssNHMv+dlGqy eCdaTN/fLD9ebLSVx3j0cs6qp3AHXu0x4RBs95xdXBVUpoRetN9pL/JLt/xYX3WIrfiZ X11UzCNOUybepnx59jHiHXMZyip9aC4OjdalYPSRzXMlehsYk7gRkJgfq3GxQayQhaxf YkPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=g70KB5NXKdaKW1Od+1/8BX7/yDYNCTEsiPfETuRA0hc=; b=l+1xILZ6oijh28PndgIba0HDj0lnhu5/mNtMeficEpY1864qAqow08KozarUcy9WPe vTTXc4KlUsomUJFJnN9t23MS1MUCRPoCZx9ZUB/qGf8ks3GZJy97dc3qXCJz0Su9Svtz F2d9lC6v6o8/DICDyj/E0ld50zGTMzFA/Q2oEQTJKKeqOQsNilUzrUz4v9XykFU3TUAC l6xL5m3cLFqxIL7L9azFM4+muDSXJY5jFckQ7lI4UM88c0k4TLqiKinnOxFTwZZ3l7QR fzb5VXSnH5ZX/U4SUxI1mjd3kpZqv31VtXQBfBeBJ54nMmKkcDgVPTWUMYmMqG+2rU6a 8EzA== X-Gm-Message-State: APjAAAX8+vJYnV8rDPF/ClwrefPY1YNS+i1JhrcsBiGNRbuG/U1Usvae CbksBEqviInA08/2lWSe0Y2LL6I0sSLT/s3IpKJI3Yhj X-Google-Smtp-Source: APXvYqwTchydhmNw54biIU00eR8+GjK9ajkDXav+6/QoXM95M9UU4kAFuVdNZhRwMYwxATArqlrfLxCi1NDEEy8mazY= X-Received: by 2002:adf:dcc6:: with SMTP id x6mr73659595wrm.322.1564151124805; Fri, 26 Jul 2019 07:25:24 -0700 (PDT) MIME-Version: 1.0 References: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org> In-Reply-To: <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org> From: Sean Solberg Date: Fri, 26 Jul 2019 09:25:14 -0500 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000002b4c25058e96502f" Archived-At: Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 14:25:28 -0000 --0000000000002b4c25058e96502f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn't the whole purpose of the tag mechanism there to provide a way for the sender to tell the receiver more specifically what type the data actually is? IE) regular expression instead of just a string, URI instead of just a string, Uint8ClampedArray instead of just a Uint8Array. Even though the concept of a Uint8ClampedArray is mostly a javaScript thing as most other languages naturally are "clamping" bytes to the 0 to 255 range (because of the definition of a byte), one of the golden rules I always to try to follow is to preserve "type" as much as possible. IMHO, the lack of good data typing is one of the reasons we have problems with JSON. Having mechanisms to explicitly communicate data type from sender to receiver is one of the areas where CBOR shines. Frankly, I don't see it as any more of a security issue than any other data type tagging in CBOR. In all cases, all receivers should be coded to properly handle what data types it needs to deal with and also properly handle any situation where it receives a tag that it isn't coded to explicitly handle. ..Sean Solberg On Thu, Jul 25, 2019 at 9:06 PM Carsten Bormann wrote: > On Jul 25, 2019, at 16:36, Jeffrey Yasskin wrote: > > > > I remain > > uncomfortable with having a serialization format describe behaviors > > that the data had or should have when it was or is loaded into a > > program. > > I don=E2=80=99t know how to avoid that. If the input is an array, in mos= t generic > decoders I get an array to work from. If the input is instead a map, I g= et > a map (or a JavaScript object); that has quite different behavior. So th= e > supplier of the input already has a lot of control over the data structur= es > that are input to my system. Uint8ClampedArray just adds a slight twist = to > that as it might look too much like a Uint8Array. > None of this relieves an application of validating its input =E2=80=94 wi= th a > standard serialization format and a robust generic decoder, this can now > simply be done on a higher level. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --0000000000002b4c25058e96502f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Isn't the whole purpose of the tag mechanism ther= e to provide a way for the sender to tell the receiver more specifically wh= at type the data actually is?=C2=A0 =C2=A0IE) regular expression instead of= just a string,=C2=A0 URI instead of just a string,=C2=A0 Uint8ClampedArray= instead of just a Uint8Array.=C2=A0 =C2=A0 Even though the concept of a Ui= nt8ClampedArray is mostly a javaScript thing as most other languages natura= lly are "clamping" bytes to the 0 to 255 range (because of the de= finition of a byte), one of the golden rules I always to try to follow is t= o preserve "type" as much as possible.=C2=A0=C2=A0

=
IMHO, the lack of good data typing is one of the reasons we have= problems with JSON.=C2=A0 Having mechanisms to explicitly communicate data= type from sender to receiver is one of the areas where CBOR shines.=C2=A0 = Frankly, I don't see it as any more of a security issue than any other = data type tagging in CBOR.=C2=A0 In all cases, all receivers should be code= d to properly handle what data types it needs to deal with and also properl= y handle any situation where it receives a tag that it isn't coded to e= xplicitly handle.

..Sean Solberg

On Thu, Jul 25, 20= 19 at 9:06 PM Carsten Bormann <cabo@tzi.= org> wrote:
On Jul 25, 2019, at 16:36, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
> I remain
> uncomfortable with having a serialization format describe behaviors > that the data had or should have when it was or is loaded into a
> program.

I don=E2=80=99t know how to avoid that.=C2=A0 If the input is an array, in = most generic decoders I get an array to work from.=C2=A0 If the input is in= stead a map, I get a map (or a JavaScript object); that has quite different= behavior.=C2=A0 So the supplier of the input already has a lot of control = over the data structures that are input to my system.=C2=A0 Uint8ClampedArr= ay just adds a slight twist to that as it might look too much like a Uint8A= rray.
None of this relieves an application of validating its input =E2=80=94 with= a standard serialization format and a robust generic decoder, this can now= simply be done on a higher level.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--0000000000002b4c25058e96502f-- From nobody Mon Jul 29 07:40:49 2019 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 B47C2120127 for ; Mon, 29 Jul 2019 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 x3J_axllvasR for ; Mon, 29 Jul 2019 07:40:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DCC120124 for ; Mon, 29 Jul 2019 07:40:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Jul 2019 07:40:39 -0700 From: Jim Schaad To: Date: Mon, 29 Jul 2019 07:40:38 -0700 Message-ID: <004a01d5461b$97fba390$c7f2eab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdVGGziMTCq8pROsRbG+WQDGMgbYpg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Adoption call for CBOR Sequences X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 14:40:48 -0000 This starts a two week adoption call for draft-bormann-cbor-sequence ending 12 August 2019. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. CBOR Chairs Francesca and Jim From nobody Mon Jul 29 11:49:22 2019 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 D606112001A for ; Mon, 29 Jul 2019 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 6YmzTUs5_u45 for ; Mon, 29 Jul 2019 11:49:19 -0700 (PDT) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (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 9243F120019 for ; Mon, 29 Jul 2019 11:49:19 -0700 (PDT) Received: from [192.168.0.107] ([67.237.247.208]) by :SMTPAUTH: with ESMTPSA id sAhyhxRCfs9XUsAhyhGruo; Mon, 29 Jul 2019 11:49:19 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_C5F88E25-5DAB-408F-88B4-827818F368EF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Mon, 29 Jul 2019 11:49:18 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfEKXvVCJiFlusYdHWwEYJ/BOPhBfMjMCGf11CasHPnFsCvQfv63Uq9xDawakTUoQwMmOujRAW1z1zfww+0ilKvKzmpEQUm3kaAo1JC32OaW3b9roPE1f 4VP2PNu8HvZB5qAppeUBG1SOnJJmWJix6tutqbV+V7GPhn7vUVszmsqH Archived-At: Subject: [Cbor] List of not-well-formed CBOR and test vectors X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 18:49:21 -0000 --Apple-Mail=_C5F88E25-5DAB-408F-88B4-827818F368EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think I=E2=80=99ve made a comprehensive list of all things that are = not well formed by going through the latest draft and my decoder. There = are about a dozen of them. I=E2=80=99ve also created 110 test vectors = that cover them pretty thoroughly.=20 Everything is here = in a C header. The dozen types of = non-well-formedness are listed as comments in the header file. The test = vectors are in an array that can be used for testing. It is BSD-3 = license. I=E2=80=99ve turned up one bug in the RFC=E2=80=99s pseudo code. It = doesn=E2=80=99t catch an indefinite length string as a segment in = another indefinite length string.=20 I=E2=80=99d like to get some review, some folks to try it out and such = to see if I=E2=80=99ve missed anything and all is right. When that is = done I=E2=80=99ll make a pull request for the draft out it. Probably in = about two weeks. So please look it over and try it against your implementation. LL --Apple-Mail=_C5F88E25-5DAB-408F-88B4-827818F368EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think I=E2=80=99ve = made a comprehensive list of all things that are not well formed by = going through the latest draft and my decoder. There are about a dozen = of them. I=E2=80=99ve also created 110 test vectors that cover them = pretty thoroughly. 

Everything is here in a C header. The = dozen types of non-well-formedness are listed as comments in the header = file. The test vectors are in an array that can be used for testing. It = is BSD-3 license.

I=E2=80=99ve turned up one bug in the RFC=E2=80= =99s pseudo code. It doesn=E2=80=99t catch an indefinite length string = as a segment in another indefinite length string. 

I=E2=80=99d like to get = some review, some folks to try it out and such to see if I=E2=80=99ve = missed anything and all is right. When that is done I=E2=80=99ll make a = pull request for the draft out it. Probably in about two = weeks.

So = please look it over and try it against your implementation.

LL

= --Apple-Mail=_C5F88E25-5DAB-408F-88B4-827818F368EF-- From nobody Mon Jul 29 12:24:53 2019 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 0243E120026 for ; Mon, 29 Jul 2019 12:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 zwmvdDHaBfy5 for ; Mon, 29 Jul 2019 12:24:49 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 3E66E120025 for ; Mon, 29 Jul 2019 12:24:49 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2019 12:24:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,324,1559545200"; d="scan'208";a="182865813" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 29 Jul 2019 12:24:48 -0700 Received: from tjmaciei-mobl1.localnet (10.54.75.14) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 29 Jul 2019 12:24:47 -0700 From: Thiago Macieira To: CC: Laurence Lundblade Date: Mon, 29 Jul 2019 12:24:47 -0700 Message-ID: <9430055.7DLcDZMovz@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.54.75.14] Archived-At: Subject: Re: [Cbor] List of not-well-formed CBOR and test vectors X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 19:24:51 -0000 On Monday, 29 July 2019 11:49:18 PDT Laurence Lundblade wrote: > I think I=E2=80=99ve made a comprehensive list of all things that are not= well > formed by going through the latest draft and my decoder. There are about a > dozen of them. I=E2=80=99ve also created 110 test vectors that cover them= pretty > thoroughly. >=20 > Everything is here > ell_formed_cbor.h> in a C header. The dozen types of non-well-formedness = are > listed as comments in the header file. The test vectors are in an array > that can be used for testing. It is BSD-3 license. >=20 > I=E2=80=99ve turned up one bug in the RFC=E2=80=99s pseudo code. It doesn= =E2=80=99t catch an > indefinite length string as a segment in another indefinite length string. >=20 > I=E2=80=99d like to get some review, some folks to try it out and such to= see if > I=E2=80=99ve missed anything and all is right. When that is done I=E2=80= =99ll make a pull > request for the draft out it. Probably in about two weeks. Hello Laurence I'll add your test vectors to TinyCBOR soon and see if there's anything I=20 didn't catch. You're welcome to do the same with my test data, see: https://github.com/intel/tinycbor/blob/dev/tests/parser/tst_parser.cpp#L153= 8-L1767 There are 194 entries in that list, though some of them are slightly duplic= ate=20 of one another. There are a couple that also test implementation limits, li= ke=20 strings bigger than half your machine's address space. Some others aren't=20 testing invalid CBOR, but common parsing mistakes like reading a size of -1= or=20 overflowing counters / pointers. Another that I came across but isn't seen in the test list was that my buff= er=20 was always followed by a NUL byte, which masked one read-past-the-end. The= =20 trick for that test is in https://github.com/intel/tinycbor/blob/dev/tests/parser/tst_parser.cpp#L159= =2DL192 which always places the data to be parsed at the end of a page, followed by= a=20 page with no read access. And if you look at https://github.com/intel/tinycbor/blob/dev/tests/parser/ tst_parser.cpp#L1796-L2155. you'll see an extensive list of strict, canonic= al=20 mode and JSON-compatibility testing. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Tue Jul 30 02:23:10 2019 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 5423B1201DD for ; Tue, 30 Jul 2019 02:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 1Onnsd09pAfc for ; Tue, 30 Jul 2019 02:23:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1091201D7 for ; Tue, 30 Jul 2019 02:23:05 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45yWLb5xHMz105P; Tue, 30 Jul 2019 11:23:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 30 Jul 2019 11:23:03 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 586171381.503354-e6a30237c7fdcd350a288f4d226fea48 Content-Transfer-Encoding: quoted-printable Message-Id: <39259861-43D9-4498-A2F5-E07DBC998CA6@tzi.org> References: To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] List of not-well-formed CBOR and test vectors X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 09:23:09 -0000 > I think I=E2=80=99ve made a comprehensive list of all things that are = not well formed by going through the latest draft and my decoder. There = are about a dozen of them. I=E2=80=99ve also created 110 test vectors = that cover them pretty thoroughly.=20 Nice! I actually find 111 vectors there. =20 If I run these through the (slightly instrumented) pseudocode of the = appendix, I get: 2 SHORT 10 FINITE 14 SHORT 1 BREAK 14 SHORT 7 BREAK 2 RESIDUAL 25 SIMPLE 4 INDEF 4 SHORT 24 AI 2 SHORT 2 BREAK Where: - SHORT =3D premature EOF - RESIDUAL =3D data remaining after decoding 1 AI =3D reserved AI 2 SIMPLE =3D impermissible coding of simple value 3 FINITE =3D indefinite inside indefinite length string 4 BREAK =3D break stop code outside indefinite length item or as map = value 5 INDEF =3D wrong major type for indefinite length (The numbers in this list enumerate the calls to =E2=80=9Cfail()=E2=80=9D = in the pseudocode in the appendix.) Why are you testing only 25 of the 32 impermissible SIMPLE cases? Gr=C3=BC=C3=9Fe, Carsten PS: These test vectors base64url-encoded in JSON: [ "X0EA", "f2EA", "X2EA_w", "f0EA_w", "XwD_", "XyH_", "X4D_", "X6D_", "X8AA_w", "X-D_", "X19BAP__", "f39hAP__", "gQ", "ggA", "mgH_AA", "oQ", "ogEC", "nw", "nwEC", "vw", "vwECAQI", "n4AA", "gZ8", "gYGBgYGBgYGB", "n5-fn5______", "n4GfgZ-f____", "n4KfgZ-f_____w", "GA", "GQ", "Gg", "Gw", "GQE", "GgEC", "GwECAwQFBgc", "OA", "WA", "eA", "mA", "uA", "2A", "-A", "gf8", "ggD_", "of8", "of8A", "oQD_", "ogAA_w", "_w", "gP8", "n___", "-AA", "-AE", "-AI", "-AM", "-AQ", "-AU", "-AY", "-Ac", "-Ag", "-Ak", "-Ao", "-As", "-Aw", "-A0", "-A4", "-A8", "-BA", "-BE", "-BI", "-BM", "-BQ", "-BU", "-BY", "-Bc", "-Bg", "Hw", "Pw", "3wA", "3w", "QQ", "YQ", "Wv____8A", "ev____8A", "HA", "HQ", "Hg", "PA", "PQ", "Pg", "XA", "XQ", "Xg", "fA", "fQ", "fg", "nA", "nQ", "ng", "vA", "vQ", "vg", "3A", "3Q", "3g", "_A", "_Q", "_g", "oQA", "ogAAAA", "vwD_", "vwAAAP8" ] From nobody Tue Jul 30 10:42:14 2019 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 3F6EA1202BA for ; Tue, 30 Jul 2019 10:42: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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2J_xyEejf_3Z for ; Tue, 30 Jul 2019 10:42:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729F512029E for ; Tue, 30 Jul 2019 10:42:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F06EF3808A for ; Tue, 30 Jul 2019 13:41:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 78695980 for ; Tue, 30 Jul 2019 13:42:08 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: <004a01d5461b$97fba390$c7f2eab0$@augustcellars.com> References: <004a01d5461b$97fba390$c7f2eab0$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Adoption call for CBOR Sequences X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 17:42:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: > This starts a two week adoption call for draft-bormann-cbor-sequence > ending 12 August 2019. > This document describes the Concise Binary Object Representation (CBO= R) > Sequence format and associated media type "application/cbor-seq". A > CBOR Sequence consists of any number of encoded CBOR data items, simp= ly > concatenated in sequence. I have read the document, and I agree with adopting it. I think that the document is pretty much done actually. A few missing articles perhaps. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1AgXAACgkQgItw+93Q 3WUjoQgAh+dG4z9zBub+c7RSzVgVR6j+O4W59asoNPapeAzGNWhhPkG6Z0lCNzPZ PwZJLwFhE4EzPqDpnhE7TPGzbIvXq0a3md6lSI/V1K0I3Vg6+4G3ZGEajEEgy6+Q neOtCFs+kER5codVxMB3XrbUYSqW9Mv/mzscxRyvjcs3zpAeDK4DpBQJR7aW5r9/ fc4cEi5ihsgdopZIOUImKADAfyM0NuMS4XQBvkLId+CYG+3BxIlFSORVOg1vju36 N1Gs8tNGEfsBssH7unN+DL43FYaRxEYjdjgvS7Ae+n7SZaP4wmJFaUHagyQV7DSQ K3kjYt9AVKg6nKzYL/JuhsEJsenkPQ== =II30 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 30 15:26:23 2019 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 5D30F120072 for ; Tue, 30 Jul 2019 15:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 8Xh_-EdvmIQV for ; Tue, 30 Jul 2019 15:26:21 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [205.237.194.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08825120043 for ; Tue, 30 Jul 2019 15:26:21 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5B6E82753F for ; Tue, 30 Jul 2019 18:26:18 -0400 (EDT) To: cbor@ietf.org References: <004a01d5461b$97fba390$c7f2eab0$@augustcellars.com> From: Sean Leonard Message-ID: Date: Tue, 30 Jul 2019 15:25:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <004a01d5461b$97fba390$c7f2eab0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: Re: [Cbor] Adoption call for CBOR Sequences X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 22:26:22 -0000 I support adoption of this draft. The document already describes the advantages (just concatenate together = easy) and disadvantages (no end-of-sequence indicator, and if a data item is corrupted then it is not possible to reliably decode the rest of the sequence) of its approach, which is good. I believe that the document should point out alternate ways to encode sequences (without specifying them, just naming/identifying alternate approaches). Sean On 7/29/2019 7:40 AM, Jim Schaad wrote: > This starts a two week adoption call for draft-bormann-cbor-sequence ending > 12 August 2019. > > This document describes the Concise Binary Object Representation (CBOR) > Sequence format and associated media type "application/cbor-seq". A CBOR > Sequence consists of any number of encoded CBOR data items, simply > concatenated in sequence. > > CBOR Chairs > Francesca and Jim > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 31 20:01:21 2019 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 B8A8F12010C for ; Wed, 31 Jul 2019 20:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Wh29wSc0nj3U for ; Wed, 31 Jul 2019 20:01:18 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (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 317DE1200C4 for ; Wed, 31 Jul 2019 20:01:18 -0700 (PDT) Received: from [10.12.100.152] ([66.228.17.5]) by :SMTPAUTH: with ESMTPSA id t1LAhOj64xKQ1t1LBhaykW; Wed, 31 Jul 2019 20:01:17 -0700 From: Laurence Lundblade Message-Id: <9592F4F7-2008-4770-8FB4-54BD39191EFE@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_14B3E25E-47E8-448C-A7C1-C35DAE978978" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 31 Jul 2019 20:01:16 -0700 In-Reply-To: <39259861-43D9-4498-A2F5-E07DBC998CA6@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <39259861-43D9-4498-A2F5-E07DBC998CA6@tzi.org> X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfGi8BTNGN6WyxjyeGAsxEid5GLAeMLnKXYQFTMMwEQgmyVTr9FCi/ChN99bfcWFtLpsk269nAS3eQN1qt9hZzBeJ+Y8L6kVL29HRsRBdCpvG9F8wfbsJ swEYJDmcG/huefRPjTaD1p9XIpKv4Nj8D6XDh/MPoqg0QbEru1mxfk46UW1IQsLgy4RJ/D498musBQ== Archived-At: Subject: [Cbor] Simple values 24..31 (was Re: List of not-well-formed CBOR and test vectors) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:01:20 -0000 --Apple-Mail=_14B3E25E-47E8-448C-A7C1-C35DAE978978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 30, 2019, at 2:23 AM, Carsten Bormann wrote: >=20 > Why are you testing only 25 of the 32 impermissible SIMPLE cases? Because I=E2=80=99m confused about unassigned vs reserved in this table = (just realized I was confused): +---------+-----------------+ | Value | Semantics | +---------+-----------------+ | 0..19 | (Unassigned) | | | | | 20 | False | | | | | 21 | True | | | | | 22 | Null | | | | | 23 | Undefined value | | | | | 24..31 | (Reserved) | | | | | 32..255 | (Unassigned) | +---------+-----------------+ Neither sections 7.1 nor 9.2 mention 24..31.=20 These of course can=E2=80=99t be represented by the single byte 0xf8 = through 0xff because those are float and such, but there seems to be no = trouble representing the with 0xf8 0x18 through 0xf8 0x1f. Why wouldn=E2=80=99t 24 through 255 be considered unassigned and encoded = 0xf8 0x18 through 0xf8 0xff? LL --Apple-Mail=_14B3E25E-47E8-448C-A7C1-C35DAE978978 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 30, 2019, at 2:23 AM, Carsten Bormann <cabo@tzi.org> wrote:

Why are you testing only 25 of = the 32 impermissible SIMPLE cases?

Because I=E2=80=99m confused about unassigned = vs reserved in this table (just realized I was confused):

                       =
+---------+-----------------+
                       | Value   | Semantics       |
                       +---------+-----------------+
                       | 0..19   | (Unassigned)    |
                       |         |                 |
                       | 20      | False           |
                       |         |                 |
                       | 21      | True            |
                       |         |                 |
                       | 22      | Null            |
                       |         |                 |
                       | 23      | Undefined value |
                       |         |                 |
                       | 24..31  | (Reserved)      |
                       |         |                 |
                       | 32..255 | (Unassigned)    |
                       +---------+-----------------+

Neither = sections 7.1 nor 9.2 mention 24..31. 

These of course can=E2=80=99t be = represented by the single byte 0xf8 through 0xff because those are float = and such, but there seems to be no trouble representing the with 0xf8 = 0x18 through 0xf8 0x1f.

Why wouldn=E2=80=99t 24 through 255 be considered unassigned = and encoded 0xf8 0x18 through 0xf8 0xff?

LL

= --Apple-Mail=_14B3E25E-47E8-448C-A7C1-C35DAE978978-- From nobody Wed Jul 31 23:52:58 2019 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 7FD2E120075 for ; Wed, 31 Jul 2019 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 RCqyjeAvHjvi for ; Wed, 31 Jul 2019 23:52:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77635120058 for ; Wed, 31 Jul 2019 23:52:54 -0700 (PDT) Received: from client-0111.vpn.uni-bremen.de (client-0111.vpn.uni-bremen.de [134.102.107.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45zgwN4kWzz10cf; Thu, 1 Aug 2019 08:52:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <9592F4F7-2008-4770-8FB4-54BD39191EFE@island-resort.com> Date: Thu, 1 Aug 2019 08:52:52 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 586335170.3400559-d1ec78a58c25f602ea12425540b6152c Content-Transfer-Encoding: quoted-printable Message-Id: <6CE31BD8-FA1C-4E5E-B55D-50EFFDCDDBE4@tzi.org> References: <39259861-43D9-4498-A2F5-E07DBC998CA6@tzi.org> <9592F4F7-2008-4770-8FB4-54BD39191EFE@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Simple values 24..31 (was Re: List of not-well-formed CBOR and test vectors) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 06:52:57 -0000 On Aug 1, 2019, at 05:01, Laurence Lundblade = wrote: >=20 > Why wouldn=E2=80=99t 24 through 255 be considered unassigned and = encoded 0xf8 0x18 through 0xf8 0xff? Because we considered those values confusing, and decided to give up on = 8 potential values in exchange for reducing this confusion. See Section = 2.3 of RFC 7049 (parenthesis in first paragraph on page 13). Whether that was a particularly wise decision can be discussed. Since = we already have to check for too-low values in the second byte of 7.24, = checking for 32 is not more onerous than checking for 24 (see = pseudocode). Giving up 8 values seems to be of limited concern given = the number of allocations of Simple values so far. Changing this now, = however, would be a backward compatibility issue that we need to avoid. Gr=C3=BC=C3=9Fe, Carsten