WebDAV: User Notifications
draft-pot-webdav-notifications-01

Abstract

This specification defines an extension to WebDAV that allows the server to provide notifications to users.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 11, 2015.

Copyright Notice

Copyright (c) 2015 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.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 3. Requirements Overview
• 4. Notifications
• 4.1. Mime type
• 4.2. Additional Principal Properties
• 4.2.1. DAV:notification-URL Property
• 4.3. Properties on Notification Resources
• 4.3.1. DAV:notificationtype Property
• 4.4. XML Element Definitions
• 4.4.1. DAV:notifications
• 4.4.2. DAV:notification
• 4.4.3. DAV:dtstamp
• 5. Notification Definitions
• 5.1. System Status Notification
• 5.1.1. DAV:systemstatus Element Definition
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Backwards-compatibility with earlier drafts
• Appendix B. Change History (to be removed prior to publication as an RFC
• Authors' Addresses

1. Introduction

It is often useful for servers to communicate arbitrary information to the end-users for a WebDAV system, such as a system status, message of the day or to notify users of changes that were made to shared resources by other users.

This specification defines a generic "notification" mechanism that allows a server to do that. Whilst primarily aimed at CalDAV [RFC4791] and CardDAV [RFC6352] this mechanism has been designed to be adaptable to other applications of WebDAV [RFC4918].

2. 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:" is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type name.

The DTD samples used in this document are for illustrative purposes only. The conventions and restrictions described in [RFC4918] section 17.

3. Requirements Overview

To add support for WebDAV notifications, a server MUST at least have support for WebDAV Class 3 [RFC4918].

WebDAV notifications also defines new properties on principal resources, which are defined in RFC3744 [RFC3744].

4. Notifications

When this feature is available, a DAV:notification-URL [DAV:notification-URL] 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.

The notification collection referenced by the DAV:notification-URL [DAV:notification-URL] property MUST have a DAV:resourcetype property with DAV:collection and DAV:notifications [DAV:notifications] child elements.

Notification "messages" are XML documents stored as resources in the notification collection. Each XML document contains a DAV:notification [DAV:notification] element as its root. The root element contains a DAV: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 DAV:notificationtype [DAV:notificationtype] 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 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 DAV:notificationtype [DAV:notificationtype] 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. Mime type

The "application/davnotification+xml" MIME media type MUST be used for transfer of WebDAV notifications.

Content-Type: application/davnotification+xml

This is an example of a Content-Type header:

HTTP GET requests that expect to receive a WebDAV notification resource, SHOULD include an "Accept" header that includes "application/davnotification+xml".

Requests that do not include this header, SHOULD be rejected with a HTTP 406 status code.

4.2. 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.

4.2.1. DAV:notification-URL Property

<!ELEMENT notification-URL (DAV:href)>

Name:

notification-URL

Namespace:

DAV:

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 principal is not enabled for notification messages on the server.

Definition:

4.3. Properties on Notification Resources

The following new WebDAV properties are defined for notification resources.

4.3.1. DAV:notificationtype Property

<!ELEMENT notificationtype ANY>
<!-- Child elements are empty but will have appropriate attributes.
     Any valid notification message child element can appear.-->

Name:

notificationtype

Namespace:

DAV:

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]).

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:

4.4. XML Element Definitions

4.4.1. DAV:notifications

<!ELEMENT notifications EMPTY>

Name:

notifications

Namespace:

DAV:

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:

4.4.2. DAV:notification

<!ELEMENT notification (dtstamp, XXX) >
<!-- Any notification type element can appear after
     DAV:dtstamp -->

Name:

notification

Namespace:

DAV:

Purpose:

Notification message root element.

Description:

The root element used in notification resources.

Definition:

4.4.3. DAV:dtstamp

<!ELEMENT dtstamp (#PCDATA)>
<!-- Value is a date-time in UTZ as per [RFC3339] -->

Name:

dtstamp

Namespace:

DAV:

Purpose:

Date-time stamp.

Description:

DAV:dtstamp is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present.

Definition:

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 an URI and/or textual description to the user. The assumption is that the URI points to a webpage where the 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 an agent's language preferences, in which case it MAY localise the DAV: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 DAV:description element to indicate what language is being used.

5.1.1. DAV:systemstatus Element Definition

<!ELEMENT systemstatus (DAV:href?, DAV:description?)>
<!ATTLIST systemstatus type (low | medium | high) "low">
<!-- One of DAV:href or DAV:description MUST be present -->

<?xml version="1.0" encoding="UTF-8"?>
<D:notification xmlns:D="DAV:">
  <D:dtstamp>2011-12-09T06:12:53Z</D:dtstamp>
  <D:systemstatus type="high">
    <D:href>http://example.com/emergency_shutdown.html</D:href>
    <D:description xml:lang='en_US'>
        Emergency shutdown now
    </D:description>
  </D:systemstatus>
</D:notification>

<?xml version="1.0" encoding="UTF-8"?>
<D:notificationtype xmlns:D="DAV:">
  <D:systemstatus type="high" />
</D:notificationtype>

Name:

systemstatus

Namespace:

DAV:

Purpose:

Indicates a system status notification.

Description:

This XML element is used in a DAV:notification element to describe a system status notification.

Definition:

Example:

This is an example of the body of a notification resource for an emergency system outage:

Example:

This is an example of the WebDAV property on the example notification resource above:

6. Security Considerations

TBD: More?

7. IANA Considerations

This document defines a MIME media type for use of WebDAV notifications in an XML format. This media type SHOULD be used for the transfer of WebDAV notifications.

Type name:

application

Subtype name:

davnotification+xml

Required parameters:

none

Optional parameters:

none

Encoding considerations:

Identical to those of "application/xml" as described in RFC7303 [RFC7303].

Security considerations:

See Section 6.

Interoperability considerations:

There are no known interoperability issues.

Published specification:

This specification.

Applications that use this media type:

No known applications currently use this media type.

Fragment identifier considerations:

N/A.

Additional information

Deprecated alias names for this type

N/A.

Magic number(s)

N/A.

File extension(s)

xml

Macintosh file type code(s)

TEXT

Person & email address to contact for further information:

me@evertpot.com

Intended usage

COMMON

Restrictions on usage

There are no restrictions on where this media

Author

See the "Authors' Addresses" section of this document.

Change Controller

IETF

8. Acknowledgments

The authors would like to thank the members of the Calendaring and Scheduling Consortium's SharingTechnical Committee. In particular, the following individuals have made important contributions to this work: Richard Brigham, John Chaffee, Michael Douglass and Ken Murchison and Dave Thewlis.

This specification originated from work at the Calendaring and Scheduling Consortium, which has supported the development and testing of implementations of the specification.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Backwards-compatibility with earlier drafts

An earlier draft of this specification is already widely deployed among both servers and clients.

This specification, informally known as 'caldav-notifications' largely uses the same structure as this specification, but where the "DAV:" xml namespace is used in this specification, the earlier draft uses "http://calendarserver.org/ns/".

It is possible to conform to both that draft and this specification by either creating two different collections, as identified by "notification-URL" in each respective namespace. Alternatively it's possible to use the same resource for both, but use content-negotation using the Accept header to ask the server for a specific representation of a notification.

Appendix B. Change History (to be removed prior to publication as an RFC

Changes in -01:

1. Added a paragraph about xml/dtd handling with a reference to RFC4917

Authors' Addresses