IETF Logo Mail Archive

Re: [Id-event] Consensus :: Single Event Syntax

Anthony Nadalin <tonynad@microsoft.com> Thu, 14 December 2017 00:03 UTC

Return-Path: <tonynad@microsoft.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AE1243FE for <id-event@ietfa.amsl.com>; Wed, 13 Dec 2017 16:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Level:
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 32p4iS38CMbQ for <id-event@ietfa.amsl.com>; Wed, 13 Dec 2017 16:03:33 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0097.outbound.protection.outlook.com [104.47.33.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE71312025C for <id-event@ietf.org>; Wed, 13 Dec 2017 16:03:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eqMuRkeb13Y/SfBr00gqE3aXWsCXInHSw4gIT/iDQsk=; b=MKbWlmrrm1+4oJgA7OE224eui0RCDJpIsWCtEMCywoBVnKbhI97C4OA/2U0wAbeMxf74PIUTgBuTTF3LIQycPepvZWQotSXIutRSBOMiLL6vnjsU8a0zVGgiMElOr0pYPBawvdgsa89Ig3mk4v8NJAB3fpMKwhZJkEmWY7XwrNY=
Received: from CO2PR00MB0087.namprd00.prod.outlook.com (10.166.215.149) by CO2PR00MB0150.namprd00.prod.outlook.com (10.166.214.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.363.0; Thu, 14 Dec 2017 00:03:29 +0000
Received: from CO2PR00MB0087.namprd00.prod.outlook.com ([fe80::4d99:f257:c61c:e52b]) by CO2PR00MB0087.namprd00.prod.outlook.com ([fe80::4d99:f257:c61c:e52b%4]) with mapi id 15.20.0364.000; Thu, 14 Dec 2017 00:03:29 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: "M.Lizar@OCG" <m.lizar@openconsentgroup.com>, Phil Hunt <phil.hunt@oracle.com>
CC: Yaron Sheffer <yaronf.ietf@gmail.com>, SecEvent <id-event@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [Id-event] Consensus :: Single Event Syntax
Thread-Index: AQHTasSHTGQQHmFqvkydT6DE2fwebKMu0MyAgATbfwCAAAY3gIAOVagg
Date: Thu, 14 Dec 2017 00:03:29 +0000
Message-ID: <CO2PR00MB0087AE819D98710CB01EEDD8A60A0@CO2PR00MB0087.namprd00.prod.outlook.com>
References: <CAD9ie-s_tmCqwBh0u=89Zx7FZEUMq0-TcPY_t-3t006oTrTbmw@mail.gmail.com> <C7C5A5CC-351F-4F65-9977-19508ECF8A65@oracle.com> <3F588BE5-4644-434F-A252-DDA2964715C4@openconsentgroup.com> <C45832CC-C0F9-4FB2-8884-A4D76AC116C4@openconsentgroup.com>
In-Reply-To: <C45832CC-C0F9-4FB2-8884-A4D76AC116C4@openconsentgroup.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-12-14T00:03:26.6577282Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:d::4ef]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR00MB0150; 6:o1SUDBjTfgpCxXV6rcSW/vdOBOEREaBXYcQyQmvzH66mojnmAQac12nL5WLgZRXl9qz+djL8BILmPr6gOnXJVf8EEu4kGyTaLmiJ0U+qRv/gRfYOu9DcN7VrYE12lC2Sg3SlpbkPOd+MIQXWUjmRzWaNyrBKEXpgnU1Od9io+IKQ+6cLrb3wAiH6/TFHX53djQ84Vz6kBCHvlLAnE9NUJp9oA4Fy79W0wuoxruXrh0IQsi9MVV13TFeT8BkVPCUcih3e2HqMvmJxzZd5O7GxsYx8LJrSCs5Z4L9FZMeDp3BipO7yBQuA0xFxrlQZ0YY8D8fYR2vqXxFw9ZSHTn9tDSyVIOSeqCeoEV6iGP/XAXs=; 5:Q3IajdR3zOLnae3gBc/xrXHNHE+tViyTtJfxtXL9Ku6gDktT2hj00+uHsgRjL8LDexYP9aqGymtr0zQtdS/E0lEGbPcjo2aKHvCk497r+zEEnHDD4qbGIk8DmBIdEvQJ2+Pi+X9DimKR8hsmJWEJsABEmQ9ut8rQx0Mkh3Tefp8=; 24:iLT6W/vxzg2aylZ/1y5k3ZXmVVVs3KcuZMhH3VF9Yc+jleO1LF/0JUcoEkuHf0MTDy3l3lSrIgfeXsP5KBE5K+YKrTfLoIHa8tlRYqY+Z1Y=; 7:FJEYxi4uQqfGFVXj48Ccq+Ik/8HhJ52/eJFG5b8xkUL2Tuxh58BYCe2VILEK0cpKDlGUuhi0Are46tBavGC1Trjh5NEqHBAwvaHmdZ14oCyGcGAZv3RiKWAi5B52M62IqXkshphxU6urFnFrbOORKRWF1/Kw0EhA1MjqJV+FqY3oDsaTsWgR4ct6KWMTkSq10quwtGzV+aM4KltKfJ6blWiCAxrymzCAWHHrW8LxDzTZ7UryEKOkZ68qGsj0UD6z
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8cae83cc-53a9-4cc7-c48a-08d542861b4a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:CO2PR00MB0150;
x-ms-traffictypediagnostic: CO2PR00MB0150:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com;
x-microsoft-antispam-prvs: <CO2PR00MB01505CC79F296BDC0CFF88E1A60A0@CO2PR00MB0150.namprd00.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(189930954265078)(100405760836317)(219752817060721)(21748063052155)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3231023)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CO2PR00MB0150; BCL:0; PCL:0; RULEID:(100000803110)(100110400104); SRVR:CO2PR00MB0150;
x-forefront-prvs: 05214FD68E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(366004)(24454002)(199004)(189003)(6246003)(76176011)(3280700002)(33656002)(59450400001)(3660700001)(106356001)(105586002)(561944003)(5660300001)(25786009)(229853002)(39060400002)(53546011)(2900100001)(53936002)(7696005)(99286004)(19609705001)(54896002)(236005)(55016002)(6306002)(9686003)(86362001)(6436002)(8990500004)(4326008)(86612001)(10090500001)(2906002)(6506007)(8676002)(5250100002)(81166006)(81156014)(6116002)(74316002)(102836003)(790700001)(7736002)(68736007)(10290500003)(606006)(478600001)(966005)(8936002)(110136005)(54906003)(14454004)(97736004)(22452003)(316002)(2950100002)(93886005)(61000200001)(42262002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0150; H:CO2PR00MB0087.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR00MB0087AE819D98710CB01EEDD8A60A0CO2PR00MB0087namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cae83cc-53a9-4cc7-c48a-08d542861b4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 00:03:29.1867 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0150
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/vLFsxaiVpOyaU3yTn2OzGeDSoRU>
Subject: Re: [Id-event] Consensus :: Single Event Syntax
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 00:03:37 -0000

I agree that we should stay with the current syntax as it already works for multiple use cases

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of M.Lizar@OCG
Sent: Monday, December 4, 2017 1:08 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>; Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Small typo,  -  should be a  ‘.’ Not a ‘?’

The spec works well for the consent a privacy syntax use cases we are aware of (full stop)

- Mark


On 4 Dec 2017, at 20:46, M.Lizar@OCG<mailto:M.Lizar@OCG> <m.lizar@openconsentgroup.com<mailto:m.lizar@openconsentgroup.com>> wrote:


I concur with Mike and Justin, we had the same issue with primary and secondary in the Consent Receipt spec.

We are also opposed  to making breaking changes at this late date and that the existing working group spec already works well for the consent and privacy use cases we are aware of?

Mark Lizar | CEO Open Consent | Co-Char CISWG at Kantara


On 1 Dec 2017, at 18:35, Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote:

For historical purposes, this has been discussed twice before (once at the request of Annabelle).

I think it would be helpful, why, after WGLC, this issue is being brought forward yet again. Dick has stated that Annabelle’s concern that she finds it difficult to implement is sufficient.  Yet, I’m not sure we are entertaining a new concern here. No new information was provided.

I note that at the time, the chairs did not feel there was a lack of consensus in order to call for one in the past.

On some of these matters, the choice may be arbitrary, and that is why I think keeping track of prior discussion is important so that we can clearly move forward and not repeat discussion of the past further confusing consensus.

While I advocated for singular events as a possibility in the past, I now have much more stronger technical reasons for the WG draft design, which have strengthened rather than weakened in the past week. I will share these later, after the minutes have been published.

On Dec 10, 2016, Yaron while reviewing the ID draft-hunt-idevent-token-07 [1]:

  * Why "events" and not "event"? We don't really have support for

    multiple events. Certainly not if they are all of the same type.

    The current text is confusing: "events" is not the same as "a

    primary event and its extensions”.

[MIKE] Reflects your earlier comment re: primary vs. extensions.  "events” is

plural to reflect the fact that the attribute is multi-valued. I agree,

given that only one primary event can be included, the naming is misleading.

From later in the thread [2]:
 * 2: "first value" is meaningless. JSON objects are unordered (4th
   paragraph of RFC 7159). If order /is/ important, we could make
   "events" into an array.
[Phil] Yup.   How would the group like to fix this?  We could make “events”
singular and have an extensions attribute to hold the extensions.  Or we
could go to a more complex JSON structure (not personally a fan).

[Yaron] I'm personally fine with a main "event" object and an "extensions" attribute. I can even live with "event" being called "events", per Mike's proposal. But the structure needs to make sense as a JSON object if we want it implemented.

[PH] Thread: Should the primary event be a separate attribute?

We had this broken out before. If there is sufficient desire to break it out again, I have no objection.


Then following WG adoption, I re-reraised the issue after discussion with Annabelle draft-secevent-token-00 [3]:
On this topic, following Yaron’s comments Mike Jones raised some points that there should be no distinction between primary events and extensions (https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fid-event%2F0Hhg46ROcidQDLL7OnXUs88TJ9U&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=qfetJaQInRps4jXPio2RVfzx4AXzppo3BdihCLdRVkk%3D&reserved=0>).  Summarizing:
* Processors will run through all of them regardless. It is not necessarily helpful to understand which is a primary vs. extension
* Let’s drop distinction between primary vs. extension. You can simply express one or more sets of event attributes in a single JWT

My proposal is to drop this terminology in the text and keep the attribute multi-valued. The purpose of the attribute is to inform the reader what events are being asserted and what additional data may be present. It is up to the reader to ultimately infer meaning when one or more URIs are present.  Further, when multiple URIs are present it must still to make a combined statement about a single state change about a subject. It must not be used to convey multiple distinct (e.g. transactions) events about a subject.

Assuming everyone agrees, I will plan to remove these distinctions in the next update with some new text. Please comment if you have concerns.

To which Mike Jones responded [4]
I believe we already had consensus to drop the primary/secondary distinction, which we intentionally did before adoption of the working group draft.  I believe any such distinction will both be unhelpful and result in syntactic complexity.  Please let’s finish stamping out the notion that any of the events in a SET are somehow different than the others.

William Denniss wrote [5]:
I agree with your proposal.

They're all just events. Up to implementors to define & categorize their events how they like.

Marius also agreed (he may have switched positions now) [6]:
I also think it makes sense to remove the primary/secondary distinction.

Marius

Justin also agreed (and may have switched positions) [7]
+1, drop "primary" and keep it an object
 -- Justin


References:
[1] - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00298.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=BSy0S%2BlqOF8qYHnHnjO%2FKyy1%2BwvkYMlQGneTKIbyB9M%3D&reserved=0>
[2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00299.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=d5z8kt%2BbLuc9O0een578pjzpMZ9umGEgKGa8mOeayus%3D&reserved=0>
[3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00345.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=HPm9cDNEidi8SUjZIovbkxBp7hn5%2B5FZfkH355OlppM%3D&reserved=0>
[4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00347.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=idGa57mCSH0WX8sDZUKOVp%2FmWfJ51n2BcOWkiuDQ4wA%3D&reserved=0>
[5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00349.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=Plq59tXa36giN0eTuFrbRkLRCiahveoL4qs5btWrnq8%3D&reserved=0>
[6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00365.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=79K6T4qnNYkHbx4B3I9SLaDk6O%2FeNxZ0unZsmAhb40M%3D&reserved=0>
[7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00406.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=MSa6OJZSW1EpCY1HEyzA2aRp7oCId%2FiZjwCWHAPReTc%3D&reserved=0>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.independentid.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=hZKQP647u5eZZLpmDBoq3og0%2Fhy%2BoW926QlSBBB6VZo%3D&reserved=0>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>


On Dec 1, 2017, at 8:50 AM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:

Is it important to syntactically ensure that only one event is in a SET?
For privacy reasons, some use cases want to ensure that only one signal is in a SET.
This adds some additional complexity for use cases that want to include multiple signals in a SET.
See https://tools.ietf.org/html/draft-backman-secevent-token-02<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DP-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=s7IfpAqVt6z5FoTUycG3z01L0yY8f6jwuYoCT8ampu4%3D&reserved=0> for an proposed syntax that ensures one event per SET, and enables multiple events per SET when desired

We will track results here: https://github.com/IETF-SecEvent/Drafts/issues/1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_1%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3D3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=qPXSf7vwwMKCFHYk0LhlU5aKdfIW%2BQMxLI3xYFgFyGU%3D&reserved=0>

Discussion to be on the mail list as usual, not in the issue tracker!

/Dick
_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DYnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=rzMzMvQ%2BHuefu7dLtS5uGTw43A97QWZWibNyo38r%2BLE%3D&reserved=0>

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=YXn2twY6s7R%2BFoO1RiCu6RwLs%2BiiacV5AFT94sXNTx0%3D&reserved=0>

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

v2.23.0 | Report a Bug | By Email