W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Interoperability and client support of options

From: Juergen Reuter <reuter@ira.uka.de>
Date: Sat, 10 Feb 2001 03:05:55 +0100
To: lisa <lisa@xythos.com>
cc: reuter@ira.uka.de, ietf-dav-versioning@w3.org
Message-ID: <"iraun1.ira.0089901:010210.020559"@ira.uka.de>
> 1) Is anybody planning to implement a client that will interoperate
> against a CORE server, not requiring any advanced options to be there at
> all?

One of the intentions of the protocol is that versioning-unware clients
will interoperate against any DeltaV server, including a core server
without any advanced options at all.

Of course, if you want to write a server that is intended to support a
serious number of different clients, then you probably will have to
implement some of the options.

> 3) Is anybody planning to use NONE OF these options:
>  - working resource option
>  - client workspace option
>  - Workspace option

As for clients, same answer as for 1), i.e. (at least) any
versioning-unware client.

> In other words, is anybody planning to expose the results of
> work-in-progress, on the VCR, to all clients doing read operations?

If I understand you correctly, this is a different question, because even
fully-fledged clients may (e.g. by the user's choice) decide not to use
any of the above options.  So, actually, the answer must always be yes
for any combination of a server and client.

> 4) Can a client that does the checkout option but not the "working
> resource" option operate against servers with the "Working Resource"
> option?

Yes, but it can only work on the resource that is checked out under the
URL of the VCR, since it does not know the URLs of the working resources.

> 5) Can a client that doesn't know about the UPDATE option interoperate
> with VCRs that have had UPDATE applied to them?

Yes, but if the server does not allow forking at the selected version,
the client can not create a new version until another proper update is

>  - what happens if the client does not support this option but the
> server does,

The client then simply does not use the option.  But it may possibly not
be able to handle resources that have been created/modified by different
clients that use that option (such as accessing working resources or
creating a new version on an updated VCR where forking is not allowed).

>  - what happens if the client supports this option but the server does
> not,

The server must reject the according request.  The client should explore
the server's capabilities via the OPTIONS method before requesting any
optional behaviour.

>  - whether clients that do not support this option can interact with
> clients that do support this option (I mean, whether both kinds of
> clients can do operations freely on the same set of resources, on a
> server that does support the option).

In general, no (cp. again 4) and 5)).

>  - If a server implements this option at all, the client must ALSO
> implement this option in order to interoperate.

I would regard such a constraint as a bug in the protocol, since a
server option never might enforce the client to implement anything.

>  - This option is only used when the client requests it.  The server
> that implements this option MUST also support the case where the client
> does NOT request this option, in order to interoperate with clients that
> do not support this option.

I think this just describes some general requirements of a
'server option'; it should always be that way.

>  - A VCR on which this option has been used (e.g. UPDATE) MUST
> interoperate with clients that are unaware of the option.

That is something that you almost never can achieve in general; see for
example the above answers on 4) and 5).  The problem here is, that you
implicitly want to have interoperability between different clients that
use different options.  This is only possible if you can map complex
options on simpler requirements.  For example, HTTP defines an optional
header that allows to GET only a range of bytes from a document.  This
can be mimicked by the more simple required GET without this header by
getting the whole document and throwing away all the data that is not

>  - If any clients on a system use this option (e.g. Merge), whether
> clients that do not understand the option (e.g. Merge) will be able to
> use the resources on the system.

In the case of Merge, yes; in general (e.g. working resources, update) no.

Received on Friday, 9 February 2001 21:06:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC