-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcaldav-audit.xml
264 lines (256 loc) · 18.5 KB
/
caldav-audit.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5545 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml'>
<!ENTITY rfc5546 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5546.xml'>
<!ENTITY rfc4791 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4791.xml'>
<!ENTITY rfc4918 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4918.xml'>
<!ENTITY rfc6638 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6638.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private="Calendar Server Extension"?>
<rfc ipr="none" docName='caldav-audit-00'>
<front>
<title abbrev="CalDAV Auditing">CalDAV: Auditing Status and Feedback</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization abbrev="Apple">
Apple Inc.
</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
<uri>http://www.apple.com/</uri>
</address>
</author>
<date />
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>Internet calendaring and scheduling standards are defined by <xref target="RFC5545">iCalendar</xref> and <xref target="RFC5546">iTIP</xref>. The <xref target="RFC4791">CalDAV Access</xref> standard defines a way to access calendar data stored on a server, and the <xref target="RFC6638">CalDAV Scheduling</xref> draft defines how scheduling occurs between users of a CalDAV server.</t>
<t>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 Section 8.1 of <xref target="RFC6638"/>), however, it would be useful to provide an explicit indication from the user to the server that a particular invitation is considered inappropriate so that the server can use that information to potentially filter future invitations that are similar. This type of feedback has been used successfully in email systems, typically exposed to users as a "report as junk" option in their email clients.</t>
<t>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.</t>
<t>This specification defines the following extensions to CalDAV to help provide better junk invitation status and reporting:
<list>
<t>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.</t>
<t>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).</t>
</list>
</t>
<t>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.</t>
</section>
<section title='Conventions Used in This Document'>
<t>
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 <xref target='RFC2119' />.
</t>
<t>
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.
</t>
<t>
The namespace "http://calendarserver.org/ns/" 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.
</t>
</section>
<section title="Server Advertised Capability" anchor="capability">
<t>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 Section 6.2.1 of <xref target="RFC4791" />). Clients MUST check for the presence of that field in the DAV response header field before supporting the extensions in this specification.</t>
</section>
<section title="Audit WebDAV Property">
<t>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.</t>
<t> 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.</t>
<t>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. </t>
<section title="CS:audit-status" anchor="prop_audit-status">
<t>
<list style="hanging">
<t hangText="Name:">
audit-status
</t>
<t hangText="Namespace:">
http://calendarserver.org/ns/
</t>
<t hangText="Purpose:">
Indicates server auditing status for the resource on which this property is defined.
</t>
<t hangText="Conformance:">
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 Section 14.2 of <xref target="RFC4918"/>). This is a protected property (as defined in Section 15 of <xref target="RFC4918"/>). This property MUST be preserved when the resource is copied or moved.
</t>
<t hangText="Description:">
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.
</t>
<t hangText="Definition:">
<figure>
<artwork><![CDATA[
<!ELEMENT audit-status CDATA>
CDATA is a string using the "audit-status" format defined below
audit-status = audit-state *("," audit-state)
audit-state = audit-key "=" audit-value
audit-key = token
audit-value = token / quoted-string
token = ALPHA *(ALPHA / DIGIT / "-")
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
; Any character except CONTROL and DQUOTE
NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629]
CONTROL = %x00-08 / %x0A-1F / %x7F
; All the controls except HTAB
]]></artwork>
</figure>
</t>
<t hangText="Example:">
<figure>
<preamble>Note that additional line breaks have been added for readability.</preamble>
<artwork><![CDATA[
<CS:audit-status
xmlns:CS="http://calendarserver.org/ns/">
status=GOOD,audit-id=51CAA5F8-5C48-45E1-B0E7-3534D7254060
</CS:audit-status>
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="Audit Status Items" anchor="audit-status-items">
<t>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.</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<c>status</c>
<c>GOOD</c>
<c>Audit result indicates no problem with this resource</c>
<c>status</c>
<c>WARNING</c>
<c>Audit result indicates a possible problem with this resource</c>
<c>status</c>
<c>BAD</c>
<c>Audit result indicates a strong possibility of a problem with this resource</c>
</texttable>
<t><vspace/></t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<c>score</c>
<c>{integer: 0-100}</c>
<c>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.</c>
<c>reason</c>
<c>{string}</c>
<c>A textual description of the result of the server audit that can be presented to the user.</c>
<c>audit-id</c>
<c>{string}</c>
<c>An opaque identifier used to correlate the reported audit status with the auditing system.</c>
</texttable>
</section>
</section>
<section title='Client Audit Reporting'>
<t>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.</t>
<t>Upon receiving such a request the server MUST take the following actions:
<list style="letters">
<t>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:
<list style="numbers">
<t>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</t>
<t>prevent any future scheduling messages with the same iCalendar UID being delivered to that calendar user</t>
</list>
</t>
<t>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.</t>
<t>The behavior for other types of resource is currently undefined. Servers MUST reject such requests with an appropriate HTTP 4xx status code</t>
</list>
</t>
<t>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.</t>
<t>The audit report POST request supports the following request-URI query parameters:</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Description</ttcol>
<c>action</c>
<c>this is REQUIRED and MUST have a value of "audit-failure"</c>
<c>reason</c>
<c>this is OPTIONAL and contains a short string indicating the nature of the failure</c>
</texttable>
<t>The client MAY include other query parameters as needed. The server SHOULD ignore all query parameters that it cannot process.
</t>
<t>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.</t>
<t>If the request fails for any reason, the actions described above MUST NOT occur, and in particular, no resources are to be deleted.</t>
<t>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.</t>
<section title='Example'>
<t>
The client issues a POST request to indicate an audit failure on a particular resource:
<figure>
<preamble>
>> Request <<
</preamble>
<artwork>
<![CDATA[POST /event.ics?action=audit-failure&reason=junk HTTP/1.1
Host: cal.example.com
Content-Length: 0
]]></artwork> </figure>
<figure>
<preamble>
>> Response <<
</preamble>
<artwork>
<![CDATA[HTTP/1.1 200 OK
Date: Fri, 10 Jan 2017 14:02:20 GMT
Content-Type: text/plain
Content-Length: xxxx
Report received and acted upon.
]]></artwork></figure>
</t>
</section>
</section>
<section title='Security Considerations'>
<t>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.</t>
<t>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.</t>
</section>
<section title='Privacy Considerations'>
<t>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.</t>
</section>
<section title='IANA Considerations'>
<t>
None.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc5545;
&rfc5546;
&rfc4791;
&rfc4918;
&rfc6638;
</references>
<!--
<references title='Informative References'>
</references>
-->
<section title='Acknowledgments'>
<t>This specification is the result of discussions between the Apple calendar server and client teams. </t>
</section>
<section title='Change History'>
<t>Changes 2016-12-09
<list style='numbers'>
<t>Clarify that clients should never totally rely on the server audit-status result, but instead should always do their own auditing and use the server status as input to that.</t>
<t>Fix xmlns value used in examples.</t>
<t>Remove reference to client reporting on the inbox scheduling resource.</t>
<t>Indicate that servers can implement their own procedures for analyzing invites reported by the client - but those are out of scope of this spec.</t>
</list>
</t>
</section>
</back>
</rfc>