draft-ietf-extra-sieve-processimip.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std" consensus="yes" ipr="trust200902"
     docName="draft-ietf-extra-processimip-09"
     obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.2 -->
  <front>
    <title abbrev="Sieve Process iMIP">Sieve Email Filtering:
    Extension for Processing Calendar Attachments</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-extra-processimip-09"/>
    <author initials="K." surname="Murchison" fullname="Kenneth Murchison">
      <organization abbrev="Fastmail">Fastmail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut Street - Suite 1201</street>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19102</code>
          <country>USA</country>
        </postal>
        <email>murch@fastmailteam.com</email>
      </address>
    </author>

    <author initials="R." surname="Signes" fullname="Ricardo Signes">
      <organization abbrev="Fastmail">Fastmail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut Street - Suite 1201</street>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19102</code>
          <country>USA</country>
        </postal>
        <email>rjbs@fastmailteam.com</email>
      </address>
    </author>

    <author initials="M." surname="Horsfall" fullname="Matthew Horsfall">
      <organization abbrev="Fastmail">Fastmail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut Street - Suite 1201</street>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19102</code>
          <country>USA</country>
        </postal>
        <email>alh@fastmailteam.com</email>
      </address>
    </author>
    <date/>
    <area>ART</area>
    <!--    <workgroup>EXTRA</workgroup>-->

    <keyword>Sieve</keyword>
    <abstract>
      <t>This document describes the "processcalendar" extension to the
      Sieve email filtering language.
      The "processcalendar" extension gives Sieve the ability to process
      machine-readable calendar data that is encapsulated in an
      email message using Multipurpose Internet Mail Extensions (MIME).</t>
    </abstract>
<!--
    <note title="Open Issues">
      <ul>
      </ul>
    </note>
-->
  </front>

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>Users frequently receive invites, replies, and cancellations
      for events, tasks, etc. via Internet mail messages.
      It is sometimes desirable to have such messages automatically
      parsed and the enclosed calendar data
      added to, updated on, or deleted from the user's calendars.</t>

      <t>Typically such messages are based on the
      <xref target="RFC6047" format="default">iCalendar Message-Based
      Interoperability Protocol (iMIP)</xref>.
      However, sometimes the enclosed
      <xref target="RFC5545">iCalendar</xref> data does not include an
      iTIP method property
      (see <xref target="RFC5546" section="1.4" sectionFormat="comma"/>),
      or the enclosed data may be in some other machine-readable format
<!--      (E.g. <xref target="I-D.ietf-calext-jscalendarbis">-->
      (E.g. <xref target="RFC8984">
      JSCalendar</xref>).
      </t>

      <t>This document defines an extension to the
      <xref target="RFC5228" format="default">Sieve language</xref>
      that enables scripts to process machine-readable calendar data
      that is encapsulated in an email message using
      <xref target="RFC2045">MIME</xref>.
      Specifically, this extension provides the ability to alter
      items on a user's calendars referenced in the encapsulated
      calendar data.</t>
    </section>

    <section numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <t>Conventions for notations are as in
      <xref target="RFC5228" section="1.1" format="default"/>,
      including use of the "Usage:" label for the definition of action
      and tagged arguments syntax.</t>

      <t>This document uses terminology and concepts from
      <xref target="RFC5545">iCalendar</xref> and 
      <xref target="RFC5546">iTIP</xref> to describe the processing of
      calendar data, but this extension can be used with any
      machine-readable calendar data format that can express similar
      concepts.</t>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14
      <xref target="RFC2119" format="default"/>
      <xref target="RFC8174" format="default"/> 
      when, and only when, they appear in all capitals, as shown
      here.</t>
    </section>

    <section anchor="capability" numbered="true" toc="default">
      <name>Capability Identifier</name>
      <t>Sieve interpreters that implement this extension MUST have an
      identifier of "processcalendar" for use with the capability
      mechanism.</t>

    </section>

    <section anchor="processcalendar" numbered="true" toc="default">
      <name>Process Calendar Action</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Usage: processcalendar [ :allowpublic ]
                       [ :addresses <string-list> ]
                       [ :updatesonly / :calendarid <string> ]
                       [ :deletecancelled ]
                       [ :organizers <ext-list-name: string> ]
                       [ :outcome <variablename: string> ]
                       [ :reason <variablename: string> ]
]]></artwork>

      <t>The "processcalendar" action is used to parse encapsulated
      calendar data and perform the appropriate action based on the
      content.
      If the calendar data is malformed in any way, it MUST be ignored
      and no action is taken.
      Otherwise, based on the iTIP method
      (see <xref target="RFC5546" section="1.4" />)
      of the message, calendar objects are created, updated, or
      deleted from a given calendar.</t>

      <t>This action can be used with or without the
      <xref target="RFC6134">"extlists"</xref> extension.
      When the "extlists" extension is enabled in a script using
      &lt;require "extlists"&gt;, the script can use the
      <xref target="organizers">:organizers</xref> argument to the
      "processcalendar" action as described below.
      When the "extlists" extension is not enabled, the :organizers
      argument MUST NOT be used and MUST cause an error
      according to <xref target="RFC5228" />.</t>

      <t>This action can be used with or without the
      <xref target="RFC5229">"variables"</xref> extension.
      When the "variables" extension is enabled in a script using
      &lt;require "variables"&gt;, the script can use the
      <xref target="outcome">:outcome</xref> and 
      <xref target="reason">:reason</xref> arguments to the
      "processcalendar" action as described below.
      When the "variables" extension is not enabled, the :outcome
      and :reason arguments MUST NOT be used and MUST cause an error
      according to <xref target="RFC5228" />.</t>

      <t>If a mail messages contains calendar data in multiple
      <xref target="RFC2045">MIME</xref> parts, this action MUST
      verify that the calendar data in each part are semantically
      equivalent to one another.  If the data is found to be
      semantically different, the action MUST NOT process the message.
      Otherwise, the action MUST only process one representation of
      the data.</t>

      <t>This action MUST NOT make any changes to the participant
      status of the recipient when processing the calendar data.
      The mechanism for a recipient to change their participant status
      to an event is out of scope for this document.</t>

      <t>This action SHOULD remove alarms from calendar data
      before applying it to a calendar.
      Failure to do so could result in unwelcome notifications being
      triggered for the recipient.</t>

      <section anchor="allowpublic" numbered="true" toc="default">
        <name>Allow Public Argument</name>
<!--
        <t>The optional :allowpublic argument is used to tell the
        implementation that it can process calendar data that
        is not an iTIP message (it does not contain METHOD and/or
        ORGANIZER properties) or the METHOD is PUBLISH.</t>
-->
        <t>The optional :allowpublic argument is used to tell the
        implementation that it can process calendar data that
        does not contain any ATTENDEE properties, such as
        iTIP messages where the METHOD is PUBLISH, or non-iTIP
        messages where the calendar data does not contain METHOD and/or
        ORGANIZER properties.</t>

        <t>If used in conjunction with the <xref target="organizers">
        :organizers</xref> argument, the implementation MUST NOT
        process non-iTIP messages.</t>
<!--
        <t>The optional :allowpublic argument is used to tell the
        implementation that it can process calendar data that
        does not contain any ATTENDEE properties.
        If used in conjunction with the <xref target="organizers">
        :organizers</xref> argument, the implementation MUST NOT
        process calendar data unless is it is a well-formed iTIP
        message, including those in which the METHOD is PUBLISH.
        Otherwise, non-iTIP calendar data may be processed.</t>
-->
        <t>If :allowpublic is omitted, the implementation MUST NOT
        process calendar data unless is it is a well-formed iTIP
        message and one of the recipient user's email addresses
        matches the Calendar User Address
        (see <xref target="RFC5545" section="3.3.3" format="default" />)
        of the intended target of the message, as determined by the
        iTIP method (see <xref target="RFC5546" section="1.4" />)
        of the message:</t>

        <ul empty="true" spacing="normal">
          <li>"REPLY": Value of the "Organizer" property
          (see <xref target="RFC5545" section="3.8.4.1" />)</li>
          <li>"REQUEST", "CANCEL", "ADD":
          Value of one of the "Attendee" properties
          (see <xref target="RFC5545" section="3.8.4.3" />)</li>  
        </ul>

        <t>The recipient user's email address matches the Calendar User
        Address of the target if the Calendar User Address is in the
        form of a mailto URI and the email address matches the
        "addr-spec" of the URI.</t>

        <t>An email address is considered to belong to the recipient if
        it is one of:</t>

        <ol>
          <li>an email address known by the implementation to be
          associated with the recipient,</li>

          <li>the final envelope recipient address if it's available to
          the implementation, or</li>

          <li>an address specified by the script writer via the
          <xref target="addresses">:addresses</xref> argument.</li>
        </ol>
      </section>

      <section anchor="addresses" numbered="true" toc="default">
        <name>Addresses Argument</name>
        <t>The optional :addresses argument is used to specify
        email addresses that belong to the recipient in addition to
        the addresses known to the implementation.</t>
      </section>

      <section anchor="updatesonly" numbered="true" toc="default">
        <name>Updates Only Argument</name>
        <t>The optional :updatesonly argument is used to limit the
        messages processed to those targeting existing calendar
        objects only.
        If the message contains a new calendar object (its
        unique identifier does
        not exist on any of the user's calendars), the implementation
        MUST NOT add the object to a calendar.</t>

        <t>If :updatesonly is omitted, new calendar objects may be
        added to one of the user's calendars.</t>

        <t>The :updatesonly and <xref target="calendarid">:calendarid</xref>
        arguments are incompatible with each other.  It is an error if
        both arguments are used in the same "processcalendar" action.</t>
      </section>

      <section anchor="calendarid" numbered="true" toc="default">
        <name>Calendar ID Argument</name>
        <t>The optional :calendarid argument specifies the identifier
        of the calendar onto which new calendar objects should be placed.</t>

        <t>If :calendarid is omitted, new calendar objects will be
        placed on the user's "default" calendar as determined by the
        implementation.</t>

        <t>The <xref target="updatesonly">:updatesonly</xref> and :calendarid
        arguments are incompatible with each other.  It is an error if
        both arguments are used in the same "processcalendar" action.</t>
      </section>

      <section anchor="deletecancelled" numbered="true" toc="default">
        <name>Delete Cancelled Argument</name>
        <t>The optional :deletecancelled argument is used to tell the
        implementation that if it receives a cancellation message,
        it SHOULD remove the associated calendar object from the
        calendar.</t>

        <t>If :deletecancelled is omitted, the status of the
        associated calendar object will be set to cancelled and will
        remain on the calendar.</t>
      </section>

      <section anchor="organizers" numbered="true" toc="default">
        <name>Organizers Argument</name>
        <t>The optional :organizers argument is used to specify
        an external list of email addresses from which the
        recipient is willing to accept public events, invites,
        updates, and cancellations.
        Implementations MUST NOT process calendar data unless is it is
        a well-formed iTIP message and one of the addresses in the
        external list matches the Calendar User Address of the
        "Organizer" property.
        An email address in the external list matches the Calendar User
        Address of the "Organizer" property if it is in the form of a
        mailto URI and the email address matches the "addr-spec" of
        the URI.</t>

        <t>If :organizers is omitted, no validation of the "Organizer"
        property is performed.</t>
      </section>

      <section anchor="outcome" numbered="true" toc="default">
        <name>Outcome Argument</name>
        <t>The optional :outcome argument specifies the name of a
        variable into which one of the following strings specifying
        the outcome of the action will be stored:</t>

        <ul>
          <li>"no_action": No action was performed
          (E.g., the message didn't contain calendar data, or
          the set of provided options prevented the message from being
          processed).</li>
          <li>"added": A new calendar object was added to a calendar</li>
          <li>"updated": A calendar resource was updated, cancelled, or
          removed from the calendar.</li>
          <li>"error": The message would have been processed but
          encountered an error in doing so.</li>
        </ul>
      </section>

      <section anchor="reason" numbered="true" toc="default">
        <name>Reason Argument</name>
        <t>The optional :reason argument specifies the name of a
        variable into which a string describing the reason for the
        outcome will be stored.
        If no reason for the outcome is available, implementations
        MUST set the variable to the empty string.</t>
        <t>For example, an outcome of "no_action" may have a reason of
        "only processing updates" or an outcome of "error" may have a
        reason of "missing unique identifier".</t>
      </section>

      <section anchor="interaction" numbered="true" toc="default">
        <name>Interaction with Other Sieve Actions</name>

        <t>The "processcalendar" action does not cancel Sieve's
        implicit keep action.</t>

        <t>The "processcalendar" action can only be executed once per
        script.
        A script MUST fail with an appropriate error if it attempts to
        execute two or more "processcalendar" actions.</t>

        <t>The "processcalendar" action is incompatible with the Sieve
        <xref target="RFC5429" format="default">
        reject and ereject</xref> actions.</t>
      </section>

      <section anchor="examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>The following example specifies email addresses belonging
        to the user and  the identifier of the calendar onto
        which to place new calendar objects:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
require [ "processcalendar" ];

processcalendar :addresses [ "me@example.com", "alsome@example.com" ]
                :calendarid "1ea6d86b-6c7f-48a2-bed3-2a4c40ec281a";
]]></artwork>

        <t>The following example tells the interpreter to process
        flight itineraries from a particular airline:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
require [ "processcalendar" ];

if allof (address ["from", "sender"] "airline@example.com",
          header :contains "subject" "itinerary") {
   processcalendar :allowpublic;
}
]]></artwork>

        <t>The following example adds headers to the message if
        calendar data isn't processed :</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
require [ "processcalendar", "variables", "editheader" ];

set "processcal_outcome" "no_action";
set "processcal_reason" "";

processcalendar :outcome "processcal_outcome"
                :reason "processcal_reason";

if not string :is "${processcal_outcome}" ["added", "updated"] {
   addheader "X-ProcessCal-Outcome" "${processcal_outcome}";
   addheader "X-ProcessCal-Reason" "${processcal_reason}";
}
]]></artwork>
      </section>

    </section> <!-- processcalendar -->

    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document describes a method for altering an electronic
      calendar without user interaction.  As such, unless proper
      precautions are undertaken, it can be used as a vector for
      calendar abuse.</t>

      <t>It is critical that implementations correctly implement the
      behavior and restrictions described throughout this document.
      Security issues associated with processing unsolicited
      calendar data, and methods for mitigating them are discussed in
      <xref target="CALSPAM" format="default"/>.  Specifically:</t>

      <ul>
        <li>Processcalendar MUST NOT process any calendar data
        enclosed in a message flagged as spam and/or malicious.
        The <xref target="RFC5235">spamtest and virustest</xref>
        extensions (or the <xref target="RFC5228">header</xref> test
        if messages are scanned outside of the Sieve
        interpreter) can be used to make processcalendar conditional
        on "safe" content.</li>

        <li>Processcalendar SHOULD NOT process calendar data
        received from a potentially malicious sender.
        The <xref target="RFC5228">address and envelope</xref> tests
        (optionally along with the <xref target="RFC6134">extlists</xref>
        extension) can be used to create a "deny list" and make
        processcalendar conditional on the sender not being a member
        of that list.</li>

        <li>Similarly, processcalendar SHOULD only process calendar
        data received from a known sender.
        The <xref target="RFC5228">address and envelope</xref> tests
        (optionally along with the <xref target="RFC6134">extlists</xref>
        extension) can be used to create an "allow list" and make
        processcalendar conditional on the sender being a member of
        that list.</li>

        <li>Processcalendar SHOULD NOT process calendar data received
        from an untrustworthy sender.  Trustworthiness may depend on
        whether the message has a valid signature (see
        <xref target="RFC8551"/>) and/or on whether one or more of
        <xref target="RFC7208">Sender Policy Framework (SPF)</xref>,
        <xref target="RFC6376">DomainKeys Identified Mail (DKIM)
        Signatures</xref>,
        <xref target="RFC7489">Domain-based Message Authentication,
        Reporting, and Conformance (DMARC)</xref> passes or fails on
        the message.
        The mechanism by which a Sieve interpreter accesses the results of
        such checks is outside the scope of this document, but if the
        results are available in the message's header fields,
        the <xref target="RFC5228">header</xref> test can be used to make
        processcalendar conditional on the sender being trustworthy.</li>
      </ul>

      <t>Additionally, if the calendar data has embedded (a.k.a. inline)
      attachments, implementations SHOULD:</t>

      <ul>
        <li>Decode the embedded attachment, if necessary.</li>

        <li>Scan the (decoded) attachment for malicious content.</li>
      </ul>

      <t>If an attachment is found to be malicious, processcalendar
      MUST NOT process the calendar data.</t>
          
    </section>

    <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>It is believed that this extension doesn't introduce any
      privacy considerations beyond those in
      <xref target="RFC5228" format="default"/>.</t>
    </section>

    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>Registration of Sieve Extension</name>
        <t>This document defines the following new Sieve extension
        to be added to the registry defined in
        Section 6.2 of <xref target="RFC5228" format="default"/> and located here:
        <eref target="https://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml#sieve-extensions"/>
        </t>
        <t>IANA are requested to add a capability to the Sieve
        Extensions registry:
        </t>
        <ul empty="true" spacing="normal">
          <li>To: iana@iana.org</li>
          <li>Subject: Registration of new Sieve extension</li>
          <li>Capability name: processcalendar</li>
          <li>Description: Adds the "processcalendar" action command to
            add and update items on a user's calendars.</li>
          <li>RFC number: RFC XXXX</li>
          <li>Contact address: The Sieve discussion list
            &lt;sieve@ietf.org&gt;</li>
        </ul>
      </section>

      <section numbered="true" toc="default">
        <name>Registration of Sieve Action</name>
        <t>This document defines the following new Sieve action
        to be added to the registry defined in
        Section 2.1 of <xref target="RFC9122" format="default"/> and located here:
        <eref target="https://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml#sieve-actions"/>
        </t>
        <t>IANA are requested to add a capability to the Sieve
        Actions registry:
        </t>
        <ul empty="true" spacing="normal">
          <li>To: iana@iana.org</li>
          <li>Subject: Registration of new Sieve action</li>
          <li>Name: processcalendar</li>
          <li>Description: Add and update items on a user's calendars</li>
          <li>References: RFC XXXX <xref target="RFC5229"/>
                          <xref target="RFC6134"/></li>
          <li>Capabilities: "processcalendar", "variables", "extlists"</li>
          <li>Action Interactions: This action is incompatible with
          "reject" and "ereject" actions</li>
          <li>Cancels Implicit Keep? No</li>
          <li>Can Use with IMAP Events? No</li>
        </ul>
      </section>
    </section> <!-- IANA -->

    <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank the following individuals for
      contributing their ideas and support for writing this
      specification: Ned Freed and Alexey Melnikov.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5228.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5229.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6047.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6134.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9122.xml"/>

        <reference anchor="CALSPAM"
                   target="https://standards.calconnect.org/csd/cc-18003.html">
          <front>
            <title>Calendar operator practices - Guidelines to protect
            against calendar abuse</title>
            <author>
              <organization>The Calendaring and Scheduling Consortium</organization>
            </author>
            <date year="2019"/>
          </front>
          <seriesInfo name="CC/R" value="18003"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5235.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.5429.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8984.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>
<!--      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-calext-jscalendarbis.xml"/>-->
      </references>
    </references>

    <section
        title="Change History (To be removed by RFC Editor before publication)">
      <t>Changes since draft-ietf-sieve-processimip-08:</t>
      <ol>
        <li>Added a consequence of not removing alarms before applying
        data to a calendar.</li>
        <li>Changed iCalendar-specific "UID" to generic "unique
        identifier".</li>
        <li>Use a normative SHOULD for :deletecancelled argument.</li>
        <li>Removed Implementation Status section.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-07:</t>
      <ol>
        <li>Fixed Sieve Action registration to include all associated
        capabilites and their references.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-06:</t>
      <ol>
        <li>Fixed example that was still using :errstr rather than
        :reason.</li>
        <li>Explicitly stated that the :updateonly and :calendarid
        options are incompatible with each each.</li>
        <li>Explicitly stated that if :allowpublic is used with :organizers
        that non-iTIP messages MUST NOT be processed.</li>
        <li>Updated security considerations to use "deny list" and
        "allow list", and to add a bullet discussing use of S/MIME,
        SPF, DKIM, and DMARC.</li>
        <li>Updated the status of the Cyrus implementation.</li>
        <li>Miscellaneous editorial changes.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-05:</t>
      <ol>
        <li>Renamed :errstr to :reason and added examples.</li>
        <li>Miscellaneous editorial changes.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-04:</t>
      <ol>
        <li>Miscellaneous editorial changes.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-03:</t>
      <ol>
        <li>Added text about multiple MIME parts containing calendar data.</li>
        <li>Added text about embedded attachments to Security
        Considerations.</li>
        <li>Added :organizers option if "extlists" is supported.</li>
        <li>Miscellaneous editorial changes.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-02:</t>
      <ol>
        <li>Renamed :nonitip to :allowpublic to cover both non-iTIP
        and METHOD:PUBLIC messages.</li>
        <li>Renamed :deletecanceled to :deletecancelled to match
        RFC5545 language.</li>
        <li>Specified that this action MUST NOT alter a recipient's
        participation status.</li>
        <li>:errstr MUST be set to the empty string if no reason for
        the outcome is available.</li>
        <li>Added the "Interaction with Other Sieve Actions" subsection.</li>
        <li>Add Security Considerations.</li>
        <li>Added action registration.</li>
        <li>Added three issues for discussion.</li>
        <li>Miscellaneous editorial changes.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-01:</t>
      <ol>
        <li>Changed the name of the action from processimip to
        processcalendar.</li>
        <li>The action is now independent of iMIP and is calendar data
        format agnostic.</li>
        <li>Added examples.</li>
      </ol>

      <t>Changes since draft-ietf-sieve-processimip-00:</t>
      <ol>
        <li>No changes.</li>
      </ol>

      <t>Changes since draft-murchison-sieve-processimip-00:</t>
      <ol>
        <li>Document name change only.</li>
      </ol>
    </section>

  </back>
</rfc>