Skip to main content

"VALARM" Extensions for iCalendar


(Barry Leiba)

No Objection

Erik Kline
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)

Note: This ballot was opened for revision 05 and is now closed.

Erik Kline
No Objection
Murray Kucherawy
No Objection
Comment (2021-02-24 for -05) Sent for earlier
This document appears to enable (or continue) support for the notion of extension properties prefixed by "X-" (via the "x-prop" ABNF token).  That seems contrary to BCP 178.  I realize this is just continuing in what was done in RFC 5545, but should it be dropped here?

Other than this one concern, this is really well written.  Nice work.
Roman Danyliw
No Objection
Comment (2021-02-22 for -05) Not sent
Thank you to Valery Smyslov for the SECDIR review.  Also thanks for responding to it.
Warren Kumari
No Objection
Comment (2021-02-24 for -05) Sent
Please note: I am not an iCal person (probably as demonstrated by the fact that I call it ical), and parsing an icalendar file fills me with dread -- but even I found this document clear, readable, understandable, and solving a set of problems that I understand. 
Thank you for such a good read.
Éric Vyncke
No Objection
Comment (2021-02-22 for -05) Sent
Thank you for this document, it is easy to read and the "snooze" and "ack" extensions will be indeed useful.

During my IESG review, I found nothing worth mentioning.


Barry Leiba Former IESG member
Yes (for -05) Unknown

Alissa Cooper Former IESG member
No Objection
No Objection (2021-02-24 for -05) Sent
Section 8.2 uses the term "precision," but precision and uncertainty are not the same thing and should not be confused. See RFC 7459. Please use the term "uncertainty" here instead.
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Not sent

Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-03-02 for -06) Sent for earlier
Thanks for responding to my previous question to clarify that the intent
is to provide an equivalent form for the alarm ABNF to what is in RFC
5545.  (I personally am not prepared to assert that it definitely is/was
equivalent, since I only looked closely enough to ascertain that it is
at least very similar.  I would prefer if we had some independent
verification of that, but I don't even know what form that verification
would take, so I can hardly insist upon it.)

That said, in making the changes to adapt to VLOCATION, we had to add
the "alarm-subcomp" production that includes x-comp / iana-comp, and
it's pretty hard for me to claim that with alarm-subcomp in place, the
ABNF remains "equivalent" to the RFC 5545 form.  So maybe we have to
revisit that claim, or leave the initial alarm-subcomp as an empty
production and make some additional explicit extension where we allow
subcomponents, or something.

Section 7

   3.  When the "snooze" alarm is triggered, the client MUST do the

       A.  Reset the "ACKNOWLEDGED" property on the original related

(nit) I think that "clear" or "remove" would probably be more clear than

Section 7.2

Should the DTSTAMP of the VEVENT change when the snooze events occur?

Also, IIUC, the ACKNOWLEDGED time for the primary alarm
(8297C37D-BA2D-4476-91AE-C1EAA364F8E1) should be something after
20210302T152000Z after the second snooze event.  (It currently shows as the
same 20210302T151514Z from after the first snooze.)

It's also a little surprising that the final acknowledgment occurs after the
meeting starts, some 6 minutes after the alarm triggered, but that's not
actually a protocol error, so it's technically okay.

Section 8

      "PROXIMITY" property - indicates that a location based trigger is
      to be used and which direction of motion is used for the trigger

It looks like we got rid of the "direction of motion" reference later on
(where I had actually commented on it), but this one should go as well.
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Not sent

Martin Vigoureux Former IESG member
No Objection
No Objection (for -05) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (2021-02-24 for -05) Sent

I was pleased to see the comments about security/privacy for UUIDs in section 4, but I wonder whether it would be helpful for chapters 9 and/or 10 to have a back reference to the UUID security/privacy considerations.