WebDAV Issues

1
WebDAV Issues

• Munich IETF
• August 11, 1997

2
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!propna
  me)
• Use http//foo.com/DAV/(http!!www.ietf.org!stan
  dards!dav!propname)

3
Property URL encoding (contd)

• 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

4
Property URL encoding (contd)

• 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
  doesnt have to)

5
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

6
Retrieving properties (contd)

• 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 doesnt know the name of
  all properties defined on the resource
• A separate WG will address full-featured search

7
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

8
Property attributes (contd)

• 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 doesnt take up space for each
  property retrieval
• Removes issue of how to set live and readonly
  attributes they are established by the server

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

10
Recursion Semantics (contd)

• 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

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

12
Atomic locking of a collection (contd)

• 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

13
Atomic locking of a collection (contd)

• 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

14
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

15
Authoring Support for Language Variants (contd)

• 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 servers
  namespace conventions for relating language
  variants
• avoids providing capability for client to map
  variants to the resource on which negotiation
  takes place

16
Authoring Support for Language Variants (contd)

• 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 -- its
  just up to the user to discover the location of
  the variants