jakob/friendica-addons
1
0
Fork 0
forked from friendica/friendica-addons
Code Pull requests Activity

Heavily refactored, including multiple calendars per user and recurring events. Not in an installable state yet, though

Browse source
This commit is contained in:
Tobias Hößl 2012-07-08 17:12:58 +00:00
commit fefee23e90
78 changed files with 8026 additions and 1205 deletions
Download patch file Download diff file Expand all files Collapse all files

1568
dav/SabreDAV/docs/caldav-notifications.txt Normal file
View file

@ -0,0 +1,1568 @@
Calendar Server Extension C. Daboo
Apple Inc.
March 19, 2012
CalDAV: Calendar User Notifications
Abstract
This specification defines an extension to CalDAV that allows the
server to provide notifications to calendar users.
Daboo [Page 1]
CalDAV User Notifications March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Additional Principal Properties . . . . . . . . . . . . . 4
4.1.1. CS:notification-URL Property . . . . . . . . . . . . . 5
4.2. Properties on Notification Resources . . . . . . . . . . . 5
4.2.1. CS:notificationtype Property . . . . . . . . . . . . . 5
4.3. XML Element Definitions . . . . . . . . . . . . . . . . . 6
4.3.1. CS:notifications . . . . . . . . . . . . . . . . . . . 6
4.3.2. CS:notification . . . . . . . . . . . . . . . . . . . 6
4.3.3. CS:dtstamp . . . . . . . . . . . . . . . . . . . . . . 7
5. Notification Definitions . . . . . . . . . . . . . . . . . . . 7
5.1. System Status Notification . . . . . . . . . . . . . . . . 7
5.1.1. CS:systemstatus Element Definition . . . . . . . . . . 8
5.2. Quota Notification . . . . . . . . . . . . . . . . . . . . 8
5.2.1. CS:quotastatus Element Definition . . . . . . . . . . 9
5.3. Resource Changes Notification . . . . . . . . . . . . . . 10
5.3.1. CS:resource-change Element Definition . . . . . . . . 11
5.3.2. CS:calendar-changes Element Definition . . . . . . . . 15
5.3.2.1. Handling Recurrences in CS:calendar-changes . . . 17
5.3.3. CS:deleted-details Element Definition . . . . . . . . 18
5.3.4. CS:notify-changes Property . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Resource Created . . . . . . . . . . . . . . . . . . . . . 21
A.2. Resource Updated - Property Change . . . . . . . . . . . . 22
A.3. Resource Updated - Parameter Change . . . . . . . . . . . 23
A.4. Resource Updated - Multiple Instances Change . . . . . . . 23
A.5. Resource Updated - Multiple User Change . . . . . . . . . 24
A.6. Resource Deleted . . . . . . . . . . . . . . . . . . . . . 25
A.7. Collection Created . . . . . . . . . . . . . . . . . . . . 26
A.8. Collection Updated . . . . . . . . . . . . . . . . . . . . 26
A.9. Collection Deleted . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Daboo [Page 2]
CalDAV User Notifications March 2012
1. Introduction
CalDAV [RFC4791] provides a way for calendar users to store calendar
data and exchange this data via scheduling operations. Based on the
WebDAV [RFC4918] protocol, it also includes the ability to manage
access to calendar data via the WebDAV ACL [RFC3744] extension.
It is often useful for servers to communicate arbitrary information
to calendar users, e.g., system status, message of the day, quota
warnings, changes to shared resources made by others etc. This
specification defines a generic "notification" mechanism that allows
a server to do that. Whilst primarily aimed at CalDAV [RFC4791],
this mechanism has been designed to be adaptable to WebDAV [RFC4918].
2. Open Issues
1. Define specific child elements for system status notification,
e.g. "server-maintenance-period", "server-read-only-period",
"client-upgrade-required".
3. Conventions Used in This Document
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 [RFC2119].
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 "http://calendarserver.org/ns/" is used for XML
elements defined in this specification. When XML element types in
that 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.
4. Notifications
When this feature is available, a CS:notification-URL (Section 4.1.1)
property appears on principal resources for those principals who are
able to receive notifications. That property specifies a single DAV:
href element whose content refers to a WebDAV collection resource.
Notification "messages" are deposited into this collection and can be
retrieved by clients and acted on accordingly.
Daboo [Page 3]
CalDAV User Notifications March 2012
The notification collection referenced by the CS:notification-URL
(Section 4.1.1) property MUST have a DAV:resourcetype property with
DAV:collection and CS:notifications (Section 4.3.1) child elements.
Notification "messages" are XML documents stored as resources in the
notification collection. Each XML document contains a CS:
notification (Section 4.3.2) element as its root. The root element
contains a CS:dtstamp element, and one additional element which
represents the type of notification being conveyed in the message.
That child element will typically contain additional content that
describes the notification.
Each notification resource has a CS:notificationtype (Section 4.2.1)
property which contains as its single child element an empty element
that matches the child element of the notification resource XML
document root. Any attributes on the child element in the XML
document are also present in the property child element.
Notifications are automatically generated by the server (perhaps in
response to a action) with an appropriate resource stored in the
notifications collection of the user to whom the notification is
targeted. Clients SHOULD monitor the notification collection looking
for new notification resources. When doing so, clients SHOULD look
at the CS:notificationtype (Section 4.2.1) property to ensure that
the notification is of a type that the client can handle. Once a
client has handled the notification in whatever way is appropriate it
SHOULD delete the notification resource. Clients SHOULD remove
notifications being displayed to a user when the notification
resource is removed from the notification collection, to enable the
user to dismiss a notification on one device and have it
automatically removed from others. Clients MUST ignore all
notifications for types they do not recognize. Servers MAY delete
notification resources on their own if they determine that the
notifications are no longer relevant or valid. Servers MAY coalesce
notifications as appropriate.
Servers MUST prevent clients from adding resources in the
notification collection.
4.1. Additional Principal Properties
This section defines new properties for WebDAV principal resources as
defined in RFC3744 [RFC3744]. These properties are likely to be
protected but the server MAY allow them to be written by appropriate
users.
Daboo [Page 4]
CalDAV User Notifications March 2012
4.1.1. CS:notification-URL Property
Name: notification-URL
Namespace: http://calendarserver.org/ns/
Purpose: Identify the URL of the notification collection owned by
the associated principal resource.
Protected: This property SHOULD be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
COPY/MOVE behavior: This property value SHOULD be preserved in COPY
and MOVE operations.
Description: This property is needed for a client to determine where
the notification collection of the current user is located so that
processing of notification messages can occur. If not present,
then the associated calendar user is not enabled for notification
messages on the server.
Definition:
<!ELEMENT notification-URL (DAV:href)>
4.2. Properties on Notification Resources
The following new WebDAV properties are defined for notification
resources.
4.2.1. CS:notificationtype Property
Name: notificationtype
Namespace: http://calendarserver.org/ns/
Purpose: Identify the type of notification of the corresponding
resource.
Protected: This property MUST be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
Daboo [Page 5]
CalDAV User Notifications March 2012
COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations.
Description: This property allows a client, via a PROPFIND Depth:1
request, to quickly find notification messages that the client can
handle in a notification collection. The single child element is
the notification resource root element's child defining the
notification itself. This element MUST be empty, though any
attributes on the element in the notification resource MUST be
present in the property element.
Definition:
<!ELEMENT notificationtype ANY>
<!-- Child elements are empty but will have appropriate attributes.
Any valid notification message child element can appear.-->
4.3. XML Element Definitions
4.3.1. CS:notifications
Name: notifications
Namespace: http://calendarserver.org/ns/
Purpose: Indicates a notification collection.
Description: This XML element is used in a DAV:resourcetype element
to indicate that the corresponding resource is a notification
collection.
Definition:
<!ELEMENT notifications EMPTY>
4.3.2. CS:notification
Name: notification
Namespace: http://calendarserver.org/ns/
Purpose: Notification message root element.
Description: The root element used in notification resources.
Daboo [Page 6]
CalDAV User Notifications March 2012
Definition:
<!ELEMENT notification (dtstamp, XXX) >
<!-- Any notification type element can appear after
CS:dtstamp -->
4.3.3. CS:dtstamp
Name: dtstamp
Namespace: http://calendarserver.org/ns/
Purpose: Date-time stamp.
Description: Contains the date-time stamp corresponding to the
creation of a notification message, using the format defined in
[RFC3339], or the "compact" format without "-" and ":" characters
between date and time elements, respectively.
Definition:
<!ELEMENT dtstamp (#PCDATA)>
<!-- Value is a date-time in UTZ as per [RFC3339] with
"compact" format allowed.-->
5. Notification Definitions
This section defines a set of common notification types.
5.1. System Status Notification
The system status notification is used to convey a URI and/or textual
description to the user. The assumption is that the URI points to a
webpage where current system status is described in detail, with the
provided description being a summary of that. A "type" attribute on
the element is used to indicate the importance of the current status
notification, and has the values "low", "medium" and "high",
representing the increasing level of importance of the message
respectively.
Servers might have knowledge of specific calendar user language
preferences, in which case it MAY localise the CS:description value
as appropriate based on the calendar user accessing the notification,
but if it does, it SHOULD include an xml:lang attribute on the CS:
description element to indicate what language is being used.
Daboo [Page 7]
CalDAV User Notifications March 2012
5.1.1. CS:systemstatus Element Definition
Name: systemstatus
Namespace: http://calendarserver.org/ns/
Purpose: Indicates a system status notification.
Description: This XML element is used in a CS:notification element
to describe a system status notification.
Definition:
<!ELEMENT systemstatus (DAV:href?, CS:description?)>
<!ATTLIST systemstatus type (low | medium | high) "low">
<!ELEMENT description CDATA>
<!-- One of DAV:href of CS:description MUST be present -->
Example: This is an example of the body of a notification resource
for an emergency system outage:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:12:53-05:00</CS:dtstamp>
<CS:systemstatus type="high">
<D:href>http://example.com/emergency_shutdown.html</D:href>
<CS:description xml:lang='en_US'
>Emergency shutdown now</CS:description>
</CS:systemstatus>
</CS:notification>
Example: This is an example of the WebDAV property on the example
notification resource above:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notificationtype xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:systemstatus type="high" />
</CS:notificationtype>
5.2. Quota Notification
The quota notification is used to convey information about the status
of one or more quotas for the user. The notification contains
elements for different types of quota being reported to the user. In
Daboo [Page 8]
CalDAV User Notifications March 2012
some cases these may be warnings (e.g., a user getting to 80% of
their quota limit), or in other cases errors (e.g., a user exceeding
their quota).
5.2.1. CS:quotastatus Element Definition
Name: quotastatus
Namespace: http://calendarserver.org/ns/
Purpose: Indicates a quota status notification.
Description: This XML element is used in a CS:notification element
to describe a quota status notification. The CS:quota-percent-
used element contains an integer greater than or equal to zero.
If the value is greater than or equal to 100, then the user's
quota has been reached or exceeded. The DAV:href element contains
a URI for a webpage where the user can go to get further
information about their quota status or take corrective action.
Definition:
<!ELEMENT quota-status (quota+)>
<!ELEMENT quota (quota-type, quota-percent-used?,
quota-count?, DAV:href?)>
<!ATTLIST quota type (warning | exceeded) "exceeded">
<!ELEMENT quota-type ANY>
<!-- Child elements are application specific -->
<!ELEMENT quota-percent-used CDATA>
<!-- Integer value greater than or equal to zero -->
<!ELEMENT quota-count CDATA>
<!-- Integer value greater than or equal to zero -->
Example: This is an example of the body of a notification resource
for a quota warning:
Daboo [Page 9]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:12:53-05:00</CS:dtstamp>
<CS:quota-status>
<CS:quota type="warning">
<CS:quota-type><CS:attachments /></CS:quota-type>
<CS:quota-percent-used>80</CS:quota-percent-used>
<D:href>https://example.com/your-account.html</D:href>
</CS:quota>
</CS:quota-status>
</CS:notification>
Example: This is an example of the body of a notification resource
for a quota that has been exceeded, and a count-based limit that
is shown as a warning:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:12:53-05:00</CS:dtstamp>
<CS:quota-status>
<CS:quota type="exceeded">
<CS:quota-type><CS:attachments /></CS:quota-type>
<CS:quota-percent-used>102</CS:quota-percent-used>
<D:href>https://example.com/fix-account.html</D:href>
</CS:quota>
<CS:quota type="warning">
<CS:quota-type><CS:events /></CS:quota-type>
<CS:quota-percent-used>82</CS:quota-percent-used>
<CS:quota-count>4980</CS:quota-count>
<D:href>https://example.com/buy-more-space.html</D:href>
</CS:quota>
</CS:quota-status>
</CS:notification>
5.3. Resource Changes Notification
The resource change notification is used to inform the user of new,
updated or deleted resources caused by changes made by someone else
(note: servers MUST NOT generate notifications to users for changes
they themselves make, though the possibility of an automated process
acting on behalf of a user needs to be considered). This
notification can be used by clients to show changes that a user can
acknowledge in their own time. When the notification is present, it
can be displayed on all devices a user is accessing their data from.
When the user acknowledges and dismisses the notification on one
device, other devices SHOULD also remove the notification when they
Daboo [Page 10]
CalDAV User Notifications March 2012
next synchronize the notification collection.
A new WebDAV property CS:notify-changes (Section 5.3.4) is defined
for calendar collections. This allows users to enable or disable the
sending of resource change notifications for the calendar and its
child resources. Servers MUST allow users to set this property on a
per-user basis on any calendars accessible to them. Servers MUST
honor the chosen setting to enable or disable change notifications.
Servers can send notifications for calendar object resources, and
ones for calendar collections. Servers SHOULD coalesce notifications
that refer to the same resource into a single notification resource,
containing multiple CS:created, CS:updated or CS:deleted elements all
with the same DAV:href child element value. Servers MAY coalesce
changes to multiple resources into a change notification for the
parent collection of those resources and use a CS:collection-changes
element to indicate the number of individual resources that changed.
5.3.1. CS:resource-change Element Definition
Name: resource-change
Namespace: http://calendarserver.org/ns/
Purpose: Indicates that resources have been created, updated or
deleted.
Description: This XML element is used in a CS:notification element
to describe a resource change notification. It can describe a
change directly to a calendar object resource or to a calendar
collection.
When used for a calendar object resource change, it can contain
one of the CS:created, or CS:deleted elements, or multiple CS:
updated elements, which indicate a created, deleted or updated
resource, respectively. The DAV:href element within those
elements, contains the URI of the changed resource, optional
information about who changed the resource and when that change
was made (the CS:changed-by element), and information specific to
the nature of the change. Servers SHOULD coalesce resource change
notifications for the same resource into a single notification
resource where possible. The CS:updated element optionally
contains CS:content and/or DAV:prop elements to indicate a change
to the body of the resource or resource WebDAV properties,
respectively. The DAV:prop element MAY contain a list of property
elements to indicate which properties changed. The CS:updated
element can also contain zero or more CS:calendar-changes elements
to list details of the changes. If no CS:calendar-changes element
Daboo [Page 11]
CalDAV User Notifications March 2012
is present, the specific details are not provided, and clients
will need to assume that some set of changes occurred, but the
server is unwilling to disclose the full details. The CS:deleted
element can also contain zero or more CS:deleted-details elements
to list details of the deleted resource.
When used for a calendar collection change, it can contain a CS:
collection-changes element. The DAV:href element within that
element, contains the URI of the changed calendar collection. The
DAV:prop element indicates a change to WebDAV properties on the
calendar collection resource. The CS:child-created, CS:child-
updated, and CS:child-deleted elements each contain a positive
integer value indicating how many child resources were added,
updated or deleted in the collection, respectively.
Definition:
Daboo [Page 12]
CalDAV User Notifications March 2012
<!ELEMENT resource-change (created | updated+ | deleted |
collection-changes)>
<!ELEMENT created (DAV:href, changed-by?, ANY)>
<!ELEMENT updated (DAV:href, changed-by?, content?,
DAV:prop?, calendar-changes*)>
<!ELEMENT content EMPTY>
<!ELEMENT deleted (DAV:href, changed-by?, deleted-details)>
<!ELEMENT changed-by (common-name | (first-name, last-name),
dtstamp?, DAV:href)>
<!ELEMENT common-name CDATA>
<!ELEMENT first-name CDATA>
<!ELEMENT last-name CDATA>
<!-- CS:changed-by indicates who made the change that caused the
notification. CS:first-name and CS:last-name are the first
and last names of the corresponding user. or the
CS:common-name is the overall display name. CS:dtstamp is the
time in UTC when the change was made. The DAV:href element
is the principal URI or email address of the user who made
the change. -->
<!ELEMENT collection-changes (DAV:href, changed-by*, DAV:prop?,
child-created?, child-updated?,
child-deleted?>
<!-- When coalescing changes from multiple users, the changed-by
element can appear more than once. -->
<!ELEMENT child-created CDATA>
<!ELEMENT child-updated CDATA>
<!ELEMENT child-deleted CDATA>
<!-- Each of the three elements above MUST contain a positive,
non-zero integer value indicate the total number of changes
being reported for the collection. -->
Example: This is an example of the body of a notification resource
for changes where one resource has been created:
Daboo [Page 13]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:created>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:common-name>Cyrus Daboo</CS:common-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
</CS:created>
</CS:resource-change>
</CS:notification>
Example: This is an example of the body of a notification resource
for changes where a resource has been updated twice. One of the
updated resources elements contains additional information
indicating which recurrence instances in the iCalendar data were
changed:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/event.ics</D:href>
<CS:changed-by>
<CS:first-name>Oliver</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>mailto:oliver@example.com</D:href>
</CS:changed-by>
</CS:updated>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/event.ics</D:href>
<CS:changed-by>
<CS:first-name>Eleanor</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>mailto:eleanor@example.com</D:href>
</CS:changed-by>
</CS:updated>
</CS:resource-change>
</CS:notification>
Daboo [Page 14]
CalDAV User Notifications March 2012
Example: This is an example of the body of a notification resource
for changes where one resource has been deleted:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:deleted>
<D:href>http://example.com/cyrus/calendar/old.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
</CS:deleted>
</CS:resource-change>
</CS:notification>
Example: This example is the same as the previous three, except that
all the individual resource changes have been coalesced into a
single notification about changes to the parent calendar
collection:
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:collection-changes>
<D:href>http://example.com/cyrus/calendar/</D:href>
<CS:child-created>1</CS:child-created>
<CS:child-updated>2</CS:child-updated>
<CS:child-deleted>1</CS:child-deleted>
</CS:collection-changes>
</CS:resource-change>
</CS:notification>
5.3.2. CS:calendar-changes Element Definition
Name: calendar-changes
Namespace: http://calendarserver.org/ns/
Purpose: Indicates which portions of an calendar object resource
have changed, or provides details of deleted calendar object
resources.
Daboo [Page 15]
CalDAV User Notifications March 2012
Description: This XML element is used in a CS:updated element to
describe how a calendar object resource changed, or in a CS:
deleted element to provide details of a deleted resource. It can
identify the master instance, or individual recurrence instances,
and for each indicate which iCalendar properties and parameters
changed during the update for which the notification was
generated. For details of handling recurrences please see
Section 5.3.2.1.
Definition:
<!ELEMENT calendar-changes (recurrence+) >
<!ELEMENT recurrence
((master | recurrenceid), added?, removed?, changes?)>
<!-- Which instances were affected by the change,
and details on the per-instance changes -->
<!ELEMENT master EMPTY>
<!-- The "master" instance was affected -->
<!ELEMENT recurrenceid CDATA>
<!-- RECURRENCE-ID value in iCalendar form (in UTC if a
non-floating DATE-TIME value) for the affected instance -->
<!ELEMENT added EMPTY>
<!-- The component was added -->
<!ELEMENT removed EMPTY>
<!-- The component was removed -->
<!ELEMENT changes changed-property*>
<!-- Detailed changes in the iCalendar data -->
<!ELEMENT changed-property changed-parameter*>
<!ATTLIST changed-property name PCDATA>
<!-- An iCalendar property changed -->
<!ELEMENT changed-parameter EMPTY>
<!ATTLIST changed-parameter name PCDATA>
<!-- An iCalendar property parameter changed -->
Example: This example indicates that a non-recurring component, or
the master component in a recurring component, was changed and
that the change was to the "SUMMARY" iCalendar property.
Daboo [Page 16]
CalDAV User Notifications March 2012
<CS:calendar-changes xmlns:CS="http://calendarserver.org/ns/">
<CS:recurrence>
<CS:master/>
<CS:changes>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
Example: This example indicates that an instance of a recurring
component was changed and that the change was to the "DTSTART"
iCalendar property.
<CS:calendar-changes xmlns:CS="http://calendarserver.org/ns/">
<CS:recurrence>
<CS:recurrenceid>20111215T160000Z</CS:recurrenceid>
<CS:changes>
<CS:changed-property name="DTSTART"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
5.3.2.1. Handling Recurrences in CS:calendar-changes
Changes to recurring components can be complex. This section
describes the possible set of changes that could occur, and what the
CS:calendar-changes element will contain as a result.
Master exists, unchanged override added In this case, a CS:
recurrence element will be present, containing a CS:recurrence-id
element with a value equal to the RECURRENCE-ID property value (in
UTC) of the added component. A CS:added element will be present.
There will not be any CS:removed or CS:changes elements.
Master exists, changed override added In this case, a CS:recurrence
element will be present, containing a CS:recurrence-id element
with a value equal to the RECURRENCE-ID property value (in UTC) of
the added component. Both CS:added and CS:changes elements will
be present. There will not be a CS:removed element.
Master exists, override changed In this case, a CS:recurrence
element will be present, containing a CS:recurrence-id element
with a value equal to the RECURRENCE-ID property value (in UTC) of
the added component. A CS:changes element will be present. There
will not be any CS:added or CS:removed elements.
Daboo [Page 17]
CalDAV User Notifications March 2012
Master exists, override removed In this case, a CS:recurrence
element will be present, containing a CS:recurrence-id element
with a value equal to the RECURRENCE-ID property value (in UTC) of
the added component. A CS:removed element will be present. There
will not be a CS:added element. A CS:changes element will only be
present if the removed component differs from the "derived" master
instance.
Master exists, override cancelled In this case, a CS:recurrence
element will be present, containing a CS:recurrence-id element
with a value equal to the RECURRENCE-ID property value (in UTC) of
the added component. A CS:removed element will be present. There
will not be any CS:added or CS:changes element. There will also
be a CS:master element present, with an appropriate CS:changes
element, likely covering a change to "RRULE" or addition of
"EXDATE" properties.
Master does not exist, override added In this case, a CS:recurrence
element will be present, containing a CS:recurrence-id element
with a value equal to the RECURRENCE-ID property value (in UTC) of
the added component. A CS:added element will be present. There
will not be a CS:removed or CS:changes element.
Master does not exist, override changed In this case, a CS:
recurrence element will be present, containing a CS:recurrence-id
element with a value equal to the RECURRENCE-ID property value (in
UTC) of the added component. A CS:changes element will be
present. There will not be any CS:added or CS:removed elements.
Master does not exist, override removed In this case, a CS:
recurrence element will be present, containing a CS:recurrence-id
element with a value equal to the RECURRENCE-ID property value (in
UTC) of the added component. A CS:removed element will be
present. There will not be any CS:added or CS:changes element.
5.3.3. CS:deleted-details Element Definition
Name: deleted-details
Namespace: http://calendarserver.org/ns/
Purpose: Provides summary information about a deleted resource or
collection.
Description: This XML element is used in a CS:deleted element to
describe useful information about a deleted resource or
collection, so clients can provide a meaningful notification
message to users. This element has two variants: one for deletion
Daboo [Page 18]
CalDAV User Notifications March 2012
of a calendar object resource, the other for deletion of a
calendar collection.
Definition:
<!ELEMENT deleted-details ((deleted-component,
deleted-summary,
deleted-next-instance?,
deleted-had-more-instances?) |
deleted-displayname)>
<!-- deleted-displayname is used for a collection delete, the other
elements used for a resource delete. -->
<!ELEMENT deleted-component CDATA>
<!-- The main calendar component type of the deleted
resource, e.g., "VEVENT", "VTODO" -->
<!ELEMENT deleted-summary CDATA>
<!-- Indicates the "SUMMARY" of the next future instance at the
time of deletion, or the previous instance if no future
instances existed at the time of deletion. -->
<!ELEMENT deleted-next-instance CDATA>
<!ATTLIST deleted-next-instance tzid PCDATA>
<!-- If present, indicates when the next deleted instance would
have occurred. For a VEVENT that would be the DTSTART value,
for a VTODO that would be either DTSTART or DUE, if present.
In each case the value must match the value in the iCalendar
data, and any TZID iCalendar property parameter value must
be included in the tzid XML element attribute value. -->
<!ELEMENT deleted-had-more-instances EMPTY>
<!-- If present indicates that there was more than one future
instances still to occur at the time of deletion. -->
<!ELEMENT deleted-displayname CDATA>
<!-- The DAV:getdisplayname property for the collection that
was deleted. -->
Example: This example indicates deletion of a non-recurring event
that was yet to occur at the time of deletion.
<CS:deleted-details xmlns:CS="http://calendarserver.org/ns/">
<CS:deleted-component>VEVENT</CS:deleted-component>
<CS:deleted-summary>Birthday Party</CS:deleted-summary>
<CS:deleted-next-instance tzid="America/New_York
>20120505T120000</CS:deleted-next-instance>
</CS:deleted-details>
Daboo [Page 19]
CalDAV User Notifications March 2012
Example: This example indicates deletion of a calendar.
<CS:deleted-details xmlns:CS="http://calendarserver.org/ns/">
<CS:deleted-displayname>Holidays</CS:deleted-displayname>
</CS:deleted-details>
5.3.4. CS:notify-changes Property
Name: notify-changes
Namespace: http://calendarserver.org/ns/
Purpose: Allows a user to specify whether resource change
notifications are generated by the server.
Protected: This property MUST NOT be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations.
Description: This property allows a user to enable or disable the
server generation of resource change notifications for the
calendar collection, and all its child resources, on which the
property resides. If the property is not present on a calendar
collection, the client and server MUST assume that resource change
notifications are enabled.
Definition:
<!ELEMENT notify-changes (true|false)>
<!ELEMENT true EMPTY>
<!ELEMENT false EMPTY>
<!-- true - notifications enabled,
false - notifications disabled -->
6. Security Considerations
Some notification mechanisms might allow a user to trigger a
notification to be delivered to other users (e.g., an invitation to
share a calendar). In such cases servers MUST ensure that suitable
limits are placed on the number and frequency of such user generated
notifications.
Daboo [Page 20]
CalDAV User Notifications March 2012
TBD: More?
7. IANA Considerations
This document does not require any actions on the part of IANA.
8. Acknowledgments
This specification is the result of discussions between the various
Apple calendar server and client teams.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
9.2. Informative References
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
March 2007.
Appendix A. Examples
This section provides more detailed examples of resource change
notifications for illustrative purposes only.
A.1. Resource Created
This is an example of the body of a notification resource where one
resource has been created.
Daboo [Page 21]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:created>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
</CS:created>
</CS:resource-change>
</CS:notification>
A.2. Resource Updated - Property Change
This is an example of the body of a notification resource where one
non-recurring event has had its "DTSTART" and "SUMMARY" iCalendar
property values changed.
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:calendar-changes>
<CS:recurrence>
<CS:master/>
<CS:changes>
<CS:changed-property name="DTSTART"/>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
</CS:updated>
</CS:resource-change>
</CS:notification>
Daboo [Page 22]
CalDAV User Notifications March 2012
A.3. Resource Updated - Parameter Change
This is an example of the body of a notification resource where one
non-recurring event has had the "PARTSTAT" iCalendar property
parameter on an "ATTENDEE" property changed, and a "TRANSP" property
added.
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:calendar-changes>
<CS:recurrence>
<CS:master/>
<CS:added>
<CS:changed-property name="TRANSP"/>
</CS:added>
<CS:changes>
<CS:changed-property name="ATTENDEE">
<CS:changed-parameter name="PARTSTAT"/>
</CS:changed-property>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
</CS:updated>
</CS:resource-change>
</CS:notification>
A.4. Resource Updated - Multiple Instances Change
This is an example of the body of a notification resource where two
instances of a recurring event have their "DTSTART" and "SUMMARY"
iCalendar property values changed.
Daboo [Page 23]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:calendar-changes>
<CS:recurrence>
<CS:recurrenceid>20120209T170000Z</CS:recurrenceid>
<CS:changes>
<CS:changed-property name="DTSTART"/>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
<CS:recurrence>
<CS:recurrenceid>20120210T170000Z</CS:recurrenceid>
<CS:changes>
<CS:changed-property name="DTSTART"/>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
</CS:updated>
</CS:resource-change>
</CS:notification>
A.5. Resource Updated - Multiple User Change
This is an example of the body of a notification resource where two
instances of a recurring event have their "DTSTART" and "SUMMARY"
iCalendar property values changed. Each instance was changed by a
different user.
Daboo [Page 24]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:calendar-changes>
<CS:recurrence>
<CS:recurrenceid>20120209T170000Z</CS:recurrenceid>
<CS:changes>
<CS:changed-property name="DTSTART"/>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
</CS:updated>
<CS:updated>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Eric</CS:first-name>
<CS:last-name>York</CS:last-name>
<D:href>/principals/ericyork</D:href>
</CS:changed-by>
<CS:calendar-changes>
<CS:recurrence>
<CS:recurrenceid>20120210T170000Z</CS:recurrenceid>
<CS:changes>
<CS:changed-property name="DTSTART"/>
<CS:changed-property name="SUMMARY"/>
</CS:changes>
</CS:recurrence>
</CS:calendar-changes>
</CS:updated>
</CS:resource-change>
</CS:notification>
A.6. Resource Deleted
This is an example of the body of a notification resource where one
resource has been deleted. The resource was a VEVENT whose next
occurrence was in the future on 20120210T170000Z.
Daboo [Page 25]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:deleted>
<D:href>http://example.com/cyrus/calendar/new.ics</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:deleted-details>
<CS:deleted-component>VEVENT</CS:deleted-component>
<CS:deleted-summary>CalDAV Meeting</CS:deleted-summary>
<CS:deleted-next-instance
>20120210T170000Z</CS:deleted-next-instance>
</CS:deleted-details>
</CS:deleted>
</CS:resource-change>
</CS:notification>
A.7. Collection Created
This is an example of the body of a notification resource where a
calendar collection has been created.
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:created>
<D:href>http://example.com/cyrus/new-calendar/</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
</CS:created>
</CS:resource-change>
</CS:notification>
A.8. Collection Updated
This is an example of the body of a notification resource where
coalesced changes in a calendar collection are shown. In this case 1
child resource was created, 2 updated, and 1 deleted.
Daboo [Page 26]
CalDAV User Notifications March 2012
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:collection-changes>
<D:href>http://example.com/cyrus/calendar/</D:href>
<CS:child-created>1</CS:child-created>
<CS:child-updated>2</CS:child-updated>
<CS:child-deleted>1</CS:child-deleted>
</CS:collection-changes>
</CS:resource-change>
</CS:notification>
A.9. Collection Deleted
This is an example of the body of a notification resource where a
calendar collection has been deleted.
<?xml version="1.0" encoding="UTF-8"?>
<CS:notification xmlns:D="DAV:"
xmlns:CS="http://calendarserver.org/ns/">
<CS:dtstamp>2011-12-09T11:51:14-05:00</CS:dtstamp>
<CS:resource-change>
<CS:deleted>
<D:href>http://example.com/cyrus/old-calendar/</D:href>
<CS:changed-by>
<CS:first-name>Cyrus</CS:first-name>
<CS:last-name>Daboo</CS:last-name>
<D:href>/principals/cyrusdaboo</D:href>
</CS:changed-by>
<CS:deleted-details>
<CS:deleted-displayname>Holidays</CS:deleted-displayname>
</CS:deleted-details>
</CS:deleted>
</CS:resource-change>
</CS:notification>
Daboo [Page 27]
CalDAV User Notifications March 2012
Author's Address
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Daboo [Page 28]

224
dav/SabreDAV/docs/caldav-sharing-02.txt Normal file
View file

File diff suppressed because one or more lines are too long

451
dav/SabreDAV/docs/rfc5785.txt Normal file
View file

@ -0,0 +1,451 @@
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 5785 E. Hammer-Lahav
Updates: 2616, 2818 April 2010
Category: Standards Track
ISSN: 2070-1721
Defining Well-Known Uniform Resource Identifiers (URIs)
Abstract
This memo defines a path prefix for "well-known locations",
"/.well-known/", in selected Uniform Resource Identifier (URI)
schemes.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5785.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nottingham & Hammer-Lahav Standards Track [Page 1]
RFC 5785 Defining Well-Known URIs April 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 7
1. Introduction
It is increasingly common for Web-based protocols to require the
discovery of policy or other information about a host ("site-wide
metadata") before making a request. For example, the Robots
Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
automated processes to obtain permission to access resources;
likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
tells user-agents how to discover privacy policy beforehand.
While there are several ways to access per-resource metadata (e.g.,
HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
(either in terms of client-perceived latency and/or deployment
difficulties) associated with them often precludes their use in these
scenarios.
When this happens, it is common to designate a "well-known location"
for such data, so that it can be easily located. However, this
approach has the drawback of risking collisions, both with other such
designated "well-known locations" and with pre-existing resources.
To address this, this memo defines a path prefix in HTTP(S) URIs for
these "well-known locations", "/.well-known/". Future specifications
that need to define a resource for such site-wide metadata can
register their use to avoid collisions and minimise impingement upon
sites' URI space.
Nottingham & Hammer-Lahav Standards Track [Page 2]
RFC 5785 Defining Well-Known URIs April 2010
1.1. Appropriate Use of Well-Known URIs
There are a number of possible ways that applications could use Well-
known URIs. However, in keeping with the Architecture of the World-
Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
for general information retrieval or establishment of large URI
namespaces on the Web. Rather, they are designed to facilitate
discovery of information on a site when it isn't practical to use
other mechanisms; for example, when discovering policy that needs to
be evaluated before a resource is accessed, or when using multiple
round-trips is judged detrimental to performance.
As such, the well-known URI space was created with the expectation
that it will be used to make site-wide policy information and other
metadata available directly (if sufficiently concise), or provide
references to other URIs that provide such metadata.
2. Notational Conventions
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 RFC 2119 [RFC2119].
3. Well-Known URIs
A well-known URI is a URI [RFC3986] whose path component begins with
the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
or another scheme that has explicitly been specified to use well-
known URIs.
Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1.
For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'.
Registered names MUST conform to the segment-nz production in
[RFC3986].
Note that this specification defines neither how to determine the
authority to use for a particular context, nor the scope of the
metadata discovered by dereferencing the well-known URI; both should
be defined by the application itself.
Typically, a registration will reference a specification that defines
the format and associated media type to be obtained by dereferencing
the well-known URI.
Nottingham & Hammer-Lahav Standards Track [Page 3]
RFC 5785 Defining Well-Known URIs April 2010
It MAY also contain additional information, such as the syntax of
additional path components, query strings and/or fragment identifiers
to be appended to the well-known URI, or protocol-specific details
(e.g., HTTP [RFC2616] method handling).
Note that this specification does not define a format or media-type
for the resource located at "/.well-known/" and clients should not
expect a resource to exist at that location.
4. Security Considerations
This memo does not specify the scope of applicability of metadata or
policy obtained from a well-known URI, and does not specify how to
discover a well-known URI for a particular application. Individual
applications using this mechanism must define both aspects.
Applications minting new well-known URIs, as well as administrators
deploying them, will need to consider several security-related
issues, including (but not limited to) exposure of sensitive data,
denial-of-service attacks (in addition to normal load issues), server
and client authentication, vulnerability to DNS rebinding attacks,
and attacks where limited access to a server grants the ability to
affect how well-known URIs are served.
5. IANA Considerations
5.1. The Well-Known URI Registry
This document establishes the well-known URI registry.
Well-known URIs are registered on the advice of one or more
Designated Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]). However,
to allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied
that such a specification will be published.
Registration requests should be sent to the
wellknown-uri-review@ietf.org mailing list for review and comment,
with an appropriate subject (e.g., "Request for well-known URI:
example").
Before a period of 14 days has passed, the Designated Expert(s) will
either approve or deny the registration request, communicating this
decision both to the review list and to IANA. Denials should include
an explanation and, if applicable, suggestions as to how to make the
Nottingham & Hammer-Lahav Standards Track [Page 4]
RFC 5785 Defining Well-Known URIs April 2010
request successful. Registration requests that are undetermined for
a period longer than 21 days can be brought to the IESG's attention
(using the iesg@iesg.org mailing list) for resolution.
5.1.1. Registration Template
URI suffix: The name requested for the well-known URI, relative to
"/.well-known/"; e.g., "example".
Change controller: For Standards-Track RFCs, state "IETF". For
others, give the name of the responsible party. Other details
(e.g., postal address, e-mail address, home page URI) may also be
included.
Specification document(s): Reference to the document that specifies
the field, preferably including a URI that can be used to retrieve
a copy of the document. An indication of the relevant sections
may also be included, but is not required.
Related information: Optionally, citations to additional documents
containing further relevant information.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
6.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
Nottingham & Hammer-Lahav Standards Track [Page 5]
RFC 5785 Defining Well-Known URIs April 2010
[W3C.REC-P3P-20020416]
Marchiori, M., "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", World Wide Web Consortium
Recommendation REC-P3P-20020416, April 2002,
<http://www.w3.org/TR/2002/ REC-P3P-20020416>.
[W3C.REC-webarch-20041215]
Jacobs, I. and N. Walsh, "Architecture of the World Wide
Web, Volume One", World Wide Web Consortium
Recommendation REC- webarch-20041215, December 2004,
<http:// www.w3.org/TR/2004/REC-webarch-20041215>.
Nottingham & Hammer-Lahav Standards Track [Page 6]
RFC 5785 Defining Well-Known URIs April 2010
Appendix A. Acknowledgements
We would like to acknowledge the contributions of everyone who
provided feedback and use cases for this document; in particular,
Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
not responsible for errors and omissions.
Appendix B. Frequently Asked Questions
1. Aren't well-known locations bad for the Web?
They are, but for various reasons -- both technical and social --
they are commonly used and their use is increasing. This memo
defines a "sandbox" for them, to reduce the risks of collision and
to minimise the impact upon pre-existing URIs on sites.
2. Why /.well-known?
It's short, descriptive, and according to search indices, not
widely used.
3. What impact does this have on existing mechanisms, such as P3P and
robots.txt?
None, until they choose to use this mechanism.
4. Why aren't per-directory well-known locations defined?
Allowing every URI path segment to have a well-known location
(e.g., "/images/.well-known/") would increase the risks of
colliding with a pre-existing URI on a site, and generally these
solutions are found not to scale well, because they're too
"chatty".
Nottingham & Hammer-Lahav Standards Track [Page 7]
RFC 5785 Defining Well-Known URIs April 2010
Authors' Addresses
Mark Nottingham
EMail: mnot@mnot.net
URI: http://www.mnot.net/
Eran Hammer-Lahav
EMail: eran@hueniverse.com
URI: http://hueniverse.com/
Nottingham & Hammer-Lahav Standards Track [Page 8]