Hi Phillip,
Thank you for the review and apologies for the late reply; I have been on leave.
1) Spam2) Duplication3) Time Zones4) Authentication
I have expanded the introduction to the security considerations to mention (4) and added sections for (1)-(3); I include the additions and alterations below. Please let me know if you believe this is insufficient:
7. Security Considerations
Calendaring and scheduling information is very privacy-sensitive.
Its transmission must be done carefully to protect it from possible
threats, such as eavesdropping, replay, message insertion, deletion,
modification, and man-in-the-middle attacks.
The data being stored and transmitted may be used in systems with
real world consequences. For example, a home automation system may
turn an alarm on and off.. Or a coworking space may charge money to
the organiser of an event that books one of their meeting rooms.
Such systems must be careful to authenticate all data they receive to
prevent them from being subverted.
This document just defines the data format; such considerations are
primarily the concern of the API or method of storage and
transmission of such files.
… 7.1-7.3 as before …
7.4. Spam
Calendar systems may receive JSCalendar files from untrusted sources,
in particular as attachments to emails. This can be a vector for an
attacker to inject spam into a user's calendar. This may confuse,
annoy, and mislead users, or overwhelm their calendar with bogus
events, preventing them from seeing legitimate ones.
Heuristic, statistical or machine-learning-based filters can be
effective in filtering out spam. Authentication mechanisms such as
DKIM [RFC6376] can help establish the source of messages and
associate the data with existing relationships (such as an address
book contact). Misclassifications are always possible however, and
providing a feedback mechanism for users to quickly correct this is
advised.
7.5. Duplication
It is important for calendar systems to maintain the UID of an event
when updating it to avoid unexpected duplication of events. When the
UID changes, consumers of the data may not remove the previous
version of the event if it has a different UID. This can lead to a
confusing situation for the user, with many variations of the event
and no indication of which one is correct. Care must be taken by
consumers of the data to remove old events where possible to avoid an
accidental denial-of-service attack due to the volume of data.
7.6. Time Zones
Events recur in a particular time zone. When this differs from the
user's current time zone, it may unexpectedly cause an occurrence to
shift in time for that user due to a daylight savings change in the
event's time zone. A maliciously crafted event could attempt to
confuse users with such an event to ensure a meeting is missed.
In the general body of the text, the treatment of recurring events MUST addresstime zones and daylight savings. This is the stuff iCal didn't get right atfirst and that lead to pain.
Can you clarify a bit what change you are looking for here, if any? Do you believe the current text in JSCalendar is ambiguous? A recurrence applies to the "start" property of the event, which is a local date-time. All other properties (including "timeZone") are inherited unless overridden for a specific instance. So an event will essentially recur in its time zone; if you need to translate this into UTC you'll of course need time zone information and to account for daylight savings etc.
Cheers,
Neil.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
