Re: Our concerns

>I had said in my earlier message that I would be cataloging our concerns.

Thank you for raising these concerns.  Let me address them.

>ISSUE 1
>
>For a protocol that attempts to describe distributed authoring and
>versioning, there is no description of what version naming scheme *must* be
>supported.
>
>Response
>
>Since there are many ways of naming versions, supporting one is not an option
>
>Reposte
>
>This stops the protocol from supporting inter-operation between clients,
>proxies, and servers developed from independent sources to inter-operate.

I remain unconvinced that having no standard version naming scheme will
lead to a lack of interoperability between WebDAV clients.  You have
certainly given no example of how such a problem would manifest itself.

If you have a naming scheme which states that "1.1" must be followed by
"1.2" (for example), the information this conveys is "the version named 1.2
succeeds the version named 1.1" and "the version named 1.1 preceeds the
version named 1.2."  In other words, the version identifiers encode the
predecessor and successor relationships.  Since there are many version
naming schemes supported by versioning systems, it makes more sense to
require interoperability for the pred/succ relationships than to mandate a
particular naming scheme.

>ISSUE 2
>
>The current protocol does not allow multiple versions to be active at the
>same time hence stoping the use of configuration management.

I think the current versioning draft is too underspecified to address this
point, although I don't really understand what you mean by "active".

> And, there is
>no way to specify that the same version is active in different
>configurations at the same time.

There are currently no plans to support configurations (which I define to
be versioned collections of versioned resources) within WebDAV.  Support
will only be provided for managing the revisions of a single resource.
However, the versioning support should not preclude the future development
of configuration support.


>ISSUE 3
>
>The current protocol does not allow the clients to inform the servers the
>current context (also sometimes refered to as the environment in
>cooperative transaction processing literature). This prevents us from
>implementing long term, cooperative transactions on top of the version
>control mechanism envisaged in WEB-DAV
>
>Response:
>
>The transaction protocol being worked in W3C and IETF will address this
>requirement
>
>Reposte:
>
>Duh! What we are asking for is different. Do we need to explain this or
>refer you folks to several papers that describe the concept of
>environments/contexts in cooperative transaction processing.

The working group has decided on many occasions not to pursue transaction
support.  To consider adding such a requirement, you need to resolve
several questions: What features do you want to support with this context
information?  Why do we need to have WebDAV clients and servers supporting
this information?  Why are cookies insufficient?

Perhaps posting the papers references you mentioned would help me to better
understand your position.  Right now all I'm hearing is "we gotta have it"
without (to my mind) really understanding either "it" or why it is so
necessary.

>ISSUE 4
>
>There are several weeknesses in the current concurrency control proposal
>which stops us from implementing robust and effcient concurrency control
>mechanisms.
>
>4.1 When an operation fails, the client has to continuously poll the server
>to execute that operation again. This increases network traffic.

Typically, if a human is taking out the lock, and the lock fails, they will
examine the ownership information for the current lock, and begin some
out-of-band negotiation over access to the resoure.  For the case where a
machine is initiating the lock, polling might occur.  Given that there is
*no support* within HTTP for sending asynchronous notifications to clients,
this leves two options: 1) have failed locks immediately return a failure
status, allowing the client to decide what to do next, or 2) perhaps a
header could be added to the request, causing the connection to be left
open, with the servecr retrying the lock request, timing-out after some
period of time.  At present, the spec. reflects option #1, since it is much
simpler than #2.  Option #2 only makes sense to me if the locks are being
held for a short period of time (~seconds), and there is significant
potential contention for locks (lots of clients requesting the same lock),
since only in this case would it be much less efficient to pursue option
#1.

>4.3 No notion of notification when some action is performed

If you can show me how to provide asynchronous notifications using
HTTP/1.1, I'll write a proposal for adding lock notification support to the
spec.

>4.4 While the lock extension mechanism is general there is no standard way
>to describe the lock mechanisms that are implemented

Lock discovery (Section 5.6 of draft-ietf-webdav-protocol-00.txt) is
intended to address this point.


>ISSUE 5
>
>Current proposal does not explicitly state the role of proxies in the
>WEB-DAV protocol
>
>Response:
>
>The current protocol assumes that all operation except INDEX is dealt by
>the origin server.
>
>Reposte
>
>This assumption stops us from implementing distributed, replicated servers
>that may pre-fetch or cache information for efficiency
>
>Solution
>
>Two mutually exclusive proposals
>
>1. Spend the time specifying the behavior of proxies (particularly
>replicating/cacheing proxies)
>
>2. Allow PEP to be used to experiment with approaches that will work for
>synchronization between replicated/cached copies and when a successful
>approach is developed add it to the standard

Which WebDAV operations would you like have handled by a proxy, and what
data would you like to have the ability to replicate?  The very notion of a
lock assumes a single point of control, so I don't see how locking can be
implemented by proxies unless we also specify a server-to-server protocol,
which is out of scope.  Similarly, what does it mean to do a COPY or a MOVE
on a proxy?  What happens if two different MOVE methods are applied to the
same resource on two different caches at the same time (what should the
state of the origin server be?)  Perhaps we could do a better job for
caching of non-live property information, but otherwise I don't really see
what better cache support we could provide.  What did you have in mind?

>ISSUE 6
>
>In the proposal for collection there is no way to determine if a resource
>is *not* a collection

Please see section 3.3.5.4 of draft-ietf-webdav-protocol-00.txt

>ISSUE 7
>
>The current meta data proposal is appropriate for simple file system based
>version stores that exchange attribute-value pair information, but is not
>easily extensible for version stores that are databases
>
>Response
>
>A rich meta data mechanism adds payload and processing requirement for
>simple version control system
>
>Reposte
>
>Lacking a formal way for other types of stores to participate results in
>this protocol being a non extensible system
>
>Solution
>
>Perhaps have two different tags. One that deals with the current meta data
>proposal and one that deal with a richer meta data language such as
>XML-Data or MCF or RDF (whatever that is)

I'm a bit confused here.  Judging by your previous posts, I think you're
arguing in favor of support for MCF/RDF and XML.  MCF/RDF is simply a set
of XML tags which have some predefined semantics.  A server which supports
the storage of XML by definition supports the definition of MCF/RDF.  This
support is provided by allowing a sequence of 8bit octets to be stored.
Supporting XML doesn't preclude support for MCF/RDF.

The current spec. proposes that the value of all properties be XML
documents.  This XML document can potentially use RDF defined tags, which
can potentially be processed by an RDF-capable client or server.  Or it may
not use RDF tags, in which case it is simply an XML document which does not
use any of the RDF defined tags.

- Jim

Received on Wednesday, 23 July 1997 17:34:08 UTC