From nobody Thu Mar 1 11:47:52 2018 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 E7CAE12F4D8 for ; Thu, 1 Mar 2018 11:47:50 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (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 w6jAVf5FC6R9 for ; Thu, 1 Mar 2018 11:47:49 -0800 (PST) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 325DA12F4CF for ; Thu, 1 Mar 2018 11:47:49 -0800 (PST) Received: by mail-pl0-x234.google.com with SMTP id m22-v6so740689pls.5 for ; Thu, 01 Mar 2018 11:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UjKQ8sjbovRN5um6pfV6XZ0Jt78KvtaVQk4Z9ZtHnFQ=; b=ILEITUlDrI+lX4RzMBtxkNzvCCuC4EEtVaAnpZEfS8bD7KSxIo9VBLIAmZKW78Nq+k pb6bPG0j2gkvXZksOK4v2GpKmYqqMEDQaVw/r6JfmYBV//zWyba/FzKSTm7+/LIZ3E+p Fwhp5m9UjnoL1PQUYPohtLN9w7i5DMq5YkISX6VcAEr5Xu1qYZ20uT1q96ap1ECnC5zD KgTyULG41u2sY4dBYSIRdvG/iiNL8RtHWrIcGHhsGkNufUfpbKgDqLNERF3EvbfNgkdt dAY3RnVc2MO3H6oZBP0qo++EUiod7B1Cz6qOYDU6GfJc5hv6cZQktKs/7q4KdKeVROWp oqqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UjKQ8sjbovRN5um6pfV6XZ0Jt78KvtaVQk4Z9ZtHnFQ=; b=f0zJpUlT9UZruoTmbRwUBRrk4j5fMWpSD6mpKcJElFKYcDFTS0CgJtH+WTpUW3U5q+ tSOLGH4lfeZsnKjRMsnWCfR/jxh7dSQZIj/xALm4kkH/5TQieEffi/LT8qaLkU4Vh4kE uFK4WJzmoVIf+Wvv1GHbWqoWttnLV73rxAHtLbdWML3Kzi2s0g4BUfkFrYxVneg1fsGt djImLwIrQVKW7mIhTyGH0o2VU6872Yx4juFsXFDwRMTm0m6qmmsiueBY20cQd15YWaZC 7UG47hRRMMrj8ZVWzyJkT6gizAg6fKzc5Kg53LpuoHsU00yUZNOb/cyGvaIwkclgUNGq Qebg== X-Gm-Message-State: APf1xPAkAyFqQrBbkdyZibDJ/ynYKeDS2pTthv/eNhniOupkPPJXHhQ7 OZdfD5gjXLLeLxSMX4rxSw1X020tSAg= X-Google-Smtp-Source: AG47ELtPFYJyd+1IZcXNhwV7x0Lgxff2yu8TjCnzsjKsViWtEcNXNxbFNpAUZJ1QmxgztbCx1toEAg== X-Received: by 2002:a17:902:3a1:: with SMTP id d30-v6mr2846648pld.409.1519933668508; Thu, 01 Mar 2018 11:47:48 -0800 (PST) Received: from [192.168.43.75] ([118.148.131.111]) by smtp.gmail.com with ESMTPSA id 7sm10133188pft.84.2018.03.01.11.47.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 11:47:47 -0800 (PST) Sender: Brian Carpenter To: cbor@ietf.org References: From: Brian E Carpenter Message-ID: <6fc9b634-5694-13b1-e447-dedfb96e5e3d@gmail.com> Date: Fri, 2 Mar 2018 08:23:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 19:47:51 -0000 Hi, As far as I'm concerned this draft is ready. That is a pragmatic view; it works for my requirements, but there are many features I haven't used. Regards Brian Carpenter On 27/02/2018 21:28, Francesca Palombini wrote: > Dear CBOR WG, >=20 > As discussed during the past IETF meetings, and after the last updates,= the CDDL draft is ready for WGLC.=20 >=20 > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02=20 >=20 > The WGLC will end by *13th of March*, please make sure to send your com= ments to the list before then.=20 >=20 > Best regards, > Francesca & Joe >=20 >> -----Original Message----- >> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann= >> Sent: den 26 februari 2018 21:46 >> To: cbor@ietf.org >> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >> >> We have submitted draft-ietf-cbor-cddl-02.txt: >> >> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >> >> Diff from previous version at: >> >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >> >> We believe that this is now ready for WGLC. >> (If we can start it quickly, the results of the call will be in for di= scussion in >> London.) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> 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 >=20 From nobody Thu Mar 1 13:47:54 2018 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 26D1012FAC2 for ; Thu, 1 Mar 2018 13:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 2HmHWh-eXsLi for ; Thu, 1 Mar 2018 13:47:51 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 4D85212FAB8 for ; Thu, 1 Mar 2018 13:47:51 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id q24so8718463ioh.8 for ; Thu, 01 Mar 2018 13:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1WYS81K8Wce8ofdmlIh9KhbwnspBDHcq3qQQBP6uR38=; b=RGzv82jlEtMfJe9taQl1OBuE9xkRZNfJVGmuaZ3tMT2/btNx3x9PO6/iUimiIfcQ/O 4oNZrHtmvDIqcwPyoeq7BnN+22pawrq81iJ5lBrlu5JwfO1ehF5UHH//9VeR7Ziap4/5 tdlrK53Y+BQf4z/6W//DCxrvbD3Ux4hwSYDNA= 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=1WYS81K8Wce8ofdmlIh9KhbwnspBDHcq3qQQBP6uR38=; b=Wv31hxhr/KvkEzD5UqPpeoU+ORofr4cgfIHBfigg1JjEk6VPJYDt/Quru4N4Yw4Ayf 7er5XEZQHORXJytn8QM50diJ43LrNZbIA99MxxZs4f0oysN1Hh8GB16kYia8EPFs3jAH 3WwdXAl4SP4ELpy/dhBx5P4Pn8iQn1thH/o9u8kfJZKYJx0ee1/oeKTXKRyL+/Md/ATl oqZ6vDlsmaAe/x7E4flT7HXK6jbopHKoIPElEg/2J37VyqQClNnlRXA4OtK43MjIPHzR 7UajtkXkbzShG/hAgM89qTQk199ur8zsl1vVrKwcBIaVw5IqchONZlrbJg+YkAGzdH1G Bcww== X-Gm-Message-State: APf1xPCDS0qdSAHSnaJ6j8xzExiyC7wZWxelZvg6d0On+OHlCB8vD+JO 7FzNX/1dQVN5ecTLWE/wkrMImxktasKgkXK82qN7hQ== X-Google-Smtp-Source: AG47ELuxIWi1z++WvgEzWsLDZOfEV2v4kNGixN4duimgbAoxTQ2gK9MDKXS6SaVBElWmbmD8jv7pKG4widpOr2XboRY= X-Received: by 10.107.192.2 with SMTP id q2mr4015677iof.112.1519940870174; Thu, 01 Mar 2018 13:47:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 01 Mar 2018 21:47:37 +0000 Message-ID: To: Francesca Palombini Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a114f74c4a62d1b056660cf38" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 21:47:53 -0000 --001a114f74c4a62d1b056660cf38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't re-reviewed this draft fully, but I think an issue I'd sent directly to Carsten is still present: if a map key type is specified with both a cut and an occurrence indicator, and the occurrence indicator is saturated, do subsequent keys matching the type fall back to later entries? For example, does: { "a": 3 "b": "cow" } match { ? tstr ^ =3D> int any =3D> any } ? I think it shouldn't, but I don't see a collection of sentences in the specification that specifies it. Jeffrey On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Dear CBOR WG, > > As discussed during the past IETF meetings, and after the last updates, > the CDDL draft is ready for WGLC. > > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 > > The WGLC will end by *13th of March*, please make sure to send your > comments to the list before then. > > Best regards, > Francesca & Joe > > > -----Original Message----- > > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann > > Sent: den 26 februari 2018 21:46 > > To: cbor@ietf.org > > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt > > > > We have submitted draft-ietf-cbor-cddl-02.txt: > > > > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 > > > > Diff from previous version at: > > > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt > > > > We believe that this is now ready for WGLC. > > (If we can start it quickly, the results of the call will be in for > discussion in > > London.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > 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 > --001a114f74c4a62d1b056660cf38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I haven't re-reviewed this draft fully, but I think an= issue I'd sent directly to Carsten is still present: if a map key type= is specified with both a cut and an occurrence indicator, and the occurren= ce indicator is saturated, do subsequent keys matching the type fall back t= o later entries? For example, does:

{
=C2=A0 &= quot;a": 3
=C2=A0 "b": "cow"
}=

match

{
=C2=A0= ? tstr ^ =3D> int
=C2=A0 any =3D> any
}

? I think it shouldn't, but I don't see a collecti= on of sentences in the specification that specifies it.

Jeffrey



=
On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini <<= a href=3D"mailto:francesca.palombini@ericsson.com">francesca.palombini@eric= sson.com> wrote:
Dear CBOR W= G,

As discussed during the past IETF meetings, and after the last updates, the= CDDL draft is ready for WGLC.

https://tools.ietf.org/html/draft-ietf-cbor-cddl-= 02

The WGLC will end by *13th of March*, please make sure to send your comment= s to the list before then.

Best regards,
Francesca & Joe

> -----Original Message-----
> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: den 26 februari 2018 21:46
> To: cbor@ietf.org
> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt
>
> We have submitted draft-ietf-cbor-cddl-02.txt:
>
> https://tools.ietf.org/html/draft-ietf-cbor-= cddl-02
>
> Diff from previous version at:
>
> https://tools.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-cbor-cddl-02.txt
>
> We believe that this is now ready for WGLC.
> (If we can start it quickly, the results of the call will be in for di= scussion in
> London.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> 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
--001a114f74c4a62d1b056660cf38-- From nobody Fri Mar 2 14:22:05 2018 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 4C7191250B8; Fri, 2 Mar 2018 14:22:04 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152002932428.8377.17657489395896486699@ietfa.amsl.com> Date: Fri, 02 Mar 2018 14:22:04 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-02.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 22:22:04 -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-02.txt Pages : 62 Date : 2018-03-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. 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-02 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 Fri Mar 2 14:30:05 2018 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 85CEB1250B8 for ; Fri, 2 Mar 2018 14:30:04 -0800 (PST) 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] 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 BIT7bhmPCdN1 for ; Fri, 2 Mar 2018 14:30:03 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 CD5BC12D876 for ; Fri, 2 Mar 2018 14:29:56 -0800 (PST) Received: from [10.32.60.132] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w22MTSre042824 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Mar 2018 15:29:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.132] From: "Paul Hoffman" To: cbor@ietf.org Date: Fri, 02 Mar 2018 14:29:54 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <6A0F9869-1623-4E85-B46C-B746D20E6428@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [Cbor] New draft-ietf-cbor-7049bis-02.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 22:30:04 -0000 Greetings. From the diff at https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-02 you can see that the big changes are: - The addition of Section 2 on data models - Pointing out that some tags extend the new data model - An explicit discussion of equivalence of keys in 4.7.1 - Major updates to "canonical CBOR" in 4.9 If you want to discuss any of these (and you should!), please start a new thread about the specific topic. Reply to this message will just be a mess... --Paul Hoffman From nobody Sat Mar 3 00:07:45 2018 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 DFA1B127077 for ; Sat, 3 Mar 2018 00:07:44 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8L__sBgE9aXE for ; Sat, 3 Mar 2018 00:07:42 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1211F120454 for ; Sat, 3 Mar 2018 00:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2387aiP014582; Sat, 3 Mar 2018 09:07:36 +0100 (CET) Received: from [10.128.6.67] (unknown [188.135.13.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ztf0m1yS1zDXfh; Sat, 3 Mar 2018 09:07:36 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-9D5F24C9-2FAA-4C12-9B86-6801CBF2DA06 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Sat, 3 Mar 2018 12:06:52 +0400 Cc: Francesca Palombini , cbor@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> References: To: Jeffrey Yasskin Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 08:07:45 -0000 --Apple-Mail-9D5F24C9-2FAA-4C12-9B86-6801CBF2DA06 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (typing this from a mobile device) Hi Jeffrey, I do believe that the current matching rules indeed saturate the optional gr= oup entry, so the cut does not apply to any additional members. I think tha= t is exactly as it should be. The requirements you seem to be expressing are= probably better solved by limiting the wildcard instead. Can you be more sp= ecific about your use case? Sent from mobile > On 2. Mar 2018, at 01:47, Jeffrey Yasskin wrote: >=20 > I haven't re-reviewed this draft fully, but I think an issue I'd sent dire= ctly to Carsten is still present: if a map key type is specified with both a= cut and an occurrence indicator, and the occurrence indicator is saturated,= do subsequent keys matching the type fall back to later entries? For exampl= e, does: >=20 > { > "a": 3 > "b": "cow" > } >=20 > match >=20 > { > ? tstr ^ =3D> int > any =3D> any > } >=20 > ? I think it shouldn't, but I don't see a collection of sentences in the s= pecification that specifies it. >=20 > Jeffrey >=20 >=20 >=20 >> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini wrote: >> Dear CBOR WG, >>=20 >> As discussed during the past IETF meetings, and after the last updates, t= he CDDL draft is ready for WGLC. >>=20 >> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>=20 >> The WGLC will end by *13th of March*, please make sure to send your comme= nts to the list before then. >>=20 >> Best regards, >> Francesca & Joe >>=20 >> > -----Original Message----- >> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann >> > Sent: den 26 februari 2018 21:46 >> > To: cbor@ietf.org >> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >> > >> > We have submitted draft-ietf-cbor-cddl-02.txt: >> > >> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >> > >> > Diff from previous version at: >> > >> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >> > >> > We believe that this is now ready for WGLC. >> > (If we can start it quickly, the results of the call will be in for dis= cussion in >> > London.) >> > >> > Gr=C3=BC=C3=9Fe, Carsten >> > >> > _______________________________________________ >> > CBOR mailing list >> > CBOR@ietf.org >> > https://www.ietf.org/mailman/listinfo/cbor >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail-9D5F24C9-2FAA-4C12-9B86-6801CBF2DA06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable (typing this from a mobile device)

=
Hi Jeffrey,

I do believe that the curren= t matching rules indeed saturate the optional group entry, so the cut does n= ot apply to any additional members.  I think that is exactly as it shou= ld be. The requirements you seem to be expressing are probably better solved= by limiting the wildcard instead. Can you be more specific about your use c= ase?

Sent from mobile

On 2. Mar 2018, at 01:47, Jeffrey= Yasskin <jyasskin@chromium.org<= /a>> wrote:

= I haven't re-reviewed this draft fully, but I think an issue I'd sent direct= ly to Carsten is still present: if a map key type is specified with both a c= ut and an occurrence indicator, and the occurrence indicator is saturated, d= o subsequent keys matching the type fall back to later entries? For example,= does:

{
  "a": 3
  "b": "c= ow"
}

match

{
  ? tstr ^ =3D> int
  any =3D> any
}

? I think it shouldn't, but I don't see a coll= ection of sentences in the specification that specifies it.

Jeffrey



Dear CBOR WG,=

As discussed during the past IETF meetings, and after the last updates, the C= DDL draft is ready for WGLC.

https://tools.ietf.org/html/draft-ietf-cbor-cddl-02=

The WGLC will end by *13th of March*, please make sure to send your comments= to the list before then.

Best regards,
Francesca & Joe

> -----Original Message-----
> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: den 26 februari 2018 21:46
> To: cbor@ietf.org
> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt
>
> We have submitted draft-ietf-cbor-cddl-02.txt:
>
> https://tools.ietf.org/html/draft-ietf-cbor-cd= dl-02
>
> Diff from previous version at:
>
> https://tools.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-cbor-cddl-02.txt
>
> We believe that this is now ready for WGLC.
> (If we can start it quickly, the results of the call will be in for dis= cussion in
> London.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
____________________= ___________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman= /listinfo/cbor
= --Apple-Mail-9D5F24C9-2FAA-4C12-9B86-6801CBF2DA06-- From nobody Sat Mar 3 08:13:32 2018 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 930A6124234 for ; Sat, 3 Mar 2018 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 l4BJwqbTh8iT for ; Sat, 3 Mar 2018 08:13:28 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 A09AD1200B9 for ; Sat, 3 Mar 2018 08:13:28 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id m22so13640777iob.12 for ; Sat, 03 Mar 2018 08:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4F9islmaEMz2jM8nsNkivMT6nM88JCprdo7gohK4XNw=; b=POvQ2DK0kV5ScdiZfFQs0zigmUY8QDsw7EV9rfmKbtPJR1T74n1YLGp7DMAr9lfAHU MkqkHk9ZndymqPxTlNf305JmvXOpeBz+bpNUXqEeIMuK+fxFWHW6uoidBcRqVBHYdRR9 IuG1va8q1l9rSe4PvsiH1CeeW9h4Xu5epusn4= 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=4F9islmaEMz2jM8nsNkivMT6nM88JCprdo7gohK4XNw=; b=rMArXTzXkYfWtm4ao9OZjdpcICQpykEDpRc2tIvszTi8mT/6/w7wWFRCl3vDZZqOHh EsxCD15b68o06Alm/YMPC9idEakdi6l1C0XOksDOapDlfc5zWN/i3mrOg7p56oIiCnyS SsNLIY95tLWD+U+EFgQM9RDzeY7Efvt2pawIvuNYf0dDSpSBM64TeAkjoZHGZY0kEozo d/Fk8oySguj1d3Cg2HQpGEgYEktPTCaLgd96JPRRb4UCBUyizKzoPJkomXR9VqQV2YHp t2b8miBwDX5pIJRufj5csbkqNDKf6e1U11qm87T7msnk8wPhTrCi3mzAHUwxkIY5O1CC hEaQ== X-Gm-Message-State: AElRT7HsxjwSDqCtnN2FmkN1wawZs7BK6v32gvpvYjaTB0oxAS0rjglC +FynERyYwjoKoPuD0mXxwtLVt1Z1P0K1Thuhxg4tiQ== X-Google-Smtp-Source: AG47ELulY98FlS/e/o4Yuu6By/GP8SShAiR27oY8g5vRJsI1oMz0G9RV4qEjnNJssoLtgpidXH1safN2E+DkfOlmsOo= X-Received: by 10.107.62.134 with SMTP id l128mr11030854ioa.199.1520093607382; Sat, 03 Mar 2018 08:13:27 -0800 (PST) MIME-Version: 1.0 References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> In-Reply-To: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> From: Jeffrey Yasskin Date: Sat, 03 Mar 2018 16:13:14 +0000 Message-ID: To: Carsten Bormann Cc: Jeffrey Yasskin , Francesca Palombini , cbor@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06143e7f16a80566845ff9" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:13:30 -0000 --94eb2c06143e7f16a80566845ff9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have a particular use case in mind, so if you prefer to ignore the cut after its occurrences are saturated, that's fine. Which sentences in the specification specify that? Thanks, Jeffrey On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann wrote: > (typing this from a mobile device) > > Hi Jeffrey, > > I do believe that the current matching rules indeed saturate the optional > group entry, so the cut does not apply to any additional members. I thin= k > that is exactly as it should be. The requirements you seem to be expressi= ng > are probably better solved by limiting the wildcard instead. Can you be > more specific about your use case? > > Sent from mobile > > On 2. Mar 2018, at 01:47, Jeffrey Yasskin wrote: > > I haven't re-reviewed this draft fully, but I think an issue I'd sent > directly to Carsten is still present: if a map key type is specified with > both a cut and an occurrence indicator, and the occurrence indicator is > saturated, do subsequent keys matching the type fall back to later entrie= s? > For example, does: > > { > "a": 3 > "b": "cow" > } > > match > > { > ? tstr ^ =3D> int > any =3D> any > } > > ? I think it shouldn't, but I don't see a collection of sentences in the > specification that specifies it. > > Jeffrey > > > > On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini < > francesca.palombini@ericsson.com> wrote: > >> Dear CBOR WG, >> >> As discussed during the past IETF meetings, and after the last updates, >> the CDDL draft is ready for WGLC. >> >> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >> >> The WGLC will end by *13th of March*, please make sure to send your >> comments to the list before then. >> >> Best regards, >> Francesca & Joe >> >> > -----Original Message----- >> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bormann >> > Sent: den 26 februari 2018 21:46 >> > To: cbor@ietf.org >> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >> > >> > We have submitted draft-ietf-cbor-cddl-02.txt: >> > >> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >> > >> > Diff from previous version at: >> > >> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >> > >> > We believe that this is now ready for WGLC. >> > (If we can start it quickly, the results of the call will be in for >> discussion in >> > London.) >> > >> > Gr=C3=BC=C3=9Fe, Carsten >> > >> > _______________________________________________ >> > CBOR mailing list >> > CBOR@ietf.org >> > https://www.ietf.org/mailman/listinfo/cbor >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > --94eb2c06143e7f16a80566845ff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have a particular use case in mind, so if you= prefer to ignore the cut after its occurrences are saturated, that's f= ine. Which sentences in the specification specify that?
Thanks,
Jeffrey

On Sat, Mar 3, 2018, 12:07= AM Carsten Bormann <cabo@tzi.org>= ; wrote:
(typing = this from a mobile device)

Hi Jeffrey,

I do believe that the current matching rules indeed saturate the op= tional group entry, so the cut does not apply to any additional members.=C2= =A0 I think that is exactly as it should be. The requirements you seem to b= e expressing are probably better solved by limiting the wildcard instead. C= an you be more specific about your use case?

Sent from=C2=A0mobile

On 2. Mar 2018, at 01:47, Jeffrey Yasskin <= jyasskin@chromium.org> wrote:

I haven't re-reviewed this draft fully, but I= think an issue I'd sent directly to Carsten is still present: if a map= key type is specified with both a cut and an occurrence indicator, and the= occurrence indicator is saturated, do subsequent keys matching the type fa= ll back to later entries? For example, does:

{
=C2=A0 "a": 3
=C2=A0 "b": "cow"
}

match

{
=C2=A0 ? tstr ^ =3D> int
=C2=A0 any =3D> any
}=

? I think it shouldn't, but I don't see a= collection of sentences in the specification that specifies it.
=
Jeffrey



On Tue, Feb 27, 2018 at 12:28 AM Francesca Palomb= ini <francesca.palombini@ericsson.com> wrote:
Dear CBOR WG,

As discussed during the past IETF meetings, and after the last updates, the= CDDL draft is ready for WGLC.

https://tools.ietf.org/html/draft-ietf= -cbor-cddl-02

The WGLC will end by *13th of March*, please make sure to send your comment= s to the list before then.

Best regards,
Francesca & Joe

> -----Original Message-----
> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten = Bormann
> Sent: den 26 februari 2018 21:46
> To: cbor@ietf.org
> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt
>
> We have submitted draft-ietf-cbor-cddl-02.txt:
>
> https://tools.ietf.org/html/draft= -ietf-cbor-cddl-02
>
> Diff from previous version at:
>
> https://tools.ietf.= org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt
>
> We believe that this is now ready for WGLC.
> (If we can start it quickly, the results of the call will be in for di= scussion in
> London.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> 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<= br>
___________________= ____________________________
CBOR mailing list
C= BOR@ietf.org
https://www.ietf.org/mail= man/listinfo/cbor
--94eb2c06143e7f16a80566845ff9-- From nobody Sat Mar 3 10:52:20 2018 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 3115A126CD6 for ; Sat, 3 Mar 2018 10:52:18 -0800 (PST) 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, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 cKEi07xagJq3 for ; Sat, 3 Mar 2018 10:52:15 -0800 (PST) Received: from smtp.macieira.info (arvernien.macieira.info [209.222.10.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2198312D969 for ; Sat, 3 Mar 2018 10:52:10 -0800 (PST) Received: from tjmaciei-mobl1.localnet (unknown [IPv6:2601:1c0:4501:5f9f:613f:c8cf:bd67:22b5]) by smtp.macieira.info (Postfix) with ESMTPSA id 85641991B for ; Sat, 3 Mar 2018 10:52:08 -0800 (PST) From: Thiago Macieira To: cbor@ietf.org Date: Sat, 03 Mar 2018 10:52:01 -0800 Message-ID: <2378172.bP1g1HZ8tr@tjmaciei-mobl1> Organization: Intel Corporation MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] 7049bis-02: Equivalence of CBOR data items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 18:52:18 -0000 Hello all This is my first post to the mailing list. I am the author and maintainer o= f=20 TinyCBOR[1] and I have prepared a set of wrapper classes for introduction i= nto=20 Qt[2] adding support for CBOR[3]. =46irst of all, thanks for addressing some of the uncertain areas of RFC 70= 49.=20 Specifically, the part about key equivalence and sorting. I've read through= =20 the previous thread that discussed this and I agree with some of the poster= s=20 there. In any case, let's start with the "Canonical CBOR" part. This is the part I= =20 like. It says that keys in a canonical map must be sorted by their bytewise=20 canonical representation. In other words, it suffices to memcmp() two keys'= =20 canonical encoding to determine whether one should be sorted before the oth= er,=20 even for strings. For those who, like me, want to sort before encoding, the= =20 current draft has these advantages: 1) two keys of different types can be sorted by type alone, ignoring paylo= ad This is important because in the internal implementation's data model, befo= re=20 encoding, the data could be stored in a fashion that makes comparing differ= ent=20 payloads difficult. It is my case. 2) unsigned numbers have the same order in both memcmp and payload Because of the big-endian representation and the way that CBOR 8-, 16-, 32-= =20 and 64-bit numbers (unsigned integers, lengths and tags) are represented,=20 given two unsigned integers a and b, if a < b, then a is sorted before b=20 bytewise too. 3) string comparison is still memcmp But not strcmp. However, once the sorting by length is done, memcmp can be= =20 used. 4) confirming a proper sorting order is easy for any decoder Since all keys are in bytewise lexicographical order, if the decoder memcmp= ()=20 two adjacent keys, the result should be positive. Any other value is a=20 violation of CBOR canonical encoding. Please note this does not guarantee=20 uniqueness of keys (see below). So in order to sort keys in a map before generating the encoding, one only = has=20 to be careful about negative numbers, where a < b =E2=86=92 a sorts after b= (sort by=20 absolute value) and floating point. For floating point, the suggested way t= o=20 compare would be to memcpy the value to an integer of the same size and=20 compare that. Moving on to the "Equivalence of keys" section, which I don't like too much= =20 (i.e., it needs improving). This section makes the comparison of a data ite= m=20 when used as a key different from when simply comparing items in, say, an=20 array. Unless it is intentional that the following two arrays should compar= e=20 equal: [h'4d 41 3d 3d'] and [34("MA=3D=3D")] Note I'm not talking just yet about using those arrays as keys. I'm merely= =20 asking if an implementation holding each of them should report that the two= =20 arrays are equal. I assume not. Consequently, we cannot use the same code to check uniqueness of map keys a= s=20 the function used to sort items when placing them in a map. By the rules in= =20 the section of "Equivalence of keys", the two arrays above are equivalent a= nd=20 therefore both must not appear at the same time in the same map. Is that intentional? If it is, I believe my classes would have the following functionality: 1) strict data item comparison Uses the rules for core canonical requirements, by: a) comparing the type b) for floating point, attempt down-conversion to fp16 and float,=20 then memcpy to a 16-, 32- or 64-bit unsigned integer c) comparing the number (unsigned integer, absolute of negative, etc.) d) for strings, memcmp the byte representation [My code currently does not compare an integer equal to a floating point of= =20 the same value] 2) data item equivalence I'm uncertain how I want to implement this. I don't want to perform=20 recursive equivalence check in arrays -- that is to say, two arrays are= =20 equivalent if and only if they are actually the same. I'd be tempted to= =20 say the same for maps used as keys too, as implementing that equivalenc= e=20 would require an O(n=C2=B2) algorithm, since even a map sorted by keys = could=20 have alternate representations of the same equivalent value and they do= n't=20 need to be adjacent, as in a map with the three keys h'41', h'42' and "= A". [1] https://github.com/intel/tinycbor [2] https://qt.io [3] https://codereview.qt-project.org/#/q/project:qt/qtbase+topic:cbor,n,z =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Sat Mar 3 18:05:01 2018 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 53E2A126C83 for ; Sat, 3 Mar 2018 18:05:00 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTacbkc8tSW0 for ; Sat, 3 Mar 2018 18:04:58 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEFA1200C1 for ; Sat, 3 Mar 2018 18:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2424qM5017796; Sun, 4 Mar 2018 03:04:52 +0100 (CET) Received: from [10.128.6.67] (unknown [188.135.13.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zv5vQ0BpQzDXlp; Sun, 4 Mar 2018 03:04:34 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-476DC080-D4BA-40F0-882B-13792A08CA8D Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Sun, 4 Mar 2018 06:04:29 +0400 Cc: Francesca Palombini , cbor@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> To: Jeffrey Yasskin Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 02:05:00 -0000 --Apple-Mail-476DC080-D4BA-40F0-882B-13792A08CA8D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can't point to a specific sentence, but for a cut to be effective, the mat= ch needs to occur first, and in this case the whole entry says that can only= happen once.=20 Sent from mobile > On 3. Mar 2018, at 20:13, Jeffrey Yasskin wrote: >=20 > I don't have a particular use case in mind, so if you prefer to ignore the= cut after its occurrences are saturated, that's fine. Which sentences in th= e specification specify that? >=20 > Thanks, > Jeffrey >=20 >> On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann wrote: >> (typing this from a mobile device) >>=20 >> Hi Jeffrey, >>=20 >> I do believe that the current matching rules indeed saturate the optional= group entry, so the cut does not apply to any additional members. I think t= hat is exactly as it should be. The requirements you seem to be expressing a= re probably better solved by limiting the wildcard instead. Can you be more s= pecific about your use case? >>=20 >> Sent from mobile >>=20 >>> On 2. Mar 2018, at 01:47, Jeffrey Yasskin wrote:= >>>=20 >>> I haven't re-reviewed this draft fully, but I think an issue I'd sent di= rectly to Carsten is still present: if a map key type is specified with both= a cut and an occurrence indicator, and the occurrence indicator is saturate= d, do subsequent keys matching the type fall back to later entries? For exam= ple, does: >>>=20 >>> { >>> "a": 3 >>> "b": "cow" >>> } >>>=20 >>> match >>>=20 >>> { >>> ? tstr ^ =3D> int >>> any =3D> any >>> } >>>=20 >>> ? I think it shouldn't, but I don't see a collection of sentences in the= specification that specifies it. >>>=20 >>> Jeffrey >>>=20 >>>=20 >>>=20 >>>> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini wrote: >>>> Dear CBOR WG, >>>>=20 >>>> As discussed during the past IETF meetings, and after the last updates,= the CDDL draft is ready for WGLC. >>>>=20 >>>> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>>>=20 >>>> The WGLC will end by *13th of March*, please make sure to send your com= ments to the list before then. >>>>=20 >>>> Best regards, >>>> Francesca & Joe >>>>=20 >>>> > -----Original Message----- >>>> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Borman= n >>>> > Sent: den 26 februari 2018 21:46 >>>> > To: cbor@ietf.org >>>> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >>>> > >>>> > We have submitted draft-ietf-cbor-cddl-02.txt: >>>> > >>>> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>>> > >>>> > Diff from previous version at: >>>> > >>>> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >>>> > >>>> > We believe that this is now ready for WGLC. >>>> > (If we can start it quickly, the results of the call will be in for d= iscussion in >>>> > London.) >>>> > >>>> > Gr=C3=BC=C3=9Fe, Carsten >>>> > >>>> > _______________________________________________ >>>> > CBOR mailing list >>>> > CBOR@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/cbor >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail-476DC080-D4BA-40F0-882B-13792A08CA8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can't point to a specific sentence, but f= or a cut to be effective, the match needs to occur first, and in this case t= he whole entry says that can only happen once. 

Sent from mobile=

On 3. Mar 2018, at 20:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:

=
I don't have a particular u= se case in mind, so if you prefer to ignore the cut after its occurrences ar= e saturated, that's fine. Which sentences in the specification specify that?=

Thanks,
Jeffrey

On Sat, M= ar 3, 2018, 12:07 AM Carsten Bormann <cab= o@tzi.org> wrote:
(typing this from a mobile device)

Hi Jeffrey,

I do believe that the current matching rules indeed sat= urate the optional group entry, so the cut does not apply to any additional m= embers.  I think that is exactly as it should be. The requirements you s= eem to be expressing are probably better solved by limiting the wildcard ins= tead. Can you be more specific about your use case?

Sent from mobile

On 2. Mar 2018, at 01:47, Jeffrey Yasskin &= lt;jyasskin@chromium.org> wrote:

I haven't re-reviewed this draft fully, but I thi= nk an issue I'd sent directly to Carsten is still present: if a map key type= is specified with both a cut and an occurrence indicator, and the occurrenc= e indicator is saturated, do subsequent keys matching the type fall back to l= ater entries? For example, does:

{
  "a": 3=
  "b": "cow"
}

match

{
  ? tstr ^ =3D> int
 = ; any =3D> any
}

? I think it shouldn'= t, but I don't see a collection of sentences in the specification that speci= fies it.

Jeffrey



=
On Tue, Feb 27, 2018 at 12:28 AM= Francesca Palombini <francesca.palombini@ericsson.com&g= t; wrote:
Dear CBOR WG,

As discussed during the past IETF meetings, and after the last updates, the C= DDL draft is ready for WGLC.

https://tools.ietf.org/html/draft-ietf-c= bor-cddl-02

The WGLC will end by *13th of March*, please make sure to send your comments= to the list before then.

Best regards,
Francesca & Joe

> -----Original Message-----
> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Bo= rmann
> Sent: den 26 februari 2018 21:46
> To: cbor@ietf.org
> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt
>
> We have submitted draft-ietf-cbor-cddl-02.txt:
>
> https://tools.ietf.org/html/draft-i= etf-cbor-cddl-02
>
> Diff from previous version at:
>
> https://tools.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt
>
> We believe that this is now ready for WGLC.
> (If we can start it quickly, the results of the call will be in for dis= cussion in
> London.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> CBOR mailing list
> C= BOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________
CBOR mailing list
CBOR@i= etf.org
https://www.ietf.org/mailman/listinfo/cbor
____________________= ___________________________
CBOR mailing list
CBOR= @ietf.org
https://www.ietf.org/mailman/l= istinfo/cbor
____________________= ___________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman= /listinfo/cbor
= --Apple-Mail-476DC080-D4BA-40F0-882B-13792A08CA8D-- From nobody Sun Mar 4 15:12:53 2018 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 20AC3126C25 for ; Sun, 4 Mar 2018 15:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 g-xrasK6cl7e for ; Sun, 4 Mar 2018 15:12:49 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 5C960126CC7 for ; Sun, 4 Mar 2018 15:12:49 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id n128so7352278ith.1 for ; Sun, 04 Mar 2018 15:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xQNqq4GL+5+nzPmMPwTACgPtKu2JvpupurhsUUDMQw0=; b=htCRjRV+44BkqOzj+BHwwgzNpNTULGgepuneVRJOrfF4vPqhnlohEcL/Ax0q/vlJFV 78LA82BuPDEagetpotm+BHR5lGGhH92AoBLlMxcfHlcXVU7mfUm/0cACMzDwAZAEpeqA PJETLuNNrELa60s5N1JryQrDAjzZHUuWP6h3I= 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=xQNqq4GL+5+nzPmMPwTACgPtKu2JvpupurhsUUDMQw0=; b=OGckrKgkF6hodAcHv6sDqjhNdtSJWPw4V9JtLV8l9NOPMiPGMRCAtjCack8kjLgD2B 0VNWm6mABjFbfVUI3imYe2SHBtH0uGJznwj1I4u49k8BnFlHI7xs+sud9e6REbvpOMXV gI5XaU/ECsRpWKySheNnPhXCku4ITkRGz1XvlhOj46vkSLw2Kb0dpKIdtF5cUfvisFyx IGxJ6ApYwD3f1x71T/IyfZ8SoyHHereXHXPOh5xyy29RaukEN68Q1J0JImBkJ+axrT5y NCB3La4iYoIEXeqiv9wZYbhJlzAedTUwzqsyRKbOnWUrbj8VGZBf8YHPuFFMefmYmWJW FjGw== X-Gm-Message-State: AElRT7Ekot2qgrYft8J0ZzD86JwywS0H8ddNA+I22W2DCCz13oieGjjE 1uhKBDaO4vZV56Ngqc6oLb3dH8G/87D5DucoiG0Xvi0mVkU= X-Google-Smtp-Source: AG47ELu9iKPvBQbUKCKYrj+TXAKycXCzsqIixbuBjegXMKJ2zRQQjrvl9pvjGqn3O8w8JcD1r3WpQQTwQ/jAuObVjFo= X-Received: by 10.36.36.144 with SMTP id f138mr11008024ita.131.1520205168357; Sun, 04 Mar 2018 15:12:48 -0800 (PST) MIME-Version: 1.0 References: <2378172.bP1g1HZ8tr@tjmaciei-mobl1> In-Reply-To: <2378172.bP1g1HZ8tr@tjmaciei-mobl1> From: Jeffrey Yasskin Date: Sun, 04 Mar 2018 23:12:35 +0000 Message-ID: To: thiago.macieira@intel.com Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a1147cd300c35bd05669e59ed" Archived-At: Subject: Re: [Cbor] 7049bis-02: Equivalence of CBOR data items X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:12:52 -0000 --001a1147cd300c35bd05669e59ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that https://github.com/cbor-wg/CBORbis/pull/11 needed some more work before merging. It's inconsistent with https://tools.ietf.org/html/draft-ietf-cbor-7049bis-02#section-2, which states that "integer and floating-point values are distinct in this model, even if they have the same numeric value." https://tools.ietf.org/html/draft-ietf-cbor-7049bis-02#section-2.2 provides a way to refine map equivalence for particular applications, by saying "Specific data models can also specify that values of different types are equivalent for the purposes of map keys and encoder freedom." It goes on to directly contradict https://tools.ietf.org/html/draft-ietf-cbor-7049bis-02#section-4.7.1: "a valid map MAY have both "0" and "0.0" as keys, =E2=80=A6". This isn't particularly the PR author's fault: those bits of the data model were added by https://github.com/cbor-wg/CBORbis/pull/12, which was merged the same day as #11. When I sent #12, I probably should have reviewed #11 to point out the conflicts. Jeffrey On Sat, Mar 3, 2018 at 10:52 AM Thiago Macieira wrote: > Hello all > > This is my first post to the mailing list. I am the author and maintainer > of > TinyCBOR[1] and I have prepared a set of wrapper classes for introduction > into > Qt[2] adding support for CBOR[3]. > > First of all, thanks for addressing some of the uncertain areas of RFC > 7049. > Specifically, the part about key equivalence and sorting. I've read throu= gh > the previous thread that discussed this and I agree with some of the > posters > there. > > In any case, let's start with the "Canonical CBOR" part. This is the part= I > like. > > It says that keys in a canonical map must be sorted by their bytewise > canonical representation. In other words, it suffices to memcmp() two key= s' > canonical encoding to determine whether one should be sorted before the > other, > even for strings. For those who, like me, want to sort before encoding, t= he > current draft has these advantages: > > 1) two keys of different types can be sorted by type alone, ignoring > payload > This is important because in the internal implementation's data model, > before > encoding, the data could be stored in a fashion that makes comparing > different > payloads difficult. It is my case. > > 2) unsigned numbers have the same order in both memcmp and payload > Because of the big-endian representation and the way that CBOR 8-, 16-, 3= 2- > and 64-bit numbers (unsigned integers, lengths and tags) are represented, > given two unsigned integers a and b, if a < b, then a is sorted before b > bytewise too. > > 3) string comparison is still memcmp > But not strcmp. However, once the sorting by length is done, memcmp can b= e > used. > > 4) confirming a proper sorting order is easy for any decoder > Since all keys are in bytewise lexicographical order, if the decoder > memcmp() > two adjacent keys, the result should be positive. Any other value is a > violation of CBOR canonical encoding. Please note this does not guarantee > uniqueness of keys (see below). > > So in order to sort keys in a map before generating the encoding, one onl= y > has > to be careful about negative numbers, where a < b =E2=86=92 a sorts after= b (sort > by > absolute value) and floating point. For floating point, the suggested way > to > compare would be to memcpy the value to an integer of the same size and > compare that. > > > Moving on to the "Equivalence of keys" section, which I don't like too mu= ch > (i.e., it needs improving). This section makes the comparison of a data > item > when used as a key different from when simply comparing items in, say, an > array. Unless it is intentional that the following two arrays should > compare > equal: > > [h'4d 41 3d 3d'] and [34("MA=3D=3D")] > > Note I'm not talking just yet about using those arrays as keys. I'm merel= y > asking if an implementation holding each of them should report that the t= wo > arrays are equal. I assume not. > > Consequently, we cannot use the same code to check uniqueness of map keys > as > the function used to sort items when placing them in a map. By the rules = in > the section of "Equivalence of keys", the two arrays above are equivalent > and > therefore both must not appear at the same time in the same map. > > Is that intentional? > > If it is, I believe my classes would have the following functionality: > > 1) strict data item comparison > Uses the rules for core canonical requirements, by: > a) comparing the type > b) for floating point, attempt down-conversion to fp16 and float, > then memcpy to a 16-, 32- or 64-bit unsigned integer > c) comparing the number (unsigned integer, absolute of negative, etc= .) > d) for strings, memcmp the byte representation > [My code currently does not compare an integer equal to a floating point = of > the same value] > > 2) data item equivalence > I'm uncertain how I want to implement this. I don't want to perform > recursive equivalence check in arrays -- that is to say, two arrays a= re > equivalent if and only if they are actually the same. I'd be tempted = to > say the same for maps used as keys too, as implementing that > equivalence > would require an O(n=C2=B2) algorithm, since even a map sorted by key= s could > have alternate representations of the same equivalent value and they > don't > need to be adjacent, as in a map with the three keys h'41', h'42' and > "A". > > > [1] https://github.com/intel/tinycbor > [2] https://qt.io > [3] https://codereview.qt-project.org/#/q/project:qt/qtbase+topic:cbor,n,= z > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --001a1147cd300c35bd05669e59ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that=C2=A0https://github.com/cbor-wg/CBORbis/pull/11 needed some m= ore work before merging. It's inconsistent with=C2=A0https://tools.ie= tf.org/html/draft-ietf-cbor-7049bis-02#section-2, which states that &qu= ot;integer and floating-point values are distinct in this model, even if th= ey have the same numeric value."=C2=A0https://tools.ietf.org/html/= draft-ietf-cbor-7049bis-02#section-2.2 provides a way to refine map equ= ivalence for particular applications, by saying "Specific data models = can also specify that values of different types are equivalent for the purp= oses of map keys and encoder freedom." It goes on to directly contradi= ct=C2=A0https://tools.ietf.org/html/draft-ietf-cbor-7049bis-02#sectio= n-4.7.1:=C2=A0"a valid map MAY have both "0" and "0= .0" as keys, =E2=80=A6".

This isn't particularly the P= R author's fault: those bits of the data model were added by=C2=A0https://github.com/cbor-w= g/CBORbis/pull/12, which was merged the same day as #11. When I sent #12,=C2=A0I probably should have reviewed = #11 to point out the conflicts.

Jeffrey

On Sat, Mar 3, 2018 at 10:52 AM Thi= ago Macieira <thiago.macieira@intel.com> wrote:
Hello all

This is my first post to the mailing list. I am the author and maintainer o= f
TinyCBOR[1] and I have prepared a set of wrapper classes for introduction i= nto
Qt[2] adding support for CBOR[3].

First of all, thanks for addressing some of the uncertain areas of RFC 7049= .
Specifically, the part about key equivalence and sorting. I've read thr= ough
the previous thread that discussed this and I agree with some of the poster= s
there.

In any case, let's start with the "Canonical CBOR" part. This= is the part I
like.

It says that keys in a canonical map must be sorted by their bytewise
canonical representation. In other words, it suffices to memcmp() two keys&= #39;
canonical encoding to determine whether one should be sorted before the oth= er,
even for strings. For those who, like me, want to sort before encoding, the=
current draft has these advantages:

=C2=A01) two keys of different types can be sorted by type alone, ignoring = payload
This is important because in the internal implementation's data model, = before
encoding, the data could be stored in a fashion that makes comparing differ= ent
payloads difficult. It is my case.

=C2=A02) unsigned numbers have the same order in both memcmp and payload Because of the big-endian representation and the way that CBOR 8-, 16-, 32-=
and 64-bit numbers (unsigned integers, lengths and tags) are represented, given two unsigned integers a and b, if a < b, then a is sorted before b=
bytewise too.

=C2=A03) string comparison is still memcmp
But not strcmp. However, once the sorting by length is done, memcmp can be<= br> used.

=C2=A04) confirming a proper sorting order is easy for any decoder
Since all keys are in bytewise lexicographical order, if the decoder memcmp= ()
two adjacent keys, the result should be positive. Any other value is a
violation of CBOR canonical encoding. Please note this does not guarantee uniqueness of keys (see below).

So in order to sort keys in a map before generating the encoding, one only = has
to be careful about negative numbers, where a < b =E2=86=92 a sorts afte= r b (sort by
absolute value) and floating point. For floating point, the suggested way t= o
compare would be to memcpy the value to an integer of the same size and
compare that.


Moving on to the "Equivalence of keys" section, which I don't= like too much
(i.e., it needs improving). This section makes the comparison of a data ite= m
when used as a key different from when simply comparing items in, say, an array. Unless it is intentional that the following two arrays should compar= e
equal:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [h'4d 41 3d 3d']=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[34("MA=3D=3D")]

Note I'm not talking just yet about using those arrays as keys. I'm= merely
asking if an implementation holding each of them should report that the two=
arrays are equal. I assume not.

Consequently, we cannot use the same code to check uniqueness of map keys a= s
the function used to sort items when placing them in a map. By the rules in=
the section of "Equivalence of keys", the two arrays above are eq= uivalent and
therefore both must not appear at the same time in the same map.

Is that intentional?

If it is, I believe my classes would have the following functionality:

=C2=A01) strict data item comparison
=C2=A0 =C2=A0 =C2=A0Uses the rules for core canonical requirements, by:
=C2=A0 =C2=A0 =C2=A0a) comparing the type
=C2=A0 =C2=A0 =C2=A0b) for floating point, attempt down-conversion to fp16 = and float,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then memcpy to a 16-, 32- or 64-bit unsig= ned integer
=C2=A0 =C2=A0 =C2=A0c) comparing the number (unsigned integer, absolute of = negative, etc.)
=C2=A0 =C2=A0 =C2=A0d) for strings, memcmp the byte representation
[My code currently does not compare an integer equal to a floating point of=
the same value]

=C2=A0 2) data item equivalence
=C2=A0 =C2=A0 I'm uncertain how I want to implement this. I don't w= ant to perform
=C2=A0 =C2=A0 recursive equivalence check in arrays -- that is to say, two = arrays are
=C2=A0 =C2=A0 equivalent if and only if they are actually the same. I'd= be tempted to
=C2=A0 =C2=A0 say the same for maps used as keys too, as implementing that = equivalence
=C2=A0 =C2=A0 would require an O(n=C2=B2) algorithm, since even a map sorte= d by keys could
=C2=A0 =C2=A0 have alternate representations of the same equivalent value a= nd they don't
=C2=A0 =C2=A0 need to be adjacent, as in a map with the three keys h'41= ', h'42' and "A".


[1] https://github.com/intel/tinycbor
[2] https://= qt.io
[3] https://codereview.qt-proj= ect.org/#/q/project:qt/qtbase+topic:cbor,n,z
--
Thiago Macieira - thiago.macieira (AT) intel.com
=C2=A0 Software Architect - Intel Open Source Technology Center



_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--001a1147cd300c35bd05669e59ed-- From nobody Sun Mar 4 18:23:29 2018 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 8C2CD124C27; Sun, 4 Mar 2018 18:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JFLCRf9v3hJW; Sun, 4 Mar 2018 18:23:26 -0800 (PST) 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 0B9B4124B0A; Sun, 4 Mar 2018 18:23:26 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 4 Mar 2018 18:21:32 -0800 From: Jim Schaad To: CC: Date: Sun, 4 Mar 2018 18:23:15 -0800 Message-ID: <020a01d3b428$ecc7e090$c657a1b0$@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: AdO0KJMl6gpjNTxRTUeo8sVobuhlMw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Equivalence of integers and floating point numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 02:23:27 -0000 I applaud the fact that the data model states that floating point numbers and integer numbers are not equivalent. I believe that this is the correct statement for a number of reasons. I do not understand why when comparing keys the same statement of equivalence is not being used. It says that An integer value encoded as a floating point data item is equivalent to the same value encoded as an integer I believe that this statement needs to be reversed so that they are not equivalent. Jim From nobody Sun Mar 4 18:33:07 2018 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 0B270129C53; Sun, 4 Mar 2018 18:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cY8EGv5oS-oW; Sun, 4 Mar 2018 18:32:58 -0800 (PST) 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 690BF1273B1; Sun, 4 Mar 2018 18:32:58 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 4 Mar 2018 18:31:07 -0800 From: Jim Schaad To: , References: In-Reply-To: Date: Sun, 4 Mar 2018 18:32:50 -0800 Message-ID: <020b01d3b42a$430e8ed0$c92bac70$@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: AdO0KJMl6gpjNTxRTUeo8sVobuhlMwAAJIQg X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] FW: Equivalence of integers and floating point numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 02:33:05 -0000 I guess I should have finished reading the section before sending the mail. The type of the keys should be required to be equivalent in order for the keys to be equivalent as a general rule. This is because that is what the data model has stated. I believe that key equivalence should be stated in terms of data model having the same value. Otherwise you end up with a situation where the data model means one thing for values and a different thing for keys. This seems to me to be a bad idea. I have no real issue with the question of things like equivalence of definite length items vs non-definite length items, but depending on what you use as the key value, i.e. use a canonical encoding as the key, then these types of things fall out. I have no real issue with the idea of ignoring tags. This seems to me to be something that is bad practice and should be avoided anyway. Ignoring tags would seem to potentially be an issue, if you do not do data model comparisons. Based on the current text I would have 1 and BigNumber(1) being the same key as they have the same value once the tag is removed. Jim -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, March 4, 2018 6:23 PM To: 'draft-ietf-cbor-7049bis@ietf.org' Cc: 'cbor@ietf.org' Subject: Equivalence of integers and floating point numbers I applaud the fact that the data model states that floating point numbers and integer numbers are not equivalent. I believe that this is the correct statement for a number of reasons. I do not understand why when comparing keys the same statement of equivalence is not being used. It says that An integer value encoded as a floating point data item is equivalent to the same value encoded as an integer I believe that this statement needs to be reversed so that they are not equivalent. Jim From nobody Sun Mar 4 20:14:10 2018 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 4B771126C83; Sun, 4 Mar 2018 20:14:09 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 2sVohXHI2GjM; Sun, 4 Mar 2018 20:14:07 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DB0126C3D; Sun, 4 Mar 2018 20:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w254DR72017383; Mon, 5 Mar 2018 05:13:28 +0100 (CET) Received: from [10.128.6.67] (unknown [188.135.13.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zvmjg5Hh2zDWMW; Mon, 5 Mar 2018 05:13:27 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-F5573550-810B-47F3-8C12-0D4B7059374E Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: <020a01d3b428$ecc7e090$c657a1b0$@augustcellars.com> Date: Mon, 5 Mar 2018 08:13:25 +0400 Cc: draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <73E1AF46-BC52-408C-939E-D2FE0BEF92F7@tzi.org> References: <020a01d3b428$ecc7e090$c657a1b0$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [Cbor] Equivalence of integers and floating point numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 04:14:09 -0000 --Apple-Mail-F5573550-810B-47F3-8C12-0D4B7059374E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The major environment that cannot distinguish integers from floats, JavaScri= pt, also cannot use either as keys for the most basic kind of map (called Ob= ject in JavaScript). So I currently believe there is little downside to incr= easing the separation between int and float. (Applications may still want to= give encoders the liberty to convert floats that happen to have an integer v= alue into int -- just not when int is simultaneously used as a map key with d= ifferent semantics.) Sent from mobile > On 5. Mar 2018, at 06:23, Jim Schaad wrote: >=20 > I applaud the fact that the data model states that floating point numbers > and integer numbers are not equivalent. I believe that this is the > correct statement for a number of reasons. >=20 > I do not understand why when comparing keys the same statement of > equivalence is not being used. It says that=20 >=20 > An integer value encoded as a floating point data item is > equivalent to the same value encoded as an integer >=20 > I believe that this statement needs to be reversed so that they are not > equivalent. >=20 > Jim >=20 >=20 >=20 --Apple-Mail-F5573550-810B-47F3-8C12-0D4B7059374E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The major environment that cannot distingui= sh integers from floats, JavaScript, also cannot use either as keys for the m= ost basic kind of map (called Object in JavaScript). So I currently believe t= here is little downside to increasing the separation between int and float. (= Applications may still want to give encoders the liberty to convert floats t= hat happen to have an integer value into int -- just not when int is simulta= neously used as a map key with different semantics.)

Sent from mobile=

On 5. Mar 2018, at 06:23, Jim Schaad <ietf@augustcellars.com> wrote:

I applaud the fact that the data model sta= tes that floating point numbers
and integer numbers are not e= quivalent.    I believe that this is the
corr= ect statement for a number of reasons.

I do= not understand why when comparing keys the same statement of
equivalence is not being used.  It says that
=
   An integer value encoded as a floating point data it= em is
equivalent to the same value encoded as an integer

I believe that this statement needs to be reve= rsed so that they are not
equivalent.

Jim



=
= --Apple-Mail-F5573550-810B-47F3-8C12-0D4B7059374E-- From nobody Sun Mar 4 20:31:59 2018 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 22061126C19; Sun, 4 Mar 2018 20:31:57 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3XIZeB_Ksl4P; Sun, 4 Mar 2018 20:31:55 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694BA12426E; Sun, 4 Mar 2018 20:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w254VF6o004400; Mon, 5 Mar 2018 05:31:15 +0100 (CET) Received: from [10.128.6.67] (unknown [188.135.13.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zvn6C13kJzDWMb; Mon, 5 Mar 2018 05:31:15 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-5A7A4869-665B-4295-B75C-A188D7109615 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: <020b01d3b42a$430e8ed0$c92bac70$@augustcellars.com> Date: Mon, 5 Mar 2018 08:31:11 +0400 Cc: cbor@ietf.org, draft-ietf-cbor-7049bis@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <020b01d3b42a$430e8ed0$c92bac70$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [Cbor] Equivalence of integers and floating point numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 04:31:57 -0000 --Apple-Mail-5A7A4869-665B-4295-B75C-A188D7109615 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable "Ignoring tags" means different things to different people. The way this phr= ase has mostly been used, it would mean interpreting a bignum 1 as a byte st= ring. Fully interpreting bignum value in a decoder is to be encouraged. The= re probably needs to be done security considerations about toctou.=20 Sent from mobile > On 5. Mar 2018, at 06:32, Jim Schaad wrote: >=20 > I guess I should have finished reading the section before sending the mail= . >=20 > The type of the keys should be required to be equivalent in order for the > keys to be equivalent as a general rule. This is because that is what the= > data model has stated. I believe that key equivalence should be stated i= n > terms of data model having the same value. Otherwise you end up with a > situation where the data model means one thing for values and a different > thing for keys. This seems to me to be a bad idea. >=20 > I have no real issue with the question of things like equivalence of > definite length items vs non-definite length items, but depending on what > you use as the key value, i.e. use a canonical encoding as the key, then > these types of things fall out. =20 >=20 > I have no real issue with the idea of ignoring tags. This seems to me to b= e > something that is bad practice and should be avoided anyway. >=20 > Ignoring tags would seem to potentially be an issue, if you do not do data= > model comparisons. Based on the current text I would have 1 and > BigNumber(1) being the same key as they have the same value once the tag i= s > removed. =20 >=20 > Jim >=20 >=20 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com]=20 > Sent: Sunday, March 4, 2018 6:23 PM > To: 'draft-ietf-cbor-7049bis@ietf.org' > Cc: 'cbor@ietf.org' > Subject: Equivalence of integers and floating point numbers >=20 > I applaud the fact that the data model states that floating point numbers > and integer numbers are not equivalent. I believe that this is the > correct statement for a number of reasons. >=20 > I do not understand why when comparing keys the same statement of > equivalence is not being used. It says that=20 >=20 > An integer value encoded as a floating point data item is > equivalent to the same value encoded as an integer >=20 > I believe that this statement needs to be reversed so that they are not > equivalent. >=20 > Jim >=20 >=20 >=20 --Apple-Mail-5A7A4869-665B-4295-B75C-A188D7109615 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Ignoring tags" means different things to d= ifferent people. The way this phrase has mostly been used, it would mean int= erpreting a bignum 1 as a byte string. Fully interpreting bignum value in a d= ecoder is to be encouraged.  There probably needs to be done security c= onsiderations about toctou. 

Sent= from mobile

On 5= . Mar 2018, at 06:32, Jim Schaad <ietf@augustcellars.com> wrote:

I guess I should have finished reading the section before sen= ding the mail.

The type of the keys should b= e required to be equivalent in order for the
keys to be equi= valent as a general rule.  This is because that is what the
<= span>data model has stated.   I believe that key equivalence shoul= d be stated in
terms of data model having the same value. &n= bsp;Otherwise you end up with a
situation where the data mod= el means one thing for values and a different
thing for keys= .  This seems to me to be a bad idea.

= I have no real issue with the question of things like equivalence of<= br>definite length items vs non-definite length items, but depending o= n what
you use as the key value, i.e. use a canonical encodi= ng as the key, then
these types of things fall out.  

I have no real issue with the idea of ignori= ng tags.  This seems to me to be
something that is bad p= ractice and should be avoided anyway.

Ignor= ing tags would seem to potentially be an issue, if you do not do data=
model comparisons.  Based on the current text I would have 1 a= nd
BigNumber(1) being the same key as they have the same val= ue once the tag is
removed.  
Jim


-----Original M= essage-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Sunday= , March 4, 2018 6:23 PM
To: 'draft-ietf-cbor-7049bis@ietf.org' <draft-ietf-cbor-7049bis@ietf.org&= gt;
Cc: 'cbor@ietf.org'= <cbor@ietf.org>
= Subject: Equivalence of integers and floating point numbers
=
I applaud the fact that the data model states that floating= point numbers
and integer numbers are not equivalent.  = ;  I believe that this is the
correct statement fo= r a number of reasons.

I do not understand w= hy when comparing keys the same statement of
equivalence is n= ot being used.  It says that

  &= nbsp;An integer value encoded as a floating point data item is
equivalent to the same value encoded as an integer

I believe that this statement needs to be reversed so that they a= re not
equivalent.

Jim



= = --Apple-Mail-5A7A4869-665B-4295-B75C-A188D7109615-- From nobody Sun Mar 4 20:49:14 2018 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 47F87126C89; Sun, 4 Mar 2018 20:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 eP72WhdxiwzG; Sun, 4 Mar 2018 20:49:11 -0800 (PST) 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 92CBC12426E; Sun, 4 Mar 2018 20:49:10 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 4 Mar 2018 20:47:18 -0800 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <020b01d3b42a$430e8ed0$c92bac70$@augustcellars.com> In-Reply-To: Date: Sun, 4 Mar 2018 20:49:01 -0800 Message-ID: <021001d3b43d$499bfa40$dcd3eec0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0211_01D3B3FA.3B797D90" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGexLSd33QUgMt6P2SsblkN92WScgHkIprdpBvP4WA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Equivalence of integers and floating point numbers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 04:49:13 -0000 ------=_NextPart_000_0211_01D3B3FA.3B797D90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If =E2=80=9Cignoring tags=E2=80=9D means different things to different = people, then it needs to be clarified so that everybody has the same = interpretation where ever it occurs in this document =20 Jim =20 =20 From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Sunday, March 4, 2018 8:31 PM To: Jim Schaad Cc: cbor@ietf.org; draft-ietf-cbor-7049bis@ietf.org Subject: Re: Equivalence of integers and floating point numbers =20 "Ignoring tags" means different things to different people. The way this = phrase has mostly been used, it would mean interpreting a bignum 1 as a = byte string. Fully interpreting bignum value in a decoder is to be = encouraged. There probably needs to be done security considerations = about toctou.=20 Sent from mobile On 5. Mar 2018, at 06:32, Jim Schaad > wrote: I guess I should have finished reading the section before sending the = mail. The type of the keys should be required to be equivalent in order for = the keys to be equivalent as a general rule. This is because that is what = the data model has stated. I believe that key equivalence should be stated = in terms of data model having the same value. Otherwise you end up with a situation where the data model means one thing for values and a = different thing for keys. This seems to me to be a bad idea. I have no real issue with the question of things like equivalence of definite length items vs non-definite length items, but depending on = what you use as the key value, i.e. use a canonical encoding as the key, then these types of things fall out. =20 I have no real issue with the idea of ignoring tags. This seems to me = to be something that is bad practice and should be avoided anyway. Ignoring tags would seem to potentially be an issue, if you do not do = data model comparisons. Based on the current text I would have 1 and BigNumber(1) being the same key as they have the same value once the tag = is removed. =20 Jim -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Sunday, March 4, 2018 6:23 PM To: 'draft-ietf-cbor-7049bis@ietf.org = ' = > Cc: 'cbor@ietf.org ' > Subject: Equivalence of integers and floating point numbers I applaud the fact that the data model states that floating point = numbers and integer numbers are not equivalent. I believe that this is the correct statement for a number of reasons. I do not understand why when comparing keys the same statement of equivalence is not being used. It says that=20 An integer value encoded as a floating point data item is equivalent to the same value encoded as an integer I believe that this statement needs to be reversed so that they are not equivalent. Jim ------=_NextPart_000_0211_01D3B3FA.3B797D90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

If = =E2=80=9Cignoring tags=E2=80=9D means different things to different = people, then it needs to be clarified so that everybody has the same = interpretation where ever it occurs in this document

 

Jim

 

 

From: = Carsten Bormann [mailto:cabo@tzi.org]
Sent: Sunday, March 4, = 2018 8:31 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: cbor@ietf.org; = draft-ietf-cbor-7049bis@ietf.org
Subject: Re: Equivalence of = integers and floating point numbers

 

"Ignoring tags" means different = things to different people. The way this phrase has mostly been used, it = would mean interpreting a bignum 1 as a byte string. Fully interpreting = bignum value in a decoder is to be encouraged.  There probably = needs to be done security considerations about = toctou. 

Sent from mobile


On 5. Mar 2018, at = 06:32, Jim Schaad <ietf@augustcellars.com> = wrote:

I guess I should have finished reading = the section before sending the mail.

The type of the keys should = be required to be equivalent in order for the
keys to be equivalent = as a general rule.  This is because that is what the
data model = has stated.   I believe that key equivalence should be stated = in
terms of data model having the same value.  Otherwise you end = up with a
situation where the data model means one thing for values = and a different
thing for keys.  This seems to me to be a bad = idea.

I have no real issue with the question of things like = equivalence of
definite length items vs non-definite length items, = but depending on what
you use as the key value, i.e. use a canonical = encoding as the key, then
these types of things fall out. =  

I have no real issue with the idea of ignoring tags. =  This seems to me to be
something that is bad practice and = should be avoided anyway.

Ignoring tags would seem to potentially = be an issue, if you do not do data
model comparisons.  Based on = the current text I would have 1 and
BigNumber(1) being the same key = as they have the same value once the tag is
removed. =  

Jim


-----Original Message-----
From: Jim = Schaad [mailto:ietf@augustcellars.com]=
Sent: Sunday, March 4, 2018 6:23 PM
To: 'draft-ietf-cbor-7049bis@= ietf.org' <draft-ietf-cbor-7049bis@= ietf.org>
Cc: 'cbor@ietf.org' <cbor@ietf.org>
Subject: = Equivalence of integers and floating point numbers

I applaud the = fact that the data model states that floating point numbers
and = integer numbers are not equivalent.    I believe that = this is the
correct statement for a number of reasons.

I do = not understand why when comparing keys the same statement = of
equivalence is not being used.  It says that

  =  An integer value encoded as a floating point data item = is
equivalent to the same value encoded as an integer

I = believe that this statement needs to be reversed so that they are = not
equivalent.

Jim


------=_NextPart_000_0211_01D3B3FA.3B797D90-- From nobody Sun Mar 4 21:50:53 2018 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 41881126CD6; Sun, 4 Mar 2018 21:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 abMq9TVII3-H; Sun, 4 Mar 2018 21:50:50 -0800 (PST) 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 7857A126CC4; Sun, 4 Mar 2018 21:50:50 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 4 Mar 2018 21:48:56 -0800 From: Jim Schaad To: , Date: Sun, 4 Mar 2018 21:50:39 -0800 Message-ID: <021d01d3b445$e5a4eb10$b0eec130$@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: AdO0PKssiq0Yi4xORMyzzVnW3jmV3g== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Canonical Encoding Issues X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 05:50:52 -0000 I have been spending the last two hours trying to convince myself that what I am proposing below is wrong. I have been unable to do so. If the data model had not been introduced, then I do not believe that I would have this issue. I would be more than happy to be convinced that this position is wrong, but I don't believe it can be done. The rules for canonical encoding MUST include all items which are in the data model. Those values that are in the extended data model can be deferred and left to the application as many of those decisions are going to be very context dependent. Which of the n different methods should be used for encoding a date? Not something that this document either needs or wants to get into. Implication #1 The document needs to decide on a single rule for encoding a floating point value and stick to it. I do not have a preference between rules 2 and 3, but I do have a problem with rule 1 - again this is no longer how the data model works. Implication #2 All text that deals with how to encode extended data model items, such as a date or a big number, can now be moved to a section that is dedicated to that problem. For the most part this can say that applications need to have criteria on how to do this if they need canonicalization. This section is now applicable both to the "correct" and to the "incorrect" method of doing base model canonicalization (i.e. 4.9 vs 4.9.1) Implication #3 A decision needs to be made about who is going to be best to list the set of issues for each of the extended model types that are in this document which have canonicalization issues: This document or set of random people who decide they need to do that canonicalization. I have not read the pull request to see if it covers all of the issues, canonicalization is something that I don't really believe in any more as my expectation is that people will mess it up and then all of those errors need to be dealt with. This has been the experience that doing X.509 certificates has certainly pounded into my skull. One example that I ran into today that is easily visible, but that I had not looked for, is what is the canonical text representation of a date when encoded as a string. The strings that I created and that Joe created for the interop matrix were not the same. It took me a while to figure out that this was the problem and get things checked correctly. Jim From nobody Fri Mar 9 14:53:06 2018 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 8612C12420B; Fri, 9 Mar 2018 14:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0gz5O08IYWta; Fri, 9 Mar 2018 14:53:04 -0800 (PST) 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 3592512D77E; Fri, 9 Mar 2018 14:53:04 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Mar 2018 14:50:56 -0800 From: Jim Schaad To: CC: Date: Fri, 9 Mar 2018 14:52:51 -0800 Message-ID: <000001d3b7f9$5d9d0e70$18d72b50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdO38f7YC6G++zKDT36gz1sbvvR3Ow== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review of draft-jroatch-cbor-tags -07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 22:53:05 -0000 1. I still have a preference to use a byte of the encoded field to hold the type information rather than assign lots of tags, but that is going to be what it is. 2. The language in 3.1 implies that a multi-dimension array may be of types other than TypedArray items. An example of this is in order so that it is made explicit just how it works. 3. In section 3.1 - not sure if there needs to be the ability to have column major rather than row major arrays. Fortran is not popular, but neither is it dead. 4. In section 3.2 - I assume that the element that is homogenous does not need to be a primitive type. An example of this might be useful. Interesting questions about things like 82 # array(2) 82 # array(2) F5 # true 03 # 3 82 # array(2) F5 # true 23 # -4 (I think) This would make to a C structure of but is not homogenous in terms of the CBOR encoding. 5. It would be good to tell IANA if the values that are being left open are to be available for other purposes or are reserved as a "just in case" to deal with the f=1, s=1 case of typed arrays. 6. It might be reasonable to add a security consideration about dealing with large items where the size is not known in advance. There may be problems with overflows and allocations if one is not careful. From nobody Sun Mar 11 17:39:18 2018 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 E3CDC12420B; Sun, 11 Mar 2018 17:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N-eqUB1boNf4; Sun, 11 Mar 2018 17:39:16 -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 08846124235; Sun, 11 Mar 2018 17:39:16 -0700 (PDT) Received: from Jude (79.173.164.218) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 11 Mar 2018 17:37:06 -0700 From: Jim Schaad To: CC: Date: Mon, 12 Mar 2018 00:39:06 +0000 Message-ID: <005701d3b99a$88fa17f0$9aee47d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdO5ZqcPKev5WZ3+R1+mpgJHWfRGJw== Content-Language: en-us X-Originating-IP: [79.173.164.218] Archived-At: Subject: [Cbor] Review of draft-ietf-cbor-cddl -02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 00:39:18 -0000 I wish I could say that this document was ready to roll out, but I really can't. 1. The order of presentation in 2.1 does not really highlight groups. A better order would be Figure 2, Figure 3, Figure 3a (figure is missing a label) and Figure 1. That is start by talking about the group (hey it is the major concept here isn't it) and then how to use it and then how it can be implicit. Starting w/ the implicit version makes it confusing about what a group is. 2. Talking about binding of operators would make delivery in section 2.2 a much clearer example. I first looked at this and assumed that the binding of a GROUP CHOICE would tie to a group. Thus delivery = ( street: tstr, ? number: uint, (city // po-box: uint),( city // per-pickup: true) ) city = ( name: tstr, zip-code: uint ) Which is wrong, but w/o the needed input or parentheses is not unreasonable. Just adding the parens, while cluttered, makes sense as you then know what groups are being referred to. 3. Section 3.2 - I really which that occurrences were placed at a tighter scope level than group. The current binding level produces some surprises to users that I think are not desirable. The discussion in section 3.11 should be promoted to highlight that this is going to be a problem for people. The fact that group9 = ( a / + b / c) This would seem to be very obvious, it applies only to be, but that is wrong. So have a discussion here where people are going to look for one. 4. Section 3.5 - There seems to be an order problem with cuts that needs to be clarified. Consider the following: map44 = { ? "option-key" ^ => int, * tstr => any, ? "option2-key" ^ => tstr, ? "option-key" ^=> tstr } >From the rules as I read them, option-key is restricted to being an int. This is matched in order going from top to bottom. There can never be an option-key that is a tstr because there was already an option-key label that had been processed. A good compiler would produce an error in this case. The label option2-key is never going to be matched because it was already matched with the tstr wild card before it was matched. The issue with option-key being in the list twice is going to be a potential problem where two groups accidently produce add on modules to a base module with the same label in map44. The order in which these two add on modules is processed (or if only one is processed) is going to produce different grammars that all allow for the option-key label to be present, but not cross usable because of the type issue. 5. Section 3.7 - It is not clear from the text if one should be able to apply a ~ twice to an element. The grammar does not appear to support the idea of applying a ~ to tagged value as in time. "time" is a type name and not a group name. 6. Section 3.10 - from the text I cannot tell if generics are restricted to types or if they can be used for both types and groups. 7. Section 3.11 - When "fixing" the third example, using parens makes more sense to me than using a group operator. I am not sure why group4a = ((+a) / b / c) is not one of the examples that is show. There is no reason to go to the less clear group choice operator. 8. Table 1 is missing the ~ operator. 9. I don't really understand why you made the "use with JSON" section to be part of appendix E rather than a top level appendix. Perhaps setup as --- here are the differences and then a section w/ the JSON specific standard prelude. 10. I see there are 10 Editorial Comments that have yet to be resolved. Jim From nobody Sun Mar 11 23:35:30 2018 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 49C8C1204DA; Sun, 11 Mar 2018 23:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 levUwhGF6gtq; Sun, 11 Mar 2018 23:35:28 -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 AA66D1200C5; Sun, 11 Mar 2018 23:35:27 -0700 (PDT) Received: from Jude (79.173.164.218) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 11 Mar 2018 23:33:17 -0700 From: Jim Schaad To: CC: Date: Mon, 12 Mar 2018 06:35:17 +0000 Message-ID: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdO5yy/kZ3ePj7zQSCuHgkDmpVPfeQ== Content-Language: en-us X-Originating-IP: [79.173.164.218] Archived-At: Subject: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 06:35:29 -0000 A couple of more quick comments. * In appendix B - The ANBF has grpent = [occur S] [memberkey S] type optcom / [occur S] groupname [genericarg] optcom ; preempted by above / [occur S] "(" S group S ")" optcom The last option in the rule is redundant. "(" group ")" will be reduced to a type via type2 => type1 => type so this is not needed. * Security considerations Having played around with some of the grammar and looking at things, I believe that there needs to be a security consideration around the following issue. You can really do harm to yourself when writing a grammar. There are tons of things that can be expressed that are going to lead to confusion on the part of other readers and implementers. Writing a complex grammar is going to lead to incorrect implementations. When writing down a CDDL grammar, keep it as simple as possible while still expressing the needed language. * A note needs to be added to section 3.5 on one of the dangers of using a bareword as a member name. If you are writing a grammar that is intended to be extended by having people append additional information to the current module, one can unexpectedly change the grammar when using a barewood as a new module may define the barewood as a type. (Potentially 5 levels down.) Example X = ( ipaddr : ipv6Address / ipv4Address } The next module then defines Ipaddr = [? macAddress, tstr, ipv4Address / ipv6Address] The bareword member name has now been converted into a type. Jim From nobody Mon Mar 12 00:26:21 2018 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 545D11204DA; Mon, 12 Mar 2018 00:26:19 -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] 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 eIQ4ZE30CKGK; Mon, 12 Mar 2018 00:26:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF7C1200C5; Mon, 12 Mar 2018 00:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2C7Pe8d000472; Mon, 12 Mar 2018 08:25:40 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4008fD0gSFzDWM8; Mon, 12 Mar 2018 08:25:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> Date: Mon, 12 Mar 2018 08:24:39 +0100 Cc: draft-ietf-cbor-cddl@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 542532274.725939-70caa17ea8a7614c94cb100bd785f686 Content-Transfer-Encoding: quoted-printable Message-Id: <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> References: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 07:26:19 -0000 Hi Jim, thanks for the additional comments. (I just returned from a two-week vacation and I=E2=80=99m processing = mail in a mix of SJN/LIFO.) > On Mar 12, 2018, at 07:35, Jim Schaad wrote: >=20 > A couple of more quick comments. >=20 > * In appendix B - The ANBF has=20 >=20 > grpent =3D [occur S] [memberkey S] type optcom > / [occur S] groupname [genericarg] optcom ; preempted by = above > / [occur S] "(" S group S ")" optcom >=20 > The last option in the rule is redundant. "(" group ")" will be = reduced to > a type via type2 =3D> type1 =3D> type so this is not needed. In the CDDL spec Foo =3D { ? ( k1: int, k2: bytes ) k3: float } The second line does not match the grpent=E2=80=99s first alternative = with =E2=80=9Ctype=E2=80=9D, so the third alternative for grpent is = actually needed. However, maybe it is worth pointing out in the text that the second line = in Foo =3D { ? ( Bar ) k3: float } Bar =3D (k1: int, k2: bytes) is indeed matched the way you describe; the ABNF grammar cannot always = reliably distinguish between groups and types (and any type does serve = as a keyless single-entry group anyway), so some semantic check is = needed in a tool. > * Security considerations >=20 > Having played around with some of the grammar and looking at things, I > believe that there needs to be a security consideration around the = following > issue. You can really do harm to yourself when writing a grammar. = There > are tons of things that can be expressed that are going to lead to = confusion > on the part of other readers and implementers. Writing a complex = grammar is > going to lead to incorrect implementations. When writing down a CDDL > grammar, keep it as simple as possible while still expressing the = needed > language. =20 This point indeed cannot be stressed enough. (It is rather obvious to = people who have witnessed what happens when people start speccing away = in languages like ASN.1=E2=80=A6) Just because CDDL makes it easier to = handle complexity in a specification, that does not make that complexity = somehow less bad (except on the level of the humans having to grasp the = complex structure while reading the spec). > * A note needs to be added to section 3.5 on one of the dangers of = using a > bareword as a member name. If you are writing a grammar that is = intended to > be extended by having people append additional information to the = current > module, one can unexpectedly change the grammar when using a barewood = as a > new module may define the barewood as a type. (Potentially 5 levels = down.) >=20 > Example >=20 > X =3D ( ipaddr : ipv6Address / ipv4Address } >=20 > The next module then defines >=20 > Ipaddr =3D [? macAddress, tstr, ipv4Address / ipv6Address] >=20 > The bareword member name has now been converted into a type. That is not what happens: A bareword stays a bare word, even if a rule = is added that uses the same word. Tools should probably **warn** when this happens (keep a list of = barewords that are in use, warn if any rule has the same name as the = bareword), but it is not an error exactly for the reason you point out: = unrelated use in a different part of the spec. Is there any text that should be fixed to make the intended behavior = more obvious? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 12 00:57:33 2018 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 581E91270A0; Mon, 12 Mar 2018 00:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 d5v1TrPyDIXz; Mon, 12 Mar 2018 00:57:31 -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 8931412706D; Mon, 12 Mar 2018 00:57:30 -0700 (PDT) Received: from Jude (79.173.164.218) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Mar 2018 00:55:22 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> In-Reply-To: <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> Date: Mon, 12 Mar 2018 07:57:21 +0000 Message-ID: <006e01d3b9d7$c22099e0$4661cda0$@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: AQMcTQansbjWj+OM/I8zCpCVWUJ02AEekN7koTIdvmA= Content-Language: en-us X-Originating-IP: [79.173.164.218] Archived-At: Subject: Re: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 07:57:32 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Monday, March 12, 2018 7:25 AM > To: Jim Schaad > Cc: draft-ietf-cbor-cddl@ietf.org; cbor@ietf.org > Subject: Re: Review comments draft-ietf-cbor-cddl-02 >=20 > Hi Jim, >=20 > thanks for the additional comments. >=20 > (I just returned from a two-week vacation and I=E2=80=99m processing = mail in a mix of > SJN/LIFO.) >=20 > > On Mar 12, 2018, at 07:35, Jim Schaad = wrote: > > > > A couple of more quick comments. > > > > * In appendix B - The ANBF has > > > > grpent =3D [occur S] [memberkey S] type optcom > > / [occur S] groupname [genericarg] optcom ; preempted by = above > > / [occur S] "(" S group S ")" optcom > > > > The last option in the rule is redundant. "(" group ")" will be > > reduced to a type via type2 =3D> type1 =3D> type so this is not = needed. >=20 > In the CDDL spec >=20 > Foo =3D { > ? ( k1: int, k2: bytes ) > k3: float > } >=20 > The second line does not match the grpent=E2=80=99s first alternative = with =E2=80=9Ctype=E2=80=9D, so > the third alternative for grpent is actually needed. --- Yuck -- { vs ( is sometimes hard to see esp if the font is small. >=20 > However, maybe it is worth pointing out in the text that the second = line in >=20 > Foo =3D { > ? ( Bar ) > k3: float > } >=20 > Bar =3D (k1: int, k2: bytes) >=20 > is indeed matched the way you describe; the ABNF grammar cannot always > reliably distinguish between groups and types (and any type does serve = as a > keyless single-entry group anyway), so some semantic check is needed = in a > tool. >=20 > > * Security considerations > > > > Having played around with some of the grammar and looking at things, = I > > believe that there needs to be a security consideration around the > > following issue. You can really do harm to yourself when writing a > > grammar. There are tons of things that can be expressed that are > > going to lead to confusion on the part of other readers and > > implementers. Writing a complex grammar is going to lead to = incorrect > > implementations. When writing down a CDDL grammar, keep it as = simple > as possible while still expressing the needed > > language. >=20 > This point indeed cannot be stressed enough. (It is rather obvious to = people > who have witnessed what happens when people start speccing away in > languages like ASN.1=E2=80=A6) Just because CDDL makes it easier to = handle > complexity in a specification, that does not make that complexity = somehow > less bad (except on the level of the humans having to grasp the = complex > structure while reading the spec). I am not worried about the complexity of the spec, I am worried about = the complexity of the CDDL. These are very different issues. >=20 >=20 > > * A note needs to be added to section 3.5 on one of the dangers of > > using a bareword as a member name. If you are writing a grammar = that > > is intended to be extended by having people append additional > > information to the current module, one can unexpectedly change the > > grammar when using a barewood as a new module may define the > barewood > > as a type. (Potentially 5 levels down.) > > > > Example > > > > X =3D ( ipaddr : ipv6Address / ipv4Address } > > > > The next module then defines > > > > Ipaddr =3D [? macAddress, tstr, ipv4Address / ipv6Address] > > > > The bareword member name has now been converted into a type. >=20 > That is not what happens: A bareword stays a bare word, even if a rule = is > added that uses the same word. I have completely missed how this would be true. Are you saying that X =3D { five : int } five =3D 5 is not the same as X =3D { 5 : int } How does the checker know when a rule that uses the same word is "added" = vs in the base specification? Jim >=20 > Tools should probably **warn** when this happens (keep a list of > barewords that are in use, warn if any rule has the same name as the > bareword), but it is not an error exactly for the reason you point = out: > unrelated use in a different part of the spec. >=20 > Is there any text that should be fixed to make the intended behavior = more > obvious? >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 12 02:44:32 2018 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 D13AD1242EA; Mon, 12 Mar 2018 02:44:30 -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] 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 6KOPJ_TvDeUL; Mon, 12 Mar 2018 02:44:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2893B1241F3; Mon, 12 Mar 2018 02:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2C9iJ8h018601; Mon, 12 Mar 2018 10:44:19 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 400CkC1jypzDWPY; Mon, 12 Mar 2018 10:44:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <006e01d3b9d7$c22099e0$4661cda0$@augustcellars.com> Date: Mon, 12 Mar 2018 10:44:18 +0100 Cc: draft-ietf-cbor-cddl@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 542540656.787585-e978ef6a3168dc3d2d09cdd0c3380785 Content-Transfer-Encoding: quoted-printable Message-Id: <4BC72B3A-574F-4FC1-AE20-84FEE49F4A40@tzi.org> References: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> <006e01d3b9d7$c22099e0$4661cda0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 09:44:31 -0000 >=20 > =E2=80=94 Yuck -- { vs ( is sometimes hard to see esp if the font is = small. Right =E2=80=94 we have experienced this effect as well. There are some =E2=80=9Cprogrammers=E2=80=99 fonts=E2=80=9D that focus = on distinction of characters; it is best to use one of those with CDDL = (or for any kind of work with computer languages beyond COBOL, = actually). (We also discussed the alternative of making the distinction more heavy = in the CDDL grammar =E2=80=94 this would lose the recognizability of { = and [ for people thinking in diagnostic notation/JSON.) >=20 > I am not worried about the complexity of the spec, I am worried about = the complexity of the CDDL. These are very different issues. Thanks =E2=80=94 my mind latched on the other issue too fast. Pointing this one out is also useful. =20 Do we want to provide some specific considerations here (what to avoid, = how to phrase things in a simpler way)? (I tend to think such a = =E2=80=9Cstyle guide=E2=80=9D would become very long quickly and = probably should go into a separate document.) >=20 > I have completely missed how this would be true. Are you saying that >=20 > X =3D { five : int } > five =3D 5 >=20 > is not the same as >=20 > X =3D { 5 : int } Yes, and I think the draft is also saying this. We could add an example explicitly calling this out. > How does the checker know when a rule that uses the same word is = =E2=80=9Cadded" vs in the base specification? It doesn=E2=80=99t, so any message about a bareword looking like an = existing rule name always will be a warning only. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 12 09:23:38 2018 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 B587B1275F4 for ; Mon, 12 Mar 2018 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 m_xB6hlFfTNd for ; Mon, 12 Mar 2018 09:23:34 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 A58EC127599 for ; Mon, 12 Mar 2018 09:23:34 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q12so5538405ioh.8 for ; Mon, 12 Mar 2018 09:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=46UA0V4a4VEJIZGnLKV+aSMWRyn6MpT1gKIaKXrD0a4=; b=bZL+GJ6Pw8IYczK2zUg8g8O16SSpmRoGjFspqLmLsRGX9haTcLiyzYcV24SInl06qQ ED3NfvTsKVyI+D+2xB/OtgZbbRFp2nCprSeS+k6z6g7F0sn+18SM53va37TgP1dPyxP/ 4n9f9ChNtT6buaD6yjB6bc4ydDcmYsbTz5Yac= 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=46UA0V4a4VEJIZGnLKV+aSMWRyn6MpT1gKIaKXrD0a4=; b=Fhi+bWT9ltPb9ILAmRf+cGhQt06gsNjpaSrPbNoT6aEj1+oGL8fcVPPG9alAeQrj5O KzYsvQ+HSvkwh4yxeanRU6DCXY6aCGF26DaooOlrXanbYdAffAMQfGSA1EBGhZeOMt+R E9SQuL7WghgQmihzp3qb7va5sGQpnOtLYS1/Ab2z423hEESoMMvWcHKpJ9XXaBJ+M4k3 72EiHFQt1ZLAZz7Umj6CBxVka1XNY0C9XsrXwTvgtZC8aYsnhpwdSaSiuXhUG1U3Hnnt RWx92Er5rvEpMywu0FoE3xCJav6WGU9Fj9dXOaLXaF5wWlz06xSxX7ZfiHaG2nIce+jO xp5A== X-Gm-Message-State: AElRT7EyHBKH+myG4F/4enx5iZbvXzFXq+h0E4jJJF2dP5h5Z2ukDo+S 00Kp70FaAqJ5qdQMj4TcuIJKyKde0Fa7NllYye782UPbPDw= X-Google-Smtp-Source: AG47ELt8sfBAytTquO8nZ8uZMgyqxXfErGTB/6l7UVMRNcb4+y9psoduXmTDj03Glp6coQ0eeKBNeD8Jdknv2oyP6C8= X-Received: by 10.107.51.208 with SMTP id z199mr9924401ioz.112.1520871813339; Mon, 12 Mar 2018 09:23:33 -0700 (PDT) MIME-Version: 1.0 References: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> <006e01d3b9d7$c22099e0$4661cda0$@augustcellars.com> <4BC72B3A-574F-4FC1-AE20-84FEE49F4A40@tzi.org> In-Reply-To: <4BC72B3A-574F-4FC1-AE20-84FEE49F4A40@tzi.org> From: Jeffrey Yasskin Date: Mon, 12 Mar 2018 16:23:22 +0000 Message-ID: To: Carsten Bormann Cc: ietf@augustcellars.com, cbor@ietf.org, draft-ietf-cbor-cddl@ietf.org Content-Type: multipart/alternative; boundary="001a114537ac2fe46e05673990c8" Archived-At: Subject: Re: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 16:23:37 -0000 --001a114537ac2fe46e05673990c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 12, 2018 at 2:44 AM Carsten Bormann wrote: > > > > > =E2=80=94 Yuck -- { vs ( is sometimes hard to see esp if the font is sm= all. > > > Right =E2=80=94 we have experienced this effect as well. > There are some =E2=80=9Cprogrammers=E2=80=99 fonts=E2=80=9D that focus on= distinction of > characters; it is best to use one of those with CDDL (or for any kind of > work with computer languages beyond COBOL, actually). > > (We also discussed the alternative of making the distinction more heavy i= n > the CDDL grammar =E2=80=94 this would lose the recognizability of { and [= for > people thinking in diagnostic notation/JSON.) > > > > > I am not worried about the complexity of the spec, I am worried about > the complexity of the CDDL. These are very different issues. > > Thanks =E2=80=94 my mind latched on the other issue too fast. > Pointing this one out is also useful. > Do we want to provide some specific considerations here (what to avoid, > how to phrase things in a simpler way)? (I tend to think such a =E2=80= =9Cstyle > guide=E2=80=9D would become very long quickly and probably should go into= a > separate document.) > > > > > I have completely missed how this would be true. Are you saying that > > > > X =3D { five : int } > > five =3D 5 > > > > is not the same as > > > > X =3D { 5 : int } > > Yes, and I think the draft is also saying this. > We could add an example explicitly calling this out. > Specifically, to use a type, you have to use the `=3D>` form. Using `:` forces either a bareword or a value. This is somewhat described in https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.5.1 with > "an identifier that is followed by a colon can be directly used as the text string for a member key ... > all the types defined can be used in a keytype position by following them with a double arrow." but because that's phrased as a tutorial instead of a specification, it's not clear exactly what the rules are. The grammar is a little more clear: > memberkey =3D type1 S ["^" S] "=3D>" > / bareword S ":" > / value S ":" But since a grammar only describes syntax, not semantics, it's plausible that implementations will pick Jim's interpretation, and interpret an id before a colon as a type instead of a bareword. Jeffrey --001a114537ac2fe46e05673990c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 12= , 2018 at 2:44 AM Carsten Bormann <cabo@= tzi.org> wrote:

>
> =E2=80=94 Yuck -- { vs ( is sometimes hard to see esp if the font is s= mall.


Right =E2=80=94 we have experienced this effect as well.
There are some =E2=80=9Cprogrammers=E2=80=99 fonts=E2=80=9D that focus on d= istinction of characters; it is best to use one of those with CDDL (or for = any kind of work with computer languages beyond COBOL, actually).

(We also discussed the alternative of making the distinction more heavy in = the CDDL grammar =E2=80=94 this would lose the recognizability of { and [ f= or people thinking in diagnostic notation/JSON.)

>
> I am not worried about the complexity of the spec, I am worried about = the complexity of the CDDL.=C2=A0 These are very different issues.

Thanks =E2=80=94 my mind latched on the other issue too fast.
Pointing this one out is also useful.
Do we want to provide some specific considerations here (what to avoid, how= to phrase things in a simpler way)?=C2=A0 (I tend to think such a =E2=80= =9Cstyle guide=E2=80=9D would become very long quickly and probably should = go into a separate document.)

>
> I have completely missed how this would be true.=C2=A0 Are you saying = that
>
> X =3D { five : int }
> five =3D 5
>
> is not the same as
>
> X =3D { 5 : int }

Yes, and I think the draft is also saying this.
We could add an example explicitly calling this out.
<= br>
Specifically, to use a type, you have to use the `=3D>` fo= rm. Using `:` forces either a bareword or a value. This is somewhat describ= ed in https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.5.1<= /a> with=C2=A0





Jeffrey
--001a114537ac2fe46e05673990c8-- From nobody Mon Mar 12 09:56:46 2018 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 025A0126B72; Mon, 12 Mar 2018 09:56:45 -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] 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 XmbX2SCpj-0U; Mon, 12 Mar 2018 09:56:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D679D1267BB; Mon, 12 Mar 2018 09:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2CGuTBi025430; Mon, 12 Mar 2018 17:56:29 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 400PJr6P0gzDWZb; Mon, 12 Mar 2018 17:56:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Mon, 12 Mar 2018 17:56:27 +0100 Cc: Jim Schaad , cbor@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 542566586.21953-901b491cbbd480ef8a5aec597cf779a1 Content-Transfer-Encoding: quoted-printable Message-Id: <68061575-96E4-4FEB-9BCC-16FFD3CBD45A@tzi.org> References: <006b01d3b9cc$4a7f9ae0$df7ed0a0$@augustcellars.com> <27F177CE-A4C2-466C-B1EB-33AD7358B399@tzi.org> <006e01d3b9d7$c22099e0$4661cda0$@augustcellars.com> <4BC72B3A-574F-4FC1-AE20-84FEE49F4A40@tzi.org> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Review comments draft-ietf-cbor-cddl-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 16:56:45 -0000 Now https://github.com/cbor-wg/cddl/issues/10 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 13 11:54:35 2018 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 1B73F12D7F4; Tue, 13 Mar 2018 11:54:34 -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] 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 ImWsJbLeQVhO; Tue, 13 Mar 2018 11:54:33 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E82F5129C6C; Tue, 13 Mar 2018 11:54:32 -0700 (PDT) Received: from [10.32.60.158] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w2DIs0C0093649 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Mar 2018 11:54:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.158] From: "Paul Hoffman" To: cbor@ietf.org Cc: draft-jroatch-cbor-tags@ietf.org Date: Tue, 13 Mar 2018 11:54:30 -0700 X-Mailer: MailMate (1.11r5462) Message-ID: In-Reply-To: <000001d3b7f9$5d9d0e70$18d72b50$@augustcellars.com> References: <000001d3b7f9$5d9d0e70$18d72b50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Cbor] Review of draft-jroatch-cbor-tags -07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 18:54:34 -0000 I too have reviewed this. My main comment is not as specific as Jim's. The endianness is going to be done wrong regardless of what you say, but we can cause it to be done more right with more use of MUST-filled language. The last paragraph in Section 2.1 particularly concerns me. Other than that, I think the document is in good shape, and it is quite understandable. --Paul Hoffman From nobody Tue Mar 13 16:47:04 2018 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 A270B126DFB for ; Tue, 13 Mar 2018 16:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 Oa4eM-nfjMD5 for ; Tue, 13 Mar 2018 16:47:01 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 D2A0B1201F8 for ; Tue, 13 Mar 2018 16:47:00 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id u5-v6so2422963itc.1 for ; Tue, 13 Mar 2018 16:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y0cDybxUt6gj2HsZF49XuqG+wPwzcGqGMH8ifs5pszI=; b=HpHekuEBq8aNLyHWiJ3UjDxo+8U1o3xwaT7PInrN8ZbTJaiGVJOe8OVXJLfHye4KYK 7KBAZ0fVj28Lke5DHjjWlYWHeS0oJZsGWe9KFslQPe4WqzF/P/Q1+IRNqx+I1qN7h0jJ CbqAOvLGVKdQQUAC2XA0knaTlbfGWytN3HhWg= 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=Y0cDybxUt6gj2HsZF49XuqG+wPwzcGqGMH8ifs5pszI=; b=E7Q+9skpnH1Ge76mXymObPte9++bgDxgmxciaiVjjZVs+nxQiPWj6/XS2CcllDwTi+ +i3+9B26I2gtShMuWLwY0tNAPfAZH1VxingSwae7pjruKZVwznktOoGZauYpFNWbpXH+ /uWBWGk1WaI7zJ7a+FkwyzJ7Igc+O+W8qcAzxuyJDiQYKnIoOv2OTYo3GSjy9s71L1vk A7+kFpa0buNgf9XffB073+w3pQuNvRoD7VFz++iEQLaO8Rd+3aMYzqcJiQjgWIm6DS/2 bSVMYDEoisuKrwJH2R1+cIKGryJRZd/hUE8AwXmpDFZpKWY0KxUibB4J7IIJqAxfhLWo dkSA== X-Gm-Message-State: AElRT7GfGJPqr2xkqK3bHI7/FK7vNnGWdn3+LSJaAq7/0pnd7mfgVyzB EP8eA+iAoI3yr0hILwKBQErmV53ERzpuAmSydsYWuQ== X-Google-Smtp-Source: AG47ELuwgYEPTOIkQ7ZHIhmOsDMYdUAhadz9EB+GSkul1rYmKEdKpr/AW02RLQ2iyiKO08b2J9xd1drTtIiiIP8O5tE= X-Received: by 10.36.164.14 with SMTP id z14mr3113720ite.106.1520984819417; Tue, 13 Mar 2018 16:46:59 -0700 (PDT) MIME-Version: 1.0 References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> In-Reply-To: <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> From: Jeffrey Yasskin Date: Tue, 13 Mar 2018 23:46:47 +0000 Message-ID: To: Carsten Bormann Cc: Jeffrey Yasskin , Francesca Palombini , cbor@ietf.org Content-Type: multipart/alternative; boundary="f403045fbfb8df4b37056753df11" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:47:04 -0000 --f403045fbfb8df4b37056753df11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've gotten criticism for using the base CBOR specification in a web specification because it's not precise enough about when there's a parse failure ( https://github.com/mozilla/standards-positions/issues/29#issuecomment-33437= 6573), so I'm extra sensitive to imprecision in CDDL. I wouldn't want an initial CDDL RFC that we have to change a lot before web folks are comfortable depending on it. For occurrences, the specification is in https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#page-39 ( https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.2 does not contain any statement saying the number of times a group needs to or can match, except for the special case of "no occurrence indicator"): > An occurrence indicator modifies the group given to its right by > requiring the group to match the sequence to be matched exactly for a > certain number of times (see Section 3.2) in sequence This specification of occurrence indicators does *not* prevent the group from matching a subsequence of items; it just says that if the group matches the wrong number of times, the requirement isn't met. If the specification intends to describe a more imperative algorithm where groups stop matching after seeing some sequence elements, it needs to say so, but unless this is done carefully, it probably leads to dependencies on the order elements appear in a map. https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.5.3 says > once the map key matches the entry > carrying the cut, other potential matches for the key that occur in > later entries in the group of the map are no longer allowed. This describes map *keys* matching whole entries ("key + value"s), which doesn't make a lot of sense. I've been interpreting it as just matching against the entry's key (but that doesn't work for group entries consisting of subgroups...), and then it's pretty clear that { "a": 3, "b": 3} has two entries matching the first group element of { ? tstr ^ =3D> int, any =3D> a= ny }, and then the occurrence indicator says that match doesn't fit the requirements. Jeffrey On Sat, Mar 3, 2018 at 6:04 PM Carsten Bormann wrote: > I can't point to a specific sentence, but for a cut to be effective, the > match needs to occur first, and in this case the whole entry says that ca= n > only happen once. > > Sent from mobile > > On 3. Mar 2018, at 20:13, Jeffrey Yasskin wrote: > > I don't have a particular use case in mind, so if you prefer to ignore th= e > cut after its occurrences are saturated, that's fine. Which sentences in > the specification specify that? > > Thanks, > Jeffrey > > On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann wrote: > >> (typing this from a mobile device) >> >> Hi Jeffrey, >> >> I do believe that the current matching rules indeed saturate the optiona= l >> group entry, so the cut does not apply to any additional members. I thi= nk >> that is exactly as it should be. The requirements you seem to be express= ing >> are probably better solved by limiting the wildcard instead. Can you be >> more specific about your use case? >> >> Sent from mobile >> >> On 2. Mar 2018, at 01:47, Jeffrey Yasskin wrote: >> >> I haven't re-reviewed this draft fully, but I think an issue I'd sent >> directly to Carsten is still present: if a map key type is specified wit= h >> both a cut and an occurrence indicator, and the occurrence indicator is >> saturated, do subsequent keys matching the type fall back to later entri= es? >> For example, does: >> >> { >> "a": 3 >> "b": "cow" >> } >> >> match >> >> { >> ? tstr ^ =3D> int >> any =3D> any >> } >> >> ? I think it shouldn't, but I don't see a collection of sentences in the >> specification that specifies it. >> >> Jeffrey >> >> >> >> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini < >> francesca.palombini@ericsson.com> wrote: >> >>> Dear CBOR WG, >>> >>> As discussed during the past IETF meetings, and after the last updates, >>> the CDDL draft is ready for WGLC. >>> >>> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>> >>> The WGLC will end by *13th of March*, please make sure to send your >>> comments to the list before then. >>> >>> Best regards, >>> Francesca & Joe >>> >>> > -----Original Message----- >>> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Borman= n >>> > Sent: den 26 februari 2018 21:46 >>> > To: cbor@ietf.org >>> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >>> > >>> > We have submitted draft-ietf-cbor-cddl-02.txt: >>> > >>> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>> > >>> > Diff from previous version at: >>> > >>> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >>> > >>> > We believe that this is now ready for WGLC. >>> > (If we can start it quickly, the results of the call will be in for >>> discussion in >>> > London.) >>> > >>> > Gr=C3=BC=C3=9Fe, Carsten >>> > >>> > _______________________________________________ >>> > CBOR mailing list >>> > CBOR@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cbor >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> >> _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > --f403045fbfb8df4b37056753df11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've gotten criticism for using the base CBOR specific= ation in a web specification because it's not precise enough about when= there's a parse failure (https://github.com/mozilla/s= tandards-positions/issues/29#issuecomment-334376573), so I'm extra = sensitive to imprecision in CDDL. I wouldn't want an initial CDDL RFC t= hat we have to change a lot before web folks are comfortable depending on i= t.

For occurrences, the specification is in https://tools.i= etf.org/html/draft-ietf-cbor-cddl-02#page-39 (https://tools.ietf.org/h= tml/draft-ietf-cbor-cddl-02#section-3.2 does not contain any statement = saying the number of times a group needs to or can match, except for the sp= ecial case of "no occurrence indicator"):

> An occurrence indicator modifies the group given to its right by
> requiring the group to match the sequence to be matched exactly= for a
> certain number of times (see Section 3.2) in sequence=

This specification of o= ccurrence indicators does *not* prevent the group from matching a subsequen= ce of items; it just says that if the group matches the wrong number of tim= es, the requirement isn't met. If the specification intends to describe= a more imperative algorithm where groups stop matching after seeing some s= equence elements, it needs to say so, but unless this is done carefully, it= probably leads to dependencies on the order elements appear in a map.


> once the map k= ey matches the entry
> carrying the cut, other potential matches for= the key that occur in
> later entries in the group of the map= are no longer allowed.

This describes map *keys* = matching whole entries ("key + value"s), which doesn't make a= lot of sense. I've been interpreting it as just matching against the e= ntry's key (but that doesn't work for group entries consisting of s= ubgroups...), and then it's pretty clear that { "a": 3, "= ;b": 3} has two entries matching the first group element of { ?=C2=A0<= span style=3D"font-size:12.8px">tstr ^ =3D> int,=C2=A0any =3D> any }, and then the occurrence indicator = says that match doesn't fit the requirements.

Jeffrey

On Sat, Mar 3, 2018 at 6:04 PM Carsten Bormann <cabo@tzi.org> wrote:
I can't point to a speci= fic sentence, but for a cut to be effective, the match needs to occur first= , and in this case the whole entry says that can only happen once.=C2=A0
Sent from=C2= =A0mobile

On 3. Mar 201= 8, at 20:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:

I don't have a particular use = case in mind, so if you prefer to ignore the cut after its occurrences are = saturated, that's fine. Which sentences in the specification specify th= at?

Thanks,
Jeffrey

On = Sat, Mar 3, 2018, 12:07 AM Carsten Bormann <cabo@tzi.org> wrote:
(typing this from a mob= ile device)

Hi Jeffrey,

I do be= lieve that the current matching rules indeed saturate the optional group en= try, so the cut does not apply to any additional members.=C2=A0 I think tha= t is exactly as it should be. The requirements you seem to be expressing ar= e probably better solved by limiting the wildcard instead. Can you be more = specific about your use case?

Sent from=C2=A0mobile

On 2. Mar 2018, at 01:47, Jeffrey = Yasskin <jyasskin@chromium.org> wrote:

I haven't re-reviewed this draft = fully, but I think an issue I'd sent directly to Carsten is still prese= nt: if a map key type is specified with both a cut and an occurrence indica= tor, and the occurrence indicator is saturated, do subsequent keys matching= the type fall back to later entries? For example, does:

{
=C2=A0 "a": 3
=C2=A0 "b": "= cow"
}

match

{
=C2=A0 ? tstr ^ =3D> int
=C2=A0 any =3D> any=
}

? I think it shouldn't, but I don= 't see a collection of sentences in the specification that specifies it= .

Jeffrey



On Tue, Feb 27, 2018 at 12:28 AM Fran= cesca Palombini <francesca.palombini@ericsson.com> = wrote:
Dear CBOR= WG,

As discussed during the past IETF meetings, and after the last updates, the= CDDL draft is ready for WGLC.

https://tools.ietf.org/html/draft-ietf= -cbor-cddl-02

The WGLC will end by *13th of March*, please make sure to send your comment= s to the list before then.

Best regards,
Francesca & Joe

> -----Original Message-----
> From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten = Bormann
> Sent: den 26 februari 2018 21:46
> To: cbor@ietf.org
> Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt
>
> We have submitted draft-ietf-cbor-cddl-02.txt:
>
> https://tools.ietf.org/html/draft= -ietf-cbor-cddl-02
>
> Diff from previous version at:
>
> https://tools.ietf.= org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt
>
> We believe that this is now ready for WGLC.
> (If we can start it quickly, the results of the call will be in for di= scussion in
> London.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> 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<= br>
___________________= ____________________________
CBOR mailing list
C= BOR@ietf.org
https://www.ietf.org/mail= man/listinfo/cbor
___________________= ____________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
=
--f403045fbfb8df4b37056753df11-- From nobody Tue Mar 13 23:27:43 2018 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 2ACD112762F for ; Tue, 13 Mar 2018 23:27:42 -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] 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 CPV_JTOCJ-Se for ; Tue, 13 Mar 2018 23:27:40 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187AB12708C for ; Tue, 13 Mar 2018 23:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2E6Ran6023846; Wed, 14 Mar 2018 07:27:36 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 401MGJ19LfzDWwq; Wed, 14 Mar 2018 07:27:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 14 Mar 2018 07:27:35 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 542701653.9075969-8c77b236febfe90c437c5033327dab11 Content-Transfer-Encoding: quoted-printable Message-Id: <56C1F963-2C5D-4F97-BD74-EC58E3CA9601@tzi.org> References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 06:27:42 -0000 On Mar 14, 2018, at 00:46, Jeffrey Yasskin = wrote: >=20 > it's not precise enough about when there's a parse failure = (https://github.com/mozilla/standards-positions/issues/29#issuecomment-334= 376573), Well, hsivonen is wrong here. It=E2=80=99s not that =E2=80=9Canything = goes=E2=80=9D in CBOR, and I have no idea how to read Section 3.3 of RFC = 7049 (which is linked in the above) that way. Section 3.3 instead = indicates specific error cases. Yes, it does allow robust parsing, but = not without "using a decoder-specific convention that clearly indicates there has been a problem=E2=80=9D. If you think there is a = need for improving the language here to better represent the intent, = I=E2=80=99d sure like to know. I=E2=80=99ll look at the specification language issues you point out in = the CDDL spec later today. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 14 10:08:39 2018 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 B6008120227 for ; Wed, 14 Mar 2018 10:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 HGJb7tI4cU5y for ; Wed, 14 Mar 2018 10:08:36 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 DE923120724 for ; Wed, 14 Mar 2018 10:08:35 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id p78so5196354iod.13 for ; Wed, 14 Mar 2018 10:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E1u6S2zsMF7RXtWy0nHPzO04QhZpyy/JZeUq5Kn8sZA=; b=BWXtg6ppoga6dp+L7SvB/d5/xvqJikZk1mR/GtHNeF+X9ERQtsjqZo8NXKvyxxuSWk RybGNNhI57W6B00GlVOct/k8dudzmRDss+TiEZ351QUrUNI83H6wwvCimgygCFBUVR9j 7lWuzCOKnc9natcThu/PzCmn6/IAd7I5ETofw= 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=E1u6S2zsMF7RXtWy0nHPzO04QhZpyy/JZeUq5Kn8sZA=; b=gv1aIA3K7Cg+cVwnJTWJEaz0KOS3Z+kEyHIlAcR4EVwk950O9RnI/whjEddCNHHYxW 2y86NMa4jeYShAFZ+0CGq48BmSIAHoWStZBtO/cBR0/9x8GJdbGu+mA2i+5QSus/ROHY UCN4gPrlzX08m/i5OUFjlNlRboRgqKIREmG+ffEvXrXo07O8fCgrkjF/WRb3MddXHF1l PBKvS9gvHdKBwCC6icEoKC4mW6ah5wHoE/yH3spkjLMwcM7hfFo/kTlRHJyVp3HmoX+n gpJng22tNYLYlK5reIwg+LwqvRMerujQ3Mtl3FWFgfy/IoKt8m2NfPtCsb7Myy3E5OOk 74uA== X-Gm-Message-State: AElRT7GLl/2C93AuEgc4umW/gfKTMM/SPwTyoV2dH9e2PYRlvBD2VRck MnIPxQoBpBk/W9PB7xsayh5RaAQhUipvt3E4FA/gPA== X-Google-Smtp-Source: AG47ELs4yKCkdxjyn6FGx4ZXUJm66KMUlTaR3ZeTO1GfrLFisff7hOfFZxWVqoElAtPA8JDgZe/+XNVr3+Jyealh6OY= X-Received: by 10.107.28.195 with SMTP id c186mr5930606ioc.30.1521047314446; Wed, 14 Mar 2018 10:08:34 -0700 (PDT) MIME-Version: 1.0 References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> <56C1F963-2C5D-4F97-BD74-EC58E3CA9601@tzi.org> In-Reply-To: <56C1F963-2C5D-4F97-BD74-EC58E3CA9601@tzi.org> From: Jeffrey Yasskin Date: Wed, 14 Mar 2018 17:08:21 +0000 Message-ID: To: Carsten Bormann Cc: Jeffrey Yasskin , cbor@ietf.org Content-Type: multipart/alternative; boundary="001a113fdf4eddcc740567626c7e" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:08:38 -0000 --001a113fdf4eddcc740567626c7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2018 at 11:27 PM Carsten Bormann wrote: > On Mar 14, 2018, at 00:46, Jeffrey Yasskin wrote: > > > > it's not precise enough about when there's a parse failure ( > https://github.com/mozilla/standards-positions/issues/29#issuecomment-334= 376573 > ), > > Well, hsivonen is wrong here. It=E2=80=99s not that =E2=80=9Canything go= es=E2=80=9D in CBOR, and > I have no idea how to read Section 3.3 of RFC 7049 (which is linked in th= e > above) that way. Section 3.3 instead indicates specific error cases. Ye= s, > it does allow robust parsing, but not without "using a decoder-specific > convention that clearly > indicates there has been a problem=E2=80=9D. If you think there is a = need for > improving the language here to better represent the intent, I=E2=80=99d s= ure like > to know. > I filed a similar issue in https://github.com/cbor-wg/CBORbis/issues/3, and I'm currently working on breaking up the changes in https://github.com/cbor-wg/CBORbis/compare/master...jyasskin:editorial-impr= ovements into manageable PRs. > I=E2=80=99ll look at the specification language issues you point out in t= he CDDL > spec later today. > Thanks. --001a113fdf4eddcc740567626c7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 13= , 2018 at 11:27 PM Carsten Bormann <cabo= @tzi.org> wrote:
On Mar 14, 2018, at 00:46, Jeffrey Yasskin <jyasskin@chromium.org> wrote:=
>
>=C2=A0 it's not precise enough about when there's a parse failu= re (https://github.co= m/mozilla/standards-positions/issues/29#issuecomment-334376573),

Well, hsivonen is wrong here.=C2=A0 It=E2=80=99s not that =E2=80=9Canything= goes=E2=80=9D in CBOR, and I have no idea how to read Section 3.3 of RFC 7= 049 (which is linked in the above) that way.=C2=A0 Section 3.3 instead indi= cates specific error cases.=C2=A0 Yes, it does allow robust parsing, but no= t without "using a decoder-specific convention that clearly
=C2=A0 =C2=A0indicates there has been a problem=E2=80=9D.=C2=A0 If you thin= k there is a need for improving the language here to better represent the i= ntent, I=E2=80=99d sure like to know.

I= filed a similar issue in=C2=A0https://github.com/cbor-wg/CBORbis/issues/3, and I'm cu= rrently working on breaking up the changes in=C2=A0htt= ps://github.com/cbor-wg/CBORbis/compare/master...jyasskin:editorial-improve= ments into manageable PRs.
=C2=A0
I=E2=80=99ll look at the specification language issues you point out in the= CDDL spec later today.

Thanks.
--001a113fdf4eddcc740567626c7e-- From nobody Thu Mar 15 03:38:43 2018 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 E4A87127871 for ; Thu, 15 Mar 2018 03:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=XLPNA2UZ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=hlrxfsfm 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 gPHFg2t4A41M for ; Thu, 15 Mar 2018 03:38:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 9203C127077 for ; Thu, 15 Mar 2018 03:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521110316; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJ5qmOCLm4x8jhyTx8JtkTrP1XjLH850hhM8LT4LPwo=; b=XLPNA2UZdWSCWWDr77f0OtxTSyKWKGoZMz1OkyQJpumy4BQ6KvLDZiZPikI+jgHI P4FD6x/kjC0m1ztp1BB+zkshfSnmXZQGULCM0fs/osmb4Od+mtAmr49p3DcBXEsd qPBeVxdNk1zhWetNQVdtAlowvKRYWWvBE3mZ8zCzqL8=; X-AuditID: c1b4fb30-703ff7000000095a-5e-5aaa4d2b6fb7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.06.02394.B2D4AAA5; Thu, 15 Mar 2018 11:38:36 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC007.ericsson.se (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 15 Mar 2018 11:38:35 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 15 Mar 2018 11:38:35 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Thu, 15 Mar 2018 11:38:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xJ5qmOCLm4x8jhyTx8JtkTrP1XjLH850hhM8LT4LPwo=; b=hlrxfsfm4CAAA+LiJRP5iwUtknOXkNbdhhp1rtLHxNuyenG1FAURALMy0JsMiYxnf1OxMWnYJX9ZsQehjT5ihbVfcR3X5jNaSlskfgc4fGwkpzIWgCSXoZA7mHR6j8SpO/wGP/0IULIJPxOjUKEGXqoZyTVssV13HoOK2pVZuxQ= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB0778.eurprd07.prod.outlook.com (10.162.24.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.7; Thu, 15 Mar 2018 10:38:33 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::fc63:65b5:e74b:8856]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::fc63:65b5:e74b:8856%2]) with mapi id 15.20.0588.013; Thu, 15 Mar 2018 10:38:33 +0000 From: Francesca Palombini To: Paul Hoffman , Jim Schaad , "cbor@ietf.org" CC: "draft-jroatch-cbor-tags@ietf.org" Thread-Topic: [Cbor] Review of draft-jroatch-cbor-tags -07 Thread-Index: AdO38f7YC6G++zKDT36gz1sbvvR3OwDCrjUAAFM/zUA= Date: Thu, 15 Mar 2018 10:38:33 +0000 Message-ID: References: <000001d3b7f9$5d9d0e70$18d72b50$@augustcellars.com> In-Reply-To: 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: [192.176.1.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB0778; 7:GD7FDNy5h1H8G0H3+kOoEUBYqt8LEhAzepwT3QB2qYYWttic8tXhsgHgGBTK3l9+56vZq/s7LuJndUzNYPk0ohdpbuPEMk2EyLR7AStLx2eSIBHA6UWlKmcxvnM6lnBIxDc4N1AnRypEt+BpPq3Xsd4KyoCJIClNMy7LZIo0lXpBg0R0NEvIFDwYt0KL1WKlKTqJj05PXgkTbqFU8feuQFS4QH7EoqSMWbBGhg4eJo1UbeLcUKZT7gLGxo5Sdhxr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4fe4a829-df77-486f-2cfe-08d58a60e6cb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB0778; x-ms-traffictypediagnostic: HE1PR07MB0778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501244)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR07MB0778; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0778; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(39380400002)(366004)(396003)(189003)(199004)(13464003)(106356001)(66066001)(14454004)(3846002)(316002)(966005)(6116002)(4326008)(9686003)(186003)(3660700001)(8936002)(478600001)(5250100002)(3280700002)(86362001)(105586002)(2501003)(55016002)(74316002)(2950100002)(7696005)(53546011)(6506007)(229853002)(6246003)(7736002)(102836004)(110136005)(305945005)(97736004)(99286004)(76176011)(81156014)(5660300001)(8676002)(6306002)(2900100001)(26005)(2906002)(33656002)(68736007)(25786009)(6436002)(53936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0778; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +4O9msv3I31ffOuKeXk9nT6WqmAFi64UYwk8tzAFxCgR0xjTpvMJFQzB0F3zeVnryxT4juwsOKKDeU7pOChcKGZBpoqIDd78hoKw0weCgxFZpWZzo1xswkukVryHsPHbHB2KAsnd4hMYCnJOdeUEyC61PDhkfYCQqnDUjdUkFwsF2dn7Ie4zTQJpGU/Gy52RN8WLHGocvo7nK+pLwDRM0HpQwpMtwiFqk+dNoraseMXq6WcuyIXnF8+sXMF+qTbOZaoStI5tlYV9zh7MyCIZG7pNkXoTfBFXFSNlPkMfJzpQxmzH2ytLqcgFurxnmLmM6kerpg/R8wkwF0Yo2XCJ+Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fe4a829-df77-486f-2cfe-08d58a60e6cb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2018 10:38:33.4560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0778 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUyM2K7uq6O76oog+1bOCxmdkxnsTixYiW7 xerp39ksbq3/wurA4rFxznQ2jyVLfjJ5fJ59lTmAOYrLJiU1J7MstUjfLoEro339WraCr2wV i87sYmtgvMjaxcjJISFgInH5yFnGLkYuDiGBw4wSN742QDlbGCUuX7jDCuF8Z5SYvHMvlLOU SeLw7DnMIA6LwCcmifVX90BlJjFJnJxxhR3CecQo0X9/HzvIGjYBG4kLD9+DrRQRKJBonbCK GcRmFvCUOH1qFViNsIClxKrdJ9kgaqwkmi90wNnHnh9lBLFZBFQlbtx7BtbLKxAj8XDpT7CZ QgKFEm+nvgebwwm0a+KLl0wgNqOArMSXxtVQu8Qlbj2ZzwTxtoDEkj3nmSFsUYmXj/+xQtQn S1y53Qc0hwMoriCx5K8kRImsxKX53eCAkRDYwiQx48YFdoiErsSHqVOh5vhKPLnxlA2i6ASj xNV7V6ESWhKnv/exQdjZEi+an7PBxDuOzGKawGg4C8l9ELaOxILdn9ggbG2JZQtfM88C+1lQ 4uTMJywLGFlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgSmloNbfhvsYHz53PEQowAHoxIP r4nTqigh1sSy4srcQ4wSHMxKIrz3C1dGCfGmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQ nliSmp2aWpBaBJNl4uCUamDUtqlK118T/uvur++1LXtqLm7gYZaetWNFYthEPvOim9w3z7x5 uNBAacaeSvE3ljGcq1e1yNsHeWySl+TpMC32a7G9J6nXL/4hRvRA8u8JN8OeNp9/4Nvpu3/C P4druaK2R5at2nFh+So3pq/J4gL+a2faere6ZmhoCFnviDt+3akyc0XooqdKLMUZiYZazEXF iQD4ceivKQMAAA== Archived-At: Subject: Re: [Cbor] Review of draft-jroatch-cbor-tags -07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 10:38:41 -0000 Thank you Jim and Paul for your reviews! Francesca > -----Original Message----- > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: den 13 mars 2018 19:55 > To: cbor@ietf.org > Cc: draft-jroatch-cbor-tags@ietf.org > Subject: Re: [Cbor] Review of draft-jroatch-cbor-tags -07 >=20 > I too have reviewed this. My main comment is not as specific as Jim's. >=20 > The endianness is going to be done wrong regardless of what you say, but = we > can cause it to be done more right with more use of MUST-filled language. > The last paragraph in Section 2.1 particularly concerns me. >=20 > Other than that, I think the document is in good shape, and it is quite > understandable. >=20 > --Paul Hoffman >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Mar 19 13:30:01 2018 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 99D7512D93F for ; Mon, 19 Mar 2018 13:29:59 -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, 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 Yh7N-Nl3f4PL for ; Mon, 19 Mar 2018 13:29:57 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF181129C6C for ; Mon, 19 Mar 2018 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2JKToM2003351; Mon, 19 Mar 2018 21:29:50 +0100 (CET) Received: from dhcp-8241.meeting.ietf.org (dhcp-8241.meeting.ietf.org [31.133.130.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 404njp3fWRzDWcW; Mon, 19 Mar 2018 21:29:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Mon, 19 Mar 2018 20:29:49 +0000 Cc: Francesca Palombini , cbor@ietf.org X-Mao-Original-Outgoing-Id: 543184187.980975-8a67eb538e17098a8150f2092768d012 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4D858E-F870-4C33-BB02-1944579584E9@tzi.org> References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 20:30:00 -0000 > For occurrences, the specification is in = https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#page-39 = (https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.2 does = not contain any statement saying the number of times a group needs to or = can match, except for the special case of =E2=80=9Cno occurrence = indicator"): The first paragraph of Section 3.2 seems pretty complete to me. What is = missing? > > An occurrence indicator modifies the group given to its right by > > requiring the group to match the sequence to be matched exactly for = a > > certain number of times (see Section 3.2) in sequence >=20 > This specification of occurrence indicators does *not* prevent the = group from matching a subsequence of items; it just says that if the = group matches the wrong number of times, the requirement isn't met. If = the specification intends to describe a more imperative algorithm where = groups stop matching after seeing some sequence elements, it needs to = say so, but unless this is done carefully, it probably leads to = dependencies on the order elements appear in a map. There is no dependence on the order in which key/value pairs (members) = appear in a CBOR map. The order in which entries are specified in a group that defines a CDDL = map, however, is relevant: > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.5.3 says >=20 > > once the map key matches the entry > > carrying the cut, other potential matches for the key that occur in > > later entries in the group of the map are no longer allowed. Right. > This describes map *keys* matching whole entries (=E2=80=9Ckey + = value"s), which doesn't make a lot of sense. Maybe I=E2=80=99m too tired, but I don=E2=80=99t see that right now. > I've been interpreting it as just matching against the entry's key = (but that doesn't work for group entries consisting of subgroups...), = and then it's pretty clear that { "a": 3, "b": 3} has two entries = matching the first group element of { ? tstr ^ =3D> int, any =3D> any }, = and then the occurrence indicator says that match doesn=E2=80=99t fit = the requirements. ? tstr ^ =3D> int, is looking for a member with a text key and an int = value. =20 Non-deterministically, it matches either member of the above map. (So the cut has no effect, as there is no failure.) The occurrence indicator is satisfied. The other member is then matched by the any =3D> any. Gr=C3=BC=C3=9Fe, Carsten >=20 > Jeffrey >=20 > On Sat, Mar 3, 2018 at 6:04 PM Carsten Bormann wrote: > I can't point to a specific sentence, but for a cut to be effective, = the match needs to occur first, and in this case the whole entry says = that can only happen once.=20 >=20 > Sent from mobile >=20 > On 3. Mar 2018, at 20:13, Jeffrey Yasskin = wrote: >=20 >> I don't have a particular use case in mind, so if you prefer to = ignore the cut after its occurrences are saturated, that's fine. Which = sentences in the specification specify that? >>=20 >> Thanks, >> Jeffrey >>=20 >> On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann wrote: >> (typing this from a mobile device) >>=20 >> Hi Jeffrey, >>=20 >> I do believe that the current matching rules indeed saturate the = optional group entry, so the cut does not apply to any additional = members. I think that is exactly as it should be. The requirements you = seem to be expressing are probably better solved by limiting the = wildcard instead. Can you be more specific about your use case? >>=20 >> Sent from mobile >>=20 >> On 2. Mar 2018, at 01:47, Jeffrey Yasskin = wrote: >>=20 >>> I haven't re-reviewed this draft fully, but I think an issue I'd = sent directly to Carsten is still present: if a map key type is = specified with both a cut and an occurrence indicator, and the = occurrence indicator is saturated, do subsequent keys matching the type = fall back to later entries? For example, does: >>>=20 >>> { >>> "a": 3 >>> "b": "cow" >>> } >>>=20 >>> match >>>=20 >>> { >>> ? tstr ^ =3D> int >>> any =3D> any >>> } >>>=20 >>> ? I think it shouldn't, but I don't see a collection of sentences in = the specification that specifies it. >>>=20 >>> Jeffrey >>>=20 >>>=20 >>>=20 >>> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini = wrote: >>> Dear CBOR WG, >>>=20 >>> As discussed during the past IETF meetings, and after the last = updates, the CDDL draft is ready for WGLC. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>>=20 >>> The WGLC will end by *13th of March*, please make sure to send your = comments to the list before then. >>>=20 >>> Best regards, >>> Francesca & Joe >>>=20 >>> > -----Original Message----- >>> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten = Bormann >>> > Sent: den 26 februari 2018 21:46 >>> > To: cbor@ietf.org >>> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt >>> > >>> > We have submitted draft-ietf-cbor-cddl-02.txt: >>> > >>> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 >>> > >>> > Diff from previous version at: >>> > >>> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt >>> > >>> > We believe that this is now ready for WGLC. >>> > (If we can start it quickly, the results of the call will be in = for discussion in >>> > London.) >>> > >>> > Gr=C3=BC=C3=9Fe, Carsten >>> > >>> > _______________________________________________ >>> > CBOR mailing list >>> > CBOR@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cbor >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >> _______________________________________________ >> 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 From nobody Tue Mar 20 06:22:41 2018 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 5D492124B17 for ; Tue, 20 Mar 2018 06:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 VOII5nc4Wk1Z for ; Tue, 20 Mar 2018 06:22:37 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FD61270AE for ; Tue, 20 Mar 2018 06:22:37 -0700 (PDT) Received: from [192.168.123.7] (cpe-76-90-60-238.socal.res.rr.com [76.90.60.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0C8152750B for ; Tue, 20 Mar 2018 09:22:35 -0400 (EDT) To: cbor@ietf.org References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> From: Sean Leonard Message-ID: <5c3d0c5d-b0cd-4672-f037-fd181c4d9134@seantek.com> Date: Tue, 20 Mar 2018 06:22:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cbor] CDDL: Solving the regexp issue X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 13:22:39 -0000 I have been meaning to respond to this, sorry for the long lag time. I disagree strongly with the dependency on XSD Regular Expressions. The primary technical argument is that XSD REs incorporate the definition of "XmlChar" (see also "normal character") aka XML character, which is extraordinarily convoluted (and does include certain ranges of Unicode code points, yet does not actually include all Unicode code points). Another such instance of Unicode accretion is "IsBlock", which allows for regular expressions that go through the Unicode Blocks.txt, which in combination with other Unicode source material, is not a reasonable dependency for smaller devices. ~~Proposal~~ My (tentative) proposal instead is to focus on POSIX Extended Regular Expressions instead: http://www.boost.org/doc/libs/1_50_0/libs/regex/doc/html/boost_regex/syntax/basic_extended.html https://en.wikibooks.org/wiki/Regular_Expressions/POSIX-Extended_Regular_Expressions http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_04 Technical arguments: * POSIX EREs appear to be a strict subset of Perl regular expression and PCRE technology. For example, POSIX character classes [:digit:] == \d are supported by PCRE. XSD does not support this. * AFAICT, there are no droppings from Unicode in the way that exist in XSD REs. * It means that the text can still refer to PCRE as an expectation (which aligns with RFC 7049), while defining a normative minimum conformance requirement. Non-technical arguments: * There is a valid normative reference for it. * POSIX ERE as a normative base doesn't actually change CDDL "v1.0" from "v0.x". Changing to XSD would actually change things, which (in my view) would then have to be changed back. Furthermore, there was impetus at the November meeting to remove syntax elements such as regular expressions from quoted strings, making them first-class parts of the grammar. This promotes readability and allows syntax highlighters the ability to highlight and validate such parts. So the text (taken from draft-greevenbosch-appsawg-cbor-cddl-11, prior to the XSD change) is proposed to read: 3.8.3.  Control operator .regexp    A ".regexp" control indicates that the text string given as a target    needs to match the regular expression given as a value in the    control type. POSIX Extended Regular Expressions are always supported.    PCRE and its full syntax are recommended as an implementation choice,    since [RFC7049] itself specifies PCRE.                  nai = tstr .regexp /^[:word:]+@[:word:]+(.[:word:]+)+$/                    Figure 9: Control with a POSIX ERE / PCRE regexp    The CDDL tool proposes:                        "N1@CH57HF.4Znqe0.dYJRN.igjf" Respectfully submitted, Sean On 1/24/2018 12:04 PM, Carsten Bormann wrote: > At IETF 100, we had a another discussion about regular expressions. > I don’t think we went home with a clear idea of how to solve this problem. > Giving up and just not doing regular expression in the first version of CDDL certainly was one choice. > But, since, there has been time to analyze the issue some more. > > Here is a proposal for addressing the regexp issue: > > https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor-cddl.html#rfc.section.3.8.3 > > Why use XSD REs? > > * There is a valid normative reference for them. > * There is precedent for using XSD REs in IETF specifications, e.g. in YANG (RFC 7950). > * They actually have been designed for the kind of use we are employing them for (albeit in an XML context). > * There are no undesirable UTF-16 droppings in XSD REs, as there would have been in JavaScript REs. > > The solution proposed works quite well and allows us to have a reasonable .regexp in the 1.0 CDDL RFC. > (It is just a tad less straightforward to implement than PCRE was. Oh well.) > > We can always add more controls for other RE types later. (This also provides a powerful incentive to continue coupling REs with the main extension point for the CDDL language: controls.) > > Grüße, Carsten > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Mar 20 06:23:05 2018 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 C5FC8126DED for ; Tue, 20 Mar 2018 06:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 N5EBSLi9w4aE for ; Tue, 20 Mar 2018 06:23:00 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 26768124B17 for ; Tue, 20 Mar 2018 06:22:55 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e195-v6so2397658ita.5 for ; Tue, 20 Mar 2018 06:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L/EvLjVMp710BDd5oq5gkRB8HcKPhBXQgpGafniYG2g=; b=lmcXDloowd9zh8CQewtKMlUewtHdqxPPwBPPnhceW9TYiNXBN8M8hCU7dTzf7ROyEg Zne/V+Kpa6m+xIATmqPiiZ8onjW0wX2DLZVvb0h/g3BcRkouAl/eT+2hDCdoiMo9+Z12 pwehUy7vsFK//lJxQpG9uV8y6/Zv6AxbE9nRc= 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=L/EvLjVMp710BDd5oq5gkRB8HcKPhBXQgpGafniYG2g=; b=A17gibnW5ZX4WWS1khRnx9RY1dSwlkTsV0thHphXV8LcCrYSQ0LTaQgW+zDr/2Mp6E 2WyK6IgJXViwiR8UpXb28EPuOfkfKhIvhOqYHtVqHtUriSuGvcC9Xh9omFx67EsuyHGn nc40w0S52/CAXpGIcqD3VO+kMOzNvd0ClLvisA0LBe/1oJJU7JI/SEvf3kyYTfmaFxRX CT13kVHaUU4PQCZJjTg2MtNGPxmhLStoOCjiulQbRKAKwjmIEBfcg2ZJCyuO/Vo81XDd lO8hk7hx+BJnqwZj9XGOUo7oAmxwNBOwQjfS0kEU/vA1p9M/Exl7vjQ/5PiuSPrlLa26 Mf2Q== X-Gm-Message-State: AElRT7GHtggyd3+CQ8STTVeXEoDYvfhL8ytp0Gl6ueik8Mlhb6lCOH7+ JtLAtidSRopw6u8f8TqDeK/1MFcSKSiyQKauigoHgA== X-Google-Smtp-Source: AG47ELtlyErKeCBWrT8QqgW5JtWjBdKvz8Bq0Wbz7sJI31Q1O6znXLSH91I7ND+rRTwCfIlNUPhgWs4HMXUmVZiMkl4= X-Received: by 2002:a24:3d55:: with SMTP id n82-v6mr2958652itn.31.1521552173733; Tue, 20 Mar 2018 06:22:53 -0700 (PDT) MIME-Version: 1.0 References: <4078F1DF-EB57-4FE1-A061-1498EEA14AAF@tzi.org> <59B322EA-913C-4933-822A-DAB7B1F64254@tzi.org> <2E4D858E-F870-4C33-BB02-1944579584E9@tzi.org> In-Reply-To: <2E4D858E-F870-4C33-BB02-1944579584E9@tzi.org> From: Jeffrey Yasskin Date: Tue, 20 Mar 2018 13:22:40 +0000 Message-ID: To: Carsten Bormann Cc: Jeffrey Yasskin , Francesca Palombini , cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000d352750567d7f88f" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-cddl?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 13:23:04 -0000 --000000000000d352750567d7f88f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 19, 2018 at 8:29 PM Carsten Bormann wrote: > > For occurrences, the specification is in > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#page-39 ( > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.2 does not > contain any statement saying the number of times a group needs to or can > match, except for the special case of =E2=80=9Cno occurrence indicator"): > > The first paragraph of Section 3.2 seems pretty complete to me. What is > missing? > Right now, "An optional _occurrence_ indicator can be given in front of a group entry. It is either one of the characters '?' (optional), '*' (zero or more), or '+' (one or more), or is of the form n*m, where n and m are optional unsigned integers and n is the lower limit (default 0) and m is the upper limit (default no limit) of occurrences." successfully describes the meaning of an occurrence indicator, but doesn't tie that to the meaning of group entries at all. (Saying that they appear next to each other doesn't specify that their meanings are connected.) Perhaps, "A group matches a collection of CBOR items if and only if each group entry can be repeated a number of times allowed by its occurrence indicator, and then paired 1-1 with a CBOR item (in an array) or key/value pair of CBOR items (in a map) that matches it." This doesn't have the semantics you want for cuts, though, so you'll have to write a different specification. I suspect this specification also implies an exponential algorithm for checking map items, but I haven't proven that, and it's not obvious whether that should disqualify it for the RFC. > > An occurrence indicator modifies the group given to its right by > > > requiring the group to match the sequence to be matched exactly for a > > > certain number of times (see Section 3.2) in sequence > > > > This specification of occurrence indicators does *not* prevent the grou= p > from matching a subsequence of items; it just says that if the group > matches the wrong number of times, the requirement isn't met. If the > specification intends to describe a more imperative algorithm where group= s > stop matching after seeing some sequence elements, it needs to say so, bu= t > unless this is done carefully, it probably leads to dependencies on the > order elements appear in a map. > > There is no dependence on the order in which key/value pairs (members) > appear in a CBOR map. I agree this is a requirement on whatever specification text the RFC eventually contains. > The order in which entries are specified in a group that defines a CDDL > map, however, is relevant: > > > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02#section-3.5.3 says > > > > > once the map key matches the entry > > > carrying the cut, other potential matches for the key that occur in > > > later entries in the group of the map are no longer allowed. > > Right. > > > This describes map *keys* matching whole entries (=E2=80=9Ckey + value"= s), which > doesn't make a lot of sense. > > Maybe I=E2=80=99m too tired, but I don=E2=80=99t see that right now. > "the map key matches the entry" is impossible because entries include at least both a key and a value, and if the entry is a group, several keys and values. Unless you can point to a sentence in the specification that describes how key items match group entries? You or me having intuition about it isn't sufficient for an RFC. > > I've been interpreting it as just matching against the entry's key (but > that doesn't work for group entries consisting of subgroups...), and then > it's pretty clear that { "a": 3, "b": 3} has two entries matching the fir= st > group element of { ? tstr ^ =3D> int, any =3D> any }, and then the occurr= ence > indicator says that match doesn=E2=80=99t fit the requirements. > > ? tstr ^ =3D> int, is looking for a member with a text key and an int val= ue. > Non-deterministically, it matches either member of the above map. > (So the cut has no effect, as there is no failure.) > The occurrence indicator is satisfied. > The other member is then matched by the any =3D> any. > The occurrence semantics I wrote above does cause { ? tstr ^ =3D> int, any = =3D> any } to match { "a": 3, "b": 3} because we rewrite the rule to { tstr ^ = =3D> int, any =3D> any }, and then the entries match 1-1. For this, the definiti= on of a map cut would need to explicitly say that once an entry with a cut has been matched, it doesn't affect further matches. However, the above group semantics makes a cut on a *'ed entry stop working entirely: {*tstr =3D> int, *any =3D> any} matches {"a": "b"} because we rewrite the r= ule to {any =3D> any}, which matches. {? a: int, *any =3D> any} also matches {"= a": "q"}. Jeffrey Gr=C3=BC=C3=9Fe, Carsten > > > > > > Jeffrey > > > > On Sat, Mar 3, 2018 at 6:04 PM Carsten Bormann wrote: > > I can't point to a specific sentence, but for a cut to be effective, th= e > match needs to occur first, and in this case the whole entry says that ca= n > only happen once. > > > > Sent from mobile > > > > On 3. Mar 2018, at 20:13, Jeffrey Yasskin wrote= : > > > >> I don't have a particular use case in mind, so if you prefer to ignore > the cut after its occurrences are saturated, that's fine. Which sentences > in the specification specify that? > >> > >> Thanks, > >> Jeffrey > >> > >> On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann wrote: > >> (typing this from a mobile device) > >> > >> Hi Jeffrey, > >> > >> I do believe that the current matching rules indeed saturate the > optional group entry, so the cut does not apply to any additional members= . > I think that is exactly as it should be. The requirements you seem to be > expressing are probably better solved by limiting the wildcard instead. C= an > you be more specific about your use case? > >> > >> Sent from mobile > >> > >> On 2. Mar 2018, at 01:47, Jeffrey Yasskin > wrote: > >> > >>> I haven't re-reviewed this draft fully, but I think an issue I'd sent > directly to Carsten is still present: if a map key type is specified with > both a cut and an occurrence indicator, and the occurrence indicator is > saturated, do subsequent keys matching the type fall back to later entrie= s? > For example, does: > >>> > >>> { > >>> "a": 3 > >>> "b": "cow" > >>> } > >>> > >>> match > >>> > >>> { > >>> ? tstr ^ =3D> int > >>> any =3D> any > >>> } > >>> > >>> ? I think it shouldn't, but I don't see a collection of sentences in > the specification that specifies it. > >>> > >>> Jeffrey > >>> > >>> > >>> > >>> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini < > francesca.palombini@ericsson.com> wrote: > >>> Dear CBOR WG, > >>> > >>> As discussed during the past IETF meetings, and after the last > updates, the CDDL draft is ready for WGLC. > >>> > >>> https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 > >>> > >>> The WGLC will end by *13th of March*, please make sure to send your > comments to the list before then. > >>> > >>> Best regards, > >>> Francesca & Joe > >>> > >>> > -----Original Message----- > >>> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten > Bormann > >>> > Sent: den 26 februari 2018 21:46 > >>> > To: cbor@ietf.org > >>> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.txt > >>> > > >>> > We have submitted draft-ietf-cbor-cddl-02.txt: > >>> > > >>> > https://tools.ietf.org/html/draft-ietf-cbor-cddl-02 > >>> > > >>> > Diff from previous version at: > >>> > > >>> > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt > >>> > > >>> > We believe that this is now ready for WGLC. > >>> > (If we can start it quickly, the results of the call will be in for > discussion in > >>> > London.) > >>> > > >>> > Gr=C3=BC=C3=9Fe, Carsten > >>> > > >>> > _______________________________________________ > >>> > CBOR mailing list > >>> > CBOR@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/cbor > >>> _______________________________________________ > >>> CBOR mailing list > >>> CBOR@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cbor > >>> _______________________________________________ > >>> CBOR mailing list > >>> CBOR@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cbor > >> _______________________________________________ > >> 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 > > --000000000000d352750567d7f88f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 19= , 2018 at 8:29 PM Carsten Bormann <cabo@tzi.org> wrote:
> For occurrences, the specification is in https://tools.ietf.org/html/draft-ietf-cbor-c= ddl-02#page-39 (https://tools.iet= f.org/html/draft-ietf-cbor-cddl-02#section-3.2 does not contain any sta= tement saying the number of times a group needs to or can match, except for= the special case of =E2=80=9Cno occurrence indicator"):

The first paragraph of Section 3.2 seems pretty complete to me.=C2=A0 What = is missing?

Right now, "An optional= _occurrence_ indicator can be given in front of a group entry.=C2=A0 It is= either one of the characters '?' (optional), '*' (zero or = more), or '+' (one or more), or is of the form n*m, where n and m a= re optional unsigned integers and n is the lower limit (default 0) and m is= the upper limit (default no limit) of occurrences." successfully desc= ribes the meaning of an occurrence indicator, but doesn't tie that to t= he meaning of group entries at all. (Saying that they appear next to each o= ther doesn't specify that their meanings are connected.)

Perhaps, "A group matches a colle= ction of CBOR items if and only if each group entry can be repeated a numbe= r of times allowed by its occurrence indicator, and then paired 1-1 with a = CBOR item (in an array) or key/value pair of CBOR items (in a map) that mat= ches it." This doesn't have the semantics you want for cuts, thoug= h, so you'll have to write a different specification.
I suspect this specification also implies an exponential algori= thm for checking map items, but I haven't proven that, and it's not= obvious whether that should disqualify it for the RFC.

> > An occurrence indicator modifies the group given to its right by<= br> > > requiring the group to match the sequence to be matched exactly f= or a
> > certain number of times (see Section 3.2) in sequence
>
> This specification of occurrence indicators does *not* prevent the gro= up from matching a subsequence of items; it just says that if the group mat= ches the wrong number of times, the requirement isn't met. If the speci= fication intends to describe a more imperative algorithm where groups stop = matching after seeing some sequence elements, it needs to say so, but unles= s this is done carefully, it probably leads to dependencies on the order el= ements appear in a map.

There is no dependence on the order in which key/value pairs (members) appe= ar in a CBOR map.

I agree this is a require= ment on whatever specification text the RFC eventually contains.
= =C2=A0
The order in which entries are specified in a group that defines a CDDL map= , however, is relevant:

> https://tools.ietf.org/html/dr= aft-ietf-cbor-cddl-02#section-3.5.3 says
>
> > once the map key matches the entry
> > carrying the cut, other potential matches for the key that occur = in
> > later entries in the group of the map are no longer allowed.

Right.

> This describes map *keys* matching whole entries (=E2=80=9Ckey + value= "s), which doesn't make a lot of sense.

Maybe I=E2=80=99m too tired, but I don=E2=80=99t see that right now.

"the map key matches the entry" is = impossible because entries include at least both a key and a value, and if = the entry is a group, several keys and values. Unless you can point to a se= ntence in the specification that describes how key items match group entrie= s? You or me having intuition about it isn't sufficient for an RFC.
=C2=A0
> I've been interpreting it as just matching against the entry's= key (but that doesn't work for group entries consisting of subgroups..= .), and then it's pretty clear that { "a": 3, "b": = 3} has two entries matching the first group element of { ? tstr ^ =3D> i= nt, any =3D> any }, and then the occurrence indicator says that match do= esn=E2=80=99t fit the requirements.

? tstr ^ =3D> int, is looking for a member with a text key and an int va= lue.
Non-deterministically, it matches either member of the above map.
(So the cut has no effect, as there is no failure.)
The occurrence indicator is satisfied.
The other member is then matched by the any =3D> any.

The occurrence semantics I wrote above does cause=C2=A0{ ? tstr ^ =3D> int, any =3D> any } to match = { "a": 3, "b": 3} because we = rewrite the rule to=C2=A0{ tstr ^ =3D> int, an= y =3D> any }, and then the entries match 1-1. For this, th= e definition of a map cut would need to explicitly say that once an entry w= ith a cut has been matched, it doesn't affect further matches.

However, the above group semantics makes a cut on a *'ed entry = stop working entirely:

{*tstr =3D> int, *any =3D> any= } matches {"a": "b"} because we rewrite the rule to {an= y =3D> any}, which matches. {? a: int, *any =3D> any} also matches {&= quot;a": "q"}.
Jeffrey

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


>
> Jeffrey
>
> On Sat, Mar 3, 2018 at 6:04 PM Carsten Bormann <cabo@tzi.org> wrote:
> I can't point to a specific sentence, but for a cut to be effectiv= e, the match needs to occur first, and in this case the whole entry says th= at can only happen once.
>
> Sent from mobile
>
> On 3. Mar 2018, at 20:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
>
>> I don't have a particular use case in mind, so if you prefer t= o ignore the cut after its occurrences are saturated, that's fine. Whic= h sentences in the specification specify that?
>>
>> Thanks,
>> Jeffrey
>>
>> On Sat, Mar 3, 2018, 12:07 AM Carsten Bormann <cabo@tzi.org> wrote:
>> (typing this from a mobile device)
>>
>> Hi Jeffrey,
>>
>> I do believe that the current matching rules indeed saturate the o= ptional group entry, so the cut does not apply to any additional members.= =C2=A0 I think that is exactly as it should be. The requirements you seem t= o be expressing are probably better solved by limiting the wildcard instead= . Can you be more specific about your use case?
>>
>> Sent from mobile
>>
>> On 2. Mar 2018, at 01:47, Jeffrey Yasskin <jyasskin@chromium.org> wrote:=
>>
>>> I haven't re-reviewed this draft fully, but I think an iss= ue I'd sent directly to Carsten is still present: if a map key type is = specified with both a cut and an occurrence indicator, and the occurrence i= ndicator is saturated, do subsequent keys matching the type fall back to la= ter entries? For example, does:
>>>
>>> {
>>>=C2=A0 =C2=A0"a": 3
>>>=C2=A0 =C2=A0"b": "cow"
>>> }
>>>
>>> match
>>>
>>> {
>>>=C2=A0 =C2=A0? tstr ^ =3D> int
>>>=C2=A0 =C2=A0any =3D> any
>>> }
>>>
>>> ? I think it shouldn't, but I don't see a collection o= f sentences in the specification that specifies it.
>>>
>>> Jeffrey
>>>
>>>
>>>
>>> On Tue, Feb 27, 2018 at 12:28 AM Francesca Palombini <francesca.= palombini@ericsson.com> wrote:
>>> Dear CBOR WG,
>>>
>>> As discussed during the past IETF meetings, and after the last= updates, the CDDL draft is ready for WGLC.
>>>
>>> https://tools.ietf.org/html/draft-ie= tf-cbor-cddl-02
>>>
>>> The WGLC will end by *13th of March*, please make sure to send= your comments to the list before then.
>>>
>>> Best regards,
>>> Francesca & Joe
>>>
>>> > -----Original Message-----
>>> > From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Carsten Borman= n
>>> > Sent: den 26 februari 2018 21:46
>>> > To: cb= or@ietf.org
>>> > Subject: [Cbor] Ready for WGLC: draft-ietf-cbor-cddl-02.t= xt
>>> >
>>> > We have submitted draft-ietf-cbor-cddl-02.txt:
>>> >
>>> > https://tools.ietf.org/html/dra= ft-ietf-cbor-cddl-02
>>> >
>>> > Diff from previous version at:
>>> >
>>> > https://tools.iet= f.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-02.txt
>>> >
>>> > We believe that this is now ready for WGLC.
>>> > (If we can start it quickly, the results of the call will= be in for discussion in
>>> > London.)
>>> >
>>> > Gr=C3=BC=C3=9Fe, Carsten
>>> >
>>> > _______________________________________________
>>> > CBOR mailing list
>>> > CBOR@i= etf.org
>>> > https://www.ietf.org/mailman/listinfo/cb= or
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/cbor
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/cbor
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor > _______________________________________________
> CBOR mailing list
> CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor

--000000000000d352750567d7f88f-- From nobody Wed Mar 21 07:39:51 2018 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 8D6C412DA6C for ; Wed, 21 Mar 2018 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 xiHxkea6O3SA for ; Wed, 21 Mar 2018 07:39:46 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890F312DA6A for ; Wed, 21 Mar 2018 07:39:46 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id m83so6914347ioi.8 for ; Wed, 21 Mar 2018 07:39:46 -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=MdhzRSTXAMyaFEDbEAlBCTg3n2jagF3ZtOR13GdSo/U=; b=FuZHTdHruOMpqkuH0atOt41OLGOLhCnuhcuZ8LbvnKQATHiIh8Cjw2Ivmn2q/1i93q 0EoHSsCjafe8NIGi2+QpUuxMwpqjyKyIAyLX1ENZZe8gW0OJW5NOSvXIj4lG/Qn104d8 2BQylVVLRwvnehUL/q3uwBHt1Cs1qepcef4E9sGi8CFoVveWySHOFVTLgTGge2634Qp8 FGkSMfG22XuJjp9nEhLPju4s8zFVoZnYJpybrqBH6Rxq6F3wCiYewm+L90vNNiboAQfx +kjjRgBcHJd8ZeXRhTR7nAUGivCINKzgz69lfOoekpRsCdMxRxbC/21VmfUn9SBRwz+c lvYQ== 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=MdhzRSTXAMyaFEDbEAlBCTg3n2jagF3ZtOR13GdSo/U=; b=Z8c3XBB/DTiDzoHOOa9Zwcx+5A9otyc2mi6kwlJPslJc8luYb4Yef3VqpblcLwqJig ouqh3o8boqSmb0CjCQk4Zlumc60VXf517CuVUWYIfYRYo8kc5m17lxRxRPhU4buPiImj xndK2iWXfUxbc9GnKAtrPKMQyWy18VO3dOvh5NkOBiU1RW9JaYnnoWZ31S+lgOw6xE4j PclPhlk/nUUN3I9pQISf4bdArxGna07ft/JGoJ4p1yEJmgEHxXatsPJEL72nvLl1AzXL hPEJTBPuDBvNh/H9vo8hw8VXEAxykap+zGmEqTKZaS9t7l+qNjNPfK7JBNWBPdETBHrW oYbg== X-Gm-Message-State: AElRT7GqJXKmXtuYf2c2OKUGp1qYrzdmSYHRTNVXHdCXi41rFlPJO/lt KVfgVcGnrRPQ6F0O9nZJt7gKc90rPzCJcs74ONCfUpU/DZA= X-Google-Smtp-Source: AG47ELtNp6ayLN1G41dKDGVOj03QnuFpU5j801SiGFbOM4wh8YwnHHLMMTf5fSJGKtfPdC6xhgKFs+tZ/vIAbPVkHXU= X-Received: by 10.107.51.207 with SMTP id z198mr21954989ioz.112.1521643185214; Wed, 21 Mar 2018 07:39:45 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Wed, 21 Mar 2018 14:39:31 +0000 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a11441a96889c760567ed29c9" Archived-At: Subject: [Cbor] Ambiguities in CDDL specifiction X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 14:39:49 -0000 --001a11441a96889c760567ed29c9 Content-Type: text/plain; charset="UTF-8" I've filed a collection of issues against CDDL where parts seem ambiguous. - groups: https://github.com/cbor-wg/cddl/issues/14 - .size: https://github.com/cbor-wg/cddl/issues/15 - types of numbers: https://github.com/cbor-wg/cddl/issues/16 - .eq and .ne: https://github.com/cbor-wg/cddl/issues/18 One thing that happens when you write a specification formally, is that you discover ambiguities that hid in a more colloquial draft, so I'm not sure this is everything, but it's all I've found. I am worried that some readers will miss that Appendix C exists, and will read uses of CDDL in other specs incorrectly as a result, but fixing that is probably as much work as making the whole spec rigorous. As discussed in the face-to-face meeting, while I'd rather wait to publish the CDDL RFC until it's rigorous so that I can use it in web specifications, the working group has heard my argument and disagrees, and that's all right. Jeffrey --001a11441a96889c760567ed29c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've filed a collection of issues against CDDL wh= ere parts seem ambiguous.
One thing that happens when you write a specification = formally, is that you discover ambiguities that hid in a more colloquial dr= aft, so I'm not sure this is everything, but it's all I've foun= d.

I am worried that some readers will miss that A= ppendix C exists, and will read uses of CDDL in other specs incorrectly as = a result, but fixing that is probably as much work as making the whole spec= rigorous.

As discussed in the face-to-face = meeting, while I'd rather wait to publish the CDDL RFC until it's r= igorous so that I can use it in web specifications, the working group has h= eard my argument and disagrees, and that's all right.

Jeffrey
--001a11441a96889c760567ed29c9-- From nobody Wed Mar 21 07:51:11 2018 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 672D2126E64 for ; Wed, 21 Mar 2018 07:51:08 -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, 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 LrUb8Wur6PbK for ; Wed, 21 Mar 2018 07:51:07 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0275A127419 for ; Wed, 21 Mar 2018 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2LEp2WJ029885; Wed, 21 Mar 2018 15:51:02 +0100 (CET) Received: from [IPv6:2001:638:708:18::7a] (unknown [IPv6:2001:638:708:18::7a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 405t5y04kWzDX3g; Wed, 21 Mar 2018 15:51:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 21 Mar 2018 14:51:01 +0000 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 543336659.7125731-5027e5260d8d111667178108f2cfa067 Content-Transfer-Encoding: quoted-printable Message-Id: <446A28DC-CD65-4F62-AE36-1239B4F62F85@tzi.org> References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Ambiguities in CDDL specifiction X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 14:51:08 -0000 On Mar 21, 2018, at 14:39, Jeffrey Yasskin wrote: >=20 > I've filed a collection of issues against CDDL where parts seem = ambiguous. > =E2=80=A2 groups: https://github.com/cbor-wg/cddl/issues/14 > =E2=80=A2 .size: https://github.com/cbor-wg/cddl/issues/15 > =E2=80=A2 types of numbers: = https://github.com/cbor-wg/cddl/issues/16 > =E2=80=A2 .eq and .ne: https://github.com/cbor-wg/cddl/issues/18 Thank you, this is very useful input. > One thing that happens when you write a specification formally, is = that you discover ambiguities that hid in a more colloquial draft, so = I=E2=80=99m not sure this is everything, but it's all I've found. Barring formal semantics (hint for bright young grad students :-), we = will always have uncertainties on an English language specification. > I am worried that some readers will miss that Appendix C exists, and = will read uses of CDDL in other specs incorrectly as a result, but = fixing that is probably as much work as making the whole spec rigorous. Lots of people write ABNF specifications without fully understanding the = implications of grammars=E2=80=A6 There is no way we can avoid the situation that CDDL is used by people = who haven=E2=80=99t invested the time to learn all its intricacies (as = few of those as there are); I actually think that this is a good thing. > As discussed in the face-to-face meeting, while I=E2=80=99d rather = wait to publish the CDDL RFC until it's rigorous so that I can use it in = web specifications, the working group has heard my argument and = disagrees, and that's all right. I=E2=80=99d rather not wait, instead make it rigorous fast, and publish = it=E2=80=A6 Let=E2=80=99s work on this the next couple of weeks. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 22 12:11:26 2018 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 B88B9126E01 for ; Thu, 22 Mar 2018 12:11:24 -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] 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 Q1ceCF2yB659 for ; Thu, 22 Mar 2018 12:11:22 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 CBB7B126DCA for ; Thu, 22 Mar 2018 12:11:22 -0700 (PDT) Received: from [2001:67c:370:128:e5ae:39f6:ccf8:5634] (port=35602 helo=cho.localnet) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ez5cP-00084e-7y; Thu, 22 Mar 2018 19:11:21 +0000 From: Jim Hague To: cbor@ietf.org Cc: Sean Leonard Date: Thu, 22 Mar 2018 19:11:17 +0000 Message-ID: <3645996.TIld9bUl5u@cho> Organization: Sinodun Ltd X-Face: "YyOu7Hab"VGm^bAO1; {iOPso3{hw9JL`&?c6?!@&m`z?E\ZMv; T44B_v+/9i''$IUz\h: 7+|+U\Sm3S)ajt}IU6bG#OB^ma3dQ%l4]6jGS1:=9N]LF\ZmxO!"2bQ}v@,\x?0{/mu; a, g3:!#KL>aL\D; )@?UJG=m@@vt; LJJxqV.w-.VxYKp-r1'$`0+>4D72C#o5(tax+Dp:0UWU ]+s_'{u[#cEm^9VXGTf0+#@VwB/%U?KWb~C<@19. References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <5c3d0c5d-b0cd-4672-f037-fd181c4d9134@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-BlackCat-Spam-Score: 9 Archived-At: Subject: Re: [Cbor] CDDL: Solving the regexp issue X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 19:11:25 -0000 On Tuesday, 20 March 2018 13:22:14 GMT Sean Leonard wrote: > Technical arguments: > * POSIX EREs appear to be a strict subset of Perl regular expression and > PCRE technology. For example, POSIX character classes [:digit:] == \d > are supported by PCRE. XSD does not support this. POSIX ERE's aren't quite a strict subset of PCRE (which in turn AIUI aren't in fact 100% Perl-compatible). Specifically, POSIX always looks for the longest of a left-most match while PCRE stops on the first valid match. Friedl gives the example pattern 'one(self)?(selfsufficient)?' matching the string 'oneselfsufficient' - PCRE matches 'oneself' while POSIX ERE matches 'oneselfsufficient'. XSD isn't wonderful, but comparing the differences between XSD, POSIX ERE and PCRE2 via https://www.regular-expressions.info/refbasic.html I have to (reluctantly) conclude that for a normative reference XSD is closer match for basic regex use, while quietly praying that everyone actually implements a PCRE2 option. -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Thu Mar 22 14:12:11 2018 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 AF51012706D for ; Thu, 22 Mar 2018 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 AYuUVT8W-CzC for ; Thu, 22 Mar 2018 14:12:07 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.249]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE96C12426E for ; Thu, 22 Mar 2018 14:12:07 -0700 (PDT) Received: from [192.168.122.118] (ip174-65-80-226.sd.sd.cox.net [174.65.80.226]) (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 81E9C27505; Thu, 22 Mar 2018 17:12:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Sean Leonard In-Reply-To: <3645996.TIld9bUl5u@cho> Date: Thu, 22 Mar 2018 14:12:04 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <5c3d0c5d-b0cd-4672-f037-fd181c4d9134@seantek.com> <3645996.TIld9bUl5u@cho> To: Jim Hague X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Cbor] CDDL: Solving the regexp issue X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 21:12:10 -0000 > On Mar 22, 2018, at 12:11 PM, Jim Hague wrote: >=20 > On Tuesday, 20 March 2018 13:22:14 GMT Sean Leonard wrote: >> Technical arguments: >> * POSIX EREs appear to be a strict subset of Perl regular expression = and >> PCRE technology. For example, POSIX character classes [:digit:] =3D=3D = \d >> are supported by PCRE. XSD does not support this. >=20 > POSIX ERE's aren't quite a strict subset of PCRE (which in turn AIUI = aren't in=20 > fact 100% Perl-compatible). Specifically, POSIX always looks for the = longest=20 > of a left-most match while PCRE stops on the first valid match. Friedl = gives=20 > the example pattern 'one(self)?(selfsufficient)?' matching the string=20= > 'oneselfsufficient' - PCRE matches 'oneself' while POSIX ERE matches=20= > 'oneselfsufficient'. >=20 > XSD isn't wonderful, but comparing the differences between XSD, POSIX = ERE and=20 > PCRE2 via https://www.regular-expressions.info/refbasic.html I have = to=20 > (reluctantly) conclude that for a normative reference XSD is closer = match for=20 > basic regex use, while quietly praying that everyone actually = implements a=20 > PCRE2 option. Hi Jim, This is a well-stated technical argument so I appreciate that. I looked closely at the pattern matching, however, and find some flaws = that need to be addressed. First of all, the Friedl example pattern you gave: > one(self)?(selfsufficient)? matches the following strings (irrespective of greediness): one oneself =3D> $1 =3D =E2=80=9Cself=E2=80=9D oneselfsufficient =3D> $1 =3D =E2=80=9C=E2=80=9D $2 =3D = =E2=80=9Cselfsufficient=E2=80=9D) oneselfselfsufficient =3D> $1 =3D =E2=80=9Cself=E2=80=9D $2 =3D = =E2=80=9Cselfsufficient=E2=80=9D oneselfselfsufficiently =3D> $1 =3D =E2=80=9Cself=E2=80=9D $2 =3D = =E2=80=9Cselfsufficient=E2=80=9D So, with respect to the input: > oneselfsufficient the first three strings: one oneself oneselfsufficient all potentially match. Which one is returned depends on the = implementation. I ran the differences through some online regex analyzers, my local bash = prompt, and RegexBuddy v4 (tests pretty much everything under the sun: a = very worthwhile tool). POSIX ERE does indeed look for the longest of the leftmost match = (matches =E2=80=9Coneselfsufficient=E2=80=9D); PCRE stops on the first = valid match (matches =E2=80=9Coneself=E2=80=9D). But running the test on =E2=80=9CXML Schema=E2=80=9D matches = =E2=80=9Coneselfsufficient=E2=80=9D, not =E2=80=9Coneself=E2=80=9D! So = actually the XSD reliance itself is problematic. The reason appears to = be because XSD has no concept of anchoring. Further inspection reveals = that that XSD also does not support word boundaries or lookaround. These = flaws, in combination with the =E2=80=9CUnicode droppings=E2=80=9D, just = hammer the nails in the coffin for XSD in my mind. The better way forward now appears to be go to back to PCRE/PCRE2, and = just deal with the reference issue directly. On that front, PCRE/PCRE2 are BSD 2-clause licensed. There is also the = public documentation: https://www.pcre.org/pcre2.txt which itself ought to suffice for documentation. I mean, the ZIP file = format is standardized across many SDOs (including this one) based on = PKWare=E2=80=99s APPNOTE.txt, so I see reliance on pcre.txt/pcre2.txt as = better than that situation. See also pcresyntax, pcrepattern. Sean > --=20 > Jim Hague - jim@sinodun.com Never trust a computer you can't = lift. >=20 From nobody Fri Mar 23 10:04:33 2018 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 8A7FA12D948 for ; Fri, 23 Mar 2018 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 OQuO8UuXnRhV for ; Fri, 23 Mar 2018 10:04:29 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 7B1541200FC for ; Fri, 23 Mar 2018 10:04:29 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b20so15972512iof.5 for ; Fri, 23 Mar 2018 10:04:29 -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=D/uVZmCa8Z3rHltOPg2ynva/O705X/waLIYowlGZGTg=; b=AtGOGKMg9fnMEJPPQOJhqWRNTl7zvAgZPGJycdcNmVynI/BHeMVgOQEOPgGl05IRxQ Nw2wWNR3yTuVttpFEg7wOhhUNH4D8MBnhgxgtrsBPbAE532pkUVsvwwFHxKt7K/rlBpE CGelnqBDHisyZPcof7GR2XlNdFkampLrhQc01ItWrG80cSzHWSkj2xV4snbtW60ZXfQZ TX71AY1vtWdMY2lGtClraoGZ/vmpcAcMG71dJp6j46VscC3fpuezX+zuCGwR406ZOOS9 7QI8heWG06NZC/biE3vRNB/cizNplWTFUFz5Rdoz2paAy/fuFJmXVZr/Q+lqIRrfge6K 0o0A== 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=D/uVZmCa8Z3rHltOPg2ynva/O705X/waLIYowlGZGTg=; b=PeHmlo0Zzh4/5BklpWioEn/sQwsVSN41yLE9id28nKOwWD/H68TzsKyZC11N9AvVBo 58FwVKykPDR+1uZk88XzV0+bUlGARr0FlG1gH27XPg89hpbubrDaSP/N1l8ErvaU6qx/ txDH0BD16ADnNKO9B5IR193kMwT79fvKufkuklgwIEpcaj9TEcA/WV42lAwOJVDXVRXE tS0nLdYQzdNFEUWvojvsv4H5VhA1waN/od5rdgCASLH3S/PZb2dNDaFL0fj42mcshUfL fRWs8J24s6nyQlweEirmGtRTMqFs5WzuU0+4PZwYdMVIyRD6P4snCFvs+J8f5wbdYfMQ YwHw== X-Gm-Message-State: AElRT7EI84Iu3Z+GJW7lKyJMwWVhXzPC57nCr7L1ROX40WuyHRonkPcI H8tbM63YgfwSouKdapw73NmIu5Gddb7hAf9LSxB5tyUVdLI= X-Google-Smtp-Source: AG47ELtzMiWMtGbifaCbTxTtmER44mLgvHJQjwcR9PlF0YSfbBDRTHNvxtsNNZIYumXacqFaqVeMYcuuFFIw/xI5Ido= X-Received: by 10.107.51.207 with SMTP id z198mr32103942ioz.112.1521824665243; Fri, 23 Mar 2018 10:04:25 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Fri, 23 Mar 2018 17:04:11 +0000 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a11441a96968b300568176a3c" Archived-At: Subject: [Cbor] Making CBOR parsing more rigorous X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 17:04:31 -0000 --001a11441a96968b300568176a3c Content-Type: text/plain; charset="UTF-8" I have a collection of PRs against CBORbis to try to make parsing more rigorous, to deal with objections from web spec owners like https://github.com/mozilla/standards-positions/issues/29#issuecomment-334376573. I haven't yet run these changes by a web spec person to make sure they're complete, so there might be another set of PRs coming after these are in. https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define which kinds of CBOR parsers need to detect which errors in the encoded data, and which errors are recoverable. The basic idea is to classify encoded CBOR data into valid, invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed categories, and then use that in this and derived specifications to describe parser behavior precisely. A question came up whether we can give an item's "unsigned integer" a better name. Any ideas? https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds of tagged items are valid. Let me know what you think. Approving PRs is probably helpful to the editors even if you have no comments. Thanks, Jeffrey --001a11441a96968b300568176a3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a collection of PRs against CBORbis to try to make = parsing more rigorous, to deal with objections from web spec owners like=C2= =A0https://github.com/mozilla/standards-positions/issues/2= 9#issuecomment-334376573. I haven't yet run these changes by a web = spec person to make sure they're complete, so there might be another se= t of PRs coming after these are in.

https://github.com/cbor-wg/CBORbis/pull/= 17 has a lot of changes to define which kinds of CBOR parsers need to d= etect which errors in the encoded data, and which errors are recoverable.

The basic idea is to classify encoded CBOR data= into valid, invalid-but-well-formed, recoverably-ill-formed, and fatally-i= ll-formed categories, and then use that in this and derived specifications = to describe parser behavior precisely.

A question = came up whether we can give an item's "unsigned integer" a be= tter name. Any ideas?

https://github.com/cbor-wg/CBORbis/pull/18 d= efines when the known kinds of tagged items are valid.=C2=A0

=
Let me know what you think. Approving PRs is probably helpful to= the editors even if you have no comments.=

Thanks,
Jeffrey

--001a11441a96968b300568176a3c-- From nobody Wed Mar 28 08:09:28 2018 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 0C161127286 for ; Wed, 28 Mar 2018 08:09:27 -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] 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 YX09OIv4siMW for ; Wed, 28 Mar 2018 08:09:24 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 89DF5124F57 for ; Wed, 28 Mar 2018 08:09:24 -0700 (PDT) Received: from [212.250.200.103] (port=50402 helo=cho.localnet) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f1ChP-0001wG-Iz; Wed, 28 Mar 2018 16:09:19 +0100 From: Jim Hague To: Sean Leonard Cc: cbor@ietf.org Date: Wed, 28 Mar 2018 16:09:08 +0100 Message-ID: <4144163.jR6knkXPVo@cho> Organization: Sinodun Ltd X-Face: "YyOu7Hab"VGm^bAO1; {iOPso3{hw9JL`&?c6?!@&m`z?E\ZMv; T44B_v+/9i''$IUz\h: 7+|+U\Sm3S)ajt}IU6bG#OB^ma3dQ%l4]6jGS1:=9N]LF\ZmxO!"2bQ}v@,\x?0{/mu; a, g3:!#KL>aL\D; )@?UJG=m@@vt; LJJxqV.w-.VxYKp-r1'$`0+>4D72C#o5(tax+Dp:0UWU ]+s_'{u[#cEm^9VXGTf0+#@VwB/%U?KWb~C<@19. References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Cbor] CDDL: Solving the regexp issue X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 15:09:27 -0000 Hi Sean, Apologies for the delay in responding. On Thursday, 22 March 2018 21:12:04 BST Sean Leonard wrote: > I looked closely at the pattern matching, however, and find some flaws th= at > need to be addressed. > First of all, the Friedl example pattern you gave: > > one(self)?(selfsufficient)? >=20 > matches the following strings (irrespective of greediness): >=20 > one > oneself =3D> $1 =3D =E2=80=9Cself=E2=80=9D > oneselfsufficient =3D> $1 =3D =E2=80=9C=E2=80=9D $2 =3D =E2=80=9Cselfsuf= ficient=E2=80=9D) > oneselfselfsufficient =3D> $1 =3D =E2=80=9Cself=E2=80=9D $2 =3D =E2=80= =9Cselfsufficient=E2=80=9D > oneselfselfsufficiently =3D> $1 =3D =E2=80=9Cself=E2=80=9D $2 =3D =E2=80= =9Cselfsufficient=E2=80=9D >=20 > So, with respect to the input: > > oneselfsufficient >=20 > the first three strings: > one > oneself > oneselfsufficient >=20 > all potentially match. Which one is returned depends on the implementatio= n. >=20 > I ran the differences through some online regex analyzers, my local bash > prompt, and RegexBuddy v4 (tests pretty much everything under the sun: a > very worthwhile tool). >=20 > POSIX ERE does indeed look for the longest of the leftmost match (matches > =E2=80=9Coneselfsufficient=E2=80=9D); PCRE stops on the first valid match= (matches > =E2=80=9Coneself=E2=80=9D). >=20 > But running the test on =E2=80=9CXML Schema=E2=80=9D matches =E2=80=9Cone= selfsufficient=E2=80=9D, not > =E2=80=9Coneself=E2=80=9D! So actually the XSD reliance itself is problem= atic. The reason > appears to be because XSD has no concept of anchoring. I've been playing directly with xmllint, and I see what you mean. I'd perha= ps=20 characterise it in PCRE terms as XSD having implicit anchors at start and e= nd=20 of the pattern. In other words, a XSD pattern "XML" would need to be expres= sed=20 as PCRE "^XML$" to give the same effect. I've also realised that (as far as I can see), POSIX ERE's longest leftmost= =20 match isn't the problem I thought it was, beyond some potential inefficienc= y=20 (as a true POSIX engine will have to exhaust every possible option looking = for=20 the longest possible match). In the context of CDDL, the only question is=20 'does the entire regexp match' - the contents of subexpressions cannot be=20 retrieved, and so my example from Friedl is not relevant. It also occurs to me that I've so far been thinking of CDDL as a specificat= ion=20 notation rather than a mechanism for ongoing validation of input or output= =20 (where limited environments are important). =20 > Further inspection > reveals that that XSD also does not support word boundaries or lookaround. > These flaws, in combination with the =E2=80=9CUnicode droppings=E2=80=9D,= just hammer the > nails in the coffin for XSD in my mind. I'm not sure I'd be overjoyed at being stuck with POSIX ERE word boundary=20 expressions, myself. And I can understand why some might find Unicode match= ing=20 in XSD useful. Lookaround might be nice to have, definitely. > The better way forward now appears to be go to back to PCRE/PCRE2, and ju= st > deal with the reference issue directly. >=20 > On that front, PCRE/PCRE2 are BSD 2-clause licensed. There is also the > public documentation: https://www.pcre.org/pcre2.txt >=20 > which itself ought to suffice for documentation. I mean, the ZIP file for= mat > is standardized across many SDOs (including this one) based on PKWare=E2= =80=99s > APPNOTE.txt, so I see reliance on pcre.txt/pcre2.txt as better than that > situation. See also pcresyntax, pcrepattern. Being a relative newbie to the IETF process, I have to defer to others on w= hat=20 might constitute a proper normative reference. I'm certainly not convinced= =20 that POSIX ERE is a big win over XSD. PCRE(2) would be definite plus for me= ,=20 if only on familiarity grounds, but if it's not immediately possible then I= =20 think I'd hope for it in future rather than delay WGLC. =2D-=20 Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Wed Mar 28 12:20:29 2018 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 57FC11275AB for ; Wed, 28 Mar 2018 12:20:27 -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, FREEMAIL_FROM=0.001, 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=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 rEtXEoCGcXHH for ; Wed, 28 Mar 2018 12:20:24 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 3093E126DC2 for ; Wed, 28 Mar 2018 12:20:24 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id i124so1400228pgc.10 for ; Wed, 28 Mar 2018 12:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ancdp/N8Jl7CcrkaxD1UL0Cm74zGPMm0D1BBkRD6Wx0=; b=CwcrG6qPoym8/WCpNfZSsuuDGDK0ApwBrVq99dg3lQR/krs674URFW5/ql+VlgDdIF MWVGzz2xRYjECtg1L69Y15K6BzDuPGa28s2EnwoiSOvqkHht0zZeC3u9nIoZWH5YF1k0 hLQxDjyMrjyugVFT6a9ldEz8LDk2+m5bpKWMJbLXsiFVunC1644wKFmxBaiyWkjLO1ow ZRQRRhg4o4eXRi/dFywdBnTHlbXSiSSdu6Z6X7Pqb23AvMUrS1Cd/5rctmoWC0xB1jjG zfTeTrbt/a6uMmMwImYHsf5611nnjtvO6D/cRHBicoU+U80r+5hyugdjg4PMShid9P6v YUQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ancdp/N8Jl7CcrkaxD1UL0Cm74zGPMm0D1BBkRD6Wx0=; b=NUovmDVXgAlBjvOwFFXmbnq781MI3SiePdCprPp0/2tEx9wGZH3EQJiphgU5Xn/229 jxd4dUcW6qChCl43PxpGMxozu6ntoYoBIgYwk4XmIWHY2j6qM5IOZYDF+iTl9r4eOGXt XXjkcmDtLOGRkXVs+sjWh7yczmBT40oOTX9JBHHfFsGODCzpdtxgFBrFx9KYYKDHhTfa sVKqnij/cNdPjeTnuN6Dmz9cJJtEtFM3Ui2+p+N1Wl8auhAlz5Tof9J+0Lv+zizzxXRf k/+6okje8F278+tp3OJHNmFm+eikkrcUpvsPziBi73vmSGXvzsXzW9kqDSizoHfKeVuW 5OsQ== X-Gm-Message-State: AElRT7F5c4b5HDci7kdSh1rZ87AkUc1eK6r8rC9IGOWtaOtp3NwOh9Xn oqZ8BT0cy5IQEvr6e1VAoTKCkg== X-Google-Smtp-Source: AIpwx48ekMSpTRTKt7zSbdeCTdqV0rz41hH2p1/R75oZCdaU1PDv5wapTrfKM4MEIGHNtBb92l1Oew== X-Received: by 2002:a17:902:968a:: with SMTP id n10-v6mr4931924plp.362.1522264823465; Wed, 28 Mar 2018 12:20:23 -0700 (PDT) Received: from [192.168.178.26] ([118.148.76.62]) by smtp.gmail.com with ESMTPSA id i86sm10575254pfi.28.2018.03.28.12.20.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 12:20:22 -0700 (PDT) Sender: Brian Carpenter To: Jim Hague , Sean Leonard Cc: cbor@ietf.org References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> <4144163.jR6knkXPVo@cho> From: Brian E Carpenter Message-ID: Date: Thu, 29 Mar 2018 08:20:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <4144163.jR6knkXPVo@cho> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cbor] Metaquestions [was CDDL: Solving the regexp issue] X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 19:20:27 -0000 On 29/03/2018 04:09, Jim Hague wrote: ... > It also occurs to me that I've so far been thinking of CDDL as a specification > notation rather than a mechanism for ongoing validation of input or output > (where limited environments are important). Yes. The question "Does this CBOR bytestring match that CDDL specification?" is much harder than "Does this CDDL specification say what I mean?" It's also, I think, out of scope according to the current CDDL draft: "The main goal for the convention is to provide a unified notation that can be used when defining protocols that use CBOR. We term the convention "Concise data definition language", or CDDL." (I'm not sure this helps to decide on a regexp reference, however.) ... > Being a relative newbie to the IETF process, I have to defer to others on what > might constitute a proper normative reference. The reality is that once you get outside both RFCs and formal documents from other well-established standards organizations, it becomes a matter of judgment and YMMV, and persuading the IESG that it's OK. Brian From nobody Wed Mar 28 16:46:03 2018 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 009E9126CC4 for ; Wed, 28 Mar 2018 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 zkcAPhpoO5gy for ; Wed, 28 Mar 2018 16:45:59 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 222741242F5 for ; Wed, 28 Mar 2018 16:45:59 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id y128so5556168iod.4 for ; Wed, 28 Mar 2018 16:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BQoPBS+lPJsZHeWFqCQptepKYgizydZRhDSzLG3C3y8=; b=PnFxpEqGXQAbieUd+B1BcIObgP45Vc0Rq3Ty9l+vbmAO3p+pqrcMEDfMPkGe2v+QMs YxGG1Md4Vhj1e0ZrrqULK/flLmdBAhMMstJZVDW+JYaXUjfvgyzpR7za+5rTOpQZBSLT kk8TasPib61iFsw1KWCNGxUm2TJdS7q6YWuVI= 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=BQoPBS+lPJsZHeWFqCQptepKYgizydZRhDSzLG3C3y8=; b=ULl019YBjcPvyiGE5QBHb09ve0OUW7YrqvDMXxwaCPwpdV/klQpVtDwwGllXszjV/x wun1Nuy3VVFJMvJ+zPNtxob+yq1VQIOY4FWD6+uZUowURVS/eLIBA49v1OFz9PbtmEsE eD3wVIaltuLRumEDHVp/3g+dTlfVZvmfuNuoa3dfoIobKjWzBH3+8zA+T9DT2pyDFGJA dZUIw+kH5z/BwN3zocYD/HgJfSiLFhaUM9E1eQBUcaWCe8eesyav6FGxuinFlmXS0iE/ E6WytoIO1gcKooHpRq72POKGxkGDbz+ZD2Vtf+p82+09P2DIdmzYCvmLtAXvMVdp2rlL KQHg== X-Gm-Message-State: AElRT7E67tYKJfvq+tnESaAWHTDyyBrrJx/68OyRGRN/eNDQI9H9Q58K CBbuCRGZu5VVshVS3dnIwrzNLGL/mXVs/yeRO7pbWjwZ X-Google-Smtp-Source: AIpwx48KejzSopkLoCzR3gc3eg2tz9J/7RST1GekMZvVkcnKLAKmLR6CVYzt+ydwwvQZfr7KB1yafgPTNcpRstsLCes= X-Received: by 10.107.158.79 with SMTP id h76mr8798565ioe.199.1522280757849; Wed, 28 Mar 2018 16:45:57 -0700 (PDT) MIME-Version: 1.0 References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> <4144163.jR6knkXPVo@cho> In-Reply-To: From: Jeffrey Yasskin Date: Wed, 28 Mar 2018 23:45:45 +0000 Message-ID: To: brian.e.carpenter@gmail.com Cc: jim@sinodun.com, dev+ietf@seantek.com, cbor@ietf.org Content-Type: multipart/alternative; boundary="001a1140c1bad285460568819b3a" Archived-At: Subject: Re: [Cbor] Metaquestions [was CDDL: Solving the regexp issue] X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 23:46:01 -0000 --001a1140c1bad285460568819b3a Content-Type: text/plain; charset="UTF-8" On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 29/03/2018 04:09, Jim Hague wrote: > .... > > It also occurs to me that I've so far been thinking of CDDL as a > specification > > notation rather than a mechanism for ongoing validation of input or > output > > (where limited environments are important). > > Yes. The question "Does this CBOR bytestring match that CDDL > specification?" > is much harder than "Does this CDDL specification say what I mean?" > I strongly disagree with the claim that these are different questions. :) If a specification doesn't say exactly which bytestrings are allowed, then it encourages non-interoperable implementations and possibly security vulnerabilities in the gaps between those implementations, which isn't acceptable in the modern world. If CDDL doesn't define exactly which bytestrings match a CDDL specification, then CDDL is not useful for modern specifications. Jeffrey > It's also, I think, out of scope according to the current CDDL draft: > "The main goal for the convention is to provide a unified notation > that can be used when defining protocols that use CBOR. We term the > convention "Concise data definition language", or CDDL." > > (I'm not sure this helps to decide on a regexp reference, however.) > > .... > > Being a relative newbie to the IETF process, I have to defer to others > on what > > might constitute a proper normative reference. > > The reality is that once you get outside both RFCs and formal documents > from > other well-established standards organizations, it becomes a matter of > judgment > and YMMV, and persuading the IESG that it's OK. > > Brian > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --001a1140c1bad285460568819b3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28= , 2018 at 12:20 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 29/03/2018 04:09, Jim Hague wrote= :
....
> It also occurs to me that I've so far been thinking of CDDL as a s= pecification
> notation rather than a mechanism for ongoing validation of input or ou= tput
> (where limited environments are important).

Yes. The question "Does this CBOR bytestring match that CDDL specifica= tion?"
is much harder than "Does this CDDL specification say what I mean?&quo= t;

I strongly disagree with the claim t= hat these are different questions. :) If a specification doesn't say ex= actly which bytestrings are allowed, then it encourages non-interoperable i= mplementations and possibly security vulnerabilities in the gaps between th= ose implementations, which isn't acceptable in the modern world. If CDD= L doesn't define exactly which bytestrings match a CDDL specification, = then CDDL is not useful for modern specifications.

Jeffrey
=C2=A0
It's also, I think, out of scope according to the current CDDL draft: =C2=A0 "The main goal for the convention is to provide a unified notat= ion
=C2=A0 =C2=A0that can be used when defining protocols that use CBOR.=C2=A0 = We term the
=C2=A0 =C2=A0convention "Concise data definition language", or CD= DL."

(I'm not sure this helps to decide on a regexp reference, however.)

....
> Being a relative newbie to the IETF process, I have to defer to others= on what
> might constitute a proper normative reference.

The reality is that once you get outside both RFCs and formal documents fro= m
other well-established standards organizations, it becomes a matter of judg= ment
and YMMV, and persuading the IESG that it's OK.

=C2=A0 =C2=A0Brian

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--001a1140c1bad285460568819b3a-- From nobody Wed Mar 28 18:39:17 2018 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 B51F5128C0A for ; Wed, 28 Mar 2018 18:39:15 -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] 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 V4EIhYzofIeH for ; Wed, 28 Mar 2018 18:39:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1A612895E for ; Wed, 28 Mar 2018 18:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w2T1d9bb005399; Thu, 29 Mar 2018 03:39:09 +0200 (CEST) Received: from client-0066.vpn.uni-bremen.de (client-0066.vpn.uni-bremen.de [134.102.107.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40BS8W3hvwzDX21; Thu, 29 Mar 2018 03:39:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 29 Mar 2018 10:39:03 +0900 Cc: Brian E Carpenter , jim@sinodun.com, cbor@ietf.org, dev+ietf@seantek.com X-Mao-Original-Outgoing-Id: 543980341.797331-29584118f08df2a67b74439fc610dc91 Content-Transfer-Encoding: quoted-printable Message-Id: <7D62C232-FC2D-458D-9FC6-B1F904CF0F0F@tzi.org> References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> <4144163.jR6knkXPVo@cho> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Metaquestions [was CDDL: Solving the regexp issue] X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 01:39:16 -0000 Hi Jeffrey, this is an interesting train of thought. Most of the specifications in the network space use the English = language, sometimes aided by some illustrations or ad-hoc notation, to = specify what is the protocol. Another observation is that the focus of protocol specification has = moved from compliance to interoperability. There is a limited return from specifying compliance in a more rigid = way. Where it is easy to do (and, in particular, where we have usable = formal description techniques such as ABNF), we of course should do it. = But arguing that all protocol specification must be done in a formally = watertight way leads nowhere good. (As an example, we still have = English language parts in many ABNF specifications.) Now what is CDDL about? It is intended as a formal description = technique, and the intention is to occupy about the same space for = tree-structured data that ABNF occupies for textual data. So I would = indeed expect that it can be decided in an unambiguous way whether a = data item serialized in CBOR (or JSON) is matched by a CDDL spec or not. = I also would expect the language to be quite usable during a time when = we still figure out some corner cases of this (but we should work on = figuring them out, and of course fix what we already know). A completely different question is whether a validator that checks each = incoming data item against a CDDL specification is desirable or not. = The majority of implementations of protocols specified in ABNF are not = directly interpreting or generated from that ABNF. I would expect the = situation to be similar for CDDL. =20 That said, I have written two ANBF parser generators and one-and-a-half = CDDL validators in my life so far, so I definitely think there is space = for appropriate tools. I just don=E2=80=99t think that tool = implementation considerations should be overriding concerns for the = development of the CDDL language =E2=80=94 it should focus on the = quality of the specifications that can be made while using it. (As an = example, the fact that XSD regexps have less viable implementations = available than PCRE or Posix concerns me less than the question which of = these formats can be best used for specification, which includes = non-technical concerns such as stable reference.) So, in summary, I believe there *is* a valid distinction here: > > It also occurs to me that I've so far been thinking of CDDL as a = specification > > notation rather than a mechanism for ongoing validation of input or = output > > (where limited environments are important). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 28 18:56:52 2018 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 23DAC124205 for ; Wed, 28 Mar 2018 18:56:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (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 gFB6X6WMYX9j for ; Wed, 28 Mar 2018 18:56:50 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 E78F6128C0A for ; Wed, 28 Mar 2018 18:56:49 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id a11so2143928pff.8 for ; Wed, 28 Mar 2018 18:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b5HemfaMf1B4FJk6pG7Cjc/RP1vQ1nxFwF4nnjs5fJ0=; b=Vwk8nCYcXmJGEpK8uskxrmq4JAae+osugYoTo/u8f02NnY1H3P4xsqk28WSvsu9neZ bEz1xlJZTc91bb+aKdSMDV8dtx3phsRhc3IYHHw/kAL2iLv6H4Hw1iaj6VFJqycvk/NT R76iF9NW2KWFmEef/SHx38UfvX6MUL/dzNZ/HR2gA9XnnsSaTKlq5PTVyToq4QkwRxlC b4IYvRrBZyH8uewYMfAeNJQfKWR3pji/qKCD4yGX+7KD86Kx2ddS9Z92v00v2qTQ65gs y0Bc64nKeAXIOdfpRjAL5oc0RuCZ+RslWT+5kDjuXw7UiSzuoY8Ihe9LH31cfYjZP0zA LwAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b5HemfaMf1B4FJk6pG7Cjc/RP1vQ1nxFwF4nnjs5fJ0=; b=ANDgC0DI2QWTUq7N8i9AP63PFukR7+q/rkYOrxAl0LgzWtQsgzJikdHY/25bzZD7N9 N/lV9OlUAT63NkyGFvHWfTNqIXF1iWtpGRaHHHpZ97HqUsvsaUMf9taahmPeZ5YsBI1v fr2Bj7qZkTZmZTL1VZvcilLU9iXSKx6+x4sC/2aNnCbewCo+r0FuKCxc8X6dgsosu0W0 x0YvnzfO/9QAQo2aNjhoIuJGwL0XWYRI5fjE0XDi9M5UZqv2klTgpu80sDFa4bKZHCUZ j7h0mSToPFQn9XRS1DFJLr8ha+Aon4BIWAUkbb6LsymyVGEniBv/naPBElSoW9jg89I3 CfWQ== X-Gm-Message-State: AElRT7E6UYxzbun8zwBJ+ks1qpH3i6LHb9YPsGy7U8ykp2Ti1GraYmwu 0cmlGEN9L01ey5TPfhUAzZZ6tA== X-Google-Smtp-Source: AIpwx4/UF3VRC9+2ZL5sDRI6HlPWn8xoS8G9IkfdXL4J6QUDdQawKUPU2Jq1m6jHoY9rgwSE092vwA== X-Received: by 2002:a17:902:47aa:: with SMTP id r39-v6mr5973150pld.59.1522288609038; Wed, 28 Mar 2018 18:56:49 -0700 (PDT) Received: from [192.168.178.26] ([118.148.76.62]) by smtp.gmail.com with ESMTPSA id q15sm10456916pfi.140.2018.03.28.18.56.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 18:56:48 -0700 (PDT) Sender: Brian Carpenter To: Jeffrey Yasskin Cc: jim@sinodun.com, dev+ietf@seantek.com, cbor@ietf.org References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> <4144163.jR6knkXPVo@cho> From: Brian E Carpenter Message-ID: Date: Thu, 29 Mar 2018 14:56:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] Metaquestions [was CDDL: Solving the regexp issue] X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 01:56:52 -0000 On 29/03/2018 12:45, Jeffrey Yasskin wrote: > On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 29/03/2018 04:09, Jim Hague wrote: >> .... >>> It also occurs to me that I've so far been thinking of CDDL as a >> specification >>> notation rather than a mechanism for ongoing validation of input or >> output >>> (where limited environments are important). >> >> Yes. The question "Does this CBOR bytestring match that CDDL >> specification?" >> is much harder than "Does this CDDL specification say what I mean?" >> > > I strongly disagree with the claim that these are different questions. :) > If a specification doesn't say exactly which bytestrings are allowed, then > it encourages non-interoperable implementations and possibly security > vulnerabilities in the gaps between those implementations, which isn't > acceptable in the modern world. If CDDL doesn't define exactly which > bytestrings match a CDDL specification, then CDDL is not useful for modern > specifications. I wasn't clear. I didn't mean that the question "Does this bytestring match the specification?" is *unanswerable*. I meant that writing a general-purpose syntax-driven verifier is hard - as hard as writing any general recursive-descent syntax checker. For my own rather trivial CDDL use case, I tried but gave up and wrote a very ad hoc parser instead. (Of course you can use Carsten's tools but I think he'll agree they have some limitations.) Brian > > Jeffrey > > >> It's also, I think, out of scope according to the current CDDL draft: >> "The main goal for the convention is to provide a unified notation >> that can be used when defining protocols that use CBOR. We term the >> convention "Concise data definition language", or CDDL." >> >> (I'm not sure this helps to decide on a regexp reference, however.) >> >> .... >>> Being a relative newbie to the IETF process, I have to defer to others >> on what >>> might constitute a proper normative reference. >> >> The reality is that once you get outside both RFCs and formal documents >> from >> other well-established standards organizations, it becomes a matter of >> judgment >> and YMMV, and persuading the IESG that it's OK. >> >> Brian >> >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >> > From nobody Wed Mar 28 23:00:32 2018 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 96A4312D7F3 for ; Wed, 28 Mar 2018 23:00:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rqCrbr7c7fN6 for ; Wed, 28 Mar 2018 23:00:27 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6541912778D for ; Wed, 28 Mar 2018 23:00:27 -0700 (PDT) Received: from [192.168.123.7] (cpe-76-90-60-238.socal.res.rr.com [76.90.60.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 47AA527555; Thu, 29 Mar 2018 02:00:25 -0400 (EDT) To: Brian E Carpenter , Jeffrey Yasskin Cc: jim@sinodun.com, cbor@ietf.org References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho> <4144163.jR6knkXPVo@cho> From: Sean Leonard Message-ID: <9b8fa85e-30f5-61ac-cea0-2985a3cdabd6@seantek.com> Date: Wed, 28 Mar 2018 23:00:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------91FD85A46DA694644FCAB6AB" Content-Language: en-US Archived-At: Subject: [Cbor] =?utf-8?q?red-flag_=F0=9F=9A=A9_validators_Re=3A__Metaques?= =?utf-8?q?tions_=5Bwas_CDDL=3A_Solving_the_regexp_issue=5D?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 06:00:31 -0000 This is a multi-part message in MIME format. --------------91FD85A46DA694644FCAB6AB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/28/2018 6:56 PM, Brian E Carpenter wrote: > On 29/03/2018 12:45, Jeffrey Yasskin wrote: >> On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> On 29/03/2018 04:09, Jim Hague wrote: >>> .... >>>> It also occurs to me that I've so far been thinking of CDDL as a >>> specification >>>> notation rather than a mechanism for ongoing validation of input or >>> output >>>> (where limited environments are important). >>> Yes. The question "Does this CBOR bytestring match that CDDL >>> specification?" >>> is much harder than "Does this CDDL specification say what I mean?" >>> >> I strongly disagree with the claim that these are different questions. :) >> If a specification doesn't say exactly which bytestrings are allowed, then >> it encourages non-interoperable implementations and possibly security >> vulnerabilities in the gaps between those implementations, which isn't >> acceptable in the modern world. If CDDL doesn't define exactly which >> bytestrings match a CDDL specification, then CDDL is not useful for modern >> specifications. > I wasn't clear. I didn't mean that the question "Does this bytestring match > the specification?" is *unanswerable*. I meant that writing a general-purpose > syntax-driven verifier is hard - as hard as writing any general recursive-descent > syntax checker. For my own rather trivial CDDL use case, I tried but gave up and > wrote a very ad hoc parser instead. > > (Of course you can use Carsten's tools but I think he'll agree they have some > limitations.) I need to spend more time making a formal proposal, but I want to make some preliminary observations. When writing grammars that are implemented in actual products (as opposed to academic exercises), there is a tension between "descriptive" -- these are the ways to express valid protocol units -- and "prescriptive" -- the sender or receiver MUST do such and such, or MUST NOT do such and such (the consequence of violating the latter, is prescribed, or proscribed, as the case may be). In many ways, it is the difference between Markdown on the descriptive side, and XML on the other. The problem with XML and its associated desiderata (XML schemas, etc.) is that they are too rigid and complicated. The specs are super-long and processors need to follow a large set of arcane rules that result in utter failure to ingest any part of the data structure if there is so much as one character that is out-of-place. CDDL has "DESCRIPTIVE" in the name so generally I am more aligned with Carsten's interpretation as a formal description technique. I would also add to this, that CDDL in its current form is not so rigid about validating productions as a parser. That is a good thing because it means that a lot of ambiguous cases don't have to result in fatality. The counterargument that it affects "security" does not hold much water for me because things that are ambiguous, need to be considered ambiguous when doing a security analysis. To the extent that CDDL is used as a validator, such a validator should output a validated production to the smallest possible unit that it can, and ignore or "red-flag" 🚩 the smallest possible invalid parts, rather than failing validation entirely. Just to pick out one area: it has always struck me that CBOR groups with respect to maps (and arrays) should be considered open-ended. Consider the CDDL: person = {( age: int, name: tstr, employer: tstr, )} Now consider the CBOR (diagnostic notation):     {"age": 6, "name": "Foobar", "employer": "Akamai", "favouriteDrink": "Pepsi"} The CBOR could have been produced by an earlier spec of person, that later got augmented. (That is what /= and //= are for.) It seems to me that a CDDL-based parser that is trying to figure out whether the input matches the CDDL grammar, should output this:     {"age": 6, "name": "Foobar", "employer": "Akamai", †("favouriteDrink": "Pepsi")} where † (dagger) means "red-flag". What I mean by red-flag is, "this part wasn't part of the CDDL spec but it's still there so you can just ignore it, or you can try to deal with it at a higher software layer, but you are on your own". A reasonable output with the red-flagged elements removed would be:     {"age": 6, "name": "Foobar", "employer": "Akamai"} ...which, of course, would be a production that could have come from the original CDDL. Keeping the red-flagged content in the output is also sensible, so that a higher software layer can try to poly-fill in functionality that the lower layer was not compiled to have knowledge of at the time (for example, if the lower layer is some system library). As a second example, consider the CBOR (diagnostic notation):     {"age": null, "name": "Foobar", "employer": "Akamai"} It's a more interesting case, because "age" is a valid key but int doesn't match null. A reasonable output could be:     {"age": †(null), "name": "Foobar", "employer": "Akamai"} This is because null doesn't match int, but "age" matched. The application will have to figure out what to do with the structure in the absence of a required item, but it is still "useful" in that the application can still extract the other map elements. Bear in mind that the /= operator in CDDL can augment age in an additional spec, by allowing null to appear in that position. Therefore †(null) is a quite sensible result. However, the problem is that if †(null) is stripped out, you are left with invalid CBOR since a key has to have a value. Another way to deal with it would be:     {†("age": null), "name": "Foobar", "employer": "Akamai"} Namely: ignore the age key/value pair entirely--treat it as if it were absent (as opposed to "age" being present but the value being absent). However, if "age": null is stripped, the production as a whole doesn't comply with the CDDL grammar. This leads us to the next possibility: which would be: †({"age": null, "name": "Foobar", "employer": "Akamai"}) Which means that the entire production does not match, because age is a required key/value pair, and a matching production is not present. This might seem like the best from a "security" standpoint, but it could lead to denial-of-service. Now consider this CDDL instead: person = {( ? age: int, name: tstr, employer: tstr, )} And our CBOR:     {"age": null, "name": "Foobar", "employer": "Akamai"} In this case, I can more confidently say that the red-flagged output of a CDDL parser should be:     {†("age": null), "name": "Foobar", "employer": "Akamai"} because "age": null does not match age: int, but age: int is optional, so the red-flag-stripped CBOR:     {"name": "Foobar", "employer": "Akamai"} would be a production generated from the original CDDL grammar. For those with ASN.1 experience (shudder), consider that ASN.1 specifications are CLOSED by default. If you say: SomeStruct ::= SEQUENCE { foo INTEGER, bar IA5String } Then you can never expand the SEQUENCE in future versions of the protocol. Early specs dealt with this by saying "ANY DEFINED BY (some OID or integer)"; later on, open types and templates were developed. Then came "extensibility", aka the ellipsis: SomeStruct ::= SEQUENCE { foo INTEGER, bar IA5String, ...  } which means more-or-less what is being proposed above: if there is extraneous ASN.1 data after the bar IA5String, don't error out, but just ignore it and maybe when you update your software we will be able to make some sense out of it. It has now come to the point that ASN.1 people recommend using ellipses all over the place, or just throwing your hands up and turning it on with EXTENSIBILITY IMPLIED. See . I would like to think that a good CDDL parser would try to cope with a reasonable spectrum of productions, including productions from future versions. Red-flagging the smallest sub-production unit that is out-of-CDDL-spec is one such way to resolve the tension between the two. Please do not burn down my straw man before I put the rest of the bundles of hay together. :) Just think about it. Best regards, Sean > > Brian > >> Jeffrey >> >> >>> It's also, I think, out of scope according to the current CDDL draft: >>> "The main goal for the convention is to provide a unified notation >>> that can be used when defining protocols that use CBOR. We term the >>> convention "Concise data definition language", or CDDL." >>> >>> (I'm not sure this helps to decide on a regexp reference, however.) >>> >>> .... >>>> Being a relative newbie to the IETF process, I have to defer to others >>> on what >>>> might constitute a proper normative reference. >>> The reality is that once you get outside both RFCs and formal documents >>> from >>> other well-established standards organizations, it becomes a matter of >>> judgment >>> and YMMV, and persuading the IESG that it's OK. >>> >>> Brian >>> >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> --------------91FD85A46DA694644FCAB6AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/28/2018 6:56 PM, Brian E Carpenter wrote:
On 29/03/2018 12:45, Jeffrey Yasskin wrote:

On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:


On 29/03/2018 04:09, Jim Hague wrote:
....

It also occurs to me that I've so far been thinking of CDDL as a

specification

notation rather than a mechanism for ongoing validation of input or

output

(where limited environments are important).

Yes. The question "Does this CBOR bytestring match that CDDL
specification?"
is much harder than "Does this CDDL specification say what I mean?"


I strongly disagree with the claim that these are different questions. :)
If a specification doesn't say exactly which bytestrings are allowed, then
it encourages non-interoperable implementations and possibly security
vulnerabilities in the gaps between those implementations, which isn't
acceptable in the modern world. If CDDL doesn't define exactly which
bytestrings match a CDDL specification, then CDDL is not useful for modern
specifications.

I wasn't clear. I didn't mean that the question "Does this bytestring match
the specification?" is *unanswerable*. I meant that writing a general-purpose
syntax-driven verifier is hard - as hard as writing any general recursive-descent
syntax checker. For my own rather trivial CDDL use case, I tried but gave up and
wrote a very ad hoc parser instead.

(Of course you can use Carsten's tools but I think he'll agree they have some
limitations.)

I need to spend more time making a formal proposal, but I want to make some preliminary observations.

When writing grammars that are implemented in actual products (as opposed to academic exercises), there is a tension between "descriptive" -- these are the ways to express valid protocol units -- and "prescriptive" -- the sender or receiver MUST do such and such, or MUST NOT do such and such (the consequence of violating the latter, is prescribed, or proscribed, as the case may be). In many ways, it is the difference between Markdown on the descriptive side, and XML on the other.

The problem with XML and its associated desiderata (XML schemas, etc.) is that they are too rigid and complicated. The specs are super-long and processors need to follow a large set of arcane rules that result in utter failure to ingest any part of the data structure if there is so much as one character that is out-of-place.

CDDL has "DESCRIPTIVE" in the name so generally I am more aligned with Carsten's interpretation as a formal description technique. I would also add to this, that CDDL in its current form is not so rigid about validating productions as a parser. That is a good thing because it means that a lot of ambiguous cases don't have to result in fatality. The counterargument that it affects "security" does not hold much water for me because things that are ambiguous, need to be considered ambiguous when doing a security analysis.

To the extent that CDDL is used as a validator, such a validator should output a validated production to the smallest possible unit that it can, and ignore or "red-flag" 🚩 the smallest possible invalid parts, rather than failing validation entirely.

Just to pick out one area: it has always struck me that CBOR groups with respect to maps (and arrays) should be considered open-ended. Consider the CDDL:

                             person = {(
                               age: int,
                               name: tstr,
                               employer: tstr,
                             )}

Now consider the CBOR (diagnostic notation):

    {"age": 6, "name": "Foobar", "employer": "Akamai", "favouriteDrink": "Pepsi"}

The CBOR could have been produced by an earlier spec of person, that later got augmented. (That is what /= and //= are for.) It seems to me that a CDDL-based parser that is trying to figure out whether the input matches the CDDL grammar, should output this:

    {"age": 6, "name": "Foobar", "employer": "Akamai", †("favouriteDrink": "Pepsi")}
where † (dagger) means "red-flag". What I mean by red-flag is, "this part wasn't part of the CDDL spec but it's still there so you can just ignore it, or you can try to deal with it at a higher software layer, but you are on your own". A reasonable output with the red-flagged elements removed would be:

    {"age": 6, "name": "Foobar", "employer": "Akamai"}
...which, of course, would be a production that could have come from the original CDDL.

Keeping the red-flagged content in the output is also sensible, so that a higher software layer can try to poly-fill in functionality that the lower layer was not compiled to have knowledge of at the time (for example, if the lower layer is some system library).

As a second example, consider the CBOR (diagnostic notation):

    {"age": null, "name": "Foobar", "employer": "Akamai"}
It's a more interesting case, because "age" is a valid key but int doesn't match null. A reasonable output could be:

    {"age": †(null), "name": "Foobar", "employer": "Akamai"}
This is because null doesn't match int, but "age" matched. The application will have to figure out what to do with the structure in the absence of a required item, but it is still "useful" in that the application can still extract the other map elements. Bear in mind that the /= operator in CDDL can augment age in an additional spec, by allowing null to appear in that position. Therefore †(null) is a quite sensible result. However, the problem is that if †(null) is stripped out, you are left with invalid CBOR since a key has to have a value.

Another way to deal with it would be:

    {†("age": null), "name": "Foobar", "employer": "Akamai"}
Namely: ignore the age key/value pair entirely--treat it as if it were absent (as opposed to "age" being present but the value being absent). However, if "age": null is stripped, the production as a whole doesn't comply with the CDDL grammar.

This leads us to the next possibility: which would be:

    †({"age": null, "name": "Foobar", "employer": "Akamai"})
Which means that the entire production does not match, because age is a required key/value pair, and a matching production is not present. This might seem like the best from a "security" standpoint, but it could lead to denial-of-service.

Now consider this CDDL instead:

                             person = {(
                               ? age: int,
                               name: tstr,
                               employer: tstr,
                             )}

And our CBOR:
    {"age": null, "name": "Foobar", "employer": "Akamai"}
In this case, I can more confidently say that the red-flagged output of a CDDL parser should be:
    {†("age": null), "name": "Foobar", "employer": "Akamai"}
because "age": null does not match age: int, but age: int is optional, so the red-flag-stripped CBOR:
    {"name": "Foobar", "employer": "Akamai"}
would be a production generated from the original CDDL grammar.

For those with ASN.1 experience (shudder), consider that ASN.1 specifications are CLOSED by default. If you say:

    SomeStruct ::= SEQUENCE {
        foo INTEGER,
        bar IA5String
    }
Then you can never expand the SEQUENCE in future versions of the protocol. Early specs dealt with this by saying "ANY DEFINED BY (some OID or integer)"; later on, open types and templates were developed. Then came "extensibility", aka the ellipsis:

    SomeStruct ::= SEQUENCE {
        foo INTEGER,
        bar IA5String,
        ...
    }
which means more-or-less what is being proposed above: if there is extraneous ASN.1 data after the bar IA5String, don't error out, but just ignore it and maybe when you update your software we will be able to make some sense out of it. It has now come to the point that ASN.1 people recommend using ellipses all over the place, or just throwing your hands up and turning it on with EXTENSIBILITY IMPLIED. See <http://lionet.info/asn1c/blog/2010/09/21/question-extensibility-removing-fields/>.

I would like to think that a good CDDL parser would try to cope with a reasonable spectrum of productions, including productions from future versions. Red-flagging the smallest sub-production unit that is out-of-CDDL-spec is one such way to resolve the tension between the two.

Please do not burn down my straw man before I put the rest of the bundles of hay together. :) Just think about it.

Best regards,

Sean


    Brian


Jeffrey



It's also, I think, out of scope according to the current CDDL draft:
  "The main goal for the convention is to provide a unified notation
   that can be used when defining protocols that use CBOR.  We term the
   convention "Concise data definition language", or CDDL."

(I'm not sure this helps to decide on a regexp reference, however.)

....

Being a relative newbie to the IETF process, I have to defer to others

on what

might constitute a proper normative reference.

The reality is that once you get outside both RFCs and formal documents
from
other well-established standards organizations, it becomes a matter of
judgment
and YMMV, and persuading the IESG that it's OK.

   Brian

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



      

    

    

  


--------------91FD85A46DA694644FCAB6AB--


From nobody Thu Mar 29 03:23:36 2018
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 BEF0012D88C for ; Thu, 29 Mar 2018 03:23:35 -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, 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 9ZPxY_wtH_Xv for ; Thu, 29 Mar 2018 03:23:33 -0700 (PDT)
Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E58E12D88B for ; Thu, 29 Mar 2018 03:23:32 -0700 (PDT)
Received: (qmail 978 invoked from network); 29 Mar 2018 11:13:17 +0100
Received: from host86-191-202-181.range86-191.btcentralplus.com (HELO ?192.168.1.72?) (86.191.202.181) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 29 Mar 2018 11:13:17 +0100
To: Jeffrey Yasskin 
Cc: cbor@ietf.org
References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho>  <4144163.jR6knkXPVo@cho>  
From: Pete Cordell 
Message-ID: <80e74f48-40cb-7134-339e-1f711d0e507d@codalogic.com>
Date: Thu, 29 Mar 2018 11:23:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cbor] Metaquestions [was CDDL: Solving the regexp issue]
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2018 10:23:35 -0000

On 29/03/2018 00:45, Jeffrey Yasskin wrote:
> On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter 
> > wrote:
> 
>     On 29/03/2018 04:09, Jim Hague wrote:
>     .....
>      > It also occurs to me that I've so far been thinking of CDDL as a
>     specification
>      > notation rather than a mechanism for ongoing validation of input
>     or output
>      > (where limited environments are important).
> 
>     Yes. The question "Does this CBOR bytestring match that CDDL
>     specification?"
>     is much harder than "Does this CDDL specification say what I mean?"
> 
> 
> I strongly disagree with the claim that these are different questions. 
> :) If a specification doesn't say exactly which bytestrings are allowed, 
> then it encourages non-interoperable implementations and possibly 
> security vulnerabilities in the gaps between those implementations, 
> which isn't acceptable in the modern world. If CDDL doesn't define 
> exactly which bytestrings match a CDDL specification, then CDDL is not 
> useful for modern specifications.

I think there is a distinction between the two, but it is a small one. 
The main issue with the above paragraph is the word "exactly".

A human reader should be allowed to be as pedantic as a computer in 
their interpretation of the CDDL.

The difference is that the human can also read the comments!  So you can 
have:

    email = tstr .regexp "[^\\s@]+@\\S+(\\.\\S+)+" ; see RFC 5322

So, as with ABNF, you can have a slightly looser definition in the CDDL 
that is still useful (not least because it allows you to be exact about 
the other 99% of the spec that can be accurately expressed), while also 
making it clear that there is slightly more pedantry to be dealt with in 
higher layers of software than the specification language can express.

In some ways, the question "Does this CBOR bytestring match that CDDL 
specification?" is much EASIER than "Does this CDDL specification say 
what I mean?" because you can come up with CDDL that will match any CBOR :-)

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
http://json-content-rules.org Rule :-)
---------------------------------------------------------------------


From nobody Thu Mar 29 10:31:39 2018
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 7A9BA12E88D for ; Thu, 29 Mar 2018 10:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level: 
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 oe6xMCFe-ldE for ; Thu, 29 Mar 2018 10:31:25 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 7558F12E894 for ; Thu, 29 Mar 2018 10:31:25 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id e79so8541913ioi.7 for ; Thu, 29 Mar 2018 10:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4+Ej7/JztLvrdJAWsld7kzRrMfTRNbiBGGEcl1Jx0SM=; b=WZuWIUdkQPCIDpRRUKDhCmmQckTrdUBThyUB4YAFpAg267DIVec16+f6DnNFA0jDUE vIAPFMXS0x1HLIbnd4jprM3wU5Fp/deOQ5jjzNCWILnO+kOmO2Cy+jpcnV4FY7ffEeg7 WLrO3B+1EnN1u7+D/RpCJ8hQ6AgWFWQSWfNSQ=
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=4+Ej7/JztLvrdJAWsld7kzRrMfTRNbiBGGEcl1Jx0SM=; b=WSQqXmojAfDqP4tbM38XbFU/tc0E3MgUkbDaUrUquxW2nZU5GfjTyU9cIyaX9ioHXK +W3M6Q1KvKH2RzVslIYrqslSzwmy1gqGjKi9rSWM8bUUhE+gBGCv4W3q3+7WqYEuHCFe JBTA7MM6j5QW+BSgIbfkpU3/A++seeotk3gTd4PMPNyx+QXzfDE8mxDfGRaeZFhRmvs1 ugDoVfdIyBg7+2aCZQQumAjwWiRc9fk5dAxdAhyGWl9rlTrqeHuEF9b1eaJ/rIHZXYzO LivhJpjJd4Yfyd2IPNdxZWrAC3jjeVY2S+9GsEf/v4Yn2FQehsGW6b8ZcWpwd7JqFvL4 O7rQ==
X-Gm-Message-State: AElRT7FQWx07EUDKvT9vIh6GYb9Kq4qTupgTuAmD380mgnyVEGi1ai2q mAyYbyZiQpoOIrz6ooYpyl4HXA/yLBqHG180aEJRWQ==
X-Google-Smtp-Source: AG47ELvdoMNhUlEITZR1Wxi1GooYutpl0HcBGoCevYoN9fpJY4NtGoPa+NEsMcgPtzbyekDdhfnsVk6Ym+t27P1FhSs=
X-Received: by 10.107.51.207 with SMTP id z198mr55742299ioz.112.1522344683996;  Thu, 29 Mar 2018 10:31:23 -0700 (PDT)
MIME-Version: 1.0
References: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> <3645996.TIld9bUl5u@cho>  <4144163.jR6knkXPVo@cho>   
In-Reply-To: 
From: Jeffrey Yasskin 
Date: Thu, 29 Mar 2018 17:31:11 +0000
Message-ID: 
To: brian.e.carpenter@gmail.com
Cc: Jeffrey Yasskin , jim@sinodun.com,  Sean Leonard , cbor@ietf.org
Content-Type: multipart/alternative; boundary="001a11441a961e39c40568907e23"
Archived-At: 
Subject: Re: [Cbor] Metaquestions [was CDDL: Solving the regexp issue]
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2018 17:31:37 -0000

--001a11441a961e39c40568907e23
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 28, 2018 at 6:56 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 29/03/2018 12:45, Jeffrey Yasskin wrote:
> > On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> On 29/03/2018 04:09, Jim Hague wrote:
> >> ....
> >>> It also occurs to me that I've so far been thinking of CDDL as a
> >> specification
> >>> notation rather than a mechanism for ongoing validation of input or
> >> output
> >>> (where limited environments are important).
> >>
> >> Yes. The question "Does this CBOR bytestring match that CDDL
> >> specification?"
> >> is much harder than "Does this CDDL specification say what I mean?"
> >>
> >
> > I strongly disagree with the claim that these are different questions. :)
> > If a specification doesn't say exactly which bytestrings are allowed,
> then
> > it encourages non-interoperable implementations and possibly security
> > vulnerabilities in the gaps between those implementations, which isn't
> > acceptable in the modern world. If CDDL doesn't define exactly which
> > bytestrings match a CDDL specification, then CDDL is not useful for
> modern
> > specifications.
>
> I wasn't clear. I didn't mean that the question "Does this bytestring match
> the specification?" is *unanswerable*. I meant that writing a
> general-purpose
> syntax-driven verifier is hard - as hard as writing any general
> recursive-descent
> syntax checker. For my own rather trivial CDDL use case, I tried but gave
> up and
> wrote a very ad hoc parser instead.
>

Ah, yep, I agree with you here. Sorry for misunderstanding. I also expect
most implementations of protocols specified using CDDL to use custom
parsers rather than sharing a generic CDDL parser.

On Thu, Mar 29, 2018 at 3:23 AM Pete Cordell  wrote:

> I think there is a distinction between the two, but it is a small one.
> The main issue with the above paragraph is the word "exactly".
>
> A human reader should be allowed to be as pedantic as a computer in
> their interpretation of the CDDL.
>
> The difference is that the human can also read the comments!  So you can
> have:
>
>     email = tstr .regexp "[^\\s@]+@\\S+(\\.\\S+)+" ; see RFC 5322
>
> So, as with ABNF, you can have a slightly looser definition in the CDDL
> that is still useful (not least because it allows you to be exact about
> the other 99% of the spec that can be accurately expressed), while also
> making it clear that there is slightly more pedantry to be dealt with in
> higher layers of software than the specification language can express.
>

I also agree with this: it's definitely useful for CDDL to accept a
superset of the bytestrings the protocol actually intends to accept, with
English used to specify which subset is actually accepted. It's only a
problem for the CDDL to be ambiguous about which strings it accepts.

Jeffrey

--001a11441a961e39c40568907e23
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Wed, Mar 28=
, 2018 at 6:56 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 29/03/2018 12:45, Jeffrey Yasskin wrote:

> On Wed, Mar 28, 2018 at 12:20 PM Brian E Carpenter <

> brian=
.e.carpenter@gmail.com> wrote:

>

>> On 29/03/2018 04:09, Jim Hague wrote:

>> ....

>>> It also occurs to me that I've so far been thinking of CDD=
L as a

>> specification

>>> notation rather than a mechanism for ongoing validation of inp=
ut or

>> output

>>> (where limited environments are important).

>>

>> Yes. The question "Does this CBOR bytestring match that CDDL<=
br>
>> specification?"

>> is much harder than "Does this CDDL specification say what I =
mean?"

>>

>

> I strongly disagree with the claim that these are different questions.=
 :)

> If a specification doesn't say exactly which bytestrings are allow=
ed, then

> it encourages non-interoperable implementations and possibly security<=
br>
> vulnerabilities in the gaps between those implementations, which isn&#=
39;t

> acceptable in the modern world. If CDDL doesn't define exactly whi=
ch

> bytestrings match a CDDL specification, then CDDL is not useful for mo=
dern

> specifications.



I wasn't clear. I didn't mean that the question "Does this byt=
estring match

the specification?" is *unanswerable*. I meant that writing a general-=
purpose

syntax-driven verifier is hard - as hard as writing any general recursive-d=
escent

syntax checker. For my own rather trivial CDDL use case, I tried but gave u=
p and

wrote a very ad hoc parser instead.

Ah,=
 yep, I agree with you here. Sorry for misunderstanding. I also expect most=
 implementations of protocols specified using CDDL to use custom parsers ra=
ther than sharing a generic CDDL parser.

On Thu, Mar 29, 2018 at 3:23 AM Pete Cordell <petejson@codalogic.com> wrote:
I think there is a distinction between the two, bu=
t it is a small one.
The main issue with the above paragraph is the word=
 "exactly".

A human reader should be allowed to be as peda=
ntic as a computer in
their interpretation of the CDDL.

The diffe=
rence is that the human can also read the comments!=C2=A0 So you can
hav=
e:

=C2=A0 =C2=A0 email =3D tstr .regexp "[^\\s@]+@\\S+(\\.\\S+)=
+" ; see RFC 5322

So, as with ABNF, you can have a slightly loo=
ser definition in the CDDL
that is still useful (not least because it al=
lows you to be exact about
the other 99% of the spec that can be accurat=
ely expressed), while also
making it clear that there is slightly more p=
edantry to be dealt with in
higher layers of software than the specifica=
tion language can express.

I also agree=
 with this: it's definitely useful for CDDL to accept a superset of the=
 bytestrings the protocol actually intends to accept, with English used to =
specify which subset is actually accepted. It's only a problem for the =
CDDL to be ambiguous about which strings it accepts.

Jeffrey


--001a11441a961e39c40568907e23--


From nobody Fri Mar 30 05:09:20 2018
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 E964B12422F for ; Fri, 30 Mar 2018 05:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 13l5nGZGIuYH for ; Fri, 30 Mar 2018 05:09:16 -0700 (PDT)
Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601D6126D73 for ; Fri, 30 Mar 2018 05:09:15 -0700 (PDT)
Received: (qmail 13289 invoked from network); 30 Mar 2018 12:58:59 +0100
Received: from host86-191-202-181.range86-191.btcentralplus.com (HELO ?192.168.1.72?) (86.191.202.181) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 30 Mar 2018 12:58:59 +0100
To: cbor@ietf.org
From: Pete Cordell 
Message-ID: 
Date: Fri, 30 Mar 2018 13:09:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2018 12:09:19 -0000

Thinking laterally, if specifying a regex format is problematic, is it 
worth considering ABNF as an alternative?

The pipe character could act as a suitable delimiter.  For example:

    triple-digit = tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT |

Over multiple lines it could look like:

    triple-digit = tstr .abnf |
         1*DIGIT "." 1*DIGIT "." 1*DIGIT
    |

The ABNF could be loosely defined; as in:

    opague-abnf = *( text / NOT-PIPE )
    NOT-PIPE = CRLF / %x20-5B / %x7D-10FFFD

It's more verbose. And it's unconventional.  But...

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
http://json-content-rules.org Rule
---------------------------------------------------------------------


From nobody Sat Mar 31 05:32:48 2018
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 6DA7512D77B for ; Sat, 31 Mar 2018 05:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VogcMP9h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c3eVfueB
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 gDIVGFKcXlMf for ; Sat, 31 Mar 2018 05:32:45 -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 250D112422F for ; Sat, 31 Mar 2018 05:32:45 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 60F5F20F81; Sat, 31 Mar 2018 08:32:44 -0400 (EDT)
Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Sat, 31 Mar 2018 08:32:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=qQ2Uo4sZkAVaozq2Ef8yZLRceN0cwpQIO2sg8i0bfCE=; b=VogcMP9h gfqY//mMK9trhtyKvcOmXeJP9rKeutFGA76amYneGnQeqtmt4shtMAVTMHOopNMm FkYJDNR18Jw5MYnAJRFF27WyiQNmWmoHjQ4YRSTdEceI5F0+vjvxDT8fLxvbygBB SLfTSliCHdZnS3dZKp9RFTDuFmuhn5aFTe6/MS75yX5GHgogEjfCDtbEwvij39DZ +RzAybO/mRZQhOYvEwz9hNU5jaasX7fEWdtBSCoJB4Iap9FYXevcKZO4/ry46P8R 11j336FcT0jIiTdfwXE04TcWkvmSObF2RIK6Bm0PAamHM0FfFQvJ4rBRnIb42Urq 6OwgPSSA6vk1XA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=qQ2Uo4sZkAVaozq2Ef8yZLRceN0cw pQIO2sg8i0bfCE=; b=c3eVfueBDLre2XBIiCKAs6Xu9s06AMnvFx602Dj1bV0HE oilq+SDbGIyr36L7bNIFMeE1WCoPx9p3XJ9OukbXxktQctTP42Xz1KNbVOVzFq7L BB3zVSuRKTWTf9z8OZ12J9+oMU1cWmukydczcuZrOYOp2AjcqtFneahckI84SdJb Hu0n4/XeNPmyr1YOwMzk3dk32HLSevOsY7jt74LO6HpzK8b1qsJ7glx4M4f0/itm oxkAlFJn7tKqQ4uye3+M8lsXRSLSMiFl1ibC9BmpexNATxkHg6cntxsDxFa7a/LE 3I2lDwqd4v/OheS3/CCpir+9HEy5QVmQDMeJysc7A==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3FEA1621BF; Sat, 31 Mar 2018 08:32:44 -0400 (EDT)
Message-Id: <1522499564.1150856.1322150896.246D3ADB@webmail.messagingengine.com>
From: Alexey Melnikov 
To: cbor@ietf.org
Cc: Joe Hildebrand , Barry Leiba , Francesca Palombini 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338
Date: Sat, 31 Mar 2018 13:32:44 +0100
Archived-At: 
Subject: [Cbor] New CBOR co-chair
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Mar 2018 12:32:46 -0000

Hi,
After Joe Hildebrand announcing stepping down as CBOR co-chair, I received a good list of volunteers.  After consulting with Francesca, I've selected Barry Leiba as Joe's replacement. Barry is an experienced IETFer and followed CORE and CBOR work in the past. I have utmost confidence that with Barry's help I will see CDDL and revision of the base specification soon in my publication queue.

I would like to thank Joe for his past contribution to the CBOR WG and wishing him all the best in his future projects.

Thank you,
Alexey Melnikov, as AD