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: ( Use: ds!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 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 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: 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