Re: A question on Versioning-unaware clients
Som Bandyopadhyay (SBANDYO@novell.com)
Thu, 07 Oct 1999 16:13:50 -0600
Message-Id: <s7fcc68f.036@prv-mail20.provo.novell.com>
Date: Thu, 07 Oct 1999 16:13:50 -0600
From: "Som Bandyopadhyay" <SBANDYO@novell.com>
To: <ietf-dav-versioning@w3.org>
Subject: RE: A question on Versioning-unaware clients
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_471180FF.A7C6BB45
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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.=20
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 ].
=20
>>> "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]=20
Sent: Thursday, October 07, 1999 10:39 AM
To: Chris Kaler (Exchange); ietf-dav-versioning@w3.org=20
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=3D"puzzled">
Just humor me for a moment...
HTTP and FTP don't interoperate. Nothing written using HTTProtocol has=20
anything to do with FTProtocol.
I admit, that they typically share the same files on a disk and thereby=20
share data, so you can 'put' with FTP and 'get' with HTTP, but that's =
not=20
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=20
server will store resources in a file structure that would be meaningful =
to=20
an FTP user.
. but I could write a VxD to make it look like a file system, and no =
you=20
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=20
just out to lunch<g>
</tpe>
--=_471180FF.A7C6BB45
Content-Type: message/rfc822
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"
--=_471180FF.A7C6BB45
Content-Type: message/rfc822
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
--=_471180FF.A7C6BB45
Content-Type: message/rfc822
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:=20
[ 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
--=_471180FF.A7C6BB45
Content-Type: message/rfc822
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
>
--=_471180FF.A7C6BB45
Content-Type: message/rfc822
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
--=_471180FF.A7C6BB45--