Re: [calsify] Working Group Last Call: draft-ietf-calext-valarm-extensions-01

[Daniel Migault <[e-mail]>]

Hi,

I apologize for the very late comments. I hope this helps and I do not
believe this goes beyond nits in any cases.

Yours,
Daniel


                    VALARM Extensions for iCalendar
                 draft-ietf-calext-valarm-extensions-01

1.  Introduction

   The iCalendar [RFC5545] specification defines a set of components
   used to describe calendar data.  One of those is the "VALARM"
   component which appears as a sub-component of "VEVENT" and "VTODO"
   components.  The "VALARM" component is used to specify a reminder for
   an event or task.  Different alarm actions are possible, as are
   different ways to specify how the alarm is triggered.

   As iCalendar has become more widely used and as client-server
   protocols such as CalDAV [RFC4791] have become more popular, several

<mglt>
I guess there is an wording issue. I suppose that " have become more
popular" should be removed.

</mglt>

[ ... ]

3.  Extensible syntax for VALARM

   Section 3.6.6 of [RFC5545] defines the syntax for "VALARM" components
   and properties within them.  However, as written, it is hard to
   extend this by adding, e.g., a new property common to all types of
   alarm.  Since many of the extensions defined in this document need to
   extend the base syntax, an alternative form for the base syntax is
   defined here, with the goal of simplifying specification of the
   extensions.

   A "VALARM" calendar component is re-defined by the following
   notation:

   alarmcext  = "BEGIN" ":" "VALARM" CRLF
                alarmprop
                "END" ":" "VALARM" CRLF

   alarmprop  = *(

                ; the following are REQUIRED,
                ; but MUST NOT occur more than once

                action / trigger /




Daboo & Murchison         Expires July 20, 2020                 [Page 3]

Internet-Draft              VALARM Extensions               January 2020


                ; 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

                )

   actionprops = audiopropext / disppropext / emailpropext

<mglt>
I believe this should go after *ext have been defined, though I am not very
familiar with ABNF.
</mglt>

   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

                   )

   disppropext = *(

                 ; the following are REQUIRED,
                 ; but MUST NOT occur more than once

                 description /

                 ; 'duration' and 'repeat' are both OPTIONAL,
                 ; and MUST NOT occur more than once each,
                 ; but if one occurs, so MUST the other

                 duration / repeat

                 )

   emailpropext = *(

                  ; the following are all REQUIRED,



Daboo & Murchison         Expires July 20, 2020                 [Page 4]

Internet-Draft              VALARM Extensions               January 2020


                  ; but MUST NOT occur more than once

                  description / summary /

                  ; the following is REQUIRED,
                  ; and MAY occur more than once

                  attendee /

                  ; 'duration' and 'repeat' are both OPTIONAL,
                  ; and MUST NOT occur more than once each,
                  ; but if one occurs, so MUST the other

                  duration / repeat

<mglt>
I have the impression that attach is missing as OPTIONAL that MAY appear
more than once.

</mglt>


4.  Alarm Unique Identifier

   This extension adds a "UID" property to "VALARM" components to allow
   a unique identifier to specified.  The value of this property can

<mglt>
to be specified
</mglt>

   then be used to refer uniquely to the "VALARM" component.

[ ... ]


6.  Alarm Acknowledgement

   There is currently no way for a "VALARM" component to indicate
   whether it has been triggered and acknowledged.  With the advent of a
   standard client/server protocol for calendaring and scheduling data
   ([RFC4791]) it is quite possible for an event with an alarm to exist
   on multiple clients in addition to the server.  If each of those is
   responsible for performing the action when an alarm triggers, then
   multiple "alerts" are generated by different devices.  In such a
   situation, a calendar user would like to be able to "dismiss" the
   alarm on one device and have it automatically dismissed on the others
   too.

<mglt>
It is probably due to my lake of expertise, but I have the impression the
acknowledgment properties only works under some conditions. Typically, I
imagine that devices not being connected, are hosting the VALARMS
components locally, in which case, these devices will not consider the
acknowledgment properties.
Similarly, when devices are connected to a centralized calendar, I suppose
- but might completely wrong - that the alarms are simultaneously sent to
the various devices. The ability to switch off all alarms relies on the
ability of these devices to be able to synch the calendar objects. I am
wondering if most systems have a push mechanism to "switch off" the alarms
on the other devices.
</mglt>

[ ... ]

6.1.  Acknowledged Property

   Property Name:  ACKNOWLEDGED

   Purpose:  This property specifies the UTC date and time at which the
      corresponding alarm was last sent or acknowledged.

   Value Type:  DATE-TIME

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property can be specified within "VALARM" calendar
      components.

   Description:  This property is used to specify when an alarm was last
      sent or acknowledged.  This allows clients to determine when a
      pending alarm has been acknowledged by a calendar user so that any
      alerts can be dismissed across multiple devices.  It also allows
      clients to track repeating alarms or alarms on recurring events or
      to-dos to ensure that the right number of missed alarms can be
      tracked.

      Clients SHOULD set this property to the current date-time value in
      UTC when a calendar user acknowledges a pending alarm.  Certain
      kinds of alarm may not provide feedback as to when the calendar
      user sees them, for example email based alerts.  For those kinds
      of alarms, the client SHOULD set this property when the alarm is
      triggered and the action successfully carried out.

      When an alarm is triggered on a client, clients can check to see
      if an "ACKNOWLEDGED" property is present.  If it is, and the value
      of that property is greater than or equal to the computed trigger
      time for the alarm, then the client SHOULD NOT trigger the alarm.

<mglt>
Just for clarification, I assume that the computed trigger time defined by
the TRIGGER property corresponds in the case of a repeated alarm to the
first occurence of the alarm. and the control only apply to the repeated
alarms. More specifically, unless I am missing something, it seems hard to
me to have an ACKNOWLEDGED time before the alarm is triggered for the first
time.

I suspect some checks should be done on the acknowledged time and make sure
the time is not in the future.
</mglt>

[ ... ]

9.  Security Considerations

   VALARMs, if not monitored properly, can be used to "spam" users and/
   or leak personal information.  For instance, an unwanted audio or
   display alert could be considered spam.  Or an email alert could be
   used to leak a user's location to a third party or to send
   unsolicited email to multiple users.  Therefore, CalDAV clients and
   servers that accept iCalendar data from a third party (e.g. via iTIP
   [RFC5546], a subscription feed, or a shared calendar) SHOULD remove
   all VALARMs from the data prior to storing in their calendar system.

<mglt>
As an attacker, I am wondering if I can format also an acknowledgment or
snoozing property to avoid or limit the alarm.
Suppose I am able to provision an acknowledgment property with a time
greater than the computed triggered time. Unless the system controls the
acknowledged time from the client, it seems to me feasible that the
acknowledged time  is set in the future. Even with such control, it could
also disable the repeat properties.

I am also wondering how loosely synchronized devices may interfere between
each other. I do not see major issues as the time is always related to the
time of the event. Loose time synchronization does not seem - but I might
be wrong - the calendar objects, but will impact the time acknowledgment /
snoozing properties are received, if there are any checks.


</mglt>

10.  Privacy Considerations

   Proximity VALARMs, if not used carefully, can leak a user's past,
   present, or future location.  For instance, storing an iCalendar
   resource containing proxmity VALARMs to a shared calendar on CalDAV
   server can expose to anyone that has access to that calendar the
   user's intent to leave from or arrive at a particular location at
   some future time.  Furthermore, if a CalDAV client updates the shared
   iCalendar resource with an ACKNOWLEDGED property when the alarm is
<mglt>
I think that is an additional ACKNOWLEDGED property.

While PROXIMITY gives an exact location, the intention. I am unsure about
the information ACKNOWLEDGE by itself provides (without proximity).
Typically, as far as I understand, it indicates the user has seen the
alarm, but does not give the reason that is whether he is willing to ignore
the alarm or going to the event itself.  Am I missing something ?
</mglt>
   triggered, will leak the exact date and time that the user left from
   or arrived at the location.  Therefore, CalDAV clients that implement
   proximity alarms SHOULD give users the option of storing and/or
   acknowledging the alarms on the local device only and not storing the
   alarm and/or acknowledgment on a remote server.



On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana <[e-mail]>
wrote:

> Obviously, that date came and went and I got sidetracked with other
> things.  I will submit this document and we don't need to put it on the
> agenda for the interim next week!
>
> Cheers,
>
> Bron.
>
> On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote:
>
> As there's been no feedback on the list about this document and Ken
> believes it's complete, we agreed in yesterday's interim meeting to take
> this one to WGLC.
>
> We'll make it 3 weeks, so you have until *Wednesday 13 May *to review and
> respond to this document.
>
> Cheers,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>


-- 
Daniel Migault
Ericsson