| Network Working Group | M. Douglass |
| Internet-Draft | Spherical Cow Group |
| Intended status: Standards Track | September 28, 2015 |
| Expires: March 31, 2016 |
DAV Server Information Object
draft-douglass-server-info-02
This specification describes a new XML object that can be retrieved from hosts to discover services, features and limits for that host or domain.
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 March 31, 2016.
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.
Any given host on a network may support a number of services. Each of those services will have limits or optional features. The advertising and discovery of services, features and limits is often through the use of properties and headers. As the number of services and features grows the amount of data and complexity of the requests grows.
Additionally, headers and properties don't allow for caching mechanisms based on etags. A client has to fetch all the information and compare with its stored copies to determine if a service change has taken place.
This specification defines a new XML document type which can be retrieved from a host and is easily extended to allow the description of complex services. The schema as described here only handles basic DAV services. Other specifications will extend this specification to define elements for other DAV based services.
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].
By service we mean an application running on one or more hosts at the network application layer and above. The service may provide data storage, manipulation, presentation, communication or other capabilities. The service may use a well defined protocol and is often implemented with a client-server relationship.
A service will usually implement one or more features which may be defined by standard specifications. Services and features may also be constrained by various limits.
Examples of services are
A feature is some functionality provided by a service. For example, a DAV based service may provide the versioning feature.
Services need not support all features that are defined as an optional part of that service. Some features may depend on the authenticated state and/or the authorization of the authenticated principal.
Examples of features are
A host will make the document available through one or more methods. Depending upon the endpoint and method of retrieval the retrieved document may describe one or more services.
If a document provides information for more than one service it SHOULD contain information allowing clients to obtain information about each individual service only. This allows a client to determine what the actual limits and features are for the specific service.
<!ELEMENT server-info-href (DAV:href)>
The document may be retrieved from the server by doing a PROPFIND on the .well_known (or any location on the service) for the D:server-info-href property defined above.
Clients SHOULD retrieve the document in the context of a session and services SHOULD ensure the context is appropriate. Values in the returned document may differ depending on who is authenticated so a server SHOULD require authentication before returning server information for an authenticated service.
While server features may not change frequently it may be important for clients to react rapidly when server features or limits change. Polling for changes is undesirable so this specification allows for informing clients when the server information has changed.
The returned server-info document contains an opaque token which the client can use to determine if the server copy is different. This token is used in a number of places to aid client synchronization.
The server-info-token header field takes as a value the current value of the token element in the server-info document.
This header field may be returned with a response at any time a server feels appropriate.
The server-info-token header MUST be returned for
The server-info-token header field SHOULD be returned when a client
If the server returns a server-info-token header field as part of the response and if the value of that token differs from the value held by the client, then the client MUST fetch a new copy of the server information document.
This specification defines a new XML document type "server-info". All XML elements in this specification are in the DAV name space.
<?xml version="1.0" encoding="utf-8"?>
<server-info xmlns="DAV">
<token>...</token>
<features>
...
</features>
<services>
...
</services>
</server-info>
At the top level of the document is a "server-info" element which encloses a change token, an optional "features" element and a "services" element
If a "features" element appears inside the "server-info" element then the features apply to all services.
The "services" element appears once and contains 0 or more "service" elements each of which provides information about a service.
NOTE: do the service have to be on the same host? I think not.
The "service" element contains the name and information about the location of that service and how to obtain a service specific server-info document.
It may also contain a "features" element which lists features implemented by that service.
<services>
<features>
<DAV:class-1 />
<DAV:class-2 />
<DAV:access-control />
</features>
<service>
<name>caldav</name>
<href>https:cal.example.org//.well-known/caldav</href>
<features>
<CALDAV:calendar-access />
<CS:sharing>
<CS:no-scheduling />
</CS:sharing>
</features>
</service>
</services>
For example:
The "features" element contains 0 or more elements each specifying a feature supported by that service.
The "features" element may appear within the "server-info" element - in which case it applies to all services or it may appear inside a "service" element in which case it only applies to that service.
When a single service is specified the features named SHOULD be accessible for the same authentication and authorization level.
A feature is specified by an element defined in this document or by an element defined in the specification for that feature.
WebDAV feature elements correspond to, but are not exactly the same as, the elements returned in the DAV header.
Some features have no corresponding DAV header element. This may be because the feature is not available on all resources. The occurrence of a such a feature simple advertises the availability of that feature on some resources.
For a service supporting this specification, the absence of a feature means that feature is NOT supported on any resource.
<features>
<DAV:class-1 />
<DAV:class-2 />
<DAV:access-control />
<CALDAV:calendar-access />
<CALDAV:calendar-availability />
<CALDAV:calendar-auto-schedule />
</features>
For example, a calendar service may return the following which specifies a global set of features:
All elements defined here are in the "DAV:" namespace.
<!ELEMENT server-info (token, services?, features?) >
<!ELEMENT token (#PCDATA) >
<!ELEMENT services (service*) >
<!ELEMENT service (name, href?, features) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT features ANY* >
Here we define the feature elements for features defined in the various DAV related specifications.
Specifications which extend this specification should define additions to this table. In addition, they may define the XML specification for that element.
| Namespace | Name | Reference |
|---|---|---|
| DAV | class-1 | [RFC4918]: section 18.1 |
| DAV | class-2 | [RFC4918]: section 18.2 |
| DAV | class-3 | [RFC4918]: section 18.3 |
| DAV | access-control | [RFC3744]: section 7.2 |
| DAV | version-control | [RFC3253]: section 3 |
| DAV | extended-mkcol | [RFC5689]: section 3.1 |
| DAV | quota | [RFC4331] |
| DAV | bind | [RFC5842] |
| DAV | search | [RFC5323] |
| DAV | sync-collection | [RFC6578] |
| DAV | add-member | [RFC5995] |
<!ELEMENT class-1 >
<!ELEMENT class-2 >
<!ELEMENT class-3 >
<!ELEMENT access-control >
<!ELEMENT version-control >
<!ELEMENT extended-mkcol >
<!ELEMENT bind >
<!ELEMENT search >
<!ELEMENT quota >
<!ELEMENT sync-collection >
<!ELEMENT add-member >
TBD.
Tag enabling synchronization Document location (section 3) server-info token in DAV header returned as part of OPTIONS response Clients that see that and do not have a server-info document for that service should do a propfind to discover document href. Authenticated v unauth Clients may fetch the si doc in an unauth mode. When they auth they must recheck their token and refetch if appropriate. Caching by intermediaries might be an issue Server info may vary by user-agent.
TBD.
TBD.
This specification is a result of discussions that took place within the Calendaring and Scheduling Consortium's CalDAV Technical Committee. The author thanks the participants of that group.