DAV Server Information Object

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 .

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 caldav email File servers

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 DAV versioning. DAV access control. CalDAV scheduling.

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.

server-info-href DAV To define the location of the server-info document. This property MAY be protected. This property SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of ). This property value SHOULD be preserved in COPY and MOVE operations. This property is needed for a client to determine where the server information document is located. If not present, then no document is available for the server.

]]>

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 takes as a value the current value of the token element in the server-info document. This header may be returned with a response at any time a server feels appropriate. It MAY be returned in response to a request containing an if-not-server-info-token header. The server-info-token header MUST be returned for an OPTIONS request. It SHOULD be returned if a client attempts to use an unsupported feature or misuse a feature or exceed a limit.

The if-not-server-info-token header takes as a value the current token stored by the client. If that value matches the value stored by the server it SHOULD NOT return a server-info-token header. If they do not match the server MUST return a server-info-token header with the current value. If a new value is returned by the server the client should refetch a copy of the server info document.

This specification defines a new XML document type "server-info". All XML elements in this specification are in the DAV name space.

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. For example:

caldav https:cal.example.org//.well-known/caldav

]]>

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

server-info Contains information about a single service.

]]>

token Contains an opaque token which changes when the document changes..

]]>

services Contains information about all services on a host.

]]>

service Contains information about a specific service on a host.

]]>

name Within a service or feature element provides the registered name of that service or feature.

]]>

href Contains location of a specific service.

]]>

features Contains information about all service features on a host.

]]>

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 : section 18.1 DAV class-2 : section 18.2 DAV class-3 : section 18.3 DAV access-control : section 7.2 DAV version-control : section 3 DAV extended-mkcol : section 3.1 DAV quota DAV sync-collection DAV add-member

DAV class-1 1 : section 18.1 Class 1 compliant resource

]]>

DAV class-2 2 : section 18.2 Class 2 compliant resource

]]>

DAV class-3 3 : section 18.3 Class 3 compliant resource

]]>

DAV access-control access-control : section 7.2 WebDAV ACL

]]>

DAV version-control version-control : section 3 WebDAV DeltaV

]]>

DAV extended-mkcol extended-mkcol : section 3.1 Extended mkcol

]]>

DAV quota DAV quotas. May not apply to all resources. Absence of this feature implies no support on any resource.

]]>

DAV sync-collection Collection synchronization report. May not apply to all resources. Absence of this feature implies no support on any resource.

]]>

DAV add-member Using POST to add a member to a collection. May not apply to all resources. Absence of this feature implies no support on any resource.

]]>

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.

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.