Skip to main content

"VALARM" Extensions for iCalendar
RFC 9074

Yes

(Barry Leiba)

No Objection

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

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

Alvaro Retana No Objection

Erik Kline No Objection

Murray Kucherawy No Objection

Comment (2021-02-24 for -05)
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.

Robert Wilton No Objection

Comment (2021-02-24 for -05)
Hi,

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.

Thanks,
Rob

Roman Danyliw No Objection

Comment (2021-02-22 for -05)
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)
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)
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.

Regards

-éric

(Barry Leiba; former steering group member) Yes

Yes (for -05)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2021-02-24 for -05)
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.

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2021-03-02 for -06)
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
       following:

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

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

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 steering group member) No Objection

No Objection (for -05)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -05)