Note: This ballot was opened for revision 05 and is now closed.
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.
Thank you to Valery Smyslov for the SECDIR review. Also thanks for responding to it.
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.
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.
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.
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
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