From nobody Mon Jan 3 04:28:10 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1773A128B for ; Mon, 3 Jan 2022 04:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT2q8BG-dWrC for ; Mon, 3 Jan 2022 04:28:03 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 7C3943A128A for ; Mon, 3 Jan 2022 04:28:03 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id z29so135232013edl.7 for ; Mon, 03 Jan 2022 04:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=L18dItYPIjFvL1oQXSUnsDjNQelUKUr9N5PaeF3VUbo=; b=D01M3leDIlsXkLIXlCDlIS6krkJcx8CBMxVat+2F3y7U+ncEEpMFOhOcAN2EVA3jbW dodUePG3hn2TL2JWRqeqDFOOCGq7weH1KmOupWyTZktFxZoiYs57Ov/jQ3ujs1jV8lCu vvRjlS9rsaO4G0YLNyrGPw0KeS9KJ9TTRPCdqFjOOL6qZIO6yloWZF6G6BdChwc/1mMM 7QfZv+/dNq8mSKB7cAzbgHWOBSUtBynU3CqevGB/EgNUc7Cxhm11yaP46smGOAIeRS4D zHAxtt3s4mBgDR4jNaRV8Js23nlrAMCU9hcvL0i+su+u88OswAL/X876pIUg+J6l4BoI C5ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=L18dItYPIjFvL1oQXSUnsDjNQelUKUr9N5PaeF3VUbo=; b=KBI4Qmj3axcpv9asifnxr5atKuNSzAOLkM4uh3YtZmGMKlCvbnWbUBAQTL0PqlNMVF 4nk5Z9cWL5e8DXXSOU60Eq7yu2xdkA0FdLF5UuDX1EDwiJRZQupIEhgL7fVNWf1CnGgr 2FpmafLNX9oJPqeMQrb512dLqEkHtYekXMtHS4e2osndWAtBdZ57gQZlDVeRr8yPo9yJ Vdyi0/ABrnbP2apnckz77c+tl88/Jt2yYPM1IJPpSbMpD+GxWxYsP7TNu/WP+aPuy10+ aV8jAIM/YymgaeipHA43YuuHN524zhzU4q6/NOmaKLb6VkIjCIsXNpWXHfcRnAdxOVal 7J1Q== X-Gm-Message-State: AOAM531MNaKqT/FnRK8uWi2pWZ6VcBCe8axKqJ8oN2OlhQsQXTUJJP7b bP8b+2f4G71tRDZ65gMHk/ztnVaW8JvRcw== X-Google-Smtp-Source: ABdhPJx6L18F1Cn02E0KJPWYgXmnxZ3G1IxgVhlTSAqBEm9fJWdx1UPL/krthR/ASyWkRTy2V+5KXQ== X-Received: by 2002:a17:907:94c9:: with SMTP id dn9mr38510414ejc.298.1641212880373; Mon, 03 Jan 2022 04:28:00 -0800 (PST) Received: from smtpclient.apple ([2001:984:65b0:2:bd5e:a297:837f:dbce]) by smtp.gmail.com with ESMTPSA id y13sm13573714edq.77.2022.01.03.04.28.00 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jan 2022 04:28:00 -0800 (PST) From: James G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Message-Id: Date: Mon, 3 Jan 2022 13:27:59 +0100 To: jsonpath@ietf.org X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: [Jsonpath] January 2022 interim meeting and agenda X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 12:28:08 -0000 Folks, This is a gentle reminder that our next interim meeting is in = approximately two weeks on Tuesday, January 18th at 10:00 UTC. = https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/json= path We haven't finalised (or published) the agenda yet, so if there=E2=80=99s = any subjects or issues you=E2=80=99d like to be part of it please email = myself or Tim and we can include it. - J= From nobody Mon Jan 3 05:02:13 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A01D3A00E1 for ; Mon, 3 Jan 2022 05:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYxxfw0_ozFI for ; Mon, 3 Jan 2022 05:02:06 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 CF5BA3A0122 for ; Mon, 3 Jan 2022 05:02:06 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id gj24so28811348pjb.0 for ; Mon, 03 Jan 2022 05:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=55PsX6SwgL/8OrMpmfVRC9zQtLI9Qq26e25dbUzkdxg=; b=QJKmNAC/GEOpY5SgwypVt7Zjueru5XtpONLotNznoamkYuDOEwlG0kKgzRyobHu+mn KMFFf+c6Adi9Ol7JP43EkyqDV3/zTE+wTuWkstog01bDVqw5KDKssnq4dWwTDB8AlzH4 AhYMpebf3PYmCKUu3jhIfa/X+u0NnuykRT7lyPJJhC9oPYtZkIdf8TAZbG8r/WdknPgQ 4CkZC0mAX2F3sa2Oi4w3Sje6ozd9TjCjFy02YZQxl2HEycYT3smsV7u+P4fkRmPjMJFx AZM1dnXmJzjQQT6S3k3hqhz61w4p01AtAmVcxLpk5UpjBmSd0hFxH8sTDLk9IGr3wSrF sakg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=55PsX6SwgL/8OrMpmfVRC9zQtLI9Qq26e25dbUzkdxg=; b=5gG6PZs2xJGyW+dx9UziSoBkmbR9REDwErX76V66imRGkbgk0fW3QsWaLU3Vw//ArB W0w1AdV5Hs4p3y/wh9hvaaqM5+nGyuuzANumsyHqfohYYM75SY8/ZWjocmSiIN1htOpB 7l8zRTPt2a/25NyPgO8MiYEPokli92cs586cx6vOApOWRxkhmt5L/HEf3JZyeWRVeeM7 WHR0oJ9r4or/yDNNEJ0SMygIn3qFVX+QWz0cbdr5wnoLFSu81FiBSGIX6Ar9jZpo0m9h wnyfZ0hAC8nvBqOctQuUuZ83th1ZlewzgngZfR1WaHYqftzY31yqMifBAX6vDhecJWES laFQ== X-Gm-Message-State: AOAM530TlVcABl8aEOOtBPKedzcTpLwNxKmDCcnD/JXHj7U5Q0R2Nz1O oHB7O69xfzXBLfuX4TDMBWLKThEQTDCi6xyHiYk= X-Google-Smtp-Source: ABdhPJw++gZ3MdGqH9LV5uS2zhcLHLKRkxEgpTaGnx4nehyW4+N8CGBESJlJS/SO0zYNx2dYku77jXY6xFrPiUv72Ew= X-Received: by 2002:a17:903:1209:b0:149:a428:19ef with SMTP id l9-20020a170903120900b00149a42819efmr18121957plh.47.1641214922070; Mon, 03 Jan 2022 05:02:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Glyn Normington Date: Mon, 3 Jan 2022 13:01:50 +0000 Message-ID: To: James G Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e480905d4ad20e2" Archived-At: Subject: Re: [Jsonpath] January 2022 interim meeting and agenda X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 13:02:11 -0000 --0000000000006e480905d4ad20e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks James. I would like to discuss the following: https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 Happy New Year everyone! On Mon, 3 Jan 2022 at 12:28, James G wrote: > Folks, > This is a gentle reminder that our next interim meeting is in > approximately two weeks on Tuesday, January 18th at 10:00 UTC. > > > https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/jso= npath > > We haven't finalised (or published) the agenda yet, so if there=E2=80=99s= any > subjects or issues you=E2=80=99d like to be part of it please email mysel= f or Tim > and we can include it. > > - J > -- > JSONpath mailing list > JSONpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --0000000000006e480905d4ad20e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks James. I would like to discuss the following:<= /div>


Happy New Year ever= yone!

On Mon, 3 Jan 2022 at 12:28, James G <james.ietf@gmail.com> wrote:
Folks,
This is a gentle reminder that our next interim meeting is in approximately= two weeks on Tuesday, January 18th at 10:00 UTC.

https://datatracker.ie= tf.org/meeting/interim-2022-jsonpath-01/session/jsonpath

We haven't finalised (or published) the agenda yet, so if there=E2=80= =99s any subjects or issues you=E2=80=99d like to be part of it please emai= l myself or Tim and we can include it.

- J
--
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--0000000000006e480905d4ad20e2-- From nobody Mon Jan 3 05:54:29 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397DC3A07D8 for ; Mon, 3 Jan 2022 05:54:27 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeiKI5H0kGvv for ; Mon, 3 Jan 2022 05:54:23 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03503A07D6 for ; Mon, 3 Jan 2022 05:54:22 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JSHKk1zgrzDCc0; Mon, 3 Jan 2022 14:54:18 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 Jan 2022 14:54:17 +0100 Cc: James G , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 662910857.875549-0672c94de6c73c9c75fa655d05a0e0b8 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 13:54:27 -0000 On 2022-01-03, at 14:01, Glyn Normington = wrote: >=20 > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 Right. I=E2=80=99ll continue the discussion here (instead of github), as we = need to make a (somewhat non-technical) WG decision. We know that there is no easy way to generate a specification for a = standard form of regular expressions (RE) (there is no such standard = form). Taking it from there, options include: (1) not having RE support in jsonpath-base (2) defining a lowest-common-denominator syntax and including that in = jsonpath-base (3) having RE syntax but not defining what that means (=E2=80=9Cpermissive= =E2=80=9D) and not providing a way to identify which syntax variant is = being used Within (2), there are multiple suboptions. Editorially: (a) define the LCD RE syntax and semantics in jsonpath-base (b) define the syntax and semantics in a separate document (This is not a very important distinction, but a decision will have to = be made.) Note that we have to define both the RE syntax itself and the decoration = that allows its use in jsonpath. Within the selection process for those two, we=E2=80=99ll have to make = subdivisions, of which I happen to have at the front of my mind: (i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style) (ii) make the outermost syntax look like existing syntax, failing many = instances that don=E2=80=99t happen to presume the same syntax, but = magically supporting some other instances that do happen to fit (iii) use a regular expression subset that is actually based on regular = expressions (Chomsky type 3 languages), or one that provides PCRE-style = additions that don=E2=80=99t allow DFA transformation (and thus = efficient, attack-resistant implementation) So much for laying out the decisions. Here is my opinion, based on a few decades of trying to make standards = work: Clearly, I think 3 is not OK for interoperability. 1 is OK by = postponing the decision (as long as the extension point is announced); 2 = is more =E2=80=9Cbatteries included=E2=80=9D. Within 2, I favor 2b. With respect to the technical subdecisions: (i): A matching syntax is actually what is needed. Most programmers learn a parsing syntax first, because one use case for = REs is writing shoddy parsers =E2=80=94 something that we cannot use in = JSONpath. I wouldn=E2=80=99t mind making the decision for a matching syntax highly = visible, also because (ii): We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D, = unless we can make sure that they are interoperable. (iii): I believe that actual RE-based syntaxes are a good subset decision = anyway. The only candidate here that is actually standardized in XSD, = but that has some unwanted baggage (character class subtraction =E2=80=94 = which is great, but not widely offered by other RE syntaxes our LCD = would need to translate into). There are further detail decisions, e.g., what does \d or \w actually = mean; we might simplify our lives by using a LCD subset that poses as = few questions of this kind as possible. Iregexp is a proposal for a separate document (2b) that plays along = these lines. I think I would like to develop this proposal further towards the goal = expressed in the previous paragraph. JSONpath of course is not the only area of application for RE syntaxes = inside the IETF. Notably, YANG and CDDL have chosen full XSD syntax, = with striking acceptance problems on the YANG side (CDDL users seem to = be more prudent here, in particular now with RFC 9165 available for = complex cases; CDDL also has a defined extension point for dropping in = multiple syntaxes). This experience strengthens my preference for a LCD = subset. I understand that a world would be more likable where we could just drop = in REs from a common, well-understood usage. Unfortunately, we don=E2=80=99= t have this world. Making decisions based on wishful thinking we did is = not doing the right thing. I also understand that my perspective may be somewhat different from = other WG members, as I have already spent a significant amount of time = researching the RE conundrum in different contexts. So I=E2=80=99m very = open to explaining this perspective in some more detail. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jan 3 07:16:53 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08323A09E3 for ; Mon, 3 Jan 2022 07:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNYPxilTA5mz for ; Mon, 3 Jan 2022 07:16:47 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 67F5F3A09DD for ; Mon, 3 Jan 2022 07:16:47 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id l10-20020a17090a384a00b001b22190e075so32667994pjf.3 for ; Mon, 03 Jan 2022 07:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tBTqhmy/glD66AOI6AypwFdHNS5q2v6piiHd6/YOlCk=; b=PzmxUr8hrZgkOX77BehLiTjwj2qdV6aN6mGvG4nmXOSdiL0WUf0xLhBowaXZvV0TE8 4uPh1bl+kgEEJ2uYT+O6HOAzTfWifm6ZXaQVsOLWzj06X1n+P6RyHZSAaJptJ9IYD7J4 qyR2L3qVYbPuEryTMptYxhYzzd9JQrz2dBgCv0K6A0u+kDmEOuLESJtkY9aY8YsRy1ZJ a8QhREI/mar/pqjxSAkjMO4GLmPNW81R3Swt2kcAaGRGaJ/fp+JF5BkJECbeaDD4xTtD cOcdxOwiWgro71ngz0Pbg4qAwIIODn5i3ploBfWS3po8IkjWFCd3apgvNfWfZX6dNGOJ I6Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tBTqhmy/glD66AOI6AypwFdHNS5q2v6piiHd6/YOlCk=; b=U4w6BedznOA7mzEbWnW80k/9RqZZSPrifaxWZ5pkI0ats0d9ifFDp325OtMYqSkGhJ JdB1xzwhAzYWQqeDSU4JDlBQcquoHHBqljmaCUz4Z+99k6bRiMivNhb0PEht/yL4nKdo P0dluXW4m+aYgHh5A8Gh4MyQgvnlh7PUKvwU+ROcQdYB0hBRxUZbXBhcXs2NSG1q+bD0 BQY+pkgOdSVreiOdyxGgjiCmWCWpPMdy254J/a01DGDTLIb7YRjAh+Dqe3np/zctZiUx Xw1ds/I8M4R4m/KRn8QOX8LUUQpJdvdey7Y5YCbsVhsLkxr/TxFONS0xTs0K+H8O0Nih TBbA== X-Gm-Message-State: AOAM533KQB/x8JlmkKSIo6xwZtKe7O/vmATu6ZO0Ld9QAYSY5K2D0B3N Mcq4sOG6RmbH9b5hkwUv4tSKIHnQtCjvLv9Is4I= X-Google-Smtp-Source: ABdhPJynSK594E5krb6raojtsXlaDKe0KpB0Cl8HocKhQYfWJhQF58o9HDernGp1KKtWOkzO8s4REu1BKV7CitEflGQ= X-Received: by 2002:a17:903:1209:b0:149:a428:19ef with SMTP id l9-20020a170903120900b00149a42819efmr18582397plh.47.1641223003644; Mon, 03 Jan 2022 07:16:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Glyn Normington Date: Mon, 3 Jan 2022 15:16:31 +0000 Message-ID: To: Carsten Bormann Cc: James G , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000021282605d4af0238" Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 15:16:52 -0000 --00000000000021282605d4af0238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten. I agree with everything you wrote there. I'm keen to complete the JSONPath draft within a reasonable time frame and I fear that regexp support may take quite a while to finalise. So I'd like us to consider finalising an *interim draft* without regexp support (i.e. option 1). Such a draft would be a useful checkpoint and holding position until iregexp is complete. The other main benefit of finalising such an interim draft would be to flush out any remaining changes that are needed in addition to regexp support. An interim draft would also be useful input toward a compliance test suite and reference implementation (assuming someone will find time to work on either or both of these!). The rest of the spec still being in flux is a disincentive to anyone investing in building a CTS and RI. On Mon, 3 Jan 2022, 13:54 Carsten Bormann, wrote: > On 2022-01-03, at 14:01, Glyn Normington > wrote: > > > > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 > > Right. > > I=E2=80=99ll continue the discussion here (instead of github), as we need= to make > a (somewhat non-technical) WG decision. > > We know that there is no easy way to generate a specification for a > standard form of regular expressions (RE) (there is no such standard > form). Taking it from there, options include: > > (1) not having RE support in jsonpath-base > (2) defining a lowest-common-denominator syntax and including that in > jsonpath-base > (3) having RE syntax but not defining what that means (=E2=80=9Cpermissiv= e=E2=80=9D) and > not providing a way to identify which syntax variant is being used > > Within (2), there are multiple suboptions. Editorially: > > (a) define the LCD RE syntax and semantics in jsonpath-base > (b) define the syntax and semantics in a separate document > > (This is not a very important distinction, but a decision will have to be > made.) > > Note that we have to define both the RE syntax itself and the decoration > that allows its use in jsonpath. > > Within the selection process for those two, we=E2=80=99ll have to make > subdivisions, of which I happen to have at the front of my mind: > (i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style) > (ii) make the outermost syntax look like existing syntax, failing many > instances that don=E2=80=99t happen to presume the same syntax, but magic= ally > supporting some other instances that do happen to fit > (iii) use a regular expression subset that is actually based on regular > expressions (Chomsky type 3 languages), or one that provides PCRE-style > additions that don=E2=80=99t allow DFA transformation (and thus efficient= , > attack-resistant implementation) > > So much for laying out the decisions. > > Here is my opinion, based on a few decades of trying to make standards > work: > > Clearly, I think 3 is not OK for interoperability. 1 is OK by postponing > the decision (as long as the extension point is announced); 2 is more > =E2=80=9Cbatteries included=E2=80=9D. > > Within 2, I favor 2b. > With respect to the technical subdecisions: > > (i): > A matching syntax is actually what is needed. > Most programmers learn a parsing syntax first, because one use case for > REs is writing shoddy parsers =E2=80=94 something that we cannot use in J= SONpath. > I wouldn=E2=80=99t mind making the decision for a matching syntax highly = visible, > also because (ii): > We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D, u= nless we can make sure > that they are interoperable. > > (iii): > I believe that actual RE-based syntaxes are a good subset decision > anyway. The only candidate here that is actually standardized in XSD, bu= t > that has some unwanted baggage (character class subtraction =E2=80=94 whi= ch is > great, but not widely offered by other RE syntaxes our LCD would need to > translate into). > > There are further detail decisions, e.g., what does \d or \w actually > mean; we might simplify our lives by using a LCD subset that poses as few > questions of this kind as possible. > > Iregexp is a proposal for a separate document (2b) that plays along these > lines. > I think I would like to develop this proposal further towards the goal > expressed in the previous paragraph. > > JSONpath of course is not the only area of application for RE syntaxes > inside the IETF. Notably, YANG and CDDL have chosen full XSD syntax, wit= h > striking acceptance problems on the YANG side (CDDL users seem to be more > prudent here, in particular now with RFC 9165 available for complex cases= ; > CDDL also has a defined extension point for dropping in multiple > syntaxes). This experience strengthens my preference for a LCD subset. > > I understand that a world would be more likable where we could just drop > in REs from a common, well-understood usage. Unfortunately, we don=E2=80= =99t have > this world. Making decisions based on wishful thinking we did is not doin= g > the right thing. > > I also understand that my perspective may be somewhat different from othe= r > WG members, as I have already spent a significant amount of time > researching the RE conundrum in different contexts. So I=E2=80=99m very = open to > explaining this perspective in some more detail. > > Gr=C3=BC=C3=9Fe, Carsten > > --00000000000021282605d4af0238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten. I agree with everything you wrote there.<= div dir=3D"auto">
I'm keen to complete the J= SONPath draft within a reasonable=C2=A0time frame and I fear that regexp su= pport may take quite a while to finalise. So I'd like us to consider fi= nalising an *interim draft* without regexp support (i.e. option 1). Such a = draft would be a useful checkpoint and holding position until iregexp is co= mplete.

The other main b= enefit of finalising such an interim draft would be to flush out any remain= ing changes that are needed in addition to regexp support.

An interim draft would also be useful in= put toward a compliance test suite and reference implementation (assuming s= omeone will find time to work on either or both of these!). The rest of the= spec still being in flux is a disincentive to anyone investing in building= a CTS and RI.

On Mon, 3 Jan 2022, 13:54 Cars= ten Bormann, <cabo@tzi.org> wrote:
On 2022-01-03, at 14:01, Glyn Normington <gly= n.normington.work@gmail.com> wrote:
>
> http= s://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143

Right.

I=E2=80=99ll continue the discussion here (instead of github), as we need t= o make a (somewhat non-technical) WG decision.

We know that there is no easy way to generate a specification for a standar= d form of regular expressions (RE) (there is no such standard form).=C2=A0 = Taking it from there, options include:

(1) not having RE support in jsonpath-base
(2) defining a lowest-common-denominator syntax and including that in jsonp= ath-base
(3) having RE syntax but not defining what that means (=E2=80=9Cpermissive= =E2=80=9D) and not providing a way to identify which syntax variant is bein= g used

Within (2), there are multiple suboptions. Editorially:

(a) define the LCD RE syntax and semantics in jsonpath-base
(b) define the syntax and semantics in a separate document

(This is not a very important distinction, but a decision will have to be m= ade.)

Note that we have to define both the RE syntax itself and the decoration th= at allows its use in jsonpath.

Within the selection process for those two, we=E2=80=99ll have to make subd= ivisions, of which I happen to have at the front of my mind:
(i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style)
(ii) make the outermost syntax look like existing syntax, failing many inst= ances that don=E2=80=99t happen to presume the same syntax, but magically s= upporting some other instances that do happen to fit
(iii) use a regular expression subset that is actually based on regular exp= ressions (Chomsky type 3 languages), or one that provides PCRE-style additi= ons that don=E2=80=99t allow DFA transformation (and thus efficient, attack= -resistant implementation)

So much for laying out the decisions.

Here is my opinion, based on a few decades of trying to make standards work= :

Clearly, I think 3 is not OK for interoperability.=C2=A0 1 is OK by postpon= ing the decision (as long as the extension point is announced); 2 is more = =E2=80=9Cbatteries included=E2=80=9D.

Within 2, I favor 2b.
With respect to the technical subdecisions:

(i):
A matching syntax is actually what is needed.
Most programmers learn a parsing syntax first, because one use case for REs= is writing shoddy parsers =E2=80=94 something that we cannot use in JSONpa= th.
I wouldn=E2=80=99t mind making the decision for a matching syntax highly vi= sible, also because (ii):
We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D, unl= ess we can make sure that they are interoperable.

(iii):
I believe that actual RE-based syntaxes are a good subset decision anyway.= =C2=A0 The only candidate here that is actually standardized in XSD, but th= at has some unwanted baggage (character class subtraction =E2=80=94 which i= s great, but not widely offered by other RE syntaxes our LCD would need to = translate into).

There are further detail decisions, e.g., what does \d or \w actually mean;= we might simplify our lives by using a LCD subset that poses as few questi= ons of this kind as possible.

Iregexp is a proposal for a separate document (2b) that plays along these l= ines.
I think I would like to develop this proposal further towards the goal expr= essed in the previous paragraph.

JSONpath of course is not the only area of application for RE syntaxes insi= de the IETF.=C2=A0 Notably, YANG and CDDL have chosen full XSD syntax, with= striking acceptance problems on the YANG side (CDDL users seem to be more = prudent here, in particular now with RFC 9165 available for complex cases; = CDDL also has a defined extension point for dropping in multiple syntaxes).= =C2=A0 This experience strengthens my preference for a LCD subset.

I understand that a world would be more likable where we could just drop in= REs from a common, well-understood usage.=C2=A0 Unfortunately, we don=E2= =80=99t have this world. Making decisions based on wishful thinking we did = is not doing the right thing.

I also understand that my perspective may be somewhat different from other = WG members, as I have already spent a significant amount of time researchin= g the RE conundrum in different contexts.=C2=A0 So I=E2=80=99m very open to= explaining this perspective in some more detail.

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

--00000000000021282605d4af0238-- From nobody Mon Jan 3 10:56:40 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367F53A097E for ; Mon, 3 Jan 2022 10:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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 JVT8rb6gcaAa for ; Mon, 3 Jan 2022 10:56:34 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (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 1D9ED3A0977 for ; Mon, 3 Jan 2022 10:56:33 -0800 (PST) Received: from [192.168.178.20] ([88.130.50.127]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Md6dH-1mUZWQ2xZj-00aAup; Mon, 03 Jan 2022 19:56:21 +0100 Content-Type: multipart/alternative; boundary="------------0RBqCO15oFNASPaUZtHGv30h" Message-ID: Date: Mon, 3 Jan 2022 19:56:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: Glyn Normington , Carsten Bormann Cc: jsonpath@ietf.org, James G References: From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= In-Reply-To: X-Provags-ID: V03:K1:dMVoQ61OHIkHUz0J0KselnV7qP4Tbkav92gdpRn6S4j+n1jfUw3 nyIyuPBPk6D73FgXfOH7584ZHp5meYdMzdgTyDYXdE6EqdNEjMwHZ7qYbfnpafScl1gBY7u 7NT/43FanQ+cK5/WWMJSz202pc/xYDzoMifvJyf57oqipY+Wh0Zd5NV59bz4B4V2zpyy5r+ deER5pUpZ9Nc1obzt/btA== X-UI-Out-Filterresults: notjunk:1;V03:K0:v98N+AUtP9I=:xCNw9ps0UOybM4HBZ7OkXV jLvmYlkZLmkhW1607T4H97RSDZ0uquvLHG3D81/u+woMGUeE0v+E1Q8GQOvwy6y9+lZHDIkK4 1DL6SZE/qMLksXNbppg9gyrTjgFBPVb9NI+jIcD2EQ/2ui0kMNz8C9Pv4flk/yzZ7cT3466XN c94EVpdx/doQiwVDqGbRGzTGuImLk99myJB5I44FCo9nvWqRB5PUZysPciWpCcRNcD5kN+JwJ 0mFwWefbzk7T68370w0WTPnKHO6xHDErZKqB+lRCVz+LGzG2/I36TtADzmQcLOhdDseAL30Qd uBaGwVH/Lq5wS7sVqwq+iCQvPmTJ10A/zXGcvko8F9WSot65fg/AUL53HMEXcqrtQt7S9lp9S mHZwi/pX930ga2bEY+U5eFZiENb3vgLIsOw6FjVS8xRhowmRytdaMPFYu9YbiXFWkp+OqIrBR 7arKkbBLABIQY8emMowZQfC92WkJLPQTv/Rbj1AOEL4Xb3YaSeXUZ8PM3lOb4ZIgMnoQPlP/c DTPk+v/kHExOBIDx86QkIGW2uu/uKby4+dS4uUE98Ayv3vPLCHexLu6kFV6TedFmphqIUMsQF rgT7iAL+u9Nd8loyzBSYFAlwK+XK6if+BY1EIp2V53rgzkligyzRUiBi8dFUVH92JeYF2qDBl JKE58bpu63yoLEdR+WXPOlGY0gGMb0Qsz3fEZaW/MygGOFIF+fFIlXnNNLEj1gMwbDHw= Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 18:56:39 -0000 This is a multi-part message in MIME format. --------------0RBqCO15oFNASPaUZtHGv30h Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Happy new year from me also to everyone. I already committed to sympathise with Carsten's proposal 2b. Yet I also strongly agree to Glyn's point of completing the JSONPath draft in a reasonable time frame. So from Carsten's background of few decades of standards work experience, I would like to ask: how can we estimate the chance of finishing here at approximately the same time frame with both drafts? If Iregexp presumably needs significantly more time for finishing, I favour the 'finalising an interim draft' approach according to proposal 1, with respect to the benefits Glyn has stated. But I must confess, that I don't know, what an 'interim draft' exactly is and if 'extension points' are necessary then. // ================================ I would like to also discuss filter-selectors regarding ... * Comparisons are restricted to primitive values (such as number, string, true, false, null). Comparisons with complex values will fail, i.e. no selection occurs. There seems to be a majority consense to allow structured (complex ?) values with comparisons. We should discuss that technically and try to strive for agreement here. Thanks -- sg Am 03.01.2022 um 16:16 schrieb Glyn Normington: > Thanks Carsten. I agree with everything you wrote there. > > I'm keen to complete the JSONPath draft within a reasonable time frame > and I fear that regexp support may take quite a while to finalise. So > I'd like us to consider finalising an *interim draft* without regexp > support (i.e. option 1). Such a draft would be a useful checkpoint and > holding position until iregexp is complete. > > The other main benefit of finalising such an interim draft would be to > flush out any remaining changes that are needed in addition to regexp > support. > > An interim draft would also be useful input toward a compliance test > suite and reference implementation (assuming someone will find time to > work on either or both of these!). The rest of the spec still being in > flux is a disincentive to anyone investing in building a CTS and RI. > > On Mon, 3 Jan 2022, 13:54 Carsten Bormann, wrote: > > On 2022-01-03, at 14:01, Glyn Normington > wrote: > > > > > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 > > Right. > > I’ll continue the discussion here (instead of github), as we need > to make a (somewhat non-technical) WG decision. > > We know that there is no easy way to generate a specification for > a standard form of regular expressions (RE) (there is no such > standard form).  Taking it from there, options include: > > (1) not having RE support in jsonpath-base > (2) defining a lowest-common-denominator syntax and including that > in jsonpath-base > (3) having RE syntax but not defining what that means > (“permissive”) and not providing a way to identify which syntax > variant is being used > > Within (2), there are multiple suboptions. Editorially: > > (a) define the LCD RE syntax and semantics in jsonpath-base > (b) define the syntax and semantics in a separate document > > (This is not a very important distinction, but a decision will > have to be made.) > > Note that we have to define both the RE syntax itself and the > decoration that allows its use in jsonpath. > > Within the selection process for those two, we’ll have to make > subdivisions, of which I happen to have at the front of my mind: > (i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style) > (ii) make the outermost syntax look like existing syntax, failing > many instances that don’t happen to presume the same syntax, but > magically supporting some other instances that do happen to fit > (iii) use a regular expression subset that is actually based on > regular expressions (Chomsky type 3 languages), or one that > provides PCRE-style additions that don’t allow DFA transformation > (and thus efficient, attack-resistant implementation) > > So much for laying out the decisions. > > Here is my opinion, based on a few decades of trying to make > standards work: > > Clearly, I think 3 is not OK for interoperability.  1 is OK by > postponing the decision (as long as the extension point is > announced); 2 is more “batteries included”. > > Within 2, I favor 2b. > With respect to the technical subdecisions: > > (i): > A matching syntax is actually what is needed. > Most programmers learn a parsing syntax first, because one use > case for REs is writing shoddy parsers — something that we cannot > use in JSONpath. > I wouldn’t mind making the decision for a matching syntax highly > visible, also because (ii): > We don’t want to make existing REs “just work”, unless we can make > sure that they are interoperable. > > (iii): > I believe that actual RE-based syntaxes are a good subset decision > anyway.  The only candidate here that is actually standardized in > XSD, but that has some unwanted baggage (character class > subtraction — which is great, but not widely offered by other RE > syntaxes our LCD would need to translate into). > > There are further detail decisions, e.g., what does \d or \w > actually mean; we might simplify our lives by using a LCD subset > that poses as few questions of this kind as possible. > > Iregexp is a proposal for a separate document (2b) that plays > along these lines. > I think I would like to develop this proposal further towards the > goal expressed in the previous paragraph. > > JSONpath of course is not the only area of application for RE > syntaxes inside the IETF.  Notably, YANG and CDDL have chosen full > XSD syntax, with striking acceptance problems on the YANG side > (CDDL users seem to be more prudent here, in particular now with > RFC 9165 available for complex cases; CDDL also has a defined > extension point for dropping in multiple syntaxes).  This > experience strengthens my preference for a LCD subset. > > I understand that a world would be more likable where we could > just drop in REs from a common, well-understood usage.  > Unfortunately, we don’t have this world. Making decisions based on > wishful thinking we did is not doing the right thing. > > I also understand that my perspective may be somewhat different > from other WG members, as I have already spent a significant > amount of time researching the RE conundrum in different > contexts.  So I’m very open to explaining this perspective in some > more detail. > > Grüße, Carsten > > > > Virenfrei. www.avg.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > --------------0RBqCO15oFNASPaUZtHGv30h Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Happy new year from me also to everyone.

I already committed to sympathise with Carsten's proposal 2b.

Yet I also strongly agree to Glyn's point of completing the JSONPath draft in a reasonable time frame.

So from Carsten's background of few decades of standards work experience, I would like to ask: how can we estimate the chance of finishing here at approximately the same time frame with both drafts?

If Iregexp presumably needs significantly more time for finishing, I favour the 'finalising an interim draft' approach according to proposal 1, with respect to the benefits Glyn has stated.

But I must confess, that I don't know, what an 'interim draft' exactly is and if 'extension points' are necessary then.

// ================================

I would like to also discuss filter-selectors regarding ...

* Comparisons are restricted to primitive values (such as number,
      string, true, false, null).  Comparisons with complex values will
      fail, i.e. no selection occurs.
There seems to be a majority consense to allow structured (complex ?) values with comparisons. We should discuss that technically and try to strive for agreement here.

Thanks
--
sg


Am 03.01.2022 um 16:16 schrieb Glyn Normington:
Thanks Carsten. I agree with everything you wrote there.

I'm keen to complete the JSONPath draft within a reasonable time frame and I fear that regexp support may take quite a while to finalise. So I'd like us to consider finalising an *interim draft* without regexp support (i.e. option 1). Such a draft would be a useful checkpoint and holding position until iregexp is complete.

The other main benefit of finalising such an interim draft would be to flush out any remaining changes that are needed in addition to regexp support.

An interim draft would also be useful input toward a compliance test suite and reference implementation (assuming someone will find time to work on either or both of these!). The rest of the spec still being in flux is a disincentive to anyone investing in building a CTS and RI.

On Mon, 3 Jan 2022, 13:54 Carsten Bormann, <cabo@tzi.org> wrote:
On 2022-01-03, at 14:01, Glyn Normington <glyn.normington.work@gmail.com> wrote:
>
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143

Right.

I’ll continue the discussion here (instead of github), as we need to make a (somewhat non-technical) WG decision.

We know that there is no easy way to generate a specification for a standard form of regular expressions (RE) (there is no such standard form).  Taking it from there, options include:

(1) not having RE support in jsonpath-base
(2) defining a lowest-common-denominator syntax and including that in jsonpath-base
(3) having RE syntax but not defining what that means (“permissive”) and not providing a way to identify which syntax variant is being used

Within (2), there are multiple suboptions. Editorially:

(a) define the LCD RE syntax and semantics in jsonpath-base
(b) define the syntax and semantics in a separate document

(This is not a very important distinction, but a decision will have to be made.)

Note that we have to define both the RE syntax itself and the decoration that allows its use in jsonpath.

Within the selection process for those two, we’ll have to make subdivisions, of which I happen to have at the front of my mind:
(i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style)
(ii) make the outermost syntax look like existing syntax, failing many instances that don’t happen to presume the same syntax, but magically supporting some other instances that do happen to fit
(iii) use a regular expression subset that is actually based on regular expressions (Chomsky type 3 languages), or one that provides PCRE-style additions that don’t allow DFA transformation (and thus efficient, attack-resistant implementation)

So much for laying out the decisions.

Here is my opinion, based on a few decades of trying to make standards work:

Clearly, I think 3 is not OK for interoperability.  1 is OK by postponing the decision (as long as the extension point is announced); 2 is more “batteries included”.

Within 2, I favor 2b.
With respect to the technical subdecisions:

(i):
A matching syntax is actually what is needed.
Most programmers learn a parsing syntax first, because one use case for REs is writing shoddy parsers — something that we cannot use in JSONpath.
I wouldn’t mind making the decision for a matching syntax highly visible, also because (ii):
We don’t want to make existing REs “just work”, unless we can make sure that they are interoperable.

(iii):
I believe that actual RE-based syntaxes are a good subset decision anyway.  The only candidate here that is actually standardized in XSD, but that has some unwanted baggage (character class subtraction — which is great, but not widely offered by other RE syntaxes our LCD would need to translate into).

There are further detail decisions, e.g., what does \d or \w actually mean; we might simplify our lives by using a LCD subset that poses as few questions of this kind as possible.

Iregexp is a proposal for a separate document (2b) that plays along these lines.
I think I would like to develop this proposal further towards the goal expressed in the previous paragraph.

JSONpath of course is not the only area of application for RE syntaxes inside the IETF.  Notably, YANG and CDDL have chosen full XSD syntax, with striking acceptance problems on the YANG side (CDDL users seem to be more prudent here, in particular now with RFC 9165 available for complex cases; CDDL also has a defined extension point for dropping in multiple syntaxes).  This experience strengthens my preference for a LCD subset.

I understand that a world would be more likable where we could just drop in REs from a common, well-understood usage.  Unfortunately, we don’t have this world. Making decisions based on wishful thinking we did is not doing the right thing.

I also understand that my perspective may be somewhat different from other WG members, as I have already spent a significant amount of time researching the RE conundrum in different contexts.  So I’m very open to explaining this perspective in some more detail.

Grüße, Carsten


Virenfrei. www.avg.com


--------------0RBqCO15oFNASPaUZtHGv30h-- From nobody Mon Jan 3 11:14:08 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5FC3A09F8 for ; Mon, 3 Jan 2022 11:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=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=brianrosen-net.20210112.gappssmtp.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 aUfjuftwP36a for ; Mon, 3 Jan 2022 11:14:02 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 E640B3A09EF for ; Mon, 3 Jan 2022 11:14:01 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id s15so30223508pfk.6 for ; Mon, 03 Jan 2022 11:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DwFLJ/Mr7PXUltCYpH7X6PfG1hDcEPM2y3lnaePlEmU=; b=OI1kMxVWZkBPZCYpQbOKIAMt/85Lo/u8pYLRWwhrIWpzrqBcRhUpqy+gUXTZIgUcrK i7AZjte3DEjQiU1oM9a3N2pCinZZaePXzeaZmMSX8sOx7FOQ47ySecvH3UCCEem3bnqa tpF1N5pVCsNNFea9cp7mj/P4wjDesuBZ+XToa/VimSiofXgv/GQrgfN2nHoQexttuByG ZZNzk6lCuJPcUOyWRaMHwEMfsFPqIKqWMUT+PpuHZY96uWVQGe6JEc8DoFfYRIK9gypa cO/WJNi/Ht/lAVZTv8oRiMODm3G8ZxICya0gLMVuy3bl6ThPWuI7lesVmAhzgAIaV+0o I1Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DwFLJ/Mr7PXUltCYpH7X6PfG1hDcEPM2y3lnaePlEmU=; b=qCZkfdXOskSIO1Lcvws5SA/8M1jBw2UcP7FlqfHl1C9Tw6re2soxZDa5Z0ltBTFe47 vSwFASbIY6zQpc5L0X87r0ofUjih/l8WjPAqduGFGvtsmP8wM8oPSi8YNBm8160hkDsr 13xZ69IkGhRVlZnxowLQELGjtKzaOK5fBhz1IyIzuEVOKpbsNwBRZWLhYWZq/NFvzxYC YNBB4V22mxQb8ZpelqkQ6kNcxambsoo2VceR0ZDiUHDlq5P53iXgK0T9QSsNeO0p7Ej2 48pjs/s+tPrjlRV21GHGZw6OglL5FEx32kbhPbHxHnHIaUg3EmAss8mVT2wLcSUv48J5 tn8g== X-Gm-Message-State: AOAM532jHMdSCgI7givasAdhnf+MPkMD8/XJiNEZY6HGROW2h7/URPTY cjzdfkz7fDMN2j1ACWmur3Az4g== X-Google-Smtp-Source: ABdhPJxc5w9+z+uK+KxDTyPPvagiBy3nRzHOu8xGg66E3Fo/pnrEdrjYDoCCfrk3EfkRwSuYdY8W0w== X-Received: by 2002:a63:824a:: with SMTP id w71mr42183826pgd.74.1641237240982; Mon, 03 Jan 2022 11:14:00 -0800 (PST) Received: from smtpclient.apple (192-184-176-217.fiber.dynamic.sonic.net. [192.184.176.217]) by smtp.gmail.com with ESMTPSA id lk10sm42147080pjb.20.2022.01.03.11.14.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jan 2022 11:14:00 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A67CC52A-C16C-47B4-A4AD-2A22901E64EF" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Mon, 3 Jan 2022 11:13:59 -0800 In-Reply-To: Cc: Glyn Normington , Carsten Bormann , jsonpath@ietf.org, James G To: =?utf-8?Q?Stefan_G=C3=B6ssner?= References: X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 19:14:07 -0000 --Apple-Mail=_A67CC52A-C16C-47B4-A4AD-2A22901E64EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW: I agree, 2b makes the most sense. There are, as Carsten points out, = other needs for a regexp for json, and I=E2=80=99m fine with starting = with the lregexp doc. =E2=80=9CInterim Draft=E2=80=9D has no meaning in the IETF. We can = process a draft that has a normative reference to another draft, That = can take it all the way to the RFC Editor=E2=80=99s queue. It won=E2=80=99= t be published until the referenced draft is published. That=E2=80=99s = what we want to do here I think. =20 Brian > On Jan 3, 2022, at 10:56 AM, Stefan G=C3=B6ssner = wrote: >=20 > Happy new year from me also to everyone. >=20 > I already committed to sympathise with Carsten's proposal 2b. >=20 > Yet I also strongly agree to Glyn's point of completing the JSONPath = draft in a reasonable time frame. >=20 > So from Carsten's background of few decades of standards work = experience, I would like to ask: how can we estimate the chance of = finishing here at approximately the same time frame with both drafts? >=20 > If Iregexp presumably needs significantly more time for finishing, I = favour the 'finalising an interim draft' approach according to proposal = 1, with respect to the benefits Glyn has stated. >=20 > But I must confess, that I don't know, what an 'interim draft' exactly = is and if 'extension points' are necessary then. >=20 > // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I would like to also discuss filter-selectors regarding ... >=20 > * Comparisons are restricted to primitive values (such as number, > string, true, false, null). Comparisons with complex values = will > fail, i.e. no selection occurs. >=20 > There seems to be a majority consense to allow structured (complex ?) = values with comparisons. We should discuss that technically and try to = strive for agreement here. >=20 > Thanks > -- > sg >=20 >=20 > Am 03.01.2022 um 16:16 schrieb Glyn Normington: >> Thanks Carsten. I agree with everything you wrote there. >>=20 >> I'm keen to complete the JSONPath draft within a reasonable time = frame and I fear that regexp support may take quite a while to finalise. = So I'd like us to consider finalising an *interim draft* without regexp = support (i.e. option 1). Such a draft would be a useful checkpoint and = holding position until iregexp is complete. >>=20 >> The other main benefit of finalising such an interim draft would be = to flush out any remaining changes that are needed in addition to regexp = support. >>=20 >> An interim draft would also be useful input toward a compliance test = suite and reference implementation (assuming someone will find time to = work on either or both of these!). The rest of the spec still being in = flux is a disincentive to anyone investing in building a CTS and RI. >>=20 >> On Mon, 3 Jan 2022, 13:54 Carsten Bormann, > wrote: >> On 2022-01-03, at 14:01, Glyn Normington = > = wrote: >> >=20 >> > = https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 = >>=20 >> Right. >>=20 >> I=E2=80=99ll continue the discussion here (instead of github), as we = need to make a (somewhat non-technical) WG decision. >>=20 >> We know that there is no easy way to generate a specification for a = standard form of regular expressions (RE) (there is no such standard = form). Taking it from there, options include: >>=20 >> (1) not having RE support in jsonpath-base >> (2) defining a lowest-common-denominator syntax and including that in = jsonpath-base >> (3) having RE syntax but not defining what that means = (=E2=80=9Cpermissive=E2=80=9D) and not providing a way to identify which = syntax variant is being used >>=20 >> Within (2), there are multiple suboptions. Editorially: >>=20 >> (a) define the LCD RE syntax and semantics in jsonpath-base >> (b) define the syntax and semantics in a separate document >>=20 >> (This is not a very important distinction, but a decision will have = to be made.) >>=20 >> Note that we have to define both the RE syntax itself and the = decoration that allows its use in jsonpath. >>=20 >> Within the selection process for those two, we=E2=80=99ll have to = make subdivisions, of which I happen to have at the front of my mind: >> (i) use a matching syntax (XSD-style) or a parsing syntax = (PCRE-style) >> (ii) make the outermost syntax look like existing syntax, failing = many instances that don=E2=80=99t happen to presume the same syntax, but = magically supporting some other instances that do happen to fit >> (iii) use a regular expression subset that is actually based on = regular expressions (Chomsky type 3 languages), or one that provides = PCRE-style additions that don=E2=80=99t allow DFA transformation (and = thus efficient, attack-resistant implementation) >>=20 >> So much for laying out the decisions. >>=20 >> Here is my opinion, based on a few decades of trying to make = standards work: >>=20 >> Clearly, I think 3 is not OK for interoperability. 1 is OK by = postponing the decision (as long as the extension point is announced); 2 = is more =E2=80=9Cbatteries included=E2=80=9D. >>=20 >> Within 2, I favor 2b. >> With respect to the technical subdecisions: >>=20 >> (i): >> A matching syntax is actually what is needed. >> Most programmers learn a parsing syntax first, because one use case = for REs is writing shoddy parsers =E2=80=94 something that we cannot use = in JSONpath. >> I wouldn=E2=80=99t mind making the decision for a matching syntax = highly visible, also because (ii): >> We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D,= unless we can make sure that they are interoperable. >>=20 >> (iii): >> I believe that actual RE-based syntaxes are a good subset decision = anyway. The only candidate here that is actually standardized in XSD, = but that has some unwanted baggage (character class subtraction =E2=80=94 = which is great, but not widely offered by other RE syntaxes our LCD = would need to translate into). >>=20 >> There are further detail decisions, e.g., what does \d or \w actually = mean; we might simplify our lives by using a LCD subset that poses as = few questions of this kind as possible. >>=20 >> Iregexp is a proposal for a separate document (2b) that plays along = these lines. >> I think I would like to develop this proposal further towards the = goal expressed in the previous paragraph. >>=20 >> JSONpath of course is not the only area of application for RE = syntaxes inside the IETF. Notably, YANG and CDDL have chosen full XSD = syntax, with striking acceptance problems on the YANG side (CDDL users = seem to be more prudent here, in particular now with RFC 9165 available = for complex cases; CDDL also has a defined extension point for dropping = in multiple syntaxes). This experience strengthens my preference for a = LCD subset. >>=20 >> I understand that a world would be more likable where we could just = drop in REs from a common, well-understood usage. Unfortunately, we = don=E2=80=99t have this world. Making decisions based on wishful = thinking we did is not doing the right thing. >>=20 >> I also understand that my perspective may be somewhat different from = other WG members, as I have already spent a significant amount of time = researching the RE conundrum in different contexts. So I=E2=80=99m very = open to explaining this perspective in some more detail. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> = Virenfrei. = www.avg.com = =20 >> >=20 > --=20 > JSONpath mailing list > JSONpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath --Apple-Mail=_A67CC52A-C16C-47B4-A4AD-2A22901E64EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW:

I = agree, 2b makes the most sense.  There are, as Carsten points out, = other needs for a regexp for json, and I=E2=80=99m fine with starting = with the lregexp doc.

=E2=80=9CInterim Draft=E2=80=9D has no meaning in the IETF. =  We can process a draft that has a normative reference to another = draft,  That can take it all the way to the RFC Editor=E2=80=99s = queue.  It won=E2=80=99t be published until the referenced draft is = published.  That=E2=80=99s what we want to do here I think. =  

Brian

On Jan 3, 2022, at 10:56 AM, = Stefan G=C3=B6ssner <stefan@goessner.net> wrote:

=20 =20
Happy new year from me also to everyone.

I already committed to sympathise with Carsten's proposal 2b.

Yet I also strongly agree to Glyn's point of completing the JSONPath draft in a reasonable time frame.

So from Carsten's background of few decades of standards work experience, I would like to ask: how can we estimate the chance of finishing here at approximately the same time frame with both drafts?

If Iregexp presumably needs significantly more time for finishing, I favour the 'finalising an interim draft' approach according to proposal 1, with respect to the benefits Glyn has stated.

But I must confess, that I don't know, what an 'interim draft' exactly is and if 'extension points' are necessary then.

// =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I would like to also discuss filter-selectors regarding ...

* Comparisons are restricted to primitive =
values (such as number,
      string, true, false, null).  Comparisons with complex values will
      fail, i.e. no selection occurs.
There seems to be a majority consense to allow structured (complex ?) values with comparisons. We should discuss that technically and try to strive for agreement here.

Thanks
--
sg


Am 03.01.2022 um 16:16 schrieb Glyn Normington:
Thanks Carsten. I agree with = everything you wrote there.

I'm keen to complete the JSONPath = draft within a reasonable time frame and I fear that regexp support may = take quite a while to finalise. So I'd like us to consider finalising an *interim draft* without regexp support (i.e. option 1). Such a draft would be a useful checkpoint and holding position until iregexp is complete.

The other main benefit of = finalising such an interim draft would be to flush out any remaining changes that are needed in addition to regexp support.

An interim draft would also be = useful input toward a compliance test suite and reference implementation (assuming someone will find time to work on either or both of these!). The rest of the spec still being in flux is a disincentive to anyone investing in building a CTS and = RI.

On Mon, 3 Jan 2022, = 13:54 Carsten Bormann, <cabo@tzi.org> wrote:
On 2022-01-03, at 14:01, Glyn Normington <glyn.normington.work@gmail.com> wrote:
>
> https://github.com/ietf-wg-jsonpath/draft-= ietf-jsonpath-base/pull/143

Right.

I=E2=80=99ll continue the discussion here (instead of = github), as we need to make a (somewhat non-technical) WG decision.

We know that there is no easy way to generate a specification for a standard form of regular expressions (RE) (there is no such standard form).  Taking it = from there, options include:

(1) not having RE support in jsonpath-base
(2) defining a lowest-common-denominator syntax and including that in jsonpath-base
(3) having RE syntax but not defining what that means (=E2=80=9Cpermissive=E2=80=9D) and not providing a way to = identify which syntax variant is being used

Within (2), there are multiple suboptions. Editorially:

(a) define the LCD RE syntax and semantics in jsonpath-base
(b) define the syntax and semantics in a separate = document

(This is not a very important distinction, but a decision will have to be made.)

Note that we have to define both the RE syntax itself and the decoration that allows its use in jsonpath.

Within the selection process for those two, we=E2=80=99ll = have to make subdivisions, of which I happen to have at the front of my mind:
(i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style)
(ii) make the outermost syntax look like existing syntax, failing many instances that don=E2=80=99t happen to = presume the same syntax, but magically supporting some other instances that do happen to fit
(iii) use a regular expression subset that is actually based on regular expressions (Chomsky type 3 languages), or one that provides PCRE-style additions that don=E2=80=99t= allow DFA transformation (and thus efficient, attack-resistant implementation)

So much for laying out the decisions.

Here is my opinion, based on a few decades of trying to make standards work:

Clearly, I think 3 is not OK for interoperability.  1 = is OK by postponing the decision (as long as the extension point is announced); 2 is more =E2=80=9Cbatteries = included=E2=80=9D.

Within 2, I favor 2b.
With respect to the technical subdecisions:

(i):
A matching syntax is actually what is needed.
= Most programmers learn a parsing syntax first, because one use case for REs is writing shoddy parsers =E2=80=94 = something that we cannot use in JSONpath.
I wouldn=E2=80=99t mind making the decision for a matching = syntax highly visible, also because (ii):
We don=E2=80=99t want to make existing REs =E2=80=9Cjust = work=E2=80=9D, unless we can make sure that they are interoperable.

(iii):
I believe that actual RE-based syntaxes are a good subset decision anyway.  The only candidate here that is = actually standardized in XSD, but that has some unwanted baggage (character class subtraction =E2=80=94 which is great, but = not widely offered by other RE syntaxes our LCD would need to translate into).

There are further detail decisions, e.g., what does \d or \w actually mean; we might simplify our lives by using a LCD subset that poses as few questions of this kind as possible.

Iregexp is a proposal for a separate document (2b) that plays along these lines.
I think I would like to develop this proposal further towards the goal expressed in the previous paragraph.

JSONpath of course is not the only area of application for RE syntaxes inside the IETF.  Notably, YANG and CDDL = have chosen full XSD syntax, with striking acceptance problems on the YANG side (CDDL users seem to be more prudent here, in particular now with RFC 9165 available for complex cases; CDDL also has a defined extension point for dropping in multiple syntaxes).  This experience strengthens my preference for a LCD subset.

I understand that a world would be more likable where we could just drop in REs from a common, well-understood usage.  Unfortunately, we don=E2=80=99t have this = world. Making decisions based on wishful thinking we did is not doing the right thing.

I also understand that my perspective may be somewhat different from other WG members, as I have already spent a significant amount of time researching the RE conundrum in different contexts.  So I=E2=80=99m very open to = explaining this perspective in some more detail.

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


3D"" Virenfrei. www.avg.com


--
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

= --Apple-Mail=_A67CC52A-C16C-47B4-A4AD-2A22901E64EF-- From nobody Mon Jan 3 11:38:44 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3107E3A0ACD for ; Mon, 3 Jan 2022 11:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 0VMjxGtilZZS for ; Mon, 3 Jan 2022 11:38:38 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 3BBEC3A0ACE for ; Mon, 3 Jan 2022 11:38:38 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id h1so22293197pls.11 for ; Mon, 03 Jan 2022 11:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LuIHOBHsMBenvmHSYod9LwiGQNvWE2xbZ6v/4UxP0s8=; b=ErZrsZoQqZqlY3uvUbCAq6RNSa/+hbfMxHsP4eGY8HtqwknQl16qTC8URlJI3KQcgi ejUKDnOiifL1csWav11csnr2hiBcP41C2sGshRLcKLCRdMwAriTH/LFVtRukzt0fu58w Qtwc7yCMsJc8lF3WXOOK5LdBkc1PcNV9R3XsAXovPzyJkA9SIa8c1Xpl8l7Fw8g1J+ZE m3QomrLNE3eyCwJPQ6A+QnxS8wUoXTy3eJQVeh7MA1RSzbJ1GqRO+udu0EIzEWCLXTYv Oh5nDC4CNIEH1Ie49WntTtBijLQSdmIOMG2qUxP0ajy2eKcl1cKRhxjtfJkS8iUjPKK5 jrAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LuIHOBHsMBenvmHSYod9LwiGQNvWE2xbZ6v/4UxP0s8=; b=5LmmaXiw956dR38h31KG8QmERMbMlhVrb6X2YsgnwQM8jZZxge2V5k1de6FdG7icti L4lkZEjD/aOIsnHTcyFLRJOTu/unKj6WS/3fI7+wfpt1GECTH5bCN9CXQUEW4ekDDIy6 yEQCGMV19yNHfq/hAW/UwHqyVlpQ1qn0o2uLlts4URugMj/4fUhMBrk9k50OxERK8GCn ohdHYmdFreBswR7x8jbV2Ml1bp7aTIkazIuajjqOMo/uoXSc4TJqRqm2oiQBbGKtWXWb t1IZSqD2gUIJ++kZQRfG4ha8fCd4rGacJrAq/4v4tWu9wKJOZFgSW9E6/+ZOU0QeZu7L qZQQ== X-Gm-Message-State: AOAM532JFJ4NoU+TExJtLZndzoIqfyhhRP3oOfqZS2g3uQIWIEnV4Q9g aEE52yEa/TnFSgQ5SbEOydFpNcUJufzLDSWm0zdo2ize X-Google-Smtp-Source: ABdhPJyTmBWP199F+6aKwHiRtMyrqAWUduvUKu5m+ZdsmkvD5ZzBnoRUlt/dAl6X56brh/j06+lkfdQzmB6ODlVMqu4= X-Received: by 2002:a17:90a:e603:: with SMTP id j3mr1815042pjy.166.1641238716494; Mon, 03 Jan 2022 11:38:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Glyn Normington Date: Mon, 3 Jan 2022 19:38:25 +0000 Message-ID: To: Brian Rosen Cc: =?UTF-8?Q?Stefan_G=C3=B6ssner?= , Carsten Bormann , jsonpath@ietf.org, James G Content-Type: multipart/alternative; boundary="000000000000b0362b05d4b2aadd" Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 19:38:43 -0000 --000000000000b0362b05d4b2aadd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable By "interim draft" I meant just one of our usual drafts which the WG had agreed to stop developing, except perhaps for critical fixes, until iregexp was ready for consumption. I don't think it would be necessary to start turning such a draft into a RFC, unless there would be some advantage in doing so. On Mon, 3 Jan 2022, 19:14 Brian Rosen, wrote: > FWIW: > > I agree, 2b makes the most sense. There are, as Carsten points out, othe= r > needs for a regexp for json, and I=E2=80=99m fine with starting with the = lregexp > doc. > > =E2=80=9CInterim Draft=E2=80=9D has no meaning in the IETF. We can proce= ss a draft that > has a normative reference to another draft, That can take it all the way > to the RFC Editor=E2=80=99s queue. It won=E2=80=99t be published until t= he referenced > draft is published. That=E2=80=99s what we want to do here I think. > > Brian > > On Jan 3, 2022, at 10:56 AM, Stefan G=C3=B6ssner wr= ote: > > Happy new year from me also to everyone. > > I already committed to sympathise with Carsten's proposal 2b. > > Yet I also strongly agree to Glyn's point of completing the JSONPath draf= t > in a reasonable time frame. > > So from Carsten's background of few decades of standards work experience, > I would like to ask: how can we estimate the chance of finishing here at > approximately the same time frame with both drafts? > > If Iregexp presumably needs significantly more time for finishing, I > favour the 'finalising an interim draft' approach according to proposal 1= , > with respect to the benefits Glyn has stated. > > But I must confess, that I don't know, what an 'interim draft' exactly is > and if 'extension points' are necessary then. > > // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > I would like to also discuss filter-selectors regarding ... > > * Comparisons are restricted to primitive values (such as number, > string, true, false, null). Comparisons with complex values will > fail, i.e. no selection occurs. > > > There seems to be a majority consense to allow structured (complex ?) > values with comparisons. We should discuss that technically and try to > strive for agreement here. > > Thanks > -- > sg > > > Am 03.01.2022 um 16:16 schrieb Glyn Normington: > > Thanks Carsten. I agree with everything you wrote there. > > I'm keen to complete the JSONPath draft within a reasonable time frame an= d > I fear that regexp support may take quite a while to finalise. So I'd lik= e > us to consider finalising an *interim draft* without regexp support (i.e. > option 1). Such a draft would be a useful checkpoint and holding position > until iregexp is complete. > > The other main benefit of finalising such an interim draft would be to > flush out any remaining changes that are needed in addition to regexp > support. > > An interim draft would also be useful input toward a compliance test suit= e > and reference implementation (assuming someone will find time to work on > either or both of these!). The rest of the spec still being in flux is a > disincentive to anyone investing in building a CTS and RI. > > On Mon, 3 Jan 2022, 13:54 Carsten Bormann, wrote: > >> On 2022-01-03, at 14:01, Glyn Normington >> wrote: >> > >> > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 >> >> Right. >> >> I=E2=80=99ll continue the discussion here (instead of github), as we nee= d to make >> a (somewhat non-technical) WG decision. >> >> We know that there is no easy way to generate a specification for a >> standard form of regular expressions (RE) (there is no such standard >> form). Taking it from there, options include: >> >> (1) not having RE support in jsonpath-base >> (2) defining a lowest-common-denominator syntax and including that in >> jsonpath-base >> (3) having RE syntax but not defining what that means (=E2=80=9Cpermissi= ve=E2=80=9D) and >> not providing a way to identify which syntax variant is being used >> >> Within (2), there are multiple suboptions. Editorially: >> >> (a) define the LCD RE syntax and semantics in jsonpath-base >> (b) define the syntax and semantics in a separate document >> >> (This is not a very important distinction, but a decision will have to b= e >> made.) >> >> Note that we have to define both the RE syntax itself and the decoration >> that allows its use in jsonpath. >> >> Within the selection process for those two, we=E2=80=99ll have to make >> subdivisions, of which I happen to have at the front of my mind: >> (i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style) >> (ii) make the outermost syntax look like existing syntax, failing many >> instances that don=E2=80=99t happen to presume the same syntax, but magi= cally >> supporting some other instances that do happen to fit >> (iii) use a regular expression subset that is actually based on regular >> expressions (Chomsky type 3 languages), or one that provides PCRE-style >> additions that don=E2=80=99t allow DFA transformation (and thus efficien= t, >> attack-resistant implementation) >> >> So much for laying out the decisions. >> >> Here is my opinion, based on a few decades of trying to make standards >> work: >> >> Clearly, I think 3 is not OK for interoperability. 1 is OK by postponin= g >> the decision (as long as the extension point is announced); 2 is more >> =E2=80=9Cbatteries included=E2=80=9D. >> >> Within 2, I favor 2b. >> With respect to the technical subdecisions: >> >> (i): >> A matching syntax is actually what is needed. >> Most programmers learn a parsing syntax first, because one use case for >> REs is writing shoddy parsers =E2=80=94 something that we cannot use in = JSONpath. >> I wouldn=E2=80=99t mind making the decision for a matching syntax highly= visible, >> also because (ii): >> We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D, = unless we can make sure >> that they are interoperable. >> >> (iii): >> I believe that actual RE-based syntaxes are a good subset decision >> anyway. The only candidate here that is actually standardized in XSD, b= ut >> that has some unwanted baggage (character class subtraction =E2=80=94 wh= ich is >> great, but not widely offered by other RE syntaxes our LCD would need to >> translate into). >> >> There are further detail decisions, e.g., what does \d or \w actually >> mean; we might simplify our lives by using a LCD subset that poses as fe= w >> questions of this kind as possible. >> >> Iregexp is a proposal for a separate document (2b) that plays along thes= e >> lines. >> I think I would like to develop this proposal further towards the goal >> expressed in the previous paragraph. >> >> JSONpath of course is not the only area of application for RE syntaxes >> inside the IETF. Notably, YANG and CDDL have chosen full XSD syntax, wi= th >> striking acceptance problems on the YANG side (CDDL users seem to be mor= e >> prudent here, in particular now with RFC 9165 available for complex case= s; >> CDDL also has a defined extension point for dropping in multiple >> syntaxes). This experience strengthens my preference for a LCD subset. >> >> I understand that a world would be more likable where we could just drop >> in REs from a common, well-understood usage. Unfortunately, we don=E2= =80=99t have >> this world. Making decisions based on wishful thinking we did is not doi= ng >> the right thing. >> >> I also understand that my perspective may be somewhat different from >> other WG members, as I have already spent a significant amount of time >> researching the RE conundrum in different contexts. So I=E2=80=99m very= open to >> explaining this perspective in some more detail. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> > > Virenfrei. > www.avg.com > > > > -- > JSONpath mailing list > JSONpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > > > --000000000000b0362b05d4b2aadd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By "interim draft" I meant just one of our usua= l drafts which the WG had agreed to stop developing, except perhaps for cri= tical fixes, until iregexp was ready for consumption. I don't think it = would be necessary to start turning such a draft into a RFC, unless there w= ould be some advantage in doing so.

On Mon, 3 Jan 2022, 19:14 Brian Rosen, &= lt;br@brianrosen.net> wrote:
FWIW:

I agree, 2b makes the = most sense.=C2=A0 There are, as Carsten points out, other needs for a regex= p for json, and I=E2=80=99m fine with starting with the lregexp doc.
<= div>
=E2=80=9CInterim Draft=E2=80=9D has no meaning in the IE= TF.=C2=A0 We can process a draft that has a normative reference to another = draft, =C2=A0That can take it all the way to the RFC Editor=E2=80=99s queue= .=C2=A0 It won=E2=80=99t be published until the referenced draft is publish= ed.=C2=A0 That=E2=80=99s what we want to do here I think. =C2=A0
=
Brian

On J= an 3, 2022, at 10:56 AM, Stefan G=C3=B6ssner <stefan@goessner.net&g= t; wrote:

=20 =20 =20
Happy new year from me also to everyone.

I already committed to sympathise with Carsten's proposal 2b.
Yet I also strongly agree to Glyn's point of completing the JSONPath draft in a reasonable time frame.

So from Carsten's background of few decades of standards work experience, I would like to ask: how can we estimate the chance of finishing here at approximately the same time frame with both drafts?

If Iregexp presumably needs significantly more time for finishing, I favour the 'finalising an interim draft' appro= ach according to proposal 1, with respect to the benefits Glyn has stated.

But I must confess, that I don't know, what an 'interim dra= ft' exactly is and if 'extension points' are necessary then.
// =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I would like to also discuss filter-selectors regarding ...

* Comparisons are restricted to primitive values (such as number,
      string, true, false, null).  Comparisons with complex values will
      fail, i.e. no selection occurs.
There seems to be a majorit= y consense to allow structured (complex ?) values with comparisons. We should discuss that technically and try to strive for agreement here.

Thanks
--
sg


Am 03.01.2022 um 16:16 schrieb Glyn Normington:
Thanks Carsten. I agree with everything you wrote there.

I'm keen to complete the JSONPath draft withi= n a reasonable=C2=A0time frame and I fear that regexp support may tak= e quite a while to finalise. So I'd like us to consider finalising an *interim draft* without regexp support (i.e. option 1). Such a draft would be a useful checkpoint and holding position until iregexp is complete.

The other main benefit of finalising such an interim draft would be to flush out any remaining changes that are needed in addition to regexp support.

An interim draft would also be useful input toward a compliance test suite and reference implementation (assuming someone will find time to work on either or both of these!). The rest of the spec still being in flux is a disincentive to anyone investing in building a CTS and RI.

On Mon, 3 Jan 2022, 13:54 Carsten Bormann, <cabo@tzi.org> wrote:
On 2022-01-03, at 14:01, Glyn Normington <glyn.no= rmington.work@gmail.com> wrote:
>
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpat= h-base/pull/143

Right.

I=E2=80=99ll continue the discussion here (instead of github)= , as we need to make a (somewhat non-technical) WG decision.

We know that there is no easy way to generate a specification for a standard form of regular expressions (RE) (there is no such standard form).=C2=A0 Taking it from there, options include:

(1) not having RE support in jsonpath-base
(2) defining a lowest-common-denominator syntax and including that in jsonpath-base
(3) having RE syntax but not defining what that means (=E2=80=9Cpermissive=E2=80=9D) and not providing a way to ide= ntify which syntax variant is being used

Within (2), there are multiple suboptions. Editorially:

(a) define the LCD RE syntax and semantics in jsonpath-base
(b) define the syntax and semantics in a separate document
(This is not a very important distinction, but a decision will have to be made.)

Note that we have to define both the RE syntax itself and the decoration that allows its use in jsonpath.

Within the selection process for those two, we=E2=80=99ll hav= e to make subdivisions, of which I happen to have at the front of my mind:
(i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style)
(ii) make the outermost syntax look like existing syntax, failing many instances that don=E2=80=99t happen to presume t= he same syntax, but magically supporting some other instances that do happen to fit
(iii) use a regular expression subset that is actually based on regular expressions (Chomsky type 3 languages), or one that provides PCRE-style additions that don=E2=80=99t = allow DFA transformation (and thus efficient, attack-resistant implementation)

So much for laying out the decisions.

Here is my opinion, based on a few decades of trying to make standards work:

Clearly, I think 3 is not OK for interoperability.=C2=A0 1 is OK by postponing the decision (as long as the extension point is announced); 2 is more =E2=80=9Cbatteries included=E2= =80=9D.

Within 2, I favor 2b.
With respect to the technical subdecisions:

(i):
A matching syntax is actually what is needed.
Most programmers learn a parsing syntax first, because one use case for REs is writing shoddy parsers =E2=80=94 somethin= g that we cannot use in JSONpath.
I wouldn=E2=80=99t mind making the decision for a matching sy= ntax highly visible, also because (ii):
We don=E2=80=99t want to make existing REs =E2=80=9Cjust work= =E2=80=9D, unless we can make sure that they are interoperable.

(iii):
I believe that actual RE-based syntaxes are a good subset decision anyway.=C2=A0 The only candidate here that is actual= ly standardized in XSD, but that has some unwanted baggage (character class subtraction =E2=80=94 which is great, but no= t widely offered by other RE syntaxes our LCD would need to translate into).

There are further detail decisions, e.g., what does \d or \w actually mean; we might simplify our lives by using a LCD subset that poses as few questions of this kind as possible.

Iregexp is a proposal for a separate document (2b) that plays along these lines.
I think I would like to develop this proposal further towards the goal expressed in the previous paragraph.

JSONpath of course is not the only area of application for RE syntaxes inside the IETF.=C2=A0 Notably, YANG and CDDL hav= e chosen full XSD syntax, with striking acceptance problems on the YANG side (CDDL users seem to be more prudent here, in particular now with RFC 9165 available for complex cases; CDDL also has a defined extension point for dropping in multiple syntaxes).=C2=A0 This experience strengthens my preference for a LCD subset.

I understand that a world would be more likable where we could just drop in REs from a common, well-understood usage.=C2=A0 Unfortunately, we don=E2=80=99t have this world.= Making decisions based on wishful thinking we did is not doing the right thing.

I also understand that my perspective may be somewhat different from other WG members, as I have already spent a significant amount of time researching the RE conundrum in different contexts.=C2=A0 So I=E2=80=99m very open to explain= ing this perspective in some more detail.

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



--
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
=

--000000000000b0362b05d4b2aadd-- From nobody Mon Jan 3 12:28:26 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3801A3A0C1C for ; Mon, 3 Jan 2022 12:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=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=brianrosen-net.20210112.gappssmtp.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 rMTZ6iBO1pnP for ; Mon, 3 Jan 2022 12:28:20 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 4C64B3A0C1B for ; Mon, 3 Jan 2022 12:28:20 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id c4so20336405iln.7 for ; Mon, 03 Jan 2022 12:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ouo6U/rC9JbbzBGRwzNtqzFgUoUim+9TCCz3UI1Adxk=; b=w3HSRErh9HEriifwROx7Fgtzt8TjNHoRNxPQqTy+IpOwYvE1TVwdbpDewYnsM5nSii hQ0GTB7+TWKQ4UouEg4NzazD1q9gahhTmH0hES3QZyHC3da0rnJ6OM4RRkZ8vvsS2jpE AHGDziccDI3J1TFCnTYntZSY3xydgGm5NM5b1xBeAopyfBAfCMJQ2FlGI2WMMXbo9BGH buJRmE/ZXsj7Gdw+ZEkGjA0PJ4jznufNmZX8gHrx90IQ7hjHDCMBuKgjfQSo8hRVOQrK RYRSv8Z0yaeeY7ryz47twee+VCzXXRF8Lp85DZOlGg42+nmCTrnyc+P7j3fT2dRAQyhK kSQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ouo6U/rC9JbbzBGRwzNtqzFgUoUim+9TCCz3UI1Adxk=; b=gMr/9wtcjipHkxG3mZcFlTAK/stuDqlMpiyXAXsw2JJAosZb2LKAHtkEjkkXrqdNZn 4+5yVMFy8RNS+hUBmr696soFKFQY1pWR+j77E70YwYmgptvQGk6lKGT6XHp76oDeQC9l QVBO7XATbkid+rR2jROwhQbv0s5Zpp2jgFkcKSVH+nZfkOK8COFtBMUFT4W/laT7sqmF LWuwjFphCRvKBRAxcws1dzD+mmKWCsfd2ByNUuvLRsQyzNp8QiCeozTtIfVcGsFZdaSr VPUruSkB4bpPDpSFmYHjD+DjeZ6BhObHOogGBIFgg6mU1kD87MX6quba4Ubqkdn+dkXN 2aLQ== X-Gm-Message-State: AOAM530HBflzkxJ792uLpVOYvzCkXEiww6Zd1LyW195nOy1QCNRnhswb XPs/MihibItARhmkv5lQig4AYK1U92vbow0SAQkqeTFUIs7SOg== X-Google-Smtp-Source: ABdhPJy+rPyivEBT+kukXHGEeivaLYntr4JLjORxq9nbxqNASYYlcuq5USbt7c601tsdHJPT246TrGTHzGvQ6UhxqNc= X-Received: by 2002:a05:6e02:1be2:: with SMTP id y2mr20657053ilv.262.1641241698944; Mon, 03 Jan 2022 12:28:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Rosen Date: Mon, 3 Jan 2022 12:28:08 -0800 Message-ID: To: Glyn Normington Cc: Carsten Bormann , James G , =?UTF-8?Q?Stefan_G=C3=B6ssner?= , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000074dcb705d4b35c91" Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 20:28:25 -0000 --00000000000074dcb705d4b35c91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, I think pushing all the way through is a good idea. We get all the critical reviews from outside people who inevitably find those =E2=80=9Chow= did we miss that?=E2=80=9D things. Sometimes that slows down progress so starting = early is good. The only reason not to is if we think there will be dependencies other than the obvious. I don=E2=80=99t think that will be the case here. Brian On Mon, Jan 3, 2022 at 11:38 AM Glyn Normington < glyn.normington.work@gmail.com> wrote: > By "interim draft" I meant just one of our usual drafts which the WG had > agreed to stop developing, except perhaps for critical fixes, until irege= xp > was ready for consumption. I don't think it would be necessary to start > turning such a draft into a RFC, unless there would be some advantage in > doing so. > > On Mon, 3 Jan 2022, 19:14 Brian Rosen, wrote: > >> FWIW: >> >> I agree, 2b makes the most sense. There are, as Carsten points out, >> other needs for a regexp for json, and I=E2=80=99m fine with starting wi= th the >> lregexp doc. >> >> =E2=80=9CInterim Draft=E2=80=9D has no meaning in the IETF. We can proc= ess a draft that >> has a normative reference to another draft, That can take it all the wa= y >> to the RFC Editor=E2=80=99s queue. It won=E2=80=99t be published until = the referenced >> draft is published. That=E2=80=99s what we want to do here I think. >> >> Brian >> >> On Jan 3, 2022, at 10:56 AM, Stefan G=C3=B6ssner w= rote: >> >> Happy new year from me also to everyone. >> >> I already committed to sympathise with Carsten's proposal 2b. >> >> Yet I also strongly agree to Glyn's point of completing the JSONPath >> draft in a reasonable time frame. >> >> So from Carsten's background of few decades of standards work experience= , >> I would like to ask: how can we estimate the chance of finishing here at >> approximately the same time frame with both drafts? >> >> If Iregexp presumably needs significantly more time for finishing, I >> favour the 'finalising an interim draft' approach according to proposal = 1, >> with respect to the benefits Glyn has stated. >> >> But I must confess, that I don't know, what an 'interim draft' exactly i= s >> and if 'extension points' are necessary then. >> >> // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> I would like to also discuss filter-selectors regarding ... >> >> * Comparisons are restricted to primitive values (such as number, >> string, true, false, null). Comparisons with complex values will >> fail, i.e. no selection occurs. >> >> >> There seems to be a majority consense to allow structured (complex ?) >> values with comparisons. We should discuss that technically and try to >> strive for agreement here. >> >> Thanks >> -- >> sg >> >> >> Am 03.01.2022 um 16:16 schrieb Glyn Normington: >> >> Thanks Carsten. I agree with everything you wrote there. >> >> I'm keen to complete the JSONPath draft within a reasonable time frame >> and I fear that regexp support may take quite a while to finalise. So I'= d >> like us to consider finalising an *interim draft* without regexp support >> (i.e. option 1). Such a draft would be a useful checkpoint and holding >> position until iregexp is complete. >> >> The other main benefit of finalising such an interim draft would be to >> flush out any remaining changes that are needed in addition to regexp >> support. >> >> An interim draft would also be useful input toward a compliance test >> suite and reference implementation (assuming someone will find time to w= ork >> on either or both of these!). The rest of the spec still being in flux i= s a >> disincentive to anyone investing in building a CTS and RI. >> >> On Mon, 3 Jan 2022, 13:54 Carsten Bormann, wrote: >> >>> On 2022-01-03, at 14:01, Glyn Normington >>> wrote: >>> > >>> > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/143 >>> >>> Right. >>> >>> I=E2=80=99ll continue the discussion here (instead of github), as we ne= ed to >>> make a (somewhat non-technical) WG decision. >>> >>> We know that there is no easy way to generate a specification for a >>> standard form of regular expressions (RE) (there is no such standard >>> form). Taking it from there, options include: >>> >>> (1) not having RE support in jsonpath-base >>> (2) defining a lowest-common-denominator syntax and including that in >>> jsonpath-base >>> (3) having RE syntax but not defining what that means (=E2=80=9Cpermiss= ive=E2=80=9D) and >>> not providing a way to identify which syntax variant is being used >>> >>> Within (2), there are multiple suboptions. Editorially: >>> >>> (a) define the LCD RE syntax and semantics in jsonpath-base >>> (b) define the syntax and semantics in a separate document >>> >>> (This is not a very important distinction, but a decision will have to >>> be made.) >>> >>> Note that we have to define both the RE syntax itself and the decoratio= n >>> that allows its use in jsonpath. >>> >>> Within the selection process for those two, we=E2=80=99ll have to make >>> subdivisions, of which I happen to have at the front of my mind: >>> (i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style) >>> (ii) make the outermost syntax look like existing syntax, failing many >>> instances that don=E2=80=99t happen to presume the same syntax, but mag= ically >>> supporting some other instances that do happen to fit >>> (iii) use a regular expression subset that is actually based on regular >>> expressions (Chomsky type 3 languages), or one that provides PCRE-style >>> additions that don=E2=80=99t allow DFA transformation (and thus efficie= nt, >>> attack-resistant implementation) >>> >>> So much for laying out the decisions. >>> >>> Here is my opinion, based on a few decades of trying to make standards >>> work: >>> >>> Clearly, I think 3 is not OK for interoperability. 1 is OK by >>> postponing the decision (as long as the extension point is announced); = 2 is >>> more =E2=80=9Cbatteries included=E2=80=9D. >>> >>> Within 2, I favor 2b. >>> With respect to the technical subdecisions: >>> >>> (i): >>> A matching syntax is actually what is needed. >>> Most programmers learn a parsing syntax first, because one use case for >>> REs is writing shoddy parsers =E2=80=94 something that we cannot use in= JSONpath. >>> I wouldn=E2=80=99t mind making the decision for a matching syntax highl= y >>> visible, also because (ii): >>> We don=E2=80=99t want to make existing REs =E2=80=9Cjust work=E2=80=9D,= unless we can make sure >>> that they are interoperable. >>> >>> (iii): >>> I believe that actual RE-based syntaxes are a good subset decision >>> anyway. The only candidate here that is actually standardized in XSD, = but >>> that has some unwanted baggage (character class subtraction =E2=80=94 w= hich is >>> great, but not widely offered by other RE syntaxes our LCD would need t= o >>> translate into). >>> >>> There are further detail decisions, e.g., what does \d or \w actually >>> mean; we might simplify our lives by using a LCD subset that poses as f= ew >>> questions of this kind as possible. >>> >>> Iregexp is a proposal for a separate document (2b) that plays along >>> these lines. >>> I think I would like to develop this proposal further towards the goal >>> expressed in the previous paragraph. >>> >>> JSONpath of course is not the only area of application for RE syntaxes >>> inside the IETF. Notably, YANG and CDDL have chosen full XSD syntax, w= ith >>> striking acceptance problems on the YANG side (CDDL users seem to be mo= re >>> prudent here, in particular now with RFC 9165 available for complex cas= es; >>> CDDL also has a defined extension point for dropping in multiple >>> syntaxes). This experience strengthens my preference for a LCD subset. >>> >>> I understand that a world would be more likable where we could just dro= p >>> in REs from a common, well-understood usage. Unfortunately, we don=E2= =80=99t have >>> this world. Making decisions based on wishful thinking we did is not do= ing >>> the right thing. >>> >>> I also understand that my perspective may be somewhat different from >>> other WG members, as I have already spent a significant amount of time >>> researching the RE conundrum in different contexts. So I=E2=80=99m ver= y open to >>> explaining this perspective in some more detail. >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> >> >> Virenfrei. >> www.avg.com >> >> >> >> -- >> JSONpath mailing list >> JSONpath@ietf.org >> https://www.ietf.org/mailman/listinfo/jsonpath >> >> >> --00000000000074dcb705d4b35c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, I think pushing all the way through is a good idea.= =C2=A0 We get all the critical reviews from outside people who inevitably f= ind those =E2=80=9Chow did we miss that?=E2=80=9D things. Sometimes that sl= ows down progress so starting early is good. The only reason not to is if w= e think there will be dependencies other than the obvious. I don=E2=80=99t = think that will be the case here.=C2=A0

Brian

On Mon, Jan 3, 2022 at 11:38 AM Glyn Normington &= lt;glyn.normington.work@g= mail.com> wrote:
By "interim draft" I meant just one of our usual drafts wh= ich the WG had agreed to stop developing, except perhaps for critical fixes= , until iregexp was ready for consumption. I don't think it would be ne= cessary to start turning such a draft into a RFC, unless there would be som= e advantage in doing so.

On Mon, 3 Jan 2022, 19:14 Brian Rosen, <br@brianrosen.net> w= rote:
FWIW:

I agree, 2b ma= kes the most sense.=C2=A0 There are, as Carsten points out, other needs for= a regexp for json, and I=E2=80=99m fine with starting with the lregexp doc= .

=E2=80=9CInterim Draft=E2=80=9D has no meaning i= n the IETF.=C2=A0 We can process a draft that has a normative reference to = another draft, =C2=A0That can take it all the way to the RFC Editor=E2=80= =99s queue.=C2=A0 It won=E2=80=99t be published until the referenced draft = is published.=C2=A0 That=E2=80=99s what we want to do here I think. =C2=A0<= /div>

Brian

On Jan 3, 2022, at 10:56 AM, Stefan G=C3=B6ssner <stefan@goessner= .net> wrote:

=20 =20 =20
Happy new year from me also to everyone.

I already committed to sympathise with Carsten's proposal 2b.
Yet I also strongly agree to Glyn's point of completing the JSONPath draft in a reasonable time frame.

So from Carsten's background of few decades of standards work experience, I would like to ask: how can we estimate the chance of finishing here at approximately the same time frame with both drafts?

If Iregexp presumably needs significantly more time for finishing, I favour the 'finalising an interim draft' appro= ach according to proposal 1, with respect to the benefits Glyn has stated.

But I must confess, that I don't know, what an 'interim dra= ft' exactly is and if 'extension points' are necessary then.
// =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I would like to also discuss filter-selectors regarding ...

* Comparisons are restricted to primitive values (such as number,
      string, true, false, null).  Comparisons with complex values will
      fail, i.e. no selection occurs.
There seems to be a majorit= y consense to allow structured (complex ?) values with comparisons. We should discuss that technically and try to strive for agreement here.

Thanks
--
sg


Am 03.01.2022 um 16:16 schrieb Glyn Normington:
Thanks Carsten. I agree with everything you wrote there.

I'm keen to complete the JSONPath draft withi= n a reasonable=C2=A0time frame and I fear that regexp support may tak= e quite a while to finalise. So I'd like us to consider finalising an *interim draft* without regexp support (i.e. option 1). Such a draft would be a useful checkpoint and holding position until iregexp is complete.

The other main benefit of finalising such an interim draft would be to flush out any remaining changes that are needed in addition to regexp support.

An interim draft would also be useful input toward a compliance test suite and reference implementation (assuming someone will find time to work on either or both of these!). The rest of the spec still being in flux is a disincentive to anyone investing in building a CTS and RI.

On Mon, 3 Jan 2022, 13:54 Carsten Bormann, <cabo@tzi.org> wrote:
On 2022-01-03, at 14:01, Glyn Normington <glyn.no= rmington.work@gmail.com> wrote:
>
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpat= h-base/pull/143

Right.

I=E2=80=99ll continue the discussion here (instead of github)= , as we need to make a (somewhat non-technical) WG decision.

We know that there is no easy way to generate a specification for a standard form of regular expressions (RE) (there is no such standard form).=C2=A0 Taking it from there, options include:

(1) not having RE support in jsonpath-base
(2) defining a lowest-common-denominator syntax and including that in jsonpath-base
(3) having RE syntax but not defining what that means (=E2=80=9Cpermissive=E2=80=9D) and not providing a way to ide= ntify which syntax variant is being used

Within (2), there are multiple suboptions. Editorially:

(a) define the LCD RE syntax and semantics in jsonpath-base
(b) define the syntax and semantics in a separate document
(This is not a very important distinction, but a decision will have to be made.)

Note that we have to define both the RE syntax itself and the decoration that allows its use in jsonpath.

Within the selection process for those two, we=E2=80=99ll hav= e to make subdivisions, of which I happen to have at the front of my mind:
(i) use a matching syntax (XSD-style) or a parsing syntax (PCRE-style)
(ii) make the outermost syntax look like existing syntax, failing many instances that don=E2=80=99t happen to presume t= he same syntax, but magically supporting some other instances that do happen to fit
(iii) use a regular expression subset that is actually based on regular expressions (Chomsky type 3 languages), or one that provides PCRE-style additions that don=E2=80=99t = allow DFA transformation (and thus efficient, attack-resistant implementation)

So much for laying out the decisions.

Here is my opinion, based on a few decades of trying to make standards work:

Clearly, I think 3 is not OK for interoperability.=C2=A0 1 is OK by postponing the decision (as long as the extension point is announced); 2 is more =E2=80=9Cbatteries included=E2= =80=9D.

Within 2, I favor 2b.
With respect to the technical subdecisions:

(i):
A matching syntax is actually what is needed.
Most programmers learn a parsing syntax first, because one use case for REs is writing shoddy parsers =E2=80=94 somethin= g that we cannot use in JSONpath.
I wouldn=E2=80=99t mind making the decision for a matching sy= ntax highly visible, also because (ii):
We don=E2=80=99t want to make existing REs =E2=80=9Cjust work= =E2=80=9D, unless we can make sure that they are interoperable.

(iii):
I believe that actual RE-based syntaxes are a good subset decision anyway.=C2=A0 The only candidate here that is actual= ly standardized in XSD, but that has some unwanted baggage (character class subtraction =E2=80=94 which is great, but no= t widely offered by other RE syntaxes our LCD would need to translate into).

There are further detail decisions, e.g., what does \d or \w actually mean; we might simplify our lives by using a LCD subset that poses as few questions of this kind as possible.

Iregexp is a proposal for a separate document (2b) that plays along these lines.
I think I would like to develop this proposal further towards the goal expressed in the previous paragraph.

JSONpath of course is not the only area of application for RE syntaxes inside the IETF.=C2=A0 Notably, YANG and CDDL hav= e chosen full XSD syntax, with striking acceptance problems on the YANG side (CDDL users seem to be more prudent here, in particular now with RFC 9165 available for complex cases; CDDL also has a defined extension point for dropping in multiple syntaxes).=C2=A0 This experience strengthens my preference for a LCD subset.

I understand that a world would be more likable where we could just drop in REs from a common, well-understood usage.=C2=A0 Unfortunately, we don=E2=80=99t have this world.= Making decisions based on wishful thinking we did is not doing the right thing.

I also understand that my perspective may be somewhat different from other WG members, as I have already spent a significant amount of time researching the RE conundrum in different contexts.=C2=A0 So I=E2=80=99m very open to explain= ing this perspective in some more detail.

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


3D"" Virenfrei. www.avg.com<= /a>


--
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
=

--00000000000074dcb705d4b35c91-- From nobody Mon Jan 3 12:56:32 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251A23A0CAE for ; Mon, 3 Jan 2022 12:56:31 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtRiWxjcgSDI for ; Mon, 3 Jan 2022 12:56:28 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFFE3A0CAD for ; Mon, 3 Jan 2022 12:56:27 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JSShl0JLQzDCbg; Mon, 3 Jan 2022 21:56:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 Jan 2022 21:56:22 +0100 Cc: Brian Rosen , jsonpath@ietf.org, James G , =?utf-8?Q?Stefan_G=C3=B6ssner?= X-Mao-Original-Outgoing-Id: 662936182.63934-5de47582e177ac712332cf7ce8eb394d Content-Transfer-Encoding: quoted-printable Message-Id: <82838468-73AA-43A6-9608-DEAA4D6A8494@tzi.org> References: To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 20:56:31 -0000 Clearly, we want to push through with the rest of the document. We don=E2=80=99t need to decide now whether it=E2=80=99s 1 or 2b; we = still have a couple of weeks for that. So for now my question is: > On 2022-01-03, at 20:38, Glyn Normington = wrote: >=20 > until iregexp was ready for consumption What do we need to do to get there? Clearly, we want to get reviews, but before that: My main remaining question is whether we want to have the complexity = emanating from \d, \w, and friends. Taking this out creates a rather = universal and simple subset, but also takes away a little convenience in = constructs like (RFC 6991)=E2=80=A6 \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)? =E2=80=A6which under the often found ASCII-only understanding then = becomes=E2=80=A6 [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)? (Note that RFC 6991 is probably broken here: YANG uses XSD patterns, so = =E2=80=A6 =D9=A2=D9=A0=D9=A2=D9=A2-=D9=A0=D9=A1-=D9=A0=D9=A3T=D9=A2=D9=A1:=D9=A4=D9=A0= :=D9=A0=D9=A0 =E2=80=A6matches that pattern, as does... =E0=A7=A8=E0=A7=A6=E0=A7=A8=E0=A7=A8-=E0=A7=A6=E0=A7=A7-=E0=A7=A6=E0=A7=A9= T=E0=A7=A8=E0=A7=A7:=E0=A7=AA=E0=A7=A6:=E0=A7=A6=E0=A7=A6 =E2=80=A6 because XSD interprets \d as a shorthand for \p{Nd}, so the = pattern actually is: \p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}(\.\p{Nd}+)? ). We would be free to define \d as we want, at the possible cost of no = longer being a strict subset of XSD, or to simply leave out \d and its = friends. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 4 00:03:42 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAEE3A100B for ; Tue, 4 Jan 2022 00:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWfN81gEhjeC for ; Tue, 4 Jan 2022 00:03:35 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 2E5733A0BFC for ; Tue, 4 Jan 2022 00:03:33 -0800 (PST) Received: from [192.168.178.20] ([88.130.50.71]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MREqy-1mjfSw1eVw-00NBDU; Tue, 04 Jan 2022 09:03:22 +0100 Content-Type: multipart/alternative; boundary="------------HS5H0IS2cn2DH5N5j1EJu60v" Message-ID: Date: Tue, 4 Jan 2022 09:03:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: Carsten Bormann , Glyn Normington Cc: jsonpath@ietf.org, James G , Brian Rosen References: <82838468-73AA-43A6-9608-DEAA4D6A8494@tzi.org> From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= In-Reply-To: <82838468-73AA-43A6-9608-DEAA4D6A8494@tzi.org> X-Provags-ID: V03:K1:xhVPv7G85QsOy0CBa4X43p0H5wvA1EjA73imeuQlPv2ePFXZ3qn 4KwQHr0BxNZQVaAtLBcGPxhH4E+yPcuUArb+nqvCSKgBZ67CBSKQGTJmZX3vZaGGqGvvRl8 SNhUVz67Gd4E4uTmXYAuqpGwf7Ad3zAr+GgyvklNXPSqyHlqCefTKTjHnG9OwJ+eWnPHZG0 DuuwDFkBuhlIQHsONoikA== X-UI-Out-Filterresults: notjunk:1;V03:K0:dTcMxGh11ak=:SFSfPpIs4Qd+wTpnaIH6/Y Wcv/c00SU0hO9UI/OqMsh4KyhTjAsBOlVLOvLsadvjONVZB9ZoN7IcUQq5Am49pN7tnewsMOV z5iiL3TqtnB2lA5JYa31GKyKpUqtk6icwUWl2IYZhYRDr/T7gwxsDA8LlN1u05sJaPQJlvy7c SMdiI6p98pgpUkDfQTlaPiTX0JrrP12rVTF0SDw+fEL0tzN2+jynwQQjLwF54E7JRm6NOwD0n E/MeHvvyMF4y2H+0U71UFwj5+paqvPCOr2oeS9Lvbrj/lonG3cFaLkd2Yi2sv0c6om8JpyShm J/youxNKusWHBof9ZEWh13ag48/Kf4gr2WucVxDdiTAOZAY120Ef8cJudddAslN+s8YuPHpJ2 s2lm0uTM6TdMjNjZR1haD+ljHhac87yUlIZDvoRcrodsstU2LVLxPD/EpuZ23RfnegrbuEvSg YkoXpcUQsbxlsgZc3jeyNwtKKGouUsA31+1HvNHPRTf2CaGo1pCPORZJoxUQ2Eg8N0VJ5oYvC 4ix8UqfmMBtz2qT2TngVNXFHQWfcKbnheks66XFEKNUkfX8JZH1M2/C9OzTjze+oM/Y7Eq67P XwbDuO6uwpku6ze+JiDQm+hrFgNJYtQP9v80rpLhjceBMvJO6raGqVVnOkURE0OmZjQkNYobJ /DVBnRguC1/ybQSWCCckxePOQjfECKkoIIXVFVSqBg3jT6UcZfuEfnOiX+ifAAw8DRgs= Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 08:03:41 -0000 This is a multi-part message in MIME format. --------------HS5H0IS2cn2DH5N5j1EJu60v Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ... as a notorious minimalist I clearly vote here for the rather universal and simple subset without those convenient but problematic parts. Especially as it promises to be finished faster. Am 03.01.2022 um 21:56 schrieb Carsten Bormann: > Clearly, we want to push through with the rest of the document. > We don’t need to decide now whether it’s 1 or 2b; we still have a couple of weeks for that. > > So for now my question is: > >> On 2022-01-03, at 20:38, Glyn Normington wrote: >> >> until iregexp was ready for consumption > What do we need to do to get there? > > Clearly, we want to get reviews, but before that: > > My main remaining question is whether we want to have the complexity emanating from \d, \w, and friends. Taking this out creates a rather universal and simple subset, but also takes away a little convenience in constructs like (RFC 6991)… > > \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)? > > …which under the often found ASCII-only understanding then becomes… > > [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)? > > (Note that RFC 6991 is probably broken here: YANG uses XSD patterns, so … > > ٢٠٢٢-٠١-٠٣T٢١:٤٠:٠٠ > > …matches that pattern, as does... > > ২০২২-০১-০৩T২১:৪০:০০ > > … because XSD interprets \d as a shorthand for \p{Nd}, so the pattern actually is: > > \p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}(\.\p{Nd}+)? > > ). We would be free to define \d as we want, at the possible cost of no longer being a strict subset of XSD, or to simply leave out \d and its friends. > > Grüße, Carsten > --------------HS5H0IS2cn2DH5N5j1EJu60v Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ... as a notorious minimalist I clearly vote here for the rather universal and simple subset without those convenient but problematic parts. Especially as it promises to be finished faster.


Am 03.01.2022 um 21:56 schrieb Carsten Bormann:
Clearly, we want to push through with the rest of the document.
We don’t need to decide now whether it’s 1 or 2b; we still have a couple of weeks for that.

So for now my question is:


On 2022-01-03, at 20:38, Glyn Normington <glyn.normington.work@gmail.com> wrote:

until iregexp was ready for consumption

What do we need to do to get there?

Clearly, we want to get reviews, but before that:

My main remaining question is whether we want to have the complexity emanating from \d, \w, and friends.  Taking this out creates a rather universal and simple subset, but also takes away a little convenience in constructs like (RFC 6991)…

\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?

…which under the often found ASCII-only understanding then becomes…

[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?

(Note that RFC 6991 is probably broken here:  YANG uses XSD patterns, so …

٢٠٢٢-٠١-٠٣T٢١:٤٠:٠٠

…matches that pattern, as does...

২০২২-০১-০৩T২১:৪০:০০

… because XSD interprets \d as a shorthand for \p{Nd}, so the pattern actually is:

\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}(\.\p{Nd}+)?

).  We would be free to define \d as we want, at the possible cost of no longer being a strict subset of XSD, or to simply leave out \d and its friends.

Grüße, Carsten

--------------HS5H0IS2cn2DH5N5j1EJu60v-- From nobody Tue Jan 4 00:47:04 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884093A195B for ; Tue, 4 Jan 2022 00:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF50vuojXZyc for ; Tue, 4 Jan 2022 00:46:58 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 40D713A1960 for ; Tue, 4 Jan 2022 00:46:58 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id j13so26641557plx.4 for ; Tue, 04 Jan 2022 00:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gm5i3MkDiF1c+jXhcAjSCK3Pyp29757iAQSkJEmJRK4=; b=gfS955h+9VhZXB6vxLn/J44FyeQPqZSf09PUi3nR+fvcip/CWvjCJU0HI75Lg25ki+ Q46r+gCpcEZKBnruPPIa9IfqlZRREB2Wq/3PKfvfUKa12w0c04DbVji3MNyceD/LfsLr U602WHw5khD86xNLLscGvZE+rtZT1tUSzBJNqNwTYZiWllHDh4p5MMa+0FGeOdDv50sr wDzPpfHzrau7I92hjrkPUfcfxP1oEXrMnoy3S/Cz8air3KmpEtqHLK+2Yo/3R/Cv3Fhi s4MCi6m3gTofbDkW67nbbbe2ZeLEDJ8sdVt+RBbHttUcCVE0D5b83yOwOmBrS9LDYqWO sxwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gm5i3MkDiF1c+jXhcAjSCK3Pyp29757iAQSkJEmJRK4=; b=8M1naa59GzyDQ3PyMg7yuxCqO6drQIR5qzFIQUL/fax+te6Ba/Jwir5dZa4jc4miGB Y1c5oG2N+Uo5LauPnlBo9AJYODiALwc05Qey5FBmdpFD0QjGjMjk0VUAuAfoBAODYZK7 HT2eIJIUFmtJCmDOD4GQ3OW3BISVJo5QLSE01RcWnjEkvm6AGtQiRHaDydD5w4kryiUA R2Aet8dqc9/a2e+neTuh04HhSYv94eW4KpM+8L6P3+wry8HeyKEANA2v1zSb9iINeSOJ /NGZSNrawGSSmbRxlhudZFti0nlK9eRSg/kVFJ9JIyJ4BkPPkmCNfOW/6FWT0akt3UPV 8XXA== X-Gm-Message-State: AOAM531+iUpVKvWX9coNmb0huC9R5V5k5k57E5cWic5EUEAwGHXjpszv Lwr/FF6jeeF2+2tduEjL9rtqWEg/fsQW/WQI/aU= X-Google-Smtp-Source: ABdhPJx3ZeZHgdx2Yr0F4tgjnbORKDEG2Rly4GAJCW5tKbAoTYFv8luJVZfxlcbSOadRePqWkAiYnzR2/cFi754fSHg= X-Received: by 2002:a17:902:db02:b0:149:4600:babc with SMTP id m2-20020a170902db0200b001494600babcmr48924181plx.2.1641286016804; Tue, 04 Jan 2022 00:46:56 -0800 (PST) MIME-Version: 1.0 References: <82838468-73AA-43A6-9608-DEAA4D6A8494@tzi.org> In-Reply-To: From: Glyn Normington Date: Tue, 4 Jan 2022 08:46:45 +0000 Message-ID: To: =?UTF-8?Q?Stefan_G=C3=B6ssner?= Cc: Carsten Bormann , jsonpath@ietf.org, James G , Brian Rosen Content-Type: multipart/alternative; boundary="00000000000001acaa05d4bdae1b" Archived-At: Subject: Re: [Jsonpath] Regexp options (Re: January 2022 interim meeting and agenda) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 08:47:03 -0000 --00000000000001acaa05d4bdae1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd be happy with that, but I suspect agreeing on a simple subset could take a while (unless it's the empty set ;-) ). On Tue, 4 Jan 2022 at 08:03, Stefan G=C3=B6ssner wrot= e: > ... as a notorious minimalist I clearly vote here for the rather universa= l > and simple subset without those convenient but problematic parts. > Especially as it promises to be finished faster. > > > Am 03.01.2022 um 21:56 schrieb Carsten Bormann: > > Clearly, we want to push through with the rest of the document. > We don=E2=80=99t need to decide now whether it=E2=80=99s 1 or 2b; we stil= l have a couple of weeks for that. > > So for now my question is: > > > On 2022-01-03, at 20:38, Glyn Normington = wrote: > > until iregexp was ready for consumption > > What do we need to do to get there? > > Clearly, we want to get reviews, but before that: > > My main remaining question is whether we want to have the complexity eman= ating from \d, \w, and friends. Taking this out creates a rather universal= and simple subset, but also takes away a little convenience in constructs = like (RFC 6991)=E2=80=A6 > > \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)? > > =E2=80=A6which under the often found ASCII-only understanding then become= s=E2=80=A6 > > [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)? > > (Note that RFC 6991 is probably broken here: YANG uses XSD patterns, so = =E2=80=A6 > > =D9=A2=D9=A0=D9=A2=D9=A2-=D9=A0=D9=A1-=D9=A0=D9=A3T=D9=A2=D9=A1:=D9=A4=D9= =A0:=D9=A0=D9=A0 > > =E2=80=A6matches that pattern, as does... > > =E0=A7=A8=E0=A7=A6=E0=A7=A8=E0=A7=A8-=E0=A7=A6=E0=A7=A7-=E0=A7=A6=E0=A7= =A9T=E0=A7=A8=E0=A7=A7:=E0=A7=AA=E0=A7=A6:=E0=A7=A6=E0=A7=A6 > > =E2=80=A6 because XSD interprets \d as a shorthand for \p{Nd}, so the pat= tern actually is: > > \p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}(\.\p{Nd}+)? > > ). We would be free to define \d as we want, at the possible cost of no = longer being a strict subset of XSD, or to simply leave out \d and its frie= nds. > > Gr=C3=BC=C3=9Fe, Carsten > > > > --00000000000001acaa05d4bdae1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd be happy with that, but I suspect agreeing on a si= mple subset could take a while (unless it's the empty set ;-) ).

On = Tue, 4 Jan 2022 at 08:03, Stefan G=C3=B6ssner <stefan@goessner.net> wrote:
=20 =20 =20
... as a notorious minimalist I clearly vote here for the rather universal and simple subset without those convenient but problematic parts. Especially as it promises to be finished faster.


Am 03.01.2022 um 21:56 schrieb Carsten Bormann:
Clearly, we want to push through with the rest of the document.
We don=E2=80=99t need to decide now whether it=E2=80=99s 1 or 2b; we still =
have a couple of weeks for that.

So for now my question is:


On 2022-01-03, at 20:38, Glyn Normington <glyn.normington.work@gma=
il.com> wrote:

until iregexp was ready for consumption

What do we need to do to get there?

Clearly, we want to get reviews, but before that:

My main remaining question is whether we want to have the complexity emanat=
ing from \d, \w, and friends.  Taking this out creates a rather universal a=
nd simple subset, but also takes away a little convenience in constructs li=
ke (RFC 6991)=E2=80=A6

\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?

=E2=80=A6which under the often found ASCII-only understanding then becomes=
=E2=80=A6

[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?

(Note that RFC 6991 is probably broken here:  YANG uses XSD patterns, so =
=E2=80=A6

=D9=A2=D9=A0=D9=A2=D9=A2-=D9=A0=D9=A1-=D9=A0=D9=A3T=D9=A2=D9=A1:=D9=A4=D9=
=A0:=D9=A0=D9=A0

=E2=80=A6matches that pattern, as does...

=E0=A7=A8=E0=A7=A6=E0=A7=A8=E0=A7=A8-=E0=A7=A6=E0=A7=A7-=E0=A7=A6=E0=A7=A9T=
=E0=A7=A8=E0=A7=A7:=E0=A7=AA=E0=A7=A6:=E0=A7=A6=E0=A7=A6

=E2=80=A6 because XSD interprets \d as a shorthand for \p{Nd}, so the patte=
rn actually is:

\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}(\.\p{Nd}+)?

).  We would be free to define \d as we want, at the possible cost of no lo=
nger being a strict subset of XSD, or to simply leave out \d and its friend=
s.

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

--00000000000001acaa05d4bdae1b-- From nobody Sun Jan 16 14:01:25 2022 Return-Path: X-Original-To: jsonpath@ietf.org Delivered-To: jsonpath@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 265D03A11FE; Sun, 16 Jan 2022 14:01:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jsonpath@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jsonpath@ietf.org Message-ID: <164237047710.30969.10996415256306738161@ietfa.amsl.com> Date: Sun, 16 Jan 2022 14:01:17 -0800 Archived-At: Subject: [Jsonpath] I-D Action: draft-ietf-jsonpath-base-03.txt X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2022 22:01:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Path WG of the IETF. Title : JSONPath: Query expressions for JSON Authors : Stefan Gössner Glyn Normington Carsten Bormann Filename : draft-ietf-jsonpath-base-03.txt Pages : 31 Date : 2022-01-16 Abstract: JSONPath defines a string syntax for selecting and extracting values within a JavaScript Object Notation (JSON, RFC 8259) value. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Jan 16 14:05:04 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6DF3A1223 for ; Sun, 16 Jan 2022 14:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqt-ZbObpjIA for ; Sun, 16 Jan 2022 14:04:59 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F953A1224 for ; Sun, 16 Jan 2022 14:04:58 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JcTbq6MyWzDCc5; Sun, 16 Jan 2022 23:04:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <164237047710.30969.10996415256306738161@ietfa.amsl.com> Date: Sun, 16 Jan 2022 23:04:55 +0100 X-Mao-Original-Outgoing-Id: 664063495.3531311-bd1e9bbff4e4285de0e673f51465ce94 Content-Transfer-Encoding: quoted-printable Message-Id: <5CC7556E-3ED5-4485-8445-5F3C3A1CAAA4@tzi.org> References: <164237047710.30969.10996415256306738161@ietfa.amsl.com> To: jsonpath@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Jsonpath] I-D Action: draft-ietf-jsonpath-base-03.txt X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2022 22:05:03 -0000 -03 consolidates all the changes we have had since -02, which was about = 2.5 months ago, so it has been overdue for a while. -03 is intended as = the document to look at for and at the 2022-01-18 JSONPath interim. Gr=C3=BC=C3=9Fe, Carsten > On 2022-01-16, at 23:01, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the JSON Path WG of the IETF. >=20 > Title : JSONPath: Query expressions for JSON > Authors : Stefan G=C3=B6ssner > Glyn Normington > Carsten Bormann > Filename : draft-ietf-jsonpath-base-03.txt > Pages : 31 > Date : 2022-01-16 >=20 > Abstract: > JSONPath defines a string syntax for selecting and extracting values > within a JavaScript Object Notation (JSON, RFC 8259) value. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jsonpath-base-03 >=20 >=20 > Internet-Drafts are also available by rsync at = rsync.ietf.org::internet-drafts >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jan 17 05:10:23 2022 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4C3A1289 for ; Mon, 17 Jan 2022 05:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmfTaI1NlWog for ; Mon, 17 Jan 2022 05:10:19 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (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 B3CBE3A12AC for ; Mon, 17 Jan 2022 05:10:18 -0800 (PST) Received: from [192.168.178.20] ([88.130.50.242]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M3UdI-1n9zjp1mU6-000YLX for ; Mon, 17 Jan 2022 14:10:15 +0100 Content-Type: multipart/alternative; boundary="------------BRB0fnmCxUjbyqh31F5DIXpJ" Message-ID: <52c37a44-9f81-bf84-ce4e-0a7b60cddd1a@goessner.net> Date: Mon, 17 Jan 2022 14:10:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: jsonpath@ietf.org References: <164237047710.30969.10996415256306738161@ietfa.amsl.com> <5CC7556E-3ED5-4485-8445-5F3C3A1CAAA4@tzi.org> From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= In-Reply-To: <5CC7556E-3ED5-4485-8445-5F3C3A1CAAA4@tzi.org> X-Provags-ID: V03:K1:Cp4WQFJEVU9dIqZyzNeLUvYsv7z1egnbbOtOxKyFV1Pkp+Em8O4 VQla+p2pHiM/tZgI0vdX4AWjNpGl/CzwpSomcS7qg6A+FqgHTBZymrP1PhzvemJ4Sg1VsVr O5g+7aXjxZD6yG0af+VTStvy0yhS6H49xCZqS9JFk6QuTHSZEtZnu5MwpklrPTdsN1dC/TA xnCWQr8fSGnFXMwtTJxGA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Cml/wqB57+4=:rRl/9FW3YhFMjX2b9dhd/X eeXm53b9BaP/g9Lh8LkdHLm83LL2B3YnT/+hYNvij16E0B0e1EjFTW1XBv/Uz1TfJTwaEOfJK fpovVV4IFJSb4HR08cSuSkbSUxdoxU41IBA2UJy1vi5MAA+qXVLCYHKVwcyXXadTBApk/sUZu xtFl/lOrijbtMLkq4zw2SIOAT/vGi5CVYmU8hj4aeq6OtPCBI9hAyAxamG3cZAHvzDaAtaW3e aB+15uiHU+n70zZ6SYuxvLXTauMiHLZyFu6NjVjuCTAYIkHd2xZQpSjAUCmscb1Lq1xE9ud0r 8z9d+RXspxG+XSDzLbke14oOiUAKBM5Bs86e5ztUoBOW+1Rtdl+CBdlsD5kb83a/dhHBvi1X9 yM5E6sJD7j0MrudaYazLqYJr0HDa+AGbfcW2b2yxhWbc10Z3hxCbsbPye6uMGA9P1BYlK8fAm 5j23q6EBGba1yIsjrykrMW6o1NEPs+X8l5pOT3o0h0h+A+ChOm8QcNsse95lD8UZNnMr/SI2J 6N7qfzmkG43zRCzcoSo0lEXOQrLrL3n9sRid7eauMazRS3Q2EULmoIfU+7ad4wON+/D8Uoxtv 8qBo7mBH+ZAyHCPcDuXxu5s5slES/EV1qb7XYSeaiZxdkmyEmkkWmE7W2Wn/3hVoxxIEdyl2x XBlw3sFW7qvVzo4RYbBXzJEb1YK9b6FpMTDoL/UUJeLFFJC52Lq3SYaNY1+/kAC+KghQ= Archived-At: Subject: Re: [Jsonpath] I-D Action: draft-ietf-jsonpath-base-03.txt X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 13:10:22 -0000 This is a multi-part message in MIME format. --------------BRB0fnmCxUjbyqh31F5DIXpJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ... I did some work on ABNF texts. Especially I tried to get equality comparisons of structured values right. -- sg Am 16.01.2022 um 23:04 schrieb Carsten Bormann: > -03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while. -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim. > > Grüße, Carsten > > >> On 2022-01-16, at 23:01,internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the JSON Path WG of the IETF. >> >> Title : JSONPath: Query expressions for JSON >> Authors : Stefan Gössner >> Glyn Normington >> Carsten Bormann >> Filename : draft-ietf-jsonpath-base-03.txt >> Pages : 31 >> Date : 2022-01-16 >> >> Abstract: >> JSONPath defines a string syntax for selecting and extracting values >> within a JavaScript Object Notation (JSON, RFC 8259) value. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03 >> >> >> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories:http://www.ietf.org/shadow.html >> orftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------BRB0fnmCxUjbyqh31F5DIXpJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ... I did some work on ABNF texts. Especially I tried to get equality comparisons of structured values right.
--
sg


Am 16.01.2022 um 23:04 schrieb Carsten Bormann:
-03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while.  -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim.

Grüße, Carsten



On 2022-01-16, at 23:01, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Path WG of the IETF.

       Title           : JSONPath: Query expressions for JSON
       Authors         : Stefan Gössner
                         Glyn Normington
                         Carsten Bormann
	Filename        : draft-ietf-jsonpath-base-03.txt
	Pages           : 31
	Date            : 2022-01-16

Abstract:
  JSONPath defines a string syntax for selecting and extracting values
  within a JavaScript Object Notation (JSON, RFC 8259) value.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


    

    

  


--------------BRB0fnmCxUjbyqh31F5DIXpJ--


From nobody Mon Jan 17 05:11:06 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296C3A1297 for ; Mon, 17 Jan 2022 05:11:04 -0800 (PST)
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, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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 3vXMShRpVRns for ; Mon, 17 Jan 2022 05:10:59 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 0B8843A1292 for ; Mon, 17 Jan 2022 05:10:58 -0800 (PST)
Received: from [192.168.178.20] ([88.130.50.242]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MMFdY-1mrEPe27Xy-00JMKw for ; Mon, 17 Jan 2022 14:10:56 +0100
Content-Type: multipart/alternative; boundary="------------kdA5TK2F0pc3qsEFZmOCr9Nr"
Message-ID: <7ed14d84-c4ee-55bd-4fc4-83e4363c44cc@goessner.net>
Date: Mon, 17 Jan 2022 14:10:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
To: jsonpath@ietf.org
References: <164237047710.30969.10996415256306738161@ietfa.amsl.com> <5CC7556E-3ED5-4485-8445-5F3C3A1CAAA4@tzi.org> <52c37a44-9f81-bf84-ce4e-0a7b60cddd1a@goessner.net>
From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= 
In-Reply-To: <52c37a44-9f81-bf84-ce4e-0a7b60cddd1a@goessner.net>
X-Provags-ID: V03:K1:Ov68GnYCPrHKI3zVRPvgNFm4Onc9guJHIzpJBZG7IX52ncILpJA uB0M2NE6ZqOV0Bq2dPBu4KkzEK6c8IeiJOjYXANQjfxM64wxGERgH45ZFB87ojVIRXj0fj6 23evF0CikOnGh9stdJUDL4kg4LX/DLuAsi9W3+PEErmuoMYGw2keRtVD2EzkxKHogtHbYSR qw+xM/juvZwzJFASYdcvw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vqIX1vNlUro=:dPeaBfFwox6j8+6seW6LjY JeV5dN9LB7rrECNLrwpvjQ0ZhaTID0j3Y1s4IUeGkqOTmXwQqDET73EFExaqoZ4GmGNEHjaql kNavtFTW3goEKQ7aC2UV3JqqQdTVM+GTofRtFznPyQjGKt0XRh+sDFrjC/Nc+BClWu3AL3Fnm j4DoUTgKUN7BTC0J6WGkaMMMuwutsvLfN+JiKakmqa1yOvgIJBPc90G1siS71dvTt8n78K1cZ qqsPhu1W1zbWIRk0J2bvMPwOxM4wzx+qmJKKfYFbU+7jOADqNfHlHYVMy5cJkUxFxFQtoloDu MNJYz01GWShG0L3+/lFdEmbhrN5iDBJlWrFfj5quelk19uH1l1J38xT1hofMO9qlbAlQzm/7I U3STYAuj3X4l2+Inw40Ne9gn+Xj0Mq903JtX6PZa9qlbNWQX1CF2HdQV02WabPJjsBDRVJuwU I6kkuTINItLvr+4LnyO3Ktm9IV0n3cpjt7LH/Arkjl1WP+wE46vGVsll4SooALfoIOZiNkwvO E1aeeKqGb++9iZB6qLaGWIj3X24iczbfc/wo8xkG0kz6YnriPJl0j3vTn0n8P9ZTqSjAOyeIi Xdm+/2UDtn3b1xvRTdTm/oQLRxTuSz4Ym8sloSUGi+fbaRmScaYdWJwUblLREvBkqC3+9PRIk IGKkANudi557h06o3jMyjrOPsn8oWOlgpXfSi5VNPX3aj8N4f9iNTzYuNXpAv3LvC8cM=
Archived-At: 
Subject: Re: [Jsonpath] I-D Action: draft-ietf-jsonpath-base-03.txt
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jan 2022 13:11:04 -0000

This is a multi-part message in MIME format.
--------------kdA5TK2F0pc3qsEFZmOCr9Nr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

pull request is here ...

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/compare/main...goessner:main

Am 17.01.2022 um 14:10 schrieb Stefan Gössner:
> ... I did some work on ABNF texts. Especially I tried to get equality 
> comparisons of structured values right.
> --
> sg
>
>
> Am 16.01.2022 um 23:04 schrieb Carsten Bormann:
>> -03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while.  -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim.
>>
>> Grüße, Carsten
>>
>>
>>> On 2022-01-16, at 23:01,internet-drafts@ietf.org  wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the JSON Path WG of the IETF.
>>>
>>>         Title           : JSONPath: Query expressions for JSON
>>>         Authors         : Stefan Gössner
>>>                           Glyn Normington
>>>                           Carsten Bormann
>>> 	Filename        : draft-ietf-jsonpath-base-03.txt
>>> 	Pages           : 31
>>> 	Date            : 2022-01-16
>>>
>>> Abstract:
>>>    JSONPath defines a string syntax for selecting and extracting values
>>>    within a JavaScript Object Notation (JSON, RFC 8259) value.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03
>>>
>>>
>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories:http://www.ietf.org/shadow.html
>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>  
> 	Virenfrei. www.avg.com 
>  
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

--------------kdA5TK2F0pc3qsEFZmOCr9Nr
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    pull request is here ...

        

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/compare/main...goessner:main

      

    
Am 17.01.2022 um 14:10 schrieb Stefan
      Gössner:

    

    

      
      ... I did some work on
          ABNF texts. Especially I tried to get equality comparisons of
          structured values right.

          --

          sg

          

        

      
Am 16.01.2022 um 23:04 schrieb
        Carsten Bormann:

      

      

        
-03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while.  -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim.

Grüße, Carsten




        

          
On 2022-01-16, at 23:01, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Path WG of the IETF.

       Title           : JSONPath: Query expressions for JSON
       Authors         : Stefan Gössner
                         Glyn Normington
                         Carsten Bormann
	Filename        : draft-ietf-jsonpath-base-03.txt
	Pages           : 31
	Date            : 2022-01-16

Abstract:
  JSONPath defines a string syntax for selecting and extracting values
  within a JavaScript Object Notation (JSON, RFC 8259) value.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


        

      

      

      


        

          
            

              
              Virenfrei. www.avg.com 
            

          
        

         

      

      

    

    

  


--------------kdA5TK2F0pc3qsEFZmOCr9Nr--


From nobody Mon Jan 17 05:14:33 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7413A12C2 for ; Mon, 17 Jan 2022 05:14:31 -0800 (PST)
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, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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 OIWD9uxCaYId for ; Mon, 17 Jan 2022 05:14:27 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 76F6D3A12BF for ; Mon, 17 Jan 2022 05:14:26 -0800 (PST)
Received: from [192.168.178.20] ([88.130.50.242]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MfHxt-1mhGcl2zBD-00goyL for ; Mon, 17 Jan 2022 14:14:24 +0100
Content-Type: multipart/alternative; boundary="------------p8miKNXSPEqeNdOPlrhu5yAR"
Message-ID: 
Date: Mon, 17 Jan 2022 14:14:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
To: jsonpath@ietf.org
References: <164237047710.30969.10996415256306738161@ietfa.amsl.com> <5CC7556E-3ED5-4485-8445-5F3C3A1CAAA4@tzi.org> <52c37a44-9f81-bf84-ce4e-0a7b60cddd1a@goessner.net> <7ed14d84-c4ee-55bd-4fc4-83e4363c44cc@goessner.net>
From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= 
In-Reply-To: <7ed14d84-c4ee-55bd-4fc4-83e4363c44cc@goessner.net>
X-Provags-ID: V03:K1:UZpvXnaXJOirIHBeERRK3V6Du0wdMBQvBjXo6DbZ65tcenPb/GE 4mhGLP1kw/HgX9Q02+cL9EnVyxlKg3kr43Ir/vYEtlFd8EvJjI6M4iLSZMQefwbST74rTVF aObAp5w85SQIZKaa/GLRevYOizRLTPs3NUbd59WnFrgHS+jIajcJyVo3rFe1NlegC9oq4Dn Vfm8XlKeeIXiCSy6NWADA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2fAItjri0oM=:7EkpjXRyZKgygcUOFcXXqL MZAn9WhxaZ6zwe9+ouTbTsSjneSeX6+E1G+Z9tep6Sbc+cRZxvFKJFaqcKnlVwKEosBCIzeg3 eyEsDyfFPwnVccQqLs/AO6xenHYD4A8Yx4MDqn6T5j8FOcFUSvSJi+zpyB9CVy8iXFfdCLfib UCMzYUZxgw/sJaQkseEPC8Di2YPYXykMqvzFeczGFAXmgCvuCxAt9sYHNmadMAKe8K5iWBoJp yaWMuP0PszeN74UbXiNwVI+vNGuopL8Sqfmwl5aKjkkEtYEJVR04LCCTxAd9ixLh9/D5S0zEN axUjcFeI6DYPf8GQy0921h8wnNnw5EQqlH00FeuZuFLUdx9+DkLNm7eLst4TMTzvn+V+5vqnF Ux/Wmu5I18xCB6KhzTjP+4+nySHJ2kn5bbMRhe72ujqT02X/d1zg5odIVd27gDZin36vomDx9 A/CVHk5XDSX4m5iR6Sm/N2Ly9DP6KOzAUV0diIfn2VWHThNNZ59/XgEuPXv0Grb7SqpjiwbyJ satOQuIUO01ri2VYIW71BB9bG3KrVcnRkfc7192KMUkC4GZTK7fvbyraBAvvbMzmcKGUZdB+z 6ecjrjoVtSntG/Tm0gAU8Qjt8+8nbNOimvucF5NNc2MgGhfAfHPWiOIcniKyR+OuL4VIkRqtY O70HzCMrfoMl002RCMjvAYLNjY3YgfGSBhqM5GAVoCH30nE1M55AEG5zD8f8Ve910zCs=
Archived-At: 
Subject: Re: [Jsonpath] I-D Action: draft-ietf-jsonpath-base-03.txt
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jan 2022 13:14:31 -0000

This is a multi-part message in MIME format.
--------------p8miKNXSPEqeNdOPlrhu5yAR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

hmm ... here

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/145

Am 17.01.2022 um 14:10 schrieb Stefan Gössner:
> pull request is here ...
>
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/compare/main...goessner:main
>
> Am 17.01.2022 um 14:10 schrieb Stefan Gössner:
>> ... I did some work on ABNF texts. Especially I tried to get equality 
>> comparisons of structured values right.
>> --
>> sg
>>
>>
>> Am 16.01.2022 um 23:04 schrieb Carsten Bormann:
>>> -03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while.  -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim.
>>>
>>> Grüße, Carsten
>>>
>>>
>>>> On 2022-01-16, at 23:01,internet-drafts@ietf.org  wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the JSON Path WG of the IETF.
>>>>
>>>>         Title           : JSONPath: Query expressions for JSON
>>>>         Authors         : Stefan Gössner
>>>>                           Glyn Normington
>>>>                           Carsten Bormann
>>>> 	Filename        : draft-ietf-jsonpath-base-03.txt
>>>> 	Pages           : 31
>>>> 	Date            : 2022-01-16
>>>>
>>>> Abstract:
>>>>    JSONPath defines a string syntax for selecting and extracting values
>>>>    within a JavaScript Object Notation (JSON, RFC 8259) value.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/
>>>>
>>>> There is also an HTML version available at:
>>>> https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03
>>>>
>>>>
>>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>>
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories:http://www.ietf.org/shadow.html
>>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>  
>> 	Virenfrei. www.avg.com 
>>  
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
>

--------------p8miKNXSPEqeNdOPlrhu5yAR
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    hmm ... here

        

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/145

      

    
Am 17.01.2022 um 14:10 schrieb Stefan
      Gössner:

    

    

      
      pull request is here ...

          

          https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/compare/main...goessner:main

        

      
Am 17.01.2022 um 14:10 schrieb Stefan
        Gössner:

      

      

        
        ... I did some work on
            ABNF texts. Especially I tried to get equality comparisons
            of structured values right.

            --

            sg

            

          

        
Am 16.01.2022 um 23:04 schrieb
          Carsten Bormann:

        

        

          
-03 consolidates all the changes we have had since -02, which was about 2.5 months ago, so it has been overdue for a while.  -03 is intended as the document to look at for and at the 2022-01-18 JSONPath interim.

Grüße, Carsten




          

            
On 2022-01-16, at 23:01, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Path WG of the IETF.

       Title           : JSONPath: Query expressions for JSON
       Authors         : Stefan Gössner
                         Glyn Normington
                         Carsten Bormann
	Filename        : draft-ietf-jsonpath-base-03.txt
	Pages           : 31
	Date            : 2022-01-16

Abstract:
  JSONPath defines a string syntax for selecting and extracting values
  within a JavaScript Object Notation (JSON, RFC 8259) value.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-jsonpath-base-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


          

        

        

        


          

            
              

                
                Virenfrei.
                  www.avg.com 
              

            
          

           

        

        

      

      

      

      

    

    

  


--------------p8miKNXSPEqeNdOPlrhu5yAR--


From nobody Mon Jan 17 17:13:42 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85753A0B4A for ; Mon, 17 Jan 2022 17:13:39 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhp-TIyimoHF for ; Mon, 17 Jan 2022 17:13:35 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D783A3A0B45 for ; Mon, 17 Jan 2022 17:13:34 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Jd9kz3cChzDCcf; Tue, 18 Jan 2022 02:13:31 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
Date: Tue, 18 Jan 2022 02:13:31 +0100
X-Mao-Original-Outgoing-Id: 664161211.101193-b76df2a5717103d4f1154d83b94e0273
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <164246808851.21465.1820987780096627397@ietfa.amsl.com>
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: [Jsonpath] Fwd: I-D Action: draft-bormann-jsonpath-iregexp-02.txt
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 01:13:40 -0000

In preparation for tomorrow=E2=80=99s interim meeting, I submitted a =
version of iregexp that is further streamlined (by removing =
multi-character escapes, i.e., \s, \d, \w and their uppercase =
equivalents, which caused more complexity than one would think).

This should now be really easy to implement on most platforms that do =
have a somewhat modern (Unicode-capable) regexp flavor.  One can lament =
the loss of multi-character escapes, but these were a cause of =
interoperability surprises with regexps before.

I hope we can pick this up for solving jsonpath issue #70.

See you all in < 9 hours!

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


> Begin forwarded message:
>=20
> [=E2=80=A6]
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
>        Title           : I-Regexp: An Interoperable Regexp Format
>        Author          : Carsten Bormann
> 	Filename        : draft-bormann-jsonpath-iregexp-02.txt
> 	Pages           : 11
> 	Date            : 2022-01-17
>=20
> Abstract:
>   "Regular expressions" (regexps) are a set of related, widely
>   implemented pattern languages used in data modeling formats and =
query
>   languages that is available in many dialects.  This specification
>   defines an interoperable flavor of regexps, I-Regexp.
>=20
>   The present version -02 of this document is a more streamlined =
update
>   of the original trial balloon, meant to determine whether this
>   approach is useful for the JSONPath WG.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bormann-jsonpath-iregexp/
>=20
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-jsonpath-iregexp-02




From nobody Mon Jan 17 20:59:19 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74E13A1071 for ; Mon, 17 Jan 2022 20:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 hV0ANi_7E--i for ; Mon, 17 Jan 2022 20:59:13 -0800 (PST)
Received: from sonic316-13.consmr.mail.bf2.yahoo.com (sonic316-13.consmr.mail.bf2.yahoo.com [74.6.130.123]) (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 185A23A106F for ; Mon, 17 Jan 2022 20:59:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642481951; bh=sUxxhPBdwwugr+306ADuC7pUt8Fdg7e7CF1qSD8BGxQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=cqyEB7Ycn9I4Bf8agzgjxTSDTFtC+lJeSNk+TgOB86yPyy+Yw3RRn7tLgal8Q8I9d9wQgGsSrupLgwj8wwXL65Zx65IsPhCtGqQXDzphX9tZhEamJDTVRJ3C8ltxd1IC6L3PSes7b1+W3k8IxS6azP5zKJuNCvQJzbOQ88GuZtY2uHivYxnfMWFKpEWhLAG8jIKT3J0JsDgnUZKr6VTnCrnwuYllu7S4lB9JVBE1OtL1078EiY+YG2tkI9JimHFZA1FoibHkfyxXcZ24mLOo5ibdfuS8253lZCTIySXWjOOwyJQ+RFMziWVfvbFcqtSrXX75i9iLsyrVTXyB30C2HQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1642481951; bh=85vGYRqrzCVPBQDE7nOs/BjPDq8bMcQayUR2oQJ3eW6=;  h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Do0ZQuVihqry7Hui5zKwxSCMr9QoIcKVhqKF0efRW4f2El4ak7JmzcaWp6n6MlTzAtqbkSKqLg6niOhoY8rJDozTDKS0EupQo/wxL/crDqtcxZMoA5Et4H19j1cDMfkGpGQqEfgNI/Mu7stW2EymN4P1UM9RE6uvwO0Ls7Gqol7CfGDqDw4FME6tiASybIK7pO65At8bRMPoqWA5ewo++o/1Z7/xj1KSzCWiba7cOL48CuNg34bMdhpSArxzlktyyu43+A6HQE5e4M3G6x0aLDSvsyODctQeAWxVAkdSFgAcdDsvn1u6dTZZ7wsqyTcLlrwamMA7Q/hu0phpJ+ym1A==
X-YMail-OSG: KbjTWHsVM1k.jy7duaY3O8wN3wr.Y9c_sOmoIWbLodHSlm2yWNkk3psQISA0dZl 7poif4hmCMRBXnj9qtHLkPfO9aKR8agStrZAULBNIxnoLeQwHXUqbL_761HhJ2eqWFgRWnUa22Yg b5lVJ6YdQAJsSqxUZd5LvcKh08_ePwWtLxp9aCUrQIaYASOEpHguXIswfsDBamJ9uExksHhMwUDK ExUgLEfUgyogR8EyU5m74gmK9JtsOw40IhhKawHyrrS4d80VuaLoKdQrInXcakL3e5wJnwmrw4.L cmkXJ2JZry0UHjtxLMDkduNoaimdiRtCLY776WZ.N2eTNYVu_Gu7WlmRFXQ2P6wykRuEcD6ZKxlF sCTK9jbOQwBSTTx9yiSue_v2UYl9fkTswc8uS5GafElXkNRNxuOYVPNV2C58JQQKepYy1OxiutqF Ug.qiv5LI81I12f61pWoyOPv0J.evnx6Ac9FWUpm7tqajKRuh1xepWZF8vvgjiEc5L5V3crVG0YM v8IhvWWMES2T3jrqB1AfHcgKzuEKjeAYbsQL5lYGXQ3WvUYM2Vxj5z8Rce.jHaEGrOBQfeHdZuL6 M33drMaZKl1BaJdNPBLR2bH.RHpW9twk8WMke4tS84zafS.oNmPmvnUkXI5A_8C6mmYZaCpQ5cBZ l5cwfk0z1wea9RoAP.UoB5P87v3Ugq6QB770llFQORUVb5_SO1HruLVwQP.kjxsN7zCTOWbIXja3 bSxo2iY7YAcHSUrmoHPYLenQh1ven8pLmm_Mcg0A7KgcjqCNoQRiBezKDTyE4.wwjgB3jGwRlLvB QyZsB.dA2wlD2PgQ82zIjHZqG_WBQvBmgkY5pynI2RX3A3gguHvcF23ewmZVQEydpEiiXDBGPEuI Gdc7jhLLJZo_ou8gwzIVwiZj9fssJs1ZyrGrjPyuQ9aopDmUxGg9DRLEA7mn2Hg9krWlrzFtXi1F 9hz1tcVTfIO9hzdUTtLNF6ZqxXQBxPmneBHiz7lUsxFPDNT6kuQEAzrmqWV2XTGFXFkOcWSBIpYL eHAlNhByJXIiPvzbYG9FB41Qiu0Qdh_4dRWWYshlwUKAV3u_7C2VZ6aqxNxbaJPnaCQ6JYv36WAp PxsWe4L1gS81W8EWcgkNV3OFK5eB5K0lWnbEIoza_iw3YSkdzcHivuSYnBugD0301x84PP8uHky2 wc_8WeK2THGoV8QLkNZxm6k5wq1m.myRe6o.A0QjZ2lSxr8nwXnYbl8OxtZXSGuOMEp75.I_vNjK w5uKRW2B9rTsmb8aBaLIcMvJIJe_O2CCpqd2Ed.JxlxD.uR2Hs2TkvJjpZeVA47BZ1.NpueZYMjU OhUl6U2V_eN5Nmcmq2HRvCK0smGgWFIytc431LtulyCddy03DcAF8HlQo.CUbrdUIfdVVrRC7iHB D..ySv9W2cGlJPloRQloxiGSRjGlmQoxYM2X.LN.ziWKjhLn9tE6tascIq0V9_dKcHPbvecYjn4p 8PjTVnYO2Kkl40u0I7KFDi6XImL6RHqYHJmziLinGM8ZPnThGzQlLzSoRcWyQIiAGmXeF2aezhNH lVN1KJOZ1nrjDQfHp.bTwzF5yHNDCR1WwaOquilKchKDnku45Kv7.bX0NIPdYRcIBVYGPWJ0jAh7 kF2VbmcijmN.Z23wPL8xSWLlN3vAPXO2lS7lD5k4u7do4teMJFWKv8lu4L3ZXF36gISRJKEnONCE kUTcsw6Tca4fOp6FFmoiRsuBj_.mQfcubUCTfLMPAOf.4JRl_W5qZqdtO9Rcr_eJnQemxzD_QuT9 NIxmcG.zGmbru5XUyJDyZICgm_FArsO2MV9STMwRoOqfdzfWvrhc1o2hGttRdVv5_Jf.jqSiGQqA PHEoUzycTgxAKCv66rn5pCnfp0NzfQpP3nXFwydLBAxrEfiBzY8Nk76nxcdSub.ZNECAvCmzszV0 k4oQrV89eYvLkLp7ELDx0bJrf_SAG_zgRp5plp2AwxHcMYjosSMuLMxq5TnYfGM0XP9gzNtF41Dg F26W6qhQ4QB2zngXjPj8aDE1_Zt2LdATuSY1HeVXjK_F735CmBQUBibF9z0OYU6WYJCf2M9gDdmN UTHkfO1fTXfuOBEPcVCIw1WEGBOBH3ZqcsZhlHh0OFVgoANQnMCBZOJF9B1Ezx7zVbODL1XjJegM irlY8B2Qx.6y1ebVEIkipE0HbcFGCq.Ac03cJiaHZP_rED2kNZyhbcgdlqtexcFG7tptI1ecyHsl nDGNA72UTt6_wDU99ng1UduAtSEHTaokxKnR5yMROqdapaSX3YqRgyGfqZnYO_TWzveSC2qlgVXa s5yr2RAjwbypH50hjcoq8MpGPHek.gMT8TVTg.tnDypyr1Wx9FN2Je4HCi2qQztHaPHYNhF08Y9l 0XKJvTLMHt2lUEAnsHZL2rWKYu5zhvftc3So1pA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Tue, 18 Jan 2022 04:59:11 +0000
Date: Tue, 18 Jan 2022 04:59:00 +0000 (UTC)
From: Greg Dennis 
Reply-To: Greg Dennis 
To: cabo@tzi.org
Cc: 
Message-ID: <38512476.714399.1642481940963@mail.yahoo.com>
In-Reply-To: 
References: <164246808851.21465.1820987780096627397@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_714398_385425175.1642481940961"
X-Mailer: WebService/1.1.19594 YahooMailAndroidMobile
Archived-At: 
Subject: Re: [Jsonpath] Fwd: I-D Action: draft-bormann-jsonpath-iregexp-02.txt
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 04:59:18 -0000

------=_Part_714398_385425175.1642481940961
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Carsten, you have closed a number (lot) of issues recently, but it seems th=
at many of them were open discussions still.
It would be helpful if a summary of the decision or change were included in=
 the closure.
ThanksGreg
=20
=20
  On Tue, 18 Jan 2022 at 2:13 pm, Carsten Bormann wrote:   In=
 preparation for tomorrow=E2=80=99s interim meeting, I submitted a version =
of iregexp that is further streamlined (by removing multi-character escapes=
, i.e., \s, \d, \w and their uppercase equivalents, which caused more compl=
exity than one would think).

This should now be really easy to implement on most platforms that do have =
a somewhat modern (Unicode-capable) regexp flavor.=C2=A0 One can lament the=
 loss of multi-character escapes, but these were a cause of interoperabilit=
y surprises with regexps before.

I hope we can pick this up for solving jsonpath issue #70.

See you all in < 9 hours!

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


> Begin forwarded message:
>=20
> [=E2=80=A6]
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : I-Re=
gexp: An Interoperable Regexp Format
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Car=
sten Bormann
> =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bormann-js=
onpath-iregexp-02.txt
> =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 11
> =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2022-0=
1-17
>=20
> Abstract:
>=C2=A0 "Regular expressions" (regexps) are a set of related, widely
>=C2=A0 implemented pattern languages used in data modeling formats and que=
ry
>=C2=A0 languages that is available in many dialects.=C2=A0 This specificat=
ion
>=C2=A0 defines an interoperable flavor of regexps, I-Regexp.
>=20
>=C2=A0 The present version -02 of this document is a more streamlined upda=
te
>=C2=A0 of the original trial balloon, meant to determine whether this
>=C2=A0 approach is useful for the JSONPath WG.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bormann-jsonpath-iregexp/
>=20
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-jsonpath-iregexp-02



--=20
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
 =20

------=_Part_714398_385425175.1642481940961
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Carsten, you have closed a number (lot) of issues recently, but it seems th=
at many of them were open discussions still.

It would be helpful if a summary of the decision or change were i=
ncluded in the closure.

Thank=
s
Greg
 
 
 
 
In prepar=
ation for tomorrow=E2=80=99s interim meeting, I submitted a version of ireg=
exp that is further streamlined (by removing multi-character escapes, i.e.,=
 \s, \d, \w and their uppercase equivalents, which caused more complexity t=
han one would think).

=
This should now be really easy to implement on most platforms that do have =
a somewhat modern (Unicode-capable) regexp flavor.  One can lament the=
 loss of multi-character escapes, but these were a cause of interoperabilit=
y surprises with regexps before.

I hope we can pick this up for solving jsonpath issue #70.

See you all in < 9 hours=
!

Gr=C3=BC=C3=9Fe, Car=
sten


> Begin forwarded message:
> 
=

> [=E2=80=A6]
> A Ne=
w Internet-Draft is available from the on-line Internet-Drafts directories.=

> 
> 
<=
div dir=3D"ltr">>        Title      &=
nbsp;    : I-Regexp: An Interoperable Regexp Format
>        Author        =
  : Carsten Bormann
>     =
Filename        : draft-bormann-jsonpath-iregexp-02.txt=

>     Pages     =
;      : 11
>     Dat=
e            : 2022-01-17
> 
> Abstract:
>   "Regular expressions" (regexps) are a set of related, =
widely
>   implemented pattern languages =
used in data modeling formats and query
> =
;  languages that is available in many dialects.  This specification
>   defines an interoperable flavor of reg=
exps, I-Regexp.
> 
&=
gt;   The present version -02 of this document is a more streamlined u=
pdate
>   of the original trial balloon, =
meant to determine whether this
>   appro=
ach is useful for the JSONPath WG.

------=_Part_714398_385425175.1642481940961--


From nobody Mon Jan 17 22:25:14 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02E13A1551 for ; Mon, 17 Jan 2022 22:25:10 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWvwMcD0D7-S for ; Mon, 17 Jan 2022 22:25:06 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD9F3A154F for ; Mon, 17 Jan 2022 22:25:04 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JdJfP6DpSzDCbs; Tue, 18 Jan 2022 07:25:01 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: <38512476.714399.1642481940963@mail.yahoo.com>
Date: Tue, 18 Jan 2022 07:25:01 +0100
Cc: jsonpath@ietf.org
X-Mao-Original-Outgoing-Id: 664179901.460964-260c685754ece103e6ef1780afc2f5a6
Content-Transfer-Encoding: quoted-printable
Message-Id: <982E91BA-E166-401E-A02B-00CFA8C9EC9D@tzi.org>
References: <164246808851.21465.1820987780096627397@ietfa.amsl.com>  <38512476.714399.1642481940963@mail.yahoo.com>
To: Greg Dennis 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: [Jsonpath] Closing issues (not really: Re: I-D Action: draft-bormann-jsonpath-iregexp-02.txt)
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 06:25:11 -0000

Hi Greg,

On 2022-01-18, at 05:59, Greg Dennis =
 wrote:
>=20
> Carsten, you have closed a number (lot) of issues recently,

25, I think.

> but it seems that many of them were open discussions still.

If by that you mean =E2=80=9Cwide open, meandering, aimless =
discussion=E2=80=9D, I can probably agree :-)
Actually, many discussions were useful at their time, but are no longer =
providing actionable content with the direction the document has taken.

> It would be helpful if a summary of the decision or change were =
included in the closure.

I think I added a comment why I closed them to each of them.
7 of them also got a =E2=80=9Crevisit-after-base-done=E2=80=9D tag, so =
we remember to look at them once the base document is done:

=
https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues?q=3Dis=
%3Aissue+label%3Arevisit-after-base-done

If you don=E2=80=99t agree with closing one of the 25 issues, please:
- do one of:
  =E2=80=94 reopen the issue,
  - add a revisit-after-base-done tag, or=20
  - add a new issue that focuses the question we actually need to decide
=E2=80=94 also, please bring it up in the interim today.

Thank you!

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


From nobody Tue Jan 18 01:55:16 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921E03A14D2 for ; Tue, 18 Jan 2022 01:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level: 
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSxJLTnsiyRy for ; Tue, 18 Jan 2022 01:55:09 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (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 073F43A14C1 for ; Tue, 18 Jan 2022 01:55:08 -0800 (PST)
Received: from [192.168.178.20] ([88.130.50.9]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MzQc2-1mNJPe3ioS-00vQ9s for ; Tue, 18 Jan 2022 10:55:06 +0100
Content-Type: multipart/alternative; boundary="------------ohuStW0D5k7KUiaqBFOAR03W"
Message-ID: 
Date: Tue, 18 Jan 2022 10:55:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
To: jsonpath@ietf.org
References: 
From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= 
In-Reply-To: 
X-Provags-ID: V03:K1:zfrAn/oUsQduAFAlwPAvVMqCvvusA6v+dBz85+N8jUxf+mk7Rcr kqCTz8nOIBExFwyNb2J9hNpCGTwVZ9jo85Mm0/cRSjTrCEplq/0GLE4C5UFb5Lxuv+xLXCp E5m9pFUrwTsBYmIKCL3eXZU7EwdBREXqcUmFxbJLCRuw2glq8gO6tyhP7Ir4GELtxcWaJ+C W7hKGOvt359zOUIrTDP0g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:NEwRf2AjAeg=:9LHdSWTZ8CXWPaSb8ruAm+ PjsXA6d3egAEWs1MI+si344I5zJPKKVkaq8zISjpRDLSo0D3Fp8jtU8TfAbsONKN0BofGvtkf E86vr/ERYuPsdoBCgB2pIllJCwYJsJZospojqMZYa7TPEWgPzwlMJ9NiyyN/xPmtc/pJawaqh cJ3nuPmGguQ6+T+3nwnAG9BdeyY/UXMpsBk4T/f5453YYRP1CXrfu9+/85eYxk26Z8rkHwdlh tIFHBs042vxNcAjBTe0gOe2mWM/uRMKMnNvpMrsZG6ZLuycJCHBjF0RNyJHNcLT35WiRkqQ+o Zv03i/T16g0G6TsQwcP4uurS+lcBduHktWfQ5x4hjzSP8YLHWXmY9DK250xYqnBOUO+eBM4ee qYzRtOj8bMj1IXHcQHMvFYjuoVozoASID3pmq+eSa0gLHyh/RJWv3yLVMvcLFPfrcIakQtkh0 O7Luw6b738rYpYskeDnBytcCANukxHuAsYcK1XnBTNUdZ1toAtaue9IfJUsxoCzxtYqjhEipq 8j/Y4iy0wIwQ/MrvrNnAoqgWA3na+rIbSZvtYOlTowQmmsAwVDjuaKhPw2L4URwXbdlr4CrGs 9VL4KnPwftAniUX2JpkuVHo6XtlSWdV3xgF924q0VWOMzEwOtpEWb/fAYZKJI5QeUtZM4ZSJd JnEGwWGyecgCpEyC5J5kVgQrUbSu6DWXjo3bhVT8VuCz3TgEUufVfNvAa4IYvKE+2mT0=
Archived-At: 
Subject: Re: [Jsonpath] January 2022 interim meeting and agenda
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 09:55:14 -0000

This is a multi-part message in MIME format.
--------------ohuStW0D5k7KUiaqBFOAR03W
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

hmm ... trying to login into meetecho by

https://meetings.conf.meetecho.com/interim/?short=39034cb3-f4b8-4c58-911b-8822065381f5

i get the message "This session is over" ?

--
sg



Am 03.01.2022 um 13:27 schrieb James G:
> Folks,
> This is a gentle reminder that our next interim meeting is in approximately two weeks on Tuesday, January 18th at 10:00 UTC.
>
> https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/jsonpath
>
> We haven't finalised (or published) the agenda yet, so if there’s any subjects or issues you’d like to be part of it please email myself or Tim and we can include it.
>
> - J

--------------ohuStW0D5k7KUiaqBFOAR03W
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    hmm ... trying to login into
        meetecho by

        

      https://meetings.conf.meetecho.com/interim/?short=39034cb3-f4b8-4c58-911b-8822065381f5

        

        i get the message "This session is over" ?

        

        --

        sg

        

        

        

      
    
Am 03.01.2022 um 13:27 schrieb James G:

    

    

      
Folks,
This is a gentle reminder that our next interim meeting is in approximately two weeks on Tuesday, January 18th at 10:00 UTC.

https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/jsonpath

We haven't finalised (or published) the agenda yet, so if there’s any subjects or issues you’d like to be part of it please email myself or Tim and we can include it.

- J


    

    

  


--------------ohuStW0D5k7KUiaqBFOAR03W--


From nobody Tue Jan 18 01:56:55 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E013A14DE for ; Tue, 18 Jan 2022 01:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoCk2uHk2qfF for ; Tue, 18 Jan 2022 01:56:49 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 EC28E3A14DB for ; Tue, 18 Jan 2022 01:56:48 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id q25so76990704edb.2 for ; Tue, 18 Jan 2022 01:56:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=rZ88q8tkCfEdVmFnUPMN8XN3t5XqSIaYLDMIhiN6Afk=; b=pHtzplTdXsnt+0mJgFpzPZCb3ZavBzMBZS016xneZVZ13a3rRNoVEZoTm/QfPYsl/e 88LJ+by2QxtxhlTWoOHiYDzYPuqPRnzzmsLmckzeWSZq2gFjIgsR8sydzXY1CmiYoY+K E82FuQQ+A5jkvQDltlsrZTYpfMWiNidv9xmOuXBgqSHew8Vvkrt0olCODJHHisjH147g Avs1P0odOTclqfOKXO9OiGx1rajXDnsr1m0gfUFhbtBgqD4tNhG2akJ5Jzr5u1Dwz4YY PfI4vLRFgzw2hQdRCa5NK+QI7RcdHVr25JBJQdJ+v8ZYp+Ognwnr6sAV6x1RS0k1VLF4 d94Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=rZ88q8tkCfEdVmFnUPMN8XN3t5XqSIaYLDMIhiN6Afk=; b=MyrpKhdzXoBz9qoOHsHqPqXXbiLOQI9V/LLcP0TVaNAkUsRmykcb7X8hiobqmgncBj IsZxEu5iL+HEz3xemWEDfDhijLkHXc/H1KqKTU4IsSrJJ624pBDkOB7CFZOp9cmB5gJo SPKpj0/zGFm5NaRtcG71MS7Tluk8XWmxxOjQmsNYZqPkjNeoliite1oJJRgGPyKOijCv dUAw1kquWZRvipUWV6mWbKjenWqW/yzj41OcNN20xtjysJNugyr+kbOCYdiwkwn/Hh7F f5vRhttTYUuzrrwj1egO+5OZ98iB5qx1YVsqE0pl16FxUVXlht6JdK2CvmnMz35mVYVI 7rPA==
X-Gm-Message-State: AOAM533bVJ+9q6Hul0jyuFj/FQMb5R9buicsmO/E+wvbgaXDXZmDfVdG +HKJsev++/HQA0ZjlWE/x2v46I2YQN2slg==
X-Google-Smtp-Source: ABdhPJyU9yp0AH0nOVvjxuF6/uVxJ5wOjgiox37YEYXvCMGM2hb9GJpIRFf7UwOcWlrQJXckBe6nRQ==
X-Received: by 2002:a17:906:d157:: with SMTP id br23mr641692ejb.534.1642499805894;  Tue, 18 Jan 2022 01:56:45 -0800 (PST)
Received: from smtpclient.apple ([2001:984:65b0:2:fc77:64bc:43ac:7bbb]) by smtp.gmail.com with ESMTPSA id ju26sm1343021ejc.223.2022.01.18.01.56.45 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jan 2022 01:56:45 -0800 (PST)
From: James 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Message-Id: 
Date: Tue, 18 Jan 2022 10:56:45 +0100
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: [Jsonpath] January Interim Meeting - UPDATED MEETING URL
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 09:56:54 -0000

Apologies all, there has been a mistake on my behalf in the scheduling =
in Meetecho. The new URL is:

=
https://meetings.conf.meetecho.com/interim/?short=3D56367b84-54cf-4ee3-8fd=
b-41b96487ef5d



From nobody Tue Jan 18 01:57:16 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62CB3A14E1 for ; Tue, 18 Jan 2022 01:57:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.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 WI--2wm9DDLg for ; Tue, 18 Jan 2022 01:57:11 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 49F073A14DB for ; Tue, 18 Jan 2022 01:57:11 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id s30so68401325lfo.7 for ; Tue, 18 Jan 2022 01:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B92TTP3LPuawFLwasExx3FZxBdaLvvj77S6H0sxsivU=; b=KcQoIU1g9hYcxbXVFupYfgUVLsFKBG5glNT2Ik1S8k45wrRiwItZvIAY7fPQ2ZuqAB nnJxzf3cp0LRnxoVbYi+tf+k3OI0UNNj1tWNs4PgRibD11Qr/4a0PbNINdsFSkhB7PM1 l8Poue+rDf96s7rJMyX/A0C1xmmX+IujOSjTk/emSJasvioq5/6SCUrJ8BZEa9vJazKo YkKCcH2fcFDcVsLxB+xhnhl9lym1FXO04yuca/3vHibesQMuU7PeXAJ10aqNobA8+GwE ETblz7985V8rz5R5v73xdmVU50jv8e4jmQ3E3EkAc2C4dtJMZpXTln9tJXyyMXa81PPg zxDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B92TTP3LPuawFLwasExx3FZxBdaLvvj77S6H0sxsivU=; b=xc3ZHBIBT9WBTkH3VqDeno+BOd4raZwC/yTZFDaO/g+wqhf9EOLLFkqxIvsdlFMSpR CUozDpSl14Bgt/OWOR/ADw8xB/hQEX33tcabt8CsjsJUNNskEF4JwCVdKFb1Z7q0px7Z tcr4K9H9BhnLGGQy7iE3KC6RPeE9qQB0DrnYQyZH7beUVteC5DunXzxpx14wEHC0YlTR xc4ZuT2iTgN3HiI42YEaAS7ROka+KO+AEMJVXl6wPW5MWnTr81G82g6hz72+sHSh62pC iryGwIxDQsUQWOBX1F3u7bhEw0sUqD9gyRKn0GDJq/q9YIIrUzhlgtDu+IaR2dGjlzLY aYkQ==
X-Gm-Message-State: AOAM533m/DH0xJ9Igg2co/OskHfA7rLFQPHPPr6CCQ6DsemzYqHTiyjF DSmlt/SL0icUOuLoG5NWQbpcRiMhKUTmaR9aUP679sM4GbE=
X-Google-Smtp-Source: ABdhPJxjCPddX2TXnVxjvwyXGyftjxSo44b4i0pgV/yYWRZ1dhQ9iyMRO/D8sm3DNrpPoQ4YjFwhK0PWH3jdd3F/Gv8=
X-Received: by 2002:a05:6512:104e:: with SMTP id c14mr15217852lfb.646.1642499827556;  Tue, 18 Jan 2022 01:57:07 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Tim Bray 
Date: Tue, 18 Jan 2022 01:56:56 -0800
Message-ID: 
To: =?UTF-8?Q?Stefan_G=C3=B6ssner?= 
Cc: jsonpath@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c3f4ba05d5d84aac"
Archived-At: 
Subject: Re: [Jsonpath] January 2022 interim meeting and agenda
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 09:57:16 -0000

--000000000000c3f4ba05d5d84aac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, me too.  Hmmm=E2=80=A6

On Tue, Jan 18, 2022 at 1:55 AM Stefan G=C3=B6ssner  w=
rote:

> hmm ... trying to login into meetecho by
>
>
> https://meetings.conf.meetecho.com/interim/?short=3D39034cb3-f4b8-4c58-91=
1b-8822065381f5
>
> i get the message "This session is over" ?
>
> --
> sg
>
>
>
> Am 03.01.2022 um 13:27 schrieb James G:
>
> Folks,
> This is a gentle reminder that our next interim meeting is in approximate=
ly two weeks on Tuesday, January 18th at 10:00 UTC.
> https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/jso=
npath
>
> We haven't finalised (or published) the agenda yet, so if there=E2=80=99s=
 any subjects or issues you=E2=80=99d like to be part of it please email my=
self or Tim and we can include it.
>
> - J
>
>
> --
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>

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


Yes=
, me too.=C2=A0 Hmmm=E2=80=A6

On Tue, Jan 18, 2022 at 1:55 AM Stefan G=
=C3=B6ssner <stefan@goessner.net<=
/a>> wrote:

 =20
   =20
 =20
  

    hmm ... trying to login int=
o
        meetecho by

        

      https://meetings.conf.meetecho.com/interim=
/?short=3D39034cb3-f4b8-4c58-911b-8822065381f5

        

        i get the message "This session is over" ?

        

        --

        sg

        

        

        

      
    
Am 03.01.2022 um 13:27 schrieb James G:

    

    

      
Folks,
This is a gentle reminder that our next interim meeting is in approximately=
 two weeks on Tuesday, January 18th at 10:00 UTC.

https://datatracker.ietf.org/meeting/inte=
rim-2022-jsonpath-01/session/jsonpath

We haven't finalised (or published) the agenda yet, so if there=E2=80=
=99s any subjects or issues you=E2=80=99d like to be part of it please emai=
l myself or Tim and we can include it.

- J


    

    

  


-- 

JSONpath mailing list

JSONpath@ietf.org

https://www.ietf.org/mailman/listinfo/jsonpath




--000000000000c3f4ba05d5d84aac--


From nobody Tue Jan 18 01:57:23 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394C03A1242 for ; Tue, 18 Jan 2022 01:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zUS-k3OkAjU for ; Tue, 18 Jan 2022 01:57:18 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303153A14E9 for ; Tue, 18 Jan 2022 01:57:18 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JdPMF3dPxzDCfj; Tue, 18 Jan 2022 10:57:13 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 18 Jan 2022 10:57:13 +0100
Cc: jsonpath@ietf.org
X-Mao-Original-Outgoing-Id: 664192633.259032-9e540039e4174207e9aafd637d9f9a80
Content-Transfer-Encoding: quoted-printable
Message-Id: <210F3F0E-2B13-469B-B5D0-2C6105156B1B@tzi.org>
References:  
To: =?utf-8?Q?Stefan_G=C3=B6ssner?= 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Jsonpath] January 2022 interim meeting and agenda
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 09:57:22 -0000

Same for me.  Alerted meetecho and secretariat.


> On 2022-01-18, at 10:55, Stefan G=C3=B6ssner  =
wrote:
>=20
> hmm ... trying to login into meetecho by
>=20
> =
https://meetings.conf.meetecho.com/interim/?short=3D39034cb3-f4b8-4c58-911=
b-8822065381f5
>=20
> i get the message "This session is over" ?
>=20
> --
> sg
>=20
>=20
>=20
> Am 03.01.2022 um 13:27 schrieb James G:
>> Folks,
>> This is a gentle reminder that our next interim meeting is in =
approximately two weeks on Tuesday, January 18th at 10:00 UTC.
>>=20
>>=20
>> =
https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/json=
path
>>=20
>>=20
>> We haven't finalised (or published) the agenda yet, so if there=E2=80=99=
s any subjects or issues you=E2=80=99d like to be part of it please =
email myself or Tim and we can include it.
>>=20
>> - J
>>=20
>=20
> --=20
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath


From nobody Tue Jan 18 01:59:34 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EF3A14F6 for ; Tue, 18 Jan 2022 01:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRMB6EuP9hMb for ; Tue, 18 Jan 2022 01:59:28 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 AF8863A14F1 for ; Tue, 18 Jan 2022 01:59:28 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id a12so19904669iod.9 for ; Tue, 18 Jan 2022 01:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4bm+OB3KZomNZiBObt3mMDy0uAcQvNXUtbFyUyshgIs=; b=lhO0/thXcacz0TIoRXafNzJvSbDNsmGbQa7zbqCNWEsvW0lXEKK/LFf2AZ8l6wZirl AzuDtb+lBO8WnWLEd4UxDiHRzPEO35I0nTsYkhu/BJgGfzONywEMrtNdjf0R0C1GIlGU GRycqZybjUlH50qvrSh646gQ9yg9O9SY8kKOacGg+4MWIibe/hD/aZ+zzW9SXGrC54Vb ktjQJ8Am1IGz589ZiBpVbuXQy8VV7embcKkXzIPFl1osiNjDoHS2N0p+/JjUcf6VdXbe HvNtbDh8DKfb680OLnxqBBofjx8X3GN4d80SmnLe89gnXN5pcP9H0jKO0Bn3D9CjHRDS BP1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4bm+OB3KZomNZiBObt3mMDy0uAcQvNXUtbFyUyshgIs=; b=ZCgOj4DxO2477Drq9j2Tw+Gy+63tcjdhIvPvqDkffPh6MV5StNR5qm2V76PCLDGWHa uIhA9UPwu8d2xIYZU367dV1YJXIF0m2YkXeceMEizL/gHM+eP9opZa9W6ExJwTgbiv6e rDt2d9sFfOEB4CCsC/lcL1APo6PtYa4jnCZcnxWS/SWQTEF1iaAQYI9pYMnmm0vbzV04 Zpz2L52uadPVVzfCisOWA2kA7xf69lecPZXPtT2r3I7Ut127yCI8FOZyhOMMf16daay9 E3o71r0YNYUqYV8kY1PmpAMr3fgMCOPVhXocYwoC+uLacY8g3o+jOVgfi3afssgTme98 tasw==
X-Gm-Message-State: AOAM532MUybr1k8nHBhnCFl2qwnbbhs9EDO2EjI4f/i9hb0DJ0q8QA13 hacj2lPHpiwKLxi4UFmLSB3D5Nh7HYBrU8pfTaA=
X-Google-Smtp-Source: ABdhPJxCB+JEDCzCRoo5uHRXx9xC12aQfqQu3mAlIbwOqM3HMwJ8/wj2ElQD/Cu+z7TcP/EaeN8JqOS++G+yaLF5cKU=
X-Received: by 2002:a05:6602:1504:: with SMTP id g4mr3653376iow.61.1642499967269;  Tue, 18 Jan 2022 01:59:27 -0800 (PST)
MIME-Version: 1.0
References:   <210F3F0E-2B13-469B-B5D0-2C6105156B1B@tzi.org>
In-Reply-To: <210F3F0E-2B13-469B-B5D0-2C6105156B1B@tzi.org>
From: Glyn Normington 
Date: Tue, 18 Jan 2022 09:59:16 +0000
Message-ID: 
To: Carsten Bormann 
Cc: =?UTF-8?Q?Stefan_G=C3=B6ssner?= , jsonpath@ietf.org
Content-Type: multipart/alternative; boundary="00000000000017c43805d5d85353"
Archived-At: 
Subject: Re: [Jsonpath] January 2022 interim meeting and agenda
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 09:59:33 -0000

--00000000000017c43805d5d85353
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You are welcome to use my Zoom if that helps:

Glyn Normington is inviting you to a scheduled Zoom meeting.

Topic: JSONPath interim meeting
Time: Jan 18, 2022 10:00 AM London

Join Zoom Meeting
https://us02web.zoom.us/j/89635618195?pwd=3DbFZXaVNoNVdSV2N1MFZyTU1aeDVKZz0=
9

Meeting ID: 896 3561 8195
Passcode: 995455



On Tue, 18 Jan 2022 at 09:57, Carsten Bormann  wrote:

> Same for me.  Alerted meetecho and secretariat.
>
>
> > On 2022-01-18, at 10:55, Stefan G=C3=B6ssner  wrot=
e:
> >
> > hmm ... trying to login into meetecho by
> >
> >
> https://meetings.conf.meetecho.com/interim/?short=3D39034cb3-f4b8-4c58-91=
1b-8822065381f5
> >
> > i get the message "This session is over" ?
> >
> > --
> > sg
> >
> >
> >
> > Am 03.01.2022 um 13:27 schrieb James G:
> >> Folks,
> >> This is a gentle reminder that our next interim meeting is in
> approximately two weeks on Tuesday, January 18th at 10:00 UTC.
> >>
> >>
> >>
> https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/session/jso=
npath
> >>
> >>
> >> We haven't finalised (or published) the agenda yet, so if there=E2=80=
=99s any
> subjects or issues you=E2=80=99d like to be part of it please email mysel=
f or Tim
> and we can include it.
> >>
> >> - J
> >>
> >
> > --
> > JSONpath mailing list
> > JSONpath@ietf.org
> > https://www.ietf.org/mailman/listinfo/jsonpath
>
> --
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>

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


You are welcome to use my Zoom if that helps:

Glyn Normington is inviting you to a scheduled Zoom meeti=
ng.

Topic: JSONPath interim meeting
Time: Jan 18, 2022 10:00 AM L=
ondon

Join Zoom Meeting
https://us02web.zoom.us/j/8=
9635618195?pwd=3DbFZXaVNoNVdSV2N1MFZyTU1aeDVKZz09

Meeting ID: 89=
6 3561 8195
Passcode: 995455



On Tue, 18 Jan 2022 at 09:=
57, Carsten Bormann <cabo@tzi.org>=
; wrote:
Same fo=
r me.=C2=A0 Alerted meetecho and secretariat.





> On 2022-01-18, at 10:55, Stefan G=C3=B6ssner <stefan@goessner.net> wrote:

> 

> hmm ... trying to login into meetecho by

> 

> https:/=
/meetings.conf.meetecho.com/interim/?short=3D39034cb3-f4b8-4c58-911b-882206=
5381f5

> 

> i get the message "This session is over" ?

> 

> --

> sg

> 

> 

> 

> Am 03.01.2022 um 13:27 schrieb James G:

>> Folks,

>> This is a gentle reminder that our next interim meeting is in appr=
oximately two weeks on Tuesday, January 18th at 10:00 UTC.

>> 

>> 

>> https://datat=
racker.ietf.org/meeting/interim-2022-jsonpath-01/session/jsonpath

>> 

>> 

>> We haven't finalised (or published) the agenda yet, so if ther=
e=E2=80=99s any subjects or issues you=E2=80=99d like to be part of it plea=
se email myself or Tim and we can include it.

>> 

>> - J

>> 

> 

> -- 

> JSONpath mailing list

> JSONpath@ietf.o=
rg

> https://www.ietf.org/mailman/listinfo/jsonpath



-- 

JSONpath mailing list

JSONpath@ietf.org

https://www.ietf.org/mailman/listinfo/jsonpath




--00000000000017c43805d5d85353--


From nobody Tue Jan 18 02:17:30 2022
Return-Path: 
X-Original-To: jsonpath@ietf.org
Delivered-To: jsonpath@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF643A15F9; Tue, 18 Jan 2022 02:17:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: jsonpath@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.42.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164250104330.26368.4231955038243699977@ietfa.amsl.com>
Date: Tue, 18 Jan 2022 02:17:23 -0800
Archived-At: 
Subject: [Jsonpath] JSON Path (jsonpath) WG Virtual Meeting: 2022-01-18 CHANGED
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 10:17:24 -0000

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The JSON Path (jsonpath) WG will hold
a virtual interim meeting on 2022-01-18 from 11:00 to 13:00 Europe/Amsterdam (10:00 to 12:00 UTC).

Agenda:
# JSONPath IETF January 2022 Interim Meeting Agenda

Date: 2022-01-18
Time: 10:00 - 12:00 UTC

Chair: Tim Bray
Chair: James Gruessing
Area Director: Francesca Palombini

* [Datatracker](https://datatracker.ietf.org/group/jsonpath/about/)
* [Jabber](xmpp:jsonpath@jabber.ietf.org?join)
* [Minutes](https://notes.ietf.org/notes-ietf-interim-2022-jsonpath-01-jsonpath)

## Agenda
* Draft Status
* Issues
  * Regular Expressions - #143, #70
  * Absent equal to absent - #123
  * Updates on other issues

### Administrivia

* Note Takers
* Jabber Scribe
* Agenda Bashing

## Discussion


### AOB



Information about remote participation:
https://ws.conf.meetecho.com/conference/?group=56367b84-54cf-4ee3-8fdb-41b96487ef5d


From nobody Tue Jan 18 10:17:15 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C100F3A090D for ; Tue, 18 Jan 2022 10:17:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.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 F4hw_pPB3TkL for ; Tue, 18 Jan 2022 10:17:08 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 F2CEE3A0B9C for ; Tue, 18 Jan 2022 10:17:07 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id x7so74204777lfu.8 for ; Tue, 18 Jan 2022 10:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ojQlRDNAPP0AVsWaFPO3wlMAZI1X1RDVNj5pYjKxoW8=; b=iDJcOegLV19C3KGv/44yJE/TPIEWjlLccO7BRylcKYBSuhC5/kQkiLqQ544x5Jhxsg mZVQ9dIEaBMFDERR/jLZ0KVZCjGjg76M/y/ajPSX+q9Kh5CShb8ArPYyvESqJZBgh8Rn 0y5H2w4Vs1dQbDKW0Xnh3ilj2xB2Gr71Ebq9VLUek8JQBgmYidXVJ9nS12Gv8yplczAL v4jZEXA/xQ6grAAI2pg0Jfnn6PB/Z4H3GXsYg04llncEuglCuc1JA0+hgYqvUZDe3P3c X81vkQ9SthnQT18je9vhaRpF0mW/tiqxzx3it7TnYDpewoxXLTgr0h8ay0Gk8JWQkNM9 VJYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ojQlRDNAPP0AVsWaFPO3wlMAZI1X1RDVNj5pYjKxoW8=; b=bAOh17GTbKF49wAc5lYFJ/oXlPRBMJI5xrlIlqt6/efqxmKcNOowXS27mxlddybnMh 66mrWp/1ypxP1sw28zxJT8bhYRH6kitdh5bYCb23owrGN6gxB8hSJM/jGWAtVKwNYbtr Pbuw5UzS8cKVZ7vnJj+jBHDs7nlP1irjSk3CBdy0HorKeCg/7pGwz18bKdbIP8sDp7g+ 94SnuebqIbQepNiGNM0NDcL3OC97MZCzEdXPBj0/YZzmnEpigG+irm3MoJoUipPjwGip /UHZ77I6eEj7B87Si4DuwU20nARLeg2PgYIS2fXzenQO5ZlCJoaqKmVh/B5kg7w3xizn ZS3w==
X-Gm-Message-State: AOAM53038SE6dyvy2vtoCRZhhTxYEq0zJYcYOBKvtCbtx5LP+hwC5y7m 1InIw2Sl7+m/M09a98LVKsyo67VJX3m6TXMkdBrvXbbjijuRmg==
X-Google-Smtp-Source: ABdhPJxSdvwopXruA3KdooKbBQpgv+wdofQrzL0+bBaMM6h3XjS0NMtHzxDI6aK8IiLHp9a7YfSI9KKP+Nv4eH3ei5o=
X-Received: by 2002:a2e:824d:: with SMTP id j13mr20353645ljh.466.1642529823971;  Tue, 18 Jan 2022 10:17:03 -0800 (PST)
MIME-Version: 1.0
From: Tim Bray 
Date: Tue, 18 Jan 2022 10:16:52 -0800
Message-ID: 
To: jsonpath@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b0f06d05d5df46b2"
Archived-At: 
Subject: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 18:17:14 -0000

--000000000000b0f06d05d5df46b2
Content-Type: text/plain; charset="UTF-8"

Co-chair hat on: At our interim meeting earlier today, we got a strong
sense that the jsonpath WG has consensus in favor of allowing regular
expressions in jsonpath filters, but that for this to be useful, the flavor
of regexps needs to be specified precisely, and that flavor should be
limited enough in scope to allow interoperation across as many as possible
different regex libraries.

Carsten Bormann has done the work of proposing such a small-scope
regexp specification. The draft may be read at
https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
and is on GitHub at https://github.com/cabo/iregexp

If you have any issues to raise or objections to this, please let the WG
know.

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


Co-=
chair hat on: At our interim meeting earlier today, we got a strong sense t=
hat the jsonpath WG has consensus in favor of allowing regular expressions =
in jsonpath filters, but that for this to be useful, the flavor of regexps =
needs to be specified precisely, and that flavor should be limited enough i=
n scope to allow interoperation across as many as possible different regex =
libraries.=C2=A0

Carsten =
Bormann has done the work of proposing such a small-scope regexp=C2=A0speci=
fication. The draft may be read at=C2=A0https://www.ietf.org/archiv=
e/id/draft-bormann-jsonpath-iregexp-02.html
and is on GitHub at=C2=A0https://github.com/cabo/iregexp

If you have any issues to raise o=
r objections to this, please let the WG know.


--000000000000b0f06d05d5df46b2--


From nobody Tue Jan 18 10:31:02 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C63A1041 for ; Tue, 18 Jan 2022 10:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 YIbolTfnkskf for ; Tue, 18 Jan 2022 10:30:57 -0800 (PST)
Received: from p3plwbeout05-04.prod.phx3.secureserver.net (p3plsmtp05-04-2.prod.phx3.secureserver.net [97.74.135.49]) (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 61E9D3A1047 for ; Tue, 18 Jan 2022 10:30:56 -0800 (PST)
Received: from mailex.mailcore.me ([94.136.40.143]) by :WBEOUT: with ESMTP id 9tFtnCBIQRkdg9tFunj7DD; Tue, 18 Jan 2022 11:30:54 -0700
X-CMAE-Analysis: v=2.4 cv=C7csdSD+ c=1 sm=1 tr=0 ts=61e7075f a=EhJYbXVJKsomWlz4CTV+qA==:117 a=G++axsv19AQkVQuwCdl4cA==:17 a=0d-FJ89MWBcA:10 a=DghFqjY3_ZEA:10 a=ZEAgVxdcAAAA:8 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=5D0ujAclF3ITgqyYMSoA:9 a=CjuIK1q_8ugA:10 a=fa6iYZI0K8gA:10 a=0ccr5IRoRmQA:10 a=LEni5nUE42jjaq2XkyEA:9 a=vRZBt7kUhwx-SR12:21 a=_W_S_7VecoQA:10 a=K4stkocu346RsC3JbKGV:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: mike@saxonica.com  
X-SID: 9tFtnCBIQRkdg
Received: from [82.152.109.221] (helo=smtpclient.apple) by smtp13.mailcore.me with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9tFr-0004pA-PI; Tue, 18 Jan 2022 18:30:53 +0000
From: Michael Kay 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FEFF1248-4123-4E6D-AC93-A14CE90C572A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 18 Jan 2022 18:30:51 +0000
In-Reply-To: 
Cc: jsonpath@ietf.org
To: Tim Bray 
References: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Mailcore-Auth: 439400257
X-Mailcore-Domain: 1881035
X-123-reg-Authenticated: mike@saxonica.com  
X-Originating-IP: 82.152.109.221
X-CMAE-Envelope: MS4xfGJIb1ut5u2+B5MGKw1ySNjB4oo9PRwM87pzQIDDoV81QYLD3Epd0WwPTsJAVuvRZ/K3R7Qk5i6H/IHglBnaieuFDNX6zGg8UucLuvuNNglEcsbeI03k 2ARx0enMgRKk/3FQLB2bMfhh+1w0fLI71FhVxgjwhHvO78XSWZBl1U6E5xh5ijHQn/riCSA9aFwrzQ==
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 18:31:01 -0000

--Apple-Mail=_FEFF1248-4123-4E6D-AC93-A14CE90C572A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I would suggest referencing XSD 1.1 rather than XSD 1.0.

The only difference in the regex capabilities is that XSD 1.1 fixes some =
bugs in the specification. It would be a shame to have a normative =
reference to a spec with known bugs.

Michael Kay
Saxonica

> On 18 Jan 2022, at 18:16, Tim Bray  wrote:
>=20
> Co-chair hat on: At our interim meeting earlier today, we got a strong =
sense that the jsonpath WG has consensus in favor of allowing regular =
expressions in jsonpath filters, but that for this to be useful, the =
flavor of regexps needs to be specified precisely, and that flavor =
should be limited enough in scope to allow interoperation across as many =
as possible different regex libraries.=20
>=20
> Carsten Bormann has done the work of proposing such a small-scope =
regexp specification. The draft may be read at =
https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html =

> and is on GitHub at https://github.com/cabo/iregexp =

>=20
> If you have any issues to raise or objections to this, please let the =
WG know.
> --=20
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath


--Apple-Mail=_FEFF1248-4123-4E6D-AC93-A14CE90C572A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I =
would suggest referencing XSD 1.1 rather than XSD 1.0.

The only difference in the regex =
capabilities is that XSD 1.1 fixes some bugs in the specification. It =
would be a shame to have a normative reference to a spec with known =
bugs.

Michael =
Kay
Saxonica

On 18 =
Jan 2022, at 18:16, Tim Bray <tbray@textuality.com> wrote:

Co-chair=
 hat on: At our interim meeting earlier today, we got a strong sense =
that the jsonpath WG has consensus in favor of allowing regular =
expressions in jsonpath filters, but that for this to be useful, the =
flavor of regexps needs to be specified precisely, and that flavor =
should be limited enough in scope to allow interoperation across as many =
as possible different regex libraries. 

Carsten Bormann has done the work of proposing =
such a small-scope regexp specification. The draft may be read =
at https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-=
02.html
and is on GitHub at https://github.com/cabo/iregexp

If=
 you have any issues to raise or objections to this, please let the WG =
know.

-- 
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

=

--Apple-Mail=_FEFF1248-4123-4E6D-AC93-A14CE90C572A--


From nobody Tue Jan 18 11:10:44 2022
Return-Path: 
X-Original-To: jsonpath@ietf.org
Delivered-To: jsonpath@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 545343A11E2; Tue, 18 Jan 2022 11:10:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: francesca.palombini@ericsson.com, james.ietf@gmail.com, jsonpath-chairs@ietf.org, jsonpath@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.42.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164253304154.23465.6558290921368083916@ietfa.amsl.com>
Date: Tue, 18 Jan 2022 11:10:42 -0800
Archived-At: 
Subject: [Jsonpath] jsonpath - Not having a session at IETF 113
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 19:10:42 -0000

James Gruessing, a chair of the jsonpath working group, indicated that the jsonpath working group does not plan to hold a session at IETF 113.

This message was generated and sent by the IETF Meeting Session Request Tool.




From nobody Tue Jan 18 12:19:05 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942D03A146A for ; Tue, 18 Jan 2022 12:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jT2uOpYRueK for ; Tue, 18 Jan 2022 12:18:59 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 E2E1B3A1468 for ; Tue, 18 Jan 2022 12:18:58 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id f21so490067eds.11 for ; Tue, 18 Jan 2022 12:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=DGh2fjxy9xAVjy2dBCGSQ7NV/MUyXA6npkIwqXHJHcQ=; b=dBc3MIJCDM7LWfXVPiTcG5XlPfvH/6vTHUwzvM/3h+J92nMKXrVEkU6MVJwuRUzYqD lkZe3utuAHbT2/jaygDasFGZI5JFs4T1NFapaRkflThSpUsMCXyFELCSIHX6/AWv0bA5 YP9FN6GW/Wna/DXumN5zGyVbeLeuAiYhLEWdf0cgkkG+wudlbn8pr8odlDYJEWqE74Jq 2suIuX6k+5GL6lLUyomaObczc6+olVuo1GAsDWmmbLf6gyx5zncyd7YrfKW70bxJdbw3 piC9ZkrCxkboWoYd+Lpa0jkQUK4hHxq7pOT9ctXa99YRneDydwX84/LnDB+OZY8Oz/jb +QNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=DGh2fjxy9xAVjy2dBCGSQ7NV/MUyXA6npkIwqXHJHcQ=; b=EJtAABoMeqXYfh6uMMFbF6w7UaUpTAqhrXlz7Y9bQ5EpeKv+wPocCCkHJNcM72dm7d kYCVA9iVv8BqKsGRa/zYjWOdcGQhKGeg4vQlXQDJLPilu1AQrKcjfm4dE41ICFVA1m52 8fDMb2DtXf29se5rIDnThGZPPDYGVchNlYVpM0a82sFnrH+asRUKQh2C8/PyjkRwpLRj aW2rZD+yaHlZGlaPLTM4wblupEe0z+Bx/8X6r9/cNhiFGEFia7Rdpc6I1sZk7z3/bTuP LBYU1dQQ/OglFI8OmkazhLOxakA0StZEA4wBPyD2NYEVX8v+jC6XbE1CaFUb/ktlmrY5 mJ3w==
X-Gm-Message-State: AOAM531YHXnqrPndey8C77S+hyZDQXoJc39HtCPjDUhV/IjVS0sDz0NK /tLe4KkSPY8Wk7fdrz3NF3YJ/0K6KP9cqg==
X-Google-Smtp-Source: ABdhPJwveqpt/THmRklXGZcXJxqhnbu9e05b9BXwj47WQOpjCt60kTV97Rq/sDxsyKm5kNEUCKgFfg==
X-Received: by 2002:a17:906:65c8:: with SMTP id z8mr23232576ejn.727.1642537136575;  Tue, 18 Jan 2022 12:18:56 -0800 (PST)
Received: from smtpclient.apple ([2001:984:65b0:1:3947:4d35:403a:f676]) by smtp.gmail.com with ESMTPSA id d2sm273164edy.86.2022.01.18.12.18.56 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jan 2022 12:18:56 -0800 (PST)
From: James 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Message-Id: <25C644CB-9D0A-472B-A2A3-2F8F297D398A@gmail.com>
Date: Tue, 18 Jan 2022 21:18:55 +0100
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: [Jsonpath] March 2022 interim meeting pool
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 20:19:04 -0000

Thank you to everyone who attended our interim meeting today. Minutes =
and actions captured will be sent out in the coming days.

As announced by the system earlier, we won't be having a meeting at IETF =
113 but instead will be having an interim meeting in early March.

The poll is here https://doodle.com/poll/g9ag99g4knzc4bdy and we'll =
leave it open until February 1st. If this isn=E2=80=99t feasible for =
you, please let us know and we can discuss or expand the polling.

Thanks

Tim & James
JSONPath Chairs=


From nobody Tue Jan 18 12:19:14 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173A33A146A for ; Tue, 18 Jan 2022 12:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 sAXsw1kJyaLh for ; Tue, 18 Jan 2022 12:19:08 -0800 (PST)
Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 8CFCF3A146C for ; Tue, 18 Jan 2022 12:19:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642537146; bh=VxgZVAJc9gJFKbNpGbaUXSyEUStZkcXCMLhWHy19xYk=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=bCPLN1kaHGTyPjkz3z4/RP8ynDbND6W5S6U1nnDoau9hecv0kI2n8Ls53OapTSNSKS5BjTYpFTXB8nLIfmF8Tfjtjm2Sp12WgHgLZanYjXbrxlBIVJdb8bsCoc5WXbGgJ1G2FdeXqxS/A0+gaVdh/EC3xHLwxqsU+DJuVQ710JM1T1EBzYVmqvIkCxHYcD8d224q0QaZtblW4EqAh6IPu1Y7RcilImP84p3Um8oqFwUWhm01BByMD5iJLTr7tOcZP/TjuIHBYr228ebmvOHfnGyrvr2UNwPtVVzMChz0mTzmfWOn2dYl/C2C4+xK3lLHTXCc+R36p9TMJ0S5p7w64Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1642537146; bh=0nNKSDucsaG8jfO1dk8N2APlu5e1D1prZX/HuP/2fIK=;  h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=DZt0gs8fNur1CVfi6EDQeORIhbKxiDNHuaWoErh68xdkjxp/eu7VHW4HVFK0taviiGfjjSTUNJ3J6xwnFlLFzaiWYvXxYq25oO6eQ8mYhS+Q0e4aiG63yzc0+zy9Wx7nYtHqUkFt4dPlgVZkI0ZToaUm5BP7/+U9nRt0B0dRir50qjW3o6ZN1bmngXZ5Jq2nggFBQ34+Jmo6J8lUecQ2/cm0AUaeAe8a7M6pklnH+QIoAQL5LhcoITaByL5kdMRyRYPnSbTQxQ9my39VB27mZzid0yuZjQ2deq3aM3QIKQN7i47OVrlGmwbaAA0BbPmOJOqdIwYoWrV7Eh4kDYLNDQ==
X-YMail-OSG: KSnS8z8VM1kpHB.gMovg7G9rRzev.5J0HdBZ.febmcux0pgsuKTmifdszMMv9s5 h9v4G3us_oTHJRN9__SpEPcCVNPjk.ZBILI4Ky720gUbo5n1jOl2gIRj87LLrSExMmrb9wpdNpG2 kXHhkYaQIH_tgKdkqUv.L0M4fjTC5grS_1T4xK5Fqfe0RDophHk5fte.ZYoHHZ7C.jnLUe8DIuKq 9okt2.vh6XzUijz9KLeHUBRe3h44SuAbZ.4.iBWkX2PTkGWTEtL00wwDLVrmFTwRcO5wLojGJRH6 0YRwjlb4v.QcFR1vVCB5gvBhsNjUlX3HAZQhEvnNGCuptX8RSat209pUsrGJn7fFiZAg7SEXjwey Y9dCLrg7BBtouNu8CwiOLZ0ONYC4QI6Bka0tMW.U91f7SK2WeR8yXAyiBtEL.EPL9P3joSPRrvHq VDjQcN8QWemOUFLh7AeS_JrjHTVDkyyfLnjlTVfwxnXmoTCEUn1BfzcbRpkm.GjrTbs90HUNbhX8 8MjecvpTyUbU7xuXjO_hrbNGVSGqvVQKa5r_DQuAzVd7Qt6hkKFgLbZ7Hyj6jRTOekRAU3_Cb1A0 7.iOc2VugspX2jR9GSz9p94sMMtkvaZJ_VcDAcwYCEsMdbWISSfwWjzd5rxd5kHHa4nXDSpOaAlk FH4TIMea8fspzMuA6Fqric3Y0qaLOUmf_KhLYP6qw26EtvAVsEXIICFYv4oY8IT7.QA9Y9qUVRLZ uMfC9moyZIr1hrkDccmxSJ.hzn9dfTebNHv6CxauDDH_lovLJ.TF49H0AYG9TiunVVgCQ5ofZk8A 3ntsYNDY8cNyk9w2UnGkZMSTiyRDRZQvrE9jN9RYIZOhL0uKCCVeIZQNFMV11zc.kOdCs2oPR9Cd 9txu9s3beR9ADOCRpC1ywmyhkxK3OsDyXn6xJFU0KEezkvReUTHcCT6KqGNrF5nVdXYEbU8ZUoy4 8OzYK.Ll85SgCVbkNUmHGu4yYoPEWURTG3Zf8OY0xH2Qw.1KG6.h8Q1OJYIz1chD94NBI_Cd5H.a tuEDIB.VcKEStLNqV_mCOAMNe8TRHU9gfM8hsoyVTIWYlBvAdBU59AazcMoB7Olqq.DjG9zMQGGx nsJjCgYlIgZUMvEmXGrYH6X70vtunV2ID.hp0dl38uxKWx3E6Yh_MWnmVfqHpby_Vw.QpzWw0ind ZV4w5qQtyenaJ.l9wSjJEQ5dq0nKZG957svnw.2qSiDAGqqKEY12w72J3xmbikggmXcLfhY8BhYk 8ZIMexDzHqWpfGBsWF_FOcLgNWAUcKrwj1h0DDL0jzXjDdB.lSrEYxCFDb2HylGA5zQEjlOX50OL JWHS8BtPzxExp8hVnW62V_Jk3F2mjZLsbDFDy9v8fZ1kU3bs8YXka6D0onmES4XOsWGWJH3y9hKo jQ0oRU.nStOfe5zR201WWwQWTeABBETu3T1TzoDTwZc7YXsnMzIBjI_GlbVbgcnBhPd8lqtawmgI OWgpB9Le8ZtJktB90lz9a.13ImkWLX_kYGRarVwik5x5rvbPk7iwKy2QZJGkwl3pOjo4p3d1.CWX bR9FYllBy_ygF3bQq8y2n9.t8zmJLuSnw_jEB_JKYa0tR33kru4Bw4gm2S.Vge97zTrNpwODCmHo jTgo2U58mIlAfBXeZTcnDzDIZGH_.fvD2fRT2OskdUTxqWFmA4wtcAsrcFJZfu3JLYAkuFvPXi49 rZJjOJmksu3GQLrPkEEbSyiTg.yfkb3XiLZacImxco4Y2ArWKCNwgl9O05gVTGXu6CkSmaJMklik qBeDPPRHoFaGVycQAB.AtLrADwMaPCQc1Cdxxdk_wVZofcPQ165NDydAfvevOK9OzjnxrP_TCwqr RcZDY28VXbGD6gGBDZULaIdC7BsoHCcWMGcu4xGDbzNdeF6P.QqsDiglNKlRf.FmC2tHHf_rrfGi ZdWqOYZuUDPA8sQQqG83gVormGCF3rZRw6.JvJwVnmMNPTkoRQsKC2_.7KAgbZm.KIrbuNrLohff dPjjjtL7TuXZbqXThP4ZV8zrL8zG.VD7bja1xYGCG5djP6gxB1FZrSSFxFMoacSteKZL8MZZGZWY 2N2qzOusGrsbHBp6jK5jzvgI9gYPTmfu_8EUPN.cfFCC76JSxDgNLfzHu3SAAzXFbrBsvB6GFVfm gsDN4SLmDnNfy44WIfeEZkL27TwZYeO2YZnO2ru_NVl4BVgMCjJWgaM1JYnaCH3FPb9HuoBZC8JW 6rHw4Z8FrWfv4WiZ1EJSKcRS8D3sQBf6_9r4cLdh4wGgMWB5TWNWeQafMcyho7g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 18 Jan 2022 20:19:06 +0000
Date: Tue, 18 Jan 2022 20:19:01 +0000 (UTC)
From: Greg Dennis 
To: "jsonpath@ietf.org" , Tim Bray 
Message-ID: <1290004912.869539.1642537141570@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_869538_1359156183.1642537141568"
X-Mailer: WebService/1.1.19594 YMailNorrin
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Jan 2022 20:19:13 -0000

------=_Part_869538_1359156183.1642537141568
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 This is great.=C2=A0 I've also opened a discussion (https://github.com/jso=
n-schema-org/community/discussions/136) with the JSON Schema group to see i=
f they're open to joining this effort and eventually adopting this small-sc=
ope spec for that functionality as well.
Greg

    On Wednesday, January 19, 2022, 07:17:17 AM GMT+13, Tim Bray  wrote: =20
=20
 Co-chair hat on: At our interim meeting earlier today, we got a strong sen=
se that the jsonpath WG has consensus in favor of allowing regular expressi=
ons in jsonpath filters, but that for this to be useful, the flavor of rege=
xps needs to be specified precisely, and that flavor should be limited enou=
gh in scope to allow interoperation across as many as possible different re=
gex libraries.=C2=A0
Carsten Bormann has done the work of proposing such a small-scope regexp=C2=
=A0specification. The draft may be read at=C2=A0https://www.ietf.org/archiv=
e/id/draft-bormann-jsonpath-iregexp-02.htmland is on GitHub at=C2=A0https:/=
/github.com/cabo/iregexp

If you have any issues to raise or objections to this, please let the WG kn=
ow.--=20
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
 =20
------=_Part_869538_1359156183.1642537141568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        
This is great.  I've al=
so opened a discussion (https:/=
/github.com/json-schema-org/community/discussions/136) with the JSON Sc=
hema group to see if they're open to joining this effort and eventually ado=
pting this small-scope spec for that functionality as well.

Greg



       =20
        

            

               =20
                

                    On Wednesday, January 19, 2022, 07:17:17 AM GMT+13, Tim=
 Bray <tbray@textuality.com> wrote:
                

                


                


                
=

Co-chair hat on: At our interim meeting earlier today, we got a strong=
 sense that the jsonpath WG has consensus in favor of allowing regular expr=
essions in jsonpath filters, but that for this to be useful, the flavor of =
regexps needs to be specified precisely, and that flavor should be limited =
enough in scope to allow interoperation across as many as possible differen=
t regex libraries. 

Carsten Bormann has done =
the work of proposing such a small-scope regexp specification. The dra=
ft may be read at https://w=
ww.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
and is on GitHub at https://github.com/cabo/iregexp

If you have any issues to raise or objections to this=
, please let the WG know.


-- 
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

            

        

------=_Part_869538_1359156183.1642537141568--


From nobody Wed Jan 19 09:07:13 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AADA3A1413 for ; Wed, 19 Jan 2022 09:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level: 
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=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=textuality-com.20210112.gappssmtp.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 8b-5r9yR4pKi for ; Wed, 19 Jan 2022 09:07:06 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4C4B53A1408 for ; Wed, 19 Jan 2022 09:07:05 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id j23so10315389edp.5 for ; Wed, 19 Jan 2022 09:07:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iq4kwYgiWXYWJf9ej+cdDGRt4oAwxZK9gqGKl467kBc=; b=DRthu9CfZX/IxtK7BWtmyiV6ySX0KMt4r5+Z+woTon4HE5AITHhJ1zX9MCb/ulWxWl HKztFMb2HoJoGCo5ccHGc7OIo7yzT9Ygf8TAH33krl63FyvTzRniqtnSNv/UC/P3GN2v /dlP5iUm7I6BGklM4yu+j3bMwpsUQnHVGzIZTrbAxZ7eWTwLY3Zdku3NwFLZCu/XL+Qc F9CGe5OnsDdjr5VpyODPbkk/VJbXOoPKcXLww58qWaX33K17xt//ex+8pRKOnIyK1Vyx xff/S8+yYPtCVCIazfzytWZOhgYO1QIMKPkQ6gmy2ScB7KCBi/i4+DlpNwPnlZ3EGqLj anVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iq4kwYgiWXYWJf9ej+cdDGRt4oAwxZK9gqGKl467kBc=; b=1P4WWb3RgupGRdlH7IbAEqWU4twYzmKNYje4lA0yrI/F+XF152dDlewty+Ex5PaxzQ J9fqgjCsxHAKPe1UTwKoaT/vQnrqkt9MFRN/SP7FP2oK1ZZilDs6WSkjxGmfIuEAj7rc 6gzxWGTvsrRm2fWTd4wS020UmTi71+dIxBo0MVdVZe1Bx54q5b9EiZJIw4Nx0FVL4fl9 VxQikRI979jcR8KHUvkA8QyoUCoOGH5RBn8pABaMr99lKGaz+i5f2u5WpvIvnyiBfd1m xLNWgEIz1PEUKf64wB+8TwEvqKGE7XwFDq7SRikv8aRi5+cRp6eMLKp3wIvQgsMwwRkj 8F6Q==
X-Gm-Message-State: AOAM532AXyjOLcenphR21mlFoPWpo+pWLtCxTmRcjvRW6t3rLO4hJ7MW 1kE3/5vZ4GmNHchhMlAXNwhR4oejvKkjx3zPmG5OoS/j1xjmSXw7
X-Google-Smtp-Source: ABdhPJwawo6juUOm3hkFx8jCFGgKgjCzI+oCGlbAhCWy7IH86bP6w+oEzkG6WwKmIfVWepVVRP4jml/yxoxGxfT4dE4=
X-Received: by 2002:ac2:4568:: with SMTP id k8mr21561842lfm.338.1642612022606;  Wed, 19 Jan 2022 09:07:02 -0800 (PST)
MIME-Version: 1.0
References:  <1290004912.869539.1642537141570@mail.yahoo.com>
In-Reply-To: <1290004912.869539.1642537141570@mail.yahoo.com>
From: Tim Bray 
Date: Wed, 19 Jan 2022 09:06:51 -0800
Message-ID: 
To: Greg Dennis 
Cc: "jsonpath@ietf.org" 
Content-Type: multipart/mixed; boundary="0000000000001cbe2a05d5f26a22"
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Jan 2022 17:07:12 -0000

--0000000000001cbe2a05d5f26a22
Content-Type: multipart/alternative; boundary="0000000000001cbe2705d5f26a20"

--0000000000001cbe2705d5f26a20
Content-Type: text/plain; charset="UTF-8"

Oh, an update: I sent a big PR yesterday reorganizing the draft while
preserving more or less all of its content:
https://github.com/cabo/iregexp/pull/1 and I just saw Carsten merged it.
For convenience, I've attached what the HTML now looks like.

On Tue, Jan 18, 2022 at 12:19 PM Greg Dennis  wrote:

> This is great.  I've also opened a discussion (
> https://github.com/json-schema-org/community/discussions/136) with the
> JSON Schema group to see if they're open to joining this effort and
> eventually adopting this small-scope spec for that functionality as well.
>
> Greg
>
>
> On Wednesday, January 19, 2022, 07:17:17 AM GMT+13, Tim Bray <
> tbray@textuality.com> wrote:
>
>
> Co-chair hat on: At our interim meeting earlier today, we got a strong
> sense that the jsonpath WG has consensus in favor of allowing regular
> expressions in jsonpath filters, but that for this to be useful, the flavor
> of regexps needs to be specified precisely, and that flavor should be
> limited enough in scope to allow interoperation across as many as possible
> different regex libraries.
>
> Carsten Bormann has done the work of proposing such a small-scope
> regexp specification. The draft may be read at
> https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
> and is on GitHub at https://github.com/cabo/iregexp
>
> If you have any issues to raise or objections to this, please let the WG
> know.
> --
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>

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


Oh,=
 an update: I sent a big PR yesterday reorganizing the draft while preservi=
ng more or less all of its content:=C2=A0https://github.com/cabo/iregexp/pull/1 and I just saw =
Carsten merged it.=C2=A0 For convenience, I've attached what the HTML n=
ow looks like.

On Tue, Jan 18, 2022 at 12:19 PM Greg Dennis <gregsdennis@yahoo.com> wrote:
=


        
This is great.=C2=A0 I've also opened a discus=
sion (https://github.com/json-schema-org/c=
ommunity/discussions/136) with the JSON Schema group to see if they'=
;re open to joining this effort and eventually adopting this small-scope sp=
ec for that functionality as well.

Greg



       =20
        

            

               =20
                

                    On Wednesday, January 19, 2022, 07:17:17 AM GMT+13, Tim=
 Bray <tbray@t=
extuality.com> wrote:
                

                


                


                
Co-chair hat on: =
At our interim meeting earlier today, we got a strong sense that the jsonpa=
th WG has consensus in favor of allowing regular expressions in jsonpath fi=
lters, but that for this to be useful, the flavor of regexps needs to be sp=
ecified precisely, and that flavor should be limited enough in scope to all=
ow interoperation across as many as possible different regex libraries.=C2=
=A0

Carsten Bormann has done the work of proposing such a small-scope reg=
exp=C2=A0specification. The draft may be read at=C2=A0https://www.ietf.org/archive/id/draft-bormann-jsonpat=
h-iregexp-02.html
and is on GitHub =
at=C2=A0https://github.com/cabo/iregexp

If you have any issue=
s to raise or objections to this, please let the WG know.


-- 
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

            

        


--0000000000001cbe2705d5f26a20--

--0000000000001cbe2a05d5f26a22
Content-Type: text/html; charset="UTF-8";
 name="draft-bormann-jsonpath-iregexp.html"
Content-Disposition: attachment; 
 filename="draft-bormann-jsonpath-iregexp.html"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_kylsrqb70

PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIiBjbGFzcz0iSW50ZXJuZXQtRHJhZnQiPgo8
aGVhZD4KPG1ldGEgY2hhcnNldD0idXRmLTgiPgo8bWV0YSBjb250ZW50PSJDb21tb24sTGF0aW4i
IG5hbWU9InNjcmlwdHMiPgo8bWV0YSBjb250ZW50PSJpbml0aWFsLXNjYWxlPTEuMCIgbmFtZT0i
dmlld3BvcnQiPgo8dGl0bGU+SS1SZWdleHA6IEFuIEludGVyb3BlcmFibGUgUmVnZXhwIEZvcm1h
dDwvdGl0bGU+CjxtZXRhIGNvbnRlbnQ9IkNhcnN0ZW4gQm9ybWFubiIgbmFtZT0iYXV0aG9yIj4K
PG1ldGEgY29udGVudD0iCiAgICAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBJLVJlZ2V4cCwg
YSBmbGF2b3Igb2YgcmVndWxhciBleHByZXNzaW9ucyB0aGF0IGlzCmxpbWl0ZWQgaW4gc2NvcGUg
d2l0aCB0aGUgZ29hbCBvZiBpbnRlcm9wZXJhdGlvbiBhY3Jvc3MgbWFueSBkaWZmZXJlbnQKcmVn
dWxhci1leHByZXNzaW9uIGxpYnJhcmllcy4gCiAgICAiIG5hbWU9ImRlc2NyaXB0aW9uIj4KPG1l
dGEgY29udGVudD0ieG1sMnJmYyAzLjEyLjAiIG5hbWU9ImdlbmVyYXRvciI+CjxtZXRhIGNvbnRl
bnQ9IkludGVybmV0LURyYWZ0IiBuYW1lPSJrZXl3b3JkIj4KPG1ldGEgY29udGVudD0iZHJhZnQt
Ym9ybWFubi1qc29ucGF0aC1pcmVnZXhwLWxhdGVzdCIgbmFtZT0iaWV0Zi5kcmFmdCI+CjwhLS0g
R2VuZXJhdG9yIHZlcnNpb24gaW5mb3JtYXRpb246CiAgeG1sMnJmYyAzLjEyLjAKICAgIFB5dGhv
biAzLjkuNwogICAgYXBwZGlycyAxLjQuNAogICAgQ29uZmlnQXJnUGFyc2UgMS41LjMKICAgIGdv
b2dsZS1pMThuLWFkZHJlc3MgMi41LjAKICAgIGh0bWw1bGliIDEuMQogICAgaW50ZXJ2YWx0cmVl
IDMuMS4wCiAgICBKaW5qYTIgMi4xMS4zCiAgICBraXRjaGVuIDEuMi42CiAgICBseG1sIDQuNy4x
CiAgICBweWNvdW50cnkgMjIuMS4xMAogICAgcHlmbGFrZXMgMi40LjAKICAgIFB5WUFNTCA2LjAK
ICAgIHJlcXVlc3RzIDIuMjcuMQogICAgc2V0dXB0b29scyA1Ny40LjAKICAgIHNpeCAxLjE2LjAK
LS0+CjxsaW5rIGhyZWY9ImRyYWZ0LWJvcm1hbm4tanNvbnBhdGgtaXJlZ2V4cC54bWwiIHJlbD0i
YWx0ZXJuYXRlIiB0eXBlPSJhcHBsaWNhdGlvbi9yZmMreG1sIj4KPGxpbmsgaHJlZj0iI2NvcHly
aWdodCIgcmVsPSJsaWNlbnNlIj4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj5AZm9udC1mYWNlIHsK
ICBmb250LWZhbWlseTogJ0xvcmEnOwogIGZvbnQtc3R5bGU6IGl0YWxpYzsKICBmb250LXdlaWdo
dDogNDAwOwogIGZvbnQtZGlzcGxheTogc3dhcDsKICBzcmM6IGxvY2FsKCdMb3JhIEl0YWxpYycp
LCBsb2NhbCgnTG9yYS1JdGFsaWMnKSwgdXJsKCdodHRwczovL21hcnRpbnRob21zb24uZ2l0aHVi
LmlvL3JmYy1jc3MvZm9udHMvbG9yYS1pdGFsaWMtY3lyaWxsaWMtZXh0LndvZmYyJykgZm9ybWF0
KCd3b2ZmMicpOwogIHVuaWNvZGUtcmFuZ2U6IFUrMDQ2MC0wNTJGLCBVKzFDODAtMUM4OCwgVSsy
MEI0LCBVKzJERTAtMkRGRiwgVStBNjQwLUE2OUYsIFUrRkUyRS1GRTJGOwp9CkBmb250LWZhY2Ug
ewogIGZvbnQtZmFtaWx5OiAnTG9yYSc7CiAgZm9udC1zdHlsZTogaXRhbGljOwogIGZvbnQtd2Vp
Z2h0OiA0MDA7CiAgZm9udC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgSXRhbGlj
JyksIGxvY2FsKCdMb3JhLUl0YWxpYycpLCB1cmwoJ2h0dHBzOi8vbWFydGludGhvbXNvbi5naXRo
dWIuaW8vcmZjLWNzcy9mb250cy9sb3JhLWl0YWxpYy1jeXJpbGxpYy1leHQud29mZjInKSBmb3Jt
YXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTogVSswNDAwLTA0NUYsIFUrMDQ5MC0wNDkxLCBV
KzA0QjAtMDRCMSwgVSsyMTE2Owp9CkBmb250LWZhY2UgewogIGZvbnQtZmFtaWx5OiAnTG9yYSc7
CiAgZm9udC1zdHlsZTogaXRhbGljOwogIGZvbnQtd2VpZ2h0OiA0MDA7CiAgZm9udC1kaXNwbGF5
OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgSXRhbGljJyksIGxvY2FsKCdMb3JhLUl0YWxpYycp
LCB1cmwoJ2h0dHBzOi8vbWFydGludGhvbXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250cy9sb3Jh
LWl0YWxpYy12aWV0bmFtZXNlLndvZmYyJykgZm9ybWF0KCd3b2ZmMicpOwogIHVuaWNvZGUtcmFu
Z2U6IFUrMDEwMi0wMTAzLCBVKzAxMTAtMDExMSwgVSsxRUEwLTFFRjksIFUrMjBBQjsKfQpAZm9u
dC1mYWNlIHsKICBmb250LWZhbWlseTogJ0xvcmEnOwogIGZvbnQtc3R5bGU6IGl0YWxpYzsKICBm
b250LXdlaWdodDogNDAwOwogIGZvbnQtZGlzcGxheTogc3dhcDsKICBzcmM6IGxvY2FsKCdMb3Jh
IEl0YWxpYycpLCBsb2NhbCgnTG9yYS1JdGFsaWMnKSwgdXJsKCdodHRwczovL21hcnRpbnRob21z
b24uZ2l0aHViLmlvL3JmYy1jc3MvZm9udHMvbG9yYS1pdGFsaWMtbGF0aW4tZXh0LndvZmYyJykg
Zm9ybWF0KCd3b2ZmMicpOwogIHVuaWNvZGUtcmFuZ2U6IFUrMDEwMC0wMjRGLCBVKzAyNTksIFUr
MUUwMC0xRUZGLCBVKzIwMjAsIFUrMjBBMC0yMEFCLCBVKzIwQUQtMjBDRiwgVSsyMTEzLCBVKzJD
NjAtMkM3RiwgVStBNzIwLUE3RkY7Cn0KCkBmb250LWZhY2UgewogIGZvbnQtZmFtaWx5OiAnTG9y
YSc7CiAgZm9udC1zdHlsZTogaXRhbGljOwogIGZvbnQtd2VpZ2h0OiA0MDA7CiAgZm9udC1kaXNw
bGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgSXRhbGljJyksIGxvY2FsKCdMb3JhLUl0YWxp
YycpLCB1cmwoJ2h0dHBzOi8vbWFydGludGhvbXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250cy9s
b3JhLWl0YWxpYy1sYXRpbi53b2ZmMicpIGZvcm1hdCgnd29mZjInKTsKICB1bmljb2RlLXJhbmdl
OiBVKzAwMDAtMDBGRiwgVSswMTMxLCBVKzAxNTItMDE1MywgVSswMkJCLTAyQkMsIFUrMDJDNiwg
VSswMkRBLCBVKzAyREMsIFUrMjAwMC0yMDZGLCBVKzIwNzQsIFUrMjBBQywgVSsyMTIyLCBVKzIx
OTEsIFUrMjE5MywgVSsyMjEyLCBVKzIyMTUsIFUrRkVGRiwgVStGRkZEOwp9CkBmb250LWZhY2Ug
ewogIGZvbnQtZmFtaWx5OiAnTG9yYSc7CiAgZm9udC1zdHlsZTogbm9ybWFsOwogIGZvbnQtd2Vp
Z2h0OiA0MDA7CiAgZm9udC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgUmVndWxh
cicpLCBsb2NhbCgnTG9yYS1SZWd1bGFyJyksIHVybCgnaHR0cHM6Ly9tYXJ0aW50aG9tc29uLmdp
dGh1Yi5pby9yZmMtY3NzL2ZvbnRzL2xvcmEtcmVndWxhci1jeXJpbGxpYy1leHQud29mZjInKSBm
b3JtYXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTogVSswNDYwLTA1MkYsIFUrMUM4MC0xQzg4
LCBVKzIwQjQsIFUrMkRFMC0yREZGLCBVK0E2NDAtQTY5RiwgVStGRTJFLUZFMkY7Cn0KQGZvbnQt
ZmFjZSB7CiAgZm9udC1mYW1pbHk6ICdMb3JhJzsKICBmb250LXN0eWxlOiBub3JtYWw7CiAgZm9u
dC13ZWlnaHQ6IDQwMDsKICBmb250LWRpc3BsYXk6IHN3YXA7CiAgc3JjOiBsb2NhbCgnTG9yYSBS
ZWd1bGFyJyksIGxvY2FsKCdMb3JhLVJlZ3VsYXInKSwgdXJsKCdodHRwczovL21hcnRpbnRob21z
b24uZ2l0aHViLmlvL3JmYy1jc3MvZm9udHMvbG9yYS1yZWd1bGFyLWN5cmlsbGljLndvZmYyJykg
Zm9ybWF0KCd3b2ZmMicpOwogIHVuaWNvZGUtcmFuZ2U6IFUrMDQwMC0wNDVGLCBVKzA0OTAtMDQ5
MSwgVSswNEIwLTA0QjEsIFUrMjExNjsKfQpAZm9udC1mYWNlIHsKICBmb250LWZhbWlseTogJ0xv
cmEnOwogIGZvbnQtc3R5bGU6IG5vcm1hbDsKICBmb250LXdlaWdodDogNDAwOwogIGZvbnQtZGlz
cGxheTogc3dhcDsKICBzcmM6IGxvY2FsKCdMb3JhIFJlZ3VsYXInKSwgbG9jYWwoJ0xvcmEtUmVn
dWxhcicpLCB1cmwoJ2h0dHBzOi8vbWFydGludGhvbXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250
cy9sb3JhLXJlZ3VsYXItdmlldG5hbWVzZS53b2ZmMicpIGZvcm1hdCgnd29mZjInKTsKICB1bmlj
b2RlLXJhbmdlOiBVKzAxMDItMDEwMywgVSswMTEwLTAxMTEsIFUrMUVBMC0xRUY5LCBVKzIwQUI7
Cn0KQGZvbnQtZmFjZSB7CiAgZm9udC1mYW1pbHk6ICdMb3JhJzsKICBmb250LXN0eWxlOiBub3Jt
YWw7CiAgZm9udC13ZWlnaHQ6IDQwMDsKICBmb250LWRpc3BsYXk6IHN3YXA7CiAgc3JjOiBsb2Nh
bCgnTG9yYSBSZWd1bGFyJyksIGxvY2FsKCdMb3JhLVJlZ3VsYXInKSwgdXJsKCdodHRwczovL21h
cnRpbnRob21zb24uZ2l0aHViLmlvL3JmYy1jc3MvZm9udHMvbG9yYS1yZWd1bGFyLWxhdGluLWV4
dC53b2ZmMicpIGZvcm1hdCgnd29mZjInKTsKICB1bmljb2RlLXJhbmdlOiBVKzAxMDAtMDI0Riwg
VSswMjU5LCBVKzFFMDAtMUVGRiwgVSsyMDIwLCBVKzIwQTAtMjBBQiwgVSsyMEFELTIwQ0YsIFUr
MjExMywgVSsyQzYwLTJDN0YsIFUrQTcyMC1BN0ZGOwp9CkBmb250LWZhY2UgewogIGZvbnQtZmFt
aWx5OiAnTG9yYSc7CiAgZm9udC1zdHlsZTogbm9ybWFsOwogIGZvbnQtd2VpZ2h0OiA0MDA7CiAg
Zm9udC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgUmVndWxhcicpLCBsb2NhbCgn
TG9yYS1SZWd1bGFyJyksIHVybCgnaHR0cHM6Ly9tYXJ0aW50aG9tc29uLmdpdGh1Yi5pby9yZmMt
Y3NzL2ZvbnRzL2xvcmEtcmVndWxhci1sYXRpbi53b2ZmMicpIGZvcm1hdCgnd29mZjInKTsKICB1
bmljb2RlLXJhbmdlOiBVKzAwMDAtMDBGRiwgVSswMTMxLCBVKzAxNTItMDE1MywgVSswMkJCLTAy
QkMsIFUrMDJDNiwgVSswMkRBLCBVKzAyREMsIFUrMjAwMC0yMDZGLCBVKzIwNzQsIFUrMjBBQywg
VSsyMTIyLCBVKzIxOTEsIFUrMjE5MywgVSsyMjEyLCBVKzIyMTUsIFUrRkVGRiwgVStGRkZEOwp9
CgpAZm9udC1mYWNlIHsKICBmb250LWZhbWlseTogJ0xvcmEnOwogIGZvbnQtc3R5bGU6IG5vcm1h
bDsKICBmb250LXdlaWdodDogNzAwOwogIGZvbnQtZGlzcGxheTogc3dhcDsKICBzcmM6IGxvY2Fs
KCdMb3JhIEJvbGQnKSwgbG9jYWwoJ0xvcmEtQm9sZCcpLCB1cmwoJ2h0dHBzOi8vbWFydGludGhv
bXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250cy9sb3JhLWJvbGQtY3lyaWxsaWMtZXh0LndvZmYy
JykgZm9ybWF0KCd3b2ZmMicpOwogIHVuaWNvZGUtcmFuZ2U6IFUrMDQ2MC0wNTJGLCBVKzFDODAt
MUM4OCwgVSsyMEI0LCBVKzJERTAtMkRGRiwgVStBNjQwLUE2OUYsIFUrRkUyRS1GRTJGOwp9CkBm
b250LWZhY2UgewogIGZvbnQtZmFtaWx5OiAnTG9yYSc7CiAgZm9udC1zdHlsZTogbm9ybWFsOwog
IGZvbnQtd2VpZ2h0OiA3MDA7CiAgZm9udC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xv
cmEgQm9sZCcpLCBsb2NhbCgnTG9yYS1Cb2xkJyksIHVybCgnaHR0cHM6Ly9tYXJ0aW50aG9tc29u
LmdpdGh1Yi5pby9yZmMtY3NzL2ZvbnRzL2xvcmEtYm9sZC1jeXJpbGxpYy53b2ZmMicpIGZvcm1h
dCgnd29mZjInKTsKICB1bmljb2RlLXJhbmdlOiBVKzA0MDAtMDQ1RiwgVSswNDkwLTA0OTEsIFUr
MDRCMC0wNEIxLCBVKzIxMTY7Cn0KQGZvbnQtZmFjZSB7CiAgZm9udC1mYW1pbHk6ICdMb3JhJzsK
ICBmb250LXN0eWxlOiBub3JtYWw7CiAgZm9udC13ZWlnaHQ6IDcwMDsKICBmb250LWRpc3BsYXk6
IHN3YXA7CiAgc3JjOiBsb2NhbCgnTG9yYSBCb2xkJyksIGxvY2FsKCdMb3JhLUJvbGQnKSwgdXJs
KCdodHRwczovL21hcnRpbnRob21zb24uZ2l0aHViLmlvL3JmYy1jc3MvZm9udHMvbG9yYS1ib2xk
LXZpZXRuYW1lc2Uud29mZjInKSBmb3JtYXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTogVSsw
MTAyLTAxMDMsIFUrMDExMC0wMTExLCBVKzFFQTAtMUVGOSwgVSsyMEFCOwp9CkBmb250LWZhY2Ug
ewogIGZvbnQtZmFtaWx5OiAnTG9yYSc7CiAgZm9udC1zdHlsZTogbm9ybWFsOwogIGZvbnQtd2Vp
Z2h0OiA3MDA7CiAgZm9udC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ0xvcmEgQm9sZCcp
LCBsb2NhbCgnTG9yYS1Cb2xkJyksIHVybCgnaHR0cHM6Ly9tYXJ0aW50aG9tc29uLmdpdGh1Yi5p
by9yZmMtY3NzL2ZvbnRzL2xvcmEtYm9sZC1sYXRpbi1leHQud29mZjInKSBmb3JtYXQoJ3dvZmYy
Jyk7CiAgdW5pY29kZS1yYW5nZTogVSswMTAwLTAyNEYsIFUrMDI1OSwgVSsxRTAwLTFFRkYsIFUr
MjAyMCwgVSsyMEEwLTIwQUIsIFUrMjBBRC0yMENGLCBVKzIxMTMsIFUrMkM2MC0yQzdGLCBVK0E3
MjAtQTdGRjsKfQpAZm9udC1mYWNlIHsKICBmb250LWZhbWlseTogJ0xvcmEnOwogIGZvbnQtc3R5
bGU6IG5vcm1hbDsKICBmb250LXdlaWdodDogNzAwOwogIGZvbnQtZGlzcGxheTogc3dhcDsKICBz
cmM6IGxvY2FsKCdMb3JhIEJvbGQnKSwgbG9jYWwoJ0xvcmEtQm9sZCcpLCB1cmwoJ2h0dHBzOi8v
bWFydGludGhvbXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250cy9sb3JhLWJvbGQtbGF0aW4ud29m
ZjInKSBmb3JtYXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTogVSswMDAwLTAwRkYsIFUrMDEz
MSwgVSswMTUyLTAxNTMsIFUrMDJCQi0wMkJDLCBVKzAyQzYsIFUrMDJEQSwgVSswMkRDLCBVKzIw
MDAtMjA2RiwgVSsyMDc0LCBVKzIwQUMsIFUrMjEyMiwgVSsyMTkxLCBVKzIxOTMsIFUrMjIxMiwg
VSsyMjE1LCBVK0ZFRkYsIFUrRkZGRDsKfQoKQGZvbnQtZmFjZSB7CiAgZm9udC1mYW1pbHk6ICdD
YWJpbiBDb25kZW5zZWQnOwogIGZvbnQtc3R5bGU6IG5vcm1hbDsKICBmb250LXdlaWdodDogNjAw
OwogIGZvbnQtZGlzcGxheTogc3dhcDsKICBzcmM6IGxvY2FsKCdDYWJpbiBDb25kZW5zZWQgU2Vt
aUJvbGQnKSwgbG9jYWwoJ0NhYmluQ29uZGVuc2VkLVNlbWlCb2xkJyksIHVybCgnaHR0cHM6Ly9t
YXJ0aW50aG9tc29uLmdpdGh1Yi5pby9yZmMtY3NzL2ZvbnRzL2NhYmluY29uZGVuc2VkLXNlbWli
b2xkLXZpZXRuYW1lc2Uud29mZjInKSBmb3JtYXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTog
VSswMTAyLTAxMDMsIFUrMDExMC0wMTExLCBVKzFFQTAtMUVGOSwgVSsyMEFCOwp9CkBmb250LWZh
Y2UgewogIGZvbnQtZmFtaWx5OiAnQ2FiaW4gQ29uZGVuc2VkJzsKICBmb250LXN0eWxlOiBub3Jt
YWw7CiAgZm9udC13ZWlnaHQ6IDYwMDsKICBmb250LWRpc3BsYXk6IHN3YXA7CiAgc3JjOiBsb2Nh
bCgnQ2FiaW4gQ29uZGVuc2VkIFNlbWlCb2xkJyksIGxvY2FsKCdDYWJpbkNvbmRlbnNlZC1TZW1p
Qm9sZCcpLCB1cmwoJ2h0dHBzOi8vbWFydGludGhvbXNvbi5naXRodWIuaW8vcmZjLWNzcy9mb250
cy9jYWJpbmNvbmRlbnNlZC1zZW1pYm9sZC1sYXRpbi1leHQud29mZjInKSBmb3JtYXQoJ3dvZmYy
Jyk7CiAgdW5pY29kZS1yYW5nZTogVSswMTAwLTAyNEYsIFUrMDI1OSwgVSsxRTAwLTFFRkYsIFUr
MjAyMCwgVSsyMEEwLTIwQUIsIFUrMjBBRC0yMENGLCBVKzIxMTMsIFUrMkM2MC0yQzdGLCBVK0E3
MjAtQTdGRjsKfQpAZm9udC1mYWNlIHsKICBmb250LWZhbWlseTogJ0NhYmluIENvbmRlbnNlZCc7
CiAgZm9udC1zdHlsZTogbm9ybWFsOwogIGZvbnQtd2VpZ2h0OiA2MDA7CiAgZm9udC1kaXNwbGF5
OiBzd2FwOwogIHNyYzogbG9jYWwoJ0NhYmluIENvbmRlbnNlZCBTZW1pQm9sZCcpLCBsb2NhbCgn
Q2FiaW5Db25kZW5zZWQtU2VtaUJvbGQnKSwgdXJsKCdodHRwczovL21hcnRpbnRob21zb24uZ2l0
aHViLmlvL3JmYy1jc3MvZm9udHMvY2FiaW5jb25kZW5zZWQtc2VtaWJvbGQtbGF0aW4ud29mZjIn
KSBmb3JtYXQoJ3dvZmYyJyk7CiAgdW5pY29kZS1yYW5nZTogVSswMDAwLTAwRkYsIFUrMDEzMSwg
VSswMTUyLTAxNTMsIFUrMDJCQi0wMkJDLCBVKzAyQzYsIFUrMDJEQSwgVSswMkRDLCBVKzIwMDAt
MjA2RiwgVSsyMDc0LCBVKzIwQUMsIFUrMjEyMiwgVSsyMTkxLCBVKzIxOTMsIFUrMjIxMiwgVSsy
MjE1LCBVK0ZFRkYsIFUrRkZGRDsKfQoKQGZvbnQtZmFjZSB7CiAgZm9udC1mYW1pbHk6ICdPeHln
ZW4gTW9ubyc7CiAgZm9udC1zdHlsZTogbm9ybWFsOwogIGZvbnQtd2VpZ2h0OiA0MDA7CiAgZm9u
dC1kaXNwbGF5OiBzd2FwOwogIHNyYzogbG9jYWwoJ094eWdlbiBNb25vJyksIGxvY2FsKCdPeHln
ZW5Nb25vLVJlZ3VsYXInKSwgdXJsKCdodHRwczovL21hcnRpbnRob21zb24uZ2l0aHViLmlvL3Jm
Yy1jc3MvZm9udHMvb3h5Z2VubW9uby1yZWd1bGFyLWxhdGluLWV4dC53b2ZmMicpIGZvcm1hdCgn
d29mZjInKTsKICB1bmljb2RlLXJhbmdlOiBVKzAxMDAtMDI0RiwgVSswMjU5LCBVKzFFMDAtMUVG
RiwgVSsyMDIwLCBVKzIwQTAtMjBBQiwgVSsyMEFELTIwQ0YsIFUrMjExMywgVSsyQzYwLTJDN0Ys
IFUrQTcyMC1BN0ZGOwp9CkBmb250LWZhY2UgewogIGZvbnQtZmFtaWx5OiAnT3h5Z2VuIE1vbm8n
OwogIGZvbnQtc3R5bGU6IG5vcm1hbDsKICBmb250LXdlaWdodDogNDAwOwogIGZvbnQtZGlzcGxh
eTogc3dhcDsKICBzcmM6IGxvY2FsKCdPeHlnZW4gTW9ubycpLCBsb2NhbCgnT3h5Z2VuTW9uby1S
ZWd1bGFyJyksIHVybCgnaHR0cHM6Ly9tYXJ0aW50aG9tc29uLmdpdGh1Yi5pby9yZmMtY3NzL2Zv
bnRzL294eWdlbm1vbm8tcmVndWxhci1sYXRpbi53b2ZmMicpIGZvcm1hdCgnd29mZjInKTsKICB1
bmljb2RlLXJhbmdlOiBVKzAwMDAtMDBGRiwgVSswMTMxLCBVKzAxNTItMDE1MywgVSswMkJCLTAy
QkMsIFUrMDJDNiwgVSswMkRBLCBVKzAyREMsIFUrMjAwMC0yMDZGLCBVKzIwNzQsIFUrMjBBQywg
VSsyMTIyLCBVKzIxOTEsIFUrMjE5MywgVSsyMjEyLCBVKzIyMTUsIFUrRkVGRiwgVStGRkZEOwp9
Cgo6cm9vdCB7CiAgY29sb3Itc2NoZW1lOiBsaWdodCBkYXJrOwogIC0tYmFja2dyb3VuZC1jb2xv
cjogI2ZmZjsKICAtLXRleHQtY29sb3I6ICMyMjI7CiAgLS10aXRsZS1jb2xvcjogIzE5MTkxOTsK
ICAtLWxpbmstY29sb3I6ICMyYTY0OTY7CiAgLS1oaWdobGlnaHQtY29sb3I6ICNmOWY5Zjk7CiAg
LS1saW5lLWNvbG9yOiAjZWVlOwogIC0tcGlsY3Jvdy13ZWFrOiAjZGRkOwogIC0tcGlsY3Jvdy1z
dHJvbmc6ICNiYmI7CiAgLS1zbWFsbC1mb250LXNpemU6IDE0LjVweDsKICAtLWZvbnQtbW9ubzog
J094eWdlbiBNb25vJywgbW9ub3NwYWNlOwogIHNjcm9sbGJhci1jb2xvcjogI2JiYiAjZWVlOwp9
CmJvZHkgewogIG1heC13aWR0aDogNjAwcHg7CiAgbWFyZ2luOiA3NXB4IGF1dG87CiAgcGFkZGlu
ZzogMCA1cHg7CiAgY29sb3I6IHZhcigtLXRleHQtY29sb3IpOwogIGJhY2tncm91bmQtY29sb3I6
IHZhcigtLWJhY2tncm91bmQtY29sb3IpOwogIGZvbnQ6IDE2cHgvMjJweCAiTG9yYSIsIHNlcmlm
OwogIHNjcm9sbC1iZWhhdmlvcjogc21vb3RoOwp9CgouZWFycyB7CiAgZGlzcGxheTogbm9uZTsK
fQoKLyogaGVhZGluZ3MgKi8KaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgZm9udC1mYW1pbHk6
ICJDYWJpbiBDb25kZW5zZWQiLCBzYW5zLXNlcmlmOwogIGZvbnQtd2VpZ2h0OiA2MDA7CiAgbWFy
Z2luOiAwLjhlbSAwIDAuM2VtOwogIGZvbnQtc2l6ZS1hZGp1c3Q6IDAuNTsKICBjb2xvcjogdmFy
KC0tdGl0bGUtY29sb3IpOwp9CmgxI3RpdGxlIHsKICBmb250LXNpemU6IDMycHg7CiAgbGluZS1o
ZWlnaHQ6IDQwcHg7CiAgY2xlYXI6IGJvdGg7Cn0KaDEjdGl0bGUsIGgxI3JmY251bSB7CiAgbWFy
Z2luOiAxLjVlbSAwIDAuMmVtOwp9CmgxI3JmY251bSArIGgxI3RpdGxlIHsKICBtYXJnaW46IDAu
MmVtIDA7Cn0KCmgxLCBoMiwgaDMgewogIGZvbnQtc2l6ZTogMjJweDsKICBsaW5lLWhlaWdodDog
MjdweDsKfQpoNCwgaDUsIGg2IHsKICBmb250LXNpemU6IDIwcHg7CiAgbGluZS1oZWlnaHQ6IDI0
cHg7Cn0KCi8qIGdlbmVyYWwgc3RydWN0dXJlICovCi5hdXRob3IgewogIHBhZGRpbmctYm90dG9t
OiAwLjNlbTsKfQojYWJzdHJhY3QrcCB7CiAgZm9udC1zaXplOiAxOHB4OwogIGxpbmUtaGVpZ2h0
OiAyNHB4Owp9CiNhYnN0cmFjdCtwIGNvZGUsICNhYnN0cmFjdCtwIHNhbXAsICNhYnN0cmFjdCtw
IHR0IHsKICBmb250LXNpemU6IDE2cHg7CiAgbGluZS1oZWlnaHQ6IDA7Cn0KCnAgewogIHBhZGRp
bmc6IDA7CiAgbWFyZ2luOiAwLjVlbSAwOwogIHRleHQtYWxpZ246IGxlZnQ7Cn0KZGl2IHsKICBt
YXJnaW46IDA7Cn0KLmFsaWduUmlnaHQuYXJ0LXRleHQgewogIGJhY2tncm91bmQtY29sb3I6IHZh
cigtLWhpZ2hsaWdodC1jb2xvcik7CiAgYm9yZGVyOiAxcHggc29saWQgdmFyKC0tbGluZS1jb2xv
cik7CiAgYm9yZGVyLXJhZGl1czogM3B4OwogIHBhZGRpbmc6IDAuNWVtIDFlbSAwOwogIG1hcmdp
bi1ib3R0b206IDAuNWVtOwp9Ci5hbGlnblJpZ2h0LmFydC10ZXh0IHByZSB7CiAgcGFkZGluZzog
MDsKICB3aWR0aDogYXV0bzsKfQouYWxpZ25SaWdodCB7CiAgbWFyZ2luOiAxZW0gMDsKfQouYWxp
Z25SaWdodCA+ICo6Zmlyc3QtY2hpbGQgewogIGJvcmRlcjogbm9uZTsKICBtYXJnaW46IDA7CiAg
ZmxvYXQ6IHJpZ2h0OwogIGNsZWFyOiBib3RoOwp9Ci5hbGlnblJpZ2h0ID4gKjpudGgtY2hpbGQo
MikgewogIGNsZWFyOiBib3RoOwogIGRpc3BsYXk6IGJsb2NrOwogIGJvcmRlcjogbm9uZTsKfQpz
dmcgewogIGRpc3BsYXk6IGJsb2NrOwp9Ci8qIGZvbnQtZmFtaWx5IGlzbid0IHNwYWNlLXNlcGFy
YXRlZCwgYnV0ID1+IHdpbGwgaGF2ZSB0byBkbyAqLwpzdmdbZm9udC1mYW1pbHl+PSJtb25vc3Bh
Y2UiIGldLCBzdmcgW2ZvbnQtZmFtaWx5fj0ibW9ub3NwYWNlIiBpXSB7CiAgZm9udC1mYW1pbHk6
IHZhcigtLWZvbnQtbW9ubyk7Cn0KLmFsaWduQ2VudGVyLmFydC10ZXh0IHsKICBiYWNrZ3JvdW5k
LWNvbG9yOiB2YXIoLS1oaWdobGlnaHQtY29sb3IpOwogIGJvcmRlcjogMXB4IHNvbGlkIHZhcigt
LWxpbmUtY29sb3IpOwogIGJvcmRlci1yYWRpdXM6IDNweDsKICBwYWRkaW5nOiAwLjVlbSAxZW0g
MDsKICBtYXJnaW4tYm90dG9tOiAwLjVlbTsKfQouYWxpZ25DZW50ZXIuYXJ0LXRleHQgcHJlIHsK
ICBwYWRkaW5nOiAwOwogIHdpZHRoOiBhdXRvOwp9Ci5hbGlnbkNlbnRlciB7CiAgbWFyZ2luOiAx
ZW0gMDsKfQouYWxpZ25DZW50ZXIgPiAqOmZpcnN0LWNoaWxkIHsKICBib3JkZXI6IG5vbmU7CiAg
LyogdGhpcyBpc24ndCBvcHRpbWFsLCBidXQgaXQncyBhbiBleGlzdGVuY2UgcHJvb2YuICBQcmlu
Y2VYTUwgZG9lc24ndAogICAgIHN1cHBvcnQgZmxleGJveCB5ZXQuCiAgKi8KICBkaXNwbGF5OiB0
YWJsZTsKICBtYXJnaW46IDAgYXV0bzsKfQoKLyogbGlzdHMgKi8Kb2wsIHVsIHsKICBwYWRkaW5n
OiAwOwogIG1hcmdpbjogMCAwIDAuNWVtIDJlbTsKfQpvbCBvbCwgdWwgdWwsIG9sIHVsLCB1bCBv
bCB7CiAgbWFyZ2luLWxlZnQ6IDFlbTsKfQpsaSB7CiAgbWFyZ2luOiAwIDAgMC4yNWVtIDA7Cn0K
LnVsQ29tcGFjdCBsaSB7CiAgbWFyZ2luOiAwOwp9CnVsLmVtcHR5LCAudWxFbXB0eSB7CiAgbGlz
dC1zdHlsZS10eXBlOiBub25lOwp9CnVsLmVtcHR5IGxpLCAudWxFbXB0eSBsaSB7CiAgbWFyZ2lu
LXRvcDogMC41ZW07Cn0KdWwuY29tcGFjdCwgLnVsQ29tcGFjdCwKb2wuY29tcGFjdCwgLm9sQ29t
cGFjdCB7CiAgbGluZS1oZWlnaHQ6IDEwMCU7CiAgbWFyZ2luOiAwIDAgMCAyZW07Cn0KCi8qIGRl
ZmluaXRpb24gbGlzdHMgKi8KZGwgewp9CmRsID4gZHQgewogIGZsb2F0OiBsZWZ0OwogIG1hcmdp
bi1yaWdodDogMWVtOwp9CmRsID4gZGQgewogIG1hcmdpbi1ib3R0b206IC44ZW07CiAgbWluLWhl
aWdodDogMS4zZW07Cn0KZGwuY29tcGFjdCA+IGRkLCAuZGxDb21wYWN0ID4gZGQgewogIG1hcmdp
bi1ib3R0b206IDBlbTsKfQpkbCA+IGRkID4gZGwgewogIG1hcmdpbi10b3A6IDAuNWVtOwogIG1h
cmdpbi1ib3R0b206IDBlbTsKfQpkZC5icmVhayB7CiAgZGlzcGxheTogbm9uZTsKfQoKLyogbGlu
a3MgKi8KYSwgYVtocmVmXS5zZWxmUmVmOmhvdmVyIHsKICB0ZXh0LWRlY29yYXRpb246IG5vbmU7
Cn0KYVtocmVmXS5zZWxmUmVmIHsKICBjb2xvcjogdmFyKC0tdGV4dC1jb2xvcik7Cn0KYVtocmVm
XSB7CiAgY29sb3I6IHZhcigtLWxpbmstY29sb3IpOwp9CmFbaHJlZl06aG92ZXIgewogIHRleHQt
ZGVjb3JhdGlvbjogdW5kZXJsaW5lOwp9CmFbaHJlZl0uc2VsZlJlZjpob3ZlciB7CiAgYmFja2dy
b3VuZC1jb2xvcjogdmFyKC0taGlnaGxpZ2h0LWNvbG9yKTsKfQphLnhyZWYgewogIHdoaXRlLXNw
YWNlOiBub3dyYXA7Cn0KCi8qIEZpZ3VyZXMgKi8KdHQsIGNvZGUsIHByZSB7CiAgYmFja2dyb3Vu
ZC1jb2xvcjogdmFyKC0taGlnaGxpZ2h0LWNvbG9yKTsKICBmb250OiAxNHB4LzIycHggdmFyKC0t
Zm9udC1tb25vKTsKfQp0dCwgY29kZSB7CiAgLyogY2hhbmdpbmcgdGhlIGZvbnQgZm9yIGlubGlu
ZSBlbGVtZW50cyBsZWFkcyB0byBkaWZmZXJlbnQgYXNjZW5kZXIKICAgICBhbmQgZGVzY2VuZGVy
IGhlaWdodHM7IGFzIHdlIHdhbnQgdG8gcmV0YWluIGJhc2VsaW5lIGFsaWdubWVudCwKICAgICBy
ZW1vdmUgbGVhZGluZyB0byBhdm9pZCBhbHRlcmluZyB0aGUgZmluYWwgaGVpZ2h0IG9mIGxpbmVz
ICovCiAgbGluZS1oZWlnaHQ6IDA7Cn0KcHJlIHsKICBib3JkZXI6IDFweCBzb2xpZCB2YXIoLS1s
aW5lLWNvbG9yKTsKICBmb250LXNpemU6IDEzLjVweDsKICBsaW5lLWhlaWdodDogMTZweDsKICBs
ZXR0ZXItc3BhY2luZzogLTAuMnB4OwogIG1hcmdpbjogNXB4OwogIHBhZGRpbmc6IDVweDsKfQpp
bWcgewogIG1heC13aWR0aDogMTAwJTsKfQpmaWd1cmUgewogIG1hcmdpbjogMC41ZW0gMDsKICBw
YWRkaW5nOiAwOwp9CmZpZ3VyZSBibG9ja3F1b3RlIHsKICBtYXJnaW46IDAuOGVtIDAuNGVtIDAu
NGVtOwp9CmZpZ2NhcHRpb24sIGNhcHRpb24gewogIGZvbnQtc3R5bGU6IGl0YWxpYzsKICBtYXJn
aW46IDAuNWVtIDEuNWVtOwogIHRleHQtYWxpZ246IGxlZnQ7Cn0KQG1lZGlhIHNjcmVlbiB7CiAg
cHJlLCBzdmcgewogICAgZGlzcGxheTogaW5saW5lLWJsb2NrOwogICAgb3ZlcmZsb3cteDogYXV0
bzsKICB9CiAgcHJlIHsKICAgIG1heC13aWR0aDogMTAwJTsKICAgIHdpZHRoOiBjYWxjKDEwMCUg
LSAyMnB4IC0gMWVtKTsKICB9CiAgc3ZnIHsKICAgIG1heC13aWR0aDogY2FsYygxMDAlIC0gMjJw
eCAtIDFlbSk7CiAgfQogIGZpZ3VyZSBwcmUgewogICAgZGlzcGxheTogYmxvY2s7CiAgICB3aWR0
aDogY2FsYygxMDAlIC0gMjVweCk7CiAgfQogIHByZSArIC5waWxjcm93LCBzdmcgKyAucGlsY3Jv
dyB7CiAgICBkaXNwbGF5OiBpbmxpbmUtYmxvY2s7CiAgICB2ZXJ0aWNhbC1hbGlnbjogdGV4dC1i
b3R0b207CiAgICBwYWRkaW5nLWJvdHRvbTogOHB4OwogIH0KfQoKLyogYXNpZGUsIGJsb2NrcXVv
dGUgKi8KYXNpZGUsIGJsb2NrcXVvdGUgewogIG1hcmdpbi1sZWZ0OiAwOwogIHBhZGRpbmc6IDAg
MmVtOwogIGZvbnQtc3R5bGU6IGl0YWxpYzsKfQpibG9ja3F1b3RlIHsKICBtYXJnaW46IDFlbSAw
Owp9CmNpdGUgewogIGRpc3BsYXk6IGJsb2NrOwogIHRleHQtYWxpZ246IHJpZ2h0OwogIGZvbnQt
c3R5bGU6IGl0YWxpYzsKfQoKLyogdGFibGVzICovCnRhYmxlIHsKICBtYXgtd2lkdGg6IDEwMCU7
CiAgbWFyZ2luOiAwIDAgMWVtOwogIGJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7Cn0KdGFibGUu
cmlnaHQgewogIG1hcmdpbi1sZWZ0OiBhdXRvOwp9CnRhYmxlLmNlbnRlciB7CiAgbWFyZ2luLWxl
ZnQ6IGF1dG87CiAgbWFyZ2luLXJpZ2h0OiBhdXRvOwp9CnRhYmxlLmxlZnQgewogIG1hcmdpbi1y
aWdodDogYXV0bzsKfQp0aGVhZCwgdGJvZHkgewogIGJvcmRlcjogMXB4IHNvbGlkIHZhcigtLWxp
bmUtY29sb3IpOwp9CnRoLCB0ZCB7CiAgdGV4dC1hbGlnbjogbGVmdDsKICB2ZXJ0aWNhbC1hbGln
bjogdG9wOwogIHBhZGRpbmc6IDVweCAxMHB4Owp9CnRoIHsKICBiYWNrZ3JvdW5kLWNvbG9yOiB2
YXIoLS1saW5lLWNvbG9yKTsKfQp0cjpudGgtY2hpbGQoMm4pID4gdGQgewogIGJhY2tncm91bmQt
Y29sb3I6IHZhcigtLWJhY2tncm91bmQtY29sb3IpOwp9CnRyOm50aC1jaGlsZCgybisxKSA+IHRk
IHsKICBiYWNrZ3JvdW5kLWNvbG9yOiB2YXIoLS1oaWdobGlnaHQtY29sb3IpOwp9CnRoZWFkK3Ri
b2R5ID4gdHI6bnRoLWNoaWxkKDJuKSA+IHRkIHsKICBiYWNrZ3JvdW5kLWNvbG9yOiB2YXIoLS1o
aWdobGlnaHQtY29sb3IpOwp9CnRoZWFkK3Rib2R5ID4gdHI6bnRoLWNoaWxkKDJuKzEpID4gdGQg
ewogIGJhY2tncm91bmQtY29sb3I6IHZhcigtLWJhY2tncm91bmQtY29sb3IpOwp9CnRhYmxlIGNh
cHRpb24gewogIG1hcmdpbjogMDsKICBwYWRkaW5nOiAzcHggMCAzcHggMWVtOwp9CnRhYmxlIHAg
ewogIG1hcmdpbjogMDsKfQoKLyogcGlsY3JvdyAqLwphLnBpbGNyb3cgewogIG1hcmdpbi1sZWZ0
OiAzcHg7CiAgb3BhY2l0eTogMC4yOwogIHVzZXItc2VsZWN0OiBub25lOwp9CmEucGlsY3Jvd1to
cmVmXSB7IGNvbG9yOiB2YXIoLS1waWxjcm93LXdlYWspOyB9CmEucGlsY3Jvd1tocmVmXTpob3Zl
ciB7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgfQpAbWVkaWEgbm90IHByaW50IHsKICA6aG92ZXIg
PiBhLnBpbGNyb3cgewogICAgb3BhY2l0eTogMTsKICB9CiAgYS5waWxjcm93W2hyZWZdOmhvdmVy
IHsKICAgIGNvbG9yOiB2YXIoLS1waWxjcm93LXN0cm9uZyk7CiAgICBiYWNrZ3JvdW5kLWNvbG9y
OiB0cmFuc3BhcmVudDsKICB9Cn0KQG1lZGlhIHByaW50IHsKICBhLnBpbGNyb3cgewogICAgZGlz
cGxheTogbm9uZTsKICB9Cn0KCi8qIG1pc2MgKi8KaHIgewogIGJvcmRlcjogMDsKICBib3JkZXIt
dG9wOiAxcHggc29saWQgdmFyKC0tbGluZS1jb2xvcik7Cn0KLmJjcDE0IHsKICBmb250LXZhcmlh
bnQ6IHNtYWxsLWNhcHM7Cn0KCi5yb2xlIHsKICBmb250LXZhcmlhbnQ6IGFsbC1zbWFsbC1jYXBz
Owp9CgovKiBpbmZvIGJsb2NrICovCiNpZGVudGlmaWVycyB7CiAgbWFyZ2luOiAwOwogIGZvbnQt
c2l6ZTogdmFyKC0tc21hbGwtZm9udC1zaXplKTsKICBsaW5lLWhlaWdodDogMThweDsKICAtLWlk
ZW50aWZpZXItd2lkdGg6IDhlbTsKfQojaWRlbnRpZmllcnMgZHQgewogIHdpZHRoOiB2YXIoLS1p
ZGVudGlmaWVyLXdpZHRoKTsKICBtYXJnaW46IDA7CiAgY2xlYXI6IGxlZnQ7CiAgZmxvYXQ6IGxl
ZnQ7CiAgdGV4dC1hbGlnbjogcmlnaHQ7Cn0KI2lkZW50aWZpZXJzIGRkIHsKICBtYXJnaW46IDAg
MCAwIGNhbGMoMWVtICsgdmFyKC0taWRlbnRpZmllci13aWR0aCkpOwogIG1pbi13aWR0aDogNWVt
Owp9CiNpZGVudGlmaWVycyAuYXV0aG9ycyAuYXV0aG9yIHsKICBkaXNwbGF5OiBpbmxpbmUtYmxv
Y2s7CiAgbWFyZ2luLXJpZ2h0OiAxLjVlbTsKfQojaWRlbnRpZmllcnMgLmF1dGhvcnMgLm9yZyB7
CiAgZm9udC1zdHlsZTogaXRhbGljOwp9CgovKiBUaGUgcHJlcGFyZWQvcmVuZGVyZWQgaW5mbyBh
dCB0aGUgdmVyeSBib3R0b20gb2YgdGhlIHBhZ2UgKi8KLmRvY0luZm8gewogIGNvbG9yOiAjOTk5
OwogIGZvbnQtc2l6ZTogMC45ZW07CiAgZm9udC1zdHlsZTogaXRhbGljOwogIG1hcmdpbi10b3A6
IDJlbTsKfQouZG9jSW5mbyAucHJlcGFyZWQgewogIGZsb2F0OiBsZWZ0Owp9Ci5kb2NJbmZvIC5w
cmVwYXJlZCB7CiAgZmxvYXQ6IHJpZ2h0Owp9CgovKiB0YWJsZSBvZiBjb250ZW50cyAqLwojdG9j
IHsKICBwYWRkaW5nOiAwLjc1ZW0gMCAyZW0gMDsKICBtYXJnaW4tYm90dG9tOiAxZW07Cn0KI3Rv
YyBuYXYgdWwgewogIG1hcmdpbjogMCAwLjVlbSAwIDA7CiAgcGFkZGluZzogMDsKICBsaXN0LXN0
eWxlOiBub25lOwp9CiN0b2MgbmF2IGxpIHsKICBsaW5lLWhlaWdodDogMS4zZW07CiAgbWFyZ2lu
OiAwLjc1ZW0gMDsKICBwYWRkaW5nLWxlZnQ6IDEuMmVtOwogIHRleHQtaW5kZW50OiAtMS4yZW07
Cn0KI3RvYyBhLnhyZWYgewogIHdoaXRlLXNwYWNlOiBub3JtYWw7Cn0KLyogcmVmZXJlbmNlcyAq
LwoucmVmZXJlbmNlcyBkdCB7CiAgdGV4dC1hbGlnbjogcmlnaHQ7CiAgZm9udC13ZWlnaHQ6IGJv
bGQ7CiAgbWluLXdpZHRoOiA3ZW07Cn0KLnJlZmVyZW5jZXMgZGQgewogIG1hcmdpbi1sZWZ0OiA4
ZW07CiAgb3ZlcmZsb3c6IGF1dG87Cn0KCi5yZWZJbnN0YW5jZSB7CiAgbWFyZ2luLWJvdHRvbTog
MS4yNWVtOwp9CgoucmVmZXJlbmNlcyAuYXNjaWkgewogIG1hcmdpbi1ib3R0b206IDAuMjVlbTsK
fQoKLyogaW5kZXggKi8KLmluZGV4IHVsIHsKICBtYXJnaW46IDAgMCAwIDFlbTsKICBwYWRkaW5n
OiAwOwogIGxpc3Qtc3R5bGU6IG5vbmU7Cn0KLmluZGV4IHVsIHVsIHsKICBtYXJnaW46IDA7Cn0K
LmluZGV4IGxpIHsKICBtYXJnaW46IDA7CiAgdGV4dC1pbmRlbnQ6IC0yZW07CiAgcGFkZGluZy1s
ZWZ0OiAyZW07CiAgcGFkZGluZy1ib3R0b206IDVweDsKfQouaW5kZXhJbmRleCB7CiAgbWFyZ2lu
OiAwLjVlbSAwIDFlbTsKfQouaW5kZXggYSB7CiAgZm9udC13ZWlnaHQ6IDcwMDsKfQovKiBtYWtl
IHRoZSBpbmRleCB0d28tY29sdW1uIG9uIGFsbCBidXQgdGhlIHNtYWxsZXN0IHNjcmVlbnMgKi8K
QG1lZGlhIChtaW4td2lkdGg6IDUwMHB4KSB7CiAgLmluZGV4IHVsIHsKICAgIGNvbHVtbi1jb3Vu
dDogMjsKICAgIGNvbHVtbi1nYXA6IDIwcHg7CiAgfQogIC5pbmRleCB1bCB1bCB7CiAgICBjb2x1
bW4tY291bnQ6IDE7CiAgICBjb2x1bW4tZ2FwOiAwOwogIH0KfQoKLyogYXV0aG9ycyAqLwphZGRy
ZXNzLnZjYXJkIHsKICBmb250LXN0eWxlOiBub3JtYWw7CiAgbWFyZ2luOiAxZW0gMDsKfQphZGRy
ZXNzLnZjYXJkIC5uYW1lUm9sZSB7CiAgZm9udC13ZWlnaHQ6IDcwMDsKICBtYXJnaW4tbGVmdDog
MDsKfQphZGRyZXNzLnZjYXJkIC5sYWJlbCB7CiAgbWFyZ2luOiAwLjVlbSAwOwp9CmFkZHJlc3Mu
dmNhcmQgLnR5cGUgewogIGRpc3BsYXk6IG5vbmU7Cn0KLmFsdGVybmF0aXZlLWNvbnRhY3Qgewog
IG1hcmdpbjogMS41ZW0gMCAxZW07Cn0KaHIuYWRkciB7CiAgYm9yZGVyLXRvcDogMXB4IGRhc2hl
ZDsKICBtYXJnaW46IDA7CiAgY29sb3I6ICNkZGQ7CiAgbWF4LXdpZHRoOiBjYWxjKDEwMCUgLSAx
NnB4KTsKfQpAbWVkaWEgKG1pbi13aWR0aDogNTAwcHgpIHsKICAjYXV0aG9ycy1hZGRyZXNzZXMg
PiBzZWN0aW9uIHsKICAgIGNvbHVtbi1jb3VudDogMjsKICAgIGNvbHVtbi1nYXA6IDIwcHg7CiAg
fQogICNhdXRob3JzLWFkZHJlc3NlcyA+IHNlY3Rpb24gPiBoMiB7CiAgICBjb2x1bW4tc3Bhbjog
YWxsOwogIH0KICAvKiBoYWNrIGZvciBicmVhay1pbnNpZGU6IGF2b2lkLWNvbHVtbiAqLwogICNh
dXRob3JzLWFkZHJlc3NlcyBhZGRyZXNzIHsKICAgIGRpc3BsYXk6IGlubGluZS1ibG9jazsKICAg
IGJyZWFrLWluc2lkZTogYXZvaWQtY29sdW1uOwogIH0KfQoKLnJmY0VkaXRvclJlbW92ZSBwOmZp
cnN0LW9mLXR5cGUgewogIGZvbnQtc3R5bGU6IGl0YWxpYzsKfQouY3JlZiB7CiAgYmFja2dyb3Vu
ZC1jb2xvcjogcmdiYSgyNDksIDIzMiwgMTA1LCAwLjMpOwogIHBhZGRpbmc6IDJweCA0cHg7Cn0K
LmNyZWZTb3VyY2UgewogIGZvbnQtc3R5bGU6IGl0YWxpYzsKfQovKiBhbHRlcm5hdGl2ZSBsYXlv
dXQgZm9yIHNtYWxsZXIgc2NyZWVucyAqLwpAbWVkaWEgc2NyZWVuIGFuZCAobWF4LXdpZHRoOiA5
MjlweCkgewogICN0b2MgewogICAgcG9zaXRpb246IGZpeGVkOwogICAgei1pbmRleDogMjsKICAg
IHRvcDogMDsKICAgIHJpZ2h0OiAwOwogICAgcGFkZGluZzogMDsKICAgIG1hcmdpbjogMDsKICAg
IGJvcmRlci1ib3R0b206IDFweCBzb2xpZCAjY2NjOwogICAgb3BhY2l0eTogMC42OwogIH0KICAj
dG9jLmFjdGl2ZSB7CiAgICAgIG9wYWNpdHk6IDE7CiAgfQogICN0b2MgaDIgewogICAgbWFyZ2lu
OiAwOwogICAgcGFkZGluZzogMnB4IDAgMnB4IDZweDsKICAgIHBhZGRpbmctcmlnaHQ6IDFlbTsK
ICAgIGZvbnQtc2l6ZTogMThweDsKICAgIGxpbmUtaGVpZ2h0OiAyNHB4OwogICAgbWluLXdpZHRo
OiAxOTBweDsKICAgIHRleHQtYWxpZ246IHJpZ2h0OwogICAgYmFja2dyb3VuZC1jb2xvcjogIzQ0
NDsKICAgIGNvbG9yOiB3aGl0ZTsKICAgIGN1cnNvcjogcG9pbnRlcjsKICB9CiAgI3RvYyBoMjo6
YmVmb3JlIHsgLyogY3NzIGhhbWJ1cmdlciAqLwogICAgZmxvYXQ6IHJpZ2h0OwogICAgcG9zaXRp
b246IHJlbGF0aXZlOwogICAgd2lkdGg6IDFlbTsKICAgIGhlaWdodDogMXB4OwogICAgbGVmdDog
LTE2NHB4OwogICAgbWFyZ2luOiA4cHggMCAwIDA7CiAgICBiYWNrZ3JvdW5kOiB3aGl0ZSBub25l
IHJlcGVhdCBzY3JvbGwgMCAwOwogICAgYm94LXNoYWRvdzogMCA0cHggMCAwIHdoaXRlLCAwIDhw
eCAwIDAgd2hpdGU7CiAgICBjb250ZW50OiAiIjsKICB9CiAgI3RvYyBuYXYgewogICAgZGlzcGxh
eTogbm9uZTsKICAgIGJhY2tncm91bmQtY29sb3I6IHZhcigtLWJhY2tncm91bmQtY29sb3IpOwog
ICAgcGFkZGluZzogMC41ZW0gMWVtIDFlbTsKICAgIG92ZXJmbG93OiBhdXRvOwogICAgb3ZlcnNj
cm9sbC1iZWhhdmlvcjogY29udGFpbjsKICAgIGhlaWdodDogY2FsYygxMDB2aCAtIDQ4cHgpOwog
ICAgYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCAjZGRkOwogIH0KICAjdG9jLmFjdGl2ZSBuYXYgewog
ICAgZGlzcGxheTogYmxvY2s7CiAgfQogIC8qIE1ha2UgdGhlIGNvbGxhcHNlZCBUb0MgaGVhZGVy
IHJlbmRlciB3aGl0ZSBvbiBncmF5IGFsc28gd2hlbiBpdCdzIGEgbGluayAqLwogICN0b2MgaDIg
YSwKICAjdG9jIGgyIGE6bGluaywKICAjdG9jIGgyIGE6Zm9jdXMsCiAgI3RvYyBoMiBhOmhvdmVy
LAogICN0b2MgYS50b3BsaW5rLAogICN0b2MgYS50b3BsaW5rOmhvdmVyIHsKICAgIGNvbG9yOiB3
aGl0ZTsKICAgIGJhY2tncm91bmQtY29sb3I6ICM0NDQ7CiAgICB0ZXh0LWRlY29yYXRpb246IG5v
bmU7CiAgfQogICN0b2MgYS50b3BsaW5rIHsKICAgIG1hcmdpbi10b3A6IDJweDsKICB9Cn0KCi8q
IGFsdGVybmF0aXZlIGxheW91dCBmb3Igd2lkZSBzY3JlZW5zICovCkBtZWRpYSBzY3JlZW4gYW5k
IChtaW4td2lkdGg6IDkzMHB4KSB7CiAgYm9keSB7CiAgICBwYWRkaW5nLXJpZ2h0OiAzNjBweDsK
ICAgIHBhZGRpbmctcmlnaHQ6IGNhbGMobWluKDE4MHB4ICsgMjAlLCA1MDBweCkpOwogIH0KICAj
dG9jIHsKICAgIHBvc2l0aW9uOiBmaXhlZDsKICAgIGJvdHRvbTogMDsKICAgIHJpZ2h0OiAwOwog
ICAgcmlnaHQ6IGNhbGMoNTB2dyAtIDQ4MHB4KTsKICAgIHdpZHRoOiAzMTJweDsKICAgIG1hcmdp
bjogMDsKICAgIHBhZGRpbmc6IDA7CiAgICB6LWluZGV4OiAxOwogIH0KICAjdG9jIGgyIHsKICAg
IG1hcmdpbjogMDsKICAgIHBhZGRpbmc6IDAuMjVlbSAxZW0gMWVtIDA7CiAgfQogICN0b2MgbmF2
IHsKICAgIGRpc3BsYXk6IGJsb2NrOwogICAgaGVpZ2h0OiBjYWxjKDkwdmggLSA4NHB4KTsKICAg
IGJvdHRvbTogMDsKICAgIHBhZGRpbmc6IDAuNWVtIDAgMmVtOwogICAgb3ZlcmZsb3c6IGF1dG87
CiAgICBvdmVyc2Nyb2xsLWJlaGF2aW9yOiBjb250YWluOwogICAgc2Nyb2xsYmFyLXdpZHRoOiB0
aGluOwogIH0KICAjdG9jIG5hdiA+IHVsICB7CiAgICBtYXJnaW4tYm90dG9tOiAyZW07CiAgfQog
ICN0b2MgdWwgewogICAgbWFyZ2luOiAwIDAgMCA0cHg7CiAgICBmb250LXNpemU6IHZhcigtLXNt
YWxsLWZvbnQtc2l6ZSk7CiAgfQogICN0b2MgdWwgcCwgI3RvYyB1bCBsaSB7CiAgICBtYXJnaW46
IDJweCAwOwogICAgbGluZS1oZWlnaHQ6IDIycHg7CiAgfQogIGltZyB7IC8qIGZ1dHVyZSBwcm9v
ZmluZyAqLwogICAgbWF4LXdpZHRoOiAxMDAlOwogICAgaGVpZ2h0OiBhdXRvOwogIH0KfQoKLyog
cGFnaW5hdGlvbiAqLwpAbWVkaWEgcHJpbnQgewogIGJvZHkgewogICAgd2lkdGg6IDEwMCU7CiAg
fQogIHAgewogICAgb3JwaGFuczogMzsKICAgIHdpZG93czogMzsKICB9CiAgI24tY29weXJpZ2h0
LW5vdGljZSB7CiAgICBib3JkZXItYm90dG9tOiBub25lOwogIH0KICAjdG9jLCAjbi1pbnRyb2R1
Y3Rpb24gewogICAgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsKICB9CiAgI3RvYyB7CiAgICBi
b3JkZXItdG9wOiBub25lOwogICAgcGFkZGluZy10b3A6IDA7CiAgfQogIGZpZ3VyZSwgcHJlIHsK
ICAgIHBhZ2UtYnJlYWstaW5zaWRlOiBhdm9pZDsKICB9CiAgZmlndXJlIHsKICAgIG92ZXJmbG93
OiBzY3JvbGw7CiAgfQogIGgxLCBoMiwgaDMsIGg0LCBoNSwgaDYgewogICAgcGFnZS1icmVhay1h
ZnRlcjogYXZvaWQ7CiAgfQogIGgyKyosIGgzKyosIGg0KyosIGg1KyosIGg2KyogewogICAgcGFn
ZS1icmVhay1iZWZvcmU6IGF2b2lkOwogIH0KICBwcmUgewogICAgd2hpdGUtc3BhY2U6IHByZS13
cmFwOwogICAgd29yZC13cmFwOiBicmVhay13b3JkOwogICAgZm9udC1zaXplOiAxMHB0OwogIH0K
ICB0YWJsZSB7CiAgICBib3JkZXI6IDFweCBzb2xpZCAjZGRkOwogIH0KICB0ZCB7CiAgICBib3Jk
ZXItdG9wOiAxcHggc29saWQgI2RkZDsKICB9Cn0KCkBwYWdlIDpmaXJzdCB7CiAgcGFkZGluZy10
b3A6IDA7CiAgQHRvcC1sZWZ0IHsKICAgIGNvbnRlbnQ6IG5vcm1hbDsKICAgIGJvcmRlcjogbm9u
ZTsKICB9CiAgQHRvcC1jZW50ZXIgewogICAgY29udGVudDogbm9ybWFsOwogICAgYm9yZGVyOiBu
b25lOwogIH0KICBAdG9wLXJpZ2h0IHsKICAgIGNvbnRlbnQ6IG5vcm1hbDsKICAgIGJvcmRlcjog
bm9uZTsKICB9Cn0KCkBwYWdlIHsKICBzaXplOiBBNDsKICBtYXJnaW4tYm90dG9tOiA0NW1tOwog
IHBhZGRpbmctdG9wOiAyMHB4Owp9CgovKiBDaGFuZ2VzIGludHJvZHVjZWQgdG8gZml4IGlzc3Vl
cyBmb3VuZCBkdXJpbmcgaW1wbGVtZW50YXRpb24gKi8KCi8qIFNlcGFyYXRlIGJvZHkgZnJvbSBk
b2N1bWVudCBpbmZvIGV2ZW4gd2l0aG91dCBpbnRlcnZlbmluZyBIMSAqLwpzZWN0aW9uIHsKICBj
bGVhcjogYm90aDsKfQoKLyogVG9wIGFsaWduIGF1dGhvciBkaXZzLCB0byBhdm9pZCBuYW1lcyB3
aXRob3V0IG9yZ2FuaXphdGlvbiBkcm9wcGluZyBsZXZlbCB3aXRoIG9yZyBuYW1lcyAqLwouYXV0
aG9yIHsKICB2ZXJ0aWNhbC1hbGlnbjogdG9wOwp9CgovKiBTdHlsZSBzZWN0aW9uIG51bWJlcnMg
d2l0aCBtb3JlIHNwYWNlIGJldHdlZW4gbnVtYmVyIGFuZCB0aXRsZSAqLwouc2VjdGlvbi1udW1i
ZXIgewogIHBhZGRpbmctcmlnaHQ6IDAuNWVtOwp9CgovKiBBZGQgc3R5bGluZyBmb3IgYSBsaW5r
IGluIHRoZSBUb0MgdGhhdCBwb2ludHMgdG8gdGhlIHRvcCBvZiB0aGUgZG9jdW1lbnQgKi8KYS50
b3BsaW5rIHsKICBmbG9hdDogcmlnaHQ7CiAgbWFyZ2luOiA4cHggMC41ZW0gMDsKfQoKLyogRml4
IHRoZSBkbCBzdHlsaW5nIHRvIG1hdGNoIHRoZSBSRkMgNzk5MiBhdHRyaWJ1dGVzICovCmRsID4g
ZHQsCmRsLmRsUGFyYWxsZWwgPiBkdCB7CiAgZmxvYXQ6IGxlZnQ7CiAgbWFyZ2luLXJpZ2h0OiAx
ZW07Cn0KZGwuZGxOZXdsaW5lID4gZHQgewogIGZsb2F0OiBub25lOwp9CgovKiBQcm92aWRlIHN0
eWxpbmcgZm9yIHRhYmxlIGNlbGwgdGV4dCBhbGlnbm1lbnQgKi8KdGFibGUgLnRleHQtbGVmdCwg
dGFibGUgLnRleHQtbGVmdCB7CiAgdGV4dC1hbGlnbjogbGVmdDsKfQp0YWJsZSAudGV4dC1jZW50
ZXIsIHRhYmxlIC50ZXh0LWNlbnRlciB7CiAgdGV4dC1hbGlnbjogY2VudGVyOwp9CnRhYmxlIC50
ZXh0LXJpZ2h0LCB0YWJsZSAudGV4dC1yaWdodCB7CiAgdGV4dC1hbGlnbjogcmlnaHQ7Cn0KCi8q
IE1ha2UgdGhlIGFsdGVybmF0aXZlIGF1dGhvciBjb250YWN0IGluZm9ybWF0aW9uIGxvb2sgbGVz
cyBsaWtlIGp1c3QgYW5vdGhlcgogICBhdXRob3IsIGFuZCBncm91cCBpdCBjbG9zZXIgd2l0aCB0
aGUgcHJpbWFyeSBhdXRob3IgY29udGFjdCBpbmZvcm1hdGlvbiAqLwouYWx0ZXJuYXRpdmUtY29u
dGFjdCB7CiAgbWFyZ2luOiAwLjVlbSAwIDAuMjVlbSAwOwp9CmFkZHJlc3MgLm5vbi1hc2NpaSB7
CiAgbWFyZ2luOiAwIDAgMCAyZW07Cn0KCi8qIFdpdGggaXQgYmVpbmcgcG9zc2libGUgdG8gc2V0
IHRhYmxlcyB3aXRoIGFsaWdubWVudAogIGxlZnQsIGNlbnRlciwgYW5kIHJpZ2h0LCB7IHdpZHRo
OiAxMDAlOyB9IGRvZXMgbm90IG1ha2Ugc2Vuc2UgKi8KdGFibGUgewogIHdpZHRoOiBhdXRvOwp9
CgovKiBBdm9pZCByZWZlcmVuY2UgdGV4dCB0aGF0IHNpdHMgaW4gYSBibG9jayB3aXRoIHZlcnkg
d2lkZSBsZWZ0IG1hcmdpbiwKICAgYmVjYXVzZSBvZiBhIGxvbmcgZmxvYXRpbmcgZHQgbGFiZWwu
Ki8KLnJlZmVyZW5jZXMgZGQgewogIG92ZXJmbG93OiB2aXNpYmxlOwp9CgovKiBDb250cm9sIGNh
cHRpb24gcGxhY2VtZW50ICovCmNhcHRpb24gewogIGNhcHRpb24tc2lkZTogYm90dG9tOwp9Cgov
KiBMaW1pdCB0aGUgd2lkdGggb2YgdGhlIGF1dGhvciBhZGRyZXNzIHZjYXJkLCBzbyBuYW1lcyBp
biByaWdodC10by1sZWZ0CiAgIHNjcmlwdCBkb24ndCBlbmQgdXAgb24gdGhlIG90aGVyIHNpZGUg
b2YgdGhlIHBhZ2UuICovCgphZGRyZXNzLnZjYXJkIHsKICBtYXgtd2lkdGg6IDIwZW07CiAgbWFy
Z2luLXJpZ2h0OiBhdXRvOwp9CgovKiBGb3IgYWRkcmVzcyBhbGlnbm1lbnQgZGVwZW5kZW50IG9u
IExUUiBvciBSVEwgc2NyaXB0cyAqLwphZGRyZXNzIGRpdi5sZWZ0IHsKICB0ZXh0LWFsaWduOiBs
ZWZ0Owp9CmFkZHJlc3MgZGl2LnJpZ2h0IHsKICB0ZXh0LWFsaWduOiByaWdodDsKfQoKLyogR2l2
ZSB0aGUgdGFibGUgY2FwdGlvbiBsYWJlbCB0aGUgc2FtZSBzdHlsaW5nIGFzIHRoZSBmaWdjYXB0
aW9uICovCgpAbWVkaWEgcHJpbnQgewogIC50b3BsaW5rIHsKICAgIGRpc3BsYXk6IG5vbmU7CiAg
fQoKICAvKiBhdm9pZCBvdmVyd3JpdGluZyB0aGUgdG9wIGJvcmRlciBsaW5lIHdpdGggdGhlIFRv
QyBoZWFkZXIgKi8KICAjdG9jIHsKICAgIHBhZGRpbmctdG9wOiAxcHg7CiAgfQoKICAvKiBBdm9p
ZCBwYWdlIGJyZWFrcyBpbnNpZGUgZGwgYW5kIGF1dGhvciBhZGRyZXNzIGVudHJpZXMgKi8KICBk
ZCB7CiAgICBwYWdlLWJyZWFrLWJlZm9yZTogYXZvaWQ7CiAgfQogIC52Y2FyZCB7CiAgICBwYWdl
LWJyZWFrLWluc2lkZTogYXZvaWQ7CiAgfQoKfQovKiBUd2VhayB0aGUgYmNwMTQga2V5d29yZCBw
cmVzZW50YXRpb24gKi8KLmJjcDE0IHsKICBmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHM7CiAgZm9u
dC13ZWlnaHQ6IGJvbGQ7CiAgZm9udC1zaXplOiAwLjllbTsKfQoKLyogRGFyayBtb2RlLiAqLwpA
bWVkaWEgKHByZWZlcnMtY29sb3Itc2NoZW1lOiBkYXJrKSB7Cjpyb290IHsKICAtLWJhY2tncm91
bmQtY29sb3I6ICMxMjEyMTI7CiAgLS10ZXh0LWNvbG9yOiAjZjBmMGYwOwogIC0tdGl0bGUtY29s
b3I6ICNmZmY7CiAgLS1saW5rLWNvbG9yOiAjNGRhNGYwOwogIC0taGlnaGxpZ2h0LWNvbG9yOiAj
MjgyODI4OwogIC0tbGluZS1jb2xvcjogIzQ0NDsKICAtLXBpbGNyb3ctd2VhazogIzQ0NDsKICAt
LXBpbGNyb3ctc3Ryb25nOiAjNjY2OwogIHNjcm9sbGJhci1jb2xvcjogIzc3NyAjMzMzOwp9Ci8q
IFRyaWNrOiBhIHByZWZpeCBtYXRjaCB3b3JrcyBiZWNhdXNlIG9ubHkgYmxhY2sgYW5kIHdoaXRl
IGFyZSBhbGxvd2VkICovCnN2ZyBbc3Ryb2tlPSJibGFjayJdLCBzdmcgW3N0cm9rZV49IiMwMDAi
XSB7CiAgc3Ryb2tlOiB2YXIoLS10ZXh0LWNvbG9yKTsKfQpzdmcgW3N0cm9rZT0id2hpdGUiXSwg
c3ZnIFtzdHJva2VePSIjZmZmIl0gewogIHN0cm9rZTogdmFyKC0tYmFja2dyb3VuZC1jb2xvcik7
Cn0Kc3ZnIFtmaWxsPSJibGFjayJdLCBzdmcgW2ZpbGxePSIjMDAwIl0sIHN2ZyA6bm90KFtmaWxs
XSkgewogIGZpbGw6IHZhcigtLXRleHQtY29sb3IpOwp9CnN2ZyBbc3Ryb2tlPSJmaWxsIl0sIHN2
ZyBbZmlsbF49IiNmZmYiXSB7CiAgZmlsbDogdmFyKC0tYmFja2dyb3VuZC1jb2xvcik7Cn0KfQo8
L3N0eWxlPgoKPC9oZWFkPgo8Ym9keT4KPHRhYmxlIGNsYXNzPSJlYXJzIj4KPHRoZWFkPjx0cj4K
PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdDwvdGQ+Cjx0ZCBjbGFzcz0iY2VudGVyIj5J
LVJlZ2V4cDwvdGQ+Cjx0ZCBjbGFzcz0icmlnaHQiPkphbnVhcnkgMjAyMjwvdGQ+CjwvdHI+PC90
aGVhZD4KPHRmb290Pjx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij5Cb3JtYW5uPC90ZD4KPHRkIGNsYXNz
PSJjZW50ZXIiPkV4cGlyZXMgMjIgSnVseSAyMDIyPC90ZD4KPHRkIGNsYXNzPSJyaWdodCI+W1Bh
Z2VdPC90ZD4KPC90cj48L3Rmb290Pgo8L3RhYmxlPgo8ZGl2IGlkPSJleHRlcm5hbC1tZXRhZGF0
YSIgY2xhc3M9ImRvY3VtZW50LWluZm9ybWF0aW9uIj48L2Rpdj4KPGRpdiBpZD0iaW50ZXJuYWwt
bWV0YWRhdGEiIGNsYXNzPSJkb2N1bWVudC1pbmZvcm1hdGlvbiI+CjxkbCBpZD0iaWRlbnRpZmll
cnMiPgo8ZHQgY2xhc3M9ImxhYmVsLXdvcmtncm91cCI+V29ya2dyb3VwOjwvZHQ+CjxkZCBjbGFz
cz0id29ya2dyb3VwIj5OZXR3b3JrIFdvcmtpbmcgR3JvdXA8L2RkPgo8ZHQgY2xhc3M9ImxhYmVs
LWludGVybmV0LWRyYWZ0Ij5JbnRlcm5ldC1EcmFmdDo8L2R0Pgo8ZGQgY2xhc3M9ImludGVybmV0
LWRyYWZ0Ij5kcmFmdC1ib3JtYW5uLWpzb25wYXRoLWlyZWdleHAtbGF0ZXN0PC9kZD4KPGR0IGNs
YXNzPSJsYWJlbC1wdWJsaXNoZWQiPlB1Ymxpc2hlZDo8L2R0Pgo8ZGQgY2xhc3M9InB1Ymxpc2hl
ZCI+Cjx0aW1lIGRhdGV0aW1lPSIyMDIyLTAxLTE4IiBjbGFzcz0icHVibGlzaGVkIj4xOCBKYW51
YXJ5IDIwMjI8L3RpbWU+CiAgICA8L2RkPgo8ZHQgY2xhc3M9ImxhYmVsLWludGVuZGVkLXN0YXR1
cyI+SW50ZW5kZWQgU3RhdHVzOjwvZHQ+CjxkZCBjbGFzcz0iaW50ZW5kZWQtc3RhdHVzIj5TdGFu
ZGFyZHMgVHJhY2s8L2RkPgo8ZHQgY2xhc3M9ImxhYmVsLWV4cGlyZXMiPkV4cGlyZXM6PC9kdD4K
PGRkIGNsYXNzPSJleHBpcmVzIj48dGltZSBkYXRldGltZT0iMjAyMi0wNy0yMiI+MjIgSnVseSAy
MDIyPC90aW1lPjwvZGQ+CjxkdCBjbGFzcz0ibGFiZWwtYXV0aG9ycyI+QXV0aG9yOjwvZHQ+Cjxk
ZCBjbGFzcz0iYXV0aG9ycyI+CjxkaXYgY2xhc3M9ImF1dGhvciI+CiAgICAgIDxkaXYgY2xhc3M9
ImF1dGhvci1uYW1lIj5DLiBCb3JtYW5uPC9kaXY+CjxkaXYgY2xhc3M9Im9yZyI+VW5pdmVyc2l0
w6R0IEJyZW1lbiBUWkk8L2Rpdj4KPC9kaXY+CjwvZGQ+CjwvZGw+CjwvZGl2Pgo8aDEgaWQ9InRp
dGxlIj5JLVJlZ2V4cDogQW4gSW50ZXJvcGVyYWJsZSBSZWdleHAgRm9ybWF0PC9oMT4KPHNlY3Rp
b24gaWQ9InNlY3Rpb24tYWJzdHJhY3QiPgogICAgICA8aDIgaWQ9ImFic3RyYWN0Ij48YSBocmVm
PSIjYWJzdHJhY3QiIGNsYXNzPSJzZWxmUmVmIj5BYnN0cmFjdDwvYT48L2gyPgo8cCBpZD0ic2Vj
dGlvbi1hYnN0cmFjdC0xIj5UaGlzIGRvY3VtZW50IHNwZWNpZmllcyBJLVJlZ2V4cCwgYSBmbGF2
b3Igb2YgcmVndWxhciBleHByZXNzaW9ucyB0aGF0IGlzCmxpbWl0ZWQgaW4gc2NvcGUgd2l0aCB0
aGUgZ29hbCBvZiBpbnRlcm9wZXJhdGlvbiBhY3Jvc3MgbWFueSBkaWZmZXJlbnQKcmVndWxhci1l
eHByZXNzaW9uIGxpYnJhcmllcy48YSBocmVmPSIjc2VjdGlvbi1hYnN0cmFjdC0xIiBjbGFzcz0i
cGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+CjxzZWN0aW9uIGNsYXNzPSJub3RlIHJmY0Vk
aXRvclJlbW92ZSIgaWQ9InNlY3Rpb24tbm90ZS4xIj4KICAgICAgPGgyIGlkPSJuYW1lLWFib3V0
LXRoaXMtZG9jdW1lbnQiPgo8YSBocmVmPSIjbmFtZS1hYm91dC10aGlzLWRvY3VtZW50IiBjbGFz
cz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPkFib3V0IFRoaXMgRG9jdW1lbnQ8L2E+CiAgICAgIDwv
aDI+CjxwIGlkPSJzZWN0aW9uLW5vdGUuMS0xIj5UaGlzIG5vdGUgaXMgdG8gYmUgcmVtb3ZlZCBi
ZWZvcmUgcHVibGlzaGluZyBhcyBhbiBSRkMuPGEgaHJlZj0iI3NlY3Rpb24tbm90ZS4xLTEiIGNs
YXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+CjxwIGlkPSJzZWN0aW9uLW5vdGUuMS0yIj4KICAgICAg
ICBTdGF0dXMgaW5mb3JtYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQgbWF5IGJlIGZvdW5kIGF0IDxz
cGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvcm1h
bm4tanNvbnBhdGgtaXJlZ2V4cC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWJvcm1hbm4tanNvbnBhdGgtaXJlZ2V4cC88L2E+PC9zcGFuPi48YSBocmVmPSIjc2VjdGlv
bi1ub3RlLjEtMiIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24tbm90
ZS4xLTMiPgogICAgICAgIERpc2N1c3Npb24gb2YgdGhpcyBkb2N1bWVudCB0YWtlcyBwbGFjZSBv
biB0aGUKICAgICAgICBKU09OcGF0aCBXb3JraW5nIEdyb3VwIG1haWxpbmcgbGlzdCAoPHNwYW4+
PGEgaHJlZj0ibWFpbHRvOkpTT05wYXRoQGlldGYub3JnIj5tYWlsdG86SlNPTnBhdGhAaWV0Zi5v
cmc8L2E+PC9zcGFuPiksCiAgICAgICAgd2hpY2ggaXMgYXJjaGl2ZWQgYXQgPHNwYW4+PGEgaHJl
Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9KU09OcGF0aC8iPmh0
dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvSlNPTnBhdGgvPC9hPjwvc3Bh
bj4uPGEgaHJlZj0iI3NlY3Rpb24tbm90ZS4xLTMiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+
CjxwIGlkPSJzZWN0aW9uLW5vdGUuMS00Ij5Tb3VyY2UgZm9yIHRoaXMgZHJhZnQgYW5kIGFuIGlz
c3VlIHRyYWNrZXIgY2FuIGJlIGZvdW5kIGF0CiAgICAgICAgPHNwYW4+PGEgaHJlZj0iaHR0cHM6
Ly9naXRodWIuY29tL2NhYm8vaXJlZ2V4cCI+aHR0cHM6Ly9naXRodWIuY29tL2NhYm8vaXJlZ2V4
cDwvYT48L3NwYW4+LjxhIGhyZWY9IiNzZWN0aW9uLW5vdGUuMS00IiBjbGFzcz0icGlsY3JvdyI+
wrY8L2E+PC9wPgo8L3NlY3Rpb24+CjxkaXYgaWQ9InN0YXR1cy1vZi1tZW1vIj4KPHNlY3Rpb24g
aWQ9InNlY3Rpb24tYm9pbGVycGxhdGUuMSI+CiAgICAgICAgPGgyIGlkPSJuYW1lLXN0YXR1cy1v
Zi10aGlzLW1lbW8iPgo8YSBocmVmPSIjbmFtZS1zdGF0dXMtb2YtdGhpcy1tZW1vIiBjbGFzcz0i
c2VjdGlvbi1uYW1lIHNlbGZSZWYiPlN0YXR1cyBvZiBUaGlzIE1lbW88L2E+CiAgICAgICAgPC9o
Mj4KPHAgaWQ9InNlY3Rpb24tYm9pbGVycGxhdGUuMS0xIj4KICAgICAgICBUaGlzIEludGVybmV0
LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgICAgICAg
cHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS48YSBocmVmPSIjc2VjdGlvbi1ib2lsZXJw
bGF0ZS4xLTEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+CjxwIGlkPSJzZWN0aW9uLWJvaWxl
cnBsYXRlLjEtMiI+CiAgICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50
cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzawogICAgICAgIEZvcmNlIChJRVRGKS4g
Tm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcKICAgICAg
ICBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy
bmV0LURyYWZ0cyBpcwogICAgICAgIGF0IDxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RyYWZ0cy9jdXJyZW50LzwvYT48L3NwYW4+LjxhIGhyZWY9IiNzZWN0aW9uLWJvaWxlcnBsYXRl
LjEtMiIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24tYm9pbGVycGxh
dGUuMS0zIj4KICAgICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp
ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgICAgICBhbmQgbWF5IGJlIHVwZGF0ZWQs
IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICAgICAg
IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl
cmVuY2UKICAgICAgICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y
ayBpbiBwcm9ncmVzcy4iPGEgaHJlZj0iI3NlY3Rpb24tYm9pbGVycGxhdGUuMS0zIiBjbGFzcz0i
cGlsY3JvdyI+wrY8L2E+PC9wPgo8cCBpZD0ic2VjdGlvbi1ib2lsZXJwbGF0ZS4xLTQiPgogICAg
ICAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gMjIgSnVseSAyMDIyLjxhIGhy
ZWY9IiNzZWN0aW9uLWJvaWxlcnBsYXRlLjEtNCIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4K
PC9zZWN0aW9uPgo8L2Rpdj4KPGRpdiBpZD0iY29weXJpZ2h0Ij4KPHNlY3Rpb24gaWQ9InNlY3Rp
b24tYm9pbGVycGxhdGUuMiI+CiAgICAgICAgPGgyIGlkPSJuYW1lLWNvcHlyaWdodC1ub3RpY2Ui
Pgo8YSBocmVmPSIjbmFtZS1jb3B5cmlnaHQtbm90aWNlIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNl
bGZSZWYiPkNvcHlyaWdodCBOb3RpY2U8L2E+CiAgICAgICAgPC9oMj4KPHAgaWQ9InNlY3Rpb24t
Ym9pbGVycGxhdGUuMi0xIj4KICAgICAgICAgICAgQ29weXJpZ2h0IChjKSAyMDIyIElFVEYgVHJ1
c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgICAgICAgICAgIGRvY3VtZW50
IGF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuPGEgaHJlZj0iI3NlY3Rpb24tYm9pbGVycGxh
dGUuMi0xIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8cCBpZD0ic2VjdGlvbi1ib2lsZXJw
bGF0ZS4yLTIiPgogICAgICAgICAgICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4
IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgICAgICAgICAgIFByb3Zpc2lvbnMgUmVsYXRp
bmcgdG8gSUVURiBEb2N1bWVudHMKICAgICAgICAgICAgKDxzcGFuPjxhIGhyZWY9Imh0dHBzOi8v
dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8iPmh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9s
aWNlbnNlLWluZm88L2E+PC9zcGFuPikgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgICAgICAg
ICAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j
dW1lbnRzCiAgICAgICAgICAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0
cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgKICAgICAgICAgICAgcmVzcGVjdCB0byB0aGlzIGRvY3Vt
ZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcwogICAgICAgICAgICBkb2N1
bWVudCBtdXN0IGluY2x1ZGUgUmV2aXNlZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp
bgogICAgICAgICAgICBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBh
bmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQKICAgICAgICAgICAgd2FycmFudHkgYXMgZGVzY3JpYmVk
IGluIHRoZSBSZXZpc2VkIEJTRCBMaWNlbnNlLjxhIGhyZWY9IiNzZWN0aW9uLWJvaWxlcnBsYXRl
LjItMiIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPC9zZWN0aW9uPgo8L2Rpdj4KPGRpdiBp
ZD0idG9jIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tdG9jLjEiPgogICAgICAgIDxhIGhyZWY9IiMi
IG9uY2xpY2s9InNjcm9sbCgwLDApIiBjbGFzcz0idG9wbGluayI+4payPC9hPjxoMiBpZD0ibmFt
ZS10YWJsZS1vZi1jb250ZW50cyI+CjxhIGhyZWY9IiNuYW1lLXRhYmxlLW9mLWNvbnRlbnRzIiBj
bGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPlRhYmxlIG9mIENvbnRlbnRzPC9hPgogICAgICAg
IDwvaDI+CjxuYXYgY2xhc3M9InRvYyI+PHVsIGNsYXNzPSJjb21wYWN0IHRvYyB1bEJhcmUgdWxF
bXB0eSI+CjxsaSBjbGFzcz0iY29tcGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiIGlkPSJzZWN0aW9u
LXRvYy4xLTEuMSI+CiAgICAgICAgICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuMS4xIiBjbGFz
cz0ia2VlcFdpdGhOZXh0Ij48YSBocmVmPSIjc2VjdGlvbi0xIiBjbGFzcz0ieHJlZiI+MTwvYT4u
wqDCoDxhIGhyZWY9IiNuYW1lLWludHJvZHVjdGlvbiIgY2xhc3M9InhyZWYiPkludHJvZHVjdGlv
bjwvYT48L3A+CjwvbGk+CiAgICAgICAgICA8bGkgY2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1
bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjIiPgogICAgICAgICAgICA8cCBpZD0ic2VjdGlv
bi10b2MuMS0xLjIuMSIgY2xhc3M9ImtlZXBXaXRoTmV4dCI+PGEgaHJlZj0iI3NlY3Rpb24tMiIg
Y2xhc3M9InhyZWYiPjI8L2E+LsKgwqA8YSBocmVmPSIjbmFtZS1yZXF1aXJlbWVudHMiIGNsYXNz
PSJ4cmVmIj5SZXF1aXJlbWVudHM8L2E+PC9wPgo8L2xpPgogICAgICAgICAgPGxpIGNsYXNzPSJj
b21wYWN0IHRvYyB1bEJhcmUgdWxFbXB0eSIgaWQ9InNlY3Rpb24tdG9jLjEtMS4zIj4KICAgICAg
ICAgICAgPHAgaWQ9InNlY3Rpb24tdG9jLjEtMS4zLjEiIGNsYXNzPSJrZWVwV2l0aE5leHQiPjxh
IGhyZWY9IiNzZWN0aW9uLTMiIGNsYXNzPSJ4cmVmIj4zPC9hPi7CoMKgPGEgaHJlZj0iI25hbWUt
aS1yZWdleHAtc3ludGF4IiBjbGFzcz0ieHJlZiI+SS1SZWdleHAgU3ludGF4PC9hPjwvcD4KPC9s
aT4KICAgICAgICAgIDxsaSBjbGFzcz0iY29tcGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiIGlkPSJz
ZWN0aW9uLXRvYy4xLTEuNCI+CiAgICAgICAgICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuNC4x
Ij48YSBocmVmPSIjc2VjdGlvbi00IiBjbGFzcz0ieHJlZiI+NDwvYT4uwqDCoDxhIGhyZWY9IiNu
YW1lLWktcmVnZXhwLXNlbWFudGljcyIgY2xhc3M9InhyZWYiPkktUmVnZXhwIFNlbWFudGljczwv
YT48L3A+CjwvbGk+CiAgICAgICAgICA8bGkgY2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVt
cHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjUiPgogICAgICAgICAgICA8cCBpZD0ic2VjdGlvbi10
b2MuMS0xLjUuMSI+PGEgaHJlZj0iI3NlY3Rpb24tNSIgY2xhc3M9InhyZWYiPjU8L2E+LsKgwqA8
YSBocmVmPSIjbmFtZS1tYXBwaW5nLWktcmVnZXhwLXRvLXJlZ2V4cC0iIGNsYXNzPSJ4cmVmIj5N
YXBwaW5nIEktUmVnZXhwIHRvIFJlZ2V4cCBEaWFsZWN0czwvYT48L3A+Cjx1bCBjbGFzcz0iY29t
cGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiPgo8bGkgY2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1
bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjUuMi4xIj4KICAgICAgICAgICAgICAgIDxwIGlk
PSJzZWN0aW9uLXRvYy4xLTEuNS4yLjEuMSI+PGEgaHJlZj0iI3NlY3Rpb24tNS4xIiBjbGFzcz0i
eHJlZiI+NS4xPC9hPi7CoMKgPGEgaHJlZj0iI25hbWUteHNkLXJlZ2V4cHMiIGNsYXNzPSJ4cmVm
Ij5YU0QgUmVnZXhwczwvYT48L3A+CjwvbGk+CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJjb21w
YWN0IHRvYyB1bEJhcmUgdWxFbXB0eSIgaWQ9InNlY3Rpb24tdG9jLjEtMS41LjIuMiI+CiAgICAg
ICAgICAgICAgICA8cCBpZD0ic2VjdGlvbi10b2MuMS0xLjUuMi4yLjEiPjxhIGhyZWY9IiNzZWN0
aW9uLTUuMiIgY2xhc3M9InhyZWYiPjUuMjwvYT4uwqDCoDxhIGhyZWY9IiNuYW1lLWVjbWFzY3Jp
cHQtcmVnZXhwcyIgY2xhc3M9InhyZWYiPkVDTUFTY3JpcHQgUmVnZXhwczwvYT48L3A+CjwvbGk+
CiAgICAgICAgICAgICAgPGxpIGNsYXNzPSJjb21wYWN0IHRvYyB1bEJhcmUgdWxFbXB0eSIgaWQ9
InNlY3Rpb24tdG9jLjEtMS41LjIuMyI+CiAgICAgICAgICAgICAgICA8cCBpZD0ic2VjdGlvbi10
b2MuMS0xLjUuMi4zLjEiPjxhIGhyZWY9IiNzZWN0aW9uLTUuMyIgY2xhc3M9InhyZWYiPjUuMzwv
YT4uwqDCoDxhIGhyZWY9IiNuYW1lLXBjcmUtcmUyLXJ1YnktcmVnZXhwcyIgY2xhc3M9InhyZWYi
PlBDUkUsIFJFMiwgUnVieSBSZWdleHBzPC9hPjwvcD4KPC9saT4KICAgICAgICAgICAgICA8bGkg
Y2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjUu
Mi40Ij4KICAgICAgICAgICAgICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuNS4yLjQuMSI+PGEg
aHJlZj0iI3NlY3Rpb24tNS40IiBjbGFzcz0ieHJlZiI+NS40PC9hPi7CoMKgPGEgaHJlZj0iI25h
bWUteW91ci1raW5kLW9mLXJlZ2V4cC1oZXJlIiBjbGFzcz0ieHJlZiI+Jmx0OyZsdDsgWW91ciBr
aW5kIG9mIFJlZ2V4cCBoZXJlICZndDsmZ3Q7PC9hPjwvcD4KPC9saT4KICAgICAgICAgICAgPC91
bD4KPC9saT4KICAgICAgICAgIDxsaSBjbGFzcz0iY29tcGFjdCB0b2MgdWxCYXJlIHVsRW1wdHki
IGlkPSJzZWN0aW9uLXRvYy4xLTEuNiI+CiAgICAgICAgICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4x
LTEuNi4xIj48YSBocmVmPSIjc2VjdGlvbi02IiBjbGFzcz0ieHJlZiI+NjwvYT4uwqDCoDxhIGhy
ZWY9IiNuYW1lLW1vdGl2YXRpb24tYW5kLWJhY2tncm91bmQiIGNsYXNzPSJ4cmVmIj5Nb3RpdmF0
aW9uIGFuZCBCYWNrZ3JvdW5kPC9hPjwvcD4KPHVsIGNsYXNzPSJjb21wYWN0IHRvYyB1bEJhcmUg
dWxFbXB0eSI+CjxsaSBjbGFzcz0iY29tcGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiIGlkPSJzZWN0
aW9uLXRvYy4xLTEuNi4yLjEiPgogICAgICAgICAgICAgICAgPHAgaWQ9InNlY3Rpb24tdG9jLjEt
MS42LjIuMS4xIj48YSBocmVmPSIjc2VjdGlvbi02LjEiIGNsYXNzPSJ4cmVmIj42LjE8L2E+LsKg
wqA8YSBocmVmPSIjbmFtZS1zdWJzZXR0aW5nLXhzZC1yZWdleHBzIiBjbGFzcz0ieHJlZiI+U3Vi
c2V0dGluZyBYU0QgUmVnZXhwczwvYT48L3A+CjwvbGk+CiAgICAgICAgICAgIDwvdWw+CjwvbGk+
CiAgICAgICAgICA8bGkgY2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVtcHR5IiBpZD0ic2Vj
dGlvbi10b2MuMS0xLjciPgogICAgICAgICAgICA8cCBpZD0ic2VjdGlvbi10b2MuMS0xLjcuMSI+
PGEgaHJlZj0iI3NlY3Rpb24tNyIgY2xhc3M9InhyZWYiPjc8L2E+LsKgwqA8YSBocmVmPSIjbmFt
ZS1pYW5hLWNvbnNpZGVyYXRpb25zIiBjbGFzcz0ieHJlZiI+SUFOQSBDb25zaWRlcmF0aW9uczwv
YT48L3A+CjwvbGk+CiAgICAgICAgICA8bGkgY2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVt
cHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjgiPgogICAgICAgICAgICA8cCBpZD0ic2VjdGlvbi10
b2MuMS0xLjguMSI+PGEgaHJlZj0iI3NlY3Rpb24tOCIgY2xhc3M9InhyZWYiPjg8L2E+LsKgwqA8
YSBocmVmPSIjbmFtZS1zZWN1cml0eS1jb25zaWRlcmF0aW9ucyIgY2xhc3M9InhyZWYiPlNlY3Vy
aXR5IGNvbnNpZGVyYXRpb25zPC9hPjwvcD4KPC9saT4KICAgICAgICAgIDxsaSBjbGFzcz0iY29t
cGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiIGlkPSJzZWN0aW9uLXRvYy4xLTEuOSI+CiAgICAgICAg
ICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuOS4xIj48YSBocmVmPSIjc2VjdGlvbi05IiBjbGFz
cz0ieHJlZiI+OTwvYT4uwqDCoDxhIGhyZWY9IiNuYW1lLXJlZmVyZW5jZXMiIGNsYXNzPSJ4cmVm
Ij5SZWZlcmVuY2VzPC9hPjwvcD4KPHVsIGNsYXNzPSJjb21wYWN0IHRvYyB1bEJhcmUgdWxFbXB0
eSI+CjxsaSBjbGFzcz0iY29tcGFjdCB0b2MgdWxCYXJlIHVsRW1wdHkiIGlkPSJzZWN0aW9uLXRv
Yy4xLTEuOS4yLjEiPgogICAgICAgICAgICAgICAgPHAgaWQ9InNlY3Rpb24tdG9jLjEtMS45LjIu
MS4xIj48YSBocmVmPSIjc2VjdGlvbi05LjEiIGNsYXNzPSJ4cmVmIj45LjE8L2E+LsKgwqA8YSBo
cmVmPSIjbmFtZS1ub3JtYXRpdmUtcmVmZXJlbmNlcyIgY2xhc3M9InhyZWYiPk5vcm1hdGl2ZSBS
ZWZlcmVuY2VzPC9hPjwvcD4KPC9saT4KICAgICAgICAgICAgICA8bGkgY2xhc3M9ImNvbXBhY3Qg
dG9jIHVsQmFyZSB1bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjkuMi4yIj4KICAgICAgICAg
ICAgICAgIDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuOS4yLjIuMSI+PGEgaHJlZj0iI3NlY3Rpb24t
OS4yIiBjbGFzcz0ieHJlZiI+OS4yPC9hPi7CoMKgPGEgaHJlZj0iI25hbWUtaW5mb3JtYXRpdmUt
cmVmZXJlbmNlcyIgY2xhc3M9InhyZWYiPkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L2E+PC9wPgo8
L2xpPgogICAgICAgICAgICA8L3VsPgo8L2xpPgogICAgICAgICAgPGxpIGNsYXNzPSJjb21wYWN0
IHRvYyB1bEJhcmUgdWxFbXB0eSIgaWQ9InNlY3Rpb24tdG9jLjEtMS4xMCI+CiAgICAgICAgICAg
IDxwIGlkPSJzZWN0aW9uLXRvYy4xLTEuMTAuMSI+PGEgaHJlZj0iI2FwcGVuZGl4LUEiIGNsYXNz
PSJ4cmVmIj5BcHBlbmRpeCBBPC9hPi7CoMKgPGEgaHJlZj0iI25hbWUtcmVnZXhwcy1hbmQtc2lt
aWxhci1jb25zdHJ1IiBjbGFzcz0ieHJlZiI+UmVnZXhwcyBhbmQgU2ltaWxhciBDb25zdHJ1Y3Rz
IGluIFJlY2VudCBQdWJsaXNoZWQgUkZDczwvYT48L3A+CjwvbGk+CiAgICAgICAgICA8bGkgY2xh
c3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjExIj4K
ICAgICAgICAgICAgPHAgaWQ9InNlY3Rpb24tdG9jLjEtMS4xMS4xIj48YSBocmVmPSIjYXBwZW5k
aXgtQiIgY2xhc3M9InhyZWYiPjwvYT48YSBocmVmPSIjbmFtZS1hY2tub3dsZWRnZW1lbnRzIiBj
bGFzcz0ieHJlZiI+QWNrbm93bGVkZ2VtZW50czwvYT48L3A+CjwvbGk+CiAgICAgICAgICA8bGkg
Y2xhc3M9ImNvbXBhY3QgdG9jIHVsQmFyZSB1bEVtcHR5IiBpZD0ic2VjdGlvbi10b2MuMS0xLjEy
Ij4KICAgICAgICAgICAgPHAgaWQ9InNlY3Rpb24tdG9jLjEtMS4xMi4xIj48YSBocmVmPSIjYXBw
ZW5kaXgtQyIgY2xhc3M9InhyZWYiPjwvYT48YSBocmVmPSIjbmFtZS1hdXRob3JzLWFkZHJlc3Mi
IGNsYXNzPSJ4cmVmIj5BdXRob3IncyBBZGRyZXNzPC9hPjwvcD4KPC9saT4KICAgICAgICA8L3Vs
Pgo8L25hdj4KPC9zZWN0aW9uPgo8L2Rpdj4KPGRpdiBpZD0iaW50cm8iPgo8c2VjdGlvbiBpZD0i
c2VjdGlvbi0xIj4KICAgICAgPGgyIGlkPSJuYW1lLWludHJvZHVjdGlvbiI+CjxhIGhyZWY9IiNz
ZWN0aW9uLTEiIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj4xLiA8L2E+PGEgaHJlZj0i
I25hbWUtaW50cm9kdWN0aW9uIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPkludHJvZHVj
dGlvbjwvYT4KICAgICAgPC9oMj4KPHAgaWQ9InNlY3Rpb24tMS0xIj5UaGUgcHJlc2VudCBzcGVj
aWZpY2F0aW9uIGRlZmluZXMgYW4gaW50ZXJvcGVyYWJsZSByZWd1bGFyIGV4cHJlc3Npb24gZmxh
dm9yLCBJLVJlZ2V4cC48YSBocmVmPSIjc2VjdGlvbi0xLTEiIGNsYXNzPSJwaWxjcm93Ij7Ctjwv
YT48L3A+CjxwIGlkPSJzZWN0aW9uLTEtMiI+VGhpcyBkb2N1bWVudCB1c2VzIHRoZSBhYmJyZXZp
YXRpb24gInJlZ2V4cCIgZm9yIHJlZ3VsYXIgZXhwcmVzc2lvbi4KIkktUmVnZXhwIiBpcyB1c2Vk
IGFzIGEgbm91biBtZWFuaW5nIGEgY2hhcmFjdGVyIHN0cmluZyB3aGljaCBjb25mb3JtcyB0byB0
aGUgcmVxdWlyZW1lbnRzCmluIHRoaXMgc3BlY2lmaWNhdGlvbjsgdGhlIHBsdXJhbCBpcyAiSS1S
ZWdleHBzIi48YSBocmVmPSIjc2VjdGlvbi0xLTIiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+
CjxwIGlkPSJzZWN0aW9uLTEtMyI+SS1SZWdleHAgZG9lcyBub3QgcHJvdmlkZSBhZHZhbmNlZCBy
ZWdleHAgZmVhdHVyZXMgc3VjaCBhcyBjYXB0dXJlIGdyb3VwcyBvciBiYWNrcmVmZXJlbmNlcy4K
SXQgc3VwcG9ydHMgb25seSBhIEJvb2xlYW4gbWF0Y2hpbmcgY2FwYWJpbGl0eSwgaS5lLiB0ZXN0
aW5nIHdoZXRoZXIgYSBnaXZlbiByZWdleHAgbWF0Y2hlcyBhIGdpdmVuIHBpZWNlIG9mIHRleHQu
PGEgaHJlZj0iI3NlY3Rpb24tMS0zIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8cCBpZD0i
c2VjdGlvbi0xLTQiPkktUmVnZXhwIGlzIGEgc3Vic2V0IG9mIFhTRCByZWdleHBzLjxhIGhyZWY9
IiNzZWN0aW9uLTEtNCIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24t
MS01Ij5UaGlzIGRvY3VtZW50IGluY2x1ZGVzIHJ1bGVzIGZvciBjb252ZXJ0aW5nIEktUmVnZXhw
cyBmb3IgdXNlIHdpdGggc2V2ZXJhbCB3ZWxsLWtub3duIHJlZ2V4cCBsaWJyYXJpZXMuPGEgaHJl
Zj0iI3NlY3Rpb24tMS01IiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+Cjwv
ZGl2Pgo8ZGl2IGlkPSJyZXF1aXJlbWVudHMiPgo8c2VjdGlvbiBpZD0ic2VjdGlvbi0yIj4KICAg
ICAgPGgyIGlkPSJuYW1lLXJlcXVpcmVtZW50cyI+CjxhIGhyZWY9IiNzZWN0aW9uLTIiIGNsYXNz
PSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj4yLiA8L2E+PGEgaHJlZj0iI25hbWUtcmVxdWlyZW1l
bnRzIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPlJlcXVpcmVtZW50czwvYT4KICAgICAg
PC9oMj4KPHAgaWQ9InNlY3Rpb24tMi0xIj5JLVJlZ2V4cHMgc2hvdWxkIGhhbmRsZSB0aGUgdmFz
dCBtYWpvcml0eSBvZiBwcmFjdGljYWwgY2FzZXMgd2hlcmUgYQptYXRjaGluZyByZWdleHAgaXMg
bmVlZGVkIGluIGEgZGF0YSBtb2RlbCBzcGVjaWZpY2F0aW9uIG9yIGEgcXVlcnkKbGFuZ3VhZ2Ug
ZXhwcmVzc2lvbi48YSBocmVmPSIjc2VjdGlvbi0yLTEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48
L3A+CjxwIGlkPSJzZWN0aW9uLTItMiI+QSBicmllZiBzdXJ2ZXkgb2YgcHVibGlzaGVkIFJGQ3Mg
eWllbGRlZCB0aGUgcmVnZXhwIHBhdHRlcm5zIGluCkFwcGVuZGl4IEEgKHdpdGggbm8gYXR0ZW1w
dCBhdCBjb21wbGV0ZW5lc3MpLgpUaGVzZSBzaG91bGQgYmUgY292ZXJlZCBieSBJLVJlZ2V4cHMs
IGJvdGggc3ludGFjdGljYWxseSBhbmQgd2l0aAp0aGVpciBpbnRlbmRlZCBzZW1hbnRpY3MuPGEg
aHJlZj0iI3NlY3Rpb24tMi0yIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+
CjwvZGl2Pgo8ZGl2IGlkPSJkZWZuIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tMyI+CiAgICAgIDxo
MiBpZD0ibmFtZS1pLXJlZ2V4cC1zeW50YXgiPgo8YSBocmVmPSIjc2VjdGlvbi0zIiBjbGFzcz0i
c2VjdGlvbi1udW1iZXIgc2VsZlJlZiI+My4gPC9hPjxhIGhyZWY9IiNuYW1lLWktcmVnZXhwLXN5
bnRheCIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5JLVJlZ2V4cCBTeW50YXg8L2E+CiAg
ICAgIDwvaDI+CjxwIGlkPSJzZWN0aW9uLTMtMSI+QW4gSS1SZWdleHAgTVVTVCBjb25mb3JtIHRv
IHRoZSBBQk5GIHNwZWNpZmljYXRpb24gaW4KPGEgaHJlZj0iI2lyZWdleHAtYWJuZiIgY2xhc3M9
InhyZWYiPkZpZ3VyZSAxPC9hPi48YSBocmVmPSIjc2VjdGlvbi0zLTEiIGNsYXNzPSJwaWxjcm93
Ij7CtjwvYT48L3A+CjxkaXYgaWQ9ImlyZWdleHAtYWJuZiI+CjxmaWd1cmUgaWQ9ImZpZ3VyZS0x
Ij4KICAgICAgICA8ZGl2IGlkPSJzZWN0aW9uLTMtMi4xIj4KPHByZSBjbGFzcz0ibGFuZy1hYm5m
IHNvdXJjZWNvZGUiPgppLXJlZ2V4cCA9IGJyYW5jaCAqKCAifCIgYnJhbmNoICkKYnJhbmNoID0g
KnBpZWNlCnBpZWNlID0gYXRvbSBbIHF1YW50aWZpZXIgXQpxdWFudGlmaWVyID0gKCAleDJBLTJC
IDsgJyonLScrJwogLyAiPyIgKSAvICggInsiIHF1YW50aXR5ICJ9IiApCnF1YW50aXR5ID0gUXVh
bnRFeGFjdCBbICIsIiBbIFF1YW50RXhhY3QgXSBdClF1YW50RXhhY3QgPSAxKiV4MzAtMzkgOyAn
MCctJzknCgphdG9tID0gTm9ybWFsQ2hhciAvIGNoYXJDbGFzcyAvICggIigiIGktcmVnZXhwICIp
IiApCk5vcm1hbENoYXIgPSAoICV4MDAtMjcgLyAleDJDLTJEIDsgJywnLSctJwogLyAleDJGLTNF
IDsgJy8nLScmZ3Q7JwogLyAleDQwLTVBIDsgJ0AnLSdaJwogLyAleDVFLTdBIDsgJ14nLSd6Jwog
LyAleDdFLTEwRkZGRiApCmNoYXJDbGFzcyA9ICIuIiAvIFNpbmdsZUNoYXJFc2MgLyBjaGFyQ2xh
c3NFc2MgLyBjaGFyQ2xhc3NFeHByClNpbmdsZUNoYXJFc2MgPSAiXCIgKCAleDI4LTJCIDsgJygn
LScrJwogLyAleDJELTJFIDsgJy0nLScuJwogLyAiPyIgLyAleDVCLTVFIDsgJ1snLSdeJwogLyAl
cyJuIiAvICVzInIiIC8gJXMidCIgLyAleDdCLTdEIDsgJ3snLSd9JwogKQpjaGFyQ2xhc3NFc2Mg
PSBjYXRFc2MgLyBjb21wbEVzYwpjaGFyQ2xhc3NFeHByID0gIlsiIFsgIl4iIF0gKCAiLSIgLyBD
Q0UxICkgKkNDRTEgWyAiLSIgXSAiXSIKQ0NFMSA9ICggQ0NjaGFyIFsgIi0iIENDY2hhciBdICkg
LyBjaGFyQ2xhc3NFc2MKQ0NjaGFyID0gKCAleDAwLTJDIC8gJXgyRS01QSA7ICcuJy0nWicKIC8g
JXg1RS0xMEZGRkYgKSAvIFNpbmdsZUNoYXJFc2MKY2F0RXNjID0gJXMiXHB7IiBjaGFyUHJvcCAi
fSIKY29tcGxFc2MgPSAlcyJcUHsiIGNoYXJQcm9wICJ9IgpjaGFyUHJvcCA9IElzQ2F0ZWdvcnkg
LyBJc0Jsb2NrCklzQ2F0ZWdvcnkgPSBMZXR0ZXJzIC8gTWFya3MgLyBOdW1iZXJzIC8gUHVuY3R1
YXRpb24gLyBTZXBhcmF0b3JzIC8KICAgIFN5bWJvbHMgLyBPdGhlcnMKTGV0dGVycyA9ICVzIkwi
IFsgKCAleDZDLTZEIDsgJ2wnLSdtJwogLyAlcyJvIiAvICV4NzQtNzUgOyAndCctJ3UnCiApIF0K
TWFya3MgPSAlcyJNIiBbICggJXMiYyIgLyAlcyJlIiAvICVzIm4iICkgXQpOdW1iZXJzID0gJXMi
TiIgWyAoICVzImQiIC8gJXMibCIgLyAlcyJvIiApIF0KUHVuY3R1YXRpb24gPSAlcyJQIiBbICgg
JXg2My02NiA7ICdjJy0nZicKIC8gJXMiaSIgLyAlcyJvIiAvICVzInMiICkgXQpTZXBhcmF0b3Jz
ID0gJXMiWiIgWyAoICVzImwiIC8gJXMicCIgLyAlcyJzIiApIF0KU3ltYm9scyA9ICVzIlMiIFsg
KCAlcyJjIiAvICVzImsiIC8gJXMibSIgLyAlcyJvIiApIF0KT3RoZXJzID0gJXMiQyIgWyAoICVz
ImMiIC8gJXMiZiIgLyAleDZFLTZGIDsgJ24nLSdvJwogKSBdCklzQmxvY2sgPSAlcyJJcyIgMSoo
ICItIiAvICV4MzAtMzkgOyAnMCctJzknCiAvICV4NDEtNUEgOyAnQSctJ1onCiAvICV4NjEtN0Eg
OyAnYSctJ3onCiApCjwvcHJlPgo8L2Rpdj4KPGZpZ2NhcHRpb24+PGEgaHJlZj0iI2ZpZ3VyZS0x
IiBjbGFzcz0ic2VsZlJlZiI+RmlndXJlIDE8L2E+PC9maWdjYXB0aW9uPjwvZmlndXJlPgo8L2Rp
dj4KPHAgaWQ9InNlY3Rpb24tMy0zIj5UaGlzIGlzIGVzc2VudGlhbGx5IFhTRCByZWdleHAgd2l0
aG91dCBjaGFyYWN0ZXIgY2xhc3MKc3VidHJhY3Rpb24gYW5kIG11bHRpLWNoYXJhY3RlciBlc2Nh
cGVzLjxhIGhyZWY9IiNzZWN0aW9uLTMtMyIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHVs
IGNsYXNzPSJub3JtYWwiPgo8bGkgY2xhc3M9Im5vcm1hbCIgaWQ9InNlY3Rpb24tMy00LjEiPgog
ICAgICAgICAgPHN0cm9uZz5Jc3N1ZTwvc3Ryb25nPjogVGhlcmUgbWlnaHQgYmUgZnVydGhlciBw
b3RlbnRpYWwgZm9yIHNpbXBsaWZpY2F0aW9uIGluIElzQmxvY2sgKGxlYXZlCm91dCkgYW5kIHBv
c3NpYmx5IGluIHRoZSByYXRoZXIgbGFyZ2UgcGFydCBmb3IgSXNDYXRlZ29yeSBhcyB3ZWxsLgpU
aGUgQUJORiBoYXMgYmVlbiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBhbmQgbWF5YmUgY291bGQg
dXNlIHNvbWUKcG9saXNoaW5nLgpUaGUgQUJORiBoYXMgYmVlbiB2ZXJpZmllZCBhZ2FpbnN0IDxh
IGhyZWY9IiNyZmNzIiBjbGFzcz0ieHJlZiI+QXBwZW5kaXggQTwvYT4sIGJ1dCBhIHdpZGVyIGNv
cnB1cyBvZgpyZWd1bGFyIGV4cHJlc3Npb25zIHNob3VsZCBiZSBleGFtaW5lZC4KQWJvdXQgYSB0
aGlyZCBvZiB0aGUgY29tcGxleGl0eSBvZiB0aGlzIEFCTkYgZ3JhbW1hciBjb21lcyBmcm9tIGdv
aW5nCmludG8gZGV0YWlscyBvbiB0aGUgVW5pY29kZSBJc0NhdGVnb3J5IGNsYXNzZXMuICBBZGRp
dGlvbmFsIGNvbXBsZXhpdHkKc3RlbXMgZnJvbSB0aGUgd2F5IGh5cGhlbnMgY2FuIGJlIHVzZWQg
aW5zaWRlIGNoYXJhY3RlciBjbGFzc2VzIHRvIGRlbm90ZQpyYW5nZXM7IHRoZSBncmFtbWFyIGRl
bGliZXJhdGVseSBleGNsdWRlcyBxdWVzdGlvbmFibGUgdXNhZ2Ugc3VjaCBhcwo8Y29kZT4vW2Et
ei1BLVpdLzwvY29kZT4uPGEgaHJlZj0iI3NlY3Rpb24tMy00LjEiIGNsYXNzPSJwaWxjcm93Ij7C
tjwvYT4KPC9saT4KICAgICAgPC91bD4KPC9zZWN0aW9uPgo8L2Rpdj4KPGRpdiBpZD0iaS1yZWdl
eHAtc2VtYW50aWNzIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tNCI+CiAgICAgIDxoMiBpZD0ibmFt
ZS1pLXJlZ2V4cC1zZW1hbnRpY3MiPgo8YSBocmVmPSIjc2VjdGlvbi00IiBjbGFzcz0ic2VjdGlv
bi1udW1iZXIgc2VsZlJlZiI+NC4gPC9hPjxhIGhyZWY9IiNuYW1lLWktcmVnZXhwLXNlbWFudGlj
cyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5JLVJlZ2V4cCBTZW1hbnRpY3M8L2E+CiAg
ICAgIDwvaDI+CjxwIGlkPSJzZWN0aW9uLTQtMSI+VGhpcyBzeW50YXggaXMgYSBzdWJzZXQgb2Yg
dGhhdCBvZiA8c3Bhbj5bPGEgaHJlZj0iI1hTRDIiIGNsYXNzPSJ4cmVmIj5YU0QyPC9hPl08L3Nw
YW4+LgpJbXBsZW1lbnRhdGlvbnMgd2hpY2ggaW50ZXJwcmV0IEktUmVnZXhwcyBNVVNUCnlpZWxk
IEJvb2xlYW4gcmVzdWx0cyBhcyBzcGVjaWZpZWQgaW4gPHNwYW4+WzxhIGhyZWY9IiNYU0QyIiBj
bGFzcz0ieHJlZiI+WFNEMjwvYT5dPC9zcGFuPi48YSBocmVmPSIjc2VjdGlvbi00LTEiIGNsYXNz
PSJwaWxjcm93Ij7CtjwvYT48L3A+Cjwvc2VjdGlvbj4KPC9kaXY+CjxkaXYgaWQ9Im1hcHBpbmct
aS1yZWdleHAtdG8tcmVnZXhwLWRpYWxlY3RzIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tNSI+CiAg
ICAgIDxoMiBpZD0ibmFtZS1tYXBwaW5nLWktcmVnZXhwLXRvLXJlZ2V4cC0iPgo8YSBocmVmPSIj
c2VjdGlvbi01IiBjbGFzcz0ic2VjdGlvbi1udW1iZXIgc2VsZlJlZiI+NS4gPC9hPjxhIGhyZWY9
IiNuYW1lLW1hcHBpbmctaS1yZWdleHAtdG8tcmVnZXhwLSIgY2xhc3M9InNlY3Rpb24tbmFtZSBz
ZWxmUmVmIj5NYXBwaW5nIEktUmVnZXhwIHRvIFJlZ2V4cCBEaWFsZWN0czwvYT4KICAgICAgPC9o
Mj4KPHAgaWQ9InNlY3Rpb24tNS0xIj4oVEJEOyB0aGVzZSBtYXBwaW5ncyBuZWVkIHRvIGJlIHRo
b3JvdWdobHkgdmVyaWZpZWQuKTxhIGhyZWY9IiNzZWN0aW9uLTUtMSIgY2xhc3M9InBpbGNyb3ci
PsK2PC9hPjwvcD4KPGRpdiBpZD0ieHNkLXJlZ2V4cHMiPgo8c2VjdGlvbiBpZD0ic2VjdGlvbi01
LjEiPgogICAgICAgIDxoMyBpZD0ibmFtZS14c2QtcmVnZXhwcyI+CjxhIGhyZWY9IiNzZWN0aW9u
LTUuMSIgY2xhc3M9InNlY3Rpb24tbnVtYmVyIHNlbGZSZWYiPjUuMS4gPC9hPjxhIGhyZWY9IiNu
YW1lLXhzZC1yZWdleHBzIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPlhTRCBSZWdleHBz
PC9hPgogICAgICAgIDwvaDM+CjxwIGlkPSJzZWN0aW9uLTUuMS0xIj5BbnkgSS1SZWdleHAgYWxz
byBpcyBhbiBYU0QgUmVnZXhwIDxzcGFuPls8YSBocmVmPSIjWFNEMiIgY2xhc3M9InhyZWYiPlhT
RDI8L2E+XTwvc3Bhbj4sIHNvIHRoZSBtYXBwaW5nIGlzIGFuIGlkZW50aXR5CmZ1bmN0aW9uLjxh
IGhyZWY9IiNzZWN0aW9uLTUuMS0xIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rp
b24+CjwvZGl2Pgo8ZGl2IGlkPSJ0b0VTcmVnIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tNS4yIj4K
ICAgICAgICA8aDMgaWQ9Im5hbWUtZWNtYXNjcmlwdC1yZWdleHBzIj4KPGEgaHJlZj0iI3NlY3Rp
b24tNS4yIiBjbGFzcz0ic2VjdGlvbi1udW1iZXIgc2VsZlJlZiI+NS4yLiA8L2E+PGEgaHJlZj0i
I25hbWUtZWNtYXNjcmlwdC1yZWdleHBzIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZSZWYiPkVD
TUFTY3JpcHQgUmVnZXhwczwvYT4KICAgICAgICA8L2gzPgo8cCBpZD0ic2VjdGlvbi01LjItMSI+
UGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzIG9uIGFuIEktUmVnZXhwIHRvIG9idGFpbiBhbiBF
Q01BU2NyaXB0CnJlZ2V4cCA8c3Bhbj5bPGEgaHJlZj0iI0VDTUEtMjYyIiBjbGFzcz0ieHJlZiI+
RUNNQS0yNjI8L2E+XTwvc3Bhbj46PGEgaHJlZj0iI3NlY3Rpb24tNS4yLTEiIGNsYXNzPSJwaWxj
cm93Ij7CtjwvYT48L3A+Cjx1bCBjbGFzcz0ibm9ybWFsIj4KPGxpIGNsYXNzPSJub3JtYWwiIGlk
PSJzZWN0aW9uLTUuMi0yLjEiPlJlcGxhY2UgYW55IGRvdHMgKDxjb2RlPi48L2NvZGU+KSBvdXRz
aWRlIGNoYXJhY3RlciBjbGFzc2VzIChmaXJzdCBhbHRlcm5hdGl2ZQpvZiA8Y29kZT5jaGFyQ2xh
c3M8L2NvZGU+IHByb2R1Y3Rpb24pIGJ5IDxjb2RlPlteXG5ccl08L2NvZGU+LjxhIGhyZWY9IiNz
ZWN0aW9uLTUuMi0yLjEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT4KPC9saT4KICAgICAgICAgIDxs
aSBjbGFzcz0ibm9ybWFsIiBpZD0ic2VjdGlvbi01LjItMi4yIj5FbnZlbG9wZSB0aGUgcmVzdWx0
IGluIDxjb2RlPl48L2NvZGU+IGFuZCA8Y29kZT4kPC9jb2RlPi48YSBocmVmPSIjc2VjdGlvbi01
LjItMi4yIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+CjwvbGk+CiAgICAgICAgPC91bD4KPHAgaWQ9
InNlY3Rpb24tNS4yLTMiPk5vdGUgdGhhdCB3aGVyZSBhIHJlZ2V4cCBsaXRlcmFsIGlzIHJlcXVp
cmVkLCB0aGlzIG5lZWRzIHRvIGVuY2xvc2UKdGhlIGFjdHVhbCByZWdleHAgaW4gPGNvZGU+Lzwv
Y29kZT4uPGEgaHJlZj0iI3NlY3Rpb24tNS4yLTMiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+
CjxwIGlkPSJzZWN0aW9uLTUuMi00Ij5UaGUgcGVyZm9ybWFuY2UgY2FuIGJlIGluY3JlYXNlZCBi
eSB0dXJuaW5nIHBhcmVudGhlc2l6ZWQgcmVnZXhwcwoocHJvZHVjdGlvbiA8Y29kZT5hdG9tPC9j
b2RlPikgaW50byA8Y29kZT4oPzouLi4pPC9jb2RlPiBjb25zdHJ1Y3Rpb25zLjxhIGhyZWY9IiNz
ZWN0aW9uLTUuMi00IiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+CjwvZGl2
Pgo8ZGl2IGlkPSJwY3JlLXJlMi1ydWJ5LXJlZ2V4cHMiPgo8c2VjdGlvbiBpZD0ic2VjdGlvbi01
LjMiPgogICAgICAgIDxoMyBpZD0ibmFtZS1wY3JlLXJlMi1ydWJ5LXJlZ2V4cHMiPgo8YSBocmVm
PSIjc2VjdGlvbi01LjMiIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj41LjMuIDwvYT48
YSBocmVmPSIjbmFtZS1wY3JlLXJlMi1ydWJ5LXJlZ2V4cHMiIGNsYXNzPSJzZWN0aW9uLW5hbWUg
c2VsZlJlZiI+UENSRSwgUkUyLCBSdWJ5IFJlZ2V4cHM8L2E+CiAgICAgICAgPC9oMz4KPHAgaWQ9
InNlY3Rpb24tNS4zLTEiPlBlcmZvcm0gdGhlIHNhbWUgc3RlcHMgYXMgaW4gPGEgaHJlZj0iI3Rv
RVNyZWciIGNsYXNzPSJ4cmVmIj5TZWN0aW9uIDUuMjwvYT4gdG8gb2J0YWluIGEgdmFsaWQgcmVn
ZXhwIGluClBDUkUgPHNwYW4+WzxhIGhyZWY9IiNQQ1JFMiIgY2xhc3M9InhyZWYiPlBDUkUyPC9h
Pl08L3NwYW4+LCB0aGUgR28gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgPHNwYW4+WzxhIGhyZWY9IiNS
RTIiIGNsYXNzPSJ4cmVmIj5SRTI8L2E+XTwvc3Bhbj4sIGFuZCB0aGUgUnVieQpwcm9ncmFtbWlu
ZyBsYW5ndWFnZSwgZXhjZXB0IHRoYXQgdGhlIGxhc3Qgc3RlcCBpczo8YSBocmVmPSIjc2VjdGlv
bi01LjMtMSIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHVsIGNsYXNzPSJub3JtYWwiPgo8
bGkgY2xhc3M9Im5vcm1hbCIgaWQ9InNlY3Rpb24tNS4zLTIuMSI+RW52ZWxvcGUgdGhlIHJlc3Vs
dCBpbiA8Y29kZT5cQTwvY29kZT4gYW5kIDxjb2RlPlx6PC9jb2RlPi48YSBocmVmPSIjc2VjdGlv
bi01LjMtMi4xIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+CjwvbGk+CiAgICAgICAgPC91bD4KPHAg
aWQ9InNlY3Rpb24tNS4zLTMiPkFnYWluLCB0aGUgcGVyZm9ybWFuY2UgY2FuIGJlIGluY3JlYXNl
ZCBieSB0dXJuaW5nIHBhcmVudGhlc2l6ZWQKcmVnZXhwcyAocHJvZHVjdGlvbiA8Y29kZT5hdG9t
PC9jb2RlPikgaW50byA8Y29kZT4oPzouLi4pPC9jb2RlPiBjb25zdHJ1Y3Rpb25zLjxhIGhyZWY9
IiNzZWN0aW9uLTUuMy0zIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+Cjwv
ZGl2Pgo8ZGl2IGlkPSJ5b3VyLWtpbmQtb2YtcmVnZXhwLWhlcmUtIj4KPHNlY3Rpb24gaWQ9InNl
Y3Rpb24tNS40Ij4KICAgICAgICA8aDMgaWQ9Im5hbWUteW91ci1raW5kLW9mLXJlZ2V4cC1oZXJl
Ij4KPGEgaHJlZj0iI3NlY3Rpb24tNS40IiBjbGFzcz0ic2VjdGlvbi1udW1iZXIgc2VsZlJlZiI+
NS40LiA8L2E+PGEgaHJlZj0iI25hbWUteW91ci1raW5kLW9mLXJlZ2V4cC1oZXJlIiBjbGFzcz0i
c2VjdGlvbi1uYW1lIHNlbGZSZWYiPiZsdDsmbHQ7IFlvdXIga2luZCBvZiBSZWdleHAgaGVyZSAm
Z3Q7Jmd0OzwvYT4KICAgICAgICA8L2gzPgo8cCBpZD0ic2VjdGlvbi01LjQtMSI+KFBsZWFzZSBz
dWJtaXQgdGhlIG1hcHBpbmcgbmVlZGVkIGZvciB5b3VyIGZhdm9yaXRlIGtpbmQgb2YgcmVnZXhw
Lik8YSBocmVmPSIjc2VjdGlvbi01LjQtMSIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPC9z
ZWN0aW9uPgo8L2Rpdj4KPC9zZWN0aW9uPgo8L2Rpdj4KPGRpdiBpZD0ibW90aXZhdGlvbi1hbmQt
YmFja2dyb3VuZCI+CjxzZWN0aW9uIGlkPSJzZWN0aW9uLTYiPgogICAgICA8aDIgaWQ9Im5hbWUt
bW90aXZhdGlvbi1hbmQtYmFja2dyb3VuZCI+CjxhIGhyZWY9IiNzZWN0aW9uLTYiIGNsYXNzPSJz
ZWN0aW9uLW51bWJlciBzZWxmUmVmIj42LiA8L2E+PGEgaHJlZj0iI25hbWUtbW90aXZhdGlvbi1h
bmQtYmFja2dyb3VuZCIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5Nb3RpdmF0aW9uIGFu
ZCBCYWNrZ3JvdW5kPC9hPgogICAgICA8L2gyPgo8cCBpZD0ic2VjdGlvbi02LTEiPkRhdGEgbW9k
ZWxpbmcgZm9ybWF0cyAoWUFORywgQ0RETCkgYXMgd2VsbCBhcyBxdWVyeSBsYW5ndWFnZXMKKGpz
b25wYXRoKSBvZnRlbiBuZWVkIGEgcmVndWxhciBleHByZXNzaW9uIChyZWdleHApIHN1Ymxhbmd1
YWdlLgpUaGVyZSBhcmUgbWFueSBkaWFsZWN0cyBvZiByZWd1bGFyIGV4cHJlc3Npb25zIGluIHVz
ZSBpbiBwbGF0Zm9ybXMsCnByb2dyYW1taW5nIGxhbmd1YWdlcywgYW5kIGRhdGEgbW9kZWxpbmcg
Zm9ybWF0cy48YSBocmVmPSIjc2VjdGlvbi02LTEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+
CjxwIGlkPSJzZWN0aW9uLTYtMiI+V2hpbGUgcmVndWxhciBleHByZXNzaW9ucyBvcmlnaW5hbGx5
IHdlcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSBhCkJvb2xlYW4gbWF0Y2hpbmcgZnVuY3Rpb24sIHRo
ZXkgaGF2ZSB0dXJuZWQgaW50byBwYXJzaW5nIGZ1bmN0aW9ucyBmb3IKbWFueSBhcHBsaWNhdGlv
bnMsIHdpdGggY2FwdHVyZSBncm91cHMsIGdyZWVkeS9sYXp5L3Bvc3Nlc3NpdmUgdmFyaWFudHMs
IGV0Yy4KTGFuZ3VhZ2UgZmVhdHVyZXMgc3VjaCBhcyBiYWNrcmVmZXJlbmNlcyBhbGxvdyBzcGVj
aWZ5aW5nIGxhbmd1YWdlcwp0aGF0IGFjdHVhbGx5IGFyZSBjb250ZXh0LWZyZWUgKENob21za3kg
dHlwZSAyKSBpbnN0ZWFkIG9mIHRoZSByZWd1bGFyCmxhbmd1YWdlcyAoQ2hvbXNreSB0eXBlIDMp
IHRoYXQgcmVndWxhciBleHByZXNzaW9ucyBhcmUgbmFtZWQgZm9yLjxhIGhyZWY9IiNzZWN0aW9u
LTYtMiIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24tNi0zIj5ZQU5H
ICg8c3Bhbj48YSBocmVmPSJodHRwczovL3JmYy1lZGl0b3Iub3JnL3JmYy9yZmM3OTUwI3NlY3Rp
b24tOS40LjUiIGNsYXNzPSJyZWxyZWYiPlNlY3Rpb24gOS40LjU8L2E+IG9mIFs8YSBocmVmPSIj
UkZDNzk1MCIgY2xhc3M9InhyZWYiPlJGQzc5NTA8L2E+XTwvc3Bhbj4pIGFuZCBDRERMICg8c3Bh
bj48YSBocmVmPSJodHRwczovL3JmYy1lZGl0b3Iub3JnL3JmYy9yZmM4NjEwI3NlY3Rpb24tMy44
LjMiIGNsYXNzPSJyZWxyZWYiPlNlY3Rpb24gMy44LjM8L2E+IG9mIFs8YSBocmVmPSIjUkZDODYx
MCIgY2xhc3M9InhyZWYiPlJGQzg2MTA8L2E+XTwvc3Bhbj4pIGhhdmUgYWRvcHRlZCB0aGUgcmVn
ZXhwIGxhbmd1YWdlIGZyb20gVzNDIFNjaGVtYSA8c3Bhbj5bPGEgaHJlZj0iI1hTRDIiIGNsYXNz
PSJ4cmVmIj5YU0QyPC9hPl08L3NwYW4+LgpYU0QgcmVnZXhwIGlzIGEgcHVyZSBtYXRjaGluZyBs
YW5ndWFnZSwgaS5lLiwgWFNEIHJlZ2V4cHMgY2FuIGJlIHVzZWQKdG8gbWF0Y2ggYSBzdHJpbmcg
YWdhaW5zdCB0aGVtIGFuZCB5aWVsZCBhIHNpbXBsZSB0cnVlIG9yIGZhbHNlCnJlc3VsdC4KWFNE
IHJlZ2V4cHMgYXJlIG5vdCBhcyB3aWRlbHkgaW1wbGVtZW50ZWQgYXMgcHJvZ3JhbW1pbmcgbGFu
Z3VhZ2UKcmVnZXhwIGRpYWxlY3RzIHN1Y2ggYXMgdGhvc2Ugb2YgUGVybCwgUHl0aG9uLCBSdWJ5
LCBHbyA8c3Bhbj5bPGEgaHJlZj0iI1JFMiIgY2xhc3M9InhyZWYiPlJFMjwvYT5dPC9zcGFuPiwg
b3IKSmF2YVNjcmlwdCAoRUNNQVNjcmlwdCkgPHNwYW4+WzxhIGhyZWY9IiNFQ01BLTI2MiIgY2xh
c3M9InhyZWYiPkVDTUEtMjYyPC9hPl08L3NwYW4+LgpUaGUgbGF0dGVyIGFyZSBvZnRlbiBpbiBh
IHN0YXRlIG9mIGNvbnRpbnVvdXMgZGV2ZWxvcG1lbnQ7IGluIHRoZSBiZXN0CmNhc2UgKEVDTUFT
Y3JpcHQpIHRoZXJlIGlzIGEgY29tcGxldGUgc3BlY2lmaWNhdGlvbiB3aGljaCBob3dldmVyIGlz
CmhpZ2hseSBjb21wbGV4IChTZWN0aW9uIDIxLjIgb2YgPHNwYW4+WzxhIGhyZWY9IiNFQ01BLTI2
MiIgY2xhc3M9InhyZWYiPkVDTUEtMjYyPC9hPl08L3NwYW4+IGNvbXByaXNlcyA2MiBwYWdlcykg
YW5kCmV2b2x2ZXMgb24gYSB5ZWFybHkgdGltZWxpbmUsIHdpdGggc2lnbmlmaWNhbnQgYWRkaXRp
b25zLgpSZWdleHAgZGlhbGVjdHMgc3VjaCBhcyBQQ1JFIDxzcGFuPls8YSBocmVmPSIjUENSRTIi
IGNsYXNzPSJ4cmVmIj5QQ1JFMjwvYT5dPC9zcGFuPiBoYXZlIGV2b2x2ZWQgdG8gY292ZXIgYQpj
b21tb24gc2V0IG9mIGZ1bmN0aW9ucyBhdmFpbGFibGUgaW4gcGFyc2luZyByZWdleHAgZGlhbGVj
dHMsIG9mZmVyZWQKaW4gYSB3aWRlbHkgYXZhaWxhYmxlIGxpYnJhcnkuPGEgaHJlZj0iI3NlY3Rp
b24tNi0zIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8cCBpZD0ic2VjdGlvbi02LTQiPldp
dGggY29udGludWluZyBhY2NyZXRpb24gb2YgY29tcGxleCBmZWF0dXJlcywgcGFyc2luZyByZWdl
eHAKbGlicmFyaWVzIGhhdmUgYmVjb21lIHN1c2NlcHRpYmxlIHRvIGJ1Z3MgYW5kIHBlcmZvcm1h
bmNlIGRlZ3JhZGF0aW9uLAppbiBwYXJ0aWN1bGFyIHRob3NlIHRoYXQgY2FuIGJlIGV4cGxvaXRl
ZCBpbiBEZW5pYWwgb2YgU2VydmljZSAoRG9TKSBhdHRhY2tzLgpUaGUgbGlicmFyeSBSRTIgdGhh
dCBpcyBjb21wYXRpYmxlIHdpdGggR28gbGFuZ3VhZ2UgcmVnZXhwcyBzdHJpdmVzIHRvCmJlIGlt
bXVuZSB0byBEb1MgYXR0YWNrcywgbWFraW5nIGl0IGF0dHJhY3RpdmUgdG8gYXBwbGljYXRpb25z
IHN1Y2ggYXMKcXVlcnkgbGFuZ3VhZ2VzIHdoZXJlIGFuIGF0dGFja2VyIGNvdWxkIGNvbnRyb2wg
dGhlIGlucHV0LgpUaGUgcHJvYmxlbSByZW1haW5zIHRoYXQgb3RoZXIgYnVncyBpbiBzdWNoIGxp
YnJhcmllcyBjYW4gbGVhZCB0bwpleHBsb2l0YWJsZSB2dWxuZXJhYmlsaXRpZXM7IGF0IHRoZSB0
aW1lIG9mIHdyaXRpbmcsIHRoZSBDb21tb24KVnVsbmVyYWJpbGl0aWVzIGFuZCBFeHBvc3VyZXMg
KENWRSkgc3lzdGVtIGhhcyAxMzEgZW50cmllcyB0aGF0Cm1lbnRpb24gdGhlIHdvcmQgInJlZ2V4
IiA8c3Bhbj5bPGEgaHJlZj0iI1JFR0VYLUNWRSIgY2xhc3M9InhyZWYiPlJFR0VYLUNWRTwvYT5d
PC9zcGFuPiAobm90IGFsbCwgYnV0IG1hbnkgb2Ygd2hpY2ggYXJlCnN1Y2ggYnVncywgd2l0aCAy
MyBtYXRjaGVzIGZvciBhcmJpdHJhcnkgY29kZSBleGVjdXRpb24pLjxhIGhyZWY9IiNzZWN0aW9u
LTYtNCIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24tNi01Ij5JbXBs
ZW1lbnRhdGlvbnMgb2YgWUFORyBhbmQgQ0RETCBvZnRlbiBzdHJ1Z2dsZSB3aXRoIHByb3ZpZGlu
ZyB0cnVlClhTRCByZWdleHBzOyBzb21lIGluc3RlYWQgY2hlYXQgYnkgcHJvdmlkaW5nIG9uZSBv
ZiB0aGUgcGFyc2luZyByZWdleHAKdmFyaWV0aWVzLCBzb21ldGltZSB3aXRob3V0IGV2ZW4gYWR2
ZXJ0aXNpbmcgdGhpcyBmYWN0LjxhIGhyZWY9IiNzZWN0aW9uLTYtNSIgY2xhc3M9InBpbGNyb3ci
PsK2PC9hPjwvcD4KPHAgaWQ9InNlY3Rpb24tNi02Ij5BIG1hdGNoaW5nIHJlZ2V4cCB0aGF0IGRv
ZXMgbm90IHVzZSB0aGUgbW9yZSBjb21wbGV4IFhTRCBmZWF0dXJlcwooPGEgaHJlZj0iI3N1YnNl
dHRpbmciIGNsYXNzPSJ4cmVmIj5TZWN0aW9uIDYuMTwvYT4pIGNhbiB1c3VhbGx5IGJlIGNvbnZl
cnRlZCBpbnRvIGEgcGFyc2luZyByZWdleHAgb2YgbWFueQpkaWFsZWN0cyBieSBzaW1wbHkgc3Vy
cm91bmRpbmcgaXQgd2l0aCBhbmNob3JzIG9mIHRoYXQgZGlhbGVjdCAoZS5nLiwgPGNvZGU+Xjwv
Y29kZT4gb3IgPGNvZGU+XEE8L2NvZGU+IGFuZCA8Y29kZT4kPC9jb2RlPiBvciA8Y29kZT5cejwv
Y29kZT4pLgpJZiB0aGUgb3JpZ2luYWwgbWF0Y2hpbmcgcmVnZXhwcyBleGNlZWQgdGhlIGVudmVs
b3BlIG9mIGNvbXBhdGliaWxpdHkKYmV0d2VlbiBkaWFsZWN0cywgdGhpcyBjYW4gbGVhZCB0byBp
bnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLCBvciwKd29yc2UsIHNlY3VyaXR5IHZ1bG5lcmFiaWxp
dGllcy4KQWxzbywgZmVhdHVyZXMgb2YgdGhlIHRhcmdldCBkaWFsZWN0IHN1Y2ggYXMgY2FwdHVy
ZSBncm91cHMgbWF5IGJlIHRyaWdnZXJlZCBpbmFkdmVydGVudGx5LCByZWR1Y2luZyBwZXJmb3Jt
YW5jZS48YSBocmVmPSIjc2VjdGlvbi02LTYiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+Cjxk
aXYgaWQ9InN1YnNldHRpbmciPgo8c2VjdGlvbiBpZD0ic2VjdGlvbi02LjEiPgogICAgICAgIDxo
MyBpZD0ibmFtZS1zdWJzZXR0aW5nLXhzZC1yZWdleHBzIj4KPGEgaHJlZj0iI3NlY3Rpb24tNi4x
IiBjbGFzcz0ic2VjdGlvbi1udW1iZXIgc2VsZlJlZiI+Ni4xLiA8L2E+PGEgaHJlZj0iI25hbWUt
c3Vic2V0dGluZy14c2QtcmVnZXhwcyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5TdWJz
ZXR0aW5nIFhTRCBSZWdleHBzPC9hPgogICAgICAgIDwvaDM+CjxwIGlkPSJzZWN0aW9uLTYuMS0x
Ij5YU0QgUmVnZXhwcyBhcmUgcmVsYXRpdmVseSBlYXN5IHRvIGltcGxlbWVudCBvciBtYXAgdG8g
d2lkZWx5CmltcGxlbWVudGVkIHBhcnNpbmcgcmVnZXhwIGRpYWxlY3RzLCB3aXRoIGEgc21hbGwg
bnVtYmVyIG9mIG5vdGFibGUKZXhjZXB0aW9uczo8YSBocmVmPSIjc2VjdGlvbi02LjEtMSIgY2xh
c3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHVsIGNsYXNzPSJub3JtYWwiPgo8bGkgY2xhc3M9Im5v
cm1hbCIgaWQ9InNlY3Rpb24tNi4xLTIuMSI+CiAgICAgICAgICAgIDxwIGlkPSJzZWN0aW9uLTYu
MS0yLjEuMSI+Q2hhcmFjdGVyIGNsYXNzIHN1YnRyYWN0aW9uLiAgVGhpcyBpcyBhIHZlcnkgdXNl
ZnVsIGZlYXR1cmUgaW4gbWFueQpzcGVjaWZpY2F0aW9ucywgYnV0IGl0IGlzIHVuZm9ydHVuYXRl
bHkgbW9zdGx5IGFic2VudCBmcm9tIHBhcnNpbmcKcmVnZXhwIGRpYWxlY3RzLjxhIGhyZWY9IiNz
ZWN0aW9uLTYuMS0yLjEuMSIgY2xhc3M9InBpbGNyb3ciPsK2PC9hPjwvcD4KPHVsIGNsYXNzPSJu
b3JtYWwiPgo8bGkgY2xhc3M9Im5vcm1hbCIgaWQ9InNlY3Rpb24tNi4xLTIuMS4yLjEiPgogICAg
ICAgICAgICAgICAgPHN0cm9uZz5Jc3N1ZTwvc3Ryb25nPjogVGhpcyBhYnNlbmNlIGNhbiBvZnRl
biBiZSBhZGRyZXNzZWQgYnkgdHJhbnNsYXRpbmcKY2hhcmFjdGVyIGNsYXNzIHN1YnRyYWN0aW9u
IGludG8gcG9zaXRpdmUgY2hhcmFjdGVyIGNsYXNzZXMKKHBvc3NpYmx5IHJlcXVpcmluZyBzaWdu
aWZpY2FudCBleHBhbnNpb24pIGFuZC9vciBpbnNlcnRpbmcKbmVnYXRpdmUgbG9va2FoZWFkIGFz
c2VydGlvbnMgKHdoaWNoIGFyZSBub3QgdW5pdmVyc2FsbHkgc3VwcG9ydGVkCmJ5IHJlZ2V4cCBs
aWJyYXJpZXMsIG1vc3Qgbm90YWJseSBub3QgYnkgUkUyIDxzcGFuPls8YSBocmVmPSIjUkUyIiBj
bGFzcz0ieHJlZiI+UkUyPC9hPl08L3NwYW4+KS4KVGhpcyBzcGVjaWZpY2F0aW9uIHRoZXJlZm9y
ZSBvcHRzIGZvciBsZWF2aW5nIG91dCBjaGFyYWN0ZXIgY2xhc3MKc3VidHJhY3Rpb24uPGEgaHJl
Zj0iI3NlY3Rpb24tNi4xLTIuMS4yLjEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT4KPC9saT4KICAg
ICAgICAgICAgPC91bD4KPC9saT4KICAgICAgICAgIDxsaSBjbGFzcz0ibm9ybWFsIiBpZD0ic2Vj
dGlvbi02LjEtMi4yIj5NdWx0aS1jaGFyYWN0ZXIgZXNjYXBlcy4gIDxjb2RlPlxkPC9jb2RlPiwg
PGNvZGU+XHc8L2NvZGU+LCA8Y29kZT5cczwvY29kZT4gYW5kIHRoZWlyIHVwcGVyY2FzZQplcXVp
dmFsZW50cyAoY29tcGxlbWVudCBjbGFzc2VzKSBleGhpYml0IGEKbGFyZ2UgYW1vdW50IG9mIHZh
cmlhdGlvbiBiZXR3ZWVuIFJlZ2V4cCBmbGF2b3JzLgooRS5nLiwgcHJlZGVmaW5lZCBjaGFyYWN0
ZXIgY2xhc3NlcyBzdWNoIGFzIDxjb2RlPlx3PC9jb2RlPiBtYXkgYmUgbWVhbnQKdG8gYmUgQVND
SUkgb25seSwgb3IgdGhleSBtYXkgZW5jb21wYXNzIGFsbCBsZXR0ZXJzIGFuZCBkaWdpdHMKZGVm
aW5lZCBpbiBVbmljb2RlLiAgICBUaGUgbGF0dGVyIGlzIHVzdWFsbHkgb2YgaW50ZXJlc3QgaW4g
cXVlcnkKbGFuZ3VhZ2VzLCB3aGlsZSB0aGUgZm9ybWVyIGlzIG9mIGludGVyZXN0IHRvIGEgc3Vi
c2V0IG9mCmFwcGxpY2F0aW9ucyBpbiBkYXRhIG1vZGVsIHNwZWNpZmljYXRpb25zLik8YSBocmVm
PSIjc2VjdGlvbi02LjEtMi4yIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+CjwvbGk+CiAgICAgICAg
ICA8bGkgY2xhc3M9Im5vcm1hbCIgaWQ9InNlY3Rpb24tNi4xLTIuMyI+CiAgICAgICAgICAgIDxw
IGlkPSJzZWN0aW9uLTYuMS0yLjMuMSI+VW5pY29kZS4KV2hpbGUgdGhlcmUgaXMgbm8gZG91YnQg
dGhhdCBhIHJlZ2V4cCBmbGF2b3IgbWVhbnQgdG8gbGFzdCBuZWVkcyB0bwpiZSBVbmljb2RlIGVu
YWJsZWQsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBhc3BlY3RzIG9mIHRoaXMgdGhhdCBuZWVkCmRp
c2N1c3Npb24uCk5vdCBhbGwgcmVnZXhwIGltcGxlbWVudGF0aW9ucyB0aGF0IG9uZSBtaWdodCB3
YW50IHRvIG1hcApJLVJlZ2V4cHMgdG8gd2lsbCBzdXBwb3J0IGFjY2Vzc2VzIHRvIFVuaWNvZGUg
dGFibGVzIHRoYXQgZW5hYmxlCmV4ZWN1dGluZyBvbiBjb25zdHJ1Y3RzIHN1Y2ggYXMgPGNvZGU+
XHB7SXNDb3B0aWN9PC9jb2RlPi4KRm9ydHVuYXRlbHksIHRoZSA8Y29kZT5ccDwvY29kZT4vPGNv
ZGU+XFA8L2NvZGU+IGZlYXR1cmUgaW4gZ2VuZXJhbCBpcyBub3cgcXVpdGUKd2lkZWx5IGF2YWls
YWJsZS48YSBocmVmPSIjc2VjdGlvbi02LjEtMi4zLjEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48
L3A+Cjx1bCBjbGFzcz0ibm9ybWFsIj4KPGxpIGNsYXNzPSJub3JtYWwiIGlkPSJzZWN0aW9uLTYu
MS0yLjMuMi4xIj4KICAgICAgICAgICAgICAgIDxzdHJvbmc+SXNzdWU8L3N0cm9uZz46IFRoZSBB
U0NJSSBmb2N1cyBjYW4gcGFydGlhbGx5IGJlIGFkZHJlc3NlZCBieSBhZGRpbmcgYQpjb25zdHJh
aW50IHRoYXQgdGhlIG1hdGNoZWQgdGV4dCBoYXMgdG8gYmUgQVNDSUkgaW4gdGhlIGZpcnN0CnBs
YWNlLiAgVGhpcyBvZnRlbiBpcyBhbGwgdGhhdCBpcyBuZWVkZWQgd2hlcmUgcmVnZXhwcyBhcmUg
dXNlZCB0bwpkZWZpbmUgbGV4aWNhbCBlbGVtZW50cyBvZiBhIGNvbXB1dGVyIGxhbmd1YWdlLiAg
VGhlIGFjY2VzcyB0bwpVbmljb2RlIHRhYmxlcyBjYW4gc2ltcGx5IGJlIHJ1bGVkIG91dC4gIChO
b3RlIHRoYXQgUkZDIDY2NDMKY29udGFpbnMgYSBsb25lIGluc3RhbmNlIG9mIDxjb2RlPlxwe0lz
QmFzaWNMYXRpbn17MCwyNTV9PC9jb2RlPiwgd2hpY2ggaXMKbmVlZGVkIHRvIGRlc2NyaWJlIGEg
dHJhbnNpdGlvbiBmcm9tIGEgbGVnYWN5IGNoYXJhY3RlciBzZXQgdG8KVW5pY29kZS4gIFRoZSBh
dXRob3IgYmVsaWV2ZXMgdGhhdCB0aGlzIHdvdWxkIGJlIGEgcmFyZQphcHBsaWNhdGlvbiBhbmQg
Y2FuIGJlIGxlZnQgb3V0LiAgUkZDMjYyMiBjb250YWlucyA8Y29kZT5bWzpkaWdpdDpdXTwvY29k
ZT4sCjxjb2RlPltbOmFscGhhOl1dPC9jb2RlPiwgPGNvZGU+W1s6YWxudW06XV08L2NvZGU+LCBh
bGJlaXQgaW4gYSAgc3BlY2lmaWNhdGlvbiBmb3IgdGhlCjxjb2RlPmZsZXg8L2NvZGU+IHRvb2w7
IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmUgY2xvc2UgdG8gPGNvZGU+XGQ8L2NvZGU+LCA8Y29kZT5c
cHtMfTwvY29kZT4sIDxjb2RlPlx3PC9jb2RlPgppbiBhbiBBU0NJSSBzdWJzZXQuKTxhIGhyZWY9
IiNzZWN0aW9uLTYuMS0yLjMuMi4xIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+CjwvbGk+CiAgICAg
ICAgICAgIDwvdWw+CjwvbGk+CiAgICAgICAgPC91bD4KPC9zZWN0aW9uPgo8L2Rpdj4KPC9zZWN0
aW9uPgo8L2Rpdj4KPGRpdiBpZD0iaWFuYS1jb25zaWRlcmF0aW9ucyI+CjxzZWN0aW9uIGlkPSJz
ZWN0aW9uLTciPgogICAgICA8aDIgaWQ9Im5hbWUtaWFuYS1jb25zaWRlcmF0aW9ucyI+CjxhIGhy
ZWY9IiNzZWN0aW9uLTciIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj43LiA8L2E+PGEg
aHJlZj0iI25hbWUtaWFuYS1jb25zaWRlcmF0aW9ucyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxm
UmVmIj5JQU5BIENvbnNpZGVyYXRpb25zPC9hPgogICAgICA8L2gyPgo8cCBpZD0ic2VjdGlvbi03
LTEiPlRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gcmVxdWVzdHMgb2YgSUFOQS48YSBocmVmPSIjc2Vj
dGlvbi03LTEiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+Cjwvc2VjdGlvbj4KPC9kaXY+Cjxk
aXYgaWQ9InNlY3VyaXR5LWNvbnNpZGVyYXRpb25zIj4KPHNlY3Rpb24gaWQ9InNlY3Rpb24tOCI+
CiAgICAgIDxoMiBpZD0ibmFtZS1zZWN1cml0eS1jb25zaWRlcmF0aW9ucyI+CjxhIGhyZWY9IiNz
ZWN0aW9uLTgiIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj44LiA8L2E+PGEgaHJlZj0i
I25hbWUtc2VjdXJpdHktY29uc2lkZXJhdGlvbnMiIGNsYXNzPSJzZWN0aW9uLW5hbWUgc2VsZlJl
ZiI+U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM8L2E+CiAgICAgIDwvaDI+CjxwIGlkPSJzZWN0aW9u
LTgtMSI+VEJEPGEgaHJlZj0iI3NlY3Rpb24tOC0xIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9w
Pgo8cCBpZD0ic2VjdGlvbi04LTIiPihEaXNjdXNzIHNlY3VyaXR5IGlzc3VlcyBvZiByZWdleHAg
aW1wbGVtZW50YXRpb25zLCBib3RoIERvUyBhbmQgUkNFOwp0aGlzIGlzIGNvdmVyZWQgaW4gcGFy
dCBpbiA8YSBocmVmPSIjaW50cm8iIGNsYXNzPSJ4cmVmIj5TZWN0aW9uIDE8L2E+Lik8YSBocmVm
PSIjc2VjdGlvbi04LTIiIGNsYXNzPSJwaWxjcm93Ij7CtjwvYT48L3A+Cjwvc2VjdGlvbj4KPC9k
aXY+CjxzZWN0aW9uIGlkPSJzZWN0aW9uLTkiPgogICAgICA8aDIgaWQ9Im5hbWUtcmVmZXJlbmNl
cyI+CjxhIGhyZWY9IiNzZWN0aW9uLTkiIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj45
LiA8L2E+PGEgaHJlZj0iI25hbWUtcmVmZXJlbmNlcyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxm
UmVmIj5SZWZlcmVuY2VzPC9hPgogICAgICA8L2gyPgo8c2VjdGlvbiBpZD0ic2VjdGlvbi05LjEi
PgogICAgICAgIDxoMyBpZD0ibmFtZS1ub3JtYXRpdmUtcmVmZXJlbmNlcyI+CjxhIGhyZWY9IiNz
ZWN0aW9uLTkuMSIgY2xhc3M9InNlY3Rpb24tbnVtYmVyIHNlbGZSZWYiPjkuMS4gPC9hPjxhIGhy
ZWY9IiNuYW1lLW5vcm1hdGl2ZS1yZWZlcmVuY2VzIiBjbGFzcz0ic2VjdGlvbi1uYW1lIHNlbGZS
ZWYiPk5vcm1hdGl2ZSBSZWZlcmVuY2VzPC9hPgogICAgICAgIDwvaDM+CjxkbCBjbGFzcz0icmVm
ZXJlbmNlcyI+CjxkdCBpZD0iWFNEMiI+W1hTRDJdPC9kdD4KICAgICAgPGRkPgo8c3BhbiBjbGFz
cz0icmVmQXV0aG9yIj5CaXJvbiwgUC48L3NwYW4+IGFuZCA8c3BhbiBjbGFzcz0icmVmQXV0aG9y
Ij5BLiBNYWxob3RyYTwvc3Bhbj4sIDxzcGFuIGNsYXNzPSJyZWZUaXRsZSI+IlhNTCBTY2hlbWEg
UGFydCAyOiBEYXRhdHlwZXMgU2Vjb25kIEVkaXRpb24iPC9zcGFuPiwgPHNwYW4gY2xhc3M9InNl
cmllc0luZm8iPldvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0gUmVjb21tZW5kYXRpb24gUkVDLXht
bHNjaGVtYS0yLTIwMDQxMDI4PC9zcGFuPiwgPHRpbWUgZGF0ZXRpbWU9IjIwMDQtMTAtMjgiIGNs
YXNzPSJyZWZEYXRlIj4yOCBPY3RvYmVyIDIwMDQ8L3RpbWU+LCA8c3Bhbj4mbHQ7PGEgaHJlZj0i
aHR0cHM6Ly93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbHNjaGVtYS0yLTIwMDQxMDI4Ij5odHRw
czovL3d3dy53My5vcmcvVFIvMjAwNC9SRUMteG1sc2NoZW1hLTItMjAwNDEwMjg8L2E+Jmd0Ozwv
c3Bhbj4uIDwvZGQ+CjxkZCBjbGFzcz0iYnJlYWsiPjwvZGQ+CjwvZGw+Cjwvc2VjdGlvbj4KPHNl
Y3Rpb24gaWQ9InNlY3Rpb24tOS4yIj4KICAgICAgICA8aDMgaWQ9Im5hbWUtaW5mb3JtYXRpdmUt
cmVmZXJlbmNlcyI+CjxhIGhyZWY9IiNzZWN0aW9uLTkuMiIgY2xhc3M9InNlY3Rpb24tbnVtYmVy
IHNlbGZSZWYiPjkuMi4gPC9hPjxhIGhyZWY9IiNuYW1lLWluZm9ybWF0aXZlLXJlZmVyZW5jZXMi
IGNsYXNzPSJzZWN0aW9uLW5hbWUgc2VsZlJlZiI+SW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvYT4K
ICAgICAgICA8L2gzPgo8ZGwgY2xhc3M9InJlZmVyZW5jZXMiPgo8ZHQgaWQ9IkVDTUEtMjYyIj5b
RUNNQS0yNjJdPC9kdD4KICAgICAgICA8ZGQ+CjxzcGFuIGNsYXNzPSJyZWZBdXRob3IiPkVjbWEg
SW50ZXJuYXRpb25hbDwvc3Bhbj4sIDxzcGFuIGNsYXNzPSJyZWZUaXRsZSI+IkVDTUFTY3JpcHQg
MjAyMCBMYW5ndWFnZSBTcGVjaWZpY2F0aW9uIjwvc3Bhbj4sIDxzcGFuIGNsYXNzPSJzZXJpZXNJ
bmZvIj5FQ01BIFN0YW5kYXJkIEVDTUEtMjYyLCAxMXRoIEVkaXRpb248L3NwYW4+LCA8dGltZSBk
YXRldGltZT0iMjAyMC0wNiIgY2xhc3M9InJlZkRhdGUiPkp1bmUgMjAyMDwvdGltZT4sIDxzcGFu
PiZsdDs8YSBocmVmPSJodHRwczovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3dwLWNvbnRl
bnQvdXBsb2Fkcy9FQ01BLTI2Mi5wZGYiPmh0dHBzOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5v
cmcvd3AtY29udGVudC91cGxvYWRzL0VDTUEtMjYyLnBkZjwvYT4mZ3Q7PC9zcGFuPi4gPC9kZD4K
PGRkIGNsYXNzPSJicmVhayI+PC9kZD4KPGR0IGlkPSJQQ1JFMiI+W1BDUkUyXTwvZHQ+CiAgICAg
ICAgPGRkPgo8c3BhbiBjbGFzcz0icmVmVGl0bGUiPiJQZXJsLWNvbXBhdGlibGUgUmVndWxhciBF
eHByZXNzaW9ucyAocmV2aXNlZCBBUEk6IFBDUkUyKSI8L3NwYW4+LCA8c3Bhbj5uLmQuPC9zcGFu
PiwgPHNwYW4+Jmx0OzxhIGhyZWY9Imh0dHA6Ly9wY3JlLm9yZy9jdXJyZW50L2RvYy9odG1sLyI+
aHR0cDovL3BjcmUub3JnL2N1cnJlbnQvZG9jL2h0bWwvPC9hPiZndDs8L3NwYW4+LiA8L2RkPgo8
ZGQgY2xhc3M9ImJyZWFrIj48L2RkPgo8ZHQgaWQ9IlJFMiI+W1JFMl08L2R0PgogICAgICAgIDxk
ZD4KPHNwYW4gY2xhc3M9InJlZlRpdGxlIj4iUkUyIGlzIGEgZmFzdCwgc2FmZSwgdGhyZWFkLWZy
aWVuZGx5IGFsdGVybmF0aXZlIHRvIGJhY2t0cmFja2luZyByZWd1bGFyIGV4cHJlc3Npb24gZW5n
aW5lcyBsaWtlIHRob3NlIHVzZWQgaW4gUENSRSwgUGVybCwgYW5kIFB5dGhvbi4gSXQgaXMgYSBD
KysgbGlicmFyeS4iPC9zcGFuPiwgPHNwYW4+bi5kLjwvc3Bhbj4sIDxzcGFuPiZsdDs8YSBocmVm
PSJodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL3JlMiI+aHR0cHM6Ly9naXRodWIuY29tL2dvb2ds
ZS9yZTI8L2E+Jmd0Ozwvc3Bhbj4uIDwvZGQ+CjxkZCBjbGFzcz0iYnJlYWsiPjwvZGQ+CjxkdCBp
ZD0iUkVHRVgtQ1ZFIj5bUkVHRVgtQ1ZFXTwvZHQ+CiAgICAgICAgPGRkPgo8c3BhbiBjbGFzcz0i
cmVmVGl0bGUiPiJDVkUgLSBTZWFyY2ggUmVzdWx0cyI8L3NwYW4+LCA8c3Bhbj5uLmQuPC9zcGFu
PiwgPHNwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vY3ZlLm1pdHJlLm9yZy9jZ2ktYmluL2N2ZWtl
eS5jZ2k/a2V5d29yZD1yZWdleCI+aHR0cHM6Ly9jdmUubWl0cmUub3JnL2NnaS1iaW4vY3Zla2V5
LmNnaT9rZXl3b3JkPXJlZ2V4PC9hPiZndDs8L3NwYW4+LiA8L2RkPgo8ZGQgY2xhc3M9ImJyZWFr
Ij48L2RkPgo8ZHQgaWQ9IlJGQzc0OTMiPltSRkM3NDkzXTwvZHQ+CiAgICAgICAgPGRkPgo8c3Bh
biBjbGFzcz0icmVmQXV0aG9yIj5CcmF5LCBULiwgRWQuPC9zcGFuPiwgPHNwYW4gY2xhc3M9InJl
ZlRpdGxlIj4iVGhlIEktSlNPTiBNZXNzYWdlIEZvcm1hdCI8L3NwYW4+LCA8c3BhbiBjbGFzcz0i
c2VyaWVzSW5mbyI+UkZDIDc0OTM8L3NwYW4+LCA8c3BhbiBjbGFzcz0ic2VyaWVzSW5mbyI+RE9J
IDEwLjE3NDg3L1JGQzc0OTM8L3NwYW4+LCA8dGltZSBkYXRldGltZT0iMjAxNS0wMyIgY2xhc3M9
InJlZkRhdGUiPk1hcmNoIDIwMTU8L3RpbWU+LCA8c3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly93
d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzc0OTMiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn
L3JmYy9yZmM3NDkzPC9hPiZndDs8L3NwYW4+LiA8L2RkPgo8ZGQgY2xhc3M9ImJyZWFrIj48L2Rk
Pgo8ZHQgaWQ9IlJGQzc5NTAiPltSRkM3OTUwXTwvZHQ+CiAgICAgICAgPGRkPgo8c3BhbiBjbGFz
cz0icmVmQXV0aG9yIj5Cam9ya2x1bmQsIE0uLCBFZC48L3NwYW4+LCA8c3BhbiBjbGFzcz0icmVm
VGl0bGUiPiJUaGUgWUFORyAxLjEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSI8L3NwYW4+LCA8c3Bh
biBjbGFzcz0ic2VyaWVzSW5mbyI+UkZDIDc5NTA8L3NwYW4+LCA8c3BhbiBjbGFzcz0ic2VyaWVz
SW5mbyI+RE9JIDEwLjE3NDg3L1JGQzc5NTA8L3NwYW4+LCA8dGltZSBkYXRldGltZT0iMjAxNi0w
OCIgY2xhc3M9InJlZkRhdGUiPkF1Z3VzdCAyMDE2PC90aW1lPiwgPHNwYW4+Jmx0OzxhIGhyZWY9
Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3OTUwIj5odHRwczovL3d3dy5yZmMt
ZWRpdG9yLm9yZy9yZmMvcmZjNzk1MDwvYT4mZ3Q7PC9zcGFuPi4gPC9kZD4KPGRkIGNsYXNzPSJi
cmVhayI+PC9kZD4KPGR0IGlkPSJSRkM4NjEwIj5bUkZDODYxMF08L2R0PgogICAgICA8ZGQ+Cjxz
cGFuIGNsYXNzPSJyZWZBdXRob3IiPkJpcmtob2x6LCBILjwvc3Bhbj4sIDxzcGFuIGNsYXNzPSJy
ZWZBdXRob3IiPlZpZ2FubywgQy48L3NwYW4+LCBhbmQgPHNwYW4gY2xhc3M9InJlZkF1dGhvciI+
Qy4gQm9ybWFubjwvc3Bhbj4sIDxzcGFuIGNsYXNzPSJyZWZUaXRsZSI+IkNvbmNpc2UgRGF0YSBE
ZWZpbml0aW9uIExhbmd1YWdlIChDRERMKTogQSBOb3RhdGlvbmFsIENvbnZlbnRpb24gdG8gRXhw
cmVzcyBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIGFuZCBKU09O
IERhdGEgU3RydWN0dXJlcyI8L3NwYW4+LCA8c3BhbiBjbGFzcz0ic2VyaWVzSW5mbyI+UkZDIDg2
MTA8L3NwYW4+LCA8c3BhbiBjbGFzcz0ic2VyaWVzSW5mbyI+RE9JIDEwLjE3NDg3L1JGQzg2MTA8
L3NwYW4+LCA8dGltZSBkYXRldGltZT0iMjAxOS0wNiIgY2xhc3M9InJlZkRhdGUiPkp1bmUgMjAx
OTwvdGltZT4sIDxzcGFuPiZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9y
ZmMvcmZjODYxMCI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg2MTA8L2E+Jmd0
Ozwvc3Bhbj4uIDwvZGQ+CjxkZCBjbGFzcz0iYnJlYWsiPjwvZGQ+CjwvZGw+Cjwvc2VjdGlvbj4K
PC9zZWN0aW9uPgo8ZGl2IGlkPSJyZmNzIj4KPHNlY3Rpb24gaWQ9ImFwcGVuZGl4LUEiPgogICAg
ICA8aDIgaWQ9Im5hbWUtcmVnZXhwcy1hbmQtc2ltaWxhci1jb25zdHJ1Ij4KPGEgaHJlZj0iI2Fw
cGVuZGl4LUEiIGNsYXNzPSJzZWN0aW9uLW51bWJlciBzZWxmUmVmIj5BcHBlbmRpeCBBLiA8L2E+
PGEgaHJlZj0iI25hbWUtcmVnZXhwcy1hbmQtc2ltaWxhci1jb25zdHJ1IiBjbGFzcz0ic2VjdGlv
bi1uYW1lIHNlbGZSZWYiPlJlZ2V4cHMgYW5kIFNpbWlsYXIgQ29uc3RydWN0cyBpbiBSZWNlbnQg
UHVibGlzaGVkIFJGQ3M8L2E+CiAgICAgIDwvaDI+CjxwIGlkPSJhcHBlbmRpeC1BLTEiPlRoaXMg
YXBwZW5kaXggY29udGFpbnMgYSBudW1iZXIgb2YgcmVndWxhciBleHByZXNzaW9ucyB0aGF0IGhh
dmUgYmVlbgpleHRyYWN0ZWQgZnJvbSBzb21lIHJlY2VudGx5IHB1Ymxpc2hlZCBSRkNzIGJhc2Vk
IG9uIHNvbWUgYWQtaG9jIG1hdGNoaW5nLgpNdWx0aS1saW5lIGNvbnN0cnVjdGlvbnMgd2VyZSBu
b3QgaW5jbHVkZWQuCldpdGggdGhlIGV4Y2VwdGlvbiBvZiBzb21lIChvZnRlbiBzdXJwcmlzaW5n
bHkgZHViaW91cykgdXNhZ2Ugb2YgbXVsdGktY2hhcmFjdGVyCmVzY2FwZXMsIGFsbCByZWd1bGFy
IGV4cHJlc3Npb25zIHZhbGlkYXRlIGFnYWluc3QgdGhlIEFCTkYgaW4gPGEgaHJlZj0iI2lyZWdl
eHAtYWJuZiIgY2xhc3M9InhyZWYiPkZpZ3VyZSAxPC9hPi48YSBocmVmPSIjYXBwZW5kaXgtQS0x
IiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8c3BhbiBpZD0ibmFtZS1leGFtcGxlLXJlZ3Vs
YXItZXhwcmVzc2lvbnMiPjwvc3Bhbj48ZGl2IGlkPSJpcmVnZXhwLWV4YW1wbGVzIj4KPGZpZ3Vy
ZSBpZD0iZmlndXJlLTIiPgogICAgICAgIDxkaXYgY2xhc3M9ImFsaWduTGVmdCBhcnQtdGV4dCBh
cnR3b3JrIiBpZD0iYXBwZW5kaXgtQS0yLjEiPgo8cHJlPgpyZmM2MDIxLnR4dCAgNDU5ICgoWzAt
MV0oXC5bMS0zXT9bMC05XSkpfCgyXC4oMHwoWzEtOV1cZCopKSkpCnJmYzYwMjEudHh0ICA1MTMg
XGQqKFwuXGQqKXsxLDEyN30KcmZjNjAyMS50eHQgIDUyOSBcZHs0fS1cZHsyfS1cZHsyfVRcZHsy
fTpcZHsyfTpcZHsyfShcLlxkKyk/CnJmYzYwMjEudHh0ICA2MzEgKFswLTlhLWZBLUZdezJ9KDpb
MC05YS1mQS1GXXsyfSkqKT8KcmZjNjAyMS50eHQgIDY0NyBbMC05YS1mQS1GXXsyfSg6WzAtOWEt
ZkEtRl17Mn0pezV9CnJmYzYwMjEudHh0ICA5MzMgKCg6fFswLTlhLWZBLUZdezAsNH0pOikoWzAt
OWEtZkEtRl17MCw0fTopezAsNX0KcmZjNjAyMS50eHQgIDkzOCAoKFteOl0rOil7Nn0oKFteOl0r
OlteOl0rKXwoLipcLi4qKSkpfApyZmM2MDIxLnR4dCAxMDI2ICgoOnxbMC05YS1mQS1GXXswLDR9
KTopKFswLTlhLWZBLUZdezAsNH06KXswLDV9CnJmYzYwMjEudHh0IDEwMzEgKChbXjpdKzopezZ9
KChbXjpdKzpbXjpdKyl8KC4qXC4uKikpKXwKcmZjNjAyMC50eHQgNjY0NyBbMC05YS1mQS1GXSoK
cmZjNjA5NS50eHQgMjU0NCBcUyguKlxTKT8KcmZjNjExMC50eHQgMTU4MyBbYWVpb3V5XSoKcmZj
NjExMC50eHQgMzIyMiBbQS1aXVthLXpdKgpyZmM2NTM2LnR4dCAxNTgzIFwqCnJmYzY1MzYudHh0
IDE2MzIgW15cKl0uKgpyZmM2NjQzLnR4dCAgNTI0IFxwe0lzQmFzaWNMYXRpbn17MCwyNTV9CnJm
YzY3MjgudHh0IDM0ODAgXFMrCnJmYzY3MjgudHh0IDM1MDAgXFMoLipcUyk/CnJmYzY5OTEudHh0
ICA0NzcgKChbMC0xXShcLlsxLTNdP1swLTldKSl8KDJcLigwfChbMS05XVxkKikpKSkKcmZjNjk5
MS50eHQgIDUyNSBcZCooXC5cZCopezEsMTI3fQpyZmM2OTkxLnR4dCAgNTQxIFthLXpBLVpfXVth
LXpBLVowLTlcLV8uXSoKcmZjNjk5MS50eHQgIDU0MiAufC4ufFteeFhdLip8LltebU1dLip8Li5b
XmxMXS4qCnJmYzY5OTEudHh0ICA1NzEgXGR7NH0tXGR7Mn0tXGR7Mn1UXGR7Mn06XGR7Mn06XGR7
Mn0oXC5cZCspPwpyZmM2OTkxLnR4dCAgNjY1IChbMC05YS1mQS1GXXsyfSg6WzAtOWEtZkEtRl17
Mn0pKik/CnJmYzY5OTEudHh0ICA2OTMgWzAtOWEtZkEtRl17Mn0oOlswLTlhLWZBLUZdezJ9KXs1
fQpyZmM2OTkxLnR4dCAgNzI1IChbMC05YS1mQS1GXXsyfSg6WzAtOWEtZkEtRl17Mn0pKik/CnJm
YzY5OTEudHh0ICA3NDMgWzAtOWEtZkEtRl17OH0tWzAtOWEtZkEtRl17NH0tWzAtOWEtZkEtRl17
NH0tCnJmYzY5OTEudHh0IDEwNDEgKCg6fFswLTlhLWZBLUZdezAsNH0pOikoWzAtOWEtZkEtRl17
MCw0fTopezAsNX0KcmZjNjk5MS50eHQgMTA0NiAoKFteOl0rOil7Nn0oKFteOl0rOlteOl0rKXwo
LipcLi4qKSkpfApyZmM2OTkxLnR4dCAxMDk5IFswLTlcLl0qCnJmYzY5OTEudHh0IDExMDkgWzAt
OWEtZkEtRjpcLl0qCnJmYzY5OTEudHh0IDExNjQgKCg6fFswLTlhLWZBLUZdezAsNH0pOikoWzAt
OWEtZkEtRl17MCw0fTopezAsNX0KcmZjNjk5MS50eHQgMTE2OSAoKFteOl0rOil7Nn0oKFteOl0r
OlteOl0rKXwoLipcLi4qKSkpfApyZmM3NDA3LnR4dCAgOTMzIChbMC05YS1mQS1GXSl7Mn0oOihb
MC05YS1mQS1GXSl7Mn0pezAsMjU0fQpyZmM3NDA3LnR4dCAxNDk0IChbMC05YS1mQS1GXSl7Mn0o
OihbMC05YS1mQS1GXSl7Mn0pezQsMzF9CnJmYzc3NTgudHh0ICA3MDMgXGR7Mn06XGR7Mn06XGR7
Mn0oXC5cZCspPwpyZmM3NzU4LnR4dCAxMzU4IFxkezJ9OlxkezJ9OlxkezJ9KFwuXGQrKT8KcmZj
Nzg5NS50eHQgIDM0OSBcZHs0fS1cZHsyfS1cZHsyfQpyZmM3OTUwLnR4dCA4MzIzIFswLTlhLWZB
LUZdKgpyZmM3OTUwLnR4dCA4MzU1IFthLXpBLVpfXVthLXpBLVowLTlcLV8uXSoKcmZjNzk1MC50
eHQgODM1NiBbeFhdW21NXVtsTF0uKgpyZmM4MDQwLnR4dCA0NzEzIFxkezR9LVxkezJ9LVxkezJ9
CnJmYzgwNDkudHh0IDY3MDQgW0EtWl17Mn0KcmZjODE5NC50eHQgIDYyOSBcKgpyZmM4MTk0LnR4
dCAgNjM3IFswLTldezh9XC5bMC05XXs2fQpyZmM4MTk0LnR4dCAgOTA1IFp8W1wrXC1dXGR7Mn06
XGR7Mn0KcmZjODE5NC50eHQgIDk2MyAoMigoMls0LTldKXwoM1swLTldKSlcLikuKgpyZmM4MTk0
LnR4dCAgOTc0ICgoW2ZGXXsyfVswLTlhLWZBLUZdezJ9KTopLioKcmZjODI5OS50eHQgNzk4NiBb
QS1aXXsyfQpyZmM4MzQxLnR4dCAxODc4IFwqCnJmYzgzNDEudHh0IDE5MjcgW15cKl0uKgpyZmM4
NDA3LnR4dCAxNzIzIFswLTlcLl0qCnJmYzg0MDcudHh0IDE3NDkgW2EtekEtWl9dW2EtekEtWjAt
OVwtXy5dKgpyZmM4NDA3LnR4dCAxNzUwIC58Li58W154WF0uKnwuW15tTV0uKnwuLltebExdLioK
cmZjODUyNS50eHQgIDU1MCBcZHs0fS1cZHsyfS1cZHsyfQpyZmM4Nzc2LnR4dCAgODM4IC8/KFth
LXpBLVowLTlcLV8uXSspKC9bYS16QS1aMC05XC1fLl0rKSoKcmZjODc3Ni50eHQgIDg3NCAoW2Et
ekEtWjAtOVwtXy5dKzopKgpyZmM4ODE5LnR4dCAgMzExIFtcUyBdKwpyZmM4OTQ0LnR4dCAgNTk2
IFswLTlhLWZBLUZdezJ9KDpbMC05YS1mQS1GXXsyfSl7N30KPC9wcmU+CjwvZGl2Pgo8ZmlnY2Fw
dGlvbj48YSBocmVmPSIjZmlndXJlLTIiIGNsYXNzPSJzZWxmUmVmIj5GaWd1cmUgMjwvYT46Cjxh
IGhyZWY9IiNuYW1lLWV4YW1wbGUtcmVndWxhci1leHByZXNzaW9ucyIgY2xhc3M9InNlbGZSZWYi
PkV4YW1wbGUgcmVndWxhciBleHByZXNzaW9ucyBleHRyYWN0ZWQgZnJvbSBSRkNzPC9hPgogICAg
ICAgIDwvZmlnY2FwdGlvbj48L2ZpZ3VyZT4KPC9kaXY+Cjwvc2VjdGlvbj4KPC9kaXY+CjxkaXYg
aWQ9ImFja25vd2xlZGdlbWVudHMiPgo8c2VjdGlvbiBpZD0iYXBwZW5kaXgtQiI+CiAgICAgIDxo
MiBpZD0ibmFtZS1hY2tub3dsZWRnZW1lbnRzIj4KPGEgaHJlZj0iI25hbWUtYWNrbm93bGVkZ2Vt
ZW50cyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5BY2tub3dsZWRnZW1lbnRzPC9hPgog
ICAgICA8L2gyPgo8cCBpZD0iYXBwZW5kaXgtQi0xIj5UaGlzIGRyYWZ0IGhhcyBiZWVuIG1vdGl2
YXRlZCBieSB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiBKU09OUEFUSApXRyBhYm91dCB3aGV0
aGVyIHRvIGluY2x1ZGUgYSByZWdleHAgbWVjaGFuaXNtIGludG8gdGhlIEpTT05QYXRoIHF1ZXJ5
CmV4cHJlc3Npb24gc3BlY2lmaWNhdGlvbiwgYXMgd2VsbCBhcyBieSBwcmV2aW91cyBkaXNjdXNz
aW9ucyBhYm91dCB0aGUKWUFORyA8Y29kZT5wYXR0ZXJuPC9jb2RlPiBhbmQgQ0RETCA8Y29kZT4u
cmVnZXhwPC9jb2RlPiBmZWF0dXJlcy48YSBocmVmPSIjYXBwZW5kaXgtQi0xIiBjbGFzcz0icGls
Y3JvdyI+wrY8L2E+PC9wPgo8cCBpZD0iYXBwZW5kaXgtQi0yIj5UaGUgYmFzaWMgYXBwcm9hY2gg
Zm9yIHRoaXMgZHJhZnQgd2FzIGluc3BpcmVkIGJ5IDxzcGFuPjxhIGhyZWY9IiNSRkM3NDkzIiBj
bGFzcz0ieHJlZiI+VGhlCkktSlNPTiBNZXNzYWdlIEZvcm1hdDwvYT4gWzxhIGhyZWY9IiNSRkM3
NDkzIiBjbGFzcz0ieHJlZiI+UkZDNzQ5MzwvYT5dPC9zcGFuPi48YSBocmVmPSIjYXBwZW5kaXgt
Qi0yIiBjbGFzcz0icGlsY3JvdyI+wrY8L2E+PC9wPgo8L3NlY3Rpb24+CjwvZGl2Pgo8ZGl2IGlk
PSJhdXRob3JzLWFkZHJlc3NlcyI+CjxzZWN0aW9uIGlkPSJhcHBlbmRpeC1DIj4KICAgICAgPGgy
IGlkPSJuYW1lLWF1dGhvcnMtYWRkcmVzcyI+CjxhIGhyZWY9IiNuYW1lLWF1dGhvcnMtYWRkcmVz
cyIgY2xhc3M9InNlY3Rpb24tbmFtZSBzZWxmUmVmIj5BdXRob3IncyBBZGRyZXNzPC9hPgogICAg
ICA8L2gyPgo8YWRkcmVzcyBjbGFzcz0idmNhcmQiPgogICAgICAgIDxkaXYgZGlyPSJhdXRvIiBj
bGFzcz0ibGVmdCI+PHNwYW4gY2xhc3M9ImZuIG5hbWVSb2xlIj5DYXJzdGVuIEJvcm1hbm48L3Nw
YW4+PC9kaXY+CjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0ibGVmdCI+PHNwYW4gY2xhc3M9Im9yZyI+
VW5pdmVyc2l0w6R0IEJyZW1lbiBUWkk8L3NwYW4+PC9kaXY+CjxkaXYgZGlyPSJhdXRvIiBjbGFz
cz0ibGVmdCI+PHNwYW4gY2xhc3M9InN0cmVldC1hZGRyZXNzIj5Qb3N0ZmFjaCAzMzA0NDA8L3Nw
YW4+PC9kaXY+CjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0ibGVmdCI+CjxzcGFuIGNsYXNzPSJwb3N0
YWwtY29kZSI+RC0yODM1OTwvc3Bhbj4gPHNwYW4gY2xhc3M9ImxvY2FsaXR5Ij5CcmVtZW48L3Nw
YW4+CjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9ImxlZnQiPjxzcGFuIGNsYXNzPSJjb3Vu
dHJ5LW5hbWUiPkdlcm1hbnk8L3NwYW4+PC9kaXY+CjxkaXYgY2xhc3M9InRlbCI+CjxzcGFuPlBo
b25lOjwvc3Bhbj4KPGEgaHJlZj0idGVsOis0OS00MjEtMjE4LTYzOTIxIiBjbGFzcz0idGVsIj4r
NDktNDIxLTIxOC02MzkyMTwvYT4KPC9kaXY+CjxkaXYgY2xhc3M9ImVtYWlsIj4KPHNwYW4+RW1h
aWw6PC9zcGFuPgo8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiBjbGFzcz0iZW1haWwiPmNh
Ym9AdHppLm9yZzwvYT4KPC9kaXY+CjwvYWRkcmVzcz4KPC9zZWN0aW9uPgo8L2Rpdj4KPHNjcmlw
dD5jb25zdCB0b2MgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgidG9jIik7CnRvYy5xdWVyeVNl
bGVjdG9yKCJoMiIpLmFkZEV2ZW50TGlzdGVuZXIoImNsaWNrIiwgZSA9PiB7CiAgdG9jLmNsYXNz
TGlzdC50b2dnbGUoImFjdGl2ZSIpOwp9KTsKdG9jLnF1ZXJ5U2VsZWN0b3IoIm5hdiIpLmFkZEV2
ZW50TGlzdGVuZXIoImNsaWNrIiwgZSA9PiB7CiAgdG9jLmNsYXNzTGlzdC5yZW1vdmUoImFjdGl2
ZSIpOwp9KTsKPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo=
--0000000000001cbe2a05d5f26a22--


From nobody Wed Jan 19 09:11:09 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E20B3A1437 for ; Wed, 19 Jan 2022 09:11:08 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX2lKS4X7z_3 for ; Wed, 19 Jan 2022 09:11:04 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33F23A142A for ; Wed, 19 Jan 2022 09:11:03 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JfBxH46TCzDCd1; Wed, 19 Jan 2022 18:10:59 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 19 Jan 2022 18:10:59 +0100
Cc: Greg Dennis , "jsonpath@ietf.org" 
X-Mao-Original-Outgoing-Id: 664305059.15109-654515c08b4e0c92673d80feca53b331
Content-Transfer-Encoding: quoted-printable
Message-Id: <592FA72D-7F2C-4632-B4DE-508F721B32BD@tzi.org>
References:  <1290004912.869539.1642537141570@mail.yahoo.com> 
To: Tim Bray 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Jan 2022 17:11:08 -0000

On 2022-01-19, at 18:06, Tim Bray  wrote:
>=20
> Oh, an update: I sent a big PR yesterday reorganizing the draft while =
preserving more or less all of its content: =
https://github.com/cabo/iregexp/pull/1 and I just saw Carsten merged it. =
 For convenience, I've attached what the HTML now looks like.

FYI: Due to the magic of Martin Thomson=E2=80=99s I-D-Template, you can =
always current HTML at

https://cabo.github.io/iregexp/draft-bormann-jsonpath-iregexp.html

=E2=80=A6 which is referenced from the README as =E2=80=9CEditor=E2=80=99s=
 copy=E2=80=9D.

I=E2=80=99ll push a commit with a few minor consistency edits soon.
Then on to Michael Kay=E2=80=99s comment, which is very good, but =
complicated in its consequences.

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


From nobody Wed Jan 19 15:32:17 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40BB3A089A for ; Wed, 19 Jan 2022 15:32:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m13xGj-qTsE for ; Wed, 19 Jan 2022 15:32:11 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439723A0897 for ; Wed, 19 Jan 2022 15:32:10 -0800 (PST)
Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JfMP04fBBzDCcP; Thu, 20 Jan 2022 00:32:04 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 20 Jan 2022 00:32:04 +0100
Cc: Tim Bray , jsonpath@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9343D2DD-C707-4E83-8DA1-F485B2F5ABFF@tzi.org>
References:  
To: Michael Kay 
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Jan 2022 23:32:16 -0000

On 18. Jan 2022, at 19:30, Michael Kay  wrote:
>=20
> I would suggest referencing XSD 1.1 rather than XSD 1.0.
>=20
> The only difference in the regex capabilities is that XSD 1.1 fixes =
some bugs in the specification. It would be a shame to have a normative =
reference to a spec with known bugs.

I have made a pull request that references XSD 1.1 as well.

https://github.com/cabo/iregexp/pull/3

This PR recognizes the fact that XSD 1.0 is more widely implemented than =
XSD 1.1.
Both RFC 7950 and RFC 8610 reference only XSD 1.0 (and imply that an =
astute consumer of any specification will handle the errata with that, =
especially if they have been known for a decade and more).
Potentially giving the impression that I-Regexp somehow needs XSD 1.1, =
which brings a lot of baggage that is not relevant here, would be highly =
misleading.

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


From nobody Wed Jan 19 16:04:40 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED503A0B3A for ; Wed, 19 Jan 2022 16:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 GYs2UsnzmJZ2 for ; Wed, 19 Jan 2022 16:04:35 -0800 (PST)
Received: from p3plwbeout13-04.prod.phx3.secureserver.net (p3plsmtp13-04-2.prod.phx3.secureserver.net [173.201.192.168]) (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 569AC3A0B35 for ; Wed, 19 Jan 2022 16:04:34 -0800 (PST)
Received: from mailex.mailcore.me ([94.136.40.141]) by :WBEOUT: with ESMTP id AKwLnlc8jzUe3AKwLnOX7u; Wed, 19 Jan 2022 17:04:34 -0700
X-CMAE-Analysis: v=2.4 cv=E7sIGYRl c=1 sm=1 tr=0 ts=61e8a712 a=bheWAUFm1xGnSTQFbH9Kqg==:117 a=np+Hvx21kC4Q4qxhmORf6Q==:17 a=iO2Z4BJ_FnUA:10 a=kj9zAlcOel0A:10 a=DghFqjY3_ZEA:10 a=SSmOFEACAAAA:8 a=u4N4SSmShvQ547jWAbUA:9 a=CjuIK1q_8ugA:10
X-SECURESERVER-ACCT: mike@saxonica.com  
X-SID: AKwLnlc8jzUe3
Received: from cpc160115-rdng30-2-0-cust150.15-3.cable.virginm.net ([86.19.35.151] helo=smtpclient.apple) by smtp06.mailcore.me with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nAKwK-00052E-LY; Thu, 20 Jan 2022 00:04:32 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Michael Kay 
In-Reply-To: <9343D2DD-C707-4E83-8DA1-F485B2F5ABFF@tzi.org>
Date: Thu, 20 Jan 2022 00:04:31 +0000
Cc: Tim Bray , jsonpath@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C47123C-4D61-475D-900C-1C2F311D4796@saxonica.com>
References:   <9343D2DD-C707-4E83-8DA1-F485B2F5ABFF@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Mailcore-Auth: 439400257
X-Mailcore-Domain: 1881035
X-123-reg-Authenticated: mike@saxonica.com  
X-Originating-IP: 86.19.35.151
X-CMAE-Envelope: MS4xfCr6dfprHHxzHb8v6x6BCMH3pT/Ade8qf/Lw3uAr9Gu16nwu6I/pdyLKijMu7rsHXNgOK4Lc7LpVKlgLYI/uuxEAxNPfb4L5rYErSfyGFZMPWR3iyf/t A2kvTh/OThFZNwb+Q+qXL7rx19MMotYPRedJyk4faD1pqrtGKwRdfAuwLOYNOJOLLzTDHQ8zT5RA3w==
Archived-At: 
Subject: Re: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Jan 2022 00:04:39 -0000

>=20
> This PR recognizes the fact that XSD 1.0 is more widely implemented =
than XSD 1.1.

If we're talking about implementations, then they will have had to fix =
the bugs in the XSD 1.0 spec, and hopefully in most cases they will have =
fixed them in the same way as XSD 1.1 fixed them. (However, some XSD 1.0 =
implementors, notably Microsoft, largely ignored the XSD-defined regex =
rules and just used an existing regex library.)

But I thought we were talking about specs, not about implementations.

For some of the discussion of bugs, see

https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D1889

https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D2019

https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D2058

https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D2123

Unfortunately these reference documents which are not publicly =
accessible.

To the best of my knowledge there are no changes in regex =
syntax/semantics between XSD 1.0 and 1.1 other than bug fixes.

Michael Kay



From nobody Sat Jan 22 09:21:01 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365163A2409 for ; Sat, 22 Jan 2022 09:20:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V074y_USzCJ1 for ; Sat, 22 Jan 2022 09:20:55 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 2F3AA3A2405 for ; Sat, 22 Jan 2022 09:20:55 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id j2so9083043ejk.6 for ; Sat, 22 Jan 2022 09:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=uFH5oaFcZ0AUoCiqmJYYxnAGKDkoSLgMIaABItU9Gqs=; b=UrMyCPtq3ndPIh8jnjzNA4gu/xyeHnb2OzkY0lyYabl/KY2kcAxQWBu3iD0W6Z5tNI 7I0m9MW04/xBsndlTDxPsYSZVqPy6M1bqNAqLMTVaaUTbPxWQWZorETD2NVwDuObAXF8 iBB7SLjWR7WyZwbhRldA+BA/jJZBhsli9lZs/gt02B9rcikFYG/PSA5zSXTF4zhGxLxw /lTHdwv5CWH90+XxKf28VYeiPDo88hzUdm8qHSWhVGEfyi+m4AC/YGuH0GogUvRVAxMM Lmksk9OHgIULHDhBFBNQ1ftU4wZIZp7MkCl2/Y2W6dJdcwV2c6lX0PdsaCrtl4iBnFBY LalA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=uFH5oaFcZ0AUoCiqmJYYxnAGKDkoSLgMIaABItU9Gqs=; b=QSBHw4NhWtH22U2HAc+FN6PgQ5vuu1h+u8aD0NWqHh++nOGJi5dr4TGek4dTNvye1T P9LYyZc0LowMjAh+Vzc/znmZD55Hexct2pPNe4tV0vE3+mbSn1ZrBm97w6ha5yeponWS fCo1kQaUwQWnqNkBYgcjlg9wvCCaqeUkK/MXpquAvkwGV0eKW6UoNWQpVUzKYy3i956w +bhqkDpgPnsp2EckcXq/IPdxKWMP9v8eUkhuY+KvPD6+HS4yfrulzj9CVGl1DZB9LYGw G4PTZsiSDJwRrtiuXuymAcz1gcY2ctNtjYzxTS448hBqRTGo5RyGzAa7UQbol7sBtTQ+ 14Cg==
X-Gm-Message-State: AOAM531tPMRFDjy7E0KxXJhauWVlhz9kB7iPK0lS5a7PSKBfl5SzJ/gE 46CyNy4jpNKWFDrD4ErsPICT04x2qXVsbg==
X-Google-Smtp-Source: ABdhPJwSr+RqZ8UKjaULsdr5bq8gn+laS0UlsOBsLZ4Re/bZCmplGRD9hODD99jazJtArXcVMDV2Iw==
X-Received: by 2002:a17:906:7b92:: with SMTP id s18mr7526885ejo.407.1642872052885;  Sat, 22 Jan 2022 09:20:52 -0800 (PST)
Received: from smtpclient.apple ([2001:984:65b0:1:b067:9f4d:60c4:98eb]) by smtp.gmail.com with ESMTPSA id w22sm3053064ejj.64.2022.01.22.09.20.51 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jan 2022 09:20:51 -0800 (PST)
From: James 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Message-Id: <8C73386C-B327-4C0B-AAD2-7267F55AD5BE@gmail.com>
Date: Sat, 22 Jan 2022 18:20:51 +0100
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: [Jsonpath] Draft minutes, consensus points, and actions from January 2022 Interim
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Jan 2022 17:20:58 -0000

Folks,
Minutes from our January Interim are now uploaded to datatracker here:

=
https://datatracker.ietf.org/meeting/interim-2022-jsonpath-01/materials/mi=
nutes-interim-2022-jsonpath-01-202201181100-00

Consensus:
* We'll set a call for adoption for the iregexp document and include it =
as dependency to JSONPath

Actions:
* Status - Editors to re-open issues labeled with =
"revise-after-base-done" after IESG submission of base document
* #123 - Email to list to discuss and finalised "undefined" behaviour as =
preferred approach
* #123 - Examples of this behaviour to be included in base document
* #70 - Confirm consensus call to the list
* #70 - Work on the embedding of regular expressions in JSONPath
* #21 - Carsten to make a PR with a proposal
* Next - Call for Adoption for iregexp - Done, see =
https://mailarchive.ietf.org/arch/msg/jsonpath/VpHilzY8XGWB_sTjusigEQ84Mxs=
/
* Poll for next Interim meeting - Done, see =
https://mailarchive.ietf.org/arch/msg/jsonpath/XiZN0RCypD8yjdhx2vVGjkrV7w8=
/

Please let me know of any omissions or errata.

- J=


From nobody Sun Jan 23 13:49:24 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CFE3A2BF9 for ; Sun, 23 Jan 2022 13:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcNPPy7UMR0O for ; Sun, 23 Jan 2022 13:49:17 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9F83A2BF8 for ; Sun, 23 Jan 2022 13:49:15 -0800 (PST)
Received: from smtpclient.apple (p5089a5d9.dip0.t-ipconnect.de [80.137.165.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JhmwR22CdzDCcF; Sun, 23 Jan 2022 22:49:11 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Carsten Bormann 
In-Reply-To: <8C73386C-B327-4C0B-AAD2-7267F55AD5BE@gmail.com>
Date: Sun, 23 Jan 2022 22:49:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2062FF94-00A8-47C7-BEF4-6E12D61CDADB@tzi.org>
References: <8C73386C-B327-4C0B-AAD2-7267F55AD5BE@gmail.com>
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: Re: [Jsonpath] Draft minutes, consensus points, and actions from January 2022 Interim
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Jan 2022 21:49:21 -0000

On 22. Jan 2022, at 18:20, James  wrote:
>=20
> * #21 - Carsten to make a PR with a proposal

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/147

Please comment.

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


From nobody Sun Jan 23 14:06:07 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344743A2C7F for ; Sun, 23 Jan 2022 14:06:06 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS9sPw5JAaA7 for ; Sun, 23 Jan 2022 14:06:01 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6194C3A2C80 for ; Sun, 23 Jan 2022 14:06:00 -0800 (PST)
Received: from smtpclient.apple (p5089a5d9.dip0.t-ipconnect.de [80.137.165.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JhnHn1pqbzDCcV; Sun, 23 Jan 2022 23:05:57 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Date: Sun, 23 Jan 2022 23:05:56 +0100
Message-Id: 
To: jsonpath@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: [Jsonpath] application/jsonpath media type
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Jan 2022 22:06:06 -0000

I did a quick pull request to register the application/jsonpath media =
type:

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/149

Comments welcome.

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


From nobody Sun Jan 23 19:17:41 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127343A1708 for ; Sun, 23 Jan 2022 19:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 XBMqINOPU4Tx for ; Sun, 23 Jan 2022 19:17:38 -0800 (PST)
Received: from sonic312-22.consmr.mail.bf2.yahoo.com (sonic312-22.consmr.mail.bf2.yahoo.com [74.6.128.84]) (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 50C123A1705 for ; Sun, 23 Jan 2022 19:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642994257; bh=KpCvpwXfzn7JZ46ZWY12jQ1PtBdJ0pf9LRTYg583mvI=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=qdhByRMWYi/sqei2jEq8bjuEcriOZYY8UL46AdlgSEs0MkJwCRBsfuVBLRnJOxhN/5JMJTMulUZttc2pwkMmPE7S1M23OqzITj5htpIb5iImXz/aVn/iV1IcV1pXdynfLu93kp9+C92g3AjBzU0ZhzfmeL9x/jqPWBI07tSqLkO24SVFTjfvHzIBAJKxBZmZdsAYePVrM6u5VCUrOLbrpL7rFDcYTXQAvKaSRzOta0lm0RTa07dT6Bxy5bzgd9DPg8Tv/Eq7iVnIJxnI1jW/mLBtemFcYOm1V4QHlw3QSIDNDwQBk9qC8Z9zD1SEkfuD3t/lFpP6ytlidhqc++n5AQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1642994257; bh=5JHE+QGhCm6XzcmY/FU0AURxoEhFSO4UHHQOecET7al=;  h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=tuoSVBH8uYYMzRf0RR0RM5qAylwCKQ7h7voZOuoxNs9KkNJvt331y/s3SWmjAscYGcEo6XDAZ9qxKRuPu9Ac8lTnSuAqx/pdOujLogmQEUJJAf971qVktZrfRsLNA8YDnAtaOijHK/7MIZ1IvSpWmQRohI88BY3o/2bVoQWV1r+PwfXOJvxJeTMVeZYzwIMtngWYC/exaJYOpPyT+chXKu7UtlA1jjUVbG5p+hzyNDQui/p/BOzT1LlDCr4mHyJwcB37ASPIIqd/Jgvjyep2FVkwmFHfA61b7yPnupyEQlMcMIGIl+RJYkWpSRQb1ZCwtOMjffhGiyBO0sMXjssiaw==
X-YMail-OSG: 1d72SFAVM1mBiv.fLsSWDk3yZRafTyWmsYVsH.nHLNdv4.tEBSGQpGV2cAy5fwA GNJCTU_Wypo6qAYLQT04_LLDgm3BNG2frktqJidqDYg1r9rQtZvrEwGQ38BLec37sU.MZ46YsD6N QeKZenAypxYilPfqwWheIgmLYDIO6ht9zqq5gYEiTD084XTfHiEV_j.2CaGjCuM6_PdIj6bk2Q4S PLuAUxUwRNShmPkqx7VdlngzPK6B1E2nGmd0c8CiXugdnXuYc7MHAJBG5nmXvKjXSneMBmhlPoME J76aDOc7iuG6wSPBnZw2S4YyRZxoxD1GCr3Ag1.zADSZe4NNX7wYfgxpET1maJWvx8eegNypfNma 8TnEuogyyWcoXKqNVRF9slcZnTQcPShvWHttK_4fMeRn3F79X0KW_NyBVZTvH4E0wE.dfe9Fl4iO GOQzK3CedSqt1gCFQMFZ2RhzwxnFwep2esng7ZXuQFa67i4REahiQbVSfh3q_KAw7fYXXpSrHXd1 ob9f_QYfRmGTO2ZiJszQz5dFTEoketYi1MyQrpin34YMysPgXWeE1txw5nonyEduHVfuih9ElrrH CMmhC73Ae9au8zbewQdSJfx4pBYXFCk1o3fQTkqpHhiaFiL5fFG5fdVWkZiNd9QkJN4ePi56zsa. pYHEEjVPF2MbAgM5D9SFglXgh2l26wtFi44MSDzl6aFJIQf2Ywt2TqcSvr8h4lxFH5W1yUw.uMss qMqvwXbvkFAlr1ajwZuw.dZt.AIvOmduN_OWoFyxM1JiI1LH4VjxWMaqE7I355ketug6v3hJL_.Q eaHVEqTEBRBLx6AXKl6vpnyVh_d1vfQqcIRwi.KC5UUHUt2kZ504m7UiU9hL12jukzEnpm8fEFjm w93TFZn_GcU1j8X9SF_way_pqLsfq9n8t259uSB3g458SckMssqtKL8U78Vyu9_NflpRZmLbtlrG MlDRk0Tg5IVD6u.4BDJHMz9FwVdbdaOYIvSoI6IAr3WFAr7v2kBqN4s5hB4mcksekejp6bbfX6Jc GOIUJXulLWPbW.yZKmzZ1tHPbPdM_DUbVm2v.5fhdPBP5ll4lkuyvdRHh3kokI0M6NoJ0xdqXpsi .mtpI4XJtFJK1v4.FS7kch9jaRvPSlBuGMEth2n9bkinUcdcdTT.02hPsNHcZteYvTKlZUK_Idvr QrKNjG3uovDQlBlEegkL6IK3LpsKE9q8.x8Lv0dxNGM1eYmwJOykvShS71a3YO31c2nIlOKaRJ7K 7tTXuYvOhgVoSVTBceB18EPR.lvsNhgSFWFcdkuAwL9pEkoJbfy7VrQD6aEuRRvYIcGPXsuwZSmT Ub4WoRpNcGfIzUTdYC_nZpNtv7zVNw1.mqE7j47lh5S_k8v4TNzRovj8bT9WNid4htFicl8eDMej Rn59_oDZ6kVyIU8sEyJvSKgk7P3.yOr7toP5Q2OlUaJQn1PiHezd13IgFetuAk.JcFXwzJ5tNUd1 P1BIQHrWjQ8l5Jjn_R87DvXgJWrcfqyM3cAwhzpStVv7QVUTQqusCLsVIkG6C8D24bBavMR.Faqr IHH2TxuXkwGXMhk.6aHwEeC0ZxCwTeP2oxFJ.yxrQfeM43gMlDarvGF97DET5PsZswqfiFWbEBit ibhkA2ZulDftgEjkWwtA51UtlUc0eolRXiLzBM7ccADEiOv6bZWAn9i7uHozbORgSSGIJ_5e7.Nv xcuQo542a09twBBBG0m8zDaSM5qPXfrfINqlvLK1J8Ry1T3nVs6qdkuBCclbdMu3.nz390LKXC0X mNK183TC.DoL38EokZHSmKJZeKOFmyI5F18Nq5A52tpqc9FRCXU7NV4phys_sl80StwcJKYyBl8f XslrlV4vnisMyB3XV_GbDc58GBE5Pmn7zP8D1g_4VNMqyzhCbhs5L5rBnU1IG4.o.mgcQSFgW43H Pzi6xa8.p2sm14i7CnBBOQbyIhGOVUNfiV4Xx1.Qgcs2cOaBRaBlrmes5tZbI5rIG_0_8QONHvsF 2ecdb77pBrLnfmP8pi4ayJNaiTGsLC0lhcTW2.zJg9bycDIrdqPd3AZsm9ySlkCtO.NEUcnWM2xe 6byAWkpB1Cv1UTqOyZ3YaZgB91hxLEuLOUaqJMJJgbest_0n5ea_mKLIOwXq2T55w9Xj2fjW79sD xay.D1cywXGQjs6QI1fjB.dxoaAkK5PKWqy9NFCObNi7hSWlqDVjEnoPvz3_uBp28qyKhLKRF.4h wXbqwrDvLpQs-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 24 Jan 2022 03:17:37 +0000
Date: Mon, 24 Jan 2022 03:18:04 +0000 (UTC)
From: Greg Dennis 
To: jsonpath@ietf.org
Message-ID: <1325036172.786283.1642994284084@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_786282_246265744.1642994284083"
References: <1325036172.786283.1642994284084.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.19615 YMailNorrin
Archived-At: 
Subject: [Jsonpath] Implementation update
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Jan 2022 03:17:40 -0000

------=_Part_786282_246265744.1642994284083
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm just letting everyone know that I plan on updating my implementation to=
 conform to specification behavior after this next round of edits.=C2=A0 It=
's admittedly been a while.

Glyn, do you know if there are any changes needed in the reference implemen=
tation test suite?=C2=A0 It seems that we're closing in on knowing what the=
 output should look like (e.g. determinism, duplicates, etc.).
Greg
------=_Part_786282_246265744.1642994284083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


I'm just letting everyone know that I plan on updating my implementation to conform to specification behavior after this next round of edits.  It's admittedly been a while.

Glyn, do you know if there are any changes needed in the reference implementation test suite?  It seems that we're closing in on knowing what the output should look like (e.g. determinism, duplicates, etc.).

Greg

------=_Part_786282_246265744.1642994284083--


From nobody Wed Jan 26 06:38:26 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14F3A124E for ; Wed, 26 Jan 2022 06:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.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 NfbA7zFrg9-A for ; Wed, 26 Jan 2022 06:38:24 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 DAF6E3A11E5 for ; Wed, 26 Jan 2022 06:38:23 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id o12so19993584lfg.12 for ; Wed, 26 Jan 2022 06:38:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=5yOyWyDLXmwwE9VIes42SEXbUYgnz/cF4j9uHs2AhPU=; b=Lk9ano2Eyo0AcQaqd79pPqv1S91Jny+4Rs8lIJ0IWKHhaXDS6aV/f0VrrQ9Xx7nHvT 6kU+ImRMFJN377IoQiWKXytu00ygUYmnM5fm1VmQxQE9noMY4bOsVZojVFOBs45dN/ab ECkyYiERTDcx/0dwPA2bhn3vTbHdnK6ZVNSCl9MMkFVBrkNiHtv6zIqKzdkbAtH0tpuK n+/ug5/DgEtvfIfa2AcSGSqwN3VUH5PMVp6JRjMjZXl/AHmvptCDhALoCS+VpOwqaAki CYGXNIqtTFSHrfRL0uXxBo/EzWtDF1iIUGg5fCF6g0/zZzuimk/R8M1r7m0EQOsKzj/M W//w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5yOyWyDLXmwwE9VIes42SEXbUYgnz/cF4j9uHs2AhPU=; b=xEmxgkfPJP4K6H7/mkUB6lWjGiC7o2Tvtnry2KmIMoYy0cs2IvEbFBhnHLeN2C+rNV jspSTRf0h9eO/MfsMIYPIJsH+hEqnL9kHDVlEPRIYPTJcTVW8DcawGpTxhRdN2H7COR4 L5oVih2Op3rwWSBOKhQ7Z7q2/bKhgSZOLuUbLVss4w+y3j4Die6D+s85B5TrdZx9rU0h 1vR/2Km37Gh8DBeJz5T4QWa2M0g0S2N1jm63IGjZYvXFZ5surAbHky9MeJZKrLNO2tYk 5MN5hMFHah1K9dLPvLZPP/qnQVsW/CTKwDMwfbQlSXyyv6/dhANjNhC0kmUyjyckCKUy xpVQ==
X-Gm-Message-State: AOAM530oamtjoD+Nr+CbAHdOpP/yp2l2Ui3xORt2OuEc6DIj/OXaTUzz TFv/A6msaLXtnMHMKQIAWJP5LR3daCHSZ9dk7bF1gILfr/M=
X-Google-Smtp-Source: ABdhPJwW+iwZFDU6zPYs9LeVlusDxaa7fsncOFQ03d3d9zl5ddzSpey2O38znD5kkTWqERPQQ9IDZUvnqJuJha90Irk=
X-Received: by 2002:a05:6512:3406:: with SMTP id i6mr20307876lfr.637.1643207900543;  Wed, 26 Jan 2022 06:38:20 -0800 (PST)
MIME-Version: 1.0
From: Tim Bray 
Date: Wed, 26 Jan 2022 06:38:08 -0800
Message-ID: 
To: jsonpath@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003453b005d67d279c"
Archived-At: 
Subject: [Jsonpath] Is [^] legal?
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jan 2022 14:38:26 -0000

--0000000000003453b005d67d279c
Content-Type: text/plain; charset="UTF-8"

[Am AFK and wanted to capture this before it vanished into the tweetstream.
I assume it just matches literal "^"? -Tim]

The Daniel Martin who follows all the other ones (@dtm609) tweeted at 3:23
a.m. on Wed., Jan. 26, 2022:
The grammar seems to allow this I-Regexp:

[^]

(Since a single caret is a legal CCE1)

I wonder what the intended semantic of that expression is. In PCRE or RE2,
that's a syntax error but Ecmascript accepts it as a synonym for ".".

I'm not familiar enough with XSD regex to say.
(
https://twitter.com/dtm609/status/1486298655497854979?t=WEw50TO63UIVdN9aWIt4nA&s=03
)

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


[Am AFK and wanted to capture this befo=
re it vanished into the tweetstream. I assume it just matches literal "=
;^"? -Tim]

The Daniel Martin who foll=
ows all the other ones (@dtm609) tweeted at 3:23 a.m. on Wed., Jan. 26, 202=
2:
The grammar seems to allow this I-Regexp:

[^]
(Since a single caret is a legal CCE1)

I wonder what the intend=
ed semantic of that expression is. In PCRE or RE2, that's a syntax erro=
r but Ecmascript accepts it as a synonym for ".".

I'm =
not familiar enough with XSD regex to say.
(https://twitter.com/dtm609/status/1486298655497854979?t=3DWEw50TO63UIVdN9a=
WIt4nA&s=3D03)=C2=A0


--0000000000003453b005d67d279c--


From nobody Wed Jan 26 07:49:48 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8678C3A1531 for ; Wed, 26 Jan 2022 07:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 6aks4tEoz7tj for ; Wed, 26 Jan 2022 07:49:43 -0800 (PST)
Received: from p3plwbeout06-02.prod.phx3.secureserver.net (p3plsmtp06-02-2.prod.phx3.secureserver.net [97.74.135.57]) (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 E5C513A1528 for ; Wed, 26 Jan 2022 07:49:23 -0800 (PST)
Received: from mailex.mailcore.me ([94.136.40.144]) by :WBEOUT: with ESMTP id CkXynIy0e9agiCkXzn7iOr; Wed, 26 Jan 2022 08:49:23 -0700
X-CMAE-Analysis: v=2.4 cv=LuVXdlRc c=1 sm=1 tr=0 ts=61f16d83 a=wXHyRMViKMYRd//SnbHIqA==:117 a=G++axsv19AQkVQuwCdl4cA==:17 a=0d-FJ89MWBcA:10 a=DghFqjY3_ZEA:10 a=ZEAgVxdcAAAA:8 a=JqEG_dyiAAAA:8 a=48vgC7mUAAAA:8 a=ejBRUuNrk-3W_sU6JNgA:9 a=QEXdDO2ut3YA:10 a=vQIlQYnbEAAA:10 a=WbRSqvxxkyQqfn8EkLkA:9 a=TWCnyiBflsUznlBa:21 a=_W_S_7VecoQA:10 a=K4stkocu346RsC3JbKGV:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: mike@saxonica.com  
X-SID: CkXynIy0e9agi
Received: from [82.152.109.221] (helo=smtpclient.apple) by smtp02.mailcore.me with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nCkXw-000309-6l; Wed, 26 Jan 2022 15:49:22 +0000
From: Michael Kay 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFA103A5-CBA8-4C8F-847E-4F7368E92964"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 26 Jan 2022 15:49:19 +0000
In-Reply-To: 
Cc: jsonpath@ietf.org
To: Tim Bray 
References: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Mailcore-Auth: 439400257
X-Mailcore-Domain: 1881035
X-123-reg-Authenticated: mike@saxonica.com  
X-Originating-IP: 82.152.109.221
X-CMAE-Envelope: MS4xfF0T+YPQE2bgSU9iYUDXExdRDsorw8lzoEHSqBI7dG4imuIkNLYbmUN1FtIcC2Na0ofCx5VrI5WtO6rr6cpxduaKQeEURnKdrjii8KSHZpZTAgmhQPvG P/xhoSxL3+/WBowbxXoWP15opN8GIkqqb+yKlWU+i7yJgB4prTM6AiA6GNE5yFPd+CqHQNH0kzzk2A==
Archived-At: 
Subject: Re: [Jsonpath] Is [^] legal?
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jan 2022 15:49:48 -0000

--Apple-Mail=_EFA103A5-CBA8-4C8F-847E-4F7368E92964
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

XSD 1.1 part 2 says in =C2=A7G.4.1:

Note: For example, the string '[^X]' is ambiguous according the grammar =
rules, denoting either a character class consisting of a negative =
character group with 'X' as a member, or a positive character class with =
'X' and '^' as members.  The normative prose rule just given requires =
that the first interpretation be taken.
The string '[^]' is unambiguous: the grammar recognizes it as a =
character class expression containing a positive character group =
containing just the character '^'.  But the grammatical derivation of =
the string violates the rule just given, so the string '[^]' must not be =
accepted as a regular expression.

Michael Kay
Saxonica

> On 26 Jan 2022, at 14:38, Tim Bray  wrote:
>=20
> [Am AFK and wanted to capture this before it vanished into the =
tweetstream. I assume it just matches literal "^"? -Tim]
>=20
> The Daniel Martin who follows all the other ones (@dtm609) tweeted at =
3:23 a.m. on Wed., Jan. 26, 2022:
> The grammar seems to allow this I-Regexp:
>=20
> [^]
>=20
> (Since a single caret is a legal CCE1)
>=20
> I wonder what the intended semantic of that expression is. In PCRE or =
RE2, that's a syntax error but Ecmascript accepts it as a synonym for =
".".
>=20
> I'm not familiar enough with XSD regex to say.
> =
(https://twitter.com/dtm609/status/1486298655497854979?t=3DWEw50TO63UIVdN9=
aWIt4nA&s=3D03 =
)=20
> --=20
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath


--Apple-Mail=_EFA103A5-CBA8-4C8F-847E-4F7368E92964
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

XSD =
1.1 part 2 says in =C2=A7G.4.1:

Note: For example, the string '[^X]' is ambiguous according the grammar rules, =
denoting either a character class consisting of a negative character =
group with 'X' as a member, or a positive =
character class with 'X' and '^' as members.  The normative prose rule just =
given requires that the first interpretation be taken.
The =
string '[^]' is unambiguous: the grammar =
recognizes it as a character class expression containing a positive =
character group containing just the character '^'.  But the grammatical derivation of the string =
violates the rule just given, so the string '[^]' must =
not be accepted as a regular expression.

Michael Kay
Saxonica

On 26 Jan 2022, at 14:38, Tim =
Bray <tbray@textuality.com> wrote:

[Am AFK and wanted to capture =
this before it vanished into the tweetstream. I assume it just matches =
literal "^"? -Tim]

The Daniel Martin who follows all the other ones =
(@dtm609) tweeted at 3:23 a.m. on Wed., Jan. 26, 2022:
The grammar seems to allow this I-Regexp:

[^]

(Since a single caret is a =
legal CCE1)

I wonder what the intended =
semantic of that expression is. In PCRE or RE2, that's a syntax error =
but Ecmascript accepts it as a synonym for ".".

I'm not familiar enough with XSD regex to say.
(https://twitter.com/dtm609/status/1486298655497854979?t=3DWEw50=
TO63UIVdN9aWIt4nA&s=3D03) 

-- 
JSONpath mailing list
JSONpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

=

--Apple-Mail=_EFA103A5-CBA8-4C8F-847E-4F7368E92964--


From nobody Wed Jan 26 08:47:46 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375FC3A1741 for ; Wed, 26 Jan 2022 08:47:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfzIEde_nD67 for ; Wed, 26 Jan 2022 08:47:39 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CFF3A16C5 for ; Wed, 26 Jan 2022 08:47:39 -0800 (PST)
Received: from [192.168.217.118] (p5089a6b7.dip0.t-ipconnect.de [80.137.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JkV5307pJzDCfS; Wed, 26 Jan 2022 17:47:34 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 26 Jan 2022 17:47:34 +0100
Cc: Tim Bray , jsonpath@ietf.org
X-Mao-Original-Outgoing-Id: 664908454.614464-baed931c159f74f41311505da1f39d09
Content-Transfer-Encoding: quoted-printable
Message-Id: <243190AA-0C07-4456-AA09-C4CBE33890AB@tzi.org>
References:  
To: Michael Kay 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Jsonpath] Is [^] legal?
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jan 2022 16:47:44 -0000

On 2022-01-26, at 16:49, Michael Kay  wrote:
>=20
> XSD 1.1 part 2 says in =C2=A7G.4.1:
>=20
> Note: For example, the string '[^X]' is ambiguous according the =
grammar rules, denoting either a character class consisting of a =
negative character group with 'X' as a member, or a positive character =
class with 'X' and '^' as members.  The normative prose rule just given =
requires that the first interpretation be taken.
> The string '[^]' is unambiguous: the grammar recognizes it as a =
character class expression containing a positive character group =
containing just the character '^'.  But the grammatical derivation of =
the string violates the rule just given, so the string '[^]' must not be =
accepted as a regular expression.

Indeed.  I tried to reflect the errata in the grammar that is in the =
document.

However, I fell into the trap that my tools are using a =E2=80=9Cprioritiz=
ed choice=E2=80=9D interpretation of ABNF (PEG), so they won=E2=80=99t =
accept [^], because the caret already matches the optional [=E2=80=9C^=E2=80=
=9D] part of the rule.

So the choice to fix this is adding prose like XSD 1.1 did, or actually =
opening up the ABNF to disallow this one case.  (Negative lookahead is a =
feature of PEG for a reason; to bad we don=E2=80=99t have that in ABNF.)

(The alternative interpretation of [^] as =E2=80=9Cnot nothing=E2=80=9D =
is different from =E2=80=9C.=E2=80=9D, by the way, as the latter =
doesn=E2=80=99t match LF/CR/LS/PS.)

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


From nobody Mon Jan 31 01:48:48 2022
Return-Path: 
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0995C3A2A57 for ; Mon, 31 Jan 2022 01:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOj9RghjnYTG for ; Mon, 31 Jan 2022 01:48:41 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 7CC143A2A5D for ; Mon, 31 Jan 2022 01:48:41 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id w25so24737304edt.7 for ; Mon, 31 Jan 2022 01:48:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=XOpu5pcJ9nVhd+menUlFo7hZDYTnqPTzV0sbWD3/5Dc=; b=lF3eOJr16joWme8GcFYZOrZqKULRGhQJkF246eWFzDkI1VSGcBlN8m1CyiCq4jeGMC 5QzgHMlXi2qRKoZEiBrvbBLCVtslnlSToUyDDg4rgqCLDRJ/rydEzDetZt8POgCXH4wv c2Wb/bism5Zy3/5r9SYtQ748ArfyR10Bvw+CRLdTM2vr56WgptLhwXinxBSQGR7CY2DJ 2zriKtLHJuztVZvX8XoGwRewkjgi32H+S0A4VI0qdFzKF6GCpWvZx9jbXzUHGJ8u9Eq+ J/PQniFmhBuIQ+yNfJuIwIrzJgYeN4U9lu1Lt317RsWY9+wsP+YWBDfArzgHsWdKqh54 gZbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=XOpu5pcJ9nVhd+menUlFo7hZDYTnqPTzV0sbWD3/5Dc=; b=zskQScOeanaH9WNTKK/VGndOPqEp92vE1lkObAClZgskgRASimCdwtufZXChNuXcNw ww/Kf7bemLGCTlbhr+3k8dBJ9m1ofwl5lh2+fVcij/waUnH7hw606t51VwN0e+BSiWo6 dQkv1vmzvernHkpuN6RMVmUNOcZVAmR+LaVNbLnET9eKyiaPqg3XL+qKEcs8P6kF82v2 gBJYy77T3Gyb394yAs9HV5GPsvLbHphrFh4i9UTHr/qfu5NmcLNFfTS3EbufwR1ZEGRW HasA+2T4puVlIEuUv0uFs5gKC7ikhIw0tz8egBdtS5hhHPuFiwE5rkL6RSqay+3+dATG WZ/A==
X-Gm-Message-State: AOAM531JR/gHB+9PHIGjT7K5R2jmQgVlC5dbcCTsLBXIUlFR8diG/4Mh URKGim/XLcF4wSipDHdY0r0vloL1VRIPZg==
X-Google-Smtp-Source: ABdhPJz5GcExAJcya2Y/aSslulQZNCEJ3/0J80AxlAVT+SaDOwADwn53TFZHn78eMMeuAJNpsek1vQ==
X-Received: by 2002:a05:6402:26c2:: with SMTP id x2mr12024519edd.354.1643622518019;  Mon, 31 Jan 2022 01:48:38 -0800 (PST)
Received: from smtpclient.apple ([2001:984:65b0:2:34ac:2dc8:2183:bb53]) by smtp.gmail.com with ESMTPSA id ce21sm11905408ejb.7.2022.01.31.01.48.37 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jan 2022 01:48:37 -0800 (PST)
From: James 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Date: Mon, 31 Jan 2022 10:48:37 +0100
References: <25C644CB-9D0A-472B-A2A3-2F8F297D398A@gmail.com>
To: jsonpath@ietf.org
In-Reply-To: <25C644CB-9D0A-472B-A2A3-2F8F297D398A@gmail.com>
Message-Id: <1C8B122D-67F1-4034-AF30-ACDE36DF5F9B@gmail.com>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: 
Subject: Re: [Jsonpath] March 2022 interim meeting pool
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jan 2022 09:48:46 -0000

Folks this is a gentle reminder if you have not yet put your =
availability for the next interim meeting in March to please do so - I =
intend on closing it and making a choice based on the results in the =
coming days.

Thanks

> On 18 Jan 2022, at 21:18, James  wrote:
>=20
> Thank you to everyone who attended our interim meeting today. Minutes =
and actions captured will be sent out in the coming days.
>=20
> As announced by the system earlier, we won't be having a meeting at =
IETF 113 but instead will be having an interim meeting in early March.
>=20
> The poll is here https://doodle.com/poll/g9ag99g4knzc4bdy and we'll =
leave it open until February 1st. If this isn=E2=80=99t feasible for =
you, please let us know and we can discuss or expand the polling.
>=20
> Thanks
>=20
> Tim & James
> JSONPath Chairs