Re: A question on Versioning-unaware clients
jamsden@us.ibm.com
Thu, 7 Oct 1999 20:49:10 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256804.00049D6E.00@d54mta03.raleigh.ibm.com>
Date: Thu, 7 Oct 1999 20:49:10 -0400
Subject: RE: A question on Versioning-unaware clients
As noted below, the interoperability was achieved through undocumented
inplementation details. This will not work for WebDAV because we want the
protocol to allow resource access through many repository managers, not just the
file system. Servers are free to implement ftp and/or http access to their
repository managers or underlying implementations, and advertise this protocol
interoperability. But nothing the the protocol or WebDAV (or ftp) semantics
should ever depend or rely on this.
So I think if protocol interoperability is desired, build ftp on top of WebDAV,
or build both protocols on top of some repository. Should we consider how ftp
could be built on WebDAV? Maybe, but there's always the option to build it
directly on top of the repository manager independently of WebDAV. Since we
can't predict what these repositories might be, we can't and probably don't need
to worry too much about this kind of interoperability.
"Som Bandyopadhyay" <SBANDYO@novell.com> on 10/07/99 06:13:50 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: RE: A question on Versioning-unaware clients
While I strongly agree with Chris on this issue, I remember strong opposition
from everyone in this group to consider this interoperability. For you
reference, the old email is attached.
Also its true there is nothing in FTP or HTTP protocol which make them to
interoperate, but its undocumented implementation story that all of them go
thru' a common file systems interface which makes it work.
In case of versioning, this won't be so trivial. Look at the examples given in
the original email. One implementor may choose to select one option and another
implementor does something different. This will have bad effect on versioning.
Even after all those mail exchanges ( few months back ), I still feel we should
consider the interoperability story in this draft itself.
thanks, som.
[ Some old emails attached only FYI ].
>>> "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com> 10/07/99 11:49AM
>>>
I just think we will avoid a lot of trouble down the road if we
address this early.
Chris
-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Thursday, October 07, 1999 10:39 AM
To: Chris Kaler (Exchange); ietf-dav-versioning@w3.org
Subject: RE: A question on Versioning-unaware cl
<chris>
It is a question of interoperability with existing protocols.
Today, HTTP and FTP (for example), interoperate.
</chris>
<tim expression="puzzled">
Just humor me for a moment...
HTTP and FTP don't interoperate. Nothing written using HTTProtocol has
anything to do with FTProtocol.
I admit, that they typically share the same files on a disk and thereby
share data, so you can 'put' with FTP and 'get' with HTTP, but that's not
the protocols interoperating, that's merely a shared disk.
</tim>
<chris>
When the HTTP portion supports WebDAV versioning,
there is now an interop problem. Although this is outside
of the scope of this effort, I think we will avoid lots of
questions and problems down the road if specify an
interop story. The one I proposed seems simple and
not burdensome on the server.
</chris>
<tpe>
I agree that adding in versioning means that it is very unlikely that the
server will store resources in a file structure that would be meaningful to
an FTP user.
. but I could write a VxD to make it look like a file system, and no you
wouldn't have versioning commands in FTP, but then again you don't have POST
and HEAD either!
I feel that I'm either missing the point, being pedantic, or perhaps I'm
just out to lunch<g>
</tpe>
Received: from prv-mx.provo.novell.com by prv-mail25.provo.novell.com; Tue, 03
Aug 1999 18:01:56 -0600
Received: from www19.w3.org by prv-mx.provo.novell.com; Tue, 03 Aug 1999
18:00:58 -0600
Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA17176;
Tue, 3 Aug 1999 19:53:48 -0400 (EDT)
Resent-Date: Tue, 3 Aug 1999 19:53:48 -0400 (EDT)
Resent-Message-Id: <199908032353.TAA17176@www19.w3.org>
Message-Id: <s7a72ca6.099@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 03 Aug 1999 17:53:35 -0600
From: "SOM Bandyopadhyay" <SBANDYO@novell.com>
To: <ietf-dav-versioning@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id TAA17156
Subject: A question on Versioning-unaware clients
Resent-From: ietf-dav-versioning@w3.org
X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/263
X-Loop: ietf-dav-versioning@w3.org
Sender: ietf-dav-versioning-request@w3.org
Resent-Sender: ietf-dav-versioning-request@w3.org
Precedence: list
In draft-ietf-webdav-versioning-02 its mentioned that
"Webdav versioning includes:
automatic versioning support for versioning-unaware clients"
My question is:
1. Is this applicable to versioning-unaware clients which is accessing the file
system thru' non-HTTP methods ( e.g. FTP )?
If yes, then:
1.1 Do we expect all FTP servers ( and others ) to talk to the versioning
component?
I don't think that will be acceptable solution at all..
If no, then:
1.2 how does this work? If a versioning-aware client did a CHECKOUT on a file
and versionig-unaware-non-HTTP client wants to open the file in "read-write"
mode? Will this operation fail?
Whatever is the case, spec is very unclear here....
thanks, som.
"These are absolutely my opinion. My opinion
do not represent those of my employer"
Received: from prv1-mx.provo.novell.com by prv-mail20.provo.novell.com; Wed, 04
Aug 1999 16:10:30 -0600
Received: from www19.w3.org by prv1-mx.provo.novell.com; Wed, 04 Aug 1999
16:09:23 -0600
Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA15379;
Wed, 4 Aug 1999 18:08:49 -0400 (EDT)
Resent-Date: Wed, 4 Aug 1999 18:08:49 -0400 (EDT)
Resent-Message-Id: <199908042208.SAA15379@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: ietf-dav-versioning@w3.org
MMDF-Warning: Parse error in original version of preceding line at
paris.ics.uci.edu
Date: Wed, 4 Aug 1999 15:05:18 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJOEIMCCAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <s7a72e2a.017@prv-mail25.provo.novell.com>
Importance: Normal
Subject: RE: A question on Versioning-unaware clients
Resent-From: ietf-dav-versioning@w3.org
X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/267
X-Loop: ietf-dav-versioning@w3.org
Sender: ietf-dav-versioning-request@w3.org
Resent-Sender: ietf-dav-versioning-request@w3.org
Precedence: list
> In draft-ietf-webdav-versioning-02 its mentioned that
>
> "Webdav versioning includes:
>
> automatic versioning support for versioning-unaware clients"
>
> My question is:
>
> 1. Is this applicable to versioning-unaware clients which is
> accessing the file system thru' non-HTTP methods ( e.g. FTP )?
Actually, versioning-unaware clients are HTTP/DAV clients that don't
understand the versioning specification. Its outside of our scope to
consider authoring via FTP.
However, I can imagine a server that, in addition to implementing DeltaV, it
also implements FTP, and as an implementation decision, performs automatic
versioning for FTP writes. But, this doesn't affect the Delta-V or FTP
protocol -- it's an implementation decision for the server.
> 1.1 Do we expect all FTP servers ( and others ) to talk to the
> versioning component?
This is an implementation decision, but I'd expect most FTP/DAV server
combos to not provide automatic versioning for FTP resources.
>
> I don't think that will be acceptable solution at all..
>
> If no, then:
>
> 1.2 how does this work? If a versioning-aware client did a
> CHECKOUT on a file and versionig-unaware-non-HTTP client wants to
> open the file in "read-write" mode? Will this operation fail?
There are several choices here:
a) do a second checkout (allow parallel development)
b) fail the second checkout (allow only single line of development)
> Whatever is the case, spec is very unclear here....
We should certainly say which choice we make... (i.e., we need to fix this
in the spec.)
- Jim
Date: Wed, 04 Aug 1999 17:09:44 -0600
From: "SOM Bandyopadhyay" <SBANDYO@novell.com>
To: <ejw@ics.uci.edu>, <ietf-dav-versioning@w3.org>
Subject: RE: A question on Versioning-unaware clients
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Jim,
Considering co-existence between Delta-V and another existing file transfer
protocol ( e.g. FTP ) is our goal of versioning....there are some
possibilities:
Possibility a:
I have something to say about your comment "it's an implementation decision for
the server." In this example, if FTP server chooses not to go thru' versioning
mechanism, then it may allow its clients( I mean FTP clients ) to modify the
file ( on which a versioning client has done a CHECKOUT operation ). This will
result in data corruption.
So this way, FTP & Delta-V will not be interoperable. Interoperability with
existing file transfer protocols must be our goal.
So this can not be left for implementation.
Possibility b:
[ your comment was: b) fail the second checkout (allow only single line of
development) ]
To provide the co-existence: CHECKOUT also performs some native lock semantics
on the file. e.g in case of CHECKOUT , do a WRITE LOCK on the file thru' common
file system interfaces. ( in that case, versioning spec has to include this
semantics of CHECOUT ).
A FTP client then can not open the file for write purpose. Is this what we
expect everyone to implement?
Possibility c:
Versioning component in server sits below the "common file system
interfaces"...I mean, all access to file system from various clients ( e.g. FTP,
HTTP+versioning, HTTP only, ....) will go thru' the versioning component. This
is the only way one can do parallel development...
I feel this is the best ....Should this be included in the spec?
thanks, som.
>>> Jim Whitehead <ejw@ics.uci.edu> 08/04/99 04:08PM >>>
> In draft-ietf-webdav-versioning-02 its mentioned that
>
> "Webdav versioning includes:
>
> automatic versioning support for versioning-unaware clients"
>
> My question is:
>
> 1. Is this applicable to versioning-unaware clients which is
> accessing the file system thru' non-HTTP methods ( e.g. FTP )?
Actually, versioning-unaware clients are HTTP/DAV clients that don't
understand the versioning specification. Its outside of our scope to
consider authoring via FTP.
However, I can imagine a server that, in addition to implementing DeltaV, it
also implements FTP, and as an implementation decision, performs automatic
versioning for FTP writes. But, this doesn't affect the Delta-V or FTP
protocol -- it's an implementation decision for the server.
> 1.1 Do we expect all FTP servers ( and others ) to talk to the
> versioning component?
This is an implementation decision, but I'd expect most FTP/DAV server
combos to not provide automatic versioning for FTP resources.
>
> I don't think that will be acceptable solution at all..
>
> If no, then:
>
> 1.2 how does this work? If a versioning-aware client did a
> CHECKOUT on a file and versionig-unaware-non-HTTP client wants to
> open the file in "read-write" mode? Will this operation fail?
There are several choices here:
a) do a second checkout (allow parallel development)
b) fail the second checkout (allow only single line of development)
> Whatever is the case, spec is very unclear here....
We should certainly say which choice we make... (i.e., we need to fix this
in the spec.)
- Jim
Received: from prv-mx.provo.novell.com by prv-mail25.provo.novell.com; Thu, 05
Aug 1999 11:37:27 -0600
Received: from www19.w3.org by prv-mx.provo.novell.com; Thu, 05 Aug 1999
11:36:13 -0600
Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15135;
Thu, 5 Aug 1999 13:33:10 -0400 (EDT)
Resent-Date: Thu, 5 Aug 1999 13:33:10 -0400 (EDT)
Resent-Message-Id: <199908051733.NAA15135@www19.w3.org>
Message-Id: <s7a9766c.050@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 05 Aug 1999 11:32:55 -0600
From: "SOM Bandyopadhyay" <SBANDYO@novell.com>
To: <ejw@ics.uci.edu>, <dbarrell@opentext.com>, <ietf-dav-versioning@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id NAA15115
Subject: RE: A question on Versioning-unaware clients
Resent-From: ietf-dav-versioning@w3.org
X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/270
X-Loop: ietf-dav-versioning@w3.org
Sender: ietf-dav-versioning-request@w3.org
Resent-Sender: ietf-dav-versioning-request@w3.org
Precedence: list
- In my email FTP was taken as an example protocol. I never asked to consider
FTP within the scope of Delta-V work.
- Question was raised to consider "interoperability with existing file system
protocols"....since I see some serious drawbacks if we don't consider that.
(e.g. in one example semantics of CHECKOUT changes ).
thanks, som.
>>> Dylan Barrell <dbarrell@opentext.com> 08/05/99 01:28AM >>>
FTP is out of scope for this spec. Jim's statement is the correct one -
whether you choose to implement a, b or c is up to you.
Cheers
Dylan
On Thursday, August 05, 1999 1:10 AM, SOM Bandyopadhyay
[SMTP:SBANDYO@novell.com] wrote:
> Jim,
>
> Considering co-existence between Delta-V and another existing file
transfer protocol ( e.g. FTP ) is our goal of versioning....there are some
possibilities:
>
> Possibility a:
>
> I have something to say about your comment "it's an implementation
decision for the server." In this example, if FTP server chooses not to go
thru' versioning mechanism, then it may allow its clients( I mean FTP
clients ) to modify the file ( on which a versioning client has done a
CHECKOUT operation ). This will result in data corruption.
> So this way, FTP & Delta-V will not be interoperable. Interoperability
with existing file transfer protocols must be our goal.
> So this can not be left for implementation.
>
> Possibility b:
>
> [ your comment was: b) fail the second checkout (allow only single line
of development) ]
>
> To provide the co-existence: CHECKOUT also performs some native lock
semantics on the file. e.g in case of CHECKOUT , do a WRITE LOCK on the
file thru' common file system interfaces. ( in that case, versioning spec
has to include this semantics of CHECOUT ).
> A FTP client then can not open the file for write purpose. Is this what
we expect everyone to implement?
>
> Possibility c:
>
> Versioning component in server sits below the "common file system
interfaces"...I mean, all access to file system from various clients ( e.g.
FTP, HTTP+versioning, HTTP only, ....) will go thru' the versioning
component. This is the only way one can do parallel development...
> I feel this is the best ....Should this be included in the spec?
>
> thanks, som.
>
>
>
> >>> Jim Whitehead <ejw@ics.uci.edu> 08/04/99 04:08PM >>>
>
> > In draft-ietf-webdav-versioning-02 its mentioned that
> >
> > "Webdav versioning includes:
> >
> > automatic versioning support for versioning-unaware clients"
> >
> > My question is:
> >
> > 1. Is this applicable to versioning-unaware clients which is
> > accessing the file system thru' non-HTTP methods ( e.g. FTP )?
>
> Actually, versioning-unaware clients are HTTP/DAV clients that don't
> understand the versioning specification. Its outside of our scope to
> consider authoring via FTP.
>
> However, I can imagine a server that, in addition to implementing DeltaV,
it
> also implements FTP, and as an implementation decision, performs
automatic
> versioning for FTP writes. But, this doesn't affect the Delta-V or FTP
> protocol -- it's an implementation decision for the server.
>
> > 1.1 Do we expect all FTP servers ( and others ) to talk to the
> > versioning component?
>
> This is an implementation decision, but I'd expect most FTP/DAV server
> combos to not provide automatic versioning for FTP resources.
>
> >
> > I don't think that will be acceptable solution at all..
> >
> > If no, then:
> >
> > 1.2 how does this work? If a versioning-aware client did a
> > CHECKOUT on a file and versionig-unaware-non-HTTP client wants to
> > open the file in "read-write" mode? Will this operation fail?
>
> There are several choices here:
>
> a) do a second checkout (allow parallel development)
> b) fail the second checkout (allow only single line of development)
>
> > Whatever is the case, spec is very unclear here....
>
> We should certainly say which choice we make... (i.e., we need to fix
this
> in the spec.)
>
> - Jim
>
Received: from prv1-mx.provo.novell.com by prv-mail25.provo.novell.com; Thu, 05
Aug 1999 12:36:37 -0600
Received: from www19.w3.org by prv1-mx.provo.novell.com; Thu, 05 Aug 1999
12:35:29 -0600
Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17551;
Thu, 5 Aug 1999 14:32:41 -0400 (EDT)
Resent-Date: Thu, 5 Aug 1999 14:32:41 -0400 (EDT)
Resent-Message-Id: <199908051832.OAA17551@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: ietf-dav-versioning@w3.org
MMDF-Warning: Parse error in original version of preceding line at
paris.ics.uci.edu
Date: Thu, 5 Aug 1999 11:28:37 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJMEJJCCAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <s7a873df.088@prv-mail25.provo.novell.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: A question on Versioning-unaware clients
Resent-From: ietf-dav-versioning@w3.org
X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/272
X-Loop: ietf-dav-versioning@w3.org
Sender: ietf-dav-versioning-request@w3.org
Resent-Sender: ietf-dav-versioning-request@w3.org
Precedence: list
While I agree with Dylan (who was agreeing with me :-) that defining the
interactions between FTP and Delta-V is out of scope, I suspect Som isn't
the only person who will be having multiple protocols interacting with a
Delta-V store.
> Considering co-existence between Delta-V and another existing file
> transfer protocol ( e.g. FTP ) is our goal of versioning....there are
> some possibilities:
>
> Possibility a:
>
> I have something to say about your comment "it's an implementation
> decision for the server." In this example, if FTP server chooses not to
> go thru' versioning mechanism, then it may allow its clients( I mean FTP
> clients ) to modify the file ( on which a versioning client has done a
> CHECKOUT operation ). This will result in data corruption.
> So this way, FTP & Delta-V will not be interoperable. Interoperability
> with existing file transfer protocols must be our goal.
> So this can not be left for implementation.
I'd turn this around and say that, in this case, the implementation decision
was to have the FTP access bypass the versioning mechanism. As you point
out, this has some bad interactions with Delta-V clients, and hence it's an
undesirable design choice to have FTP acess bypass the versioning mechanism.
> Possibility b:
>
> [ your comment was: b) fail the second checkout (allow only single line
> of development) ]
>
> To provide the co-existence: CHECKOUT also performs some native lock
> semantics on the file. e.g in case of CHECKOUT , do a WRITE LOCK on the
> file thru' common file system interfaces. ( in that case, versioning
> spec has to include this semantics of CHECOUT ).
> A FTP client then can not open the file for write purpose. Is this
> what we expect everyone to implement?
This seem to me to be a consistent implementation of the specification. If
the underlying file is checked-out, then an FTP read operation should
succeed on the checked-out resource, but a write operation on the
checked-out resource would fail. I'd also expect an FTP delete to always
fail when operating on a versioned resource.
> Possibility c:
>
> Versioning component in server sits below the "common file system
> interfaces"...I mean, all access to file system from various clients (
> e.g. FTP, HTTP+versioning, HTTP only, ....) will go thru' the versioning
> component. This is the only way one can do parallel development...
> I feel this is the best ....Should this be included in the spec?
Having all accesses to the repository go through the same interface also
makes sense to me as an implementation choice. But, since the Delta-V
protocol is only concerned with how to express versioning and CM commands
sent across a network, and is not concerned with how a server implements
those commands (so long as their behavior is compliant with the
specification), this implementation choice shouldn't be included in the
protocol specification.
Occasionally working groups decide to produce implementation handbooks, that
detail some of these issues. But this is a separate document from the
protocol specification, which should be as agnostic as possible about
potential implementation strategies (judging from the HTTP/DAV experience,
people will implement the protocol in ways you have never imagined).
- Jim