This document defines an extension to CalDAV that allows clients and servers that audit data on the server, to provide feedback based on the results of such audits. This can be used to signal clients about junk events, or other inappropriate content. It can also be used by clients to provide feedback about junk events, or other inappropriate content, that the server can act on in a manner that prevents the originator of the data from knowing it was discarded.
© 2018 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This document defines an extension to CalDAV that allows clients and servers that audit data on the server, to provide feedback based on the results of such audits. This can be used to signal clients about junk events, or other inappropriate content. It can also be used by clients to provide feedback about junk events, or other inappropriate content, that the server can act on in a manner that prevents the originator of the data from knowing it was discarded.
Internet calendaring and scheduling standards are defined by iCalendar
CalDAV calendar users can receive event invitations or sharing invitations from other users on the CalDAV server, and in the case of event invitations, they may also be received from users outside the system (e.g., via an email based gateway service). Unfortunately, as has been the case with email for quite some time now, this provides an avenue for abuse. In particular, there has recently been an increase in so called calendar “spam” (unsolicited bulk event invitations — in future referred to as “junk” invitations) that automatically appear on a user’s calendar. Whilst users can delete such invitations, the current default behavior of CalDAV servers is to send a scheduling iTIP reply message back to the organizer of the invite indicating that the user (who appears as an attendee in the invite) has declined the invitation. This is not desirable as it signals to the originator that a speculative attendee calendar user address they might have used is in fact valid. It is much more preferable for the invite to be silently discarded without a reply being sent. CalDAV does support such an option via use of the “Schedule-Reply” HTTP header (see
Also, as with email, a server can scan invitations as they are being delivered and provide an indication of “junk” status to allow clients to filter invitations or provide warnings to the user. Such status is usually conveyed in email messages via the addition of email message headers during delivery, however, iCalendar invitations typically do not include delivery meta-data.
This specification defines the following extensions to CalDAV to help provide better junk invitation status and reporting:
A new CS:audit-status WebDAV property is defined for use on any resource in a CalDAV server. The value of that property is a comma-separated list of “key=value” pairs that can be used to convey invitation auditing status from the server to a client.
A new POST request action can be targeted at resources to allow a client to report a problem about the resource and trigger the server to take appropriate steps (e.g., discard the resource, record information about the resource so that it can be permanently suppressed).
This specification does not cover how servers or clients analyse invitations, but rather it only covers the reporting of such analysis. What is considered inappropriate is likely dependent on local policies and regulations, which cannot be generally codified. It is expected that email scanning tools and techniques can be adapted for use with calendar data on both clients and servers.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
When XML element types in the namespaces “DAV:” and “urn:ietf:params:xml:ns:caldav” are referenced in this document outside of the context of an XML fragment, the string “DAV:” and “CALDAV:” will be prefixed to the element type names respectively.
The namespace “” is used for XML elements defined in this specification. When XML element types in this namespace are referenced in this document outside of the context of an XML fragment, the string “CS:” will be prefixed to the element type names respectively.
A server that supports this specification MUST include “calendar-audit” as a field in the DAV response header field from an OPTIONS request on a calendar home collection (see
The CS:audit-status WebDAV property provides any server side audit results, for the resource the property is present on, to the client. The value of this property is a string containing one or more comma- separated “key=value” pairs that can be used to conveying specific details about the audit results. A set of initial keys defined by this specification are listed below. Additional keys may be added in the future. Servers SHOULD only include audit results that are known to be useful to clients to avoid having this property grow too large.
Clients that support this extension SHOULD request the CS:audit-status property in any PROPFIND or REPORT requests that return properties for resources on the CalDAV server. In particular, calendar object resources will likely all be audited, and so SHOULD be checked by clients.
Clients MAY do their own auditing of resources retrieved from the server. Clients are likely to take into consideration locally available contextual information when doing client-side auditing, information that is typically not available to servers. As a result, when the CS:audit-status property is present, clients SHOULD use it in conjunction with, rather than as a replacement of, any client-side auditing to determine the overall suitability of the resource.
audit-status
Indicates server auditing status for the resource on which this property is defined.
This property MAY be present on any resource within a CalDAV calendar home collection. If present, it SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in
The CS:audit-status property provides details of any server auditing done for the resource on which it is defined. In the absence of this property, clients MUST assume that no auditing has taken place. The supported key/value pairs defined in this specification are listed in the next section.
Note that additional line breaks have been added for readability.
The following CS:audit-status key/value pair items are defined by this specification. The “status” MUST be present, other keys are OPTIONAL. Clients SHOULD ignore any keys that they do not recognize.
| Key | Value | Description |
|---|---|---|
| status | GOOD | Audit result indicates no problem with this resource |
| status | WARNING | Audit result indicates a possible problem with this resource |
| status | BAD | Audit result indicates a strong possibility of a problem with this resource |
| score | {integer: 0-100} | An integer value in the range 0-100. 0 means the resource is definitely free of problematic content. 100 means the resource definitely contains problematic content. Values in between relate to varying degrees of concern for the resource content. |
| reason | {string} | A textual description of the result of the server audit that can be presented to the user. |
| audit-id | {string} | An opaque identifier used to correlate the reported audit status with the auditing system. |
When a client detects a CalDAV resource that it has determined to be inappropriate for some reason, or as the result of the calendar user explicitly indicating that a resource is inappropriate, it can signal that state to the server by issuing a POST request with the request- URI set to the resource URI, and with an “action=audit-failure” query parameter in the request-URI.
Upon receiving such a request the server MUST take the following actions:
If the target resource is a calendar object resource, the server MUST delete the resource without sending any scheduling reply messages. The server MUST use the iCalendar UID property value in the target resource to:
delete any other resources in calendar collections owned by the calendar user, or the calendar user’s scheduling inbox collection, that have the same iCalendar UID property
prevent any future scheduling messages with the same iCalendar UID being delivered to that calendar user
If the target resource is a sharing invitation in the calendar user’s notification collection, the server MUST delete the notification resource without sending any sharing reply to the sharer. The server MUST also prevent any future sharing invitations for the same calendar collection from being delivered to the calendar user.
The behavior for other types of resource is currently undefined. Servers MUST reject such requests with an appropriate HTTP 4xx status code.
Servers MAY perform their own analysis of the resource being reported and act on it accordingly, but this specification does not define how that is done or what the consequences are.
The audit report POST request supports the following request-URI query parameters:
| Name | Description |
|---|---|
| action | this is REQUIRED and MUST have a value of “audit-failure” |
| reason | this is OPTIONAL and contains a short string indicating the nature of the failure |
The client MAY include other query parameters as needed. The server SHOULD ignore all query parameters that it cannot process.
On successful completion of the request, the server returns an appropriate HTTP 2xx status code. Upon receiving a successful response, clients SHOULD immediately re-synchronize their state with the server to ensure any resources that were removed as a result of the POST request are also removed from any cache the client might have.
If the request fails for any reason, the actions described above MUST NOT occur, and in particular, no resources are to be deleted.
This specification discards an entire resource — thus there is no provision to report inappropriate content in one instance of a recurring event since all instances are in the same calendar object resource.
The client issues a POST request to indicate an audit failure on a particular resource:
Report received and acted upon.
It is important that no replies whatsoever be sent back to the originator of the invitation being discarded. In addition, the invite originator MUST NOT be given any other indication that the invite was discarded.
The server MUST protect any information it gets from client audit failure reports to prevent attackers from learning how to work around client auditing procedures.
The server MUST protect any information it gets from client audit failure reports to prevent calendar users from being “profiled” based on what items they consider to be inappropriate.
None.
This specification is the result of discussions between the Apple calendar server and client teams.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) “calendar-access” feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the “calendar-auto-schedule” feature of CalDAV. [STANDARDS-TRACK]