WebDAV Issues

Munich IETF

August 11, 1997

Property URL encoding

• At present, spec. allows encoding of the name of a property so it can be appended to the URL of the resource being described.

• Example: (http:!!www.ietf.org!standards!dav!propname)

• Use: http://foo.com/;DAV/(http:!!www.ietf.org!standards!dav!propname)

Property URL encoding (cont’d)

• Pro: removes need to discover the URL of a property instance, since it can be computed

• Con: – this is a URL munge

– CGI scripts may be confused by ;DAV/ parameter

– potential for namespace collisions

Property URL encoding (cont’d)

• Recommended solution– do not provide a standard URL encoding scheme

like ;DAV/ (but servers can support this if they wish)

– return URL of property as in the PropLoc attribute of the <Prop> tag (which is a container tag for a property description), if the server supports a mapping of properties to URLs (it doesn’t have to)

Retrieving properties

• At present, spec. defines a method called SEARCH which performs a limited search of the properties defined on a resource, and can search on the name and the value.

• Pro: allows retrieval of only specific properties• Con: there is no way to specify a set of resources on

which to perform the search -- cannot easy search a whole server (however, specifying a full-power search is really hard, and is out of scope)– search is an expensive operation

Retrieving properties (cont’d)

• Recommended solution– change name of SEARCH to PROPGET (or GETPROP or

FINDPROP), reserving SEARCH for a more full-powered search facility

– limit the capabilities of PROPGET to retrieving only named properties

– support only a wildcard “*” so that all properties on a resource are retrieved

• helpful if the client doesn’t know the name of all properties defined on the resource

• A separate WG will address full-featured search

Property attributes

• At present, the spec. defines two XML attributes, “live” and “readonly” which are used with the <Prop> tag to describe the characteristics of the property.

• Pro: returning the attributes with each property allows the behavior of a property to vary from resource to resource

• Con: live and readonly properties are typically the same across an entire server– passing these attributes takes up extra octets on the wire

Property attributes (cont’d)

• Recommended solution:– Do not return live and readonly attributes for every property

• semantics of live and readonly are per-server, not per-instance

– Instead, allow this information to be discovered for an entire server, using schema discovery

– The information is still available, but it must be discovered, and doesn’t take up space for each property retrieval

– Removes issue of how to set live and readonly attributes: they are established by the server

Recursion Semantics

• A present, the spec. defines a “Depth” header which can take the values “0”, “1” or “infinity” and which specifies the depth to which a method should be propagated when invoked on a collection (i.e., how many levels down the hierarchy tree?)

• Applies to COPY, MOVE, DELETE, LOCK, others...

Recursion Semantics (cont’d)

• Pro: a simple header states the limit of the action• Con: it is very difficult to specify the recursion

behavior of all functions• Recommended solution: move the specification of the

Depth header and recursion semantics to a separate specification– allows the main specification to continue without being held

back by quibbling over definition of recursion semantics– Saveen Reddy, Microsoft, has volunteered to be document

editor

Atomic locking of a collection

– The requirements spec. states:

5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock on multiple resources residing on the same server in a single action, and this locking operation must be atomic across these resources.

Atomic locking of a collection (cont’d)

• Pro:– prevents situation where more than one autor try to lock

a set of resources simultaneously, and all end up with some, but not all the locks they want.

• Con:– it is difficult to implement atomic locking behavior

within a server (appears to require transaction support)

– a LOCK method can only specify a single URI, so this would have to be satisfied with a collection of external member resources

Atomic locking of a collection (cont’d)

• Recommended solution:– Keep the requirement as-is, since there is wide

agreement on the need for the requirement

– Try to develop a means for satisfying this requirement in the specification

– Recognize that it may not be possible to satisfy this requirement, and move on

Authoring Support for Language Variants

• At present, the spec. does not provide support for authoring language variants of a document (i.e., the same document content translated into a different natural language)

• Participants on the mailing list have requested the inclusion of this behavior

Authoring Support for Language Variants (cont’d)

• Recommended solution: do not add authoring support for language variants to the spec.– But remain open to proposals developed by the working group

for how to accomplish this capability.

• Pro: keeps spec. simple (KISS)– avoids complexity of interactions between variants and

versions– avoids complexity of discovering server’s namespace

conventions for relating language variants– avoids providing capability for client to map variants to the

resource on which negotiation takes place

Authoring Support for Language Variants (cont’d)

• Con: – spec. does not provide authoring support for language

variants, a standard HTTP capability

– reduces i18n support in spec.

• But note:– language variants can still be edited -- it’s just up to the

user to discover the location of the variants