calendars: Make agnostic to scheduling protocol

rfc/src/calendars.xml

@@ -532,7 +532,7 @@ invitation from another calendar system)? This is true if, and only if:</t>
 
 <section anchor="splitting-an-event"><name>Splitting an event</name>
 <t>If the event is not scheduled (has no participants), the simplest thing to do is to duplicate the event, modifying the recurrence rules of the original so it finishes before the split point, and the duplicate so it starts at the split point. As per JSCalendar <xref target="RFC8984" section="4.1.3" />, a "next" and "first" relation MUST be set on the new objects respectively.</t>
-<t>Splitting an event however is problematic in the case of a scheduled event, because the iTIP messages generated make it appear like two unrelated changes, which can be confusing.</t>
+<t>Splitting an event however is problematic in the case of a scheduled event, because the participants will see it as two separate changes, and may not understand the connection between the two.</t>
 </section>
 
 <section anchor="updating-the-base-event-and-overriding-previous"><name>Updating the base event and overriding previous</name>
@@ -580,7 +580,8 @@ invitation from another calendar system)? This is true if, and only if:</t>
 <ul spacing="compact">
 <li><t><strong>sendSchedulingMessages</strong>: <tt>Boolean</tt> (default: false)</t>
 <t>If true then any changes to scheduled events will be sent to all the participants (if the server is the origin of the event) or back to the origin (otherwise). If false, the changes only affect this account and no scheduling messages will be sent.</t>
-<t>At time of writing, the most common interoperable protocol for sending scheduling methods between participants on different servers is iMIP. A future document will provide recommendations of what iMIP messages to send based on the change for best compatibility.</t></li>
+<t>The server may send the scheduling message via any of the methods defined on the sendTo property of a participant (if the server is the origin) or the replyTo property of the event (otherwise) that it supports. If no supported methods are available, the server MUST reject the change with a <tt>noSupportedScheduleMethods</tt> SetError.</t>
+<t>At time of writing, the most common interoperable protocol for sending scheduling methods between participants on different servers is iMIP <xref target="RFC5546" />. A future document will provide recommendations of what iMIP messages to send based on the change for best compatibility.</t></li>
 </ul>
 <t>An id may represent a server-expanded single instance of a recurring event if the client asked the server to expand recurrences in "CalendarEvent/query". When the synthetic id for such an instance is given, the server MUST process an update as an update to the recurrence override for that instance on the base event, and a destroy as removing just that instance.</t>
 <t>Clients MUST NOT send an update/destroy to both the base event and a synthetic instance in a single "/set" request; the result of this is undefined. Note however, a client may replace a series of explicit instances (each with the same uid but a different <tt>recurrenceId</tt> property) with the base event (same uid, no <tt>recurrenceId</tt>) in a single "/set" call. (So the /set will destroy the existing instances and create the new base event.) This will happen when someone is initially invited to a specific instance or instances of a recurring event, then later invited to the whole series.</t>
@@ -596,9 +597,9 @@ omitting/removing the property from the JSCalendar Event object.</t>
 <li><t>uid</t></li>
 <li><t>created</t></li>
 </ul>
-<t>If (and only if) the server is the origin of the event (i.e., the event's "isOrigin" property is true), the "updated" property MUST be set to the current time by the server whenever an event is created or updated. If the client tries to set a value for this property it is not an error, but it MUST be overridden and replaced with the server's time. If the event is being created and the overridden "updated" time is now earlier than a client-supplied "created" time, the "created" time MUST also be overridden to the server's time. If the server is not the origin of the event it MUST NOT automatically set an "updated" time, as this can break correct processing of iTIP messages.</t>
+<t>If (and only if) the server is the origin of the event (i.e., the event's "isOrigin" property is true), the "updated" property MUST be set to the current time by the server whenever an event is created or updated. If the client tries to set a value for this property it is not an error, but it MUST be overridden and replaced with the server's time. If the event is being created and the overridden "updated" time is now earlier than a client-supplied "created" time, the "created" time MUST also be overridden to the server's time. If the server is not the origin of the event it MUST NOT automatically set an "updated" time, as this can break correct processing of scheduling messages.</t>
 <t>Clients SHOULD NOT allow users to manually edit anything other than per-user
-properties when the "isOrigin" property is false, even if the calendar "myRights" allows them to do so. All other properties may be overwritten when a future update arrives to this event from the origin (i.e., via another iTIP REQUEST). Such updates may be directly applied by the server, or applied at the user's request by a client if it has access to the data through some other means (e.g., the client also has access to the user's email and can parse an iMIP message).</t>
+properties when the "isOrigin" property is false, even if the calendar "myRights" allows them to do so. All other properties may be overwritten when a future update arrives to this event from the origin (e.g., via an iTIP REQUEST message). Such updates may be directly applied by the server, or applied at the user's request by a client if it has access to the data through some other means (e.g., the client also has access to the user's email and can parse an iMIP message).</t>
 <t>When updating an event, if all of:</t>
 
 <ul spacing="compact">
@@ -936,9 +937,9 @@ triggered, or <tt>null</tt> if the event is not recurring.</t></li>
 <li><t><strong>email</strong>: <tt>String|null</tt></t>
 <t>The email of the person who made the change, or null if no email is available.</t></li>
 <li><t><strong>principalId</strong>: <tt>Id|null</tt></t>
-<t>The id of the Principal corresponding to the person who made the change, if any. This will be null if the change was due to receving an iTIP message.</t></li>
+<t>The id of the Principal corresponding to the person who made the change, if any. This will be null if the change was due to an entity outside of this user's organisation, e.g. an iTIP invitation from an external person.</t></li>
 <li><t><strong>calendarUserAddress</strong>: <tt>String|null</tt></t>
-<t>The calendarUserAddress URI of the person who made the change, if any. This will normally be set if the change was made due to receving an iTIP message.</t></li>
+<t>The calendarUserAddress URI of the person who made the change, if any. This may be set if the change was made due to receving a scheduling message, such as an iTIP message, in addition to changes made by internal users.</t></li>
 </ul></li>
 <li><t><strong>comment</strong>: <tt>String|null</tt></t>
 <t>Comment sent along with the change by the user that made it. (e.g. COMMENT
@@ -1179,7 +1180,7 @@ data after the update.</t></li>
   }, "0"]
 ]
 </artwork>
-<t>As the event has participants, the server sets a "replyTo" property. This server uses a special email address for receiving iTIP RSVPs rather than just receiving them at the owner's regular email address, and also provides a web page for people that don't have calendar clients supporting iTIP. The response may look something like this:</t>
+<t>As the event has participants, the server sets a "replyTo" property. This server uses a special email address for receiving iMIP RSVPs (<xref target="RFC5546" />) rather than just receiving them at the owner's regular email address, and also provides a web page for people that don't have calendar clients supporting iMIP. The response may look something like this:</t>
 
 <artwork>[
   ["CalendarEvent/set", {
@@ -1426,7 +1427,7 @@ makes no other change):</t>
 <section anchor="spam"><name>Spam</name>
 <t>Invitations received from an untrusted source may be spam. If this is added to the user's calendar automatically it can be very obtrusive, especially if it is a recurring event that now appears every day. Incoming invitations to events should be subject to spam scanning, and suspicious events should not be added to the calendar automatically.</t>
 <t>Servers should strip any alerts on invitations when adding to the user's calendar; the useDefaultAlerts property should be set instead to apply the user's preferences.</t>
-<t>Similarly, a malicious user may use a calendar system to send spam by inviting people to an event. Outbound iTIP should be subject to all the same controls used on outbound email systems, and rate limited as appropriate. A rate limit on the number of distinct recipients as well as overall messages is recommended.</t>
+<t>Similarly, a malicious user may use a calendar system to send spam by inviting people to an event. Outbound scheduling messages should be subject to all the same controls used on outbound email systems, and rate limited as appropriate. A rate limit on the number of distinct recipients as well as overall messages is recommended.</t>
 </section>
 </section>
 
@@ -1587,6 +1588,7 @@ makes no other change):</t>
 <references><name>Informative References</name>
 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4791.xml"/>
 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5546.xml"/>
+<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6047.xml"/>
 </references>
 
 </back>