Subject: Re: [calsify] AD review of draft-ietf-calext-valarm-extensions-03

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Jan 2021 14:33:09 -0500

It's been about a month and a half, and I haven't seen any response to
this review.  What's the status, please?

Barry

On Thu, Dec 3, 2020 at 4:15 PM Barry Leiba <[email-masked]> wrote:
>
> Most of my comments are minor, but there are a couple of things to
> discuss (particularly how to handle the ABNF).  I'm going to put this
> in "revised I-D needed", but let's talk about the things that need
> discussion before submitting a revision for the others.
>
> — Section 2 —
> There’s no need for the “[1]” citation, and it only messes up idnits.
> Please remove it and the “URLs” section at the end.
>
> — Section 3 —
>
> My biggest issue here is with the ABNF, so let’s please have a
> discussion about it.
>
> First, some minor things:
>
> 1. This is probably a good time to pay attention to BCP 178 (RFC 6648) by
> removing the x-prop construction (and x-name elsewhere in the draft).
>
> 2. Why is there a need to define new constructs (“alarmcext”,
> “audiopropext”, and so on), rather than just re-defining the base ones
> (“alarmc”, “audioprop”, …)?  It seems to me that this just confuses
> things, and the point here is to make changes that are compatible, but
> more readily extensible.
>
> Now, the big one:
>
> 3. I have never liked the way iCalendar did its ABNF, to the point
> where I think it’s wrong and harmful, causing confusion and not
> permitting automated processing of the ABNF.  It relies on normative
> comments where that’s not necessary, and ABNF was never intended to be
> usef that way.  Comments are meant to be explanatory, and normative
> comments are meant to be used only as a last resort, when you can’t
> express what you need in the formal language.  I would much rather
> limit the comments to a statment that elements can appear in any
> order, and then use the ABNF to convey whether the elements are
> required and how many times they can appear.
>
> Taking “alarmprop” as an example, here’s a re-write of it in the way
> ABNF should be representing it:
>
> OLD
>    alarmprop  = *(
>
>                 ; the following are REQUIRED,
>                 ; but MUST NOT occur more than once
>
>                 action / trigger /
>
>                 ; one set of action properties MUST be
>                 ; present and MUST match the action specified
>                 ; in the ACTION property
>
>                 actionprops /
>
>                 ; the following is OPTIONAL,
>                 ; and MAY occur more than once
>
>                 x-prop / iana-prop
>
>                 )
> NEW
>    alarmprop  = ; the elements herein may appear in any order,
>                 ; and the order is not significant.
>
>                 action
>                 trigger
>
>                 actionprops ; MUST match the action specified
>                             ; in the ACTION property
>
>                 [*iana-prop]
> END
>
> For “audiopropext”:
>
> OLD
>    audiopropext  = *(
>
>                    ; 'duration' and 'repeat' are both OPTIONAL,
>                    ; and MUST NOT occur more than once each,
>                    ; but if one occurs, so MUST the other
>
>                    duration / repeat /
>
>                    ; the following is OPTIONAL,
>                    ; but MUST NOT occur more than once
>
>                    attach
>
>                    )
> NEW
>    audiopropext  = ; the elements herein may appear in any order,
>                    ; and the order is not significant.
>                    [duration repeat]
>                    [attach]
>                    )
> END
>
> Is there really a good reason not to move in this direction?  The
> mechanism of saying that everything can appear zero or more times, and
> then limiting that with comments seems very poor.
>
> — Section 6.1 —
>
>       Certain
>       kinds of alarm may not provide feedback as to when the calendar
>       user sees them, for example email based alerts.
>
> Nit: This sentence isn’t properly ordered (and has a couple of other
> nit-level errors).
>
> NEW
>       Certain
>       kinds of alarms, such as email-based alerts, might not provide
>       feedback as to when the calendar user sees them.
> END
>
> — Section 7 —
>
>    Clients SHOULD add a "RELATED-TO" property to the new "VALARM"
>    component with a value set to the "UID" property value of the
>    "VALARM" component being snoozed.  If the "VALARM" component being
>    snoozed does not already have a "UID" property, the client SHOULD add
>    one.  The "RELATED-TO" property added to the new "VALARM" component
>    SHOULD include a "RELTYPE" property parameter with a value set to
>    "SNOOZE".
>
> Why the SHOULDs?  This is new function; why are these not MUSTs?
>
>    When the "snooze" alarm is triggered and dismissed the client SHOULD
>    remove the corresponding "VALARM" component, or set the
>    "ACKNOWLEDGED" property (see Section 6.1).  Alternatively, if the
>    "snooze" alarm is itself "snoozed", the client SHOULD remove the
>    original "snooze" alarm and create a new one, with the appropriate
>    trigger time and relationship set.
>
> Same here about the SHOULDs.  Also, it’s not clear to me how this
> relates to the original alarm.  It would be good to say, explicitly,
> that the original VALARM is not removed.  But also, is the
> “ACKNOWLEDGED” time on the original alarm changed to show the time
> that the snooze was dismissed?  If not, why not?  And is there a
> reason to choose between the apparently equal alternatives presented
> in the first sentence?  Or is the choice entirely up to the
> implementation?
>
> — Section 7.1 —
>
>    This specification adds the "SNOOZE" relationship type for use with
>    the "RELTYPE" property defined in Section 3.2.15 of [RFC5545].  This
>    is used to relate a "snoozed" "VALARM" component to the original
>    alarm that the "snooze" was generated for.
>
> Maybe I’m being too picky here, but I don’t think the RELTYPE of
> SNOOZE is used to relate the alarms: the UID property is used for
> that.  Maybe “This is used when relating” is better wording?
>
> — Section 8.1 —
>
>       When the property value is set to "ARRIVE", the alarm is triggered
>       when the calendar user agent arrives in the vicinity of any of the
>       specified locations.  When set to "DEPART", the alarm is triggered
>       when the calendar user agent departs from the vicinity of any
>       specified locations.
>
> I think we need to more clearly specify “vicinity” here, even if it’s
> just to say that the definition is up to the implementation.  As it
> is, I don’t know whether I need to depart from my kitchen, from my
> house, from my street, from my town, or whatever.
>
>       When the property value is set to "CONNECT", the alarm is
>       triggered when the calendar user agent connects to a Bluetooth(R)
>       [BTcore]-enabled automobile.  When set to "DISCONNECT", the alarm
>       is triggered when the calendar user agent disconnects from a
>       Bluetooth(R)-enabled automobile.
>
> Nit: It’s odd to have the citation in the middle of the compound
> modifier.  I suggest rewriting to avoid the problem:
>
> NEW
>       When the property value is set to "CONNECT", the alarm is
>       triggered when the calendar user agent connects to an automobile
>       that is enabled for Bluetooth(R) [BTcore].  When set to
>       "DISCONNECT", the alarm is triggered when the calendar user agent
>       disconnects from a Bluetooth(R)-enabled automobile.
> END
>
>    Example:  The following is an example of this property:
>    PROXIMITY:ARRIVE
>
> I think this example is useless, as it’s incomplete without the geo
> location.  And you have Section 8.2 immediately after, so why not just
> remove this?
>
> — Section 11 —
> Throughout this section, please specify the names and/or URIs of the
> registries, to make it easier for both IANA and other readers to find
> them.  For example, in Section 11.1:
>
> NEW
>    This document defines the following new iCalendar properties to be
>    added to the Properties registry defined in Section 8.2.3 of [RFC5545]
>    and located here:
>    <https://www.iana.org/assignments/icalendar#properties>
> END
>
> --
> Barry

---

From: Ken Murchison <[email-masked]>
Date: Fri, 22 Jan 2021 14:34:40 -0500

Hi Barry,

Sorry, its been in my queue.  I will try to get to it shortly.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Jan 2021 15:37:44 -0500

Hi Barry,

Thanks for the review.  I *think* I hit all of your points inline.

> Please remove it and the “URLs” section at the end.

Fixed.

> removing the x-prop construction (and x-name elsewhere in the draft).

I have no problem removing these.  Anyone care to disagree?

> then limiting that with comments seems very poor.

I agree and don't have any good reason to not just redefine existing 
constructs and use the ABNF as proposed above, especially since this is 
what was done in draft-ietf-calext-valarm-extensions.  If there are no 
objections I will go ahead and do this and post a diff.

>        feedback as to when the calendar user sees them.

Fixed.

> Why the SHOULDs?  This is new function; why are these not MUSTs?

I agree, the client is adding a new VALARM component for a specific 
purpose so we should standardize what it looks like.

> in the first sentence?  Or is the choice entirely up to the

I'm leaning towards changing this text to the following:

    When the "snooze" alarm is triggered and dismissed the client MUST do
    one of the following with the corresponding "VALARM" component:

    o  Set the "ACKNOWLEDGED" property (see Section 6.1)

    o  Remove the component

    Alternatively, if the "snooze" alarm is itself "snoozed", the client
    MUST remove the original "snooze" alarm and create a new one, with
    the appropriate trigger time and relationship set.

    Note that regardless of the final disposition of the "snooze" alarm
    when triggered, the original "VALARM" component is left unchanged.

Is this any better?

> that.  Maybe “This is used when relating” is better wording?

Yes, Fixed.

> house, from my street, from my town, or whatever.

Punted this as implementation defined.

>        disconnects from a Bluetooth(R)-enabled automobile.

Fixed.

> location.  And you have Section 8.2 immediately after, so why not just

Removed.

>     <https://www.iana.org/assignments/icalendar#properties>

Added.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Jan 2021 16:09:18 -0500

Thanks, Ken; this all looks good.  I'll wait for a revised I-D and
move forward from there.

Barry

On Thu, Jan 28, 2021 at 3:37 PM Ken Murchison <[email-masked]> wrote:
> I agree and don't have any good reason to not just redefine existing constructs and use the ABNF as proposed above, especially since this is what was done in draft-ietf-calext-valarm-extensions.  If there are no objections I will go ahead and do this and post a diff.
>
>
> — Section 6.1 —
>
>       Certain
> I agree, the client is adding a new VALARM component for a specific purpose so we should standardize what it looks like.
>
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 29 Jan 2021 09:07:39 -0500

Thanks Barry and Ken for the follow-up. I am happy to see the draft being
moved forward.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 11:00:40 -0500

Hi Barry,

>> then limiting that with comments seems very poor.

I started making these changes and then ran into what I think is the 
reason for the "ugly" ABNF.  With the above definition of alarmprop, how 
do we add the new properties defined in the later sections?  We have the 
incremental alternatives syntax in ABNF, but no incremental 
concatenation syntax.  So,

alarmprop =/ [uid]

Is incorrect.  I'd like to be able to do:

alarmprop =+ [uid]

Does the following make sense and is it allowed?

alarmprop = alarmprop [uid]

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 11:04:09 -0500

On 1/29/21 11:00 AM, Ken Murchison wrote:
> reason for the "ugly" ABNF.  With the above definition of alarmprop, 
> how do we add the new properties defined in the later sections?  We 
> have the incremental alternatives syntax in ABNF, but no incremental 

Another alternative is to add the newly defined properties to the 
initial definition of alarmprop with a comment pointing to the relevant 
section in this document.  But that doesn't solve the problem of a 
future spec adding to alarmprop.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Jan 2021 11:13:13 -0500

Hi Ken,

--On Fri, 29 Jan 2021 11:00:40 -0500 Ken Murchison <[email-masked]> 
wrote:

> I started making these changes and then ran into what I think is the reason
> for the "ugly" ABNF.  With the above definition of alarmprop, how do we add
> the new properties defined in the later sections?  We have the incremental
> alternatives syntax in ABNF, but no incremental concatenation syntax.  So,
>
> alarmprop =/ [uid]
>

I recall thinking about how to improve the ABNF in the past and not coming 
up with a feasible solution. My preference is to leave this alone as anyone 
who is familiar with 5545 knows how to cope with the current "awkward" 
syntax. Plus changing it here would mean we should do the same for all 
pending calext drafts.

Whilst I think Barry's proposed changes are a step in the right direction, I 
do not believe they really manage the stated goal of allowing the ABNF to be 
machine parsed because there are still "normative comments" present to deal 
with the fact that ABNF itself does not have an "unordered list of elements" 
construct. Plus ABNF does not have anything to say about the concept of 
"normative comments".

If we want to solve this properly then we should do something similar to 
HTTP (https://tools.ietf.org/html/rfc7230#section-7), and create our own 
ABNF rule for unordered list. That way ABNF parsers can be extended to 
understand the new rule (and not comments) and deal with it. Of course such 
a change should really be done as an update to 5545 and not this spec.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2021 11:15:04 -0500

> future spec adding to alarmprop.

The usual way to do this is, indeed, to put all of the properties
defined in this document into the initial definition... and to add an
extension element to allow other documents to add more, like this:

                action
                trigger
                [uid]
                [*related]
                [acknowledged]
                [proximity [*structured-location] ]

                [*alarmprop-ext]
                [*iana-prop]

   alarmprop-ext = token ; extension point for future additions

-- 
Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2021 11:18:29 -0500

Apart from my response just now, which proposes a way to handle this,
Cyrus might be right that it's not worth doing surgery on the ABNF,
bad though it be.  It's certainly true that anyone who'd been dealing
with 5545 already deals with the mess we have, and the right way to
fix it is in a 5545bis.

On the other hand, I'm torn, because if we *do* update 5545 to deal
with the ABNF, all the extensions that do things the same way will
need to be similarly updated.

In any case, please do as you (collectively) think best here, and I'm
not going to block the document if the consensus is that we should
leave it be for now.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Jan 2021 11:22:12 -0500

Hi Ken,

> I have no problem removing these.  Anyone care to disagree?

Technically this prevents anyone from extending the new items with 
custom/vendor properties etc. So I am not in favor of removing the x- items 
without some other form of vendor items being supported (e.g., I would like 
to see us adopt the same scheme we used for vCard4 with a `VND-<PEN>-` 
prefix: https://www.rfc-editor.org/rfc/rfc6350.html#section-10.2.2). But I 
don't think that is appropriate to do in this spec.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2021 11:34:53 -0500

Sigh.  I guess this is true also.  If we leave the "x-" items in,
let's make sure the shepherd writeup calls out the BCP 178 issue and
explains why we're leaving them here.

Barry

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 11:54:18 -0500

On 1/29/21 11:13 AM, Cyrus Daboo wrote:
> Hi Ken,
>
> --On Fri, 29 Jan 2021 11:00:40 -0500 Ken Murchison 
> <[email-masked]> wrote:
>
>
>> reason
> I recall thinking about how to improve the ABNF in the past and not 
> coming up with a feasible solution. My preference is to leave this 
> alone as anyone who is familiar with 5545 knows how to cope with the 
> current "awkward" syntax. Plus changing it here would mean we should 
> do the same for all pending calext drafts.
>
> Whilst I think Barry's proposed changes are a step in the right 
> direction, I do not believe they really manage the stated goal of 
> allowing the ABNF to be machine parsed because there are still 
> "normative comments" present to deal with the fact that ABNF itself 
> does not have an "unordered list of elements" construct. Plus ABNF 
> does not have anything to say about the concept of "normative comments".
>
> If we want to solve this properly then we should do something similar 
> to HTTP (https://tools.ietf.org/html/rfc7230#section-7), and create 
> our own ABNF rule for unordered list. That way ABNF parsers can be 
> extended to understand the new rule (and not comments) and deal with 
> it. Of course such a change should really be done as an update to 5545 
> and not this spec.

So, I went and took a look at what we have done in the past to extend 
the list of properties for a given component.  E.g., 
https://tools.ietf.org/html/rfc7986#section-4 
<https://tools.ietf.org/html/rfc7986#section-4>

Is what is done there to extend calprops, eventprop, etc technically 
correct?  Doesn't the use of the incremental alternative syntax mean 
that calprops can be the existing calprops OR the newly defined 
properties?  Or have I completely lost my ABNF bearings?

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 12:15:35 -0500

On 1/29/21 11:54 AM, Ken Murchison wrote:
>> it. Of course such a change should really be done as an update to 
>> 5545 and not this spec.
>
>

The problem as I see it is in RFC 5545.  Its defines:

        icalbody   = calprops component

        calprops   = *(
                   ;
                   ; The following are REQUIRED,
                   ; but MUST NOT occur more than once.
                   ;
                   prodid / version /
                   ;
                   ; The following are OPTIONAL,
                   ; but MUST NOT occur more than once.
                   ;
                   calscale / method /
                   ;
                   ; The following are OPTIONAL,
                   ; and MAY occur more than once.
                   ;

                   x-prop / iana-prop
                   ;
                   )

        component  = 1*(eventc / todoc / journalc / freebusyc /
                     timezonec / iana-comp / x-comp)

If this was instead:

        icalbody   = *calprops 1*component

        calprops   =
                   ;
                   ; The following are REQUIRED,
                   ; but MUST NOT occur more than once.
                   ;
                   prodid / version /
                   ;
                   ; The following are OPTIONAL,
                   ; but MUST NOT occur more than once.
                   ;
                   calscale / method /
                   ;
                   ; The following are OPTIONAL,
                   ; and MAY occur more than once.
                   ;

                   x-prop / iana-prop
                   ;

        component  = eventc / todoc / journalc / freebusyc /
                     timezonec / iana-comp / x-comp

Then, something like:

calprops =/ uid / name

component =/ VPOLL

Would do what we want.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Jan 2021 12:18:50 -0500

Hi Ken,

--On Fri, 29 Jan 2021 11:54:18 -0500 Ken Murchison <[email-masked]> 
wrote:

> So, I went and took a look at what we have done in the past to extend the
> list of properties for a given component.  E.g.,
> correct?  Doesn't the use of the incremental alternative syntax mean that
> calprops can be the existing calprops OR the newly defined properties?  Or
> have I completely lost my ABNF bearings?

I don't see in issue there: use of the "=/" ABNF syntax to extend existing 
definitions is fine. All 7986 is doing is adding new properties into 
existing components.

The specific issue for valarm is that the original 5545 definition of 
"alarmc" was not granular enough to allow use of "=/" for extending the 
definitions. Hence the need for the "alarmcext" version of the syntax in the 
new extension which splits things up so there is "alarmprop" for properties 
common to all alarm actions, and "actionprops" which specifies the 
action-speific ones and can be extended with new actions. Ideally this new 
syntax would replace the existing one in any update to 5545.

This also emphasises my earlier point about keeping "x-prop", because the 
new spec is simply providing an alternative way of defining the existing 
5545 syntax, without altering it in any way. Since 5545 has "x-prop", this 
alternative syntax should keep it.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Jan 2021 12:29:32 -0500

Hi Ken,

> Would do what we want.

I don't think there is anything wrong with the existing syntax. I think this 
is correct:

These two:

  a = *(x / y)

  a /= *(z)

are equivalent to:

  a = *(x /y) / *(z)

which is equivalent to:

  a= *(x / y / z)

Admittedly, your alternative syntax is easier to understand in that you 
don't have to think too hard about how all the ABNF operators combine.
 
-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 12:34:28 -0500

On 1/29/21 12:29 PM, Cyrus Daboo wrote:
> Hi Ken,
>
> --On Fri, 29 Jan 2021 12:15:35 -0500 Ken Murchison 
> I don't think there is anything wrong with the existing syntax. I 
> think this is correct:
>
> These two:
>
>  a = *(x / y)
>
>  a /= *(z)
>
> are equivalent to:
>
>  a = *(x /y) / *(z)

I read the above as zero or more 'x' and/or 'y'  OR zero or more 'z'.  I 
don't see how https://tools.ietf.org/html/rfc5234#section-3.2 
<https://tools.ietf.org/html/rfc5234#section-3.2> would allow having 'x' 
and 'z' together.

>
> which is equivalent to:
>
>  a= *(x / y / z)
>
> Admittedly, your alternative syntax is easier to understand in that 
> you don't have to think too hard about how all the ABNF operators 
> combine.
>

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 13:01:39 -0500

On 1/29/21 12:34 PM, Ken Murchison wrote:
> I read the above as zero or more 'x' and/or 'y'  OR zero or more 'z'.  
> I don't see how https://tools.ietf.org/html/rfc5234#section-3.2 
> <https://tools.ietf.org/html/rfc5234#section-3.2> would allow having 
> 'x' and 'z' together.

To continue my thought. Given:

a = *(x /y) / *(z)

*a would equate to: *(x / y / z)

-- 

Kenneth Murchison

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2021 13:02:17 -0500

Ken, I think your interpretation is correct.

One way to handle the various combinations of required "things",
optional-but-once things, and optional-multiple things is something
like this:

   abc = req opt-once *("," opt-mult)

   req = r1 "," r2 "," r3

   opt-once = ["," o1] ["," o2] ["," o3]

   opt-multi = m1 / m2 / m3 / r3

In this case, r3 is required once and can appear multiple times, so
it's in both places.

The problem with that mechanism is that it's hard to extend anything
except opt-multi.  You can do

   opt-multi =/ m4

...but you can't do anything similar with req or opt-once.  And also,
req and opt-once are ordered, which is sad.

I'm chatting with Dave Crocker and some others about whether it makes
sense to extend ABNF to support unordered lists.

Anyway, the more we talk about this, the more convinced I am that
Cyrus is right: we should leave the ABNF alone here, and deal with
properly updating it in an update of the base doc, if we ever get to
that.

Barry

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 13:10:07 -0500

> properly updating it in an update of the base doc, if we ever get to

Agreed that we shouldn't try to reinvent the wheel here, but still I 
think our current use of alarmprop =/ foo in this draft follows previous 
use, but doesn't actually do what we want.

I also think this is an issue in 
https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-18#section-4 
<https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-18#section-4>

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Jan 2021 14:00:37 -0500

Hi Ken,

> *a would equate to: *(x / y / z)

Yeah, OK. I guess I got it wrong in 7986 then :-(

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Jan 2021 14:11:22 -0500

On 1/29/21 2:00 PM, Cyrus Daboo wrote:
> Hi Ken,
>
> --On Fri, 29 Jan 2021 13:01:39 -0500 Ken Murchison 

We all got it wrong, since it passed review without being caught.

Anyhow, attached are my proposed changes per Barry's review and our ABNF 
discussion.

---

From: Michael Douglass <[email-masked]>
Date: Fri, 29 Jan 2021 15:08:46 -0500

One thought that comes to mind is that the abnf is pretty much unusable 
for anything other than descriptive purposes while it's spread across 
multiple documents.

If we want something that's truly usable by software - first it needs to 
cover all the cases - e.g. unordered lists - and we also should have an 
up to date complete abnf maintained as an external artifact - much as 
other bodies provide xml schemas.

It would be interesting to know if it's even possible to build a parser 
that reads abnf and then successfully parses any valid icalendar data

On 1/29/21 14:11, Ken Murchison wrote:
> Anyhow, attached are my proposed changes per Barry's review and our 
> ABNF discussion.
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify