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

On Fri, Dec 15, 2017 at 9:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

> The related syntax is needlessly complex and if this mysterious ambiguity
> exists, the alt draft does nothing to address it.
>
> The example Annabelle gave isn't even a valid example. We are proposing a
> major format change for a non-existent problem.
>

Phil, this hard core black and white attitude makes it very hard to have a
dialog. Can you make an effort and find some value in the alt proposal?

>
> Mike has commented extensively how jwt has similar practice. If the
> ambiguity problem existed JWT would be a failure.
>

Not sure what your point is regarding JWT and how that is relevant.

>
> How much hard fact do we need Marius?
>

You have provided none in this message, only strong statements.

Again, let's find a way to have a real dialog and to respect each other.

>
> Phil
>
> On Dec 15, 2017, at 8:50 AM, Marius Scurtescu <mscurtescu@google.com>
> wrote:
>
> Simpler? Yes.
>
> Working? For some use cases, yes.
>
> Mike, it would be useful if you actually spelled out the reasons why we
> should hold on to it. Two minor reasons are above, what are the great ones?
>
> Also, if you disagree with the reasons presented for the new syntax, it
> would be constructive to hear why.
>
> Marius
>
> On Fri, Dec 15, 2017 at 8:12 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
>> The current syntax is demonstrably working and substantially simpler than
>> the proposed alternative.  Those are great reasons to hold onto it.
>>
>>
>>
>> *From:* Justin Richer [mailto:jricher@mit.edu]
>> *Sent:* Friday, December 15, 2017 7:09 AM
>> *To:* Marius Scurtescu <mscurtescu@google.com>
>> *Cc:* Richard Backman, Annabelle <richanna@amazon.com>; Phil Hunt <
>> phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com>;
>> Benjamin Kaduk <bkaduk@akamai.com>; id-event@ietf.org
>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> +1 to Annabelle and Marius. The current syntax is demonstrably broken for
>> the purposes that people are claiming it’s needed for. Why are we hanging
>> on to it?
>>
>>
>>
>> On Dec 14, 2017, at 6:22 PM, Marius Scurtescu <mscurtescu@google.com>
>> wrote:
>>
>>
>>
>> On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>>
>> You can’t conceive of any combination of event statements that could be
>> ambiguous?
>>
>>
>>
>> Here’s one possible example:
>>
>> {
>>
>> // ...other SET claims...
>>
>>  "events": {
>>
>>     "account_updated": { },
>>
>>    "shipping_address_added": { /* ... */ },
>>
>>     "billing_address_added": { /* ... */ },
>>
>>     "address_verified": { "is_verified": true }
>>
>>  }
>>
>> }
>>
>>
>>
>> Does the “address_verified” event statement apply to the shipping address
>> or the billing address? Or both? How would the transmitter indicate that
>> one is verified but the other isn’t?
>>
>>
>>
>> The current draft’s syntax allows for implementers to fall into traps
>> like this. Leaving this as a problem for profiling specifications to solve
>> means giving up on general interoperability between SET profiles.
>>
>>
>>
>> +1
>>
>>
>>
>> To add to that, we can go back to the original reasons why multiple
>> events are needed. At IIW we looked at this and we came up with:
>>
>> - extensions
>>
>> - aliases
>>
>> - convenience packaging of related events
>>
>>
>>
>> The current format does not provide any means to convey the above. That
>> is ambiguity.
>>
>>
>>
>> Phil, you are well aware of this, you acknowledged this at the IIW
>> meetings. You could argue that the ambiguity is not important in your
>> opinion, but saying that you do not see any ambiguity is very surprising.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Phil Hunt <phil.hunt@oracle.com>
>> *Date: *Thursday, December 14, 2017 at 1:14 PM
>> *To: *"Richard Backman, Annabelle" <richanna@amazon.com>
>> *Cc: *Mike Jones <Michael.Jones@microsoft.com>, Benjamin Kaduk <
>> bkaduk@akamai.com>, "id-event@ietf.org" <id-event@ietf.org>, Justin
>> Richer <jricher@mit.edu>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> I don't see any ambiguity.
>>
>> Phil
>>
>>
>> On Dec 14, 2017, at 12:37 PM, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>>
>> RFC 7519 is very clear about the semantics of the claims that it defines.
>> Where do you see a degree of ambiguity similar to what exists for the
>> “events” claim in the current draft?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Date: *Thursday, December 14, 2017 at 11:04 AM
>> *To: *Phil Hunt <phil.hunt@oracle.com>, "Richard Backman, Annabelle" <
>> richanna@amazon.com>
>> *Cc: *Benjamin Kaduk <bkaduk@akamai.com>, "id-event@ietf.org" <
>> id-event@ietf.org>, Justin Richer <jricher@mit.edu>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> By your logic, JWT should be even worse of an "interoperability
>> disaster", but that doesn't seem to be the case in practice.
>>
>> From: Richard Backman, Annabelle
>>
>> Sent: Thursday, December 14, 10:49 AM
>>
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>>
>> To: Phil Hunt, Mike Jones
>>
>> Cc: Benjamin Kaduk, Justin Richer, id-event@ietf.org
>>
>> Mike,
>>
>>
>>
>> What do you mean by “application”? A profiling specification? A
>> transmitter using a particular profiling specification? A
>> transmitter/receiver pair using a profiling application? Something else?
>>
>>
>>
>> I’m not sure why you and Phil are bringing up single vs. multi-aspect in
>> your responses – the point I’m making is that while you claim the current
>> draft supports multi-aspect SETs, its syntax implies limitations on that
>> support that have not been acknowledged:
>>
>> By using a JSON object as a map with event types as keys, it prohibits
>> transmitters from including two instances of the same event type in a
>> single SET. This reduces the scope of the events claim from “aspects of a
>> single logical event” to “singleton aspects of a single logical event.”By
>> placing all event statements in a single layer without hierarchy or any
>> other indicator of relationships, the syntax requires that receivers be
>> able to infer the correct relationships between event statements.
>> Consequently, either event statements have to be entirely independent of
>> one another, define their own mechanism for disambiguation, or transmitters
>> have to take special care to not produce SETs with ambiguous combinations
>> of event statements.
>>
>>
>>
>> It’s easy to dismiss interpretation of the events claim as up to the
>> profile/receiver/”application”/etc., but if we do not actually think
>> through how profiles might use the claim, and how someone would implement
>> code to interpret the claim, then we’re setting ourselves up for an
>> interoperability disaster.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Id-event <id-event-bounces@ietf.org> on behalf of Phil Hunt <
>> phil.hunt@oracle.com>
>>
>> *Date: *Thursday, December 14, 2017 at 9:32 AM
>>
>> *To: *Mike Jones <Michael.Jones@microsoft.com>
>>
>> *Cc: *Benjamin Kaduk <bkaduk@akamai.com>, "Richard Backman, Annabelle" <
>> richanna@amazon.com>, Justin Richer <jricher@mit.edu>, "id-event@ietf.org"
>> <id-event@ietf.org>
>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> +1
>>
>> Phil
>>
>> On Dec 14, 2017, at 8:33 AM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>>
>> I agree with Phil.  If an application uses multi-aspect SETs, it would be
>> unsurprising for them to generate or receive them.  In other applications,
>> single-aspect SETS can be specified, and in fact unexpected multi-aspect
>> SETs received can be rejected if appropriate for the application.  Both are
>> possible – by design.  Both of Annabelle’s proposed statements seem to be
>> intruding into application and profile design.  The core SET spec shouldn’t
>> take a position on them either way (just like the core JWT spec allows any
>> claims to be used by applications).
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Id-event [mailto:id-event-bounces@ietf.org
>> <id-event-bounces@ietf.org>] *On Behalf Of *Benjamin Kaduk
>>
>> *Sent:* Thursday, December 14, 2017 7:50 AM
>>
>> *To:* Phil Hunt <phil.hunt@oracle.com>; Richard Backman, Annabelle <
>> richanna@amazon.com>
>>
>> *Cc:* id-event@ietf.org; Justin Richer <jricher@mit.edu>
>>
>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> Sure, they're not your assertions; they're Annabelle's assertions.  But
>> the question at hand is whether you believe or disbelieve that the
>> assertions are true of the current draft (and, if so, whether they should
>> move from implicit to explicit assumptions).
>>
>> It sounds like you are saying that you do not believe the two assertions
>> are true of the current draft, but could you please be explicit about your
>> personal beliefs (as opposed to Mike's)?
>>
>> Thanks,
>>
>> Ben
>>
>> On 12/13/2017 08:39 PM, Phil Hunt wrote:
>>
>> Those aren’t my assertions.
>>
>>
>>
>> The draft is written based on group input. So no, not everything is
>> backed directly by case. It is backed by consensus.
>>
>>
>>
>> Mike’s comments that just like JWT’s can have different content per
>> audience, so can a stream of SET per receiver.  So single event only SETs
>> and multi-aspect SETs are possible.
>>
>>
>>
>> If the receiver wants multi-aspect SETs, I doubt they would find them
>> ambiguous.
>>
>>
>>
>> Phil
>>
>>
>>
>> Oracle Corporation, Identity Cloud Services Architect
>>
>> @independentid
>>
>> www.independentid.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=85cyhAYmmz380nKWOgwzhl0dZmKMtiFnEEge6fiK1rA&s=iccVyyTJcw_ZwESlqJw6m2HkrrnU0xd4xZjIbfavofA&e=>
>>
>> phil.hunt@oracle.com
>>
>>
>> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>>
>>
>>
>> The ones in my previous email (quoted below):
>>
>>
>>
>> The current syntax doesn’t even work for the professed use case, without
>> two unstated constraints:
>>
>> 1.       Two instances of a single type of event statement cannot be
>> related to the same logical event.
>>
>> 2.       The combination of event statements cannot be ambiguous.
>>
>>
>>
>> If the current draft intends to impose these limits, they need to be
>> stated in the text. But more importantly, what is the basis for imposing
>> these limitations on SET in the first place?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Phil Hunt <phil.hunt@oracle.com>
>>
>> *Date: *Wednesday, December 13, 2017 at 5:53 PM
>>
>> *To: *"Richard Backman, Annabelle" <richanna@amazon.com>
>>
>> *Cc: *Justin Richer <jricher@mit.edu>, "id-event@ietf.org" <
>> id-event@ietf.org>
>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> What restrictions are you referring to?
>>
>>
>>
>> Phil
>>
>>
>>
>> Oracle Corporation, Identity Cloud Services Architect
>>
>> @independentid
>>
>> www.independentid.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=HKiKUZgXDLuGHjfG_wYgXCVNOctJXueCEh63hvF_ixc&s=nvU8oqF7Izoh-0sBdFy3FOwGW-pNlwpynSj4aet5atE&e=>
>>
>> phil.hunt@oracle.com
>>
>>
>>
>> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>>
>>
>>
>> Phil,
>>
>>
>>
>> As the author of the current draft, can you clarify whether these
>> restrictions are intentional, and if so why the use cases for SET are being
>> restricted in this way?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *"Richard Backman, Annabelle" <richanna@amazon.com>
>>
>> *Date: *Monday, December 11, 2017 at 10:09 AM
>>
>> *To: *Justin Richer <jricher@mit.edu>, "id-event@ietf.org" <
>> id-event@ietf.org>
>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> The current syntax doesn’t even work for the professed use case, without
>> two unstated constraints:
>>
>> Two instances of a single type of event statement cannot be related to
>> the same logical event. The combination of event statements cannot be
>> ambiguous.
>>
>>
>>
>> If the current draft intends to impose these limits, they need to be
>> stated in the text. But more importantly, what is the basis for imposing
>> these limitations on SET in the first place?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Id-event <id-event-bounces@ietf.org> on behalf of Justin Richer <
>> jricher@mit.edu>
>>
>> *Date: *Saturday, December 9, 2017 at 6:04 AM
>>
>> *To: *"id-event@ietf.org" <id-event@ietf.org>
>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> So the current syntax doesn't work for Tony's stated use case of even
>> bundles while the new syntax does, then.
>>
>>
>>
>> On 12/5/2017 5:50 PM, Mike Jones wrote:
>>
>> The “events” claim definition is already clear that the “events” values
>> convey multiple aspects of a single logical event - not independent
>> events.  Section 2.1 (Core Set Claims) says:
>>
>>    events
>>
>>       The semantics of this claim is to define a set of event statements
>>
>>       that each MAY add additional claims to fully describe a single
>>
>>       logical event that has occurred (e.g. a state change to a
>>
>>       subject). … The "events" claim SHOULD NOT be used to express
>>
>>       multiple logical events.
>>
>>
>>
>> You’re describing a theoretical problem that’s not actually present in
>> the working group spec.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Richard Backman, Annabelle [mailto:richanna@amazon.com
>> <richanna@amazon.com>]
>>
>> *Sent:* Tuesday, December 5, 2017 2:06 PM
>>
>> *To:* Mike Jones <Michael.Jones@microsoft.com>
>> <Michael.Jones@microsoft.com>; Phil Hunt <phil.hunt@oracle.com>
>> <phil.hunt@oracle.com>
>>
>> *Cc:* William Denniss <wdenniss@google.com> <wdenniss@google.com>;
>> M.Lizar@OCG <m.lizar@openconsentgroup.com> <m.lizar@openconsentgroup.com>;
>> Yaron Sheffer <yaronf.ietf@gmail.com> <yaronf.ietf@gmail.com>; Dick
>> Hardt <dick.hardt@gmail.com> <dick.hardt@gmail.com>; SecEvent
>> <id-event@ietf.org> <id-event@ietf.org>
>>
>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> Once again, I am not talking about the meaning of a given event type or
>> its contents. I’m talking about the meaning of putting an event in an
>> “events” claim alongside another event in the same SET.
>>
>>
>>
>> Drawing an analogy to programming, I’m talking about defining what the
>> syntax “function_x() && function_y()” means. Regardless of what
>> “function_x” and “function_y” mean, the language defines the meaning of
>> that syntax as “true if the result of function_x is true and the result of
>> function_y is true.”
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Mike Jones <Michael.Jones@microsoft.com>
>>
>> *Date: *Tuesday, December 5, 2017 at 1:30 PM
>>
>> *To: *Phil Hunt <phil.hunt@oracle.com>, "Richard Backman, Annabelle" <
>> richanna@amazon.com>
>>
>> *Cc: *William Denniss <wdenniss@google.com>, "M.Lizar@OCG" <
>> m.lizar@openconsentgroup.com>, Yaron Sheffer <yaronf.ietf@gmail.com>,
>> Dick Hardt <dick.hardt@gmail.com>, SecEvent <id-event@ietf.org>
>>
>> *Subject: *RE: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> Hi Annabelle,
>>
>>
>>
>> The data contained in a SET and the semantics of that data will **always**
>> be profile-specific.  That’s a feature – not a bug.  It’s what makes SETs
>> general-purpose, rather than being suited only for a narrow set of use
>> cases.
>>
>>
>>
>> An analogy with JWTs is applicable.  JWTs have no required claims, so
>> their usage is always profile-specific.  That has enabled them to be
>> adopted by numerous diverse applications.  SETs currently have that same
>> level of flexibility – by design.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Phil Hunt [mailto:phil.hunt@oracle.com <phil.hunt@oracle.com>]
>>
>> *Sent:* Tuesday, December 5, 2017 1:22 PM
>>
>> *To:* Richard Backman, Annabelle <richanna@amazon.com>
>>
>> *Cc:* Mike Jones <Michael.Jones@microsoft.com>; William Denniss <
>> wdenniss@google.com>; M.Lizar@OCG <m.lizar@openconsentgroup.com>; Yaron
>> Sheffer <yaronf.ietf@gmail.com>; Dick Hardt <dick.hardt@gmail.com>;
>> SecEvent <id-event@ietf.org>
>>
>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> I would disagree strongly with the notion of inter-operability
>> requirements on expected outcomes or actions by receivers.
>>
>>
>>
>> SETs are statements of changes in state of security objects by
>> transmitters. SETs do not indicate any specific actions that should be
>> taken by receivers.
>>
>>
>>
>> I believe I’ve covered this issue during the informal BOF (at the SCIM WG
>> meeting Argentina) and several times during IETF WG meeting presentations.
>> I did so, because within the IETF community many people have vastly
>> different notions of what an event is.
>>
>>
>>
>> Phil
>>
>>
>>
>> Oracle Corporation, Identity Cloud Services Architect
>>
>> @independentid
>>
>> www.independentid.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=tqqw1ywr-k_fQTVlTIQ-V24SRkRzlh5clMJQKLMLANw&e=>
>>
>> phil.hunt@oracle.com
>>
>>
>>
>>
>>
>>
>> On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>>
>>
>>
>> Mike,
>>
>>
>>
>> This isn’t simply an issue of “single vs multiple” – the current draft is
>> fundamentally broken from an interoperability standpoint, because the
>> correct interpretation of the “events” claim is at best profile-specific,
>> at worst implementation-specific.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Mike Jones <Michael.Jones@microsoft.com>
>>
>> *Date: *Tuesday, December 5, 2017 at 12:22 PM
>>
>> *To: *"Richard Backman, Annabelle" <richanna@amazon.com>, William
>> Denniss <wdenniss@google.com>, "M.Lizar@OCG" <
>> m.lizar@openconsentgroup.com>
>>
>> *Cc: *Yaron Sheffer <yaronf.ietf@gmail.com>, Phil Hunt <
>> phil.hunt@oracle.com>, SecEvent <id-event@ietf.org>, Dick Hardt <
>> dick.hardt@gmail.com>
>>
>> *Subject: *RE: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> Morteza already pointed out
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=ZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA&e=> a
>> simple solution to enabling SETs to contain only a single event description
>> for profiles that want that – a solution proposed by Yaron
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=tac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg&e=> that
>> doesn’t involve making any breaking changes:  Explicitly specify that
>> profiles can restrict the number of elements in the “events” data structure
>> – including limiting them to one element, when desired.  Then profiles that
>> want this can have it and profiles that need to enable multiple aspects of
>> an event to be easily represented can have that too.  Hopefully people can
>> rally around that straightforward solution, enabling us to move on and
>> finish the SET spec in as timely a fashion as possible.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Id-event [mailto:id-event-bounces@ietf.org
>> <id-event-bounces@ietf.org>] *On Behalf Of *Richard Backman, Annabelle
>>
>> *Sent:* Tuesday, December 5, 2017 11:40 AM
>>
>> *To:* William Denniss <wdenniss@google.com>; M.Lizar@OCG <
>> m.lizar@openconsentgroup.com>
>>
>> *Cc:* Yaron Sheffer <yaronf.ietf@gmail.com>; Phil Hunt <
>> phil.hunt@oracle.com>; SecEvent <id-event@ietf.org>; Dick Hardt <
>> dick.hardt@gmail.com>
>>
>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> William’s email analogy demonstrates the problem with the current syntax:
>> imagine if the text part of a multi-part email could be any of the
>> following, with no explicit indication which one it is:
>>
>> A plaintext representation of the same content in the HTML part.  The CSS
>> to use when rendering the HTML part.  Annotations on the contents of the
>> HTML part.  A vCard for the sender of the message.  A completely separate
>> message with a separate subject line embedded in the text.
>>
>>
>>
>> How would a mail reader know what to do with this? It couldn’t, not in
>> any scalable way. Yet is exactly the situation we will have, given the
>> current draft and the way people are proposing using its multi-part
>> capability:
>>
>> William wants to use it to send different independent representations of
>> the same event. Phil wants to use it to send different aspects of the same
>> event, intended to be processed together. Tony wants to use it for
>> directory synchronization.  Marius wants to use it to send the same event
>> under both standard and deprecated names. et cetera, et cetera…
>>
>>
>>
>> This confusion is going to limit reusability and interoperability, and
>> hinder adoption. If the WG consensus is that all these use cases are in
>> scope for SET, that’s fine, we can support them – but we need to do so in a
>> way that doesn’t create complete chaos.
>>
>>
>>
>> At risk of repeating myself, maybe we need to have a consensus discussion
>> on which multi-part use cases are in scope for SET before we continue with
>> this discussion?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> Amazon – Identity Services
>>
>>
>>
>>
>>
>> *From: *Id-event <id-event-bounces@ietf.org> on behalf of William
>> Denniss <wdenniss@google.com>
>>
>> *Date: *Monday, December 4, 2017 at 7:20 PM
>>
>> *To: *"M.Lizar@OCG" <m.lizar@openconsentgroup.com>
>>
>> *Cc: *Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt <
>> dick.hardt@gmail.com>, SecEvent <id-event@ietf.org>, Phil Hunt <
>> phil.hunt@oracle.com>
>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>
>>
>>
>> I would prefer to keep the format in the current working group draft.
>>
>> Based on the requirement that events may be represented in multiple ways,
>> I believe having both formats carried in a single SET is superior as it
>> avoids complex linking logic. The best analogy I can think of is email,
>> where MIME allows for text and html versions *of the same content* to be
>> carried in a single email (much like how SET allows for multiple
>> representations *of the same event* in a SET). With email, the recipient's
>> client is then able to display the version it prefers from those available.
>> Imagine the additional logic if every email was sent twice – e.g. what if
>> the plain text version arrives, the HTML one is delayed? How should the
>> client react if the HTML version arrives later, would it replace the
>> version it had? What if you were already viewing and/or replying?
>>
>> Time-wise I'm really concerned if we don't lock this down soon, the
>> people who are waiting on us to profile SET will walk away and do their own
>> thing (I was worried about that a year ago… and I think we've waited long
>> enough). I think we should keep this in mind and choose the path that will
>> have the fastest resolution.  If the decision was to change the format at
>> this late stage, I would like to hear what steps can be done to avoid
>> additional delay.
>>
>> I really respect the work Annabelle has done in leading the alternative
>> representation, and I do think it’s a viable alternative. If we choose to
>> change the spec and go with the singular option, then I think the
>> requirement of multiple representations should be dropped, or at a minimum
>> de-emphasized as this (along with expediency) is the main reason I believe
>> the existing format is better.
>>
>>
>>
>>
>>
>> On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG <m.lizar@openconsentgroup.com>
>> wrote:
>>
>> 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 <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> 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/0Hhg46ROcidQ
>> DLL7OnXUs88TJ9U
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ&e=>).
>> 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/msg
>> 00298.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=rG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8&e=>
>>
>> [2] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00299.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=wE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA&e=>
>>
>> [3] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00345.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=QEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8&e=>
>>
>> [4] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00347.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=IcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c&e=>
>>
>> [5] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00349.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=d0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE&e=>
>>
>> [6] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00365.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ&e=>
>>
>> [7] - https://www.ietf.org/mail-archive/web/id-event/current/msg
>> 00406.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=k5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc&e=>
>>
>>
>>
>> Phil
>>
>>
>>
>> Oracle Corporation, Identity Cloud Services Architect
>>
>> @independentid
>>
>> www.independentid.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=zQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk&e=>
>>
>> phil.hunt@oracle.com
>>
>>
>>
>> On Dec 1, 2017, at 8:50 AM, Dick Hardt <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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=P-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM&e=> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw&e=>
>>
>>
>>
>> Discussion to be on the mail list as usual, not in the issue tracker!
>>
>>
>>
>> /Dick
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzw
>> Y&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e=
>>
>>
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>
>>
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>
>>
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>
>>
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcE
>> k&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________ Id-event mailing list
>> Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Id-event mailing list
>>
>> Id-event@ietf.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0A
>> Q&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________ Id-event mailing list
>> Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=>
>>
>>
>>
>
> _______________________________________________
> Id-event mailing list
> 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=
> kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-
> BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=
>
>