From w3c-dist-auth-request@www10.w3.org  Mon Feb  1 11:54:25 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA07671
	for <w3c-dist-auth@www19.w3.org>; Mon, 1 Feb 1999 11:54:25 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA14863
	for <w3c-dist-auth@w3.org>; Mon, 1 Feb 1999 11:54:23 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA23929;
	Mon, 1 Feb 1999 11:54:18 -0500 (EST)
Message-Id: <199902011654.LAA23929@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
>From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 01 Feb 1999 11:54:18 -0500
Sender: cclark@ns.cnri.reston.va.us
Subject: I-D ACTION:draft-ietf-webdav-versioning-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: Versioning Extensions to WebDAV
	Author(s)	: C. Kaler, J. Amsden, G. Clemm,  B. Cragun,
                          D. Durand, B. Sergeant, J. Whitehead
	Filename	: draft-ietf-webdav-versioning-01.txt
	Pages		: 45
	Date		: 29-Jan-99
	
       This document specifies a set of methods, headers, and content-
       types composing DAV Versioning extensions, an application of the
       HTTP/1.1 protocol to version DAV resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-versioning-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-versioning-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-versioning-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990129142224.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-versioning-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-versioning-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990129142224.I-D@ietf.org>

--OtherAccess--

--NextPart--



From w3c-dist-auth-request@www10.w3.org  Mon Feb  1 19:06:44 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA14048
	for <w3c-dist-auth@www19.w3.org>; Mon, 1 Feb 1999 19:06:44 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id TAA19848
	for <w3c-dist-auth@w3.org>; Mon, 1 Feb 1999 19:06:42 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29532;
          1 Feb 99 15:02 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 1 Feb 1999 15:00:22 -0800
Message-ID: <002e01be4e36$a678fce0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: New interim collections requirements draft

A new, interim revision of the Advanced Collections requirements draft is
now available off the WebDAV web site, at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollReqts031.txt

A change history is available at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/ReqtHistory.txt

Although these documents are primarily for the use of participants in the
advanced collections conference calls, comments on these, or any WebDAV
drafts are welcome on the mailing list.

- Jim


From w3c-dist-auth-request@www10.w3.org  Mon Feb  1 22:56:30 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA15931
	for <w3c-dist-auth@www19.w3.org>; Mon, 1 Feb 1999 22:56:30 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id WAA21341
	for <w3c-dist-auth@w3.org>; Mon, 1 Feb 1999 22:56:28 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id TAA25648
	for <w3c-dist-auth@w3.org>; Mon, 1 Feb 1999 19:55:13 -0800 (PST)
Message-Id: <4.1.19990201165831.00a25ca0@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 01 Feb 1999 19:54:54 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Max Rible <max@glyphica.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

This looks fundamentally quite good; it covers all the versioning
scenarios I've ever encountered and more.  Kudos to the authors
who must have put in some very long hours on it!

***

My biggest issue with the new draft of the versioning standard
is the usage of gibberish temporary URIs where a user might have
to cope with them or a system administrator might have to clean them
up.  Are there any actual cases where temporaries are actually 
required, as opposed to a gibberish token that can be used in
relation to a comprehensible URI?

I'm thinking usability here:  if incomprehensible, unmemorable temporary 
names are being used in WebDAV, it should be easy to make the usage 
[a] seamless from the point of view of the end user and [b] straightforward 
for the system administrator who will inevitably have to clean up
the incomprehensibly named files cluttering the temporary area.
Is the intention here that a client program would use PROPFIND
to locate all these obscurely named resources?  That all such
resources have a lifetime and will automatically be reaped?

There is a certain utility to having the magic files in a magic
directory for ease of implementation-- you know you only have to
treat a file in a special way if it's in a special location.  In
my opinion, if you've already done the necessary work to make MKREF function,
the additional amount needed to support checked-out files and
configurations going anyplace should be small.

***

Is there a major flaw with the notion of CHECKOUT creating a locked, 
mutable, non-autoversioned revision that the user holding the lock can 
mutate arbitrarily until a CHECKIN is performed, at which point the 
revision's name changes from a placeholder to a version number?  
(i.e.  
CHECKOUT /foo/bar.html HTTP/1.1
Host: www.foobar.com
...

returns

HTTP/1.1 201 Created
Location: /foo/bar.html
Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

and the combination of URI and Revision-Id can then be used for any
number of PUT and PROPPATCH operations.  When the user says

CHECKIN /foo/bar.html HTTP/1.1
Host: www.foobar.com
Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>
...

the current version is frozen, given a non-temporary name (such as "1.2.1"),
and the lock is released.  If they UNCHECKOUT that URI/revision-id
configuration, the revision quietly goes away.

***

The same thing applies to configurations:  do they need to exist
in special areas?  Couldn't they be a part of a user's home
directory on a server?  Direct references would make it possible
to give the illusion of a configuration in your home directory, but
now you have issues regarding cleaning up a user's files when
moving their home directory from one machine to another or removing
it entirely.

***

Is a configuration so different from a collection that it should be
treated as a separate sort of entity?  It looks like a collection
that has a special sort of name (the configuration ID) and holds
nothing but MKREF-created links to particular versions of files.
(An aside:  should it be possible to use MKREF to link to a 
particular version of a file, allowing the reference to provide the 
Revision-Id or Configuration-Id header to a client who knows nothing 
of them?)  Are there any fundamental differences that would make
it difficult to consider a configuration as a collection with
some added rules and functionality?

Should configurations be able to contain other configurations, or
simply references to them?  I can easily see that a configuration's
user might wish to partition it when it gets large and cluttered.

I'm thinking of software development solutions:  a configuration might
represent a project, with subconfigurations containing subprojects.
You'd want automatic inheritance from the core project so any time
someone else added a file to the configuration, you got a reference
to it.  A large project with a couple of dozen subprojects would
otherwise be a pain to bring into a workspace, unless you had a
development tool that dealt with all the repetetive actions for you.
(Direct references to other configurations could be used to 
provide the illusion of nested configurations, but would require
a lot of transactions make the parent configuration and then each
child configuration inheriting from the originals.)

Might there occasionally be call for having non-reference members of
a configuration?  I could easily see a checkin set that has no other
reason for existence than its membership in a workspace.

***

Regarding the specification of the BRANCH command:

Why was the decision made to use 

       BRANCH VER:FHHR4959 HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

instead of 

       BRANCH /foo/bar.html HTTP/1.1
	Revision-Id: VER:FHHR4959
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

?

The current method makes for a great deal of extra work, and seems
inconsistent with the other usages in the specification.  Without
this, revision IDs need only be unique for a given resource; now, they
must be unique across an entire server.  I was originally expecting
that a lot of "Revision-Id" headers would be exactly the same as the
version number in your source control system; requiring revision ID's
to be unique across all files would make the raw data less readable
to human beings.  (This should also be called out explicitly in
2.10.1, which only specified that it must identify a specific
revision of a given resource.)

This also creates a complication for developers attempting to
implement the WebDAV standard.  If the WebDAV functionality is provided
as a plug-in module for an existing web server, that server might 
wind up doing some extra work in attempting to resolve a rather
mysterious URI-- lacking a leading slash, it might reject it 
entirely.  (Netscape Enterprise Server 3.5.1, for instance, will
immediately return 404 Not Found without even talking to plugins
registered for the method used.)  Granted, this isn't illegal by
the HTTP 1.1 standard, but it could certainly delay the progress
of WebDAV until the server technology has a chance to catch up.
If there's no strong reason to go with BRANCH revision-id, I
suggest switching to BRANCH uri.

***

There has also been a massive growth in the number of available DAV
properties.  PROPFIND allprop operations may lead to very large
responses even with Depth: 1, which would slow down performance
for users due to network speeds.  It might be worthwhile to add this
facet to the open issue ALLPROP_AND_COMPUTED.

***

I presume that the results of asking for DAV:defaulthistory,
DAV:activecheckouts, DAV:directlineage, and DAV:fulllineage
should *not* be included in a PROPFIND allprop response?  Also, don't
the new PROPPATCH parameters violate WebDAV spec 12.9.1, since an
identical DAV:href is turning up in multiple DAV:response
tags under the same DAV:multistatus?  (It's probably worth just
making an addendum to the WebDAV spec in the grammar section.)

***

Regarding SETDEFAULT:  why is it specified as sending an XML body?
It it seems that 
	SETDEFAULT uri HTTP/1.1
	Revision-Id: DAV:none
is equivalent to the request with a body and consistent with
other usages in the specification.  Are there other data that
may be used with SETDEFAULT at some point?

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 05:20:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19886
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 05:20:40 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id FAA23756
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 05:20:36 -0500 (EST)
Received: from tantalum by gw.atria.com id <FAA03901@gw.atria.com> Tue, 2 Feb 1999 05:20:35 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA24625; Tue, 2 Feb 1999 05:20:35 -0500
Date: Tue, 2 Feb 1999 05:20:35 -0500
Message-Id: <9902021020.AA24625@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: w3c-dist-auth@w3.org
Subject: COPY vs. MOVE on advanced collection references

I promised Adv. Coll. design team I'd start a thread on this topic,

The expected semantics of MOVE is that I end up with the same stuff
at some new location, and even a hope that appropriate references to
the old stuff ends up pointing at the new stuff (i.e. that business
about updating things between the COPY and the DELETE).

The expected semantics of COPY is that I end up with a different
object, so that I can modify one copy and have it not affect the other.

Now let's look at what a MOVE on a reference should be.  It's pretty
clear that you just want to have a copy of the source reference created
at the destination.  If you look at how both hard-links and sym-links
are implemented in file systems, this is exactly what happens.

But now let's look at what a COPY on a reference should be.  
If you just make a copy of the reference, then any PUT to the
source object will cause a modification visible in a GET to the
destination object, and vica versa.  This is the opposite behavior
from what one would expect from a "copy", and seems to violate
the whole point of differentiating a "MOVE" from a "COPY".

One alternative is to revisit the definition of MOVE as a kind
of COPY.  Part of me says that is the right choice, since many
(or even most) systems treat MOVE as a "rename", not as a copy
followed by a delete, i.e. it is a change to the namespace, not
to the object being moved.  This means that the current definition
will keep getting us into trouble (as I believe it will in the
case of locking a collection), since it forces the server to treat
a cheap operation (rename) as an expensive operation (a recursive
create, followed by a recursive delete).  It's like forcing every
"mv" to be a "tar" followed by an "rm -r".

On the other hand, for simple resources and simple collections, the
current definition works reasonably well, so it would be worth trying
hard to find an alternative that does not re-open the existing spec.
One such alternative would be to say that the COPY automatically
invoked by a MOVE is "no-passthrough" by default (i.e. like DELETE),
while an explicit COPY is passed through references (i.e. like a GET
or a PUT, whose behavior we want to affect).  This does "override" the
original spec, but only when applied to references, which is probably
more acceptable, since references are after all being defined in the
Adv. Coll. spec.

Either alternative is fine with me.

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 09:14:48 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA25372
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 09:14:48 -0500 (EST)
Received: from smtp4.server.ibm.com (smtp4.ny.us.ibm.com [198.133.22.43])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA25536
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 09:14:46 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp4.server.ibm.com (8.8.7/8.8.7) with ESMTP id JAA62172
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 09:00:12 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id JAA79388
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 09:14:39 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525670C.004E3B6C ; Tue, 2 Feb 1999 09:14:30 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525670C.004E393B.00@D51MTA07.pok.ibm.com>
Date: Tue, 2 Feb 1999 09:17:31 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: COPY vs. MOVE on advanced collection references



> I promised Adv. Coll. design team I'd start a thread on this topic,

Thank you Geoff.  I'm in the middle of a similar note but keep on getting
distracted by work.  :-)


> The expected semantics of MOVE is that I end up with the same stuff
> at some new location, and even a hope that appropriate references to
> the old stuff ends up pointing at the new stuff (i.e. that business
> about updating things between the COPY and the DELETE).

I agree.


> The expected semantics of COPY is that I end up with a different
> object, so that I can modify one copy and have it not affect the other.

Yup. I agree.


> Now let's look at what a MOVE on a reference should be.  It's pretty
> clear that you just want to have a copy of the source reference created
> at the destination.  If you look at how both hard-links and sym-links
> are implemented in file systems, this is exactly what happens.

I tend to agree.


> But now let's look at what a COPY on a reference should be.
> If you just make a copy of the reference, then any PUT to tthe
> source object will cause a modification visible in a GET to the
> destination object, and vica versa.  This is the opposite behavior
> from what one would expect from a "copy", and seems to violate
> the whole point of differentiating a "MOVE" from a "COPY".

I don't necessarily agree here.  What I expect (or at least want)
depends on what I'm doing at the time.  I think I'd tend to expect
the reference to be copied.  I don't think my disagreement
here really detracts from what you're saying though.



> One alternative is to revisit the definition of MOVE as a kind
> of COPY.  Part of me says that is the right choice, since many
> (or even most) systems treat MOVE as a "rename", not as a copy.
> ...
> "mv" to be a "tar" followed by an "rm -r".

I agree.

We should look through the old discussions to see what reasons they had for
this.  (I started this in my unfinished note.) I recall one was MOVE
between servers.  That's not really a compelling argument for me and I
believe that it was suggested at one point that if the move is between
servers, then a COPY/DELETE would get done... otherwise, what you suggest.
Anyway, I'm suggesting going through those discussions again to see what we
can learn.


> Either alternative is fine with me.
I prefer the right solution over the expedient.  We should not be
encouraging the view that MOVE is a COPY/DELETE... except where necessary.
Let's review old postings to see what situations we need to cover.

Thanks again for bringing this up.

J.



From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 09:59:44 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA26682
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 09:59:44 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA26076
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 09:59:42 -0500 (EST)
Received: from tantalum by gw.atria.com id <JAA18136@gw.atria.com> Tue, 2 Feb 1999 09:59:38 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA24777; Tue, 2 Feb 1999 09:59:35 -0500
Date: Tue, 2 Feb 1999 09:59:35 -0500
Message-Id: <9902021459.AA24777@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ccjason@us.ibm.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <8525670C.004E393B.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: COPY vs. MOVE on advanced collection references


I hate to snip out all the sections where we agreed (:-), but for the
sake of brevity, I'll just skip to the one section which raised a question:

   From: ccjason@us.ibm.com

   GMC> The expected semantics of COPY is that I end up with a different
   GMC> object, so that I can modify one copy and have it not affect the other.

   Yup. I agree.

OK, I left in one "I agree", but I need this one for context (:-).

   GMC> But now let's look at what a COPY on a reference should be.
   GMC> If you just make a copy of the reference, then any PUT to tthe
   GMC> source object will cause a modification visible in a GET to the
   GMC> destination object, and vica versa.  This is the opposite behavior
   GMC> from what one would expect from a "copy", and seems to violate
   GMC> the whole point of differentiating a "MOVE" from a "COPY".

   I don't necessarily agree here.  What I expect (or at least want)
   depends on what I'm doing at the time.

My turn to agree (:-).

   I think I'd tend to expect the reference to be copied.

The problem with copying just the reference shows up especially
vividly in a downlevel client (that doesn't even know about
references).  If I say "COPY", the key expectation that I can
now modify the copy-target without affecting the copy-source is violated.

The general rule I try to apply in these situations is:
If there are two reasonable things to do, so you need an extra parameter
(e.g. a header) do indicate which one you want, then have the
default be the one that does what a downlevel client would expect,
and have the presence of the header mean to "do the other thing".

In the case of "COPY" applied to a reference, this would seem to
say that the reasonable thing that the downlevel client would
expect (i.e. a copy of the reftarget of the reference) should be the
default, and the other reasonable thing (i.e. a copy of the
reference itself) should be indicated by a header.  The "no-pass-through"
header immediately springs to mind.

Cheers,
Geoff




From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 11:17:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA27951
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 11:17:40 -0500 (EST)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA26783
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 11:17:38 -0500 (EST)
>From: jamsden@us.ibm.com
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA65458
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 11:17:02 -0500
Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35])
	by southrelay01.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id LAA64134
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 11:17:33 -0500
Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525670C.00597C1C ; Tue, 2 Feb 1999 11:17:24 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525670C.00597A77.00@d54mta03.raleigh.ibm.com>
Date: Tue, 2 Feb 1999 11:11:54 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: COPY vs. MOVE on advanced collection references



In many file systems, the implementation of move is different depending on
the source and targets. Windows for example does something different if the
move is within the same device or on a different device. UNIX is similar.
So maybe we need to just state the semantics of MOVE in WebDAV and not tie
it to a particular implementation, for example, the implementation implied
by COPY followed by DELETE. Then the semantics can be expressed in a
resource-dependent way if necessary including distinguishing references
from concrete resources as necessary to produce meaningful results.



From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 13:05:43 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA29753
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 13:05:43 -0500 (EST)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA27877
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 13:05:41 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id MAA48160
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 12:42:18 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id NAA31042
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 13:05:33 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525670C.00635C3E ; Tue, 2 Feb 1999 13:05:16 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525670C.00635A65.00@D51MTA07.pok.ibm.com>
Date: Tue, 2 Feb 1999 13:08:18 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: COPY vs. MOVE on advanced collection references


Geoff (& JimA)

> The problem with copying just the reference shows up especially
> vividly in a downlevel client (that doesn't even know about
> ...
> The general rule I try to apply in these situations is:
> If there are two reasonable things to do, so you need an extra
> parameter...

Sounds good.

Now to check the history of the decision to say MOVE == COPY+DELETE....

I've just done that.  I've found nothing in the earlier discussions besides
the mentioning of cross-server/device copy/move that might require
COPY/DELETE approach.  I think we've already dealt with that in this
thread.

In reading the spec, rather than just the mailing list, I see the WebDAV
spec isn't that far off.  It just needs to be clearer about intent.  It's
description COPY/DELETE isn't too bad depending on how you interpret it.
We probably should leave a bit less for interpretation though.  I think
that's what JimA just suggested when he spoke of semantics vs.
implementation.


J.



From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 14:42:29 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA01025
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 14:42:29 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA28820
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 14:42:28 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <D8W1GMY1>; Tue, 2 Feb 1999 11:42:29 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757C90@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>, w3c-dist-auth@w3.org
Date: Tue, 2 Feb 1999 11:42:25 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: COPY vs. MOVE on advanced collection references


The question of what does COPYing a link mean is an interesting one.  It has
been a while since I used UNIX, so I don't recall how copy behaves.
However, on Windows, if you copy a link then you have copied the link.
Saves to the link go to the original file.  This seems really intuitive to
me because the link has a glyphette that differentiates the link from the
original.

On the other side of the coin, it is not unreasonable to expect the "share
and branch" semantics that VSS provides.  That is, you copy and when you
update you sever the link.

I guess my initial feeling is that COPYing a link does just that and if we
want to have a "copy on write" semantics, then we use a separate method or
special form of COPY.

Chris


From w3c-dist-auth-request@www10.w3.org  Tue Feb  2 15:10:12 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01655
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Feb 1999 15:10:12 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA29067
	for <w3c-dist-auth@w3.org>; Tue, 2 Feb 1999 15:10:10 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <D8V4M5G3>; Tue, 2 Feb 1999 12:10:09 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757C91@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Max Rible'" <max@glyphica.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 2 Feb 1999 12:10:07 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Comments below...

-----Original Message-----
>From: Max Rible [mailto:max@glyphica.com]
Sent: Monday, February 01, 1999 7:55 PM
To: WEBDAV WG
Subject: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt


This looks fundamentally quite good; it covers all the versioning
scenarios I've ever encountered and more.  Kudos to the authors
who must have put in some very long hours on it!

[CK] Thanks!

***

My biggest issue with the new draft of the versioning standard
is the usage of gibberish temporary URIs where a user might have
to cope with them or a system administrator might have to clean them
up.  Are there any actual cases where temporaries are actually 
required, as opposed to a gibberish token that can be used in
relation to a comprehensible URI?

[CK] The point of using "giberish" in the draft is to reinforce
     that the server determines the value.  A server could make it
     giberish or something else.  One limitation we have is the
     strong reluctance in IETF to "munge" URLs.

I'm thinking usability here:  if incomprehensible, unmemorable temporary 
names are being used in WebDAV, it should be easy to make the usage 
[a] seamless from the point of view of the end user and [b] straightforward 
for the system administrator who will inevitably have to clean up
the incomprehensibly named files cluttering the temporary area.
Is the intention here that a client program would use PROPFIND
to locate all these obscurely named resources?  That all such
resources have a lifetime and will automatically be reaped?

[CK] I think it is important to remember that these are protocol-level
     resources.  I would assume that the UI on top of the protocol hides
     all this.  For example, you "checkout" and "checkin" based on the
     resource name you desire.  The working copy resource is part of the
     implementation and isn't visible to the user.  As well, there is
     always the DAV:displayname property.

[CK] That is really a per-server administrative function.  A server may
     choose, for example, to put all working copies in /tmp/wc.  As well,
     they might choose to have a lifetime.  Although that is dangerous 
     because many systems support long-running checkouts.  Especially if
     the checkout doesn't involve a lock.  That is, it will merge on
     check-in.

There is a certain utility to having the magic files in a magic
directory for ease of implementation-- you know you only have to
treat a file in a special way if it's in a special location.  In
my opinion, if you've already done the necessary work to make MKREF
function,
the additional amount needed to support checked-out files and
configurations going anyplace should be small.

[CK] The general idea was that this is up to the server.  A "checkout"
     request returns the location/URL which is managed by the server.

***

Is there a major flaw with the notion of CHECKOUT creating a locked, 
mutable, non-autoversioned revision that the user holding the lock can 
mutate arbitrarily until a CHECKIN is performed, at which point the 
revision's name changes from a placeholder to a version number?  
(i.e.  
CHECKOUT /foo/bar.html HTTP/1.1
Host: www.foobar.com
...

returns

HTTP/1.1 201 Created
Location: /foo/bar.html
Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

and the combination of URI and Revision-Id can then be used for any
number of PUT and PROPPATCH operations.  When the user says

CHECKIN /foo/bar.html HTTP/1.1
Host: www.foobar.com
Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>
...

the current version is frozen, given a non-temporary name (such as "1.2.1"),
and the lock is released.  If they UNCHECKOUT that URI/revision-id
configuration, the revision quietly goes away.

[CK] I don't think so.  The idea is that a CHECKOUT creates a working copy.
     Technically this is not part of the revision graph for the resource.
     It must be mutable because clients need to be able to make multiple
     changes.  You can't version it because it isn't part of the version
     graph.  It is just a scratch space where PUTs and PROPPATCHs can be
     performed until the resource is ready.  CHECKIN then assigns a revision
     id and makes it part of the graph.  Working copies don't have revision
     ids.  Also, UNCHECKOUT cancels a CHECKOUT.  You can't issue UNCHECKOUT
     once you've issued a CHECKIN.  The draft should be clearer on this
point.

***

The same thing applies to configurations:  do they need to exist
in special areas?  Couldn't they be a part of a user's home
directory on a server?  Direct references would make it possible
to give the illusion of a configuration in your home directory, but
now you have issues regarding cleaning up a user's files when
moving their home directory from one machine to another or removing
it entirely.

[CK] The idea here was to put them in a unified place so that standard
     DAV discovery mechanisms can be used.  Otherwise we need to add
     new methods to discover the configurations.  These would be exactly
     the same as the normal folder discovery mechanism, just under a 
     new name.  We could do that -- we were just trying to use existing
     DAV semantics where appropriate.

***

Is a configuration so different from a collection that it should be
treated as a separate sort of entity?  It looks like a collection
that has a special sort of name (the configuration ID) and holds
nothing but MKREF-created links to particular versions of files.
(An aside:  should it be possible to use MKREF to link to a 
particular version of a file, allowing the reference to provide the 
Revision-Id or Configuration-Id header to a client who knows nothing 
of them?)  Are there any fundamental differences that would make
it difficult to consider a configuration as a collection with
some added rules and functionality?

[CK] Configurations are very similar, but also very different.  A
     configuration collection can be referenced in the Configuration-Id
     header.  That is not true of all MKREF collections.  As well, changes
     to the resources in the context of a configuration are automatically
     represented inside the configuration collection.  That is, if I
     rename foo.htm to bar.htm using MOVE in the /c/1 configuration, then
     inside /c/1 there will be a reference to bar.htm.

Should configurations be able to contain other configurations, or
simply references to them?  I can easily see that a configuration's
user might wish to partition it when it gets large and cluttered.

[CK] This is a really interesting question.  Conceptually, why not?
     However, that is really hard to represent in the resources.  As
     well, some of the semantics start to get really messy.  What does
     it mean to have nested configurations?  What does it mean for a
     resource to be "in" nested configurations.  We opted to say that a
     configuration can be derived from another, but there isn't a notion 
     of containment.

I'm thinking of software development solutions:  a configuration might
represent a project, with subconfigurations containing subprojects.
You'd want automatic inheritance from the core project so any time
someone else added a file to the configuration, you got a reference
to it.  A large project with a couple of dozen subprojects would
otherwise be a pain to bring into a workspace, unless you had a
development tool that dealt with all the repetetive actions for you.
(Direct references to other configurations could be used to 
provide the illusion of nested configurations, but would require
a lot of transactions make the parent configuration and then each
child configuration inheriting from the originals.)

[CK] Another way to think of this is that the collections in the
     namespace represent the project and sub-project relationships
     and that configurations represent various "releases" of those
     projects.  In this way the "V2" configuration can be derived
     from the "V1" configuration.

Might there occasionally be call for having non-reference members of
a configuration?  I could easily see a checkin set that has no other
reason for existence than its membership in a workspace.

[CK] The idea here was that configurations are a way of grouping resources
     that exist in the DAV namespace.  Our thoughts were that you have
     resources and make them part of configurations.  That is /foo/bar.htm
     is a resource whose revisions might be part of zero or more
configurations.
     But /foo/bar.htm exists to DAV on its own and isn't a sub-element of
     a configuration.  Not to say your idea isn't good -- I'm just trying
     to explain our thinking here.

***

Regarding the specification of the BRANCH command:

Why was the decision made to use 

       BRANCH VER:FHHR4959 HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

instead of 

       BRANCH /foo/bar.html HTTP/1.1
	Revision-Id: VER:FHHR4959
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

?

The current method makes for a great deal of extra work, and seems
inconsistent with the other usages in the specification.  Without
this, revision IDs need only be unique for a given resource; now, they
must be unique across an entire server.  I was originally expecting
that a lot of "Revision-Id" headers would be exactly the same as the
version number in your source control system; requiring revision ID's
to be unique across all files would make the raw data less readable
to human beings.  (This should also be called out explicitly in
2.10.1, which only specified that it must identify a specific
revision of a given resource.)

This also creates a complication for developers attempting to
implement the WebDAV standard.  If the WebDAV functionality is provided
as a plug-in module for an existing web server, that server might 
wind up doing some extra work in attempting to resolve a rather
mysterious URI-- lacking a leading slash, it might reject it 
entirely.  (Netscape Enterprise Server 3.5.1, for instance, will
immediately return 404 Not Found without even talking to plugins
registered for the method used.)  Granted, this isn't illegal by
the HTTP 1.1 standard, but it could certainly delay the progress
of WebDAV until the server technology has a chance to catch up.
If there's no strong reason to go with BRANCH revision-id, I
suggest switching to BRANCH uri.

[CK] This is something I should have made clearer.  Both are valid.
     The VER:... notion is used to refer to a specific revision via
     a URI.  You can also specify the URL and the Revision-Id header.
     Chalk this up to a bad example.

***

There has also been a massive growth in the number of available DAV
properties.  PROPFIND allprop operations may lead to very large
responses even with Depth: 1, which would slow down performance
for users due to network speeds.  It might be worthwhile to add this
facet to the open issue ALLPROP_AND_COMPUTED.

[CK] This is an excellent point.  It seems reasonable to use properties,
     but live vs. dead selection is interesting and DAV:allprop is
     becoming a very expensive operation.

***

I presume that the results of asking for DAV:defaulthistory,
DAV:activecheckouts, DAV:directlineage, and DAV:fulllineage
should *not* be included in a PROPFIND allprop response?  Also, don't
the new PROPPATCH parameters violate WebDAV spec 12.9.1, since an
identical DAV:href is turning up in multiple DAV:response
tags under the same DAV:multistatus?  (It's probably worth just
making an addendum to the WebDAV spec in the grammar section.)

[CK] The idea here is that you want a separate DAV:response for
     each DAV:href.  If you place DAV:defaulthistory inside of 
     the DAV:prop, you'd get a different response.  I'll take a
     look at the DAV spec again.

***

Regarding SETDEFAULT:  why is it specified as sending an XML body?
It it seems that 
	SETDEFAULT uri HTTP/1.1
	Revision-Id: DAV:none
is equivalent to the request with a body and consistent with
other usages in the specification.  Are there other data that
may be used with SETDEFAULT at some point?

[CK] The idea was to allow the user to specify additional information
     as well as allow the DAV:none to cancel.  We could do this all 
     through headers, but XML seemed appropriate.

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%

[CK] Thanks for the feedback.  We really appreciate you taking the 
     time to read and comment.  We have a working group meeting next
     week and I'll make sure we talk about the issues you have raised
     here.  Thanks again!


From w3c-dist-auth-request@www10.w3.org  Wed Feb  3 18:15:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA03733
	for <w3c-dist-auth@www19.w3.org>; Wed, 3 Feb 1999 18:15:34 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA13176
	for <w3c-dist-auth@w3.org>; Wed, 3 Feb 1999 18:15:32 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id PAA07351;
	Wed, 3 Feb 1999 15:13:19 -0800
Sender: gstein@lyra.org
Message-ID: <36B8D80E.3928FF75@lyra.org>
Date: Wed, 03 Feb 1999 15:13:18 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: w3c-dist-auth@w3.org, dav-announce@lyra.org, dav-dev@lyra.org
CC: new-httpd@apache.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: ANN: www.webdav.org now online

Hello fellow DAV people...

   http://www.webdav.org/ is now online!


webdav.org is intended to be a central resource for the DAV community.
It contains my DAV FAQ, a list of relevant specifications, some papers
about DAV, useful links, and a list of DAV projects.

For people who wish to be an editor/maintainer for a section of the
site, I am quite willing to provide DAV access (of course! :-). Jim
Whitehead will be managing the Working Group area on webdav.org, using
Joe Orton's sitecopy tool.

webdav.org is also available for hosting projects (web pages and a
distribution point) and mailing lists with an associated web archive.
Please contact me if you would like to host your DAV-related project
and/or mailing list at webdav.org.

Lastly, if you simply have suggestions for some content, then please
feel free to email me.


I hope everyone will find webdav.org useful!

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Wed Feb  3 19:18:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05331
	for <w3c-dist-auth@www19.w3.org>; Wed, 3 Feb 1999 19:18:51 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id TAA13662
	for <w3c-dist-auth@w3.org>; Wed, 3 Feb 1999 19:18:50 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa02654;
          3 Feb 99 16:16 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Wed, 3 Feb 1999 16:14:04 -0800
Message-ID: <001101be4fd3$45e6cd00$d115c380@galileo.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 8.5, Build 4.71.2173.0
In-Reply-To: <36B8D80E.3928FF75@lyra.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: www.webdav.org now online


> Hello fellow DAV people...
>
>    http://www.webdav.org/ is now online!
>
>
> webdav.org is intended to be a central resource for the DAV community.
> It contains my DAV FAQ, a list of relevant specifications, some papers
> about DAV, useful links, and a list of DAV projects.

Thank you Greg for taking the lead in producing the webdav.org site!  I
think it's a great step forward in bridging the gap between the community of
protocol developers within the IETF working group, and the rapidly emerging
development and user communities.

I'd also like to take this opportunity to call for volunteers to help Greg,
both to help out with the webdav.org site, and also to assist in the
development of mod_dav, the Apache WebDAV module.  In my view, having both
healthy open source and commercial development communities is crucial to the
adoption of WebDAV by a broad audience.

So,

* if you're a programmer, and could spare some time to work on or test
mod_dav functionality
* if you're a Web site designer, and want to work on webdav.org
* if you're a programmer in languages such as Java, C, C++, Python, Tcl and
others, and you'd like to develop an API for WebDAV for that language
* you have a great idea for a WebDAV application, and want to work with
others to make it a reality
* if there's an existing project (like Joe Orton's sitecopy, or UCI's WebDAV
Explorer) that you'd like to help work on

then...

I heartily encourage you to get in contact with Greg Stein <greg@lyra.org>,
or myself <ejw@ics.uci.edu>, so we can put you in contact with others who
are interested in the same thing, and so we can get your interest or project
up on webdav.org.

Many hands *do* make light work, and right now as interest in WebDAV is
ramping up, your individual contributions can make a big difference.

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu Feb  4 11:25:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA15908
	for <w3c-dist-auth@www19.w3.org>; Thu, 4 Feb 1999 11:25:34 -0500 (EST)
Received: from gandalf.digicool.com (jfulton.erols.com [207.96.8.119])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA20222
	for <w3c-dist-auth@w3.org>; Thu, 4 Feb 1999 11:25:31 -0500 (EST)
Received: by GANDALF with Internet Mail Service (5.5.1960.3)
	id <1H2RMS3P>; Thu, 4 Feb 1999 11:33:10 -0500
Message-ID: <613145F79272D211914B0020AFF64019FD48@GANDALF>
>From: Brian Lloyd <Brian@digicool.com>
To: "'Greg Stein'" <gstein@lyra.org>
Cc: new-httpd@apache.org, w3c-dist-auth@w3.org,
        Jim Fulton
	 <jim.fulton@digicool.com>,
        Paul Everitt <Paul@digicool.com>
Date: Thu, 4 Feb 1999 11:33:09 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Subject: RE: www.webdav.org now online

> Hello fellow DAV people...
> 
>    http://www.webdav.org/ is now online!
> 
> 
> webdav.org is intended to be a central resource for the DAV community.
> It contains my DAV FAQ, a list of relevant specifications, some papers
> about DAV, useful links, and a list of DAV projects.
> ...
> Greg Stein, http://www.lyra.org/
> 

Great news! We are currently working on DAV support for Zope,
our open source web object publishing environment. I hope to 
have a prototype that includes at least basic class 1 support
ready soon so that we can get into interoperability testing.

Synergy with Apache is important to us as many Zope users 
run one or more Zope installations in the url namespaces of
their existing Apache servers, so we'll definitely be putting
some time into testing peaceful co-existence with mod_dav. Let
me know if there are particular things we can do to help the
mod_dav effort on this front.

Once I have the prototype ready, we'd be happy to put an 
installation on webdav.org for folks to beat on and test
against. I'll also work on getting a overview of Zope WebDAV 
support up on the www.zope.org site that can be listed in
webdav.org's projects area.





Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 


From w3c-dist-auth-request@www10.w3.org  Thu Feb  4 17:14:04 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA10188
	for <w3c-dist-auth@www19.w3.org>; Thu, 4 Feb 1999 17:14:04 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA24845
	for <w3c-dist-auth@w3.org>; Thu, 4 Feb 1999 17:14:03 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa01211;
          4 Feb 99 14:02 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 4 Feb 1999 14:00:20 -0800
Message-ID: <001b01be5089$c258e560$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Minutes from Feb. 2, 1999 Adv. Col. Conference Call

The minutes from the February 2, 1999 Advanced Collections conference call
are now available on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990202.txt

Thanks to Judy Slein for capturing these minutes so quickly.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri Feb  5 18:24:58 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01199
	for <w3c-dist-auth@www19.w3.org>; Fri, 5 Feb 1999 18:24:58 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA07909
	for <w3c-dist-auth@w3.org>; Fri, 5 Feb 1999 18:24:56 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id PAA22898
	for <w3c-dist-auth@w3.org>; Fri, 5 Feb 1999 15:22:18 -0800 (PST)
Message-Id: <4.1.19990202133529.00a54500@shell7.ba.best.com>
Message-Id: <4.1.19990202133529.00a54500@shell7.ba.best.com>
Message-Id: <4.1.19990202133529.00a54500@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Feb 1999 15:21:46 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Max Rible <max@glyphica.com>
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757C91@RED-MSG-52>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

At 12:10 2/2/99 -0800, Chris Kaler wrote:
>[CK] The point of using "giberish" in the draft is to reinforce
>     that the server determines the value.  A server could make it
>     giberish or something else.  One limitation we have is the
>     strong reluctance in IETF to "munge" URLs.

Is there a document describing what the IETF folks mean when they
describe "mungeing" URLs?  The image that comes to mind is tacking
on decorations like # and ? with information after them, or creating
extra namespaces like the ones for configurations and checked-out
files.

I see a URI as a three-dimensional phenomenon-- taking us through
a space dimensioned by machine/protocol/port combinations (each unique
one defining a plane), directories (the vertical aspect of the plane,
if you consider the directory hierarchy unfolded completely) and files 
in directories (the horizontal aspect of the plane, with files as
chains following folders).  

Versioning adds a new dimension.  I see the headers as allowing us to add 
that new dimension (version number, etc.) to the URI, rather than trying 
to map the fourth dimension into other parts of the plane (which is
what a temporary file created for checkin/checkout purposes is).  
Since headers such as Revision-Id are already in use to provide that 
fourth dimension for accessing concrete versions, using them to 
access temporaries seems to me the least work to implement and the most 
consistent.  Of course, having eight different things happen depending on 
three different headers you might or might not send could be precisely what 
the IETF considers URL mungeing.

>[CK] I think it is important to remember that these are protocol-level
>     resources.  I would assume that the UI on top of the protocol hides
>     all this.  For example, you "checkout" and "checkin" based on the
>     resource name you desire.

For sufficiently general values of "based on", yes. :-)  The current
document gives the example of CHECKIN /tmp/VRJHJWE3493409 HTTP/1.1,
which makes no reference to the resource name involved.

As long as the user thinks they're checking in to the usual location,
it doesn't really matter, but things in the underlying implementation
have a way of percolating up to the user's view of the world.  It
also makes life easier for watching the requests as a programmer
or administrator.

>                                The working copy resource is part of the
>     implementation and isn't visible to the user.  As well, there is
>     always the DAV:displayname property.

Perhaps checked-out temporaries should have a property that
points at their original document and version?  Or should the
lineage report suffice for that purpose?

[re:  my idea for CHECKOUT/CHECKIN/UNCHECKOUT]

>[CK] I don't think so.  The idea is that a CHECKOUT creates a working copy.
>     Technically this is not part of the revision graph for the resource.
>     It must be mutable because clients need to be able to make multiple
>     changes.  You can't version it because it isn't part of the version
>     graph.  It is just a scratch space where PUTs and PROPPATCHs can be
>     performed until the resource is ready.  CHECKIN then assigns a revision
>     id and makes it part of the graph.  Working copies don't have revision
>     ids.  Also, UNCHECKOUT cancels a CHECKOUT.  You can't issue UNCHECKOUT
>     once you've issued a CHECKIN.  The draft should be clearer on this
>     point.

Sorry; I should've been clearer.  (It does seem pretty obvious that 
you can't UNCHECKOUT once you've done a CHECKIN; I probably just
flubbed the language.)  I meant to suggest:

1.  "CHECKOUT uri" returns 200 OK and gives you a token instead of
    201 Created and an URL.
2.  "PUT uri" and "PROPPATCH uri" with the token provided in the request
    header allow you to meddle with the working copy at uri to your 
    heart's content.  If uri isn't locked, there could conceivably
    be multiple such working copies, each accessed with different tokens.
3a. "CHECKIN uri" with the token would check in the working copy with
    a proper revision ID, release any locks you have on the original uri
    (unless you explicitly request to keep the locks), and lose all
    record of the token; alternatively,
3b. "UNCHECKOUT uri" with the token would remove the working copy, all
    record of its token, and any locks you had on it.

The token could be passed as a Revision-Id of some particular sort, if
you treat working copies as mutable revisions, or in some other fashion.

>The same thing applies to configurations:  do they need to exist
>in special areas?  [...]

>[CK] The idea here was to put them in a unified place so that standard
>     DAV discovery mechanisms can be used.  Otherwise we need to add
>     new methods to discover the configurations.

They could always exist as normal residents of the namespace who
happen to have a DAV:resourcetype of DAV:configuration-- they could
sit there next to collections and ordinary files.  (Once references
are implemented, I don't see it as that much more trouble to do
other special entities.)

[An aside:  we've been doing a lot of hammering on a very similar
notion over here at Glyphica for our next product, which is intended
to be WebDAV-compliant, and the "configurations" from the versioning
draft sound a lot like the "projects" we've been debating over here.
After much hammer-and-tongs haranguing about the natures of projects, 
we settled on the notion that a project would have a lot of links but 
could own entities in its own right, in order to simplify matters
of hierarchy.  I'm trying to figure out if a project is likely to 
*be* a configuration or *use* a configuration.  The example in the
versioning goals isn't much different from labeling a source tree,
which you can do with a BRANCH operation in this specification.
Were there any other examples that you folks used in coming up with
what a configuration should be able to do?]

>From an object-oriented point of view, I'm thinking of configurations
as a subclass of collections with some added functionality.  Both
accept PROPFIND with a Depth header, both need to manage a bunch
of other entities when you use COPY and DELETE and MOVE.  A
Configuration-Id URI would tell the system where the configuration is,
so there doesn't need to be any central lookup location; putting
a collection that is not a configuration in the Configuration-Id
header should generate an error.

>[CK] Configurations are very similar, but also very different.  A
>     configuration collection can be referenced in the Configuration-Id
>     header.  That is not true of all MKREF collections.  As well, changes
>     to the resources in the context of a configuration are automatically
>     represented inside the configuration collection.  That is, if I
>     rename foo.htm to bar.htm using MOVE in the /c/1 configuration, then
>     inside /c/1 there will be a reference to bar.htm.

I'm not sure I got that.  Do you mean that 

MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /c/1/foo.htm
Destination: /c/1/bar.htm

works as expected, (/c/1/bar.htm is a reference to /potzrebie/foo.htm,
just like in a collection), or

MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /potzrebie/foo.htm
Destination:  /potzrebie/bar.htm

will update /c/1/foo.htm to point to /potzrebie/bar.htm?

>Should configurations be able to contain other configurations, or
>simply references to them?  I can easily see that a configuration's
>user might wish to partition it when it gets large and cluttered.

>[CK] This is a really interesting question.  Conceptually, why not?
>     However, that is really hard to represent in the resources.

More than a collection is?  I may be missing something here...

>                                                                  As
>     well, some of the semantics start to get really messy.  What does
>     it mean to have nested configurations?  What does it mean for a
>     resource to be "in" nested configurations.  We opted to say that a
>     configuration can be derived from another, but there isn't a notion 
>     of containment.

If a configuration is a collection with special attributes for how it
interacts with the configurations it derives from and that derive from
it, and containment is handled like any collection, does that open
any cans of worms?

>I'm thinking of software development solutions:  a configuration might
>represent a project, with subconfigurations containing subprojects.
>You'd want automatic inheritance from the core project so any time
>someone else added a file to the configuration, you got a reference
>to it. [...]

>[CK] Another way to think of this is that the collections in the
>     namespace represent the project and sub-project relationships
>     and that configurations represent various "releases" of those
>     projects.  In this way the "V2" configuration can be derived
>     from the "V1" configuration.

So you have:

1.  A bunch of actual files in a namespace, representing the source tree.
2.  A number of configurations, each representing a separate release of the
    code, with links into multiple levels of the source tree.
3.  Many more configurations, each depending on the release configurations,
    representing developer workspaces.

The developer would then use the actual URIs from (1) for dealing with
the files and personal (3) workspace as a header to to select the 
appropriate versions from (1), and seldom (if ever) actually see the 
contents of (3)?  (Logging in to a workspace becomes interesting:
how to choose from among a bunch of configurations?  

Thus, most WebDAV operations would not occur on configurations
directly.  All the PUTs and GETs and PROPPATCHes and LOCKs and 
UNLOCKs would happen using the URIs from (1) and the configuration
ID from (3).  The configuration would occasionally be added to
through MKREF and removed from via DELETE, but all of this would
happen behind the scenes.

This makes a big difference in my visualization of configurations.  The
impression I got from the document was that a user might want to create a
configuration in their home directory on a server and use that as their
local copy of the data in the source tree, that configurations would be
something that you navigated into just like a normal directory tree.

What I'm seeing now is something more like a lock token with a lot more
state packed into it.  A user would "log in" to a configuration and
begin sending the configuration-id header along with almost all
requests to the server.  This would provide a context for their
particular view of the source tree.

Could a user ever wind up being "logged in" to multiple configurations?

[re: BRANCH]

>[CK] This is something I should have made clearer.  Both are valid.
>     The VER:... notion is used to refer to a specific revision via
>     a URI.  You can also specify the URL and the Revision-Id header.
>     Chalk this up to a bad example.

Hopefully, the VER:... URI functionality will be optional?  Should there
be a way to discover this functionality through OPTIONS?

>>Regarding SETDEFAULT:  why is it specified as sending an XML body?

>[CK] The idea was to allow the user to specify additional information
>     as well as allow the DAV:none to cancel.  We could do this all 
>     through headers, but XML seemed appropriate.

What other information would go in with SETDEFAULT?  For that matter,
is SETDEFAULT really doing anything you couldn't with PROPPATCH?
If I'd read that SETDEFAULT functionality was to be implemented with
a live property named DAV:defualtversion, I wouldn't have blinked...

***

Another question that comes to mind:  why are there properties using
comma-separated lists (such as DAV:revisionlabel, DAV:mergedfrom, ...) 
instead of an XML representation of such a list?  I would think
	<D:revisionlabel>
	  <D:label>Beta test</D:label>
	  <D:label>Release</D:label>
	</D:revisionlabel>
would be more in keeping with the standard.

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Sun Feb  7 00:50:59 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA16417
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Feb 1999 00:50:59 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id AAA16439
	for <w3c-dist-auth@w3.org>; Sun, 7 Feb 1999 00:50:58 -0500 (EST)
Received: from tantalum by gw.atria.com id <AAA03834@gw.atria.com> Sun, 7 Feb 1999 00:50:54 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA27186; Sun, 7 Feb 1999 00:50:52 -0500
Date: Sun, 7 Feb 1999 00:50:52 -0500
Message-Id: <9902070550.AA27186@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: max@glyphica.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <4.1.19990201165831.00a25ca0@shell7.ba.best.com> (message from
	Max Rible on Mon, 01 Feb 1999 19:54:54 -0800)
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt


Max: A thoroughly excellent (and excellently thorough) review!

I'll respond to them in the context of "draft-clemm-webdav-versioning-00"
(mailed a bit ago to this mailing list, and available on the WebDAV
web site).  This will give a preview of some of the discussions that
will take place at the upcoming design meeting.

   From: Max Rible <max@glyphica.com>

   My biggest issue with the new draft of the versioning standard
   is the usage of gibberish temporary URIs where a user might have
   to cope with them or a system administrator might have to clean them
   up.

I agree.  I believe the argument to CHECKOUT, CHECKIN, and UNCHECKOUT
should always be a consistent human-comprehensible URL.

   Are there any actual cases where temporaries are actually 
   required, as opposed to a gibberish token that can be used in
   relation to a comprehensible URI?

I believe the client should not need to be aware of the location of
any such temporaries.

   There is a certain utility to having the magic files in a magic
   directory for ease of implementation-- you know you only have to
   treat a file in a special way if it's in a special location.  In
   my opinion, if you've already done the necessary work to make MKREF function,
   the additional amount needed to support checked-out files and
   configurations going anyplace should be small.

I agree.

   Is there a major flaw with the notion of CHECKOUT creating a locked, 
   mutable, non-autoversioned revision that the user holding the lock can 
   mutate arbitrarily until a CHECKIN is performed, at which point the 
   revision's name changes from a placeholder to a version number?  

I agree with the overall concept, i.e. CHECKOUT creates a mutable resource
at the specified URL, but I'd modify the following details:

I wouldn't want it to be a "revision" because this places excessive
constraints on the mutable resource.  In particular, a revision can
have only one descendent on a given branch, but you sometimes want to
allow a revision to have multiple CHECKOUT's to a given branch
(requiring a merge before any CHECKIN after the first).  But I don't
think that it being a "revision" was an essential part of your point.

Also, I would want the "lock" to be optional (I don't think the "lock"
mechanism scales well, and want it to be an optional part of the
versioning protocol).  Again, I believe this is not an essential part
of your point.

   (i.e.  
   CHECKOUT /foo/bar.html HTTP/1.1
   Host: www.foobar.com
   ...

I'd add an (optional) "Workspace:" header, which you can add to
indicate that you are checking out into a non-default workspace (a
Workspace is the resource that specifies how revision selection occurs
across the entire web-site, via a "revision-selection-rule" property).

   returns

   HTTP/1.1 201 Created
   Location: /foo/bar.html
   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

I'd omit the Location header (it's always created at the place
specified by the CHECKOUT).

The Revision-Id is no longer necessary, since you either are
checking out into the default workspace, or you are checking
out into a specific workspace.  In any case, your workspace
determines which version you see, so no Revision-Id's need
to be passed in requests or reponses.

And I'd just use the LOCK command following the CHECKOUT if I want a
LOCK, rather than bundling LOCK with CHECKOUT (I don't believe the
frequency of CHECKOUT warrants worrying about an extra LOCK method call in
this case).

   and the combination of URI and Revision-Id can then be used for any
   number of PUT and PROPPATCH operations.

I agree (replacing "Revision-Id" with "optional Workspace-Id").

   When the user says

   CHECKIN /foo/bar.html HTTP/1.1
   Host: www.foobar.com
   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>
   ...

   the current version is frozen, given a non-temporary name (such as "1.2.1"),
   and the lock is released.

Yes (replacing Revision-Id with optional Workspace-Id, and making the
Lock-Token optional, in case you checked it out without a lock).

   If they UNCHECKOUT that URI/revision-id
   configuration, the revision quietly goes away.

Yes (i.e. the "working-resource" goes away).

   The same thing applies to configurations:  do they need to exist
   in special areas?

In draft-clemm-webdav-versioning, configurations have a much more
constrained purpose (and definition) than in draft-ietf-webdav-versioning.
In particular, they are effectively the mechanism for defining an
immutable-revision of a tree of resources (rooted at some collection).
They can then be specified in the revision-selection-rule of a workspace to
cause the appropriate revisions to appear in that workspace at the
appropriate URL's.

To illustrate the characteristics of the more constrained definition,
I'll answer Max's questions as if they were asked about the more
constrained definition.

*** NOTE ***
Max would not have asked these questions about the more constrained
definition ... he would have known the answers given below!  But his
questions and suggestions are very good for illustrating why the
more constrained definition might be preferable.
*** END NOTE ***

   Couldn't they be a part of a user's home
   directory on a server?  Direct references would make it possible
   to give the illusion of a configuration in your home directory, but
   now you have issues regarding cleaning up a user's files when
   moving their home directory from one machine to another or removing
   it entirely.

Like other CM metadata such as a "branch" or a "label", you would not
normally expect to find one in your home directory.

   Is a configuration so different from a collection that it should be
   treated as a separate sort of entity?  It looks like a collection
   that has a special sort of name (the configuration ID) and holds
   nothing but MKREF-created links to particular versions of files.

This is a read-only collection (it is immutable), and it is just a flat
list of revision references, with machine-generated names, e.g.
mem1, mem2, mem3.  So it's nothing a human would ever directly use to find
a revision of a particular resource (but is *is* something that a
workspace could use to efficiently find such a revision).

   (An aside:  should it be possible to use MKREF to link to a 
   particular version of a file, allowing the reference to provide the 
   Revision-Id or Configuration-Id header to a client who knows nothing 
   of them?)  Are there any fundamental differences that would make
   it difficult to consider a configuration as a collection with
   some added rules and functionality?

The creation of a configuration is an optimized server-specific operation.
Although it always results in a (read-only) collection, its creation
and storage will depend on factors that would not allow direct
creation or modification by a client.

   Should configurations be able to contain other configurations, or
   simply references to them?  I can easily see that a configuration's
   user might wish to partition it when it gets large and cluttered.

Yes.

   I'm thinking of software development solutions:  a configuration might
   represent a project, with subconfigurations containing subprojects.

Yes.

   You'd want automatic inheritance from the core project so any time
   someone else added a file to the configuration, you got a reference
   to it.

This is something you handle with workspace revision-selection-rules,
not with configurations (you can't add or remove files from configurations,
a configuration is immutable).

   A large project with a couple of dozen subprojects would
   otherwise be a pain to bring into a workspace, unless you had a
   development tool that dealt with all the repetetive actions for you.

Yes.

   (Direct references to other configurations could be used to 
   provide the illusion of nested configurations, but would require
   a lot of transactions make the parent configuration and then each
   child configuration inheriting from the originals.)

I'm not quite sure what this means, but I'd probably agree with it
if I did (:-).

   Might there occasionally be call for having non-reference members of
   a configuration?  I could easily see a checkin set that has no other
   reason for existence than its membership in a workspace.

Everything in a configuration is a reference to something else
(either a revision or another configuration).  To make something be
an immediate member would complicate the semantics with no obvious
benefit.

   Regarding the specification of the BRANCH command:

   Why was the decision made to use 

	  BRANCH VER:FHHR4959 HTTP/1.1
	  Host: www.foobar.com
	  Content-Type: text/html
	  Content-Length: xxxx

   instead of 

	  BRANCH /foo/bar.html HTTP/1.1
	   Revision-Id: VER:FHHR4959
	  Host: www.foobar.com
	  Content-Type: text/html
	  Content-Length: xxxx

I agree that it should be the latter (except that a Workspace header
rather than a Revision-Id should be passed in).  I also prefer the
method name "CHECKOUT-NEW", since this method is useful for
non-branch based servers as well.

   There has also been a massive growth in the number of available DAV
   properties.  PROPFIND allprop operations may lead to very large
   responses even with Depth: 1, which would slow down performance
   for users due to network speeds.  It might be worthwhile to add this
   facet to the open issue ALLPROP_AND_COMPUTED.

I believe strongly that defining useful properties should take
precedence over any desire that ALLPROP should run fast.  I personally
would vote to just nuke ALLPROP as a mistake, but as long as
clients know to never use it, I suppose it doesn't do that much
harm.

   Regarding SETDEFAULT:  why is it specified as sending an XML body?
   It it seems that 
	   SETDEFAULT uri HTTP/1.1
	   Revision-Id: DAV:none
   is equivalent to the request with a body and consistent with
   other usages in the specification.  Are there other data that
   may be used with SETDEFAULT at some point?

I believe SETDEFAULT is unnecessary, once you have the notion of
a default workspace, and therefore should be removed from the protocol.

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Sun Feb  7 00:59:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA16549
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Feb 1999 00:59:26 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id AAA16474
	for <w3c-dist-auth@w3.org>; Sun, 7 Feb 1999 00:59:25 -0500 (EST)
Received: from tantalum by gw.atria.com id <AAA03888@gw.atria.com> Sun, 7 Feb 1999 00:59:25 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA27199; Sun, 7 Feb 1999 00:59:23 -0500
Date: Sun, 7 Feb 1999 00:59:23 -0500
Message-Id: <9902070559.AA27199@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <9902070550.AA27186@tantalum> (gclemm@tantalum.atria.com)
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt


Apologies for the bandwidth wastage, but one correction:

   From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>

   I'll respond to them in the context of "draft-clemm-webdav-versioning-00"
   (mailed a bit ago to this mailing list, and available on the WebDAV
   web site).  ...

The document, "draft-clemm-webdav-versioning-00" was not mailed to
this mailing list (i.e. w3c-dist-auth@w3.org), but rather to the
versioning mailing list (i.e. ietf-dav-versioning@w3.org).  But it
has been posted on the WebDAV web site.

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Sun Feb  7 03:31:57 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA17294
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Feb 1999 03:31:57 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id DAA16983
	for <w3c-dist-auth@w3.org>; Sun, 7 Feb 1999 03:31:55 -0500 (EST)
Received: from copper.parc.xerox.com ([13.0.208.21]) by alpha.xerox.com with SMTP id <52521(1)>; Sun, 7 Feb 1999 00:19:17 PST
>From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Max Rible" <max@glyphica.com>, "WEBDAV WG" <w3c-dist-auth@w3.org>
Date: Sun, 7 Feb 1999 00:18:33 PST
Message-ID: <000901be5272$73f77860$15d0000d@copper.parc.xerox.com>
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 8.5, Build 4.71.2173.0
In-Reply-To: <4.1.19990202133529.00a54500@shell7.ba.best.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

> At 12:10 2/2/99 -0800, Chris Kaler wrote:
> >[CK] The point of using "giberish" in the draft is to reinforce
> >     that the server determines the value.  A server could make it
> >     giberish or something else.  One limitation we have is the
> >     strong reluctance in IETF to "munge" URLs.
> 
> Is there a document describing what the IETF folks mean when they
> describe "mungeing" URLs?  The image that comes to mind is tacking
> on decorations like # and ? with information after them, or creating
> extra namespaces like the ones for configurations and checked-out
> files.

RFC 2396 establishes the syntax for URIs, and two classes:
those that follow a hierarchical syntax, and those for which
everything after the scheme is 'opaque'.

There isn't a clear document on the framework into which URIs
fit, but my personal view is that we have several roles:

a) supplying URIs for resources to be identified
b) receiving URIs inside content or protocols, and subsequently 
  attempting to contact the resources identified
c) resolving a URI to the resource it identifies

My personal view is that URIs should be completely opaque to
components that are engaged in (b), with two exceptions
 1) the (completely syntactic) "relative URI" computation
 2) the (completely syntactic) construction of new URIs
    based on query or form submission, by adding "?" and
    either query or form data.

WebDAV has expanded this, by allowing (requiring?) WebDAV clients
to interpret the syntax of hierarchical URIs as corresponding
to the WebDAV containment model.

In any case, 'mungeing' refers to semantic or syntactic
processing of URIs outside of the resolution process (c).

Requiring versioning clients to interpret, parse, and
reconstruct URIs to syntactically link between one
version of a resource and another would be outside of
these guidelines.

The guidelines are put into place in order to give maximum
flexibility to the origin servers which are serving the
URIs, to allow whatever mapping is necessary between the
URI syntax and the actual resource, in the back-end of
the resolution process.

Larry


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 00:35:33 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA25619
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 00:35:32 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id AAA22531
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 00:35:31 -0500 (EST)
Received: from tantalum by gw.atria.com id <AAA24934@gw.atria.com> Mon, 8 Feb 1999 00:35:31 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA27540; Mon, 8 Feb 1999 00:35:30 -0500
Date: Mon, 8 Feb 1999 00:35:30 -0500
Message-Id: <9902080535.AA27540@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: max@glyphica.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <4.1.19990202133529.00a54500@shell7.ba.best.com> (message from
	Max Rible on Fri, 05 Feb 1999 15:21:46 -0800)
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

   From: Max Rible <max@glyphica.com>

Note:
Indented lines with a ">" are from Chris Kaler.
Indented lines without a ">" are from Max.

   ... the "configurations" from the versioning
   draft sound a lot like the "projects" we've been debating over here.
   After much hammer-and-tongs haranguing about the natures of projects, 
   we settled on the notion that a project would have a lot of links but 
   could own entities in its own right, in order to simplify matters
   of hierarchy.

There are two very different notions of project currently in common use.

The first (and the one I prefer) is "a team of people working together
to produce a particular product" (e.g. a project as defined by the tool
"Microsoft Project").

The second is "a set of resources" (e.g. a project as defined by the
tool "Microsoft Visual Studio", although it appears likely that
Visual Studio will stop using the term in this way).

The major reason for this confusion probably stems from the common
simple case where a set of resources is worked on by only one team of
people.  In this case it is natural to associate the set of resources
with the team that is responsible for it.  Unfortunately, when life
gets more complicated and several teams work on the same set of
resources, significant confusion results from this ambiguous use
of the term project.

So I'd strongly recommend reserving the word "project" for the team of
people building a particular release of a product, and use some other
term (such as "component" or "package" or "subsystem") to refer to "a
set of resources".

In particular, I'll be using this definition of project in the rest of
this message.  I'll also be using the term "workspace" to refer to the
resource that specifies how version selection is done for client
requests, and the term "configuration" to refer to the resource that
is an immutable set of revisions (sometimes called a "baseline" or a
"checkpoint").

   I'm trying to figure out if a project is likely to 
   *be* a configuration or *use* a configuration.

A project (as defined above) would "use" a configuration (as defined above)
to capture a particular state of the project.  The "product" produced
by the project would be the final configuration produced by the project.
A project would also use a set of workspaces, some for developers working
on that project, others for system integrators, testers, and release engineers.

   >[CK] Configurations are very similar, but also very different.  A
   >     configuration collection can be referenced in the Configuration-Id
   >     header.  That is not true of all MKREF collections.  As well, changes
   >     to the resources in the context of a configuration are automatically
   >     represented inside the configuration collection.  That is, if I
   >     rename foo.htm to bar.htm using MOVE in the /c/1 configuration, then
   >     inside /c/1 there will be a reference to bar.htm.

Note: Chris uses the term "configuration" to cover both what I would call
a "workspace" and what I would call a "configuration".  I believe that it
is essential that we clearly separate these two concepts (although I'd
be happy to not use the term "configuration" for the latter, since "baseline"
and "checkpoint" are probably more commonly used terms for this concept).

   >Should configurations be able to contain other configurations, or
   >simply references to them?  I can easily see that a configuration's
   >user might wish to partition it when it gets large and cluttered.

   >[CK] This is a really interesting question.  Conceptually, why not?
   >     However, that is really hard to represent in the resources.

   More than a collection is?  I may be missing something here...

I think that it is hard to represent when it is a broadly defined concept.
When it is more narrowly defined (i.e. an immutable set of revisions),
then it is quite simply represented.

   >                                                                  As
   >     well, some of the semantics start to get really messy.  What does
   >     it mean to have nested configurations?  What does it mean for a
   >     resource to be "in" nested configurations.  We opted to say that a
   >     configuration can be derived from another, but there isn't a notion 
   >     of containment.

There are two senses of the term "derived" ... one which I am for,
and one which I am against.

The one I am "for" is a relationship between configurations, namely,
that you can select a configuration in a workspace, make some changes
in that workspace, and then create a new configuration.  I would then
say that the new configuration is a "descendent" of the original one
(in the same way that one revision is a descendent of a prior
revision).

The one I am "against" is a relationship between workspaces, namely,
that you somehow automatically see any change from one workspace in
another.  I believe you can achieve the same effect in a more
controlled fashion by having two workspaces specify common
configurations and activities in their revision-selection-rules.

   >[CK] Another way to think of this is that the collections in the
   >     namespace represent the project and sub-project relationships
   >     and that configurations represent various "releases" of those
   >     projects.  In this way the "V2" configuration can be derived
   >     from the "V1" configuration.

   So you have:

   1.  A bunch of actual files in a namespace, representing the source tree.

Well, you have a bunch of resources accessible in a URL namespace ...
whether the server actually implements that as a bunch of actual files
in a namespace is up to the server (many will in fact do just that).

   2.  A number of configurations, each representing a separate release of the
       code, with links into multiple levels of the source tree.

Yes, this is the sense in which I would use the term "configuration",
although the links are to specific revisions, not into a "source tree".

   3.  Many more configurations, each depending on the release configurations,
       representing developer workspaces.

And these are what I would call "workspaces", not "configurations".
And a workspace "depends" on a (release) configuration by specifying
that configuration in its revision-selection-rule.

   The developer would then use the actual URIs from (1) for dealing with
   the files

Yes!

   and personal (3) workspace as a header to to select the 
   appropriate versions from (1),

Yes!

   and seldom (if ever) actually see the contents of (3)?

Yes, assuming by "the contents of (3)", you mean the flat list of references
to revisions.

   (Logging in to a workspace becomes interesting:
   how to choose from among a bunch of configurations?  

When time comes to change the configuration selected by your
workspace, you normally would pick a descendent of that configuration
(where the "descendent" of a configuration is described earlier).

   Thus, most WebDAV operations would not occur on configurations
   directly.  All the PUTs and GETs and PROPPATCHes and LOCKs and 
   UNLOCKs would happen using the URIs from (1) and the configuration
   ID from (3).

Yes!  The only time you'd refer to server-defined URL's would be when
you wanted to do things like label revisions you don't currently see
in your workspace (possibly, to make them visible in your workspace).

   The configuration would occasionally be added to
   through MKREF and removed from via DELETE, but all of this would
   happen behind the scenes.

Configurations are immutable, but workspaces would be changed by these
MKREF's and DELETE's.

   This makes a big difference in my visualization of configurations.  The
   impression I got from the document was that a user might want to create a
   configuration in their home directory on a server and use that as their
   local copy of the data in the source tree, that configurations would be
   something that you navigated into just like a normal directory tree.

   What I'm seeing now is something more like a lock token with a lot more
   state packed into it.  A user would "log in" to a configuration and
   begin sending the configuration-id header along with almost all
   requests to the server.  This would provide a context for their
   particular view of the source tree.

Yes!  (Replacing the term "configuration" with the term "workspace").

   Could a user ever wind up being "logged in" to multiple configurations?
   [re: BRANCH]

Not to multiple workspaces, but a given workspace could specify multiple
configurations and activities in its version-selection-rule.


   >[CK] This is something I should have made clearer.  Both are valid.
   >     The VER:... notion is used to refer to a specific revision via
   >     a URI.  You can also specify the URL and the Revision-Id header.
   >     Chalk this up to a bad example.

   Hopefully, the VER:... URI functionality will be optional?  Should there
   be a way to discover this functionality through OPTIONS?

I would restrict the use of these server generated URI's for CM
metadata manipulations (such as labeling, and doing merges) on
revisions not visible in the workspace.  Standard user commands such
as CHECKOUT/CHECKIN/UNCHECKOUT should be restricted to the human
understandable URI's.

   >>Regarding SETDEFAULT:  why is it specified as sending an XML body?

   >[CK] The idea was to allow the user to specify additional information
   >     as well as allow the DAV:none to cancel.  We could do this all 
   >     through headers, but XML seemed appropriate.

   What other information would go in with SETDEFAULT?  For that matter,
   is SETDEFAULT really doing anything you couldn't with PROPPATCH?
   If I'd read that SETDEFAULT functionality was to be implemented with
   a live property named DAV:defualtversion, I wouldn't have blinked...

Once you have the notion of a default workspace for a web site, you no
longer need the SETDEFAULT method ... you just make changes to the
revision-selection-rule of the default workspace, or modify the labels
or branches specified in that revision-selection-rule.

   Another question that comes to mind:  why are there properties using
   comma-separated lists (such as DAV:revisionlabel, DAV:mergedfrom, ...) 
   instead of an XML representation of such a list?  I would think
	   <D:revisionlabel>
	     <D:label>Beta test</D:label>
	     <D:label>Release</D:label>
	   </D:revisionlabel>
   would be more in keeping with the standard.

I share your distaste for something as mungy as a comma-separated list.
Although an XML property would be an improvement, I believe what we
really should do is represent a resource-list property as a collection.
One of the key advantages of using a collection is that it has an
incremental update mechanism, which circumvents the "lost update" problem
(i.e. two clients read a property list, make different changes, and then
write back their change, with the second writer overwriting the changes
made by the first writer).

Max: Another set of excellent observations/suggestions!

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 09:27:52 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA01393
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 09:27:52 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA25875
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 09:27:51 -0500 (EST)
Received: from tantalum by gw.atria.com id <JAA05421@gw.atria.com> Mon, 8 Feb 1999 09:27:50 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA27801; Mon, 8 Feb 1999 09:27:49 -0500
Date: Mon, 8 Feb 1999 09:27:49 -0500
>From: gclemm@atria.com (Geoffrey M. Clemm)
Message-Id: <9902081427.AA27801@tantalum>
To: max@glyphica.com
Cc: w3c-dist-auth@w3.org
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

A couple of use cases that illustrate why you might want working
resources to only appear at the URL that was checked-out:

Shared-Workspace:

Two (or more) users are working on the same activity and want to see
each others checked-out work, so they are both working in the same
workspace.  If working resources are scattered about in server defined
locations, only the client that actually did the checkout would have
direct knowledge of where they are.  To share these resources, the
clients would have to implement some mechanism for tracking down these
working resources.  Rather than have clients try to do this (in
various non-interoperable ways), the server could be required to 
make the working-resource visible at the checked-out URL.

Testing-Before-Checkin

A developer would like to test the contents of working resources before
checking them in.  This involves link-validity checking, and in case
the working resources contain code, running some builds and testing
the results.  If working-resources are scattered about in temporary
locations, the link-validity check will fail to find the changes, as
will the code builds.  As with the previous use case, this problem is
solved by requiring the server to make the working resource visible
at the checked-out URL.

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 10:35:43 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA02799
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 10:35:42 -0500 (EST)
Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA26681
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 10:35:42 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA02754
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 10:35:28 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <1RN0KWVH>; Mon, 8 Feb 1999 10:38:16 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DB3@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 10:38:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: WebDAV Collections: Rationale for Lock Semantics

Locking for references has turned out to be a very difficult area that the
advanced collections design team has been discussing for several weeks.  The
position we have reached is:

1. When locking a collection with Depth = infinity, if the collection
contains redirect references, the redirect references will be locked.  The
response will *not* include 302 response codes for redirect references.  The
response element for a redirect reference does include reftype and
reftarget, so that a referencing client can lock the reference's target if
it wants to.

Rationale: A 302 response code for a redirect reference would cause the
entire lock request to fail.  In effect, we would be making it impossible to
lock collections that contain redirect references.  This is unacceptable.
This means that down-level clients will not realize that the target resource
has not been locked, but we felt this consequence was less objectionable
than failing the lock altogether.  Although we could have chosen to require
the server to lock the target resource as well as the redirect reference,
this would have violated the purpose of redirect references, which is to
provide a level of referencing that is simple for servers to implement, and
in particular does not require them to operate on target resources that may
reside on other servers.

2. When the request-URI of a LOCK request identifies a redirect reference,
the reference will be locked.  Although most requests to redirect references
get 302 responses, there will *not* be a 302 response to a LOCK request.
This is for consistency with 1.

The attached note discusses our decisions about LOCK for direct references
and the rationale for them.


> -----Original Message-----
> From:	Slein, Judith A 
> Sent:	Wednesday, February 03, 1999 1:51 PM
> To:	Alan Babich; Chuck Fay; Geoff Clemm; Jim Davis; Jim Whitehead;
> jslein; Tyson Chihaya
> Subject:	WebDAV Collections: Rationale for Lock Semantics
> 
> I promised to try to capture the rationale behind our decision on locking
> semantics for direct references.  We decided that by default, a LOCK on a
> direct reference would lock the target, not the reference.  For locks with
> Depth=infinity on collections that contain direct references, the targets
> of the direct reference would be locked, and not the references
> themselves.
> 
The No-Passthrough header can be used with any LOCK request, and causes the
lock to be applied to any direct references in the scope of the request,
rather than to their targets.

> -------------
> 
> No matter what semantics we choose, there are some objectionable
> consequences.  So we are forced to select the least objectionable
> semantics.
> 
> The options for direct references are:
> Lock only the target (our choice this week)
> Lock only the reference
> Lock both the target and the reference
> 
> Goals:
> 1. No surprises for clients
> 2. Efficient implementation possible
> 3. Be consistent with the WebDAV spec
> 4. Preserve the distinction between direct and redirect references as
> cleanly as possible.
> 5. Be consistent with the behavior of other methods on direct references
> as far as possible, especially for collections (PROPFIND).
> 
> Lock only the target:
> 1. Someone may change the reference to point elsewhere while the LOCK is
> present. This will surprise the lock holder.  It's a change to the
> namespace that appears as a change in content.  This problem can be
> avoided if referencing clients make it a practice to check whether the
> target is locked before moving or deleting a direct reference.  In
> addition, a referencing client can lock both the reference and its target
> by performing two LOCK operations, one with No-Passthrough.
> Both down-level and referencing clients would be surprised, though the
> referencing client at least could figure out what had happened.
> 2. Locking a collection can be costly, especially if direct references in
> the collection point to other collections.
> 3. This is inconsistent with the WebDAV spec, which requires that if a
> collection is locked with Depth=infinity, all members of the collection
> get locked.  The reference is the member of the collection, but we are not
> locking it.  (From the client's point of view, however, we are locking the
> collection member.)
> 4-5. This clearly maintains the difference between redirect and direct
> references, and follows the general semantics we have established for
> direct references: operations on direct references affect only the target,
> unless the No-Passthrough header is used, in which case the operation
> affects only the reference.
> 
> Lock Both the Target and the Reference:
> 1. This prevents surprises caused by changing the reference to point to a
> different target while only the target is locked.
> (It's still possible to cause surprises in a hierarchy of references
> /X/Y.html by changing /X/ to point to a difference target.)
> 2. Locking a collection can be costly, especially if direct references in
> the collection point to other collections.
> 3. This is consistent with the semantics of locking defined in WebDAV.
> 4. This maintains the difference between direct and redirect references.
> 5. It is inconsistent with the semantics of other operations on direct
> references.  There is no other case where both the reference and its
> target are affected by a single operation.
> It is inconsistent with PROPFIND on a collection that contains direct
> references, which by default retrieves the properties of the targets.
> 
> Lock Only the Reference:
> 1. Clients (especially down-level clients) may be surprised.  Their lock
> operation is successful, but the target is not locked, so someone else can
> change the target.  (Someone else can also lock a different direct
> reference to the same target.)
> 2. Makes locking a collection efficient.  You never have to go outside the
> hierarchy where you started.
> 3. This is consistent with the semantics of locking defined in WebDAV.
> 4. Blurs the distinction between direct and redirect references, since the
> server does not resolve the reference in this case, even though it is
> dealing with a direct reference.
> 5. This is inconsistent with the semantics of other operations on direct
> references, which generally affect the target, not the reference.  There
> are exceptions -- DELETE, MOVE, COPY -- but these are all because their
> primary effect is to modify the namespace as seen by the client.  That
> rationale wouldn't apply in this case.
> This is inconsistent with the semantics of PROPFIND on collections.
> 
> 3 = best, 1 = worst
> 				Lock Target	Lock Reference		Lock
> Both
> 
> Surprise			2		1			3
> 
> Efficiency			1		3			1
> 
> Consistency with WebDAV	1		3			3
> 
> Consistency with definitions	3		1			3
> of direct / redirect
> 
> Consistency with other		3		1
> 1
> referencing semantics
> 
> So in choosing to lock only the target of a direct reference, we are
> choosing consistency with other referencing definitions and semantics over
> other considerations.  We also can avoid surprising results by including
> an implementation note encouraging referencing clients to check whether
> the target is locked before deleting or replacing a direct reference.  We
> choose not to be too concerned about efficiency because we have provided
> redirect references for servers that want to provide low-cost referencing.
> 
> The most serious objection to our decision is that it is inconsistent with
> the WebDAV specification's locking semantics.  In justification, we can
> say that those semantics were specified before referencing had been
> investigated, and that we are honoring the intent, though not the letter,
> of those semantics. The point of direct references is to make it appear to
> users as if the target resource is a member of the collection where the
> reference in fact resides, and to hide from users the existence of the
> reference.  Locking the target comes closer to giving the user the
> illusion that the collection and its members have been locked than locking
> the reference does.  (Locking both comes closer still, and also satisfies
> the WebDAV semantics.)
> 
> -- Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 12:10:46 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA05071
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 12:10:45 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA27920
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 12:10:44 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <D8W7N7K7>; Mon, 8 Feb 1999 09:10:44 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757CFF@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "'WebDAV'"
	 <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 09:10:33 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: WebDAV Collections: Rationale for Lock Semantics

Can I LOCK a direct reference and have just the reference LOCKed, not what
it refers to?

Chris

-----Original Message-----
>From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
Sent: Monday, February 08, 1999 7:38 AM
To: 'WebDAV'
Subject: FW: WebDAV Collections: Rationale for Lock Semantics


Locking for references has turned out to be a very difficult area that the
advanced collections design team has been discussing for several weeks.  The
position we have reached is:

1. When locking a collection with Depth = infinity, if the collection
contains redirect references, the redirect references will be locked.  The
response will *not* include 302 response codes for redirect references.  The
response element for a redirect reference does include reftype and
reftarget, so that a referencing client can lock the reference's target if
it wants to.

Rationale: A 302 response code for a redirect reference would cause the
entire lock request to fail.  In effect, we would be making it impossible to
lock collections that contain redirect references.  This is unacceptable.
This means that down-level clients will not realize that the target resource
has not been locked, but we felt this consequence was less objectionable
than failing the lock altogether.  Although we could have chosen to require
the server to lock the target resource as well as the redirect reference,
this would have violated the purpose of redirect references, which is to
provide a level of referencing that is simple for servers to implement, and
in particular does not require them to operate on target resources that may
reside on other servers.

2. When the request-URI of a LOCK request identifies a redirect reference,
the reference will be locked.  Although most requests to redirect references
get 302 responses, there will *not* be a 302 response to a LOCK request.
This is for consistency with 1.

The attached note discusses our decisions about LOCK for direct references
and the rationale for them.


> -----Original Message-----
> From:	Slein, Judith A 
> Sent:	Wednesday, February 03, 1999 1:51 PM
> To:	Alan Babich; Chuck Fay; Geoff Clemm; Jim Davis; Jim Whitehead;
> jslein; Tyson Chihaya
> Subject:	WebDAV Collections: Rationale for Lock Semantics
> 
> I promised to try to capture the rationale behind our decision on locking
> semantics for direct references.  We decided that by default, a LOCK on a
> direct reference would lock the target, not the reference.  For locks with
> Depth=infinity on collections that contain direct references, the targets
> of the direct reference would be locked, and not the references
> themselves.
> 
The No-Passthrough header can be used with any LOCK request, and causes the
lock to be applied to any direct references in the scope of the request,
rather than to their targets.

> -------------
> 
> No matter what semantics we choose, there are some objectionable
> consequences.  So we are forced to select the least objectionable
> semantics.
> 
> The options for direct references are:
> Lock only the target (our choice this week)
> Lock only the reference
> Lock both the target and the reference
> 
> Goals:
> 1. No surprises for clients
> 2. Efficient implementation possible
> 3. Be consistent with the WebDAV spec
> 4. Preserve the distinction between direct and redirect references as
> cleanly as possible.
> 5. Be consistent with the behavior of other methods on direct references
> as far as possible, especially for collections (PROPFIND).
> 
> Lock only the target:
> 1. Someone may change the reference to point elsewhere while the LOCK is
> present. This will surprise the lock holder.  It's a change to the
> namespace that appears as a change in content.  This problem can be
> avoided if referencing clients make it a practice to check whether the
> target is locked before moving or deleting a direct reference.  In
> addition, a referencing client can lock both the reference and its target
> by performing two LOCK operations, one with No-Passthrough.
> Both down-level and referencing clients would be surprised, though the
> referencing client at least could figure out what had happened.
> 2. Locking a collection can be costly, especially if direct references in
> the collection point to other collections.
> 3. This is inconsistent with the WebDAV spec, which requires that if a
> collection is locked with Depth=infinity, all members of the collection
> get locked.  The reference is the member of the collection, but we are not
> locking it.  (From the client's point of view, however, we are locking the
> collection member.)
> 4-5. This clearly maintains the difference between redirect and direct
> references, and follows the general semantics we have established for
> direct references: operations on direct references affect only the target,
> unless the No-Passthrough header is used, in which case the operation
> affects only the reference.
> 
> Lock Both the Target and the Reference:
> 1. This prevents surprises caused by changing the reference to point to a
> different target while only the target is locked.
> (It's still possible to cause surprises in a hierarchy of references
> /X/Y.html by changing /X/ to point to a difference target.)
> 2. Locking a collection can be costly, especially if direct references in
> the collection point to other collections.
> 3. This is consistent with the semantics of locking defined in WebDAV.
> 4. This maintains the difference between direct and redirect references.
> 5. It is inconsistent with the semantics of other operations on direct
> references.  There is no other case where both the reference and its
> target are affected by a single operation.
> It is inconsistent with PROPFIND on a collection that contains direct
> references, which by default retrieves the properties of the targets.
> 
> Lock Only the Reference:
> 1. Clients (especially down-level clients) may be surprised.  Their lock
> operation is successful, but the target is not locked, so someone else can
> change the target.  (Someone else can also lock a different direct
> reference to the same target.)
> 2. Makes locking a collection efficient.  You never have to go outside the
> hierarchy where you started.
> 3. This is consistent with the semantics of locking defined in WebDAV.
> 4. Blurs the distinction between direct and redirect references, since the
> server does not resolve the reference in this case, even though it is
> dealing with a direct reference.
> 5. This is inconsistent with the semantics of other operations on direct
> references, which generally affect the target, not the reference.  There
> are exceptions -- DELETE, MOVE, COPY -- but these are all because their
> primary effect is to modify the namespace as seen by the client.  That
> rationale wouldn't apply in this case.
> This is inconsistent with the semantics of PROPFIND on collections.
> 
> 3 = best, 1 = worst
> 				Lock Target	Lock Reference		Lock
> Both
> 
> Surprise			2		1			3
> 
> Efficiency			1		3			1
> 
> Consistency with WebDAV	1		3			3
> 
> Consistency with definitions	3		1			3
> of direct / redirect
> 
> Consistency with other		3		1
> 1
> referencing semantics
> 
> So in choosing to lock only the target of a direct reference, we are
> choosing consistency with other referencing definitions and semantics over
> other considerations.  We also can avoid surprising results by including
> an implementation note encouraging referencing clients to check whether
> the target is locked before deleting or replacing a direct reference.  We
> choose not to be too concerned about efficiency because we have provided
> redirect references for servers that want to provide low-cost referencing.
> 
> The most serious objection to our decision is that it is inconsistent with
> the WebDAV specification's locking semantics.  In justification, we can
> say that those semantics were specified before referencing had been
> investigated, and that we are honoring the intent, though not the letter,
> of those semantics. The point of direct references is to make it appear to
> users as if the target resource is a member of the collection where the
> reference in fact resides, and to hide from users the existence of the
> reference.  Locking the target comes closer to giving the user the
> illusion that the collection and its members have been locked than locking
> the reference does.  (Locking both comes closer still, and also satisfies
> the WebDAV semantics.)
> 
> -- Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 12:56:49 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA06584
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 12:56:49 -0500 (EST)
Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA28723
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 12:56:47 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id MAA06174;
	Mon, 8 Feb 1999 12:56:44 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <1RN0KZA9>; Mon, 8 Feb 1999 12:59:33 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DB4@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Chris Kaler'" <ckaler@microsoft.com>,
        "Slein, Judith A"
	 <JSlein@crt.xerox.com>,
        "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 12:59:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Collections: Rationale for Lock Semantics

Yes, you do that by including the No-Passthrough header with the request.

--Judy

> -----Original Message-----
> From: Chris Kaler [mailto:ckaler@microsoft.com]
> Sent: Monday, February 08, 1999 12:11 PM
> To: 'Slein, Judith A'; 'WebDAV'
> Subject: RE: WebDAV Collections: Rationale for Lock Semantics
> 
> 
> Can I LOCK a direct reference and have just the reference 
> LOCKed, not what
> it refers to?
> 
> Chris
> 


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 18:11:42 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17047
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 18:11:42 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA03215
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 18:11:41 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1RWQWA73>; Mon, 8 Feb 1999 15:11:40 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792EB2@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 15:11:33 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: COPY and Methods

In this paper I am going to talk about COPY's definition as it relates to
the behavior of the copied resource at the destination. I will leave the
issue of COPY and properties to another paper.

When the COPY and MOVE debate began it was almost instantly agreed that MOVE
somehow inherited COPY's functionality. The exact nature of the inheritance
was left open but it was felt that we first had to get our definition of
COPY right before we could deal with MOVE. Thus the WG worked first on COPY.

In order to understand what it means to copy a resource one must first
understand the nature of an HTTP resource. HTTP defines a resource in terms
of how it responds to methods. The actual implementation of the resource is
left as an open question. This flexibility allows HTTP resources to be
files, CGIs, databases, extensions, etc.

Thus the most obvious definition of the COPY method was something along the
lines of "The result of a COPY method is to create a new destination
resource, whose state is independent of the source resource, which responds
to the same methods in the same way as the source resource."

This definition lasted about the length of time it took to utter it. For
example, imagine one has a resource that maps to a file in a directory. The
directory is CGI enabled. A user then tries to copy the resource to another
directory that doesn't have CGI support. The previous definition would
require the attempt to fail because clearly the destination resource would
not "respond... to the same methods in the same way as the source resource."
Everyone instinctively understood that failing the previous scenario made
COPY less than useful.

There was some thought of defining a switch which would determine if a COPY
should be strict or not. A strict copy would work as the previous definition
and a loose copy would just do whatever it wanted. But nobody felt the
definition of "strict" could be satisfactorily nailed down. Phrases like
"respond... to the same methods in the same way" were too murky. The only
way to come up with a completely reliable definition was to re-invent
COM/CORBA so we could exactly define what a resource was. Then we would
either have to put in negotiation based on environment, processor, etc. or
try to adopt some universal portable environment like JAVA. Most folks in
the WG could actually feel themselves sliding down the slope heading for the
bottomless pit.

The consensus was that COPY was going to be a "magic" method. Its behavior
would be a function of who controlled the source and destination. So you
better know what you are doing before you execute the COPY. If you were
copying around files, everything would pretty much work the way you
expected. If you tried to copy anything more complicated, your mileage would
vary.

I realize that this definition would seem to be counter to the goal of
interoperability but it accurately reflects how systems work today. If you
want your CGI file to be properly executed you better know where the CGI
enabled directory is. If you want your ISAPI filter to run, you better know
how to register it (way out of scope for WebDAV). Even things as simple as
wanting to copy a file to a disk require that you know the name of the disk
drive. In general copy gets leveraged to implicitly provide many services
because copy is the programmatic equivalent of drag and drop. What happens
when you drag object A over object B completely depends on the nature of A
and B.

Killing the magic would just break ranks with current implementations
without providing any real user benefit. We would have the best-defined COPY
method that no one ever used. 

In the end the WG agreed and defined copy as the creation of a new resource
at the destination whose initial state was related, in an unspecified
manner, to the state of source resource at the time of the COPY. Certainly
not perfect but in practice it has proven to be good enough.


From w3c-dist-auth-request@www10.w3.org  Mon Feb  8 21:25:59 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA20033
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Feb 1999 21:25:58 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id VAA04782
	for <w3c-dist-auth@w3.org>; Mon, 8 Feb 1999 21:25:56 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1RWQW43X>; Mon, 8 Feb 1999 18:25:55 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792EB7@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 18:25:51 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: copy and properties

One particular aspect of COPY that took a lot longer to gel was how to
handle the properties on a resource. If memory serves the very first
definition of COPY didn't even include the properties. Then property support
was added but on the same basis as support for methods - your mileage may
vary. In other words, you couldn't be sure which properties made it across
and in what state.

Where as everyone seemed to accept that defining how the methods were copied
should be left as magic, properties were a different story. It was felt that
properties were "well defined" and therefore we should be able to fully
define their behavior over a COPY.

In typical WebDAV fashion, we went to the other extreme and stated that all
properties had to be copied over or the COPY would fail. Furthermore, if a
property was live on the source then it also had to be live on the
destination.

This definition was so overly restrictive that it would have prevented
something as simple as copying a resource (read: file, in this particular
example) from an NTFS drive to a FAT drive because NTFS supports certain
properties as live that FAT doesn't. Everyone understood that this was
clearly not the desired behavior.

There was some flirtation with the idea of having a pre-copy method. The
idea is that you would execute a pre-copy method on the source and it would
tell you which properties would make it across to the destination, if any
and if they would be live or not. The motivation for this feature is that a
destination resource would support only what it supported, you couldn't
negotiate to get it to support more than it did. So it was best to just
discover what would happen to the properties of the source when copied to
destination and decide if that was acceptable. Of course the design was
insane since there was no guarantee that the results of a pre-copy would
match the eventual copy and it meant having to perform at least two round
trips, one for pre-copy and one for copy. The whole thing was really silly.
But it did help the authors focus in on the need for a declarative
mechanism. In other words, clients needed to be able to say "If you can do
the following then the copy should be attempted, otherwise don't bother."

After some discussion four declarative cases where identified for property
behaviors on a COPY:

1) Copy all properties but don't require that live properties stay live.
This was considered the general case where it was expected that the user
would have some clue as to which live properties the destination supported
or didn't care.

2) Copy all properties but require that all live properties stay live. No
one had a good example of why this would be necessary but it was easy to
specify. =)

3) Copy all properties but only require that a sub-set of live properties
stay live. While there were some contrived examples for this case, no one
had a particularly compelling one. However there was a general feeling that
if copy was to be useful outside of the limited scenarios where you knew
something about the destination we would need this feature.

4) Don't fail the copy for any property related reasons. This was a fall
back case meant to cover situations where you were copying to really dumb or
resource constrained WebDAV servers that couldn't handle properties very
well. 

There fifth case which, to the best of my recollection, was never discussed:


5) Guarantee that a certain sub-set of properties are copied across as live,
a certain sub-set are copied across as either live or dead and do not fail
if any of the properties not listed in the previous two sub-sets don't make
it across or can only be copied across as dead.

Cases 1 - 3 require that all properties must make it across, the only issue
is if the properties will be live at the destination. Case 4 was a fall back
case. I'm not convinced that supporting case 5 is all that critical, disk
space is cheap, but time will tell.

Defining the language for copying a live property on the source to a live
property on the destination is easy, its magic. Specifically, it is expected
that live properties will fully define how they are to behave when copied.
There really isn't anything useful that the standard could say on this
topic.

However a most unfortunate choice of language was made in describing how to
copy a property which was live on the source but would be dead on the
destination, quoting from section 8.8.2:

   If a property cannot be
   copied live, then its value MUST be duplicated, octet-for-octet, in
   an identically named, dead property on the destination resource
   subject to the effects of the propertybehavior XML element.

The phrase at question is "octet-for-octet." The purpose of saying
"octet-for-octet" was to indicate that one should take the value that the
live property would have produced at the time of the copy and just copy that
dead value over. For example, imagine one had a live property called
iso:time-of-day. If you asked for the property's value you would get back
the current time of day. If you copied this property to a server which
didn't support iso:time-of-day as a live property then the value of the dead
property should be the live property's output at the time of the copy. So if
you asked for the property's value on the destination you would always get
back the same time of day, the time when the resource was copied.

However we didn't want to absolutely require this behavior. We could imagine
that a live property may be smart enough to come up with a better value for
its dead counterpart. For example, the source resource may decide to pass
over a property value which says "I'm dead, ignore me." This would be
completely acceptable and in fact, extremely reasonable.

In the end, this section fell through the editing filter. Clearly the
language needs to be cleaned up before we move to draft standard.


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 01:39:38 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA22936
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 01:39:38 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA06416
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 01:39:36 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <D8W7QVLG>; Mon, 8 Feb 1999 22:39:36 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D18@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Max Rible'" <max@glyphica.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 8 Feb 1999 22:39:34 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

At 12:10 2/2/99 -0800, Chris Kaler wrote:
	>[CK] The point of using "giberish" in the draft is to reinforce
	>     that the server determines the value.  A server could make it
	>     giberish or something else.  One limitation we have is the
	>     strong reluctance in IETF to "munge" URLs.

Is there a document describing what the IETF folks mean when they describe
"mungeing" URLs?  The image that comes to mind is tacking on decorations
like # and ? with information after them, or creating extra namespaces like
the ones for configurations and checked-out files.
I see a URI as a three-dimensional phenomenon-taking us through a space
dimensioned by machine/protocol/port combinations (each unique one defining
a plane), directories (the vertical aspect of the plane, if you consider the
directory hierarchy unfolded completely) and files in directories (the
horizontal aspect of the plane, with files as chains following folders).  
Versioning adds a new dimension.  I see the headers as allowing us to add
that new dimension (version number, etc.) to the URI, rather than trying to
map the fourth dimension into other parts of the plane (which is what a
temporary file created for checkin/checkout purposes is).  Since headers
such as Revision-Id are already in use to provide that fourth dimension for
accessing concrete versions, using them to access temporaries seems to me
the least work to implement and the most consistent.  Of course, having
eight different things happen depending on three different headers you might
or might not send could be precisely what the IETF considers URL mungeing.
[CK] The term "URL" munging generally refers to taking stuff onto the URL to
pass
        additional information about the URL.  In the case of versioning,
you can use
        either # or ? as they have meaning.  For example, # is typically
filtered at the client.
        The ? might be a legitimate part of the URL.  There is already a
precedent for headers.
        Consider, for example, content-type.
	>[CK] I think it is important to remember that these are
protocol-level
	>     resources.  I would assume that the UI on top of the protocol
hides
	>     all this.  For example, you "checkout" and "checkin" based on
the
	>     resource name you desire.

For sufficiently general values of "based on", yes. :-)  The current
document gives the example of CHECKIN /tmp/VRJHJWE3493409 HTTP/1.1, which
makes no reference to the resource name involved.
[CK] You can really argue this one either way.  The CHECKOUT operation
created a
        new resource.  Either you CHECKIN the working resource, or you must
pass the
        working resource as a required header if you specify the checked out
resource.
        In this draft we chose to use the working resource since the server
created it, it
        can map it back to the original resource.  Personally, I don't see
the issue if the
        resource referenced is not user friendly.  This is a wire protocol.
The alternative
        is another header.  However, this is clear open to discussion and
debate.  :-)
As long as the user thinks they're checking in to the usual location, it
doesn't really matter, but things in the underlying implementation have a
way of percolating up to the user's view of the world.  It also makes life
easier for watching the requests as a programmer or administrator.
	>                                The working copy resource is part
of the
	>     implementation and isn't visible to the user.  As well, there
is
	>     always the DAV:displayname property.

Perhaps checked-out temporaries should have a property that points at their
original document and version?  Or should the lineage report suffice for
that purpose?
[CK] I think this is a good idea.
[re:  my idea for CHECKOUT/CHECKIN/UNCHECKOUT]
	>[CK] I don't think so.  The idea is that a CHECKOUT creates a
working copy.
	>     Technically this is not part of the revision graph for the
resource.
	>     It must be mutable because clients need to be able to make
multiple
	>     changes.  You can't version it because it isn't part of the
version
	>     graph.  It is just a scratch space where PUTs and PROPPATCHs
can be
	>     performed until the resource is ready.  CHECKIN then assigns a
revision
	>     id and makes it part of the graph.  Working copies don't have
revision
	>     ids.  Also, UNCHECKOUT cancels a CHECKOUT.  You can't issue
UNCHECKOUT
	>     once you've issued a CHECKIN.  The draft should be clearer on
this
	>     point.

Sorry; I should've been clearer.  (It does seem pretty obvious that you
can't UNCHECKOUT once you've done a CHECKIN; I probably just flubbed the
language.)  I meant to suggest:
	1.  "CHECKOUT uri" returns 200 OK and gives you a token instead of
201 Created and an URL.
	2.  "PUT uri" and "PROPPATCH uri" with the token provided in the
request header allow you to meddle with the working copy at uri to your
heart's content.  If uri isn't locked, there could conceivably be multiple
such working copies, each accessed with different tokens.
3a. "CHECKIN uri" with the token would check in the working copy with
		a proper revision ID, release any locks you have on the
original uri
		(unless you explicitly request to keep the locks), and lose
all
		record of the token; alternatively,
3b. "UNCHECKOUT uri" with the token would remove the working copy, all
		record of its token, and any locks you had on it.
The token could be passed as a Revision-Id of some particular sort, if you
treat working copies as mutable revisions, or in some other fashion.
[CK] In the -00 draft it was proposed that CHECKOUT/IN use the LOCK method
        since the behavior is very similar to locks.  The working group
decided against
        this.  Note that this style approach would resolve your issue above
as well.  Maybe
        we should model this as LOCK and return a checkout token as you
suggest.  This
        token would then be passed in on CHECKIN.  I guess the question I
have then is,
        how is this different from LOCK?
	>The same thing applies to configurations:  do they need to exist
	>in special areas?  [...]

	>[CK] The idea here was to put them in a unified place so that
standard
	>     DAV discovery mechanisms can be used.  Otherwise we need to
add
	>     new methods to discover the configurations.

They could always exist as normal residents of the namespace who happen to
have a DAV:resourcetype of DAV:configuration-they could sit there next to
collections and ordinary files.  (Once references are implemented, I don't
see it as that much more trouble to do other special entities.)
[CK] If they live anywhere in the namespace, getting a list of the defined
configurations
        is quite hard.  That was the idea for putting them in a "well known"
place.
[An aside:  we've been doing a lot of hammering on a very similar notion
over here at Glyphica for our next product, which is intended to be
WebDAV-compliant, and the "configurations" from the versioning draft sound a
lot like the "projects" we've been debating over here.  After much
hammer-and-tongs haranguing about the natures of projects, we settled on the
notion that a project would have a lot of links but could own entities in
its own right, in order to simplify matters of hierarchy.  I'm trying to
figure out if a project is likely to *be* a configuration or *use* a
configuration.  The example in the versioning goals isn't much different
from labeling a source tree, which you can do with a BRANCH operation in
this specification.  Were there any other examples that you folks used in
coming up with what a configuration should be able to do?]
[CK] We have introduced two notions: branching of a single resource, and
branching of a set
        of related resources.  The first uses the BRANCH method, the second
uses configurations.
        I would suggest that a configuration represents a point in the
project lifetime, not a 
        project.  I believe this to be a more powerful management tool.
>From an object-oriented point of view, I'm thinking of configurations as a
subclass of collections with some added functionality.  Both accept PROPFIND
with a Depth header, both need to manage a bunch of other entities when you
use COPY and DELETE and MOVE.  A Configuration-Id URI would tell the system
where the configuration is, so there doesn't need to be any central lookup
location; putting a collection that is not a configuration in the
Configuration-Id header should generate an error.
[CK] That is one aspect that is there for discovery.  However,
configurations also represent
        a way to view the namespace orthogonal to the URL.  I think this is
important.  For example,
        you can have Beta1 and Beta2 of your web site and edit them using
the exact same URLs
        if your editor is versioning-aware and knows to pass the
configuration.
	>[CK] Configurations are very similar, but also very different.  A
	>     configuration collection can be referenced in the
Configuration-Id
	>     header.  That is not true of all MKREF collections.  As well,
changes
	>     to the resources in the context of a configuration are
automatically
	>     represented inside the configuration collection.  That is, if
I
	>     rename foo.htm to bar.htm using MOVE in the /c/1
configuration, then
	>     inside /c/1 there will be a reference to bar.htm.

I'm not sure I got that.  Do you mean that 
MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /c/1/foo.htm
Destination: /c/1/bar.htm

works as expected, (/c/1/bar.htm is a reference to /potzrebie/foo.htm,
just like in a collection), or
MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /potzrebie/foo.htm
Destination:  /potzrebie/bar.htm

will update /c/1/foo.htm to point to /potzrebie/bar.htm?
[CK] What I meant was that you MKCONFIG /c/beta1 and /c/beta2 you can then
reference
        /foo/bar.htm in the following ways:
        GET /foo/bar.htm
        Configuration-Id: Beta1
         -or-
         GET /foo/bar.htm
         Configuration-Id: Beta2
        This let's you switch between the two without having to change the
links.  This is
        Different from other MKREF references.
	>Should configurations be able to contain other configurations, or
	>simply references to them?  I can easily see that a configuration's
	>user might wish to partition it when it gets large and cluttered.

	>[CK] This is a really interesting question.  Conceptually, why not?
	>     However, that is really hard to represent in the resources.

More than a collection is?  I may be missing something here...
[CK] Our idea was that a the /c/Beta1 would contain references to the
resources in the 
        configuration.  If a configuration contains another configuration,
how would you
        represent that?
	>
As
	>     well, some of the semantics start to get really messy.  What
does
	>     it mean to have nested configurations?  What does it mean for
a
	>     resource to be "in" nested configurations.  We opted to say
that a
	>     configuration can be derived from another, but there isn't a
notion 
	>     of containment.

If a configuration is a collection with special attributes for how it
interacts with the configurations it derives from and that derive from it,
and containment is handled like any collection, does that open any cans of
worms?
[CK] Possibly.  Do any come to mind?
	>I'm thinking of software development solutions:  a configuration
might
	>represent a project, with subconfigurations containing subprojects.
	>You'd want automatic inheritance from the core project so any time
	>someone else added a file to the configuration, you got a reference
	>to it. [...]

	>[CK] Another way to think of this is that the collections in the
	>     namespace represent the project and sub-project relationships
	>     and that configurations represent various "releases" of those
	>     projects.  In this way the "V2" configuration can be derived
	>     from the "V1" configuration.

So you have:
1.  A bunch of actual files in a namespace, representing the source tree.
	2.  A number of configurations, each representing a separate release
of the code, with links into multiple levels of the source tree.
	3.  Many more configurations, each depending on the release
configurations, representing developer workspaces.

The developer would then use the actual URIs from (1) for dealing with the
files and personal (3) workspace as a header to to select the appropriate
versions from (1), and seldom (if ever) actually see the contents of (3)?
(Logging in to a workspace becomes interesting: how to choose from among a
bunch of configurations?  
Thus, most WebDAV operations would not occur on configurations directly.
All the PUTs and GETs and PROPPATCHes and LOCKs and UNLOCKs would happen
using the URIs from (1) and the configuration ID from (3).  The
configuration would occasionally be added to through MKREF and removed from
via DELETE, but all of this would happen behind the scenes.
This makes a big difference in my visualization of configurations.  The
impression I got from the document was that a user might want to create a
configuration in their home directory on a server and use that as their
local copy of the data in the source tree, that configurations would be
something that you navigated into just like a normal directory tree.
What I'm seeing now is something more like a lock token with a lot more
state packed into it.  A user would "log in" to a configuration and begin
sending the configuration-id header along with almost all requests to the
server.  This would provide a context for their particular view of the
source tree.
Could a user ever wind up being "logged in" to multiple configurations?
[CK] Its clear that we need much more verbage in the document.  I'm not sure
I followed the
        "logging in" part.  However, much of what you stated is the
thinking.  The configuration
        represents an orthogonal view of the namespace.  That is, you can
reference a specific
        URL in the context of a configuration.  The configuration defines
which revision you get
        or which "project version" (we called them threads) to use.
[re: BRANCH]
	>[CK] This is something I should have made clearer.  Both are valid.
	>     The VER:... notion is used to refer to a specific revision via
	>     a URI.  You can also specify the URL and the Revision-Id
header.
	>     Chalk this up to a bad example.

Hopefully, the VER:... URI functionality will be optional?  Should there be
a way to discover this functionality through OPTIONS?
[CK] I have to change this in the protocol spec, it is more confusing.  I
should say something
        like:   http://www.foobar.com/internal/FJH3490345
<http://www.foobar.com/internal/FJH3490345>    I think that would be less
confusing.
		>>Regarding SETDEFAULT:  why is it specified as sending an
XML body?

	>[CK] The idea was to allow the user to specify additional
information
	>     as well as allow the DAV:none to cancel.  We could do this all

	>     through headers, but XML seemed appropriate.

What other information would go in with SETDEFAULT?  For that matter, is
SETDEFAULT really doing anything you couldn't with PROPPATCH?  If I'd read
that SETDEFAULT functionality was to be implemented with a live property
named DAV:defualtversion, I wouldn't have blinked...
[CK] We debated this one for a while.  The issue really comes up with
references.  Let's say
        I create a direct reference to /a/b.htm in /x/y.  I should be able
to set the default version
        of /x/y/b.htm to be a different revision from the default revision
of /a/b.htm.  Using 
        PROPPATCH is reasonable, but a little confusing.  This would
introduce the notion
        of namespace properties (which is already happening).  The other
reason is that this 
        is really a state change on the resource and it is reasonable
(desirable) to effect change
        via a method rather than as a side-effect of a property change.

***

Another question that comes to mind:  why are there properties using
comma-separated lists (such as DAV:revisionlabel, DAV:mergedfrom, ...) 
instead of an XML representation of such a list?  I would think
	<D:revisionlabel>
	  <D:label>Beta test</D:label>
	  <D:label>Release</D:label>
	</D:revisionlabel>
would be more in keeping with the standard.

[CK] For simplicity.  Technically a comma-separated list is valid XML, but
         your point is taken.
-- 
%% Max Rible %% max@glyphica.com <mailto:max@glyphica.com>  %%
http://www.amurgsval.org/~slothman/ <http://www.amurgsval.org/~slothman/>
%%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 01:52:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA23104
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 01:52:33 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA06482
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 01:52:32 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <D8W7QWAX>; Mon, 8 Feb 1999 22:52:32 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D19@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, max@glyphica.com
Cc: w3c-dist-auth@w3.org
Date: Mon, 8 Feb 1999 22:52:22 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Comments intermixed...

		-----Original Message-----
		From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
		Sent:	Saturday, February 06, 1999 9:51 PM
		To:	max@glyphica.com
		Cc:	w3c-dist-auth@w3.org
		Subject:	Re: [long] Re: I-D
ACTION:draft-ietf-webdav-versioning-01.txt


		Max: A thoroughly excellent (and excellently thorough)
review!

		I'll respond to them in the context of
"draft-clemm-webdav-versioning-00"
		(mailed a bit ago to this mailing list, and available on the
WebDAV
		web site).  This will give a preview of some of the
discussions that
		will take place at the upcoming design meeting.

		   From: Max Rible <max@glyphica.com>

		   My biggest issue with the new draft of the versioning
standard
		   is the usage of gibberish temporary URIs where a user
might have
		   to cope with them or a system administrator might have to
clean them
		   up.

		I agree.  I believe the argument to CHECKOUT, CHECKIN, and
UNCHECKOUT
		should always be a consistent human-comprehensible URL.

		[CK] This requires then that a checkout token be passed as
part of the request.
		        We can do this, but how then is a CHECKOUT different
from a LOCK?

		   Are there any actual cases where temporaries are actually

		   required, as opposed to a gibberish token that can be
used in
		   relation to a comprehensible URI?

		I believe the client should not need to be aware of the
location of
		any such temporaries.

		[CK] Agreed.  Clients should hide the protocol from the user
model.

		   There is a certain utility to having the magic files in a
magic
		   directory for ease of implementation-- you know you only
have to
		   treat a file in a special way if it's in a special
location.  In
		   my opinion, if you've already done the necessary work to
make MKREF function,
		   the additional amount needed to support checked-out files
and
		   configurations going anyplace should be small.

		I agree.

		[CK] How then does one quickly discover the defined
configurations?

		   Is there a major flaw with the notion of CHECKOUT
creating a locked, 
		   mutable, non-autoversioned revision that the user holding
the lock can 
		   mutate arbitrarily until a CHECKIN is performed, at which
point the 
		   revision's name changes from a placeholder to a version
number?  

		I agree with the overall concept, i.e. CHECKOUT creates a
mutable resource
		at the specified URL, but I'd modify the following details:

		I wouldn't want it to be a "revision" because this places
excessive
		constraints on the mutable resource.  In particular, a
revision can
		have only one descendent on a given branch, but you
sometimes want to
		allow a revision to have multiple CHECKOUT's to a given
branch
		(requiring a merge before any CHECKIN after the first).  But
I don't
		think that it being a "revision" was an essential part of
your point.

		Also, I would want the "lock" to be optional (I don't think
the "lock"
		mechanism scales well, and want it to be an optional part of
the
		versioning protocol).  Again, I believe this is not an
essential part
		of your point.

		[CK] The lock portion is option in -01.  I'm curious as to
why you don't
		        think the lock mechanism will scale?

		   (i.e.  
		   CHECKOUT /foo/bar.html HTTP/1.1
		   Host: www.foobar.com
		   ...

		I'd add an (optional) "Workspace:" header, which you can add
to
		indicate that you are checking out into a non-default
workspace (a
		Workspace is the resource that specifies how revision
selection occurs
		across the entire web-site, via a "revision-selection-rule"
property).

		   returns

		   HTTP/1.1 201 Created
		   Location: /foo/bar.html
		   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
		   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

		I'd omit the Location header (it's always created at the
place
		specified by the CHECKOUT).

		The Revision-Id is no longer necessary, since you either are
		checking out into the default workspace, or you are checking
		out into a specific workspace.  In any case, your workspace
		determines which version you see, so no Revision-Id's need
		to be passed in requests or reponses.

		And I'd just use the LOCK command following the CHECKOUT if
I want a
		LOCK, rather than bundling LOCK with CHECKOUT (I don't
believe the
		frequency of CHECKOUT warrants worrying about an extra LOCK
method call in
		this case).

		[CK] Very confusing.  How did you identify the checkout?
You don't have
		        a lock-token and you used the same URL?  If you
return a reivision-id
		        then it is part of the revision graph by definition.
This doesn't make sense.

		[CK]  In order for a lock to make sense, it must be atomic
with the checkout.
		         As well, there must be interaction between lock and
checkout.  That is,
		         Non-versioning-aware clients that use LOCK must be
able to block
		         Versioning-aware clients otherwise they will clash
and non-versioning
		         Clients will not be able to react.

		[CK]  I also disagree with your premise about locks.  I find
that people frequently
		         want exclusive locks when they checkout a resource
even if they have
		         merge facilities.  It is a process issue.

		   and the combination of URI and Revision-Id can then be
used for any
		   number of PUT and PROPPATCH operations.

		I agree (replacing "Revision-Id" with "optional
Workspace-Id").

		   When the user says

		   CHECKIN /foo/bar.html HTTP/1.1
		   Host: www.foobar.com
		   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
		   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>
		   ...

		   the current version is frozen, given a non-temporary name
(such as "1.2.1"),
		   and the lock is released.

		Yes (replacing Revision-Id with optional Workspace-Id, and
making the
		Lock-Token optional, in case you checked it out without a
lock).

		[CK] I think the Workspace-Id concept is confusing and adds
an extra layer
		        of burden on clients.  Maybe I just don't get it.

		   If they UNCHECKOUT that URI/revision-id
		   configuration, the revision quietly goes away.

		Yes (i.e. the "working-resource" goes away).

		   The same thing applies to configurations:  do they need
to exist
		   in special areas?

		In draft-clemm-webdav-versioning, configurations have a much
more
		constrained purpose (and definition) than in
draft-ietf-webdav-versioning.
		In particular, they are effectively the mechanism for
defining an
		immutable-revision of a tree of resources (rooted at some
collection).
		They can then be specified in the revision-selection-rule of
a workspace to
		cause the appropriate revisions to appear in that workspace
at the
		appropriate URL's.

		To illustrate the characteristics of the more constrained
definition,
		I'll answer Max's questions as if they were asked about the
more
		constrained definition.

		*** NOTE ***
		Max would not have asked these questions about the more
constrained
		definition ... he would have known the answers given below!
But his
		questions and suggestions are very good for illustrating why
the
		more constrained definition might be preferable.
		*** END NOTE ***

		   Couldn't they be a part of a user's home
		   directory on a server?  Direct references would make it
possible
		   to give the illusion of a configuration in your home
directory, but
		   now you have issues regarding cleaning up a user's files
when
		   moving their home directory from one machine to another
or removing
		   it entirely.

		Like other CM metadata such as a "branch" or a "label", you
would not
		normally expect to find one in your home directory.

		   Is a configuration so different from a collection that it
should be
		   treated as a separate sort of entity?  It looks like a
collection
		   that has a special sort of name (the configuration ID)
and holds
		   nothing but MKREF-created links to particular versions of
files.

		This is a read-only collection (it is immutable), and it is
just a flat
		list of revision references, with machine-generated names,
e.g.
		mem1, mem2, mem3.  So it's nothing a human would ever
directly use to find
		a revision of a particular resource (but is *is* something
that a
		workspace could use to efficiently find such a revision).

		   (An aside:  should it be possible to use MKREF to link to
a 
		   particular version of a file, allowing the reference to
provide the 
		   Revision-Id or Configuration-Id header to a client who
knows nothing 
		   of them?)  Are there any fundamental differences that
would make
		   it difficult to consider a configuration as a collection
with
		   some added rules and functionality?

		The creation of a configuration is an optimized
server-specific operation.
		Although it always results in a (read-only) collection, its
creation
		and storage will depend on factors that would not allow
direct
		creation or modification by a client.

		   Should configurations be able to contain other
configurations, or
		   simply references to them?  I can easily see that a
configuration's
		   user might wish to partition it when it gets large and
cluttered.

		Yes.

		[CK] I can see why you would want to have a configuration be
based on
		         another, but I don't understand containment.  If a
configuration is
		         a revision selection or a "thread" selection, then
containment makes
		         no sense?

		   I'm thinking of software development solutions:  a
configuration might
		   represent a project, with subconfigurations containing
subprojects.

		Yes.

		[CK] So the disconnect is becoming more clear here.  In -01,
a configuration
		        is viewed a the selection of a revision or a
revision thread.  In this
		        context, a configuration would not be a project, but
the project at a
		        point in time.

		   You'd want automatic inheritance from the core project so
any time
		   someone else added a file to the configuration, you got a
reference
		   to it.

		This is something you handle with workspace
revision-selection-rules,
		not with configurations (you can't add or remove files from
configurations,
		a configuration is immutable).

		   A large project with a couple of dozen subprojects would
		   otherwise be a pain to bring into a workspace, unless you
had a
		   development tool that dealt with all the repetetive
actions for you.

		Yes.

		   (Direct references to other configurations could be used
to 
		   provide the illusion of nested configurations, but would
require
		   a lot of transactions make the parent configuration and
then each
		   child configuration inheriting from the originals.)

		I'm not quite sure what this means, but I'd probably agree
with it
		if I did (:-).

		   Might there occasionally be call for having non-reference
members of
		   a configuration?  I could easily see a checkin set that
has no other
		   reason for existence than its membership in a workspace.

		Everything in a configuration is a reference to something
else
		(either a revision or another configuration).  To make
something be
		an immediate member would complicate the semantics with no
obvious
		benefit.

		   Regarding the specification of the BRANCH command:

		   Why was the decision made to use 

			  BRANCH VER:FHHR4959 HTTP/1.1
			  Host: www.foobar.com
			  Content-Type: text/html
			  Content-Length: xxxx

		   instead of 

			  BRANCH /foo/bar.html HTTP/1.1
			   Revision-Id: VER:FHHR4959
			  Host: www.foobar.com
			  Content-Type: text/html
			  Content-Length: xxxx

		I agree that it should be the latter (except that a
Workspace header
		rather than a Revision-Id should be passed in).  I also
prefer the
		method name "CHECKOUT-NEW", since this method is useful for
		non-branch based servers as well.

		   There has also been a massive growth in the number of
available DAV
		   properties.  PROPFIND allprop operations may lead to very
large
		   responses even with Depth: 1, which would slow down
performance
		   for users due to network speeds.  It might be worthwhile
to add this
		   facet to the open issue ALLPROP_AND_COMPUTED.

		I believe strongly that defining useful properties should
take
		precedence over any desire that ALLPROP should run fast.  I
personally
		would vote to just nuke ALLPROP as a mistake, but as long as
		clients know to never use it, I suppose it doesn't do that
much
		harm.

		   Regarding SETDEFAULT:  why is it specified as sending an
XML body?
		   It it seems that 
			   SETDEFAULT uri HTTP/1.1
			   Revision-Id: DAV:none
		   is equivalent to the request with a body and consistent
with
		   other usages in the specification.  Are there other data
that
		   may be used with SETDEFAULT at some point?

		I believe SETDEFAULT is unnecessary, once you have the
notion of
		a default workspace, and therefore should be removed from
the protocol.

		Cheers,
		Geoff


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 10:26:04 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA00853
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 10:26:04 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA10253
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 10:26:02 -0500 (EST)
Received: from tantalum by gw.atria.com id <KAA23664@gw.atria.com> Tue, 9 Feb 1999 10:26:00 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA28444; Tue, 9 Feb 1999 10:25:58 -0500
Date: Tue, 9 Feb 1999 10:25:58 -0500
Message-Id: <9902091525.AA28444@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757D19@RED-MSG-52> (message
	from Chris Kaler on Mon, 8 Feb 1999 22:52:22 -0800)
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt


I think I may see one possible source of disconnect between the two
protocol proposals.  I assume there are two key use cases:

- All persistent state is maintained on the web server.
The client can GET some data via some WebDAV client and manipulate it
in memory.  Whenever there is any new state to be preserved it is PUT
back to the web server.  This would be the case if you start some activity
at work, and then need to continue it from home, and all you've got at
home is an internet connection and a computer with a WebDAV client.

- Persistent state is shared between the client and the web server.
The client can GET some data via some WebDAV client, manipulate it in
memory, *and* store it locally.  This client doesn't need to
communicate as frequently with the web server, since it can cache
server state, and can make things persistent in its private persistent
store, but users need to effectively carry this client state around
with them.  This would be the case if you carried a laptop around with
you, or always dialed up directly to the same client machine to do remote
work.

I believe our protocol MUST handle both these use cases.  I suspect
that Chris has focused only on the second case.

In particular, my comments about the scalability of the WebDAV lock
mechanism is specifically directed at the first use case.  If there is
some lock token that must be remembered, then either users have to
check-in everything before they can go home (an unacceptable
requirement, in my opinion), remember all the lock tokens for what
they have checked out (now that will be a really popular option :-),
or store them all on the server somewhere, and have some mechanism for
downloading all the lock tokens all as a clump, once they have passed
some user authentication check.  I believe the last option, involving
user authentication, is the only viable long-term answer, and I expect
many clients will be willing to use the existing web-based user
authentication mechanisms, until WebDAV choses one as a "standard".
But WebDAV must define how information is stored into and retrieved
from the "clump" or we've blown any chance of client interoperability.

My rejection of server-defined temporaries as the location for checked
out resources is based on the same reasoning.

To support the first use case, my proposal asserts that a server is
responsible for maintaining working resources as human understandable
URL's, and parallel work is supported by having a single additional
identifier (the Workspace-ID) that the user must remember, to
distinguish his work from other users' work.

This proposal is based both on a logical analysis of this use case,
as well as the pragmatic observation that this is how virtually all
CM systems work: they provide a workspace with human understandable
"pathnames" (URL's) for the checked-out working resources.  It would
be hard to make current CM systems *not* work this way, and I think
producing a protocol that reflects how current systems do versioning
is an important criterion for evaluating a protocol proposal.

Soooo, with this lengthy preface in mind, let's get back to the
current thread of discussion ... 

   From: Chris Kaler <ckaler@microsoft.com>

   > From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   > ...  I believe the argument to CHECKOUT, CHECKIN, and UNCHECKOUT
   > should always be a consistent human-comprehensible URL.

   [CK] This requires then that a checkout token be passed as part of
   the request.  We can do this, but how then is a CHECKOUT different
   from a LOCK?

A CHECKOUT makes a readonly URL writeable.  A LOCK restricts who can
write to a writeable URL.

   >    There is a certain utility to having the magic files in a magic
   >    directory for ease of implementation-- you know you only have to
   >    treat a file in a special way if it's in a special location.  In
   >    my opinion, if you've already done the necessary work to make MKREF function,
   >    the additional amount needed to support checked-out files and
   >    configurations going anyplace should be small.

   > I agree.

   [CK] How then does one quickly discover the defined configurations?

Ooops.  I was agreeing with the comment wrt checked-out files.  I
agree with Chris that versioning meta-data (such as workspaces,
configurations and activities) should be stored in standard places, so
that they can be easily discovered/browsed.

   > Also, I would want the "lock" to be optional (I don't think the "lock"
   > mechanism scales well, and want it to be an optional part of the
   > versioning protocol).  Again, I believe this is not an essential part
   > of your point.

   [CK] The lock portion is option in -01.  I'm curious as to why you
   don't think the lock mechanism will scale?

See comments above.

   >    (i.e.  
   >    CHECKOUT /foo/bar.html HTTP/1.1
   >    Host: www.foobar.com
   >    ...

   >    returns

   >    HTTP/1.1 201 Created
   >    Location: /foo/bar.html
   >    Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   >    Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

   > I'd omit the Location header (it's always created at the place
   > specified by the CHECKOUT).
   > The Revision-Id is no longer necessary, since you either are
   > checking out into the default workspace, or you are checking
   > out into a specific workspace.  In any case, your workspace
   > determines which version you see, so no Revision-Id's need
   > to be passed in requests or reponses.

   [CK] Very confusing.  How did you identify the checkout?

Every workspace has at most one checkout at a given URL.  If you
tried to check it out again, it would say "already checked out".
So if you have a URL (and optionally, a workspace ID), you have all you need.

   You don't have a lock-token and you used the same URL?

Sure.  Before the CHECKOUT, the URL referred to an immutable revision.
After the CHECKOUT, it referred to a working resource.  Where is a
lock-token required to identify what has been checked-out?

   If you return a
   reivision-id then it is part of the revision graph by definition. This
   doesn't make sense.

I don't follow what you are saying here ... (but I do agree that
this doesn't make sense, for an appropriate value of "this" :-).

   > And I'd just use the LOCK command following the CHECKOUT if I want a
   > LOCK, rather than bundling LOCK with CHECKOUT (I don't believe the
   > frequency of CHECKOUT warrants worrying about an extra LOCK method call in
   > this case).

   [CK] In order for a lock to make sense, it must be atomic with the
   checkout.

Why?  You check something out to make it writeable.  If somebody jumps
in ahead of you to get a LOCK, so be it.  That just means that they
also wanted to work on it, and they beat you to it.  No different from
them beating you to a combined CHECKOUT/LOCK command.

   As well, there must be interaction between lock and
   checkout.  That is, Non-versioning-aware clients that use LOCK must be
   able to block Versioning-aware clients otherwise they will clash and
   non-versioning Clients will not be able to react.

I'd have to see a description of the particular clash you have in mind.
Some clashes in locking are inavoidable, as we have discovered in
work out the details of locking and advanced collections interact.

   [CK] I also disagree with your premise about locks.  I find that
   people frequently want exclusive locks when they checkout a resource
   even if they have merge facilities.  It is a process issue.

And some people don't want exclusive locks.
And some people don't want to use WebDAV locks to specify access control.
Which is why I resist any proposal to inextricably link WebDAV locks
with the orthogonal notion of CHECKOUT.

   [CK] I think the Workspace-Id concept is confusing and adds an extra
   layer of burden on clients.  Maybe I just don't get it.

In VSS, it's a "sandbox".  In ClearCase it's a "view".  In many/most other
CM systems, it's called a "workspace".  They've all got the concept, and
any client that doesn't understand it won't be able to interoperate in a
simple with any of the existing CM systems.

This may just be confusion over terminology ... if we get a common set
of definitions for "configuration" and "workspace" this week in Utah,
this confusion may just disappear (well, it's at least a possibility :-).

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 10:45:58 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA01564
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 10:45:57 -0500 (EST)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA10512
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 10:45:55 -0500 (EST)
>From: jamsden@us.ibm.com
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id KAA120460
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 10:45:23 -0500
Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35])
	by southrelay01.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id KAA50382
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 10:45:51 -0500
Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256713.005697A6 ; Tue, 9 Feb 1999 10:45:49 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256713.00569673.00@d54mta03.raleigh.ibm.com>
Date: Tue, 9 Feb 1999 10:39:43 -0500
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC"
Content-Disposition: inline
Subject: Updated WebDAV Versioning Model

--0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Attached is an update to the proposed WebDAV versioning model. I had time
to clean up some of the grammar, and to fill in some gaps in the semantics.

(See attached file: vermod.gif)(See attached file: exampleHistory.gif)(See
attached file: versioning.htm)

--0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC
Content-type: image/gif; 
	name="vermod.gif"
Content-Disposition: attachment; filename="vermod.gif"
Content-transfer-encoding: base64
Content-Description: Compuserve GIF


NVql9ZcCAgA7

--0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC
Content-type: image/gif; 
	name="exampleHistory.gif"
Content-Disposition: attachment; filename="exampleHistory.gif"
Content-transfer-encoding: base64
Content-Description: Compuserve GIF


TLKF28ESvKsgzL4kPMLd+7EmnLjtlsL8hK8s7FGp+8K1ExAAOw==

--0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC
Content-type: text/html; 
	name="versioning.htm"
Content-Disposition: attachment; filename="versioning.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML


cD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--0__=TwRKRRv9AaZUlB5iXjDSEQO2kAmwuN6WnR5ZZKAoytkNvTNj93W3eHNC--


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 14:11:16 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06578
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 14:11:15 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13438
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 14:11:13 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id LAA20219
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 11:05:16 -0800 (PST)
Message-Id: <4.1.19990209101250.00a19bd0@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 09 Feb 1999 11:04:47 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Max Rible <max@glyphica.com>
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757D18@RED-MSG-52>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

At 22:39 2/8/99 -0800, Chris Kaler wrote:
>[CK] In the -00 draft it was proposed that CHECKOUT/IN use the LOCK method
>        since the behavior is very similar to locks.  The working group
>        decided against this.  Note that this style approach would resolve 
>        your issue above as well.  Maybe we should model this as LOCK and 
>        return a checkout token as you suggest.  This token would then 
>        be passed in on CHECKIN.  I guess the question I have then is,
>        how is this different from LOCK?

LOCK gives you a token that may expire at any time for mysterious reasons.
CHECKOUT should give you a token that persists until CHECKIN or 
UNCHECKOUT.  

There are a couple of ways to look at CHECKOUT.  One is Geoffrey's 
"A CHECKOUT makes a readonly URL writeable.  A LOCK restricts who can
write to a writeable URL."  In this case, for the usual source control
functionality, you would LOCK a resource, then perform a CHECKOUT, and no 
one else would be able to do anything until you perform a CHECKIN and 
UNLOCK it.  If you simply did a CHECKOUT, *anyone* could write to
the resource, and *anyone* could do a CHECKIN on it.

The current proposal for CHECKOUT does not restrict the number of
CHECKOUTs against a single resource.  The reason I suggested a 
CHECKOUT token is that you would be able to maintain this functionality
if you received a Checkout-Token on doing a CHECKOUT.  Any access
of a given URL with the appropriate Checkout-Token for the URL will
get you the data pertaining to that CHECKOUT-- you can PUT and PROPPATCH
using the Checkout-Token all you want, until you perform the CHECKIN.

If you have multiple checkouts of the same file, the first person to
do a CHECKIN creates the next version; at this point, all other people
with CHECKOUTs of the file have to either BRANCH from the version they
checked out, perform a CHECKOUT of the new version, UNCHECKOUT the
old one, make the changes to the new version, and do a CHECKIN, or
apply the new version's changes to their current CHECKOUT and 
do a CHECKIN with the Override-Checkin header turned on.  (This
appears to be the behavior in section 3 of the latest document,
anyway.)  They find out about this when their CHECKIN fails--
presumably with 412 Precondition Failed? 424 Failed Dependency?
409 Conflict?

>[CK] If they live anywhere in the namespace, getting a list of the defined
>        configurations is quite hard.  That was the idea for putting them 
>        in a "well known" place.

Is there a need to get a list of defined configurations?  If the
header you're passing for a configuration is the URI of the configuration
on that server, there's no extra time spent in looking it up.

>[CK] Our idea was that a the /c/Beta1 would contain references to the
>        resources in the configuration.  If a configuration contains 
>        another configuration, how would you represent that?

If a configuration is something you navigate into because it is,
in itself, a view of a project, it makes sense to have subconfigurations;
if it is just a token you pass in so you see a particular version 
when looking at a given URL, it no longer makes sense to have 
subconfigurations.

>[CK] Its clear that we need much more verbage in the document.  I'm not sure
>     I followed the "logging in" part.

I'm considering the way that configurations would manifest at a
user interface level.  At some point, the user needs to tell their
software what configuration to use for accessing a server.  The choice
of configuration would be the equivalent of acquiring an environment
when logging in to a machine.

If a user is attempting to do work involving two different configurations
on the same machine, things could get complicated when persuading their
interface to switch back and forth.  For instance, consider the case where
a project has been BRANCHed after the 1.0 release.  One branch is
used for bug fixes to the 1.0 code, while the other is used for developing
the next 1.1 release.  If a bug is found that needs patching in both
branches, it should not be immensely difficult for a user to switch
back and forth between configurations.

Another, similar case is the one for two projects that need related
changes made-- such as to a WebDAV client and server when a new document
comes out from the working group. :-)  One configuration exists for
the client, and another for the server.  Many programmers would 
implement each feature in turn on the server and the client, testing
as they go, rather than implementing them all on the server and then
all on the client.  If all files remain checked out the whole time,
that might not be too hard, but if the programmer does a check-in after
each feature has been implemented and tested on both ends, it could
be a lot of work to keep switching configurations between the one for
the client and the one for the server. 

>What other information would go in with SETDEFAULT?  For that matter, is
>SETDEFAULT really doing anything you couldn't with PROPPATCH?  If I'd read
>that SETDEFAULT functionality was to be implemented with a live property
>named DAV:defualtversion, I wouldn't have blinked...

>[CK] We debated this one for a while.  The issue really comes up with
>        references.  

Aha.  It might be good to explicitly call out references for
"If a resource is shared, servers MUST support the ability to set
different default revisions at each point of the share."

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 14:12:32 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06736
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 14:12:32 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA13463
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 14:12:30 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa04847;
          9 Feb 99 11:02 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 9 Feb 1999 10:59:41 -0800
Message-ID: <000f01be545e$59bd74c0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: FW: Internet-Draft Cut-off Date

FYI.

- Jim

-----Original Message-----
>From: Cynthia Clark [mailto:cclark@ns.cnri.reston.va.us] 
Sent: Tuesday, February 09, 1999 8:35 AM
To: IETF-Announce: ;
Subject: Internet-Draft Cut-off Date



The cut-off for Internet-Draft submissions prior to the
Minneapolis IETF meeting is Friday, February 26, 1999 
at 5pm ET. Internet-Drafts received after this time will not be 
announced nor made available in the Internet-drafts Directories.

We will begin processing Internet-Draft submissions the week
following the IETF meeting.

Thank you for your understanding and cooperation. Please do not
hesitate to contact me if you have any questions or concerns.

Cynthia Clark
IETF Internet-Drafts Administrator
<cclark@ietf.org>


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 15:23:55 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA08555
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 15:23:55 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA14165
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 15:23:53 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA08539
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 15:23:51 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1SS020QL>; Tue, 9 Feb 1999 12:23:03 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D24@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, w3c-dist-auth@w3.org
Date: Tue, 9 Feb 1999 12:22:56 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Interesting summary... thanks Geoff.

My assumption has been that the protocol returns tokens to
the client.  The client can choose to remember them locally
or store them on the server is a well defined place.  But 
this is up to the client.  I guess I don't see the need for
the protocol to understand both, since the client can easily
persist the tokens back to the server.  

Maybe this is an interesting optimization where we have a 
header on requests that specifies where on the server to
store the information.  But then you need a discovery mechanism.
The beauty of leaving it to the client is that standard DAV
mechanism, e.g. PROPFIND and PUT, can be used.

Chris

-----Original Message-----
>From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Tuesday, February 09, 1999 7:26 AM
To: w3c-dist-auth@w3.org
Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt



I think I may see one possible source of disconnect between the two
protocol proposals.  I assume there are two key use cases:

- All persistent state is maintained on the web server.
The client can GET some data via some WebDAV client and manipulate it
in memory.  Whenever there is any new state to be preserved it is PUT
back to the web server.  This would be the case if you start some activity
at work, and then need to continue it from home, and all you've got at
home is an internet connection and a computer with a WebDAV client.

- Persistent state is shared between the client and the web server.
The client can GET some data via some WebDAV client, manipulate it in
memory, *and* store it locally.  This client doesn't need to
communicate as frequently with the web server, since it can cache
server state, and can make things persistent in its private persistent
store, but users need to effectively carry this client state around
with them.  This would be the case if you carried a laptop around with
you, or always dialed up directly to the same client machine to do remote
work.

I believe our protocol MUST handle both these use cases.  I suspect
that Chris has focused only on the second case.

In particular, my comments about the scalability of the WebDAV lock
mechanism is specifically directed at the first use case.  If there is
some lock token that must be remembered, then either users have to
check-in everything before they can go home (an unacceptable
requirement, in my opinion), remember all the lock tokens for what
they have checked out (now that will be a really popular option :-),
or store them all on the server somewhere, and have some mechanism for
downloading all the lock tokens all as a clump, once they have passed
some user authentication check.  I believe the last option, involving
user authentication, is the only viable long-term answer, and I expect
many clients will be willing to use the existing web-based user
authentication mechanisms, until WebDAV choses one as a "standard".
But WebDAV must define how information is stored into and retrieved
from the "clump" or we've blown any chance of client interoperability.

My rejection of server-defined temporaries as the location for checked
out resources is based on the same reasoning.

To support the first use case, my proposal asserts that a server is
responsible for maintaining working resources as human understandable
URL's, and parallel work is supported by having a single additional
identifier (the Workspace-ID) that the user must remember, to
distinguish his work from other users' work.

This proposal is based both on a logical analysis of this use case,
as well as the pragmatic observation that this is how virtually all
CM systems work: they provide a workspace with human understandable
"pathnames" (URL's) for the checked-out working resources.  It would
be hard to make current CM systems *not* work this way, and I think
producing a protocol that reflects how current systems do versioning
is an important criterion for evaluating a protocol proposal.

Soooo, with this lengthy preface in mind, let's get back to the
current thread of discussion ... 

   From: Chris Kaler <ckaler@microsoft.com>

   > From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   > ...  I believe the argument to CHECKOUT, CHECKIN, and UNCHECKOUT
   > should always be a consistent human-comprehensible URL.

   [CK] This requires then that a checkout token be passed as part of
   the request.  We can do this, but how then is a CHECKOUT different
   from a LOCK?

A CHECKOUT makes a readonly URL writeable.  A LOCK restricts who can
write to a writeable URL.

   >    There is a certain utility to having the magic files in a magic
   >    directory for ease of implementation-- you know you only have to
   >    treat a file in a special way if it's in a special location.  In
   >    my opinion, if you've already done the necessary work to make MKREF
function,
   >    the additional amount needed to support checked-out files and
   >    configurations going anyplace should be small.

   > I agree.

   [CK] How then does one quickly discover the defined configurations?

Ooops.  I was agreeing with the comment wrt checked-out files.  I
agree with Chris that versioning meta-data (such as workspaces,
configurations and activities) should be stored in standard places, so
that they can be easily discovered/browsed.

   > Also, I would want the "lock" to be optional (I don't think the "lock"
   > mechanism scales well, and want it to be an optional part of the
   > versioning protocol).  Again, I believe this is not an essential part
   > of your point.

   [CK] The lock portion is option in -01.  I'm curious as to why you
   don't think the lock mechanism will scale?

See comments above.

   >    (i.e.  
   >    CHECKOUT /foo/bar.html HTTP/1.1
   >    Host: www.foobar.com
   >    ...

   >    returns

   >    HTTP/1.1 201 Created
   >    Location: /foo/bar.html
   >    Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   >    Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

   > I'd omit the Location header (it's always created at the place
   > specified by the CHECKOUT).
   > The Revision-Id is no longer necessary, since you either are
   > checking out into the default workspace, or you are checking
   > out into a specific workspace.  In any case, your workspace
   > determines which version you see, so no Revision-Id's need
   > to be passed in requests or reponses.

   [CK] Very confusing.  How did you identify the checkout?

Every workspace has at most one checkout at a given URL.  If you
tried to check it out again, it would say "already checked out".
So if you have a URL (and optionally, a workspace ID), you have all you
need.

   You don't have a lock-token and you used the same URL?

Sure.  Before the CHECKOUT, the URL referred to an immutable revision.
After the CHECKOUT, it referred to a working resource.  Where is a
lock-token required to identify what has been checked-out?

   If you return a
   reivision-id then it is part of the revision graph by definition. This
   doesn't make sense.

I don't follow what you are saying here ... (but I do agree that
this doesn't make sense, for an appropriate value of "this" :-).

   > And I'd just use the LOCK command following the CHECKOUT if I want a
   > LOCK, rather than bundling LOCK with CHECKOUT (I don't believe the
   > frequency of CHECKOUT warrants worrying about an extra LOCK method call
in
   > this case).

   [CK] In order for a lock to make sense, it must be atomic with the
   checkout.

Why?  You check something out to make it writeable.  If somebody jumps
in ahead of you to get a LOCK, so be it.  That just means that they
also wanted to work on it, and they beat you to it.  No different from
them beating you to a combined CHECKOUT/LOCK command.

   As well, there must be interaction between lock and
   checkout.  That is, Non-versioning-aware clients that use LOCK must be
   able to block Versioning-aware clients otherwise they will clash and
   non-versioning Clients will not be able to react.

I'd have to see a description of the particular clash you have in mind.
Some clashes in locking are inavoidable, as we have discovered in
work out the details of locking and advanced collections interact.

   [CK] I also disagree with your premise about locks.  I find that
   people frequently want exclusive locks when they checkout a resource
   even if they have merge facilities.  It is a process issue.

And some people don't want exclusive locks.
And some people don't want to use WebDAV locks to specify access control.
Which is why I resist any proposal to inextricably link WebDAV locks
with the orthogonal notion of CHECKOUT.

   [CK] I think the Workspace-Id concept is confusing and adds an extra
   layer of burden on clients.  Maybe I just don't get it.

In VSS, it's a "sandbox".  In ClearCase it's a "view".  In many/most other
CM systems, it's called a "workspace".  They've all got the concept, and
any client that doesn't understand it won't be able to interoperate in a
simple with any of the existing CM systems.

This may just be confusion over terminology ... if we get a common set
of definitions for "configuration" and "workspace" this week in Utah,
this confusion may just disappear (well, it's at least a possibility :-).

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 15:35:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA09053
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 15:35:41 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA14288
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 15:35:40 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <D8HCR1G8>; Tue, 9 Feb 1999 12:35:35 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D25@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Max Rible'" <max@glyphica.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 9 Feb 1999 12:35:25 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Comments below...  

hopefully my mailer won't munge the file like it did yesterday.
Sorry about that!

-----Original Message-----
>From: Max Rible [mailto:max@glyphica.com]
Sent: Tuesday, February 09, 1999 11:05 AM
To: WEBDAV WG
Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt


At 22:39 2/8/99 -0800, Chris Kaler wrote:
>[CK] In the -00 draft it was proposed that CHECKOUT/IN use the LOCK method
>        since the behavior is very similar to locks.  The working group
>        decided against this.  Note that this style approach would resolve 
>        your issue above as well.  Maybe we should model this as LOCK and 
>        return a checkout token as you suggest.  This token would then 
>        be passed in on CHECKIN.  I guess the question I have then is,
>        how is this different from LOCK?

LOCK gives you a token that may expire at any time for mysterious reasons.
CHECKOUT should give you a token that persists until CHECKIN or 
UNCHECKOUT.  

CK>> I can take an infinite lock

There are a couple of ways to look at CHECKOUT.  One is Geoffrey's 
"A CHECKOUT makes a readonly URL writeable.  A LOCK restricts who can
write to a writeable URL."  In this case, for the usual source control
functionality, you would LOCK a resource, then perform a CHECKOUT, and no 
one else would be able to do anything until you perform a CHECKIN and 
UNLOCK it.  If you simply did a CHECKOUT, *anyone* could write to
the resource, and *anyone* could do a CHECKIN on it.

CK>> As you point out in the paragraph below, this model doesn't
CK>> support multiple checkouts.  Note that I do not believe this
CK>> is what Geoff meant.  He was using a token to distinguish
CK>> each checkout.

The current proposal for CHECKOUT does not restrict the number of
CHECKOUTs against a single resource.  The reason I suggested a 
CHECKOUT token is that you would be able to maintain this functionality
if you received a Checkout-Token on doing a CHECKOUT.  Any access
of a given URL with the appropriate Checkout-Token for the URL will
get you the data pertaining to that CHECKOUT-- you can PUT and PROPPATCH
using the Checkout-Token all you want, until you perform the CHECKIN.

CK>> However, for the case where you need to lock and checkout, which
CK>> I would argue is very common even if you take a shared lock, the
CK>> client needs to track multiple tokens and include them in the header.
CK>> I'm just trying to point out that LOCK and CHECKOUT have very
CK>> similar behavior and would be implemented the same in the server.

If you have multiple checkouts of the same file, the first person to
do a CHECKIN creates the next version; at this point, all other people
with CHECKOUTs of the file have to either BRANCH from the version they
checked out, perform a CHECKOUT of the new version, UNCHECKOUT the
old one, make the changes to the new version, and do a CHECKIN, or
apply the new version's changes to their current CHECKOUT and 
do a CHECKIN with the Override-Checkin header turned on.  (This
appears to be the behavior in section 3 of the latest document,
anyway.)  They find out about this when their CHECKIN fails--
presumably with 412 Precondition Failed? 424 Failed Dependency?
409 Conflict?

CK>> Exactly.  We haven't gotten to the level of selecting the
CK>> error condition, although any of the 3 you listed would be
CK>> reasonable.

>[CK] If they live anywhere in the namespace, getting a list of the defined
>        configurations is quite hard.  That was the idea for putting them 
>        in a "well known" place.

Is there a need to get a list of defined configurations?  If the
header you're passing for a configuration is the URI of the configuration
on that server, there's no extra time spent in looking it up.

CK>> It is not hard to imagine that a client might want to provide
CK>> the user the ability to select a configuration to use.  To do
CK>> so, it must generate a list.  If configurations are anywhere
CK>> in the namespace, then you have to search the entire namespace
CK>> to produce the list.

>[CK] Our idea was that a the /c/Beta1 would contain references to the
>        resources in the configuration.  If a configuration contains 
>        another configuration, how would you represent that?

If a configuration is something you navigate into because it is,
in itself, a view of a project, it makes sense to have subconfigurations;
if it is just a token you pass in so you see a particular version 
when looking at a given URL, it no longer makes sense to have 
subconfigurations.

CK>> There is still lots of debate here, so let me state this is just
CK>> my view.  I believe configurations, as defined in -01, serve two
CK>> purposes. Dynamic configurations provide a reliable way to select
CK>> specific revisions of identified resources.  Workspace configurations
CK>> provide a way to track changes to related resources.  That is,
CK>> a branch across a project.  In the terms section, we talk about a
CK>> thread as a sequence of changes.  Workspace configurations are the
CK>> related threads of multiple resources.  For example, Beta1 of my
CK>> project.

>[CK] Its clear that we need much more verbage in the document.  I'm not
sure
>     I followed the "logging in" part.

I'm considering the way that configurations would manifest at a
user interface level.  At some point, the user needs to tell their
software what configuration to use for accessing a server.  The choice
of configuration would be the equivalent of acquiring an environment
when logging in to a machine.

CK>> I see.  However, I think you can easily switch your "view" of the
CK>> the versioning database.

If a user is attempting to do work involving two different configurations
on the same machine, things could get complicated when persuading their
interface to switch back and forth.  For instance, consider the case where
a project has been BRANCHed after the 1.0 release.  One branch is
used for bug fixes to the 1.0 code, while the other is used for developing
the next 1.1 release.  If a bug is found that needs patching in both
branches, it should not be immensely difficult for a user to switch
back and forth between configurations.

CK>> I totally agree.  From a protocol perspective, it is as easy
CK>> as changing the value of the Configuration-Id header.

Another, similar case is the one for two projects that need related
changes made-- such as to a WebDAV client and server when a new document
comes out from the working group. :-)  One configuration exists for
the client, and another for the server.  Many programmers would 
implement each feature in turn on the server and the client, testing
as they go, rather than implementing them all on the server and then
all on the client.  If all files remain checked out the whole time,
that might not be too hard, but if the programmer does a check-in after
each feature has been implemented and tested on both ends, it could
be a lot of work to keep switching configurations between the one for
the client and the one for the server. 

CK>> Although they could use a separate configuration to "stage"
CK>> the visibility of the change.

>What other information would go in with SETDEFAULT?  For that matter, is
>SETDEFAULT really doing anything you couldn't with PROPPATCH?  If I'd read
>that SETDEFAULT functionality was to be implemented with a live property
>named DAV:defualtversion, I wouldn't have blinked...

>[CK] We debated this one for a while.  The issue really comes up with
>        references.  

Aha.  It might be good to explicitly call out references for
"If a resource is shared, servers MUST support the ability to set
different default revisions at each point of the share."

CK>> I thought we did.  If we didn't, and I can believe it got lost
CK>> in the editing, I'll make sure it is in the next revision.


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 16:56:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA10511
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 16:56:41 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id QAA15217;
	Tue, 9 Feb 1999 16:56:38 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa22180;
          9 Feb 99 13:48 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Cc: Versioning <ietf-dav-versioning@w3.org>
Date: Tue, 9 Feb 1999 13:45:49 -0800
Message-ID: <001401be5475$8ed3bae0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Proposed charter for versioning WG


One characteristic of the IETF which distinguishes it from other standards
development organizations is the IETF requires its working groups to have
finite lifespans, and to close after its work has been complete.  This is
motivated by a desire not to have working groups keep expanding their
mission to self-perpetuate, and to ensure that the working group doesn't get
"stale" with the same cast of characters rehashing the same issues.

Now, I don't think the WebDAV working group has fallen into any of these
traps yet -- we continue to make good progress on the versioning protocol,
and the advanced collections protocol.  We haven't strayed from our original
charter.  Now that the WebDAV Distriubted Authoring protocol has been
approved, we're starting to see lots of public announcements by companies of
their WebDAV product plans (see http://www.webdav.org/projects/).  There is
also increasing interest in open source development of WebDAV applications,
significantly helped by Greg Stein's webdav.org site.  All these are signs
of robust health.

So, you might ask, if it ain't broke, why fix it?  Well, one good reason is
that Keith Moore, our Applications Area advisor thinks the time is right.
But, more generally, I look at it as a case of preventative medicine.  By
creating a separate versioning working group, with its own separate charter,
several positive goals are accomplished:

 * It sends a signal that new people can become involved and participate.

   While it's always the case that new people can get involved in an
   IETF effort, it's often difficult to know when you can get involved
   without annoying people who have been working on the topic for awhile.
   For example, Mark Anderson's comments on draft-ietf-webdav-protocol-09
   last fall were well intentioned, but had terrible timing.

 * It provides the opportunity to refresh the agreement over what work is
being done.

   Most people on the mailing list today didn't have a chance to discuss the
   original WebDAV charter.  Even if there is common agreement that the
charter
   of the versioning working group should continue in the same vein as
current
   efforts, it still is worthwhile to make sure that *current* list members
   agree with the goals.

 * It forces people to explicitly subscribe to a new mailing list.

   Though it may seem funny to list this as a positive, working group
mailing
   lists tend to attract a lot of lurkers over time, people who want to
track an
   effort rather than being an active participant.  You might be surprised
to
   know that the WebDAV mailing list now has appx. 350 people on it!
Obviously
   you're not all active participants :-) (Although I very much appreciate
   having such a large pool of people to call on for volunteers for various
   activities). By causing people to reaffirm their interest by joining a
new
   list, it tends to "refresh" the membership.

 * It allows the burden of work to be more evenly shared.

   This one is more of a personal motivation, but it does impact the
   working group as a whole.  The motivation and ability to participate
   of the hardest working people in a working group is hard to sustain
   over several years, and it's good to have some rotation of duties.
   If too much is asked of the same people for too long, the working
   group suffers immensely when they, inevitably, are no longer able to
   participate any longer.

Many of you know that I have been working towards my Ph.D. degree while
being chair of WebDAV.  And, truth be told, my participation has definitely
delayed my graduation.  I have no regrets -- this has been an excellent
experience, the kind of activity I wanted to be able to work on during grad.
school.  Plus, interacting with members of the working group has been very
rewarding, both professionally and personally.  Still, I'm at least a year
away from graduation if I have complete focus on my degree, and I need to
get more of WebDAV off my plate to do this.

So, while I still intend to continue on as chair of the WebDAV working
group, working to finish up advanced collections, and work on issues from
the issues list, and resolve any interoperability problems that may arise, I
intend that the efforts on versioning and advanced collections will form new
working groups.  I will not chair those new groups, though I will help form
them, and make sure they get a good start.  My goal is to create continuity
from the current WebDAV working group into the new working groups, to make
sure none of the momentum we have is lost.

There is successful precedent for this in the DASL working group, which has
been making steady progress towards defining a searching protocol for DAV
resources (http://www.ics.uci.edu/pub/ietf/dasl/).  DASL shows the strength
of creating a new working group -- it has a different set of people working
on it than who developed the base WebDAV protocol, people who have deep
searching experience.  Their mailing list collected people who had interest
in the searching problem, helping ensure that their discussions are focused,
and not lost in other topics on the main DAV list.  DASL is the right model
for what the working groups on versioning and access control can accomplish.

At the bottom of this message is a proposed charter for the versioning
working group, which I have tentatively named "DELTA-V" (you know, to
emphasize they're creating extensions to DAV -- "delta" -- and are working
on the "V" part of DAV. :-)  I'd appreciate any comments you have on the
charter -- send them to the main WebDAV list.  You can also expect to see
another charter in the near future to develop an access control working
group, but I don't have this one done yet.

I look forward to working with you to develop these new working groups, and
to setting the stage for the completion of the original WebDAV goals,
creating a writeable, versioned collaborative Web.

- Jim

---------------------------------------


Web Versioning and Configuration Management (DELTA-V)

Chair(s):

TBD (Though Jim Whitehead emphatically declines to be chair)

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

TBD, probably Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion: ietf-dav-versioning@w3.org
To Subscribe: ietf-dav-versioning-request@w3.org
Subject: subscribe
Archive: http://lists.w3.org/Archives/Public/ietf-dav-versioning/

Description of Working Group:

xThis working group will define extensions to HTTP and the WebDAV
Distributed Authoring Protocol necessary to enable distributed Web
authoring tools to perform, in an interoperable manner, versioning and
configuration management of Web resources.

Versioning, parallel development, and configuration management are
important features for remote authoring of Web content.  Version
management is concerned with tracking and accessing the history of
important states of a single Web resource, such as a standalone Web
page.  Parallel development provides additional resource availability
in multi-user, distributed environments, letting authors make changes
on the same resource at the same time, later merging together those
changes. Configuration management addresses the problems of tracking
and accessing multiple interrelated resources over time as sets of
resources, not simply individual resources.  Traditionally, artifacts
of software development, including code, design, test cases,
requirements, help files, and more have been a focus of configuration
management. Web sites, comprised of multiple inter-linked resources
(HTML, graphics, sound, CGI, and others), are an important class of
complex information artifacts that benefit from the application of
configuration management.

The WebDAV working group originally focused on defining version
management capabilities for remote authoring applications. However, it
has become clear that while versioning functionality alone is useful
for a range of content authoring scenarios involving one, or a small
set of resources, versioning alone is insufficient for managing larger
sets of content. Protocol support for parallel development and simple
remote configuration management of Web resources provides
functionality for managing larger sets of interrelated content
developed by multiple users at different locations.

A sub-group of the WebDAV working group has developed functional
requirements for versioning and configuration management of Web
content. These requirements encompass the following capabilities,
which shall be considered by this working group:

IN-SCOPE:

* Naming and accessing resource versions and configurations
* Creating new revisions of a resource
* Placing a resource under version and configuration control
* History retrieval
* Differencing
* Merging of revisions and configurations
* Operations on configurations
* Mapping resource versions and configurations to the URL namespace
* Versioning support for downlevel HTTP and WebDAV clients

Further information on these objectives can be found in the document,
"Goals for Web Versioning".

NOT IN SCOPE:

* HTTP server to server communication protocols
* Versioning and configuration management via non-HTTP and WebDAV protocols.
* Implementation of functionality by non-origin proxies

Deliverables

The final output of this working group is expected to be two documents:

1. A goals document, which describes the high-level functional
   requirements for remote versioning and configuration management,
   including rationale. Jim Amsden, IBM, is editor of this document.

2. A model document, which describes the semantics of versioning,
   configuration management, and parallel development in a
   protocol independent fashion.  Editor: TBD

2. A protocol specification, which describes new HTTP methods,
   headers, request bodies, response bodies, and WebDAV properties to
   implement the remote versioning and configuration management
   goals. Chris Kaler, Microsoft, is editor of this document.

Goals and Milestones:

Since significant work on remote versioning and configuration
management has already taken place within the WebDAV working group,
the following schedule is a reasonable estimate of the remaining
effort, despite the scope of the working group.

Jun 99 (Specification, Goals, Model) Produce drafts of distributed
       versioning and configuration management protocol specification,
       as well as the goals and requirements documents. Submit as
       Internet Draft.

Jul 99 (Meeting, Specification, Goals, Model) Meet at Oslo IETF and
       hold working group meeting to review the protocol specification,
       goals, and model document.

Oct 99 (Goals) Create final version of distributed versioning and
       configuration management goals document. Submit for approval as
       Informational RFC.

Oct 99 (Specification, Model) Produce revised model document, and
       distributed versioning and configuration management protocol
       specification. Submit both as Internet Drafts.

Nov 99 (Meeting, Specification, Model) Meet at Washington, DC IETF and
       hold working group meeting to review the model document and the
       distributed versioning and configuration management protocol
       specification.

Feb 00 (Specification, Model) Submit revised model document, and
       distributed versioning and configuration management
       specification as Internet Drafts.

Mar 00 (Meeting, Specification, Model) Meet at Adelaide IETF and hold
       working group meeting to review the model document and
       distributed versioning and configuration management protocol
       specification.

Apr 00 (Specification, Model) Submit revised model document and
       distributed versioning and configuration management
       specification as Internet Draft.  Hold working group last call
       for comments on both drafts.

May 00 (Specification, Model) Revise model document and distributed
       versioning and configuration management specification based on
       working group last call comments, and submit both documents to
       the IESG for approval as a Proposed Standard RFC.



From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 18:07:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12041
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 18:07:23 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA15978
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 18:07:21 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id PAA12026;
	Tue, 9 Feb 1999 15:07:09 -0800
Sender: gstein@lyra.org
Message-ID: <36C0BF9C.5259D8D3@lyra.org>
Date: Tue, 09 Feb 1999 15:07:08 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
CC: dav-announce@lyra.org, dav-dev@lyra.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: RFC 2518

Taking a peek into ftp://ftp.isi.edu/in-notes/rfc-index.txt shows that
it is official...

RFC 2518: HTTP Extensions for Distributed Authoring -- WEBDAV


woo!

-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 18:40:47 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12473
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 18:40:47 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA16318
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 18:40:44 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa03612;
          9 Feb 99 15:29 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Greg Stein <gstein@lyra.org>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Cc: dav-announce@lyra.org, dav-dev@lyra.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Tue, 9 Feb 1999 15:26:22 -0800
Message-ID: <000101be5483$9b038260$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <36C0BF9C.5259D8D3@lyra.org>
Subject: RE: RFC 2518

Whoa!  The RFC editors put RFCs on the FTP directory before they're
officially released, so the authors can send feedback.  So, this file
probably isn't (yet) in its final form.  But, based on my review of it,
there are no major changes that need to be made, just spelling corrections.
So, if you download it today, you'll be fine, it just won't be the *final*
version.

When the RFC editors are done (any day now), it'll be posted on the
ietf-annouce mailing list.  But, yeah, our RFC number does definitely look
like it's RFC 2518.

And you bet I'm excited about it!!

- Jim

> Taking a peek into ftp://ftp.isi.edu/in-notes/rfc-index.txt shows that
> it is official...
>
> RFC 2518: HTTP Extensions for Distributed Authoring -- WEBDAV
>
>
> woo!
>
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 18:56:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12839
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 18:56:16 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA16482
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 18:56:14 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa05597;
          9 Feb 99 15:47 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 9 Feb 1999 15:45:06 -0800
Message-ID: <000201be5486$38a46000$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Collections conference call minutes

The minutes from today's advanced collections conference call are available
on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990209.txt

Thank you Judy for generating these minutes so quickly!!

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Feb  9 18:56:18 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA12850
	for <w3c-dist-auth@www19.w3.org>; Tue, 9 Feb 1999 18:56:17 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA16484
	for <w3c-dist-auth@w3.org>; Tue, 9 Feb 1999 18:56:15 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa05598;
          9 Feb 99 15:47 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 9 Feb 1999 15:45:07 -0800
Message-ID: <000301be5486$39756ba0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Updated versioning model document on Web

The updated versioning model document, posted to the list by Jim Amsden, has
been placed on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209/

Thanks, Jim and Geoff, for making such a rapid revision of this document!

- Jim


From w3c-dist-auth-request@www10.w3.org  Wed Feb 10 02:25:19 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA18741
	for <w3c-dist-auth@www19.w3.org>; Wed, 10 Feb 1999 02:25:19 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id CAA20483
	for <w3c-dist-auth@w3.org>; Wed, 10 Feb 1999 02:25:18 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <D8VVDNGR>; Tue, 9 Feb 1999 23:25:17 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792EC5@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Tue, 9 Feb 1999 23:25:17 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: Whatever Happened to the Destroy Header and the UNDELETE method?

Very early on the WebDAV WG recognized that versioning introduced two types
of DELETE. The first type of versioning system delete is used to prevent any
further successors to a resource from being created. The second type of
versioning system delete, usually referred to as destroy, was a lot harsher,
it meant to obliterate the resource, recover all storage and remove all
traces that be the resource ever existed.

At the same time it was recognized that certain types of WebDAV users were
likely to have explicit requirements for how a resource was DELETE’d. For
example, a military customer was likely to require that a MILSPEC approved
deletion algorithm be used. A classic example of a MILSPEC approved deletion
algorithm is the one that involves overwriting the deleted file with a
series of 1’s, 0’s and a random stream of bits.

The WG looked to the HTTP/1.1 spec for guidance but the spec was vague as to
what the term “delete” in the DELETE method really meant. So the WG decided
that it needed to provide a mechanism to specify what a DELETE meant.

At the same time the WG also recognized that if something could be deleted
it could quite likely also be undeleted. So undelete functionality was
contemplated.

To make a long story shorter the destroy header was introduced for use with
the DELETE method. The destroy header was completely extensible able to use
both tokens and URIs so new forms of delete could be added.

WebDAV defined three values for the destroy header, undelete, noundelete and
destroy.

"Destroy: undelete" on a DELETE method requested that the resource be
deleted in such a way that the UNDELETE method could be used to retrieve it
later, assuming no further changes were made in the meantime.

"Destroy: noundelete" on a DELETE method requested that the resource be
deleted in such a way that a future UNDELETE would fail.

"Destroy: destroy" requested that all traces of the resource's existence be
obliterated. Obviously an UNDELETE was expected to fail.

A problem with the destroy header was that it was being used on a method
defined by HTTP/1.1 not WebDAV. As such we couldn't require that anyone who
understood DELETE had to honor the destroy header since existing systems
which supported DELETE would just ignore the destroy header. We could have
required that WebDAV compliant resources support destroy but this didn't
really accomplish much. Without transactioning there was no way to guarantee
that from the time you performed discovery to the time you executed the
DELETE request with the destroy header the resource didn't decide to stop
supporting WebDAV. Therefore the WG had to mandate the use of PEP, later
simplified into Mandatory, with the DELETE method if the destroy header was
used. PEP/Mandatory provided a simple mechanism which guaranteed that
existing servers would reject the DELETE method but PEP/Mandatory compliant
servers would not.

If memory serves the UNDELETE method never actually made it into a published
draft, even though the destroy header did. I suspect that the reason for
this is that UNDELETE failed the "There are two kinds of features, mandatory
and not in the spec." We couldn't realistically mandate support for UNDELETE
because many systems didn't have facilities for supporting it and no
interest in introducing them. In fact the definition of the "undelete" value
of the destroy header specified that servers were free to ignore the request
and delete the resource in a manner that did not permit for UNDELETE. In
addition there were a lot of arguments about what exactly UNDELETE meant,
what guarantees if any did one get about the state of a resource after an
UNDELETE? What if the resource had been recreated and deleted again? Did we
need to hand out state tokens in DELETE responses so people could be sure
they were UNDELETing to the right state? Doesn't the whole thing sound like
versioning?

All of the previous questions could have been answered but in the end I
think the final nail in UNDELETE's coffin was that one could build a very
useful authoring system without support for UNDELETE. This argued that
UNDELETE did not need to be in the base spec.

The nail in the Destroy header's coffin came when the WebDAV specification
split out the versioning functionality. Destroy was primarily introduced for
use with versioning, this is why the header was named "destroy" in the first
place. With versioning no longer in the spec and with UNDELETE having never
even been introduced into the spec it was clear that the destroy header was
no longer critical to the successful use of the base WebDAV spec. In
addition since destroy required the use of PEP/Mandatory anyway we could
always add the feature to a future spec with no issues of backwards
compatibility.


From w3c-dist-auth-request@www10.w3.org  Wed Feb 10 13:28:55 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01726
	for <w3c-dist-auth@www19.w3.org>; Wed, 10 Feb 1999 13:28:55 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA27550
	for <w3c-dist-auth@w3.org>; Wed, 10 Feb 1999 13:28:53 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <57478(3)>; Wed, 10 Feb 1999 10:28:42 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147521>; Wed, 10 Feb 1999 10:28:31 PST
Message-Id: <3.0.3.32.19990210095937.0095cd20@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 10 Feb 1999 09:59:37 PST
To: w3c-dist-auth@w3.org
>From: Jim Davis <jdavis@parc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: contents of src and dst XML elements

The spec (RFC 2518) is inconsistent about the expected contents of the src
and dst XML elements.  In particular are they supposed to contain an href
XML element, or a 'raw' URI.

1. The description of the link XML element (12.4) says:

   The values in the href XML elements inside
   the src and dst XML elements of the link XML element MUST NOT be
   rejected if they point to resources which do not exist."

which implies the former.

2.  The definition of dst (12.4.1) and src (12.4.2) say that the value is a
URI and the contents is PCDATA, which implies the latter.

3. The example of the source property (13.10.1) shows src without an href

    <D:src>http://foo.bar/program</D:src>

So which is it?

One reason I ask is that someone asked me how to express anchors with
smaller granularity than an entire resource, for example byte ranges or
Xpointers.

Could I write, e.g.

<src><href>http://foo.bar/program</href>
     <byte-range><start>100</start><length>255</length></byte-range></src>



From w3c-dist-auth-request@www10.w3.org  Wed Feb 10 14:42:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA02964
	for <w3c-dist-auth@www19.w3.org>; Wed, 10 Feb 1999 14:42:23 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA28339
	for <w3c-dist-auth@w3.org>; Wed, 10 Feb 1999 14:42:21 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <D8VVFHA4>; Wed, 10 Feb 1999 11:42:20 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792EC9@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Date: Wed, 10 Feb 1999 11:42:17 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: contents of src and dst XML elements

Jim, the source of your confusion is that the spec doesn't do a good job of
defining how we use the value argument in defining XML elements. XML DTDs
fail to provide sufficient granularity for us to define the exact syntax of
the character content of an XML element. Therefore we use the value argument
to provide BNF which should be used to define the contents of the XML
element. Sections 12.4.1 and 12.4.2 both clearly define their values as URI.
Following the same BNF rules used in RFC 2068 once we define a BNF element
we do not redefine it for subsequent use. The BNF token URI was defined in
section 12.3, the definition of HREF. Therefore the value of src and dst
elements should be the same as the value of an HREF, a URI. Thus the example
in 13.10.1 is correct.

To address your particular example your friend should use
<src>http://foo.bar/program<byte-range><start>100</start><length>255</length
></byte-range></src>. According to the WebDAV XML ignore rules defined in
section 14 and discussed further in section 23.3 any existing WebDAV system
handed that src element MUST ignore the byte-range element and its content.
Thus an existing WebDAV system handed the previous MUST treat it as if it
received <src>http://foo.bar/program</src> or it is in gross violation of
the most basic extensibility mechanism in WebDAV.

				Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Wednesday, February 10, 1999 10:00 AM
> To: w3c-dist-auth@w3.org
> Subject: contents of src and dst XML elements
> 
> 
> The spec (RFC 2518) is inconsistent about the expected 
> contents of the src
> and dst XML elements.  In particular are they supposed to 
> contain an href
> XML element, or a 'raw' URI.
> 
> 1. The description of the link XML element (12.4) says:
> 
>    The values in the href XML elements inside
>    the src and dst XML elements of the link XML element MUST NOT be
>    rejected if they point to resources which do not exist."
> 
> which implies the former.
> 
> 2.  The definition of dst (12.4.1) and src (12.4.2) say that 
> the value is a
> URI and the contents is PCDATA, which implies the latter.
> 
> 3. The example of the source property (13.10.1) shows src 
> without an href
> 
>     <D:src>http://foo.bar/program</D:src>
> 
> So which is it?
> 
> One reason I ask is that someone asked me how to express anchors with
> smaller granularity than an entire resource, for example byte 
> ranges or
> Xpointers.
> 
> Could I write, e.g.
> 
> <src><href>http://foo.bar/program</href>
>      
> <byte-range><start>100</start><length>255</length></byte-range></src>
> 
> 


From w3c-dist-auth-request@www10.w3.org  Wed Feb 10 15:56:14 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA04990
	for <w3c-dist-auth@www19.w3.org>; Wed, 10 Feb 1999 15:56:14 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id PAA29458
	for <w3c-dist-auth@w3.org>; Wed, 10 Feb 1999 15:56:12 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <61469(1)>; Wed, 10 Feb 1999 12:56:06 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147484>; Wed, 10 Feb 1999 12:55:59 PST
Message-Id: <3.0.3.32.19990210125527.00987100@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 10 Feb 1999 12:55:27 PST
To: w3c-dist-auth@w3.org
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792EC9@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: contents of src and dst XML elements

At 11:42 AM 2/10/99 PST, Yaron Goland wrote:
>Jim, the source of your confusion is that the spec doesn't do a good job of
>defining how we use the value argument in defining XML elements.

No, the source of my confusion is that the spec uses inconsistent language.
 The description of the link XML element clearly says the src and dest XML
elements contain href XML elements, not PCDATA.

   Description: The link XML element is used to provide the sources and
   destinations of a link.  The name of the property containing the link
   XML element provides the type of the link.  Link is a multi-valued
   element, so multiple links may be used together to indicate multiple
   links with the same type.  The values in the href XML elements inside
   the src and dst XML elements of the link XML element MUST NOT be
   rejected if they point to resources which do not exist.

If you agree that this is inconsistent, then why not change it?  

I suggest we just drop the last sentence altogether.

We don't need the prohibition about not rejecting the property if the
resources don't exist because:

1. It's just common sense.  WebDAV applications shouldn't routinely
dereference these URIs (in order to check whether they exist), and indeed
there might be bad security implications if they did.

2. The prohibition applies to all places src and dst might be used, not
just in link.

3. It applies in general to other properties whose value is a URI.  Lock
tokens are URIs one can't dereference.

If you insist on keeping it, then move it to the descriptions of src and
dst, to read:

   The src/dst XML elements  MUST NOT be
   rejected if the URI they point to  does not exist.

unless there really is some reason that this applies only to their use
within a link element, and not elsewhere.



From w3c-dist-auth-request@www10.w3.org  Wed Feb 10 16:56:45 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA06990
	for <w3c-dist-auth@www19.w3.org>; Wed, 10 Feb 1999 16:56:45 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA00385
	for <w3c-dist-auth@w3.org>; Wed, 10 Feb 1999 16:56:43 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1WFMLPB7>; Wed, 10 Feb 1999 13:37:31 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792ECB@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Date: Wed, 10 Feb 1999 13:28:05 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: contents of src and dst XML elements

Yup.... definitely inconsistent. I remember the argument about this, I just
don't remember which side I was on. =)

Basically the argument was that any time we have a URI we should have an
HREF element wrapping it. The counter argument is that adding more and more
layers of layering (src->href->uri) made it more difficult to parse and more
difficult to implement. At various points the spec got edited one way and
then the other. I would use the space shuttle logic here. You have three
votes (the value element, the example and the text), majority wins. The
majority choose using URI not HREF so we should just use URI.

I have added this issue to my list of issues to be considered when WebDAV
goes to draft status. I'm sure Jim Whitehead will do the same. His list,
unlike mine, is actually published.

			Yaron


> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Wednesday, February 10, 1999 12:55 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: contents of src and dst XML elements
> 
> 
> At 11:42 AM 2/10/99 PST, Yaron Goland wrote:
> >Jim, the source of your confusion is that the spec doesn't 
> do a good job of
> >defining how we use the value argument in defining XML elements.
> 
> No, the source of my confusion is that the spec uses 
> inconsistent language.
>  The description of the link XML element clearly says the src 
> and dest XML
> elements contain href XML elements, not PCDATA.
> 
>    Description: The link XML element is used to provide the 
> sources and
>    destinations of a link.  The name of the property 
> containing the link
>    XML element provides the type of the link.  Link is a multi-valued
>    element, so multiple links may be used together to 
> indicate multiple
>    links with the same type.  The values in the href XML 
> elements inside
>    the src and dst XML elements of the link XML element MUST NOT be
>    rejected if they point to resources which do not exist.
> 
> If you agree that this is inconsistent, then why not change it?  
> 
> I suggest we just drop the last sentence altogether.
> 
> We don't need the prohibition about not rejecting the property if the
> resources don't exist because:
> 
> 1. It's just common sense.  WebDAV applications shouldn't routinely
> dereference these URIs (in order to check whether they 
> exist), and indeed
> there might be bad security implications if they did.
> 
> 2. The prohibition applies to all places src and dst might be 
> used, not
> just in link.
> 
> 3. It applies in general to other properties whose value is a 
> URI.  Lock
> tokens are URIs one can't dereference.
> 
> If you insist on keeping it, then move it to the descriptions 
> of src and
> dst, to read:
> 
>    The src/dst XML elements  MUST NOT be
>    rejected if the URI they point to  does not exist.
> 
> unless there really is some reason that this applies only to their use
> within a link element, and not elsewhere.
> 
> 


From w3c-dist-auth-request@www10.w3.org  Thu Feb 11 00:08:37 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA13417
	for <w3c-dist-auth@www19.w3.org>; Thu, 11 Feb 1999 00:08:37 -0500 (EST)
Received: from mercury.toad.net (mercury.toad.net [205.197.182.105])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id AAA04515
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 00:08:36 -0500 (EST)
Received: from [209.49.30.178] (sp4d34.toad.net [209.49.30.178])
	by mercury.toad.net (8.8.8/8.8.8) with ESMTP id AAA01143
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 00:08:28 -0500
X-Sender: dcarson@pop.toad.net
Message-Id: <v03130301b2e816c0c263@[209.49.30.46]>
In-Reply-To: <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 11 Feb 1999 00:12:50 -0500
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Dana Carson <dcarson@toad.net>
Subject: New CyberTeams mod_webdav

A new version of the CyberTeams mod_webdav is installed at
http://www.fwi.com:8080/. There are still some things I need to fix in
PROPPATCH but this fixes many of the open problems. Please test if you have
a chance.

--
Dana Carson
dcarson@cyberteams.com           http://www.cyberteams.com/
dcarson@toad.net         http://www.toad.net/~dcarson/
Lunar Resources Company          http://www.tlrc.com/
Artemis Society International    http://www.asi.org/



From w3c-dist-auth-request@www10.w3.org  Thu Feb 11 14:20:45 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA25342
	for <w3c-dist-auth@www19.w3.org>; Thu, 11 Feb 1999 14:20:45 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA12922
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 14:20:44 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id LAA20797
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 11:19:04 -0800 (PST)
Message-Id: <4.1.19990211111242.00a28380@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 11 Feb 1999 11:18:40 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Max Rible <max@glyphica.com>
In-Reply-To: <v03130301b2e816c0c263@[209.49.30.46]>
References: <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: New CyberTeams mod_webdav

At 00:12 2/11/99 -0500, Dana Carson wrote:
>A new version of the CyberTeams mod_webdav is installed at
>http://www.fwi.com:8080/. There are still some things I need to fix in
>PROPPATCH but this fixes many of the open problems. Please test if you have
>a chance.

OPTIONS * works, but it's not even returning 207 Multi-Status.

% telnet www.fwi.com 8080
Trying 209.84.160.61...
Connected to serv1-r.fwi.com.
Escape character is '^]'.
PROPFIND / HTTP/1.0
Authorization: Basic xxxxxxxxxxxx
Depth: 0

Connection closed by foreign host.

% telnet www.fwi.com 8080
Trying 209.84.160.61...
Connected to serv1-r.fwi.com.
Escape character is '^]'.
PROPFIND / HTTP/1.1
Host: www.fwi.com:8080
Connection: close
Depth: 0
Authorization: Basic xxxxxxxxxxxx
Content-Length: 0

HTTP/1.1 200 OK
Date: Thu, 11 Feb 1999 19:13:50 GMT
Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.14
Connection: close
Transfer-Encoding: chunked
Content-Type: httpd/unix-directory

0

Connection closed by foreign host.

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Thu Feb 11 21:12:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA00395
	for <w3c-dist-auth@www19.w3.org>; Thu, 11 Feb 1999 21:12:34 -0500 (EST)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id VAA17118
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 21:12:32 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id UAA150162
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 20:48:42 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id VAA155456
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 21:12:19 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256716.000C1A6D ; Thu, 11 Feb 1999 21:12:11 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256716.000C19A9.00@D51MTA07.pok.ibm.com>
Date: Thu, 11 Feb 1999 21:15:15 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: references to references



I'm trying to nail down the model that we're using for references.  My
first question is,   is it possible to have references to references?

I assume the answer is yes.

Let's assume we set the ref target of resource A to be B.   And let's
assume  resouce B has a reftarget of C.   If I do a propfind on A, what
will we find it's reftarget to be equal to?

Do we require a specific behavior in this case or are we allowing this to
be unspecified for the sake of future (ref-integrity, etc) flexibility?


------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com



From w3c-dist-auth-request@www10.w3.org  Thu Feb 11 23:01:54 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA01029
	for <w3c-dist-auth@www19.w3.org>; Thu, 11 Feb 1999 23:01:54 -0500 (EST)
Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id XAA17924
	for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 23:01:51 -0500 (EST)
Received: (from smap@localhost)
          by dfw-ix15.ix.netcom.com (8.8.4/8.8.4)
	  id WAA29695 for <w3c-dist-auth@w3.org>; Thu, 11 Feb 1999 22:01:28 -0600 (CST)
Received: from ali-ca18-38.ix.netcom.com(209.110.228.102) by dfw-ix15.ix.netcom.com via smap (V1.3)
	id rma029584; Thu Feb 11 22:00:42 1999
Message-Id: <2.2.32.19990212035448.008e1dcc@ix.netcom.com>
X-Sender: froker@ix.netcom.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 11 Feb 1999 19:54:48 -0800
To: w3c-dist-auth@w3.org
>From: Rob Frost <froker@ix.netcom.com>
Subject: Move for Collections

I wanted to clarify my understanding of the MOVE operation for collection
resources. In section 8.9.2 "MOVE for Collections", it states:

   So, for example, if an infinite depth move is performed on collection /a/,
   which contains collections /a/b/ and /a/c/, and an error occurs
   moving /a/b/, an attempt should still be made to try moving /a/c/.

If the /a/c/ move is successful, what happens to /a/b/? I'm assuming we
would get the following result:

- collection /a/ and the /a/c/ subtree will be copied to the destination
- collection /a/ and subtrees /a/b/ and /a/c/ will be deleted from the
original location 

If this is the intended behavior, it seems to conflict with the atomicity of
the move method (copy then delete) on resource /a/b/: the resource will have
been deleted without being copied.

I haven't been looking at the WebDAV stuff for very long, so I apologize if
this has already been discussed or I'm missing something obvious.

Rob 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 12 09:24:48 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06672
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Feb 1999 09:24:48 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA22388
	for <w3c-dist-auth@w3.org>; Fri, 12 Feb 1999 09:24:47 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id JAA02454;
	Fri, 12 Feb 1999 09:24:43 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <1HQAKZZN>; Fri, 12 Feb 1999 09:23:07 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DC0@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>, w3c-dist-auth@w3.org
Date: Fri, 12 Feb 1999 09:27:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: references to references

Yes, there can be references to references.  The semantics is specified in
Section 4.14 of the latest draft, which you can find at:

http://www.ics.uci.edu/~ejw/authoring/collection/dt/CollSpec024.txt

That section does not explicitly address your question, since it assumes
that the semantics described elsewhere in the spec will hold.  I assume you
are talking about direct references, so for them:  If the No-Passthrough
header is used with a PROPFIND request on the first reference in a chain of
references, the value of DAV:reftarget that gets returned is the URI of the
next reference in the chain.  So it is possible to follow the chain step by
step to its end.

If the No-Passthrough header is not used, the properties returned will be
the properties of the target of the last reference in the chain.

--Judy


> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Thursday, February 11, 1999 9:15 PM
> To: w3c-dist-auth@w3.org
> Subject: references to references
> 
> 
> 
> 
> I'm trying to nail down the model that we're using for references.  My
> first question is,   is it possible to have references to references?
> 
> I assume the answer is yes.
> 
> Let's assume we set the ref target of resource A to be B.   And let's
> assume  resouce B has a reftarget of C.   If I do a propfind 
> on A, what
> will we find it's reftarget to be equal to?
> 
> Do we require a specific behavior in this case or are we 
> allowing this to
> be unspecified for the sake of future (ref-integrity, etc) 
> flexibility?
> 
> 
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 12 12:57:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA10712
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Feb 1999 12:57:27 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id MAA25118
	for <w3c-dist-auth@w3.org>; Fri, 12 Feb 1999 12:57:24 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa03211;
          12 Feb 99 9:49 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Rob Frost <froker@ix.netcom.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Fri, 12 Feb 1999 09:47:06 -0800
Message-ID: <005a01be56af$b49ce800$d115c380@galileo.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 8.5, Build 4.71.2173.0
In-Reply-To: <2.2.32.19990212035448.008e1dcc@ix.netcom.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Move for Collections

Hi Rob,

> I wanted to clarify my understanding of the MOVE operation for collection
> resources. In section 8.9.2 "MOVE for Collections", it states:
>
>    So, for example, if an infinite depth move is performed on
>    collection /a/, which contains collections /a/b/ and /a/c/,
>    and an error occurs moving /a/b/, an attempt should still
>    be made to try moving /a/c/.

Right.

> If the /a/c/ move is successful, what happens to /a/b/? I'm assuming we
> would get the following result:
>
> - collection /a/ and the /a/c/ subtree will be copied to the destination

Right.

> - collection /a/ and subtrees /a/b/ and /a/c/ will be deleted from the
> original location

Nope.

The design principles we used here are:

- perform a best-effort move if errors are detected (which assumes the user
really wanted the move, and would prefer a partial move over a complete
failure)
- do not accidentally delete data
- the way to view a depth operation is that the methods are being passed
from the collection to its members, then executed by each member.  The tree
traversal algorithm is intentionally unspecified -- it could be depth-first
or breadth-first, etc.

So, what should happen is:

 - collection /a/ and subtree /a/c/ will be copied to the destination
(including all members of /a/).
 - subtree /a/c/ will be deleted.
 - all resources in /a/, excepting /a/b/, are deleted (since they have been
copied)
 - collection /a/c/ is untouched.
 - collection /a/ must remain to maintain a consistent namespace

Of course, each individual move operation is performed as a logical atomic
operation -- my discussion above separates out the copy and delete steps for
expository reasons.

> If this is the intended behavior, it seems to conflict with the
> atomicity of the move method (copy then delete) on resource /a/b/: the
> resource will have been deleted without being copied.

True -- since this is a violation, the resources aren't deleted, since they
weren't copied.

> I haven't been looking at the WebDAV stuff for very long, so I
> apologize if this has already been discussed or I'm missing something
> obvious.

No problem -- if you have a question, others likely do too.

- Jm


From w3c-dist-auth-request@www10.w3.org  Fri Feb 12 16:09:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA14013
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Feb 1999 16:09:33 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id QAA27432
	for <w3c-dist-auth@w3.org>; Fri, 12 Feb 1999 16:09:31 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa21279;
          12 Feb 99 13:08 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Cc: dav-announce@lyra.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Fri, 12 Feb 1999 13:06:09 -0800
Message-ID: <006701be56cb$8342de60$d115c380@galileo.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 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: RFC 2518 on WEBDAV

RFC 2518 has officially been released!

- Jim

-----Original Message-----
>From: RFC Editor [mailto:rfc-ed@isi.edu] 
Sent: Wednesday, February 10, 1999 4:15 PM
To: IETF-Announce: ;
Cc: rfc-ed@isi.edu
Subject: RFC 2518 on WEBDAV



A new Request for Comments is now available in online RFC libraries.


        RFC 2518: 

        Title:	    HTTP Extensions for Distributed Authoring --
		    WEBDAV
	Author(s):  Y. Goland, E. Whitehead, A. Faizi, S. Carter,
		    D. Jensen
	Status:     Proposed Standard
	Date:       February 1999
        Mailbox:    yarong@microsoft.com, ejw@ics.uci.edu,
		    asad@netscape.com, srcarter@novell.com,
		    dcjensen@novell.com
	Pages:      94
        Characters: 202829
        Updates/Obsoletes/See Also: None  
        I-D Tag:    draft-ietf-webdav-protocol-10.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2518.txt


This document specifies a set of methods, headers, and content-types
ancillary to HTTP/1.1 for the management of resource properties,
creation and management of resource collections, namespace
manipulation, and resource locking (collision avoidance).

This document is a product of the WWW Distributed Authoring and
Versioning Working Group of the	IETF.	

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Alegre Ramos
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.


From w3c-dist-auth-request@www10.w3.org  Fri Feb 12 17:03:47 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA15848
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Feb 1999 17:03:46 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA28111
	for <w3c-dist-auth@w3.org>; Fri, 12 Feb 1999 17:03:44 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa25780;
          12 Feb 99 13:57 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 12 Feb 1999 13:55:06 -0800
Message-ID: <006b01be56d2$59c5aac0$d115c380@galileo.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 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Updated Web versioning and config. mgmt. charter

Hi,

I've updated the charter for the Web Versioning and Configuration Management
working group, and placed it on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/versioning/charter.txt

I have also requested a BOF slot at the Minneapolis IETF meeting to discuss
this charter.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri Feb 12 17:18:05 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA16328
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Feb 1999 17:18:05 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA28286
	for <w3c-dist-auth@w3.org>; Fri, 12 Feb 1999 17:18:02 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa27966;
          12 Feb 99 14:15 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 12 Feb 1999 14:13:00 -0800
Message-ID: <006f01be56d4$da6bb5a0$d115c380@galileo.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 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Interim Advanced Collections Specification

An updated interim revision of the Advanced Collections Specification is now
available on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec025.txt

A list of the changes that went into this revision can be found at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/ssreport.txt

With this update, Judy again shows she's "the fastest spec. in the East" :-)
Thanks!

- Jim


From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 02:05:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA29935
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 02:05:23 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id CAA09720
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 02:05:22 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1Z0GG20F>; Sat, 13 Feb 1999 23:05:21 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F03@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Sat, 13 Feb 1999 23:03:58 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: Why MOVE isn't really defined as a COPY followed by a DELETE


The simplest definition of the MOVE method would probably be something like
"The result of a MOVE method is that the source URI is replaced with the
destination URI as a reference to the resource."

However this definition would imply certain things. For example, one would
expect that after a MOVE the resource referred to with the new destination
URI will behave exactly the way it behaved when it was named with the source
URI.

However this assumption ignores the realities of implementation. To pull out
the usual example, what happens if the source URI was in a CGI enabled
directory and the destination is not? Should the MOVE fail?

What if the MOVE will require, under the covers, that the resource be moved
from one server to another and the destination server doesn't support the
same live properties as the source? Should the MOVE fail?

All of this, of course, should sound very familiar. These are the exact same
problems that COPY has. Sort of.

In the last example we talked about a MOVE resulting in a resource being
moved from one server to another. If this were just a COPY then there would
now be two resources, one at the source server and one at the destination
server. But this is a MOVE, it should only result in a single resource. What
happened to the resource at the source server? Practically speaking its
file/program/etc. was deleted. This brings us to the Destroy header (see
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html> for
more details). At the time that MOVE was being defined the Destroy header
was still in the spec. So there was a concern that since a MOVE could
potentially involve a DELETE it was important to be able to specify how the
DELETE was to be performed. The key word here is "potentially." There is no
requirement that a DELETE occur, but it could and if it does we need to be
able to control how it happens.

Which leads us back to the question of how to define MOVE. MOVE has the same
issues with resource behavior and live property support that COPY has. Just
like COPY, if you MOVE a resource you aren’t guaranteed it will behave the
same way at the destination as it did at the source. Just like COPY, the
only guarantees you have about properties after a MOVE are those provided by
the propertybehavior XML element. MOVE is more complicated than COPY,
however, because it also includes DELETE.

The general consensus of the authors was that the easiest way to define MOVE
was to inherit COPY and DELETE's definitions. In inheriting COPY the
author's intention was to guarantee the minimal functionality that COPY
provides, including support for the propertybehavior XML element. In
inheriting DELETE the author's intention was to provide support for the
Destroy header and other mechanisms relating to the DELETE method. It was
not the author's intention to require an actual COPY followed by an actual
DELETE, just to provide the same guarantees of minimal functionality.

This lead the authors to first define MOVE as "The logical equivalent of a
COPY followed by a DELETE performed atomically." The key word was "logical."
The word logical was supposed to mean that COPY and DELETE functionality was
inherited, not explicitly performed. Unfortunately the authors were too
subtle.

Judy Slein posted the classic example demonstrating the author's failure to
provide a sufficiently clear definition. Judy pointed out that if one had a
resource identified by a unique ID then moving the resource shouldn't cause
the ID to change. On the other hand, if one copied a resource then one would
expect the ID to change. So if a MOVE really is a COPY followed by a DELETE
then the resource at the destination would have a different ID because the
COPY would generate a new ID.

Of course the definition wasn't meant to result in the ID changing. We
though the word "logical" bought us a way out but readers who hadn't mind
melded with one of the authors had no way of knowing that.

The authors did try to clean things up by changing the definition to:

   The MOVE operation on a non-collection resource is the logical
   equivalent of a copy (COPY), followed by consistency maintenance
   processing, followed by a delete of the source, where all three
   actions are performed atomically.

We were trying to be very explicit that things like ID maintenance were
completely within the definition. In fact everything is in the definition.
The definition is not meant to exclude, only to provide basic guarantees.
When Judy came back with the same concern I knew we had failed. You see,
Judy knows more about WebDAV than anyone but the authors. If Judy didn't
understand what we intended then the only possible conclusion is that the
authors failed to provide a clear definition. I hope this paper will go a
little way toward fixing things. But obviously we will have to try again
when we move from Proposed to Draft.


From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 06:10:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA01151
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 06:10:51 -0500 (EST)
Received: from mercury.toad.net (mercury.toad.net [205.197.182.105])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id GAA10784
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 06:10:50 -0500 (EST)
Received: from [209.49.30.44] (sp1d44.toad.net [209.49.30.44])
	by mercury.toad.net (8.8.8/8.8.8) with ESMTP id GAA24390;
	Sun, 14 Feb 1999 06:10:31 -0500
X-Sender: dcarson@pop.toad.net
Message-Id: <v03130302b2ec609f2ca5@[209.49.30.44]>
In-Reply-To: <4.1.19990211111242.00a28380@shell7.ba.best.com>
References: <v03130301b2e816c0c263@[209.49.30.46]>
 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 14 Feb 1999 06:15:49 -0500
To: Max Rible <max@glyphica.com>, WEBDAV WG <w3c-dist-auth@w3.org>
>From: Dana Carson <dcarson@toad.net>
Subject: Re: New CyberTeams mod_webdav

> >A new version of the CyberTeams mod_webdav is installed at
> >http://www.fwi.com:8080/. There are still some things I need to fix in
> >PROPPATCH but this fixes many of the open problems. Please test if you have
> >a chance.
>
> OPTIONS * works, but it's not even returning 207 Multi-Status.

Keyboards and pain killers don't mix. The correct version is now installed.
Sigh.

--
Dana Carson
dcarson@cyberteams.com           http://www.cyberteams.com/
dcarson@toad.net         http://www.toad.net/~dcarson/
Lunar Resources Company          http://www.tlrc.com/
Artemis Society International    http://www.asi.org/



From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 16:52:30 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA05274
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 16:52:30 -0500 (EST)
Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA14332
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 16:52:29 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp8.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id QAA19740
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 16:55:00 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id QAA106898
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 16:52:23 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256718.0078255C ; Sun, 14 Feb 1999 16:52:18 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256718.00782402.00@D51MTA07.pok.ibm.com>
Date: Sun, 14 Feb 1999 16:55:16 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Why MOVE isn't really defined as a COPY followed by a DELETE


Yaron,

Cool.  Then we are all basically in agreement and just need to reword the
spec.   The current wording looks pretty tight.  I quickly tried to come up
with something that was less "subtle" without wrecking the current wording.
I've not come up with anything that I'm really happy about though.
I believe the current spec says...

8.9.1     MOVE for Properties
   The behavior of properties on a MOVE, including the effects of the
   propertybehavior XML element, MUST be the same as specified in
   section 8.8.2.

Perhaps this could be enhanced via...

8.9.1     MOVE for Properties
   The behavior of properties on a MOVE, including the effects of the
   propertybehavior XML element, MUST be ****basically**** the same as
specified in
   section 8.8.2.   ****This does allow for differences due to differences
in the
   basic semantic model of MOVE vs. COPY.  For example, a live
unique_resource_id property
   might retain the same value at the destination as at the source for a
   MOVE; whereas, have a new unique value after a COPY.  The same would
   usually be expected of properties like getlastmodified.****


I'm not even sure if that applies to getlastmodified.  My uncertainty
suggests that we need to specify up front it's MOVE behavior.  Does
getlastmodified apply to the underlying resource... or the URL?  (I know
what my browser prefers. :-))

Which gets me to... rfc2518 doesn't say what happens if one sets the value
of getlastmodified...  but now I'm off on a tangent.

Anyway, that was my shot.  I hope that someone can come up with a better
wording...

BTW, I notice that section 8.8.2 doesn't actually say what happens with
dead properties during a COPY.  Perhaps that's too obvious though.  :-)

J.


------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com



From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 17:28:12 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA05469
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 17:28:11 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA14579
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 17:28:10 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <15A6THMB>; Sun, 14 Feb 1999 14:28:10 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F04@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Joe Orton'" <jeo101@york.ac.uk>, jamsden@us.ibm.com
Cc: w3c-dist-auth@w3.org
Date: Sun, 14 Feb 1999 14:28:08 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: Why Multi-Status is a 2xx Response

Before we dive into this we need to get some terms defined. There are two
different kinds of responses discussed below. Response line codes and body
response codes. For example:

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50">
     <D:response>
          <D:href>http://www.foo.com/bar.html</D:href>
          <D:propstat>
               <D:prop><Z:Authors/></D:prop>
               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

In the previous the response line code, the code returned in the HTTP
response line, is 207. The body response code, one of many possible codes
included in the body of a Multi-Status response, is 424. Now, back to the
show.

So I send a PROPFIND request to a resource and get back a 207 Multi-Status
response line code filled with 4xx body response codes telling me that the
properties I was looking for aren't defined, I'm not authorized, etc. So why
did I get back a 2xx response line code? The method clearly failed.

So I sent a PROPPATCH request to a resource and get back a 207 Multi-Status
response line code telling me that one of the changes didn't work so all the
changes were aborted. Why did I get back a 2xx response line code? The
method clearly failed.

So I sent a COPY/MOVE/DELETE with a Depth: Infinity header and got back a
207 Multi-Status response line code telling me that absolutely nothing got
COPYied, MOVEd, or DELETEd. Why did I get back a 2xx response line code? The
method clearly failed!

When Multi-Status was first defined the authors considered having a 2xx
response line code and a 4xx response line code for Multi-Status. So if I
send in a PROPFIND and the resulting Multi-Status comes back with nothing
but 2xx body response codes inside of it then I would use the 2xx response
line code. If I send in a PROPFIND and the resulting Multi-Status comes back
with nothing but 4xx body response codes inside of it then I would use the
4xx response line code. But what happens if the PROPFIND comes back with
nothing but 5xx body response codes? Do I need a 5xx response line code
Multi-Status? What about 3xx body response codes?

However the key case was as follows: I send a PROPFIND request asking for
three properties. One property came back with a 200 O.k. body response code.
One property came back with a 403 Forbidden body response code. The last
property came back with a 500 Server Error body response code. What response
line code should be used?

Initially the authors thought that in a mixed case one should just use a 4xx
response line code. But no one could come up with a compelling reason why a
mixed case should be called a failure instead of a success. In fact, no one
could come up with a case where it mattered if a mixed response was returned
using a 2xx, 4xx or 5xx response line code. In fact, no one could come up
with a reason to have multiple Multi-Status responses. The response line
code just wasn't that useful.

Response line codes in HTTP serve two purposes. The primary purpose is to
provide exact information regarding the result of a request. If that was
their only purpose then there wouldn't be error classes (e.g. 1xx, 2xx, 3xx,
4xx and 5xx response line codes). The reason error classes were introduced
is to allow a client to do something intelligent in case the client doesn't
recognize a response code.

In the case of Multi-Status the error class isn't terribly relevant. Baring
implementation error it isn't possible to get a 207 unless you were
expecting it. PROPFIND and PROPPATCH both require understanding
Multi-Status, as does COPY/MOVE/DELETE if a Depth header is used. Thus we
never have to worry about someone receiving a 207 without being able to
understand it. If you got a 207 it can only be because you made a request
whose definition requires you to understand 207.

While this logic is sound it ignores the bigger picture. Future generations
are quite likely to use 207 and equally like to muck things up and use it in
a context where someone receiving it may not have expected it. However they
will expect to be able to rely on the response class and the response class
fails them here because it will always be 207 even if everything inside of
it is a failure.

In the end however, the mixed error case refused to admit a sensible
solution. So rather than mucking up the protocol with a large number of
response line codes with arcane rules specifying their use we decided to
keep matters simple and return a single response line code.

> -----Original Message-----
> From: Joe Orton [mailto:jeo101@york.ac.uk]
> Sent: Friday, January 22, 1999 11:12 AM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Multistatus responses
> 
> 
> 
> > It is my understanding that methods only return a 
> multistatus when they
> > effect multiple resources.
> 
> PROPPATCH uses 207 responses for methods on single resources, I think?
> 
> > So for example, you could DELETE a collection and get a 
> multistatus if
> > it failed indicating which resource in the collection couldn't be
> > deleted. If the DELETE failed because the collection itself 
> was locked,
> > then you could also return a single status as the members were
> > unaffected.
> 
> Yes, so if it failed, why not return a 4xx class response 
> which is what
> 4xx class responses are for? The 'degree' to which it failed 
> (i.e., which
> resources couldn't be deleted) is indicated only by the 
> response body, but
> the bottom line is that the request did NOT succeed, which is what 2xx
> responses are for.
> 
> I'm not trying to suggest that multistatus responses should 
> be scrapped,
> only that they should not have a fixed status code.
> 
> Regads,
> 
> joe
> 
> -- 
> Joe Orton
> jeo101@york.ac.uk ... joe@orton.demon.co.uk
> http://www.orton.demon.co.uk/
> 
> 
> 


From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 17:53:01 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA05749
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 17:53:00 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA14757
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 17:52:59 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <15AJTXY8>; Sun, 14 Feb 1999 14:52:58 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F05@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Sun, 14 Feb 1999 14:52:58 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: The WebDAV Book of Why - V. Alpha 2

1 The WebDAV Book of Why

V.Alpha 2 - 02/14/99 2:39 PM

1.1 Introduction

This is my personal collection of posts from the WebDAV mailing list. I use
this collection to save me time in answering questions about the design of
the WebDAV distributed authoring standard. In here you will find answers to
everything you ever wanted to know, but were wise enough not to ask, about
how WebDAV ended up the way it did.

Many of these papers contain histories of how various features were
developed. Almost all the histories are wrong. The reason they are wrong is
that:
a) I have a lousy memory
b) I didn't bother to actually research my answers
c) All of the above

On the other hand I have been reviewing some of the old drafts, meeting
notes and mailing lists and there is quite a story in there. Did you know
that WebDAV was originally written to use POST? That WebDAV had support for
fully distributed searching and eventing? We have all the drafts, all the
meeting notes and the entire mail archive. I'm sure there is a researcher
out there who would just love to dive in to a fully documented history of
the development of a protocol. For more information please contact Jim
Whitehead, chief librarian and head researcher of the WebDAV archives.

Disclaimer:

Nothing said here is official, binding, normative, a standard or
representative of working group consensus. The official history of the
working group is contained in the meeting minutes, the mailing list and the
untold drafts the working group produced. The final word on all standards
issues is the RFC and failing that, working group consensus.

1.2 Changes

This is the second Alpha release of this reference. Each entry is marked
with the version number, V. Alpha 1 or V. Alpha 2 to indicate when it was
added to the reference.

1.3 Index

1	The WebDAV Book of Why
1.1	Introduction
1.2	Changes
1.3	Index
2	A History of WebDAV's Property Design -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html - V
Alpha 1
3	The DAV Property/Message Object Model -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0044.html - V
Alpha 1
4	Collections, Resourcetype and Hierarchy in WebDAV -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html - V
Alpha 1
4.1	Why Did WebDAV Decide that the HTTP URL Namespace is a Hierarchy?
4.2	Why Did WebDAV Create Resource Types like the Collection Resource?
4.3	Why Did WebDAV Create the Resourcetype Property?
4.4	Why Did WebDAV Create MKCOL?
4.5	Why Did WebDAV Allow for Mixed WebDAV and Non-WebDAV Compliant
Namespaces?
4.6	Why Does WebDAV Allow for non-WebDAV Compliant Collections?
4.7	Why Does WebDAV Require Hierarchy in WebDAV Only Namespaces?
4.7.1	Client Hierarchy Requirements
4.7.2	Server Hierarchy Requirements
4.7.3	The Working Group Analysis
5	Whatever Happened to the Destroy Header and the UNDELETE method? -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html - V
Alpha 2
6	A History of Copy and Move -
6.1	COPY and Methods -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0096.html - V
Alpha 2
6.2	COPY and Properties -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0097.html - V
Alpha 2
6.3	Why MOVE isn't really defined as a COPY followed by a DELETE -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0125.html - V
Alpha 2
7	Why MOVE Eats Write Locks -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html - V
Alpha 2
8	Why Multi-Status is a 2xx Response -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html - V
Alpha 2
9	How WebDAV Uses the Value argument in defining XML elements -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0113.html - V
Alpha 2
10	Levels of HTTP Nirvana or POST Vs. New Methods -
http://xent.ics.uci.edu/FoRK-archive/feb98/0238.html - V Alpha 1
11	When to Use the Header vs. the Body for Method Arguments -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0113.html - V
Alpha 1
12	HTTP Design Issues, lessons from WebDAV's Property and Depth header
experiences -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html - V
Alpha 1
12.1	Skipping to the End
12.1.1	Side Note
12.2	Why I Bother
12.3	This is another fine protocol you've gotten me into!
12.4	Out of our Depth
13	Ramifications of WebDAV's property design decisions -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html - V
Alpha 1
13.1	Introduction
13.2	Design Principals
13.3	POST
13.4	Severability
13.5	Is it live or is it Memorex?
13.6	Schemas
13.7	Conclusion
14	XML Attributes and the WebDAV object model -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html - V
Alpha 1
14.1	Dumbing Down Data Structures -
14.2	Killing Extensibility -
15	Versioning, Collections and Sources -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0280.html - V
Alpha 1
16	Larry Masinter’s Excellent Advice on how to structure early protocol
Drafts -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0246.html - V
Alpha 2


From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 18:20:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA05980
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 18:20:22 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA14949
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 18:20:21 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <1Z0GH2H7>; Sun, 14 Feb 1999 15:20:21 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F06@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Sun, 14 Feb 1999 15:20:20 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: If you are going to write WebDAV Standards - PLEASE READ THIS

One of the smartest things the WebDAV authors ever did was to listen to
Larry Masinter's suggestions
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0246.html)
regarding how to put together our early drafts. The way we implemented his
suggestion was to require that every feature in the spec have three
sections. 

Section 1 - A description of the problem the feature was meant to address

Section 2 - A proposed solution for the problem

Section 3 - An explanation of the design rational behind the solution.

If you look at the early drafts you will literally see things like:

PROPFIND -
	Section 1
	Section 2
	Section 3
COPY -
	Section 1
	Section 2
	Section 3
Etc.

Sections 1 & 3 do not belong in an RFC because they are not normative.
However, imagine how much more useful the WebDAV spec would be if we could
release an "unofficial" version with all the sections 1 & 3? In essence "The
WebDAV Book of Why" is just me trying to remember all the arguments we made
in the old section 3s. The section 1s were supposed to be covered by a
scenario document, but the draft died from lack of interest.

If I had it all over to do again I would use styles in Word to mark sections
1, 2 & 3s and then I would use Visual Basic for Office (or whatever it is
called) to write a program to auto-generate the "official" version only
consisting of section 2s.

My recommendation to WebDAV authors, especially the versioning group, is
that they seriously consider using this same structure for their drafts.
More than that, if they will be using Word, they should seriously consider
putting together the environment I propose. In one of those "you can pay me
now or you can pay me later" type of situations, you can put these sections
into the draft and maintain them or you can keep re-explaining yourselves on
the mailing list for years to come.

My penance for not putting together that environment is The WebDAV Book of
Why, which is 37 pages and counting. Please, save yourselves some serious
pain.


From w3c-dist-auth-request@www10.w3.org  Sun Feb 14 18:24:21 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA06038
	for <w3c-dist-auth@www19.w3.org>; Sun, 14 Feb 1999 18:24:20 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA14964
	for <w3c-dist-auth@w3.org>; Sun, 14 Feb 1999 18:24:19 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <15AV1TJJ>; Sun, 14 Feb 1999 15:24:20 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F07@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "'WebDAV'"
	 <w3c-dist-auth@w3.org>
Date: Sun, 14 Feb 1999 15:24:18 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Issue: MOVE Semantics

Thanks for your post Judy. It helped me realize that the section of the
WebDAV Book of Why entitled "A Short history of copy and move" should really
be titled "A short history of copy". More than that, it helped me to realize
that the post really sucked. I swear it was funny when I wrote it, but
apparently in a "you had to be there" kind of way. Anyway I broke it out
into three separate posts which I have put up on the list.

Your post also helped me find this gem of a post (if I do say so myself =)
which goes into the gory details of exactly why locks are lost on moves -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html. As
you will see, the definition of MOVE did not play a part in the decision
requiring that locks be lost on MOVEs.

Also, while working on my response to your question I found Larry's post on
how to structure WebDAV which sparked this post
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0130.html).

In fact, your post sparked so much new material that I just released the V.
Alpha 2 version of the WebDAV Book of Why
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html)

As to your specific points, I hope my post on MOVE
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/) helped to
explain the relationship of COPY and DELETE to MOVE and why the authors
wrote the language the way they did. More importantly I hope it explains why
the definition of MOVE does not prevent the functionality you are seeking.

			Thanks,
						Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Friday, January 22, 1999 9:08 AM
> To: 'WebDAV'
> Subject: Issue: MOVE Semantics
> 
> 
> In the current version of the WebDAV specification, MOVE is 
> defined as COPY
> followed by DELETE.
> 
> I believe that this definition causes enough problems that we should
> consider changing it.
> 
> As Jim Davis recently pointed out (in his comments on
> draft-hopmann-collection-props-00.txt), it causes problems 
> for IDs.  We
> expect that when an object is moved, it will have the same ID.  But we
> expect that when an object is copied, the new copy will have 
> a distinct ID.
> We can't have both these semantics if MOVE is defined as COPY 
> followed by
> DELETE.
> 
> Other properties will have similar problems, like creation date.
> 
> An attempt to MOVE a resource to its same location will result in the
> resource being deleted.  (This forced the advanced 
> collections protocol to
> invent a new method for changing the position of a resource in a
> collection's ordering, when we might otherwise have been able 
> to use MOVE.)
> 
> It is probably this definition that forced the spec to say 
> that locks are
> lost after a MOVE, a counterintuitive result.  I would expect 
> an object that
> was locked before a MOVE still to be locked after the MOVE.
> 
> Could we just say that after a MOVE, the resource is 
> accessible through the
> URI in the Destination header, and is no longer accessible through the
> request-URI of the MOVE request, and get rid of the 
> definition in terms of
> COPY and DELETE?
> 
> --Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 


From w3c-dist-auth-request@www10.w3.org  Mon Feb 15 09:53:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA22519
	for <w3c-dist-auth@www19.w3.org>; Mon, 15 Feb 1999 09:53:40 -0500 (EST)
Received: from pump2.york.ac.uk (pump2.york.ac.uk [144.32.128.12])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA21087
	for <w3c-dist-auth@w3.org>; Mon, 15 Feb 1999 09:53:36 -0500 (EST)
Received: from tower.york.ac.uk (tower.york.ac.uk [144.32.128.102])
	by pump2.york.ac.uk (8.8.7/8.8.7) with SMTP id OAA10474;
	Mon, 15 Feb 1999 14:52:50 GMT
Date: Mon, 15 Feb 1999 14:52:49 +0000 (GMT)
>From: Joe Orton <jeo101@york.ac.uk>
To: Dana Carson <dcarson@toad.net>
cc: WEBDAV WG <w3c-dist-auth@w3.org>
In-Reply-To: <v03130302b2ec609f2ca5@[209.49.30.44]>
Message-ID: <Pine.SOL.3.95L.990215144510.2666F-100000@tower.york.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: New CyberTeams mod_webdav


> A new version of the CyberTeams mod_webdav is installed at
> http://www.fwi.com:8080/. There are still some things I need to fix in
> PROPPATCH but this fixes many of the open problems. Please test if you
> have a chance. 

I still get these 422 errors, as indicated before, and I'm yet to see them
against any other servers - is this a known bug? 

Regards,

joe

-- 
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/


From w3c-dist-auth-request@www10.w3.org  Mon Feb 15 11:20:21 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA23818
	for <w3c-dist-auth@www19.w3.org>; Mon, 15 Feb 1999 11:20:20 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id LAA21956
	for <w3c-dist-auth@w3.org>; Mon, 15 Feb 1999 11:20:19 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <53581(2)>; Mon, 15 Feb 1999 08:20:12 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147468>; Mon, 15 Feb 1999 08:20:08 PST
Message-Id: <3.0.3.32.19990215081728.0097f9f0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 15 Feb 1999 08:17:28 PST
To: Dana Carson <dcarson@toad.net>, WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <v03130301b2e816c0c263@[209.49.30.46]>
References: <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: New CyberTeams mod_webdav

At 09:12 PM 2/10/99 PST, Dana Carson wrote:
>A new version of the CyberTeams mod_webdav is installed at
>http://www.fwi.com:8080/. There are still some things I need to fix in
>PROPPATCH but this fixes many of the open problems. Please test if you have
>a chance.

The PROPFIND reply has malformed XML.

I tried to fetch the value of the resourcetype property for /jrd/

PROPFIND /jrd/ HTTP/1.1
Host: www.fwi.com
Authorization: ....
Content-Type: text/xml
Content-Length:  

<?xml version="1.0"?>
<A:propfind xmlns:A="DAV:">
  <A:prop>
    <A:resourcetype/>
  </A:prop>
</A:propfind>

The reply was

<?xml version="1.0"?>
<A:multistatus xmlns:A="DAV:">
  <A:response>
    <A:href>http://serv1-r.fwi.com/jrd/</A:href>
    <A:propstat>
      <A:prop>
        <resourcetype>
          <collection/>
        </resourcetype>
      </A:prop>
      <A:status>HTTP/1.1 200 OK</A:status>
    </A:propstat>
  </A:response>
</A:multistatus>

Note the lack of a namespace prefix on resourcetype and collection.

The automated test script refused to continue past this point.


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 06:10:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA08503
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 06:10:27 -0500 (EST)
Received: from mercury.toad.net (mercury.toad.net [205.197.182.105])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id GAA01272
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 06:10:26 -0500 (EST)
Received: from [209.49.30.174] (sp4d30.toad.net [209.49.30.174])
	by mercury.toad.net (8.8.8/8.8.8) with ESMTP id GAA27523;
	Tue, 16 Feb 1999 06:10:15 -0500
X-Sender: dcarson@pop.toad.net
Message-Id: <v03130301b2ef038cfe7c@[209.49.30.174]>
In-Reply-To: <3.0.3.32.19990215081728.0097f9f0@mailback.parc.xerox.com>
References: <v03130301b2e816c0c263@[209.49.30.46]>
 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Feb 1999 06:15:40 -0500
To: Jim Davis <jdavis@parc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
>From: Dana Carson <dcarson@toad.net>
Subject: Re: New CyberTeams mod_webdav

At 8:17 AM -0800 on 2/15/99, Jim Davis wrote:


> The PROPFIND reply has malformed XML.
>
> I tried to fetch the value of the resourcetype property for /jrd/
>
> PROPFIND /jrd/ HTTP/1.1

> The reply was
>
> <?xml version="1.0"?>

>         <resourcetype>
>           <collection/>
>         </resourcetype>

> Note the lack of a namespace prefix on resourcetype and collection.
>
> The automated test script refused to continue past this point.

Arugh. Fixed.

--
Dana Carson
dcarson@cyberteams.com           http://www.cyberteams.com/
dcarson@toad.net         http://www.toad.net/~dcarson/
Lunar Resources Company          http://www.tlrc.com/
Artemis Society International    http://www.asi.org/



From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 13:29:21 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16320
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 13:29:21 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA06235
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 13:29:20 -0500 (EST)
Received: from appoint.net (mail.appoint.net [207.242.168.162])
	by phaisos.cube.com (8.8.5/8.8.5) with ESMTP id OAA27439
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 14:30:25 -0500
Received: from appoint.net [209.218.166.130] by appoint.net with ESMTP
  (SMTPD32-5.00) id A976BD50132; Tue, 16 Feb 1999 13:31:18 EST
Sender: francis@phaisos.cube.com
Message-ID: <36C9B941.76E91074@appoint.net>
Date: Tue, 16 Feb 1999 18:30:26 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "'WebDAV'" <w3c-dist-auth@w3.org>
References: <3FF8121C9B6DD111812100805F31FC0D08792F06@RED-MSG-59>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: If you are going to write WebDAV Standards - PLEASE READ THIS

Yaron Goland wrote:

> Sections 1 & 3 do not belong in an RFC because they are not normative.
> However, imagine how much more useful the WebDAV spec would be if we could
> release an "unofficial" version with all the sections 1 & 3?

Can't we release the 1&3s as an Informational RFC?

> My recommendation to WebDAV authors, especially the versioning group, is
> that they seriously consider using this same structure for their drafts.
> More than that, if they will be using Word, they should seriously consider
> putting together the environment I propose.

Personally, I'd recommend using non-proprietary tools, so that, if they have to
hand the document off to somebody else, they're not limited to people who run
Windows or Mac and have bought Word.  A good preprocessor would do (or even a
not-so-good one--I use cpp for my personal website).

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




CUBElink Internet Services.


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 13:30:11 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16373
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 13:30:11 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA06249
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 13:30:09 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <55633(4)>; Tue, 16 Feb 1999 10:30:06 PST
Received: from klagen ([13.1.101.197]) by mailback.parc.xerox.com with SMTP id <147514>; Tue, 16 Feb 1999 10:30:00 PST
Message-Id: <3.0.5.32.19990216102957.00986420@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 16 Feb 1999 10:29:57 PST
To: Dana Carson <dcarson@toad.net>, WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <v03130301b2ef038cfe7c@[209.49.30.174]>
References: <3.0.3.32.19990215081728.0097f9f0@mailback.parc.xerox.com>
 <v03130301b2e816c0c263@[209.49.30.46]>
 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: New CyberTeams mod_webdav

At 03:15 AM 2/16/99 PST, Dana Carson wrote:
>
>Arugh. Fixed.

Yes, fixed.  My test script got further, but then hit the following bug

PROPFIND /jrd/foo.html HTTP/1.1
Host: www.fwi.com
Authorization: Basic anJkOmZvbw==
content-length: 105
content-type: text/xml

<?xml version="1.0"?>
<A:propfind xmlns:A="DAV:">
<A:prop><A:getcontenttype/></A:prop>
</A:propfind>


HTTP/1.1 207 Multi-Status
Date: Tue, 16 Feb 1999 18:26:23 GMT
Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.15
Content-Length: 298
Content-Type: text/xml
 
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" xmlns:W="http://www.cyberteams.com/">
<D:response>
<D:href>http://serv1-r.fwi.com/jrd/foo.html</D:href>
<D:propstat>
<D:prop>
<getcontenttype/>
</D:prop>
 <D:status>HTTP/1.1 400 Bad Request</D:status></D:propstat>
</D:response>
</D:multistatus>

1) I think this is a valid request.  (I could be wrong).  Why does
mod_webdav reject it?

2) If it does indeed think it's an invalid request, it should return status
400, not 207 Multistatus, because the error applies to the entire request
as a whole, not to the status of some individual resource within a set.



From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 13:40:06 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16613
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 13:40:05 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA06358
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 13:40:04 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id KAA30772;
	Tue, 16 Feb 1999 10:38:22 -0800
Sender: gstein@lyra.org
Message-ID: <36C9BB1D.480AD8A8@lyra.org>
Date: Tue, 16 Feb 1999 10:38:21 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: Dana Carson <dcarson@toad.net>
CC: WEBDAV WG <w3c-dist-auth@w3.org>
References: <3.0.3.32.19990215081728.0097f9f0@mailback.parc.xerox.com>
	 <v03130301b2e816c0c263@[209.49.30.46]>
	 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu> <3.0.5.32.19990216102957.00986420@mailback.parc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: New CyberTeams mod_webdav

Jim Davis wrote:
>...
> HTTP/1.1 207 Multi-Status
> Date: Tue, 16 Feb 1999 18:26:23 GMT
> Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.15
> Content-Length: 298
> Content-Type: text/xml
> 
> <?xml version="1.0" ?>
> <D:multistatus xmlns:D="DAV:" xmlns:W="http://www.cyberteams.com/">
> <D:response>
> <D:href>http://serv1-r.fwi.com/jrd/foo.html</D:href>
> <D:propstat>
> <D:prop>
> <getcontenttype/>
> </D:prop>
>  <D:status>HTTP/1.1 400 Bad Request</D:status></D:propstat>
> </D:response>
> </D:multistatus>
> 
> 1) I think this is a valid request.  (I could be wrong).  Why does
> mod_webdav reject it?
> 
> 2) If it does indeed think it's an invalid request, it should return status
> 400, not 207 Multistatus, because the error applies to the entire request
> as a whole, not to the status of some individual resource within a set.

3) there is a missing namespace on the <getcontenttype/>

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 13:47:52 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16763
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 13:47:51 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA06479
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 13:47:50 -0500 (EST)
Received: from appoint.net (mail.appoint.net [207.242.168.162])
	by phaisos.cube.com (8.8.5/8.8.5) with ESMTP id OAA27936
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 14:48:55 -0500
Received: from appoint.net [209.218.166.130] by appoint.net with ESMTP
  (SMTPD32-5.00) id ADCCC3C014C; Tue, 16 Feb 1999 13:49:48 EST
Sender: francis@phaisos.cube.com
Message-ID: <36C9BD98.FE6DF8E6@appoint.net>
Date: Tue, 16 Feb 1999 18:48:56 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: WebDAV WG <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: AdvCol section 4.15

In section 4.15 of the current Advanced Collections protocol Draft, we
have:

     In a request-URI /segment1/segment2/segment3, any of the paths
     /segment1/, /segment1/segment2/ or /segment1/segment2/segment3
     may identify a reference.  (See [URI], Section 3.3, for
     definitions of "path" and "segment".)  If any segment except
     the last segment of the path identifies a reference, that
     reference MUST have as its target a collection.  Otherwise,
     the request will fail.

I'm not sure this MUST is appropriate in all cases.  Suppose /segment1
is a reference that points to a CGI script? CGI includes the PATH_INFO
header, which means that CGI scripts can be written that behave as
collections.  So, if /segment1 points to /foo.cgi, then it may be
reasonable for /segment1/segment2/segment3 to get redirected to
/foo.cgi/segment2/segment3.

I believe that a more appropriate behavior may be for the server to
expand the path and either pass back the resulting URI without prejudice
(if it's a redirect reference) or process it exactly as if the resulting
URI had come in in the first place (if it's a direct ref).  If this
results in an error, fine; but don't add extra rules that will create
errors where none may be needed.

(Yes, there are efficiency issues in having the redirect reference point
the client at an invalid URI; but, given weak refs, we already have
them.)

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




CUBElink Internet Services.


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 15:11:55 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA19616
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 15:11:55 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA07852
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 15:11:53 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id MAA29250
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 12:09:18 -0800 (PST)
Message-Id: <4.1.19990216113833.00a54db0@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 16 Feb 1999 12:08:52 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Max Rible <max@glyphica.com>
In-Reply-To: <v03130302b2ec609f2ca5@[209.49.30.44]>
References: <4.1.19990211111242.00a28380@shell7.ba.best.com>
 <v03130301b2e816c0c263@[209.49.30.46]>
 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: PROPFIND hrefs and CyberTeams mod_webdav

One problem I'm having with testing the CyberTeams server is that it
the hrefs that its PROPFIND responses contain are on a different 
server and port than the actual WebDAV server.

When I use PROPFIND to discover the contents of a collection, I need 
some way to figure out how they relate to the request I made.
This is not a problem on most servers:  if I telnet to sandbox.xerox.com:8080
and PROPFIND / with Depth: 0, I get the href "/", which clearly refers
to http://sandbox.xerox.com:8080/.  The server at dav.ics.uci.edu gives me 
hrefs that have http://dav.ics.uci.edu/ on the front.  These are all
internally consistent.

When I connect to www.fwi.com:8080, I get hrefs that may be valid
hrefs for the documents that are served up when you connect to the
href given, but they are *not* valid hrefs for performing a PROPFIND on.  
http://www.fwi.com:8080/ gives me the href "http://serv1-r.fwi.com/" 
when I ask about it with PROPFIND.  serv1-r.fwi.com:80 does not respond 
to WebDAV requests; it requires using port 8080, and still makes
reference to port 80 for the objects on which the properties are
defined.

Is this in accordance with the WebDAV standard?

RFC2518 only says:
                                                           Each response
   XML element MUST contain an href XML element that gives the URI of
   the resource on which the properties in the prop XML element are
   defined.

Now, technically, properties can be defined on an object accessed through
a URI that is not the one used to perform the PROPFIND.  However,
this could be extremely confusing for developers to implement.  If 
it is acceptable for PROPFIND to return hrefs that have no apparent
connection to the URI requested, that should be called out for the 
people developing WebDAV clients and servers; if not, that should also
be made more explicit.

Currently, I treat UNIX-style paths as belonging to the server/port
combination of the web server I'm talking to, and full URLs are checked
against the server/port combination as a consistency check.  Should
I just assume that any server in an href returned by PROPFIND is
equivalent to the one I'm talking to?  What should the significance
of an href pointing to a different server be-- a hint that GET requests
should be made of the referenced server, perhaps?

% telnet www.fwi.com 8080
Trying 209.84.160.61...
Connected to serv1-r.fwi.com.
Escape character is '^]'.
PROPFIND / HTTP/1.1
Host: www.fwi.com:8080
Connection: close
Authorization: Basic xxxxxxxxxxxx
Depth: 0

HTTP/1.1 207 Multi-Status
Date: Tue, 16 Feb 1999 19:38:00 GMT
Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.15
Content-Length: 398
Content-Type: text/xml
Connection: close

<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" xmlns:W="http://www.cyberteams.com/">
<D:response>
<D:href>http://serv1-r.fwi.com/</href>
<D:propstat>
<D:prop>
<D:creationdate>Tue Feb 16 14:38:11 1999</D:creationdate>
<D:displayname>/</D:displayname>
<D:resourcetype><D:collection/>
</D:resourcetype>
</D:prop>
 <D:status>HTTP/1.1 200 OK</D:status></D:propstat>
</D:response>
</D:multistatus>

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 15:26:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA20007
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 15:26:33 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA08048
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 15:26:31 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id MAA31125;
	Tue, 16 Feb 1999 12:24:56 -0800
Sender: gstein@lyra.org
Message-ID: <36C9D418.4C737F9C@lyra.org>
Date: Tue, 16 Feb 1999 12:24:56 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: Max Rible <max@glyphica.com>
CC: WEBDAV WG <w3c-dist-auth@w3.org>
References: <4.1.19990211111242.00a28380@shell7.ba.best.com>
	 <v03130301b2e816c0c263@[209.49.30.46]>
	 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu> <4.1.19990216113833.00a54db0@shell7.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: PROPFIND hrefs and CyberTeams mod_webdav

Max Rible wrote:
> ...
> When I use PROPFIND to discover the contents of a collection, I need
> some way to figure out how they relate to the request I made.
> This is not a problem on most servers:  if I telnet to sandbox.xerox.com:8080
> and PROPFIND / with Depth: 0, I get the href "/", which clearly refers
> to http://sandbox.xerox.com:8080/.  The server at dav.ics.uci.edu gives me
> hrefs that have http://dav.ics.uci.edu/ on the front.  These are all
> internally consistent.

fyi, you can also test against http://msdav.lyra.org/dav/. You should
find that the <href> elements are similar to PyDAV (they begin with
"/").

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 16:33:35 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21334
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 16:33:34 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA09081
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 16:33:33 -0500 (EST)
Received: from appoint.net (mail.appoint.net [207.242.168.162])
	by phaisos.cube.com (8.8.5/8.8.5) with ESMTP id RAA01457
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 17:34:37 -0500
Received: from appoint.net [209.218.166.130] by appoint.net with ESMTP
  (SMTPD32-5.00) id A4A25350150; Tue, 16 Feb 1999 16:35:30 EST
Sender: francis@phaisos.cube.com
Message-ID: <36C9E46D.28E68865@appoint.net>
Date: Tue, 16 Feb 1999 21:34:38 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: WEBDAV WG <w3c-dist-auth@w3.org>
References: <4.1.19990211111242.00a28380@shell7.ba.best.com>
	 <v03130301b2e816c0c263@[209.49.30.46]>
	 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu> <4.1.19990216113833.00a54db0@shell7.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: PROPFIND hrefs and CyberTeams mod_webdav

Max Rible wrote:

> Is this in accordance with the WebDAV standard?
>
> RFC2518 only says:
>                                                            Each response
>    XML element MUST contain an href XML element that gives the URI of
>    the resource on which the properties in the prop XML element are
>    defined.

I would say that this is noncompliant, because the properties are not defined on
the resource in the href's URI.  Just because two URIs map to the same file
doesn't mean they refer to the same resource.

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




CUBElink Internet Services.


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 16:39:57 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21418
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 16:39:56 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA09158
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 16:39:54 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id NAA31425;
	Tue, 16 Feb 1999 13:38:24 -0800
Sender: gstein@lyra.org
Message-ID: <36C9E54F.641B4401@lyra.org>
Date: Tue, 16 Feb 1999 13:38:23 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: Max Rible <max@glyphica.com>
CC: w3c-dist-auth@w3.org
References: <4.1.19990211111242.00a28380@shell7.ba.best.com>
	 <v03130301b2e816c0c263@[209.49.30.46]>
	 <000301be5486$39756ba0$d115c380@galileo.ics.uci.edu>
	 <4.1.19990216113833.00a54db0@shell7.ba.best.com> <4.1.19990216124638.00a0ba10@shell7.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: PROPFIND hrefs and CyberTeams mod_webdav

Max Rible wrote:
>...
> The lack of DAV support on OPTIONS * can be confusing to some clients.
> Can you get it to put a DAV: 1 in the OPTIONS * response, even if
> none of the actual DAV methods are listed there?

I wasn't familiar with that form of OPTIONS. I'll go in there and get
the right thing done.

> I tweaked my client code a bit so it would check the OPTIONS on the
> URI given if OPTIONS * didn't return DAV: 1, and that did the trick.

fwiw, mod_dav only supports Class 1 right now.

> I got a Bad Gateway (502) response when I attempted renaming
> a directory through MOVE, and another one when I attempted to
> COPY a file.  DELETE, PUT, and MKCOL seem to be fine.

There is a known bug that requires the Destination header to specify the
port number in the absolute URI. The bug has been fixed and will be in
the next release (note that msdav.lyra.org is a stable server; it does
not track development, but is updated on each release). The 0.9.7
release should happen late Thursday night or earlier.

I greatly appreciate the feedback, and look forward to future bug
reports :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 16:47:18 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21528
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 16:47:17 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA09248
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 16:47:15 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id QAA14070;
	Tue, 16 Feb 1999 16:47:08 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <1HQALX9M>; Tue, 16 Feb 1999 16:45:28 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DCF@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'John Stracke'" <francis@appoint.net>, WebDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 16 Feb 1999 16:50:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: AdvCol section 4.15

Good catch.  We're working on rewriting this section this week, so there
will be a new (and we hope improved) draft on Friday or soon thereafter.

--Judy

> -----Original Message-----
> From: John Stracke [mailto:francis@appoint.net]
> Sent: Tuesday, February 16, 1999 1:49 PM
> To: WebDAV WG
> Subject: AdvCol section 4.15
> 
> 
> In section 4.15 of the current Advanced Collections protocol Draft, we
> have:
> 
>      In a request-URI /segment1/segment2/segment3, any of the paths
>      /segment1/, /segment1/segment2/ or /segment1/segment2/segment3
>      may identify a reference.  (See [URI], Section 3.3, for
>      definitions of "path" and "segment".)  If any segment except
>      the last segment of the path identifies a reference, that
>      reference MUST have as its target a collection.  Otherwise,
>      the request will fail.
> 
> I'm not sure this MUST is appropriate in all cases.  Suppose /segment1
> is a reference that points to a CGI script? CGI includes the PATH_INFO
> header, which means that CGI scripts can be written that behave as
> collections.  So, if /segment1 points to /foo.cgi, then it may be
> reasonable for /segment1/segment2/segment3 to get redirected to
> /foo.cgi/segment2/segment3.
> 
> I believe that a more appropriate behavior may be for the server to
> expand the path and either pass back the resulting URI 
> without prejudice
> (if it's a redirect reference) or process it exactly as if 
> the resulting
> URI had come in in the first place (if it's a direct ref).  If this
> results in an error, fine; but don't add extra rules that will create
> errors where none may be needed.
> 
> (Yes, there are efficiency issues in having the redirect 
> reference point
> the client at an invalid URI; but, given weak refs, we already have
> them.)
> 
> --
> /==============================================================\
> |John Stracke       | My opinions are my own |S/MIME & HTML OK |
> |francis@appoint.net|==========================================|
> |Chief Scientist    |NT's lack of reliability is only surpassed|
> |Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
> \==============================================================/
> 
> 
> 
> 
> CUBElink Internet Services.
> 


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 17:28:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22422
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 17:28:26 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA09794
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 17:28:25 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa02296;
          16 Feb 99 14:22 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 16 Feb 1999 14:19:31 -0800
Message-ID: <001001be59fa$6c9431a0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Adv. Col. Teleconference Minutes 2/16/99

The minutes from the Feb. 16, 1999 Adavanced Collections conference call
have now been placed on the Web at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990216.txt

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 18:23:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA24167
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 18:23:56 -0500 (EST)
Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA10539
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 18:23:54 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp8.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA37258
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 18:23:25 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA42592
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 18:23:47 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525671A.0080820A ; Tue, 16 Feb 1999 18:23:38 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525671A.00808146.00@D51MTA07.pok.ibm.com>
Date: Tue, 16 Feb 1999 18:26:32 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Adv. Col. Teleconference Minutes 2/16/99, relative


Re: Relative references

As an server implementer, I prefer that we stick to absolute, but if we do
decide to support relative, let's consider if we want to make an exception
for "..".

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com



From w3c-dist-auth-request@www10.w3.org  Tue Feb 16 23:38:19 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA27727
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Feb 1999 23:38:19 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id XAA13104
	for <w3c-dist-auth@w3.org>; Tue, 16 Feb 1999 23:38:17 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa07644;
          16 Feb 99 20:37 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 16 Feb 1999 20:33:59 -0800
Message-ID: <000701be5a2e$bddb1680$d115c380@galileo.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 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: Alpha test of /rfcland1.0

FYI.

- Jim

-----Original Message-----
>From: Carl Malamud [mailto:carl@invisible.net] 
Sent: Tuesday, February 16, 1999 3:12 PM
To: ietf@ietf.org
Subject: Alpha test of /rfcland1.0


Invisible Worlds has just opened an alpha test period for our new site,
/rfcland1.0. This site presents a new interface to the RFC series for
retrieval and authoring of documents.  Pointers to more information are
at the end of this note.

This database was prompted by a repeating cycle of food fights on this
mailing list having to do with proper data formats for presentations and
documents.   You will find at http://memory.palace.org/ a new
Internet-Draft by Marshall Rose, Chief of Protocol at Invisible Worlds,
on the topic of "Writing I-Ds and RFCs in XML."  As Marshall recently
observed:

  "In the 80s, RFC 822 was the universal data exchange language.  
   In the 90s we took a step sideways with ASN.1, but now it looks like 
   XML will be the data representation language for the next millenium."

In addition to this document which describes a Document Type Definition
for RFCs, you will find on the site a program called xml2rfc, which
takes a validly tagged XML document and produces HTML and ASCII output,
where the ASCII is identical to the original format of RFCs that we all
know and love.   Thanks to Steve Deering for his advance comments on the
draft.

Concurrent with the xml2rfc process, we've initiated a mirror process of
rfc2xml.  Brad Burdick and I (who did the EDGAR and ITU databases, but
we'll reserve news on those two topics for a subsequent period) have
been converting the existing RFC database into XML format.  This process
is long and tedious, and involved a combination of one really hairy
PERLball and some very long editing hours.  Today, we have 391 documents
in full markup which are undergoing a certification process and we have
a plan that will enable us to have the entire RFC database on-line in
XML by the end of the summer.

The last piece in /rfcland1.0 is a novel user interface that uses a
back-end search engine written by Marshall, a JavaScript library written
by Danny Goodman, a bunch of scripts by Brad Burdick, and a front-end
design by Becky and Larry Pranger.  While there is a LCD interface for
Lynx and 3.0 browsers, for those of you with MSIE 4.x or Netscape 4.x,
the site allows you to submit structured queries, sort the results by a
variety of parameters, drill down on individual documents, suggest added
metadata fields, provide commentary such as pointers to reference
implementations, and save the current state of a particular query for
later retrieval.  Unix users be warned that we are still tracking down a
seemingly random memory leak on NN4.5.

The alpha process will last one month, after which we will run the code
and the database through a beta process.  We hope to have the full site
stable shortly thereafter and certainly look forward to any feedback or
comments you may have during that time.  You can send comments directly
to me and if we see sufficient demand, we'd be pleased to bring this
work onto a mailing list or to participate in any other IETF discussions
on the subject.

Regards,

Carl Malamud
Invisible Worlds, Inc.

References:
[1] The main entrance to /rfcland1.0 is at http://memory.palace.org/
[2] You may reach the mirror site at http://palace.memory.org/
[3] Marshall T. Rose's new I-D is at http://memory.palace.org/authoring/
[4] A public directory of RFCs is at http://memory.palace.org/public
[5] General information on Invisible Worlds is at http://invisible.net/


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 10:14:47 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA07205
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 10:14:47 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA18416
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 10:14:46 -0500 (EST)
Received: from appoint.net (mail.appoint.net [207.242.168.162])
	by phaisos.cube.com (8.8.5/8.8.5) with ESMTP id LAA32339
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 11:15:47 -0500
Received: from appoint.net [209.218.166.130] by appoint.net with ESMTP
  (SMTPD32-5.00) id AD5C58E00F8; Wed, 17 Feb 1999 10:16:44 EST
Sender: francis@phaisos.cube.com
Message-ID: <36CADD26.F1FB2B45@appoint.net>
Date: Wed, 17 Feb 1999 15:15:51 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <8525671A.00808146.00@D51MTA07.pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Adv. Col. Teleconference Minutes 2/16/99, relative

ccjason@us.ibm.com wrote:

> Re: Relative references
>
> As an server implementer, I prefer that we stick to absolute,

OK, how come?

> but if we do
> decide to support relative, let's consider if we want to make an exception
> for "..".

Why's that?

One problem with the current idea of relative references: the notes say, "If
reftarget is relative, the client has the burden of figuring out the value of
the absolute URL.".  This sounds fine--clients already have code for relative
URLs--but it won't work, because a 302's Location: header is required to
provide an absolute URI (see RFC-2068, section 14.30).  (Plus, of course, it
doesn't work at all for direct references.)

I'd say that the Right Thing to do for expanding relative references is to
base them off of the Request-URI of the request you're currently processing.
This shouldn't be too hard: for the spec, point to RFC-1808 (with a note that
the "base document" is the reference itself); for the implementation, lift
some code from lynx or Mozilla or something.

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 13:56:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13632
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 13:56:27 -0500 (EST)
Received: from GW.NOVELL.COM ([151.155.134.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA21425
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 13:56:24 -0500 (EST)
Received: from ORM-GATEWAYS-Message_Server by GW.NOVELL.COM
	with Novell_GroupWise; Wed, 17 Feb 1999 11:48:46 -0700
Message-Id: <s6caac9e.053@GW.NOVELL.COM>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 16 Feb 1999 09:47:27 -0700
>From: "Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com>
To: <w3c-dist-auth@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Subject: Versioning Goals feedback

Here is my feedback on the latest goals document for WebDAV Versioning.

Definition #2 - Versioned Resource - We don't specify that this is an
actual object, but later in the goals we refer to it having a URL. 
Also, is it or is it not intended that this resource would have specific
properties that represent the entire set of revisions?  For instance, in
our DMS we allow a document owner to specify an "Official" revision,
which may or may not be the latest.  A label could be used, but I would
like to get such a property from a central place (the Versioned
Resource) rather than have to search for the label across all
revisions.

Definition #4 - Working Resource - It says a "working resource can
become a new..."  The meaning of 'can' isn't clear to me.  Is this a
may-or-may-not?

Definition #8 - Label - The definition isn't clear on the uniqueness. 
I believe the uniqueness applies only within a single versioned
resource, not across any larger namespace.  One of the goals makes this
clearer by stating that a given label may be used on revisions of
multiple versioned resources, so the definition ought to clarify
"uniqueness."

----------

Goal #1 - Right near the end it states "a non-versioning aware client
should be able to PUT to a versioned resource and have a new revision be
automatically created."  I agree with this, but want to make sure that
somewhere we clarify what this really implies, or simply state that the
server can deal with this however it desires.  If a server supports
this, how does that interact with what others may be doing with that
resource?  The non-versioning aware client is blind to the intricacies
of activities and configurations, and it seems this will present some
problems we may need to consider.

Goal #1 (again) - The last sentence says a subsequent GET on the same
versioned resource by this client should return the new version.  How
can this be guaranteed?  What if the PUT forced a branch?  How does a
GET know what branch if the client is non-versioning aware?

Goal #11 - This should not specify HTML, but rather indicate any
document that contains URL links should be able to use relative URLs.

Goal #13 - This sounds too much like we are setting a DASL
goal/requirement.  Can we word this such that it is clear that
Versioning needs to make these properties conform to DASL such that a
DASL query automatically has access to this info.  Or does our
requirement truly require something to be added or changed in DASL?

Goal #14 - Let's get rid of the "DM / CM" distinction and just go with
"Level 1" and "Level 2" versioning.  Then I would reword this goal to
something like, "It must be possible to implement Level 1 versioning
without having to implement any part of Level 2 versioning."

Goal #15 - Immutable Properties are never defined.

Goal #15 (again) - The last sentence of the goal portion, "It must be
possible to determine...", sounds like a separate goal.

Goal #15 (again) - Is there an important reason why mutability is being
defined at the revision level?  Why not greatly simplify and declare
this at the collection level?  I think it is very confusing to mix
within a collection, and having to check this on every resource I access
seems cumbersome.

Goal #17 - I don't agree with this.  Why can I not delete a given
revision while leaving the rest intact?  For CM there are probably valid
reasons, but 1) in the DMS world this is done frequently, and 2) what if
I just want to clean up some old, non-important part of the set?  I
frequently delete older revisions but rarely delete newer ones.

Goal #23.1 - Some systems, if they support versioning, have no concept
of an unversioned resource and a versioned resource.  When a new
document is created it is, from its inception, a versioned resource with
a single revision.  The goals & protocol need to support this type of
environment.


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 18:24:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA18992
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 18:24:51 -0500 (EST)
Received: from web606.mail.yahoo.com (web606.mail.yahoo.com [128.11.68.170])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA24542
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 18:24:49 -0500 (EST)
Message-ID: <19990217232623.26062.rocketmail@web606.mail.yahoo.com>
Received: from [209.102.20.221] by web606.mail.yahoo.com; Wed, 17 Feb 1999 15:26:23 PST
Date: Wed, 17 Feb 1999 15:26:23 -0800 (PST)
>From: Imran Khan <imrank123@yahoo.com>
To: w3c-dist-auth@w3.org
Cc: imrank123@yahoo.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Must PROPPATCH operation be atomic...

I am implementing WebDAV server but I feel I might be hitting in a
brick wall. I was wondering if PROPPATCH command enforces atomicity?
Atleast according to the WebDAV draft it says that either all the
set/remove operations pass or they all fail which means rolling back.
Can't I do "besteffort" vs. "atomic" in case of PROPPATCH? Because in
my application scenario I am trying to replace the current protocol
that allows besteffort as well as atomic flexibility.

Any response would be appreciated.

Thanks,
-Imran




_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 19:16:00 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA19627
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 19:15:59 -0500 (EST)
Received: from GW.NOVELL.COM (ocnt3.orem.novell.com [151.155.134.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id TAA24970
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 19:15:58 -0500 (EST)
Received: from ORM-GATEWAYS-Message_Server by GW.NOVELL.COM
	with Novell_GroupWise; Wed, 17 Feb 1999 17:08:23 -0700
Message-Id: <s6caf787.070@GW.NOVELL.COM>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 17 Feb 1999 17:12:40 -0700
>From: "Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com>
To: <jamsden@us.ibm.com>
Cc: <w3c-dist-auth@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Subject: RE: Version issues

Okay, I see our disconnect.  You are assuming that, even in Level 1, we
want some method of creating / identifying a logical *set* of resources,
such as all revisions that made up a particular milestone or release. 
In the DMS world there is no such grouping ability; every file is on its
own.  In the web site arena, however, I can see some value in this
grouping concept.

A simple versioning client and/or server, I believe, will not generally
implement workspaces if given a choice.  If that is true, then I would
vote to leave workspaces in Level 2.  If with my particular product I
want only basic versioning, but the ability to create sets (workspaces)
is important, then I can implement Level 1 versioning and add workspaces
without the rest of Level 2.  Now my client and my server can take
advantage of the ability to use workspaces, but other peoples' Level 1
clients can still make use of my server.  Workspaces are a useful
"utility" not a required piece of functionality.

So I vote workspaces remain in Level 2.

>>> <jamsden@us.ibm.com> 02/17/99 01:44PM >>>


Bruce,
I'm sorry to hear you weren't feeling well, but welcome back!

No, you're getting it just fine. For your item 1 below, the default
workspace does just what you want. You never even need to know its
there.
Recall the default workspace has a revision selection rule containing
checkedout and latest.

For item 2, the model currently allows access through a specific
revision
name which temporarily overrides the workspace, so this can be done
too.

If this was all you wanted, then probably workspaces for level 1 would
be
overkill. But, lets look at some other simple scenarios and see what
would
happen.

Say a development organization finishes work on  a milestone and wants
some
way to refer to the proper revisions. When work continues, these
revisions
won't necessarily be the latest revision because the resources may
have
changed in some appropriate way. Configurations solve this in level 2,
but
a common scenario for level 1 might be to come up with a label for the
release and use this label on every revision that participates.

So now every time you want to get the R1 revision for any of these
resources, you have to remember the revision name and provide it on
each
access. That's not so bad though, and is the same thing as remembering
a
workspace that has checkedout, R1, and latest in its revision
selection
rule. So far this is a wash.

Now say there's an R2 of the project as a whole. Some of the resources
changed and some of them didn't. You could label all the participant
revisions with R2 and that would work. But, after a while specific
revisions might have a lot of labels on them making the revision
history of
many resource hard to manage. In addition users have to remember
something
new, use label R2 instead of R1. An alternative is to just label the
ones
that changed with R2 and put checkedout, R2, R1, and latest in the
revision
selection rule. Then you'll get the right versions without remembering
R1,
R2, ..., you only have to remember the same workspace you were using
before
the revisions changed. All users get updated just by updating their
workspace. The default workspace revision selection rule can be changed
to
so that clients that can't or don't specify a revision will get the
right
revisions too. You could do this with default labels, but it would take
a
lot more work to update a property on every resource resetting its
default
when you can just add a single entry to a revision selection rule.

Workspaces just provide flexibility and ease of use for level 1, not
any
new functionality. I think they make the clients simpler and simplify
the
user's interaction with the server. So they are useful for level 1
even
though there aren't any activities or configurations.






"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/17/99
03:10:40 PM

To:   ckaler@microsoft.com, Jim Amsden/Raleigh/IBM
cc:   ietf-dav-versioning@w3.org 
Subject:  RE: Version issues




It isn't that workspaces provide unneeded functionality for Level 1.
It's just an abstraction that a) isn't in simple versioning models
now,
so would require learning and understanding, and b) isn't necessary.

The way I envision it for a Level 1 implementation is this:

1. If I request a resource and specify nothing other than "get me this
resource" the default is to give me the latest.  Without branching and
other Level 2 features, this is trivial.  With Level 2
implementations,
this is interpreted as the latest on the main line.

2. If I want something other than the latest, I include a Revision Id
or a Label.  This works fine for both levels, without any complexity
whatsoever.

Am I just not getting it?

>>> <jamsden@us.ibm.com> 02/17/99 11:20AM >>>


Comments below in <jra> tags.





Chris Kaler <ckaler@microsoft.com> on 02/17/99 12:13:42 PM

To:   Jim Amsden/Raleigh/IBM
cc:
Subject:  RE: Version issues




I don't think level 1 servers want to deal with revision selection
rules.
I
suspect they could be complicated.  As well, we need to understand the
semantics of parallel checkouts in the "default workspace".  The
current
definition of a workspaces prohibits this and I think it is an
important
requirement for level 1.

<jra>
Level 1 revision selection rules don't need to be complicated at all.
There
are no activities or configurations, so the revision selection rule
has
checkedout and 0 or more labels. When a resource is accessed with a
simple
URL, this means, get the checked out revision if any, otherwise look
for a
revision that has a matchin label. It's hard to imagine anything
simpler.
</jra>

Geoff and I started talking about the Revision-Id header yesterday.  I
think
it is reasonable for a client to request version X of /foo/bar.htm.
It
seems a cumbersome requirement to have to set the revision of
/foo/bar.htm
in the default workspace to be X and get /foo/bar.htm.  As well, this
won't
scale at all.  Imagine one person trying to get version X and one
trying to
get version Y.  We clearly need more discussion on this, but I don't
yet
see
how we can eliminate a header that specifies a revision.  I do believe
that
we could condense several headers into one...

<jra>
I also belive that users want to access specific revisions given the
label.
If they can assign a label, they should be able to access the resource
that
they assigned the label to. Recall that this capability is in the
model. In
the new version I moved the method to Repository.getResource(url :
String,
label : String = null) : Resource. There's also
Repository.getResource(url
: String, context Workspace) : Resource to access a resource in the
context
of a workspace. One reason you would want to do this is if you want to
look
at an old version, or compare two revisions, and don't want to change
your
workspace.

My issue isn't that I didn't want access by labels, only that access
when
labels aren't specified should use Workspaces to resolve the URL.
</jra>

I, personally, think that RSR are interesting but probably too
complicated
for level 1 servers.  We could say that the SETDEFAULT method is a
"utility"
method that modifies the workspace to use the specified revision of
the
specified resource.  This allows us to still describe level 1
functionality
in the context of level 2 workspaces.  And for level 2, it provides a
handy
service for augmenting an RSR without having to pull it, modify it,
and
put
it.

<jra>
Again, I don't think revision selection rules are complicate at all,
especially for level 1 which doesn't have activities, merging, or
configurations. The complexity results from introducing multiple
revisions.
Leaving workspaces out of level 1 will just move the complexity to the
client or user who have to remember lots of labels on a resource by
resource basis. This makes the server simpler, but not WebDAV.

I stress again, what would anyone want to do with versioning level 1
that
workspaces wouldn't support? What would workspaces include that would
be
considered too much for level 1? We need specific scenarios that
address
these issues. As you know, I am also keen to keep things simple. Its
just I
want the simplicity for the users and clients, not necessarily just
for
the
server.
</jra>

Thoughts?

Chris

-----Original Message-----
>From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] 
Sent: Tuesday, February 16, 1999 12:56 PM
To: Chris Kaler
Subject: RE: Version issues




But if we keep the Revision-Id header and a SETDEFAULT method, this
will
conflict with level using a default workspace. I suggest we
effectively
use
default workspaces for level 1. This doesn't mean servers have to
implement
them, only do something that makes them look like they work. Clients
should
be able to use level 1 services without being aware of workspaces. If
activities and configurations are not in level 1, then the workspace
only
has to consider revision selection rules that include checkedout,
latest,
and revision labels. This should be pretty simple.






Chris Kaler <ckaler@microsoft.com> on 02/16/99 03:21:30 PM

To:   Jim Amsden/Raleigh/IBM, ietf-dav-versioning@w3.org 
cc:
Subject:  RE: Version issues





[CK] Comments below...

A few issues came up at our last versioning working group meeting:

1. DAV versioning level 1 will still need to be a way of resolving
access
to versioned resources given just a URL (and not a label). If
workspaces
aren't supported, level 1 servers will have to provide some other way
to
resolve URLs to specific revisions, perhaps a default revision for
each
versioned resource. For level 2 servers that do support workspaces,
this
would result in two, potentially conflicting ways of performing URL
mapping. This is a strong argument for including workspaces in level
1.
What would anyone want to do with versioning level 1 that workspaces
wouldn't support? What would workspaces include that would be
considered
too much for level 1? If there are no compelling answers to these
questions, we should include workspaces in level 1, including the
default
workspace.

[CK] I suggest we keep the Revision-Id header and the SETDEFAULT
method.

2. Deleting a resource must explicitly state that the resource is
removed
from its parent collection; that is, the collection with which the
resource
is an internal member. Versioning complicates delete semantics. There
are
three things we might want to delete: an unversioned or working
resource, a
revision (and all its descendents?) of a versioned resource, a
versioned
resource and all its revision history. This must be done in the
context
of
versioned and unversioned collections that contain the resource, or
versioned resource as an internal member. The preferred way to do this
would be to have add and remove methods on collections to create and
delete
resources as its the collection that controls the namespace.
Unfortunately,
DAV doesn't have those semantics, so we will have to find a
work-around
for
versioning.

[CK] I expect deleting a working resource to be the same as
UNCHECKOUT.
[CK] Deleting a versioned resource is up to the store.  Some stores
might
[CK] just delete it.  Some might create an "delete" version.  I don't
think
[CK] we want to push a specific model on people.  Especially since the
[CK] DELETE method is about a resource and in no way describes the
[CK] underlying repository actions.

Actually, the current WebDAV spec is a little confusing about
collections
and their members. The current spec indicates collections contain
URLs,
not
resources. But, there is the notion of internal members and
referential
members, and deleting a collection deletes all its internal members.
So
the
collection behaves like it contains resources, not URLs. This issue
will
likely get more confusing when we add versioned resources, versioned
collections, and multiple revisions.

[CK]Your right -- some clarification here would be could.

3. It is not possible to automatically create workspaces or activities
for
either non-versioning clients, or versioning clients that don't
specify
them. Default workspaces and/or activities must be used. Creating a
new
workspace or activity on each request could cause resources that were
manipulated in the previous request to disappear.

[CK] If we say this is what "logically" happens on a Level 1 server
then
[CK] OK.  But if the server must in fact do this, then I think the
cost
[CK] is too high since Level 1 clients don't care about this
information.












From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 19:22:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA19860
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 19:22:27 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA25038
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 19:22:25 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id QAA03906;
	Wed, 17 Feb 1999 16:21:26 -0800
Sender: gstein@lyra.org
Message-ID: <36CB5D05.604958C@lyra.org>
Date: Wed, 17 Feb 1999 16:21:25 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: Imran Khan <imrank123@yahoo.com>
CC: w3c-dist-auth@w3.org
References: <19990217232623.26062.rocketmail@web606.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Must PROPPATCH operation be atomic...

Imran Khan wrote:
> 
> I am implementing WebDAV server but I feel I might be hitting in a
> brick wall. I was wondering if PROPPATCH command enforces atomicity?
> Atleast according to the WebDAV draft it says that either all the
> set/remove operations pass or they all fail which means rolling back.
> Can't I do "besteffort" vs. "atomic" in case of PROPPATCH? Because in
> my application scenario I am trying to replace the current protocol
> that allows besteffort as well as atomic flexibility.

Painful as it may be, the operation must be atomic. As a fellow server
implementor, I sympathize ... I haven't implemented rollback either :-)

It would be nice if a client could say "do best effort", but that
doesn't exist. The atomic requirement allows a client to ensure that a
consistent set of changes are made.

IMO, if you have a closed system (your own client and server), then it
is perfectly acceptable to insert a new child element in the PROPPATCH
to identify best-effort. For example, the request body could look like:

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.example.com/mydav/">
  <Z:besteffort>
  <D:set>
    <D:prop>
      <Z:some-prop/>
    </D:prop>
  </D:set>
  <D:remove>
    <D:prop>
      <Z:other-prop/>
    </D:prop>
  </D:remove>
</D:propertyupdate>

Your server could then recognize the besteffort tag. Your client would
also use the tag. Other clients that access the server would not include
it, so your server would guarantee atomicity for them (since they expect
it).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 19:31:06 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA20075
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 19:31:06 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA25122
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 19:31:04 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FCCMVY49>; Wed, 17 Feb 1999 16:31:03 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F31@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Greg Stein'" <gstein@lyra.org>, Imran Khan <imrank123@yahoo.com>
Cc: w3c-dist-auth@w3.org
Date: Wed, 17 Feb 1999 16:31:01 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Must PROPPATCH operation be atomic...

In http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html
(section 3) I talk about why WebDAV requires atomicity. I also question how
critical this need really is. In the end, however, I suspect that atomicity
really is important. I can just imagine too many scenarios where not having
a truly atomic PROPPATCH would leave your system in a truly horrendous
state.

			Yaron

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, February 17, 1999 4:21 PM
> To: Imran Khan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Must PROPPATCH operation be atomic...
> 
> 
> Imran Khan wrote:
> > 
> > I am implementing WebDAV server but I feel I might be hitting in a
> > brick wall. I was wondering if PROPPATCH command enforces atomicity?
> > Atleast according to the WebDAV draft it says that either all the
> > set/remove operations pass or they all fail which means 
> rolling back.
> > Can't I do "besteffort" vs. "atomic" in case of PROPPATCH? 
> Because in
> > my application scenario I am trying to replace the current protocol
> > that allows besteffort as well as atomic flexibility.
> 
> Painful as it may be, the operation must be atomic. As a fellow server
> implementor, I sympathize ... I haven't implemented rollback 
> either :-)
> 
> It would be nice if a client could say "do best effort", but that
> doesn't exist. The atomic requirement allows a client to ensure that a
> consistent set of changes are made.
> 
> IMO, if you have a closed system (your own client and server), then it
> is perfectly acceptable to insert a new child element in the PROPPATCH
> to identify best-effort. For example, the request body could 
> look like:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:"
> xmlns:Z="http://www.example.com/mydav/">
>   <Z:besteffort>
>   <D:set>
>     <D:prop>
>       <Z:some-prop/>
>     </D:prop>
>   </D:set>
>   <D:remove>
>     <D:prop>
>       <Z:other-prop/>
>     </D:prop>
>   </D:remove>
> </D:propertyupdate>
> 
> Your server could then recognize the besteffort tag. Your client would
> also use the tag. Other clients that access the server would 
> not include
> it, so your server would guarantee atomicity for them (since 
> they expect
> it).
> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/
> 


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 21:02:29 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA21969
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 21:02:28 -0500 (EST)
Received: from web606.mail.yahoo.com (web606.mail.yahoo.com [128.11.68.170])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id VAA25931
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 21:02:26 -0500 (EST)
Message-ID: <19990218020356.12546.rocketmail@web606.mail.yahoo.com>
Received: from [209.102.20.221] by web606.mail.yahoo.com; Wed, 17 Feb 1999 18:03:56 PST
Date: Wed, 17 Feb 1999 18:03:56 -0800 (PST)
>From: Imran Khan <imran1233@yahoo.com>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: How can I do conditional PROPPATCH....

Is there an existing way to set/remove properties based on the fact
that certain conditions are met in WebDAV or DASL?? I looked at the
existing draft of DASL and it seems to be only query (SELECT), no
INSERT or UPDATE. Any guidance would be appreciated.

Thanks,
Rajiv



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


From w3c-dist-auth-request@www10.w3.org  Wed Feb 17 21:27:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA22260
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Feb 1999 21:27:23 -0500 (EST)
Received: from kurgan.lyra.org (kurgan.lyra.org [208.192.43.9])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id VAA26151
	for <w3c-dist-auth@w3.org>; Wed, 17 Feb 1999 21:27:21 -0500 (EST)
Received: from kurgan.lyra.org (localhost [127.0.0.1])
	by kurgan.lyra.org (8.8.5/8.8.5) with SMTP id SAA04317;
	Wed, 17 Feb 1999 18:26:13 -0800
Sender: gstein@lyra.org
Message-ID: <36CB7A43.4943144F@lyra.org>
Date: Wed, 17 Feb 1999 18:26:11 -0800
>From: Greg Stein <gstein@lyra.org>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586)
MIME-Version: 1.0
To: Imran Khan <imran1233@yahoo.com>
CC: w3c-dist-auth@w3.org
References: <19990218020356.12546.rocketmail@web606.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: How can I do conditional PROPPATCH....

Imran Khan wrote:
> 
> Is there an existing way to set/remove properties based on the fact
> that certain conditions are met in WebDAV or DASL?? I looked at the
> existing draft of DASL and it seems to be only query (SELECT), no
> INSERT or UPDATE. Any guidance would be appreciated.

Not that I know of. You'll need two round trips (at least) for that.

It really depends on how "atomic" you need to be. You can issue a SEARCH
followed by a PROPPATCH. If you need a true atomic operation, then you
can LOCK, SEARCH, (test), PROPPATCH, UNLOCK.

There are also funny things you can do with the If: header, but I'm not
really clear on how it can be used in situations like this.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From w3c-dist-auth-request@www10.w3.org  Thu Feb 18 12:25:43 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA04878
	for <w3c-dist-auth@www19.w3.org>; Thu, 18 Feb 1999 12:25:43 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id MAA03860
	for <w3c-dist-auth@w3.org>; Thu, 18 Feb 1999 12:25:42 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa04551;
          18 Feb 99 9:21 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 18 Feb 1999 09:18:26 -0800
Message-ID: <000601be5b62$b1fe2ca0$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <36CB7A43.4943144F@lyra.org>
Importance: Normal
Subject: RE: How can I do conditional PROPPATCH....


> There are also funny things you can do with the If: header, but I'm not
> really clear on how it can be used in situations like this.

The If header doesn't let you express predicates involving property values,
only etags and lock tokens.

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu Feb 18 20:07:40 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA14924
	for <w3c-dist-auth@www19.w3.org>; Thu, 18 Feb 1999 20:07:39 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA09630
	for <w3c-dist-auth@w3.org>; Thu, 18 Feb 1999 20:07:38 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FCC583DC>; Thu, 18 Feb 1999 17:07:36 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757DD5@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
To: "'Bruce Cragun'" <BCragun.ORM2-1.OREM2@GW.Novell.com>,
        w3c-dist-auth@w3.org
Date: Thu, 18 Feb 1999 17:07:32 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Versioning Goals feedback


Here's more feedback...

[Note that I reference Bruce's comments and Jim's replies]

- Jim: Excellent work pulling this together - Thanks!

- It would be great if the scenarios were numbered

- In "Creating a Versioned Resource": we talked about not using
  CHECKIN as the way this occurs.  I would like to re-iterate that
  I think we should have a separate method.

- I'm worried that the scenarios and goals assume that there are
  workspaces and activities.  We have had some mail exchanges on
  the subject and I thought I would mention here that I don't
  believe either should be visible to a Level 1 client.

- I think we need a scenario for getting a specific revision.  Joe
  lists the history and decides that the revision whose revision id
  is 32345 is the desired version.  Joe's client directly obtains
  this revision from the server.

- The "Parallel Development with Activities" section leaves one with
  the impression that you can only do parallel checkouts via activities.
  I believe that Level 1 must support parallel checkouts and shouldn't
  require activities.

- The last paragraph of "Parallel Development with Activities" confused
  me.  If one person wants to prevent checkouts, they would lock the
  versioned resource not the working resource. ??

- I believe that the merge stuff is interesting but more complex than
  we need to address in the first draft of versioning.  I think that
  we will find it difficult to agree on how you express the differences,
  the rules, communication, etc.  I would rather address this stuff in 
  a subsequent draft/effort after we get some of the simple concepts
handled.

- Same comment for the last paragraph of "Creating a Configuration" -- this
  walks into the merge path.

- I don't understand how the "Changing a Revision" section is different
  from "Editing a Mutable Revision".  Aren't they saying essentially
  the same thing?  Or did I just miss it? :-)

- The "Accessing Resources by Non-Versioning Aware Clients" assumes there
  is always a workspace notion.  If we are describing this as a model, OK,
  but if the client or server have to know about this for Level 1, I think
  this is an issue.  See previous mail.

- Several times the revision "label" is used.  I think people will often
  want to use the revision "id".

- The last paragraph of "Updating Resources by Non-versioning Aware Clients"
  goes into a discussion of workspaces and activities.  I assume that a
  down-level client knows neither.

- Can we add a scenario about configurations related to other configuration?
  Alice is using the Beta1 configuration and finds a bug.  She fixes the
  bug and checks it in.  She creates a new configuration, Beta1a which
  consists of the "Beta1" configuration plus the changes in the "Bug1223"
  activity.

- Goal 1: I agree with Bruce that a down-level PUT could result in the
  server automatically branching.

- Goal 5: I believe this is needed.  We see several usage scenarios where
  different revisions are checked out simultaneously.

- Goal 15: In response to Jim's update to this goal -- I believe that
  both live and dead properties can be mutable (or immutable).

- Goal 17: I agree with Bruce that you should be able to delete a
  revision without deleting its successors.  However, I'm fine with
  saying that a server MAY refuse the request.

- I think we need a Goal 22.5 that states that simple parallel development
  must be possible without activities.

- Goal 23.1, bullet 2: I should be able to use a revision id as well

- Goal 23.1, bullet 3: I should be able to checkout and create a
  working resource without using activities.

- Goal 23.2, bullet 3: I think this should be "revision labels" since
  there can only be a single revision id and this section is all about
  labels.

- Goal 23.3, bullet 3: I don't think we should be addressing merge at
  this point.  We should constrain the problem so that we can generate
  a protocol.  We can then layer merge semantics on top in a separate draft.

- Goal 23.4, bullet 3: I should be able to access a revision using
  the URL of the versioned resource and a configuration name since
  a configuration uniquely selects a single revision.

- Goal 23.4, bullet 5: I would like to add into this that is must be
  possible for a client to determine this.  My point is that the protocol
  doesn't need to support this exact operation if a client, using other
  mechanisms, can determine this information.

- Goal 31:  This should be true inside or outside of an activity.

Thanks for all the hard work Jim, this is starting to come together.

Chris


From w3c-dist-auth-request@www10.w3.org  Fri Feb 19 00:48:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA17764
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Feb 1999 00:48:23 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id AAA11743
	for <w3c-dist-auth@w3.org>; Fri, 19 Feb 1999 00:48:21 -0500 (EST)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa10122;
          18 Feb 99 21:45 PST
To: John Stracke <francis@appoint.net>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Wed, 17 Feb 1999 15:15:51 GMT."
             <36CADD26.F1FB2B45@appoint.net> 
Date: Thu, 18 Feb 1999 21:44:51 -0800
>From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9902182145.aa10122@paris.ics.uci.edu>
Subject: Re: Adv. Col. Teleconference Minutes 2/16/99, relative 

>One problem with the current idea of relative references: the notes say, "If
>reftarget is relative, the client has the burden of figuring out the value of
>the absolute URL.".  This sounds fine--clients already have code for relative
>URLs--but it won't work, because a 302's Location: header is required to
>provide an absolute URI (see RFC-2068, section 14.30).  (Plus, of course, it
>doesn't work at all for direct references.)

Right, the server must handle the relative to absolute conversion.
Most servers already do this for config or cgi-based redirects.

>I'd say that the Right Thing to do for expanding relative references is to
>base them off of the Request-URI of the request you're currently processing.
>This shouldn't be too hard: for the spec, point to RFC-1808 (with a note that
>the "base document" is the reference itself); for the implementation, lift
>some code from lynx or Mozilla or something.

That would be RFC 2396.

....Roy


From w3c-dist-auth-request@www10.w3.org  Fri Feb 19 10:09:07 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA26423
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Feb 1999 10:09:06 -0500 (EST)
Received: from fxiod04.is.chrysler.com (fxiod04.is.chrysler.com [204.189.94.73])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA16627
	for <w3c-dist-auth@w3.org>; Fri, 19 Feb 1999 10:09:04 -0500 (EST)
>From: MGA@daimlerchrysler.com
Received: from odnpspr2-nf0.oddc.chrysler.com (odnpspr2-nf0.oddc.chrysler.com [129.9.202.74])
	by fxiod04.is.chrysler.com (8.9.0/8.9.0) with ESMTP id KAA09632;
	Fri, 19 Feb 1999 10:06:47 -0500 (EST)
Received: from lngodd02.notes.chrysler.com (lngodd02.notes.chrysler.com [129.9.202.75])
	by odnpspr2-nf0.oddc.chrysler.com (8.9.0/8.9.0/daimlerchrysler-relay-1.0-kcd) with SMTP id KAA13305;
	Fri, 19 Feb 1999 10:08:55 -0500 (EST)
Received: by lngodd02.notes.chrysler.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 8525671D.0053388F ; Fri, 19 Feb 1999 10:08:59 -0500
X-Lotus-FromDomain: CHRYSLER
To: Chris Kaler <ckaler@microsoft.com>
cc: "'Bruce Cragun'" <BCragun.ORM2-1.OREM2@GW.Novell.com>,
        w3c-dist-auth@w3.org
Message-ID: <0525671D.005336CB.00@lngodd02.notes.chrysler.com>
Date: Fri, 19 Feb 1999 10:04:28 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: Versioning Goals feedback

I just signed up to this forum, thus I'm not up to speed as to the discussion at
hand.  We at DaimlerChrysler are very much interested in versioning of web
content.
Currently there is no consistent and automated process to promote and control
versioning of web content from multiple suppliers (outside the firewall) and
internal content creators. Web page templates are maintained by IS, however,
site content is maintained, in many cases, by the customer community. We've
estimated that manageability of Web content becomes extremely difficult after
the site reaches 2000 pages.  Some of our Intranet and Internet sites either
have reached or are close to reaching that maximum.  As a result of our recent
merger, we have common web sites updated and administered, 7x24, on both sides
of the Atlantic. All this has posed some interesting problems.
I have read that the current release of WebDAV does not contain versioning. Are
there any estimates/targets for when versioning can be expected?
Please give me the URL for the document you are discussing. We have obvious
versioning and authoring requirement. I'll match them up with what you've
published so far. Then I'll respond to this forum with my comments.

Fred Appel
DaimlerChrysler ITM/Version Management
Phone: (810) 758-9501
E-mail: mga@daimlerchrysler.com
Pager: mga-page@is.chrysler.com





Chris Kaler <ckaler@microsoft.com> on 02/18/99 08:07:32 PM
                                                              
                                                              
                                                              
 To:      "'Bruce Cragun'"                                    
          <BCragun.ORM2-1.OREM2@GW.Novell.com>,               
          w3c-dist-auth@w3.org                                
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: RE: Versioning Goals feedback                       
                                                              









Here's more feedback...

[Note that I reference Bruce's comments and Jim's replies]

- Jim: Excellent work pulling this together - Thanks!

- It would be great if the scenarios were numbered

- In "Creating a Versioned Resource": we talked about not using
  CHECKIN as the way this occurs.  I would like to re-iterate that
  I think we should have a separate method.

- I'm worried that the scenarios and goals assume that there are
  workspaces and activities.  We have had some mail exchanges on
  the subject and I thought I would mention here that I don't
  believe either should be visible to a Level 1 client.

- I think we need a scenario for getting a specific revision.  Joe
  lists the history and decides that the revision whose revision id
  is 32345 is the desired version.  Joe's client directly obtains
  this revision from the server.

- The "Parallel Development with Activities" section leaves one with
  the impression that you can only do parallel checkouts via activities.
  I believe that Level 1 must support parallel checkouts and shouldn't
  require activities.

- The last paragraph of "Parallel Development with Activities" confused
  me.  If one person wants to prevent checkouts, they would lock the
  versioned resource not the working resource. ??

- I believe that the merge stuff is interesting but more complex than
  we need to address in the first draft of versioning.  I think that
  we will find it difficult to agree on how you express the differences,
  the rules, communication, etc.  I would rather address this stuff in
  a subsequent draft/effort after we get some of the simple concepts
handled.

- Same comment for the last paragraph of "Creating a Configuration" -- this
  walks into the merge path.

- I don't understand how the "Changing a Revision" section is different
  from "Editing a Mutable Revision".  Aren't they saying essentially
  the same thing?  Or did I just miss it? :-)

- The "Accessing Resources by Non-Versioning Aware Clients" assumes there
  is always a workspace notion.  If we are describing this as a model, OK,
  but if the client or server have to know about this for Level 1, I think
  this is an issue.  See previous mail.

- Several times the revision "label" is used.  I think people will often
  want to use the revision "id".

- The last paragraph of "Updating Resources by Non-versioning Aware Clients"
  goes into a discussion of workspaces and activities.  I assume that a
  down-level client knows neither.

- Can we add a scenario about configurations related to other configuration?
  Alice is using the Beta1 configuration and finds a bug.  She fixes the
  bug and checks it in.  She creates a new configuration, Beta1a which
  consists of the "Beta1" configuration plus the changes in the "Bug1223"
  activity.

- Goal 1: I agree with Bruce that a down-level PUT could result in the
  server automatically branching.

- Goal 5: I believe this is needed.  We see several usage scenarios where
  different revisions are checked out simultaneously.

- Goal 15: In response to Jim's update to this goal -- I believe that
  both live and dead properties can be mutable (or immutable).

- Goal 17: I agree with Bruce that you should be able to delete a
  revision without deleting its successors.  However, I'm fine with
  saying that a server MAY refuse the request.

- I think we need a Goal 22.5 that states that simple parallel development
  must be possible without activities.

- Goal 23.1, bullet 2: I should be able to use a revision id as well

- Goal 23.1, bullet 3: I should be able to checkout and create a
  working resource without using activities.

- Goal 23.2, bullet 3: I think this should be "revision labels" since
  there can only be a single revision id and this section is all about
  labels.

- Goal 23.3, bullet 3: I don't think we should be addressing merge at
  this point.  We should constrain the problem so that we can generate
  a protocol.  We can then layer merge semantics on top in a separate draft.

- Goal 23.4, bullet 3: I should be able to access a revision using
  the URL of the versioned resource and a configuration name since
  a configuration uniquely selects a single revision.

- Goal 23.4, bullet 5: I would like to add into this that is must be
  possible for a client to determine this.  My point is that the protocol
  doesn't need to support this exact operation if a client, using other
  mechanisms, can determine this information.

- Goal 31:  This should be true inside or outside of an activity.

Thanks for all the hard work Jim, this is starting to come together.

Chris





From w3c-dist-auth-request@www10.w3.org  Fri Feb 19 16:23:39 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA04131
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Feb 1999 16:23:39 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id QAA21040
	for <w3c-dist-auth@w3.org>; Fri, 19 Feb 1999 16:23:37 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa14028;
          19 Feb 99 13:22 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 19 Feb 1999 13:19:16 -0800
Message-ID: <000401be5c4d$821b0a80$d115c380@galileo.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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: New advanced collections specs.

New Internet Draft revisions of the Advanced Collections requirements and
protocol specifications are now available via the WebDAV Web site.

Requirements:

http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collecti
on-reqts-04.txt

Protocol:

http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collecti
on-protocol-03.txt


Thank you Judy for organizing the conference calls, and leading this work
forward.

The advanced collections design team believes that these specifications are
close to being complete.  If you have been waiting for a stable revision of
these specifications before performing your review of these documents, wait
no longer.  Unless there is significant feedback on the mailing list, or
during the WG meeting in Minneapolis, these documents will rapidly proceed
to a working group last call in late March/early April.

- Jim



From w3c-dist-auth-request@www10.w3.org  Mon Feb 22 01:36:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA28257
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Feb 1999 01:36:28 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA14666
	for <w3c-dist-auth@w3.org>; Mon, 22 Feb 1999 01:36:27 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <FCC7QRWP>; Sun, 21 Feb 1999 22:36:20 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F4A@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, WEBDAV WG
	 <w3c-dist-auth@w3.org>
Date: Sun, 21 Feb 1999 22:36:18 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: Collections Protocol Review

The following comments are based on
http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collecti
on-protocol-03.txt:

(Issue #1) Section 2 - Definition of the term Collection - What does the
word "contains" mean in the definition of a collection? Does this mean if I
perform a GET I will get a list of them?

(Issue #2) Section 2- Definition of the term Referential Resource - It
should be explicitly pointed out that this is a new resource type. I think
this would make the definition clearer.
	The term "body" as used in RFC 2068 and 2518 refer exclusively to
messages, not resources. Hence the phrase "body of its own" does not have a
definition in either spec.
	In general I find this definition confusing as it indicates that a
reference is a resource but has some relationship with a target somehow
involving properties. I think the problem is that the authors have cleaved
too tightly to the file system heritage of this feature. First off, I think
we need to cease viewing direct references and redirect references as
children of the same mother. They are two very different creatures with
largely unrelated functionality. It would probably be in everyone's interest
if they were given names which shared no common words.
	A direct reference is really just an HTTP object which practices
inheritances. Its sole purpose being to passthrough any methods it receives
to its target. Thus if a PROPFIND comes the direct reference will simply
pass it through to the target. This behavior can then be stopped by
explicitly marking the request as being addressed to the reference resource
itself. Describing direct references as "passing through" methods lets us
avoid discussions of undefined terms like "body" and discussions involving
vague references to properties.
	A redirect reference is just a 3xx machine. It is a resource which
always returns 3xx to all requests which are not appropriate marked as being
direct at the reference. By describing redirect resources in such concrete
terms we avoid the maddening ambiguities inherent to the current
specification.

Section 4.1 - I would like to congratulate the authors for the section on
why referential integrity is not supported. It is a very well written
explanation.

(Issue #3) Section 4.2 - Problems with the Location header and redirect
reference responses - I never liked the location header very much because it
only allows one to return a single URI. Thus if the target resource has
multiple names by which it is accessible one can only return one of them.
This isn't terribly robust. As such I would propose that this specification
provide an extension header to Location which allows for additional URIs to
be returned.

(Issue #4) Section 4.3.1 - The Ref-Integrity header and its support for the
enforce value - If I send in an "enforce" value for Ref-Integrity, can I
delete a target which still has references? If I don't send in a
Ref-Integrity header, can I be sure if I can delete a target which still has
references? As beautifully explained in the same spec, the answer currently
is "we don't know." This means that creating a reference without a
Ref-Integrity header or with the value "enforce" is a blind act. You have no
idea what the results will be and this very clearly violates the Hardie
Rule.
	The naïve solution would be to just rip out the ref-integrity
header, however the current language in the spec says that in this case it
is a gamble as to what one will get. Again, this violates the Hardie Rule.
	As such I propose that the Ref-Integrity header MUST be included in
all requests and that the only defined value be DAV:do-not-enforce. A server
receiving this header with an unrecognized value MUST fail the request. We
do not act in the interests of interoperability by allowing referential
integrity when as this spec so elegantly argues, no one can even define what
this means. As such defining an "enforce" header does not help
interoperability and so should not be in the spec. For now let various
implements put out RFCs defining their particular implementation along with
a URL for the Ref-Integrity header that requires their particular
implementation. Hopefully at some point in the future there will be
convergence and a standardized URL can be specified.

(Issue #5) Section 4.3.1 - Why DAV:reftarget, reftype and refintegrity are
stand alone properties - I do not understand why DAV:reftarget, DAV:reftype
and DAV:refintegrity are all defined as properties. As these values help to
define the nature of the resource type should they not have their values
included inside the DAV:reference element in the DAV:resourcetype property?

(Issue #6) Section 4.3.1 - MKREF and the use of bodies - Why doesn't MKREF
follow the same rules that MKCOL has regarding the possible inclusion of a
body? They provide for the inclusion of a body but specify that if the
content-type of the body is not understood then the request MUST be
rejected. I believe the same rational that merited the inclusion of this
language in MKCOL's definition applies here.

(Issue #7) Section 4.4.1 - Do references to collections have to provide
references for all the members of the collection? - If one creates a
reference to a collection is one also required to create references to all
the members of that collection? I suspect the answer is yes but this is not
clear from the specification. For example, the referential resource in the
example is http://www.svr.com/MyCollection/tuva/ and it points to a
collection which has a member called history.html. Does this mean that a GET
on http://www.svr.com/MyCollection/tuva/history.html MUST succeed? In other
words, that by creating a reference to a collection one is required to
create references to its entire tree? Again, I suspect the answer is yes
(this would explain the PROPFIND response format for direct references as
well as the COPY behavior for direct references) but this requirement is
never explicitly stated in the spec.

(Issue #8) Section 4.5.5 - Requiring reftype and reftarget in COPY responses
- Why must one return the reftype and reftarget information for COPY
requests? As this information is available from a PROPFIND on the
destination requiring it to be supplied as part of the COPY response seems
redundant. Including this information also would most likely break RFC 2518
clients who would expect an empty body on a fully successful copy.

(Issue #9) Section 4.6 - Banning passthrough behavior on DELETE and MOVE - I
have a direct reference http://foo/bar to http://bar/blaz. I can define a
MOVE on http://foo/bar to http://icky/bik as meaning that http://bar/blaz is
to be moved to http://icky/bik. Following the logic discussed in Issue #7 I
can even properly define how to move any children that http://bar/blaz might
have. With DELETE I can define a DELETE of http://foo/bar as meaning that
http://bar/blaz should be deleted. So there doesn't seem to be any technical
reason to ban passthrough behavior on MOVE and DELETE involving direct
references.
	I suspect the real reason that passthrough behavior is disallowed on
direct references is because of concerns regarding interactions with
existing WebDAV clients. In most file systems that support links if one
deletes or moves a link, only the link is deleted or moved. I suspect the
authors are concerned that allowing passthrough on DELETE and MOVE would
mean that if an existing WebDAV client asks for a DELETE or MOVE then the
resource being pointed at would be deleted/moved as well, which wasn't
something the non-reference enabled client would have intended. As such I
think it is completely reasonable to design the protocol such that if a RFC
2518 client issues a DELETE or MOVE then only the direct reference and not
the target is affected. In fact I would propose the design rule that when
moving/deleting a resource the resource should retain its type unless
explicit instructions to the contrary are given. That is, if you are a
direct reference at the source then you should be a direct reference at the
destination unless explicit instructions to the contrary are provided.
	The way to easily implement this rule is to give no-passthrough a
value and define the default for that value on a method by method basis.
PROPFIND and COPY, for example, would default to no-passthrough: f.
MOVE/DELETE would default to no-passthrough: t.
	The previous all applies to direct references. Redirect references
are obviously a different animal since one can only directly manipulate the
reference and never the target. Thus the only issue is - should a 302 ever
appear in a COPY/MOVE/DELETE response? Following the law of minimum surprise
an RFC 2518 client getting a 302 would be very surprised. They ordered that
all resources be copied, redirect references are resources, therefore they
should be copied. As such I propose that redirect references on
COPY/MOVE/DELETE always behavior as if no-passthrough equals t, regardless
of its actual value.

(Issue #10) Section 4.7.1 - Passthrough locks on direct references - I'm
thoroughly confused regarding why a passthrough lock doesn't lock both the
reference and the target. I read the spec a couple of times and I still
don't get it. For example, imagine an RFC 2518 client issued a lock on
http://foo/bar which is a direct reference to http://bar/blaz. To the RFC
2518 client it appears that they have locked http://foo/bar which will act
exactly as http://bar/blaz. This seems the much more reasonable behavior.
I'm sure there is a scenario here I'm missing but whatever it is, I wasn't
able to discern it from the spec. I apologize if the scenario is staring me
in the face and I am just failing to see it.

Section 4.7.3 - Returning reftype and reftarget on LOCKs of redirect
resources - The text says that a reftype and a reftarget element is returned
in the result but the actual result does not contain them. I'm not marking
this as an issue because I assume it is just a minor editorial glitch.

Section 4.7.4 - While there is a title for this section, there is no
example. I'm not marking this as an issue because I assume it is just a
minor editorial glitch.

(Issue #11) Section 4.7.5 - LOCK on a Collection that contains a direct
reference and a redirect reference - First off, the format is not backwards
compatible with RFC 2518 and thus will break existing RFC 2518 clients. Such
clients are expecting to get back a prop response, not a multistatus. They
will ignore the multistatus (since they won't recognize it in this context)
and thus "see" an empty response body.
	It would seem that returning reftype and reftarget information is
not necessary. A client can retrieve this information from a PROPFIND. This
is a similar argument to Issue #8. The best counter argument is that not
returning this information would cause reference enhanced clients to always
perform a PROPFIND after a LOCK. While this is not necessarily the end of
the world (LOCKs tend to be rare) it could still be bad. However, if we
adopt the behavior proposed in Issue #10 then there won't usually even be a
good reason to perform the PROPFIND. In addition, this behavior is
consistent with what an RFC 2518 client would expect.

I believe I have provided more than a sufficient number of issues to keep
the authors busy for some time and that providing even more would just
overload the authors. I look forward to returning to my review once these
concerns have been appropriately addressed.

			Yaron







From w3c-dist-auth-request@www10.w3.org  Mon Feb 22 10:09:42 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA04647
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Feb 1999 10:09:42 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA18583
	for <w3c-dist-auth@w3.org>; Mon, 22 Feb 1999 10:09:41 -0500 (EST)
Received: from appoint.net (mail.appoint.net [207.242.168.162])
	by phaisos.cube.com (8.8.5/8.8.5) with ESMTP id LAA10864
	for <w3c-dist-auth@w3.org>; Mon, 22 Feb 1999 11:10:25 -0500
Received: from appoint.net [209.218.166.130] by appoint.net with ESMTP
  (SMTPD32-5.00) id A3AB132800DE; Mon, 22 Feb 1999 10:11:39 EST
Sender: francis@phaisos.cube.com
Message-ID: <36D1737E.68EF5580@appoint.net>
Date: Mon, 22 Feb 1999 15:10:54 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <19990217232623.26062.rocketmail@web606.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Must PROPPATCH operation be atomic...

Imran Khan wrote:

> Can't I do "besteffort" vs. "atomic" in case of PROPPATCH? Because in
> my application scenario I am trying to replace the current protocol
> that allows besteffort as well as atomic flexibility.

If the client wants best-effort semantics, it can make multiple
requests.

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




From w3c-dist-auth-request@www10.w3.org  Mon Feb 22 16:28:42 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA12607
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Feb 1999 16:28:41 -0500 (EST)
Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA23254
	for <w3c-dist-auth@w3.org>; Mon, 22 Feb 1999 16:28:40 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id QAA22536;
	Mon, 22 Feb 1999 16:28:22 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <F35PH79T>; Mon, 22 Feb 1999 16:32:23 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D02@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@microsoft.com>,
        "'ejw@ics.uci.edu'"
	 <ejw@ics.uci.edu>,
        WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 22 Feb 1999 16:27:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Collections Protocol Review

Thanks for giving us these comments so quickly.  I'll take a stab at
responding here, and hope that others on the design team will add their two
cents.  I'll also add all of your issues to our issues list to make sure
they get addressed in the spec as well as in the mail.

--Judy

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Monday, February 22, 1999 1:36 AM
> To: 'ejw@ics.uci.edu'; WEBDAV WG
> Subject: Collections Protocol Review
> 
> 
> The following comments are based on
> http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-w
> ebdav-collecti
> on-protocol-03.txt:
> 
> (Issue #1) Section 2 - Definition of the term Collection - 
> What does the
> word "contains" mean in the definition of a collection? Does 
> this mean if I
> perform a GET I will get a list of them?

The term Collection is intended to mean exactly the same as in the WebDAV
specification.  I think I copied the definition from the WebDAV spec.  Since
WebDAV does not specify what the results of GET on a collection will be, I
would be more inclined to define "contains" in terms of which URIs will be
included in the response to a PROPFIND with Depth = 1 on the collection.

> 
> (Issue #2) Section 2- Definition of the term Referential Resource - It
> should be explicitly pointed out that this is a new resource 
> type. I think
> this would make the definition clearer.
> 	The term "body" as used in RFC 2068 and 2518 refer 
> exclusively to
> messages, not resources. Hence the phrase "body of its own" 
> does not have a
> definition in either spec.
> 	In general I find this definition confusing as it 
> indicates that a
> reference is a resource but has some relationship with a 
> target somehow
> involving properties. I think the problem is that the authors 
> have cleaved
> too tightly to the file system heritage of this feature. 
> First off, I think
> we need to cease viewing direct references and redirect references as
> children of the same mother. They are two very different 
> creatures with
> largely unrelated functionality. It would probably be in 
> everyone's interest
> if they were given names which shared no common words.
> 	A direct reference is really just an HTTP object which practices
> inheritances. Its sole purpose being to passthrough any 
> methods it receives
> to its target. Thus if a PROPFIND comes the direct reference 
> will simply
> pass it through to the target. This behavior can then be stopped by
> explicitly marking the request as being addressed to the 
> reference resource
> itself. Describing direct references as "passing through" 
> methods lets us
> avoid discussions of undefined terms like "body" and 
> discussions involving
> vague references to properties.
> 	A redirect reference is just a 3xx machine. It is a 
> resource which
> always returns 3xx to all requests which are not appropriate 
> marked as being
> direct at the reference. By describing redirect resources in 
> such concrete
> terms we avoid the maddening ambiguities inherent to the current
> specification.

I agree that the definition of "referential resource" is pretty lame, but I
do think it should be possible to come up with a definition of reference
that encompasses both direct and redirect references.  They really were
intended to be 2 different implementatons of the same basic capabilities:
one puts more burden on the client, the other puts more burden on the
server.  They both allow users to construct new collections that include
(loosely speaking) resources that really live someplace else, without making
a physical copy of the resource in the new collection.  How about:

a resource that provides access to the content and properties of another
resource
 
> Section 4.1 - I would like to congratulate the authors for 
> the section on
> why referential integrity is not supported. It is a very well written
> explanation.
 
Thanks.
 
> (Issue #3) Section 4.2 - Problems with the Location header 
> and redirect
> reference responses - I never liked the location header very 
> much because it
> only allows one to return a single URI. Thus if the target 
> resource has
> multiple names by which it is accessible one can only return 
> one of them.
> This isn't terribly robust. As such I would propose that this 
> specification
> provide an extension header to Location which allows for 
> additional URIs to
> be returned.

Good idea.  We just have to make sure that whatever we do doesn't confuse
down-level clients.  The whole point of implementing redirect references
using 302 with Location was that this would allow down-level clients to use
redirect references.
  
> (Issue #4) Section 4.3.1 - The Ref-Integrity header and its 
> support for the
> enforce value - If I send in an "enforce" value for 
> Ref-Integrity, can I
> delete a target which still has references? If I don't send in a
> Ref-Integrity header, can I be sure if I can delete a target 
> which still has
> references? As beautifully explained in the same spec, the 
> answer currently
> is "we don't know." This means that creating a reference without a
> Ref-Integrity header or with the value "enforce" is a blind 
> act. You have no
> idea what the results will be and this very clearly violates 
> the Hardie
> Rule.
> 	The naïve solution would be to just rip out the ref-integrity
> header, however the current language in the spec says that in 
> this case it
> is a gamble as to what one will get. Again, this violates the 
> Hardie Rule.
> 	As such I propose that the Ref-Integrity header MUST be 
> included in
> all requests and that the only defined value be 
> DAV:do-not-enforce. A server
> receiving this header with an unrecognized value MUST fail 
> the request. We
> do not act in the interests of interoperability by allowing 
> referential
> integrity when as this spec so elegantly argues, no one can 
> even define what
> this means. As such defining an "enforce" header does not help
> interoperability and so should not be in the spec. For now let various
> implements put out RFCs defining their particular 
> implementation along with
> a URL for the Ref-Integrity header that requires their particular
> implementation. Hopefully at some point in the future there will be
> convergence and a standardized URL can be specified.

The design team will need to revisit this issue.  I think we need to take
your argument into account.  However, the consequences of following your
suggestion might be worse than our current situation.

Since we are ruling referential integrity out of scope, it is true that
clients won't know at the time they create a reference whether or how its
integrity will be enforced.  This is bad.  But they can at least examine the
value of the DAV:refintegrity property once the reference has been created
in order to find out.  (Of course, since we are also not defining any
standard values for DAV:refintegrity except DAV:weak, the client is unlikely
to understand the value unless it has been designed to work with the
particular server.)

If we take your suggestion and require clients to specify a particular
integrity policy whenever they create a reference, but decline to define
additional values of Ref-Integrity, we prevent clients from creating
references at all unless they have some private agreement with the server
about values or unless servers do publish values of Ref-Integrity that they
use -- so clients would have to be designed to work with particular servers,
and we get no interoperability out of this spec.

It's not really likely that clients get to choose what policy a server would
use on a per-reference basis in any case.  The server has a policy that it
uses to enforce referential integrity.  It may allow clients to say
"do-not-enforce", but it won't allow clients to choose how to enforce.  So
it seems reasonable to have just 2 values "do-not-enforce" and "enforce".
Clients will find out how referential integrity is being enforced by trial
and error or by examining the value of DAV:refintegrity.

> 
> (Issue #5) Section 4.3.1 - Why DAV:reftarget, reftype and 
> refintegrity are
> stand alone properties - I do not understand why 
> DAV:reftarget, DAV:reftype
> and DAV:refintegrity are all defined as properties. As these 
> values help to
> define the nature of the resource type should they not have 
> their values
> included inside the DAV:reference element in the 
> DAV:resourcetype property?

It does seem more elegant to make them part of a reference element of
DAV:resourcetype.  A practical reason for not doing that is that DASL
doesn't (yet) support searches on structured properties and these seem like
properties we would want to be able to search on.  Actually, I see that we
need to revisit the values of these properties in any case, since they are
all structured at present.

> 
> (Issue #6) Section 4.3.1 - MKREF and the use of bodies - Why 
> doesn't MKREF
> follow the same rules that MKCOL has regarding the possible 
> inclusion of a
> body? They provide for the inclusion of a body but specify that if the
> content-type of the body is not understood then the request MUST be
> rejected. I believe the same rational that merited the 
> inclusion of this
> language in MKCOL's definition applies here.

I'm not sure what the rationale for allowing MKCOL to have a body was.  My
own view was that it could be used to populate the collection with members
in a single request when the collection was created.  There's nothing
analogous to that for references.

I'd be glad to see scenarios for how a message body for MKREF might be used.

> 
> (Issue #7) Section 4.4.1 - Do references to collections have 
> to provide
> references for all the members of the collection? - If one creates a
> reference to a collection is one also required to create 
> references to all
> the members of that collection? I suspect the answer is yes 
> but this is not
> clear from the specification. For example, the referential 
> resource in the
> example is http://www.svr.com/MyCollection/tuva/ and it points to a
> collection which has a member called history.html. Does this 
> mean that a GET
> on http://www.svr.com/MyCollection/tuva/history.html MUST 
> succeed? In other
> words, that by creating a reference to a collection one is required to
> create references to its entire tree? Again, I suspect the 
> answer is yes
> (this would explain the PROPFIND response format for direct 
> references as
> well as the COPY behavior for direct references) but this 
> requirement is
> never explicitly stated in the spec.

The way I've been thinking about this is that a reference is a resource.
When you create a reference to a collection you only create one new
resource.  You do not create a new referential resource for each member of
the target collection.  But the consequence of creating that one new
resource is that there is a new URI that can be used to access each member
of the target collection.  And yes, a GET on any member of that collection
through the new reference MUST succeed.

You can see us struggling with exactly this sort of example in Section 4.16.

> 
> (Issue #8) Section 4.5.5 - Requiring reftype and reftarget in 
> COPY responses
> - Why must one return the reftype and reftarget information for COPY
> requests? As this information is available from a PROPFIND on the
> destination requiring it to be supplied as part of the COPY 
> response seems
> redundant. Including this information also would most likely 
> break RFC 2518
> clients who would expect an empty body on a fully successful copy.

If you look at Appendix 2, you'll see that we're requiring Ref-Type to come
back in the response for any request made on a reference or through a
reference to its target.  And we're requiring Ref-Target to come back in the
response whenever the target is affected by the request.  The rationale was
that the client should be able to tell for any request what resource was
actually affected by the request.

But you are right that the client can always find this out by looking at
properties on the reference.  And incorporating this information in
responses to requests on collections is very messy -- LOCK is even worse
than COPY.  So we should probably revisit the issue of whether to require
any referencing headers to be included in responses, and make a consistent
decision across all cases, not just for the case of COPY on collections.

> 
> (Issue #9) Section 4.6 - Banning passthrough behavior on 
> DELETE and MOVE - I
> have a direct reference http://foo/bar to http://bar/blaz. I 
> can define a
> MOVE on http://foo/bar to http://icky/bik as meaning that 
> http://bar/blaz is
> to be moved to http://icky/bik. Following the logic discussed 
> in Issue #7 I
> can even properly define how to move any children that 
> http://bar/blaz might
> have. With DELETE I can define a DELETE of http://foo/bar as 
> meaning that
> http://bar/blaz should be deleted. So there doesn't seem to 
> be any technical
> reason to ban passthrough behavior on MOVE and DELETE involving direct
> references.
> 	I suspect the real reason that passthrough behavior is 
> disallowed on
> direct references is because of concerns regarding interactions with
> existing WebDAV clients. In most file systems that support 
> links if one
> deletes or moves a link, only the link is deleted or moved. I 
> suspect the
> authors are concerned that allowing passthrough on DELETE and 
> MOVE would
> mean that if an existing WebDAV client asks for a DELETE or 
> MOVE then the
> resource being pointed at would be deleted/moved as well, which wasn't
> something the non-reference enabled client would have 
> intended. As such I
> think it is completely reasonable to design the protocol such 
> that if a RFC
> 2518 client issues a DELETE or MOVE then only the direct 
> reference and not
> the target is affected. In fact I would propose the design 
> rule that when
> moving/deleting a resource the resource should retain its type unless
> explicit instructions to the contrary are given. That is, if you are a
> direct reference at the source then you should be a direct 
> reference at the
> destination unless explicit instructions to the contrary are provided.
> 	The way to easily implement this rule is to give 
> no-passthrough a
> value and define the default for that value on a method by 
> method basis.
> PROPFIND and COPY, for example, would default to no-passthrough: f.
> MOVE/DELETE would default to no-passthrough: t.
> 	The previous all applies to direct references. Redirect 
> references
> are obviously a different animal since one can only directly 
> manipulate the
> reference and never the target. Thus the only issue is - 
> should a 302 ever
> appear in a COPY/MOVE/DELETE response? Following the law of 
> minimum surprise
> an RFC 2518 client getting a 302 would be very surprised. 
> They ordered that
> all resources be copied, redirect references are resources, 
> therefore they
> should be copied. As such I propose that redirect references on
> COPY/MOVE/DELETE always behavior as if no-passthrough equals 
> t, regardless
> of its actual value.

We do think of the default behavior of most methods as No-Passthrough: f.
That is, if you want to operate on the reference rather than its target, you
have to use the No-Passthrough header to make that happen.  If you don't use
the No-Passthrough header, the operation will get applied to the target.

The exceptions are MOVE and DELETE, as you notice, and for redirect
references also COPY, LOCK, and UNLOCK.

The stated rationale for preventing MOVE and DELETE from ever getting passed
through to the target is this: When a reference is added to a collection,
the aim is to make it look as if the target resource were a member of that
collection.  When the reference is removed from that collection, the aim is
to change the membership of that collection.  Membership of the target in
any other collections, either internally or by reference, should not be
affected.  So MOVE and DELETE are different from other methods, which are
intended to affect the resource identified by the request-URI rather than
the collection to which it belongs.

I'm sure it was also in the back of people's minds that they would like to
keep behavior similar to file system behavior to make life easier for
servers based on file systems.

That said, we can certainly revisit the question whether to keep
No-Passthrough: t as the default for MOVE and DELETE, but allow them to be
passed through by saying No-Passthrough: f.

COPY, LOCK, and UNLOCK for redirect references are more complicated cases.
I think there is really no consensus within the design team on how we think
COPY should behave for redirect references.  For LOCK (and therefore for
UNLOCK) on redirect references, we didn't want to allow No-Passthrough: f
because this would result in 302 responses, and so in the case of
collections that contain redirect references would cause the entire LOCK to
fail.

> 
> (Issue #10) Section 4.7.1 - Passthrough locks on direct 
> references - I'm
> thoroughly confused regarding why a passthrough lock doesn't 
> lock both the
> reference and the target. I read the spec a couple of times 
> and I still
> don't get it. For example, imagine an RFC 2518 client issued a lock on
> http://foo/bar which is a direct reference to
> http://bar/blaz. To the RFC 2518 client it appears that they have 
> locked http://foo/bar which will act exactly as http://bar/blaz. This
seems > the much more reasonable behavior.
> I'm sure there is a scenario here I'm missing but whatever it is, I wasn't
> able to discern it from the spec. I apologize if the scenario is staring
me
> in the face and I am just failing to see it.

At least one member of the design team agrees with you.  We all agreed that
the most intuitive behavior when LOCKing a reference would be for both the
reference and its target to get locked.  So that would argue for making it
the default behavior, at least for direct references.

However, we are balancing intuitive behavior against various consistency
considerations, and in this case consistency with the way other methods
behave for direct references won out.  The default behavior for most methods
on direct references is to pass the request on to the target, so we decided
to do the same for LOCK.  This at least prevents non-lock-holders from
modifying the target, while there is still a risk that someone might delete
or replace the reference while the lock was in place.  We do point out that
if reference-aware clients are good citizens and check whether the target is
locked before mucking around with a reference, all will be well.

> Section 4.7.3 - Returning reftype and reftarget on LOCKs of redirect
> resources - The text says that a reftype and a reftarget element is 
> returned
> in the result but the actual result does not contain them. I'm not marking
> this as an issue because I assume it is just a minor editorial glitch.

Right.  Good catch.

> Section 4.7.4 - While there is a title for this section, there is no
> example. I'm not marking this as an issue because I assume it is just a
> minor editorial glitch.

Right.  I ran out of time.

> (Issue #11) Section 4.7.5 - LOCK on a Collection that contains a direct
> reference and a redirect reference - First off, the format is not
backwards
> compatible with RFC 2518 and thus will break existing RFC 2518 clients. 
> Such
> clients are expecting to get back a prop response, not a multistatus. They
> will ignore the multistatus (since they won't recognize it in this
context)
> and thus "see" an empty response body.
> 	It would seem that returning reftype and reftarget information is
> not necessary. A client can retrieve this information from a PROPFIND.
This
> is a similar argument to Issue #8. The best counter argument is that not
> returning this information would cause reference enhanced clients to
always
> perform a PROPFIND after a LOCK. While this is not necessarily the end of
> the world (LOCKs tend to be rare) it could still be bad. However, if we
> adopt the behavior proposed in Issue #10 then there won't usually even be
a
> good reason to perform the PROPFIND. In addition, this behavior is
> consistent with what an RFC 2518 client would expect.

We definitely don't want to break existing clients, so let's see where we
end up once we resolve issues 8 and 10.

Thanks again for (as always) prompt and insightful comments.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580







From w3c-dist-auth-request@www10.w3.org  Mon Feb 22 18:07:31 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13581
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Feb 1999 18:07:30 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA24093
	for <w3c-dist-auth@w3.org>; Mon, 22 Feb 1999 18:07:29 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FLHRWM6A>; Mon, 22 Feb 1999 15:07:28 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F59@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "'ejw@ics.uci.edu'"
	 <ejw@ics.uci.edu>,
        WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 22 Feb 1999 15:07:25 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Collections Protocol Review

These are only my initial comments and only cover the first twenty pages or
so of the spec. They also only identify what I consider to be significant
issues. Having found a sufficient number of them I decided to not provide
the entire shopping list of minor issues.

I apologize for not being able to provide additional comments on the rest of
the paper but I am completely swamped at work and have to do this review on
my single free day (I'm currently working six days a week). I hope to be
freed up sometime in April after the WinHEC conference.

See comments below.

			Yaron


> The term Collection is intended to mean exactly the same as 
> in the WebDAV
> specification.  I think I copied the definition from the 
> WebDAV spec.  Since
> WebDAV does not specify what the results of GET on a 
> collection will be, I
> would be more inclined to define "contains" in terms of which 
> URIs will be
> included in the response to a PROPFIND with Depth = 1 on the 
> collection.
> 

I know what you meant, it just wasn't what the spec says.

> I agree that the definition of "referential resource" is 
> pretty lame, but I
> do think it should be possible to come up with a definition 
> of reference
> that encompasses both direct and redirect references.  They 
> really were
> intended to be 2 different implementatons of the same basic 
> capabilities:
> one puts more burden on the client, the other puts more burden on the
> server.  They both allow users to construct new collections 
> that include
> (loosely speaking) resources that really live someplace else, 
> without making
> a physical copy of the resource in the new collection.  How about:
> 
> a resource that provides access to the content and properties 
> of another
> resource
>  

The purpose of a spec is to help implementers and we should choose
definitions that aid in that cause. Redirect references are based on 3xx and
should be defined as such. This makes the situation extremely clear to
anyone writing code.

> Good idea.  We just have to make sure that whatever we do 
> doesn't confuse
> down-level clients.  The whole point of implementing redirect 
> references
> using 302 with Location was that this would allow down-level 
> clients to use
> redirect references.

Each enough. Continue to use Location and define an addition header
LocationEx (a nod to my MS roots =). The definition is "First use Location
and if that doesn't work then try the list of URIs in LocationEx." 100%
compatible with existing systems and better functionality for advanced
collection enhanced clients.


> The design team will need to revisit this issue.  I think we 
> need to take
> your argument into account.  However, the consequences of 
> following your
> suggestion might be worse than our current situation.
> 

The current situation is that this spec provides a definition whereby one
has absolutely no idea what will happen as a result of executing a request.
As a clear violation of the Hardie Rule this means you are not providing an
interoperable solution. In other words, things can't possibly get worse.
Uglier, perhaps, but not worse.

> Since we are ruling referential integrity out of scope, it is 
> true that
> clients won't know at the time they create a reference 
> whether or how its
> integrity will be enforced.  This is bad.  But they can at 
> least examine the
> value of the DAV:refintegrity property once the reference has 
> been created
> in order to find out.  (Of course, since we are also not defining any
> standard values for DAV:refintegrity except DAV:weak, the 
> client is unlikely
> to understand the value unless it has been designed to work with the
> particular server.)
> 

Given the ramifications of integrity enforcement as so well explained by
your own paper any situation where a client does not know if a reference
will be integrity enforced and thus has absolutely no idea what the final
behavior will be is, by definition, non-interoperable and thus unacceptable.
Your only options are to either define referential integrity (a hopeless
task) or to specify that the current spec will only allow for the creation
of unenforced references and that later specs can add different types of
referential integrity.

> If we take your suggestion and require clients to specify a particular
> integrity policy whenever they create a reference, but 
> decline to define
> additional values of Ref-Integrity, we prevent clients from creating
> references at all unless they have some private agreement 
> with the server
> about values or unless servers do publish values of 
> Ref-Integrity that they
> use -- so clients would have to be designed to work with 
> particular servers,
> and we get no interoperability out of this spec.
> 

The ONLY interoperability you can get without defining referential integrity
is to provide the do-not-enforce value. That is it. You can not do better.
As your own spec clearly illustrates, allowing for referential integrity
without defining it means non-interoperability by definition!

> It's not really likely that clients get to choose what policy 
> a server would
> use on a per-reference basis in any case.  The server has a 
> policy that it
> uses to enforce referential integrity.  It may allow clients to say
> "do-not-enforce", but it won't allow clients to choose how to 
> enforce.  So
> it seems reasonable to have just 2 values "do-not-enforce" 
> and "enforce".
> Clients will find out how referential integrity is being 
> enforced by trial
> and error or by examining the value of DAV:refintegrity.
> 

This sounds like the old COPY arguments that lead to the definition of the
Hardie rule. You are not helping interoperability when a method can have any
number of completely unknown ramifications. Even discovering that your link
is "enforced" tells you nothing as you know nothing about the type of
enforcement policy being used.
Systems which can not support non-enforced references will be forced to
publish their own schemes and will only work with clients which support
those schemes. Hopefully this will lead implementers to be willing to make
sufficient tradeoffs that a common scheme can be created. But until then
simply saying "your mileage may vary" on the fundamental ramifications of a
command is a non-starter.

> > 
> > (Issue #5) Section 4.3.1 - Why DAV:reftarget, reftype and 
> > refintegrity are
> > stand alone properties - I do not understand why 
> > DAV:reftarget, DAV:reftype
> > and DAV:refintegrity are all defined as properties. As these 
> > values help to
> > define the nature of the resource type should they not have 
> > their values
> > included inside the DAV:reference element in the 
> > DAV:resourcetype property?
> 
> It does seem more elegant to make them part of a reference element of
> DAV:resourcetype.  A practical reason for not doing that is that DASL
> doesn't (yet) support searches on structured properties and 
> these seem like
> properties we would want to be able to search on.  Actually, 
> I see that we
> need to revisit the values of these properties in any case, 
> since they are
> all structured at present.
> 

The design rational for including these values in resourcetype are clear and
should be followed. If DASL can not support WebDAV then it has violated its
charter and needs to be changed.

> > 
> > (Issue #6) Section 4.3.1 - MKREF and the use of bodies - Why 
> > doesn't MKREF
> > follow the same rules that MKCOL has regarding the possible 
> > inclusion of a
> > body? They provide for the inclusion of a body but specify 
> that if the
> > content-type of the body is not understood then the request MUST be
> > rejected. I believe the same rational that merited the 
> > inclusion of this
> > language in MKCOL's definition applies here.
> 
> I'm not sure what the rationale for allowing MKCOL to have a 
> body was.  My
> own view was that it could be used to populate the collection 
> with members
> in a single request when the collection was created.  There's nothing
> analogous to that for references.
> 
> I'd be glad to see scenarios for how a message body for MKREF 
> might be used.
> 

One of the most important rules in HTTP is to never ban anything unless you
have a damn good reason because it will always come back to bite you. Just
because you can't think of a reason to include a body does not mean that
someone far smarter than both of us will come forward some day and come up
with a good reason. The impetus is upon the authors to argue why banning a
body is such a critical requirement that it is worth cutting off this
direction of extensibility.

> > 
> > (Issue #7) Section 4.4.1 - Do references to collections have 
> > to provide
> > references for all the members of the collection? - If one creates a
> > reference to a collection is one also required to create 
> > references to all
> > the members of that collection? I suspect the answer is yes 
> > but this is not
> > clear from the specification. For example, the referential 
> > resource in the
> > example is http://www.svr.com/MyCollection/tuva/ and it points to a
> > collection which has a member called history.html. Does this 
> > mean that a GET
> > on http://www.svr.com/MyCollection/tuva/history.html MUST 
> > succeed? In other
> > words, that by creating a reference to a collection one is 
> required to
> > create references to its entire tree? Again, I suspect the 
> > answer is yes
> > (this would explain the PROPFIND response format for direct 
> > references as
> > well as the COPY behavior for direct references) but this 
> > requirement is
> > never explicitly stated in the spec.
> 
> The way I've been thinking about this is that a reference is 
> a resource.
> When you create a reference to a collection you only create one new
> resource.  You do not create a new referential resource for 
> each member of
> the target collection.  But the consequence of creating that one new
> resource is that there is a new URI that can be used to 
> access each member
> of the target collection.  And yes, a GET on any member of 
> that collection
> through the new reference MUST succeed.
> 

HTTP defines that there are HTTP URLs and that HTTP URLs point to resource.
If creating a reference called http://foo/bar that points to a collection
with a member baz and thus I can perform a GET on http://foo/bar/baz, even
though the MKREF only created http://foo/bar, then there exists a resource
called http://foo/bar/baz and it is a reference. Thus the only possible
conclusion is that creating a reference to a collection causes references to
be created to all the members of that reference's entire tree. Otherwise
http://foo/bar/baz would fail.

> You can see us struggling with exactly this sort of example 
> in Section 4.16.
> 

Indeed, lack of sufficient clarity on this issue causes ramifications
throughout the entire specification.

> > 
> > (Issue #8) Section 4.5.5 - Requiring reftype and reftarget in 
> > COPY responses
> > - Why must one return the reftype and reftarget information for COPY
> > requests? As this information is available from a PROPFIND on the
> > destination requiring it to be supplied as part of the COPY 
> > response seems
> > redundant. Including this information also would most likely 
> > break RFC 2518
> > clients who would expect an empty body on a fully successful copy.
> 
> If you look at Appendix 2, you'll see that we're requiring 
> Ref-Type to come
> back in the response for any request made on a reference or through a
> reference to its target.  And we're requiring Ref-Target to 
> come back in the
> response whenever the target is affected by the request.  The 
> rationale was
> that the client should be able to tell for any request what 
> resource was
> actually affected by the request.
> 
> But you are right that the client can always find this out by 
> looking at
> properties on the reference.  And incorporating this information in
> responses to requests on collections is very messy -- LOCK is 
> even worse
> than COPY.  So we should probably revisit the issue of 
> whether to require
> any referencing headers to be included in responses, and make 
> a consistent
> decision across all cases, not just for the case of COPY on 
> collections.
> 

I understand why you wanted to do this but given that there are alternative
means and that your current proposal may or may not work with RFC 2518
clients it would seem reasonable to exclude the data.

> > 
> > (Issue #9) Section 4.6 - Banning passthrough behavior on 
> > DELETE and MOVE - I
> > have a direct reference http://foo/bar to http://bar/blaz. I 
> > can define a
> > MOVE on http://foo/bar to http://icky/bik as meaning that 
> > http://bar/blaz is
> > to be moved to http://icky/bik. Following the logic discussed 
> > in Issue #7 I
> > can even properly define how to move any children that 
> > http://bar/blaz might
> > have. With DELETE I can define a DELETE of http://foo/bar as 
> > meaning that
> > http://bar/blaz should be deleted. So there doesn't seem to 
> > be any technical
> > reason to ban passthrough behavior on MOVE and DELETE 
> involving direct
> > references.
> > 	I suspect the real reason that passthrough behavior is 
> > disallowed on
> > direct references is because of concerns regarding interactions with
> > existing WebDAV clients. In most file systems that support 
> > links if one
> > deletes or moves a link, only the link is deleted or moved. I 
> > suspect the
> > authors are concerned that allowing passthrough on DELETE and 
> > MOVE would
> > mean that if an existing WebDAV client asks for a DELETE or 
> > MOVE then the
> > resource being pointed at would be deleted/moved as well, 
> which wasn't
> > something the non-reference enabled client would have 
> > intended. As such I
> > think it is completely reasonable to design the protocol such 
> > that if a RFC
> > 2518 client issues a DELETE or MOVE then only the direct 
> > reference and not
> > the target is affected. In fact I would propose the design 
> > rule that when
> > moving/deleting a resource the resource should retain its 
> type unless
> > explicit instructions to the contrary are given. That is, 
> if you are a
> > direct reference at the source then you should be a direct 
> > reference at the
> > destination unless explicit instructions to the contrary 
> are provided.
> > 	The way to easily implement this rule is to give 
> > no-passthrough a
> > value and define the default for that value on a method by 
> > method basis.
> > PROPFIND and COPY, for example, would default to no-passthrough: f.
> > MOVE/DELETE would default to no-passthrough: t.
> > 	The previous all applies to direct references. Redirect 
> > references
> > are obviously a different animal since one can only directly 
> > manipulate the
> > reference and never the target. Thus the only issue is - 
> > should a 302 ever
> > appear in a COPY/MOVE/DELETE response? Following the law of 
> > minimum surprise
> > an RFC 2518 client getting a 302 would be very surprised. 
> > They ordered that
> > all resources be copied, redirect references are resources, 
> > therefore they
> > should be copied. As such I propose that redirect references on
> > COPY/MOVE/DELETE always behavior as if no-passthrough equals 
> > t, regardless
> > of its actual value.
> 
> We do think of the default behavior of most methods as 
> No-Passthrough: f.
> That is, if you want to operate on the reference rather than 
> its target, you
> have to use the No-Passthrough header to make that happen.  
> If you don't use
> the No-Passthrough header, the operation will get applied to 
> the target.
> 
> The exceptions are MOVE and DELETE, as you notice, and for redirect
> references also COPY, LOCK, and UNLOCK.
> 
> The stated rationale for preventing MOVE and DELETE from ever 
> getting passed
> through to the target is this: When a reference is added to a 
> collection,
> the aim is to make it look as if the target resource were a 
> member of that
> collection.  When the reference is removed from that 
> collection, the aim is
> to change the membership of that collection.  Membership of 
> the target in
> any other collections, either internally or by reference, 
> should not be
> affected.  So MOVE and DELETE are different from other 
> methods, which are
> intended to affect the resource identified by the request-URI 
> rather than
> the collection to which it belongs.
> 

I still fail to see why you are banning perfectly reasonable functionality
when there does not appear to be any technical or protocol related reason
for doing so. As my comments demonstrate it is completely possible to use
DELETE and MOVE to effect the targets and to do so in a manner which causes
the expected behavior with RFC 2518 clients. As such what possible reason
can there be for banning this logical and well defined behavior? Just
because it doesn't fit your conceptual model? This would argue for changing
your model not banning this functionality. Again, I call upon the general
HTTP rule "allow unless you have a damn good reason for not doing so."

> I'm sure it was also in the back of people's minds that they 
> would like to
> keep behavior similar to file system behavior to make life easier for
> servers based on file systems.
> 
> That said, we can certainly revisit the question whether to keep
> No-Passthrough: t as the default for MOVE and DELETE, but 
> allow them to be
> passed through by saying No-Passthrough: f.
> 
> COPY, LOCK, and UNLOCK for redirect references are more 
> complicated cases.
> I think there is really no consensus within the design team 
> on how we think
> COPY should behave for redirect references.  For LOCK (and 
> therefore for
> UNLOCK) on redirect references, we didn't want to allow 
> No-Passthrough: f
> because this would result in 302 responses, and so in the case of
> collections that contain redirect references would cause the 
> entire LOCK to
> fail.
> 
> > 
> > (Issue #10) Section 4.7.1 - Passthrough locks on direct 
> > references - I'm
> > thoroughly confused regarding why a passthrough lock doesn't 
> > lock both the
> > reference and the target. I read the spec a couple of times 
> > and I still
> > don't get it. For example, imagine an RFC 2518 client 
> issued a lock on
> > http://foo/bar which is a direct reference to
> > http://bar/blaz. To the RFC 2518 client it appears that they have 
> > locked http://foo/bar which will act exactly as 
> http://bar/blaz. This
> seems > the much more reasonable behavior.
> > I'm sure there is a scenario here I'm missing but whatever 
> it is, I wasn't
> > able to discern it from the spec. I apologize if the 
> scenario is staring
> me
> > in the face and I am just failing to see it.
> 
> At least one member of the design team agrees with you.  We 
> all agreed that
> the most intuitive behavior when LOCKing a reference would be 
> for both the
> reference and its target to get locked.  So that would argue 
> for making it
> the default behavior, at least for direct references.
> 
> However, we are balancing intuitive behavior against various 
> consistency
> considerations, and in this case consistency with the way 
> other methods
> behave for direct references won out.  The default behavior 
> for most methods
> on direct references is to pass the request on to the target, 
> so we decided
> to do the same for LOCK.  This at least prevents non-lock-holders from
> modifying the target, while there is still a risk that 
> someone might delete
> or replace the reference while the lock was in place.  We do 
> point out that
> if reference-aware clients are good citizens and check 
> whether the target is
> locked before mucking around with a reference, all will be well.
> 

The current situation is, in my opinion, a clear violation of RFC 2518. RFC
2518 is crystal clear that locking a resource means that the resource is
locked. Your current definition does not do this. In fact someone locking a
direct reference, which actually locks the target, could end up with the
reference changed underneath them, thus leading to the violation. Whatever
solution you choose the reference MUST be locked or this specification is in
violation of RFC 2518 and must therefore choose a new method name rather
than LOCK.

Personally I think you should just accept that LOCKing references can be a
bit wacky and will result in locking both the reference and the target.

> > Section 4.7.3 - Returning reftype and reftarget on LOCKs of redirect
> > resources - The text says that a reftype and a reftarget element is 
> > returned
> > in the result but the actual result does not contain them. 
> I'm not marking
> > this as an issue because I assume it is just a minor 
> editorial glitch.
> 
> Right.  Good catch.
> 
> > Section 4.7.4 - While there is a title for this section, there is no
> > example. I'm not marking this as an issue because I assume 
> it is just a
> > minor editorial glitch.
> 
> Right.  I ran out of time.
> 
> > (Issue #11) Section 4.7.5 - LOCK on a Collection that 
> contains a direct
> > reference and a redirect reference - First off, the format is not
> backwards
> > compatible with RFC 2518 and thus will break existing RFC 
> 2518 clients. 
> > Such
> > clients are expecting to get back a prop response, not a 
> multistatus. They
> > will ignore the multistatus (since they won't recognize it in this
> context)
> > and thus "see" an empty response body.
> > 	It would seem that returning reftype and reftarget 
> information is
> > not necessary. A client can retrieve this information from 
> a PROPFIND.
> This
> > is a similar argument to Issue #8. The best counter 
> argument is that not
> > returning this information would cause reference enhanced clients to
> always
> > perform a PROPFIND after a LOCK. While this is not 
> necessarily the end of
> > the world (LOCKs tend to be rare) it could still be bad. 
> However, if we
> > adopt the behavior proposed in Issue #10 then there won't 
> usually even be
> a
> > good reason to perform the PROPFIND. In addition, this behavior is
> > consistent with what an RFC 2518 client would expect.
> 
> We definitely don't want to break existing clients, so let's 
> see where we
> end up once we resolve issues 8 and 10.
> 
> Thanks again for (as always) prompt and insightful comments.
> 
> --Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 
> 
> 
> 
> 
> 


From w3c-dist-auth-request@www10.w3.org  Tue Feb 23 11:44:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA26110
	for <w3c-dist-auth@www19.w3.org>; Tue, 23 Feb 1999 11:44:52 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA03138
	for <w3c-dist-auth@w3.org>; Tue, 23 Feb 1999 11:44:51 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id LAA11757;
	Tue, 23 Feb 1999 11:43:34 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <F37937SR>; Tue, 23 Feb 1999 11:47:45 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D04@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Bruce Cragun'" <BCragun.ORM2-1.OREM2@GW.Novell.com>, jamsden@us.ibm.com
Cc: w3c-dist-auth@w3.org,
        "Falkenhainer, Brian"
	 <Brian.Falkenhainer@usa.xerox.com>,
        "Garnaat, Mitchell"
	 <MGarnaat@crt.xerox.com>
Date: Tue, 23 Feb 1999 11:47:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Version issues

I'd like to weigh in with Bruce for keeping Level 1 as simple as possible.
Xerox has several products that do linear versioning only, and versioning of
individual resources only, and have no use for workspaces that I can see.
The client always gets the tip revision unless it requests a particular
revision by id.  (There's no notion of a label that a client could assign.)
We'd like them to use WebDAV versioning, but it will be a hard sell if Level
1 forces them to implement a lot of stuff that they don't really need.

-----------

I'd like to describe the model used by one of these products, because it has
several features that may break your view of how version management works:

The user can decide, when creating a document, whether it is versioned or
not.

Assuming that the user specifies that a given document is versioned:

Only simple linear versioning is supported.  Only individual documents can
be versioned.

Revisions are immutable.  That is, once a revision is created, it cannot be
modified.

The server assigns identifiers to revisions, and has the notion of the tip
revision.  Clients cannot assign labels to revisions.

There is no checkout operation.  There is only a "new revision" operation on
the document (on the version series), which results in a new revision being
created at the tip of the series, with the content submitted with the
request; if the document was locked, only the lock owner can do a "new
revision", and the "new revision" operation also unlocks it.

The user can specify how many revisions are to be saved.  This number can be
changed at any time.  Once that number of revisions exist, when a new
revision is created, one is thrown away from the beginning of the list.
There is no trace left of any revision that has been thrown away in this
way.  Version history information is saved only for the most recent n
revisions, where n is the number of revisions the user asked to have saved.

Only one report can be generated.  It contains the revision id, revision
date, user who created the revision, and comments for each revision of the
document.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: Bruce Cragun [mailto:BCragun.ORM2-1.OREM2@GW.Novell.com]
> Sent: Wednesday, February 17, 1999 7:13 PM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: RE: Version issues
> 
> 
> Okay, I see our disconnect.  You are assuming that, even in 
> Level 1, we
> want some method of creating / identifying a logical *set* of 
> resources,
> such as all revisions that made up a particular milestone or release. 
> In the DMS world there is no such grouping ability; every 
> file is on its
> own.  In the web site arena, however, I can see some value in this
> grouping concept.
> 
> A simple versioning client and/or server, I believe, will not 
> generally
> implement workspaces if given a choice.  If that is true, then I would
> vote to leave workspaces in Level 2.  If with my particular product I
> want only basic versioning, but the ability to create sets 
> (workspaces)
> is important, then I can implement Level 1 versioning and add 
> workspaces
> without the rest of Level 2.  Now my client and my server can take
> advantage of the ability to use workspaces, but other peoples' Level 1
> clients can still make use of my server.  Workspaces are a useful
> "utility" not a required piece of functionality.
> 
> So I vote workspaces remain in Level 2.
> 
> >>> <jamsden@us.ibm.com> 02/17/99 01:44PM >>>
> 
> 
> Bruce,
> I'm sorry to hear you weren't feeling well, but welcome back!
> 
> No, you're getting it just fine. For your item 1 below, the default
> workspace does just what you want. You never even need to know its
> there.
> Recall the default workspace has a revision selection rule containing
> checkedout and latest.
> 
> For item 2, the model currently allows access through a specific
> revision
> name which temporarily overrides the workspace, so this can be done
> too.
> 
> If this was all you wanted, then probably workspaces for level 1 would
> be
> overkill. But, lets look at some other simple scenarios and see what
> would
> happen.
> 
> Say a development organization finishes work on  a milestone and wants
> some
> way to refer to the proper revisions. When work continues, these
> revisions
> won't necessarily be the latest revision because the resources may
> have
> changed in some appropriate way. Configurations solve this in level 2,
> but
> a common scenario for level 1 might be to come up with a label for the
> release and use this label on every revision that participates.
> 
> So now every time you want to get the R1 revision for any of these
> resources, you have to remember the revision name and provide it on
> each
> access. That's not so bad though, and is the same thing as remembering
> a
> workspace that has checkedout, R1, and latest in its revision
> selection
> rule. So far this is a wash.
> 
> Now say there's an R2 of the project as a whole. Some of the resources
> changed and some of them didn't. You could label all the participant
> revisions with R2 and that would work. But, after a while specific
> revisions might have a lot of labels on them making the revision
> history of
> many resource hard to manage. In addition users have to remember
> something
> new, use label R2 instead of R1. An alternative is to just label the
> ones
> that changed with R2 and put checkedout, R2, R1, and latest in the
> revision
> selection rule. Then you'll get the right versions without remembering
> R1,
> R2, ..., you only have to remember the same workspace you were using
> before
> the revisions changed. All users get updated just by updating their
> workspace. The default workspace revision selection rule can 
> be changed
> to
> so that clients that can't or don't specify a revision will get the
> right
> revisions too. You could do this with default labels, but it 
> would take
> a
> lot more work to update a property on every resource resetting its
> default
> when you can just add a single entry to a revision selection rule.
> 
> Workspaces just provide flexibility and ease of use for level 1, not
> any
> new functionality. I think they make the clients simpler and simplify
> the
> user's interaction with the server. So they are useful for level 1
> even
> though there aren't any activities or configurations.
> 
> 
> 
> 
> 
> 
> "Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/17/99
> 03:10:40 PM
> 
> To:   ckaler@microsoft.com, Jim Amsden/Raleigh/IBM
> cc:   ietf-dav-versioning@w3.org 
> Subject:  RE: Version issues
> 
> 
> 
> 
> It isn't that workspaces provide unneeded functionality for Level 1.
> It's just an abstraction that a) isn't in simple versioning models
> now,
> so would require learning and understanding, and b) isn't necessary.
> 
> The way I envision it for a Level 1 implementation is this:
> 
> 1. If I request a resource and specify nothing other than "get me this
> resource" the default is to give me the latest.  Without branching and
> other Level 2 features, this is trivial.  With Level 2
> implementations,
> this is interpreted as the latest on the main line.
> 
> 2. If I want something other than the latest, I include a Revision Id
> or a Label.  This works fine for both levels, without any complexity
> whatsoever.
> 
> Am I just not getting it?
> 
> >>> <jamsden@us.ibm.com> 02/17/99 11:20AM >>>
> 
> 
> Comments below in <jra> tags.
> 
> 
> 
> 
> 
> Chris Kaler <ckaler@microsoft.com> on 02/17/99 12:13:42 PM
> 
> To:   Jim Amsden/Raleigh/IBM
> cc:
> Subject:  RE: Version issues
> 
> 
> 
> 
> I don't think level 1 servers want to deal with revision selection
> rules.
> I
> suspect they could be complicated.  As well, we need to understand the
> semantics of parallel checkouts in the "default workspace".  The
> current
> definition of a workspaces prohibits this and I think it is an
> important
> requirement for level 1.
> 
> <jra>
> Level 1 revision selection rules don't need to be complicated at all.
> There
> are no activities or configurations, so the revision selection rule
> has
> checkedout and 0 or more labels. When a resource is accessed with a
> simple
> URL, this means, get the checked out revision if any, otherwise look
> for a
> revision that has a matchin label. It's hard to imagine anything
> simpler.
> </jra>
> 
> Geoff and I started talking about the Revision-Id header yesterday.  I
> think
> it is reasonable for a client to request version X of /foo/bar.htm.
> It
> seems a cumbersome requirement to have to set the revision of
> /foo/bar.htm
> in the default workspace to be X and get /foo/bar.htm.  As well, this
> won't
> scale at all.  Imagine one person trying to get version X and one
> trying to
> get version Y.  We clearly need more discussion on this, but I don't
> yet
> see
> how we can eliminate a header that specifies a revision.  I do believe
> that
> we could condense several headers into one...
> 
> <jra>
> I also belive that users want to access specific revisions given the
> label.
> If they can assign a label, they should be able to access the resource
> that
> they assigned the label to. Recall that this capability is in the
> model. In
> the new version I moved the method to Repository.getResource(url :
> String,
> label : String = null) : Resource. There's also
> Repository.getResource(url
> : String, context Workspace) : Resource to access a resource in the
> context
> of a workspace. One reason you would want to do this is if you want to
> look
> at an old version, or compare two revisions, and don't want to change
> your
> workspace.
> 
> My issue isn't that I didn't want access by labels, only that access
> when
> labels aren't specified should use Workspaces to resolve the URL.
> </jra>
> 
> I, personally, think that RSR are interesting but probably too
> complicated
> for level 1 servers.  We could say that the SETDEFAULT method is a
> "utility"
> method that modifies the workspace to use the specified revision of
> the
> specified resource.  This allows us to still describe level 1
> functionality
> in the context of level 2 workspaces.  And for level 2, it provides a
> handy
> service for augmenting an RSR without having to pull it, modify it,
> and
> put
> it.
> 
> <jra>
> Again, I don't think revision selection rules are complicate at all,
> especially for level 1 which doesn't have activities, merging, or
> configurations. The complexity results from introducing multiple
> revisions.
> Leaving workspaces out of level 1 will just move the complexity to the
> client or user who have to remember lots of labels on a resource by
> resource basis. This makes the server simpler, but not WebDAV.
> 
> I stress again, what would anyone want to do with versioning level 1
> that
> workspaces wouldn't support? What would workspaces include that would
> be
> considered too much for level 1? We need specific scenarios that
> address
> these issues. As you know, I am also keen to keep things simple. Its
> just I
> want the simplicity for the users and clients, not necessarily just
> for
> the
> server.
> </jra>
> 
> Thoughts?
> 
> Chris
> 
> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] 
> Sent: Tuesday, February 16, 1999 12:56 PM
> To: Chris Kaler
> Subject: RE: Version issues
> 
> 
> 
> 
> But if we keep the Revision-Id header and a SETDEFAULT method, this
> will
> conflict with level using a default workspace. I suggest we
> effectively
> use
> default workspaces for level 1. This doesn't mean servers have to
> implement
> them, only do something that makes them look like they work. Clients
> should
> be able to use level 1 services without being aware of workspaces. If
> activities and configurations are not in level 1, then the workspace
> only
> has to consider revision selection rules that include checkedout,
> latest,
> and revision labels. This should be pretty simple.
> 
> 
> 
> 
> 
> 
> Chris Kaler <ckaler@microsoft.com> on 02/16/99 03:21:30 PM
> 
> To:   Jim Amsden/Raleigh/IBM, ietf-dav-versioning@w3.org 
> cc:
> Subject:  RE: Version issues
> 
> 
> 
> 
> 
> [CK] Comments below...
> 
> A few issues came up at our last versioning working group meeting:
> 
> 1. DAV versioning level 1 will still need to be a way of resolving
> access
> to versioned resources given just a URL (and not a label). If
> workspaces
> aren't supported, level 1 servers will have to provide some other way
> to
> resolve URLs to specific revisions, perhaps a default revision for
> each
> versioned resource. For level 2 servers that do support workspaces,
> this
> would result in two, potentially conflicting ways of performing URL
> mapping. This is a strong argument for including workspaces in level
> 1.
> What would anyone want to do with versioning level 1 that workspaces
> wouldn't support? What would workspaces include that would be
> considered
> too much for level 1? If there are no compelling answers to these
> questions, we should include workspaces in level 1, including the
> default
> workspace.
> 
> [CK] I suggest we keep the Revision-Id header and the SETDEFAULT
> method.
> 
> 2. Deleting a resource must explicitly state that the resource is
> removed
> from its parent collection; that is, the collection with which the
> resource
> is an internal member. Versioning complicates delete semantics. There
> are
> three things we might want to delete: an unversioned or working
> resource, a
> revision (and all its descendents?) of a versioned resource, a
> versioned
> resource and all its revision history. This must be done in the
> context
> of
> versioned and unversioned collections that contain the resource, or
> versioned resource as an internal member. The preferred way to do this
> would be to have add and remove methods on collections to create and
> delete
> resources as its the collection that controls the namespace.
> Unfortunately,
> DAV doesn't have those semantics, so we will have to find a
> work-around
> for
> versioning.
> 
> [CK] I expect deleting a working resource to be the same as
> UNCHECKOUT.
> [CK] Deleting a versioned resource is up to the store.  Some stores
> might
> [CK] just delete it.  Some might create an "delete" version.  I don't
> think
> [CK] we want to push a specific model on people.  Especially since the
> [CK] DELETE method is about a resource and in no way describes the
> [CK] underlying repository actions.
> 
> Actually, the current WebDAV spec is a little confusing about
> collections
> and their members. The current spec indicates collections contain
> URLs,
> not
> resources. But, there is the notion of internal members and
> referential
> members, and deleting a collection deletes all its internal members.
> So
> the
> collection behaves like it contains resources, not URLs. This issue
> will
> likely get more confusing when we add versioned resources, versioned
> collections, and multiple revisions.
> 
> [CK]Your right -- some clarification here would be could.
> 
> 3. It is not possible to automatically create workspaces or activities
> for
> either non-versioning clients, or versioning clients that don't
> specify
> them. Default workspaces and/or activities must be used. Creating a
> new
> workspace or activity on each request could cause resources that were
> manipulated in the previous request to disappear.
> 
> [CK] If we say this is what "logically" happens on a Level 1 server
> then
> [CK] OK.  But if the server must in fact do this, then I think the
> cost
> [CK] is too high since Level 1 clients don't care about this
> information.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


From w3c-dist-auth-request@www10.w3.org  Tue Feb 23 19:02:19 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05503
	for <w3c-dist-auth@www19.w3.org>; Tue, 23 Feb 1999 19:02:19 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA08229
	for <w3c-dist-auth@w3.org>; Tue, 23 Feb 1999 19:02:18 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20768;
	Tue, 23 Feb 1999 19:02:15 -0500 (EST)
Message-Id: <199902240002.TAA20768@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
>From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 23 Feb 1999 19:02:14 -0500
Sender: scoya@ns.cnri.reston.va.us
Subject: I-D ACTION:draft-ietf-webdav-collection-reqts-04.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the WWW Distributed
Authoring and Versioning Working Group of the IETF.

	Title           : Requirements for Advanced Collection
			  Functionality in WebDAV
	Author(s)	: J. Slein, J. Davis
	Filename	: draft-ietf-webdav-collection-reqts-04.txt
	Pages		: 11
	Date		: 19-Feb-99
	
The base WebDAV protocol [WebDAV] provides basic support for
        collections.  It defines a MKCOL method for creating collections
        and specifies how other HTTP and WebDAV methods interact with
        collections.  It supports internal members of collections, which it
        defines as members whose URIs are immediately relative to the URI
        of the collection.
 
        This draft sets out requirements for more advanced, optional
        collection functionality. It extends the base functionality in two
        general directions: support for referential resources, and support
        for ordered collections.  A separate WebDAV specification is
        expected to define protocol elements providing the functionality
        described here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-collection-reqts-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-collection-reqts-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-collection-reqts-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990223182229.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-collection-reqts-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-collection-reqts-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990223182229.I-D@ietf.org>

--OtherAccess--

--NextPart--



From w3c-dist-auth-request@www10.w3.org  Tue Feb 23 19:02:26 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA05527
	for <w3c-dist-auth@www19.w3.org>; Tue, 23 Feb 1999 19:02:26 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA08232
	for <w3c-dist-auth@w3.org>; Tue, 23 Feb 1999 19:02:24 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20796;
	Tue, 23 Feb 1999 19:02:21 -0500 (EST)
Message-Id: <199902240002.TAA20796@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
>From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 23 Feb 1999 19:02:21 -0500
Sender: scoya@ns.cnri.reston.va.us
Subject: I-D ACTION:draft-ietf-webdav-collection-protocol-03.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: WebDAV Advanced Collections Protocol
	Author(s)       : A. Babich, T. Chihaya, G. Clemm, J. Davis,
			  C. Fay, J. Slein, J. Whitehead
	Filename	: draft-ietf-webdav-collection-protocol-03.txt
	Pages		: 53
	Date		: 19-Feb-99
	
The base WebDAV protocol [WebDAV] provides basic support for
collections.  It defines a MKCOL method for creating collections and
specifies how other HTTP and WebDAV methods interact with collections.
It supports internal members of collections, which it defines as URIs
that are immediately relative to the URI of the collection.
 
Many applications, however, need more powerful collections.  There are
two areas in particular where more powerful functionality is often
needed: referential resources and ordering.
 
This draft specifies extensions to the base WebDAV protocol to support
these more powerful collections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-collection-protocol-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-collection-protocol-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-collection-protocol-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990223182244.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-collection-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-collection-protocol-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990223182244.I-D@ietf.org>

--OtherAccess--

--NextPart--



From w3c-dist-auth-request@www10.w3.org  Thu Feb 25 15:41:20 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA18873
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Feb 1999 15:41:20 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA02145
	for <w3c-dist-auth@w3.org>; Thu, 25 Feb 1999 15:41:14 -0500 (EST)
Received: from tantalum by gw.atria.com id <PAA20591@gw.atria.com> Thu, 25 Feb 1999 15:41:08 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA06625; Thu, 25 Feb 1999 15:41:07 -0500
Date: Thu, 25 Feb 1999 15:41:07 -0500
Message-Id: <9902252041.AA06625@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F59@RED-MSG-59> (message
	from Yaron Goland on Mon, 22 Feb 1999 15:07:25 -0800)
Subject: Re: Collections Protocol Review


Judy: I think Yaron raised all of the issues that I had promised
you some backup material, so I'll use his message as a motivator for
finally getting it to you (:-).

   From: Yaron Goland <yarong@microsoft.com>

   The purpose of a spec is to help implementers and we should choose
   definitions that aid in that cause. Redirect references are based on 3xx and
   should be defined as such. This makes the situation extremely clear to
   anyone writing code.

I believe redirect references are *not* intended to be an abstraction that
means "things that return 3xx".  They *are* intended to be an abstraction
for "references that are visible to downlevel clients", and 3xx was a
convenient mechanism to do that.  So their semantics is determined by
"what is a good way to expose references to downlevel clients", and not
"always return 3xx".  Although the later semantics is simpler to implement,
it is a much less valuable abstraction to introduce (in my opinion).

   .... Continue to use Location and define an addition header
   LocationEx (a nod to my MS roots =). The definition is "First use Location
   and if that doesn't work then try the list of URIs in LocationEx." 100%
   compatible with existing systems and better functionality for advanced
   collection enhanced clients.

One of the advantages of a redirect reference is that it does not require
the server to hop off to other servers to see what's there (and gives the
downlevel client more control of where it wants the server to go hopping).
The LocationEx header loses these advantages.


   > > (Issue #5) Section 4.3.1 - Why DAV:reftarget, reftype and 
   > > refintegrity are
   > > stand alone properties - I do not understand why 
   > > DAV:reftarget, DAV:reftype
   > > and DAV:refintegrity are all defined as properties. As these 
   > > values help to
   > > define the nature of the resource type should they not have 
   > > their values
   > > included inside the DAV:reference element in the 
   > > DAV:resourcetype property?

I disagree.  The DAV:reftarget is much more like the "value"
of the resource, than it is the "type" of the resource.  The DAV:refintegrity
property could be orthogonal to each of these, in that it is easy
to imagine a server where the integrity properties of a reference
can be changed, without changing either the reftarget or the
direct/redirect "type" of the reference.

   > > (Issue #6) Section 4.3.1 - MKREF and the use of bodies - Why 
   > > doesn't MKREF
   > > follow the same rules that MKCOL has regarding the possible 
   > > inclusion of a
   > > body?

I agree.  I personally feel that all MKxxx methods should allow an
XML body that initializes any and all of the contents/properties of
the resource being created.  Just like a PROPPATCH.

   > > (Issue #7) Section 4.4.1 - Do references to collections have 
   > > to provide
   > > references for all the members of the collection?

No.  A reference is a member of a collection.
What collection would these "references to members" be part of?
The reference to the collection is not itself a collection, it is
a reference, so it cannot contain these "references to members",
and there doesn't seem to be any other candidate to do so either.

Or we could just look at the kinds of things references are there to model:
things like symbolic links in Unix file systems, and shortcuts in NT
(or symbolic links in NT, once they finally appear :-).  When you
create a symbolic link to a directory or shortcut to a folder, you
don't create symbolic links or shortcuts to all the members of that
directory or folder.

   > > - If one creates a
   > > reference to a collection is one also required to create 
   > > references to all
   > > the members of that collection? I suspect the answer is yes 
   > > but this is not
   > > clear from the specification.

The answer is no.

Judy: let's add words to the effect that "References to collections
allow clients to introduce multiple URL's for the same resource."  to
avoid this potential source of confusion.

   > > For example, the referential 
   > > resource in the
   > > example is http://www.svr.com/MyCollection/tuva/ and it points to a
   > > collection which has a member called history.html. Does this 
   > > mean that a GET
   > > on http://www.svr.com/MyCollection/tuva/history.html MUST 
   > > succeed?

If  http://www.svr.com/MyCollection/tuva/ is a reference to
http://www.other.com/YourCollection/, then
http://www.svr.com/MyCollection/tuva/history.html and
http://www.other.com/YourCollection/history.html are two different
URL's for the *same* resource.

So a GET on one will succeed if a GET on the other will succeed.
The server does the dereferencing for direct references.  The client
does the dereferencing for redirect references.

   > > In other
   > > words, that by creating a reference to a collection one is 
   > required to
   > > create references to its entire tree? Again, I suspect the 
   > > answer is yes
   > > (this would explain the PROPFIND response format for direct 
   > > references as
   > > well as the COPY behavior for direct references) but this 
   > > requirement is
   > > never explicitly stated in the spec.

You are assuming that every distinct URL selects a distinct resource.
This is not the case, and references to collections allow clients
to explicitly make this not be the case.

   HTTP defines that there are HTTP URLs and that HTTP URLs point to resource.

Yes.

   If creating a reference called http://foo/bar that points to a collection
   with a member baz and thus I can perform a GET on http://foo/bar/baz, even
   though the MKREF only created http://foo/bar, then there exists a resource
   called http://foo/bar/baz

Yes.

   and it is a reference.

No.  References are not in HTTP-1.1, so there's no way it could require that
this resource be a reference.

   Thus the only possible
   conclusion is that creating a reference to a collection causes references to
   be created to all the members of that reference's entire tree. Otherwise
   http://foo/bar/baz would fail.

No, http://foo/bar/baz is a resource that just happens to have another URL
that can be used to refer to it.

   > > (Issue #9) Section 4.6 - Banning passthrough behavior on 
   > > DELETE and MOVE - I
   > > have a direct reference http://foo/bar to http://bar/blaz. I 
   > > can define a
   > > MOVE on http://foo/bar to http://icky/bik as meaning that 
   > > http://bar/blaz is
   > > to be moved to http://icky/bik.

True.

In the presence of references, there are always two possible
interpretations of every request, namely, apply it to the reference
itself, or apply it to the target.  For methods where both of
these interpretations are useful, the question is not which to
support (we will support both), but rather, which interpretation
is the default and which interpretation  requires Adv.Col. methods
or properties to achieve.

The desired behavior for downlevel clients will significantly affect
the choice of a default.  Note that it will *affect* the choice of a
default, but will not determine it, since there could be uplevel
considerations that override the downlevel ones.

For most methods (e.g. GET, PUT, LOCK), the only way to make the results
of the method visible to a downlevel client is to have it affect
the target.  This is actually unfortunate for "write" operations, because
the downlevel client can unknowingly affect what is seen at a
whole bunch of other URL's.  (Yaron mentions this below).

This would be *especially* unfortunate for heavyweight operations like
DELETE and MOVE, which can result in all references to those other URL's
to dangle, the bane of Web management.

Happily, we can fulfill the semantics of DELETE and MOVE for downlevel
clients *without* the damaging effect on these other URL's, by having
the default behavior of the method be "no-passthrough".  A client using
the URL(s) explicitly named in the DELETE and MOVE will see the desired
effect, without trashing all the other references to the target of
that reference.

Now an uplevel client can find out the URL of the target, and do the
DELETE/MOVE on it (knowingly trashing all references to that target).
It requires them to do an explicit PROPFIND, and is not something
downlevel (or uplevel!) clients end up doing by mistake.

   > > Following the logic discussed 
   > > in Issue #7 I
   > > can even properly define how to move any children that 
   > > http://bar/blaz might
   > > have. With DELETE I can define a DELETE of http://foo/bar as 
   > > meaning that
   > > http://bar/blaz should be deleted. So there doesn't seem to 
   > > be any technical
   > > reason to ban passthrough behavior on MOVE and DELETE 
   > involving direct
   > > references.

Agreed.  It is a downlevel usability argument that bans it.

   > > 	I suspect the real reason that passthrough behavior is 
   > > disallowed on
   > > direct references is because of concerns regarding interactions with
   > > existing WebDAV clients. In most file systems that support 
   > > links if one
   > > deletes or moves a link, only the link is deleted or moved. I 
   > > suspect the
   > > authors are concerned that allowing passthrough on DELETE and 
   > > MOVE would
   > > mean that if an existing WebDAV client asks for a DELETE or 
   > > MOVE then the
   > > resource being pointed at would be deleted/moved as well, 
   > which wasn't
   > > something the non-reference enabled client would have 
   > > intended.

Exactly.

   > >  As such I
   > > think it is completely reasonable to design the protocol such 
   > > that if a RFC
   > > 2518 client issues a DELETE or MOVE then only the direct 
   > > reference and not
   > > the target is affected.

Having it do one thing for 2518 clients, and another thing for other
clients would be very confusing, and cause all sorts of mistakes.
(Or did you not intend to imply that we would do something different
for non-2518 clients?)

   > > In fact I would propose the design 
   > > rule that when
   > > moving/deleting a resource the resource should retain its 
   > type unless
   > > explicit instructions to the contrary are given.

Agreed.

   > > That is, 
   > if you are a
   > > direct reference at the source then you should be a direct 
   > > reference at the
   > > destination unless explicit instructions to the contrary 
   > are provided.

Agreed (for a MOVE operation).

   > > 	The way to easily implement this rule is to give 
   > > no-passthrough a
   > > value and define the default for that value on a method by 
   > > method basis.
   > > PROPFIND and COPY, for example, would default to no-passthrough: f.
   > > MOVE/DELETE would default to no-passthrough: t.
 
Sounds fine to me (as long as these rules are not HTTP-level dependent).

   > > 	The previous all applies to direct references. Redirect 
   > > references
   > > are obviously a different animal since one can only directly 
   > > manipulate the
   > > reference and never the target. Thus the only issue is - 
   > > should a 302 ever
   > > appear in a COPY/MOVE/DELETE response? Following the law of 
   > > minimum surprise
   > > an RFC 2518 client getting a 302 would be very surprised. 
   > > They ordered that
   > > all resources be copied, redirect references are resources, 
   > > therefore they
   > > should be copied. As such I propose that redirect references on
   > > COPY/MOVE/DELETE always behavior as if no-passthrough equals 
   > > t, regardless
   > > of its actual value.

For MOVE/DELETE, yes.  This is consistent with direct reference
functionality.  For COPY, I and Judy vote no.  The client needs to be
warned that there really will *not* be a copy made, and it will then
have sufficient information to make a real copy if it needs to.

   I still fail to see why you are banning perfectly reasonable functionality
   when there does not appear to be any technical or protocol related reason
   for doing so.

We are not banning functionality, we are just picking the other more
expected functionality as the default.  Remember, both interpretations
are valid and are supported -- we're just deciding what is the default.

   As my comments demonstrate it is completely possible to use
   DELETE and MOVE to effect the targets and to do so in a manner which causes
   the expected behavior with RFC 2518 clients.

Only if you have one set of clients (2518) clients see one kind of
behavior and other clients see a very different kind of behavior.
Since you can achieve the alternative DELETE/MOVE semantics, why would
you consciously introduce this kind of inconsistency?

   As such what possible reason
   can there be for banning this logical and well defined behavior? Just
   because it doesn't fit your conceptual model? This would argue for changing
   your model not banning this functionality. Again, I call upon the general
   HTTP rule "allow unless you have a damn good reason for not doing so."

We're not banning anything, we're just making sure the default
is consistent and corresponds to the semantics that the majority of
servers and clients support/expect.

   > > (Issue #10) Section 4.7.1 - Passthrough locks on direct 
   > > references - I'm
   > > thoroughly confused regarding why a passthrough lock doesn't 
   > > lock both the
   > > reference and the target.

This is the main point I owed Judy a writeup on.  There are a variety
of reasons why it should only lock the target.  Many of them have to
do with making the semantics of a LOCK work in the presence of versioning
(and versioned namespaces in particular).

But there are some simple examples that don't require understanding
the needs of versioning, so let's see if those are convincing first.

For example, if I take out an exclusive lock on /x/y/z.html, and
/x/ is a reference, then I would need to take out a lock on /x/
or else someone could just DELETE /x/, and put a new reference or
collection in its place, thereby causing a different resource to
be selected by /x/y/z.html.

But that means that any subsequent attempt to get an exclusive lock
an *any* resource with a URL beginning /x/ will fail, because of
the prior exclusive lock on /x/.

This kind of behavior is even more disastrous in the presence of
versioned URL namespaces, where the whole point is to allow
multiple people to use the same URL (combined with a Version-Name
or Workspace header) to access different resources.

The alternative, which says that a lock on /x/y/z.html locks the
*resource* that this URL refers to, but does not lock the binding
of that URL to that resource, avoids this problem, and furthermore,
is consistent with access control on file systems (those file systems
guys were actually pretty smart when they decided on these kinds of
issues).

   > > I read the spec a couple of times 
   > > and I still
   > > don't get it. For example, imagine an RFC 2518 client 
   > issued a lock on
   > > http://foo/bar which is a direct reference to
   > > http://bar/blaz. To the RFC 2518 client it appears that they have 
   > > locked http://foo/bar which will act exactly as 
   > http://bar/blaz. This
   > seems > the much more reasonable behavior.
   > > I'm sure there is a scenario here I'm missing but whatever 
   > it is, I wasn't
   > > able to discern it from the spec. I apologize if the 
   > scenario is staring
   > me
   > > in the face and I am just failing to see it.

No, the scenario (especially the versioned namespace scenario) is
not staring you in the face (unless you've ever tried to implement
a versioned namespace!).

   The current situation is, in my opinion, a clear violation of RFC 2518. RFC
   2518 is crystal clear that locking a resource means that the resource is
   locked.

Not at all a clear violation.  A URL is a handle on a resource, it is
not the resource.  This is made very clear by the fact that multiple
URL's can refer to the same resource.  So if 2518 said "you lock a
URL", then it would be crystal clear, and I would have objected
strenuously to the spec, because that definition of locking is
incompatible with advanced versioning, where users must have the
ability to use the same URL (plus a header) to refer to different
resources.

No, 2518 got it right.  What you are locking is a resource, not the
binding of a URL to a resource.

   Your current definition does not do this. In fact someone locking a
   direct reference, which actually locks the target, could end up with the
   reference changed underneath them, thus leading to the violation.

The alternative is worse (i.e. having a lock on one resource preventing
you from locking any other resource in that tree).  This is why a "lock"
on a file in a file system (e.g. making it read-only except for the owner),
does not "pin" that inode to that pathname.  Again, those file system
guys knew what they were doing.

   Whatever
   solution you choose the reference MUST be locked or this specification is in
   violation of RFC 2518 and must therefore choose a new method name rather
   than LOCK.

   Personally I think you should just accept that LOCKing references can be a
   bit wacky and will result in locking both the reference and the target.

We do accept that LOCK'ing references will be a bit wacky, and
they will lock only the target (:-).

   > Thanks again for (as always) prompt and insightful comments.

Me too!!

Cheers,
Geoff



From w3c-dist-auth-request@www10.w3.org  Thu Feb 25 23:35:16 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA26869
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Feb 1999 23:35:15 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id XAA06291
	for <w3c-dist-auth@w3.org>; Thu, 25 Feb 1999 23:35:14 -0500 (EST)
Received: from tantalum by gw.atria.com id <XAA08878@gw.atria.com> Thu, 25 Feb 1999 23:35:14 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA06902; Thu, 25 Feb 1999 23:35:12 -0500
Date: Thu, 25 Feb 1999 23:35:12 -0500
Message-Id: <9902260435.AA06902@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<201BB34B3A73D1118C1F00805F1582E8B76D80@x-wb-0128-nt8.wrc.xerox.com>
	(JSlein@crt.xerox.com)
Subject: Locking a Resource or Locking a URL?


One of the key topics in the recent thread on the Adv. Versioning Collection
protocol was the question of what gets locked when you lock a resource.

There are (at least :-) three interpretations:

(1) You are locking only the resource.

(2) You are locking what appears at a given URL (i.e. if the resource
currently selected at that URL also appears at another URL, then the
lock does not apply to accesses through that other URL).

(3) You are locking both the resource and the fact that the resource
appears at the given URL.

In my message in the Adv. Coll. thread, I gave arguments for why
(3) does not work in the context of references and versioning.

In this message, I would like to confirm that nobody believes that
(2) is the correct interpretation.  In particular, I would like to
confirm that if /a/x.html and /b/y.html happen to be the same resource
(by some quirk of the server, say), and /a/x.html is locked, then
a PUT to /b/y.html would fail without the appropriate lock token.

There also is the question of whether lock discovery would detect this
implicit lock on /b/y.html.  This question has two parts ... what do
you think the spec currently says, and what did the spec authors
intend?

Cheers,
Geoff



From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:08:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00097
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:08:17 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA06891
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:08:16 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FLJC1K04>; Thu, 25 Feb 1999 22:08:15 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F94@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, w3c-dist-auth@w3.org
Date: Thu, 25 Feb 1999 22:08:13 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Locking a Resource or Locking a URL?

[Larry, stop laughing.]

You perceive a differentiation where none exists. URLs exist solely to
address resources. That a resource has multiple URLs is irrelevant. When a
method is sent to a URL the end result is an interaction with a resource.
Thus, using your language, #2 is correct. Any other interpretation would
mean that someone locking a resource through one URL could still see the
resource changed simply because someone addressing the same resource through
another URL made a change. I believe the WebDAV spec to be crystal clear on
this point but if somehow the language has lead you astray please point out
the language that confused you and I will make sure it is properly edited
before we move on to draft status.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 8:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Locking a Resource or Locking a URL?
> 
> 
> 
> One of the key topics in the recent thread on the Adv. 
> Versioning Collection
> protocol was the question of what gets locked when you lock a 
> resource.
> 
> There are (at least :-) three interpretations:
> 
> (1) You are locking only the resource.
> 
> (2) You are locking what appears at a given URL (i.e. if the resource
> currently selected at that URL also appears at another URL, then the
> lock does not apply to accesses through that other URL).
> 
> (3) You are locking both the resource and the fact that the resource
> appears at the given URL.
> 
> In my message in the Adv. Coll. thread, I gave arguments for why
> (3) does not work in the context of references and versioning.
> 
> In this message, I would like to confirm that nobody believes that
> (2) is the correct interpretation.  In particular, I would like to
> confirm that if /a/x.html and /b/y.html happen to be the same resource
> (by some quirk of the server, say), and /a/x.html is locked, then
> a PUT to /b/y.html would fail without the appropriate lock token.
> 
> There also is the question of whether lock discovery would detect this
> implicit lock on /b/y.html.  This question has two parts ... what do
> you think the spec currently says, and what did the spec authors
> intend?
> 
> Cheers,
> Geoff
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:21:04 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00363
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:21:04 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA06949
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:21:03 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FLJC1L0Y>; Thu, 25 Feb 1999 22:21:02 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F96@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: w3c-dist-auth@w3.org
Date: Thu, 25 Feb 1999 22:21:01 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Collections Protocol Review

Geoffrey, having read your letter I believe the gulf between us in our
understanding of the most fundamental design principals of the HTTP and
WebDAV object models to be so vast that attempting to resolve this issue by
e-mail will prove futile.

E-mail, I have found, is only useful when substantive common understanding
exist and remaining issues address mere detail. 

Such is not the case here.

Previous experience leads me to guess that you will be attending the next
IETF. If so, I will try my best to finish my review of the collections spec
by then and perhaps we can get together to discuss the matter in person.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 12:41 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Collections Protocol Review
> 
> 
> 
> Judy: I think Yaron raised all of the issues that I had promised
> you some backup material, so I'll use his message as a motivator for
> finally getting it to you (:-).
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    The purpose of a spec is to help implementers and we should choose
>    definitions that aid in that cause. Redirect references 
> are based on 3xx and
>    should be defined as such. This makes the situation 
> extremely clear to
>    anyone writing code.
> 
> I believe redirect references are *not* intended to be an 
> abstraction that
> means "things that return 3xx".  They *are* intended to be an 
> abstraction
> for "references that are visible to downlevel clients", and 3xx was a
> convenient mechanism to do that.  So their semantics is determined by
> "what is a good way to expose references to downlevel 
> clients", and not
> "always return 3xx".  Although the later semantics is simpler 
> to implement,
> it is a much less valuable abstraction to introduce (in my opinion).
> 
>    .... Continue to use Location and define an addition header
>    LocationEx (a nod to my MS roots =). The definition is 
> "First use Location
>    and if that doesn't work then try the list of URIs in 
> LocationEx." 100%
>    compatible with existing systems and better functionality 
> for advanced
>    collection enhanced clients.
> 
> One of the advantages of a redirect reference is that it does 
> not require
> the server to hop off to other servers to see what's there 
> (and gives the
> downlevel client more control of where it wants the server to 
> go hopping).
> The LocationEx header loses these advantages.
> 
> 
>    > > (Issue #5) Section 4.3.1 - Why DAV:reftarget, reftype and 
>    > > refintegrity are
>    > > stand alone properties - I do not understand why 
>    > > DAV:reftarget, DAV:reftype
>    > > and DAV:refintegrity are all defined as properties. As these 
>    > > values help to
>    > > define the nature of the resource type should they not have 
>    > > their values
>    > > included inside the DAV:reference element in the 
>    > > DAV:resourcetype property?
> 
> I disagree.  The DAV:reftarget is much more like the "value"
> of the resource, than it is the "type" of the resource.  The 
> DAV:refintegrity
> property could be orthogonal to each of these, in that it is easy
> to imagine a server where the integrity properties of a reference
> can be changed, without changing either the reftarget or the
> direct/redirect "type" of the reference.
> 
>    > > (Issue #6) Section 4.3.1 - MKREF and the use of bodies - Why 
>    > > doesn't MKREF
>    > > follow the same rules that MKCOL has regarding the possible 
>    > > inclusion of a
>    > > body?
> 
> I agree.  I personally feel that all MKxxx methods should allow an
> XML body that initializes any and all of the contents/properties of
> the resource being created.  Just like a PROPPATCH.
> 
>    > > (Issue #7) Section 4.4.1 - Do references to collections have 
>    > > to provide
>    > > references for all the members of the collection?
> 
> No.  A reference is a member of a collection.
> What collection would these "references to members" be part of?
> The reference to the collection is not itself a collection, it is
> a reference, so it cannot contain these "references to members",
> and there doesn't seem to be any other candidate to do so either.
> 
> Or we could just look at the kinds of things references are 
> there to model:
> things like symbolic links in Unix file systems, and shortcuts in NT
> (or symbolic links in NT, once they finally appear :-).  When you
> create a symbolic link to a directory or shortcut to a folder, you
> don't create symbolic links or shortcuts to all the members of that
> directory or folder.
> 
>    > > - If one creates a
>    > > reference to a collection is one also required to create 
>    > > references to all
>    > > the members of that collection? I suspect the answer is yes 
>    > > but this is not
>    > > clear from the specification.
> 
> The answer is no.
> 
> Judy: let's add words to the effect that "References to collections
> allow clients to introduce multiple URL's for the same resource."  to
> avoid this potential source of confusion.
> 
>    > > For example, the referential 
>    > > resource in the
>    > > example is http://www.svr.com/MyCollection/tuva/ and 
> it points to a
>    > > collection which has a member called history.html. Does this 
>    > > mean that a GET
>    > > on http://www.svr.com/MyCollection/tuva/history.html MUST 
>    > > succeed?
> 
> If  http://www.svr.com/MyCollection/tuva/ is a reference to
> http://www.other.com/YourCollection/, then
> http://www.svr.com/MyCollection/tuva/history.html and
> http://www.other.com/YourCollection/history.html are two different
> URL's for the *same* resource.
> 
> So a GET on one will succeed if a GET on the other will succeed.
> The server does the dereferencing for direct references.  The client
> does the dereferencing for redirect references.
> 
>    > > In other
>    > > words, that by creating a reference to a collection one is 
>    > required to
>    > > create references to its entire tree? Again, I suspect the 
>    > > answer is yes
>    > > (this would explain the PROPFIND response format for direct 
>    > > references as
>    > > well as the COPY behavior for direct references) but this 
>    > > requirement is
>    > > never explicitly stated in the spec.
> 
> You are assuming that every distinct URL selects a distinct resource.
> This is not the case, and references to collections allow clients
> to explicitly make this not be the case.
> 
>    HTTP defines that there are HTTP URLs and that HTTP URLs 
> point to resource.
> 
> Yes.
> 
>    If creating a reference called http://foo/bar that points 
> to a collection
>    with a member baz and thus I can perform a GET on 
> http://foo/bar/baz, even
>    though the MKREF only created http://foo/bar, then there 
> exists a resource
>    called http://foo/bar/baz
> 
> Yes.
> 
>    and it is a reference.
> 
> No.  References are not in HTTP-1.1, so there's no way it 
> could require that
> this resource be a reference.
> 
>    Thus the only possible
>    conclusion is that creating a reference to a collection 
> causes references to
>    be created to all the members of that reference's entire 
> tree. Otherwise
>    http://foo/bar/baz would fail.
> 
> No, http://foo/bar/baz is a resource that just happens to 
> have another URL
> that can be used to refer to it.
> 
>    > > (Issue #9) Section 4.6 - Banning passthrough behavior on 
>    > > DELETE and MOVE - I
>    > > have a direct reference http://foo/bar to http://bar/blaz. I 
>    > > can define a
>    > > MOVE on http://foo/bar to http://icky/bik as meaning that 
>    > > http://bar/blaz is
>    > > to be moved to http://icky/bik.
> 
> True.
> 
> In the presence of references, there are always two possible
> interpretations of every request, namely, apply it to the reference
> itself, or apply it to the target.  For methods where both of
> these interpretations are useful, the question is not which to
> support (we will support both), but rather, which interpretation
> is the default and which interpretation  requires Adv.Col. methods
> or properties to achieve.
> 
> The desired behavior for downlevel clients will significantly affect
> the choice of a default.  Note that it will *affect* the choice of a
> default, but will not determine it, since there could be uplevel
> considerations that override the downlevel ones.
> 
> For most methods (e.g. GET, PUT, LOCK), the only way to make 
> the results
> of the method visible to a downlevel client is to have it affect
> the target.  This is actually unfortunate for "write" 
> operations, because
> the downlevel client can unknowingly affect what is seen at a
> whole bunch of other URL's.  (Yaron mentions this below).
> 
> This would be *especially* unfortunate for heavyweight operations like
> DELETE and MOVE, which can result in all references to those 
> other URL's
> to dangle, the bane of Web management.
> 
> Happily, we can fulfill the semantics of DELETE and MOVE for downlevel
> clients *without* the damaging effect on these other URL's, by having
> the default behavior of the method be "no-passthrough".  A 
> client using
> the URL(s) explicitly named in the DELETE and MOVE will see 
> the desired
> effect, without trashing all the other references to the target of
> that reference.
> 
> Now an uplevel client can find out the URL of the target, and do the
> DELETE/MOVE on it (knowingly trashing all references to that target).
> It requires them to do an explicit PROPFIND, and is not something
> downlevel (or uplevel!) clients end up doing by mistake.
> 
>    > > Following the logic discussed 
>    > > in Issue #7 I
>    > > can even properly define how to move any children that 
>    > > http://bar/blaz might
>    > > have. With DELETE I can define a DELETE of http://foo/bar as 
>    > > meaning that
>    > > http://bar/blaz should be deleted. So there doesn't seem to 
>    > > be any technical
>    > > reason to ban passthrough behavior on MOVE and DELETE 
>    > involving direct
>    > > references.
> 
> Agreed.  It is a downlevel usability argument that bans it.
> 
>    > > 	I suspect the real reason that passthrough behavior is 
>    > > disallowed on
>    > > direct references is because of concerns regarding 
> interactions with
>    > > existing WebDAV clients. In most file systems that support 
>    > > links if one
>    > > deletes or moves a link, only the link is deleted or moved. I 
>    > > suspect the
>    > > authors are concerned that allowing passthrough on DELETE and 
>    > > MOVE would
>    > > mean that if an existing WebDAV client asks for a DELETE or 
>    > > MOVE then the
>    > > resource being pointed at would be deleted/moved as well, 
>    > which wasn't
>    > > something the non-reference enabled client would have 
>    > > intended.
> 
> Exactly.
> 
>    > >  As such I
>    > > think it is completely reasonable to design the protocol such 
>    > > that if a RFC
>    > > 2518 client issues a DELETE or MOVE then only the direct 
>    > > reference and not
>    > > the target is affected.
> 
> Having it do one thing for 2518 clients, and another thing for other
> clients would be very confusing, and cause all sorts of mistakes.
> (Or did you not intend to imply that we would do something different
> for non-2518 clients?)
> 
>    > > In fact I would propose the design 
>    > > rule that when
>    > > moving/deleting a resource the resource should retain its 
>    > type unless
>    > > explicit instructions to the contrary are given.
> 
> Agreed.
> 
>    > > That is, 
>    > if you are a
>    > > direct reference at the source then you should be a direct 
>    > > reference at the
>    > > destination unless explicit instructions to the contrary 
>    > are provided.
> 
> Agreed (for a MOVE operation).
> 
>    > > 	The way to easily implement this rule is to give 
>    > > no-passthrough a
>    > > value and define the default for that value on a method by 
>    > > method basis.
>    > > PROPFIND and COPY, for example, would default to 
> no-passthrough: f.
>    > > MOVE/DELETE would default to no-passthrough: t.
>  
> Sounds fine to me (as long as these rules are not HTTP-level 
> dependent).
> 
>    > > 	The previous all applies to direct references. Redirect 
>    > > references
>    > > are obviously a different animal since one can only directly 
>    > > manipulate the
>    > > reference and never the target. Thus the only issue is - 
>    > > should a 302 ever
>    > > appear in a COPY/MOVE/DELETE response? Following the law of 
>    > > minimum surprise
>    > > an RFC 2518 client getting a 302 would be very surprised. 
>    > > They ordered that
>    > > all resources be copied, redirect references are resources, 
>    > > therefore they
>    > > should be copied. As such I propose that redirect references on
>    > > COPY/MOVE/DELETE always behavior as if no-passthrough equals 
>    > > t, regardless
>    > > of its actual value.
> 
> For MOVE/DELETE, yes.  This is consistent with direct reference
> functionality.  For COPY, I and Judy vote no.  The client needs to be
> warned that there really will *not* be a copy made, and it will then
> have sufficient information to make a real copy if it needs to.
> 
>    I still fail to see why you are banning perfectly 
> reasonable functionality
>    when there does not appear to be any technical or protocol 
> related reason
>    for doing so.
> 
> We are not banning functionality, we are just picking the other more
> expected functionality as the default.  Remember, both interpretations
> are valid and are supported -- we're just deciding what is 
> the default.
> 
>    As my comments demonstrate it is completely possible to use
>    DELETE and MOVE to effect the targets and to do so in a 
> manner which causes
>    the expected behavior with RFC 2518 clients.
> 
> Only if you have one set of clients (2518) clients see one kind of
> behavior and other clients see a very different kind of behavior.
> Since you can achieve the alternative DELETE/MOVE semantics, why would
> you consciously introduce this kind of inconsistency?
> 
>    As such what possible reason
>    can there be for banning this logical and well defined 
> behavior? Just
>    because it doesn't fit your conceptual model? This would 
> argue for changing
>    your model not banning this functionality. Again, I call 
> upon the general
>    HTTP rule "allow unless you have a damn good reason for 
> not doing so."
> 
> We're not banning anything, we're just making sure the default
> is consistent and corresponds to the semantics that the majority of
> servers and clients support/expect.
> 
>    > > (Issue #10) Section 4.7.1 - Passthrough locks on direct 
>    > > references - I'm
>    > > thoroughly confused regarding why a passthrough lock doesn't 
>    > > lock both the
>    > > reference and the target.
> 
> This is the main point I owed Judy a writeup on.  There are a variety
> of reasons why it should only lock the target.  Many of them have to
> do with making the semantics of a LOCK work in the presence 
> of versioning
> (and versioned namespaces in particular).
> 
> But there are some simple examples that don't require understanding
> the needs of versioning, so let's see if those are convincing first.
> 
> For example, if I take out an exclusive lock on /x/y/z.html, and
> /x/ is a reference, then I would need to take out a lock on /x/
> or else someone could just DELETE /x/, and put a new reference or
> collection in its place, thereby causing a different resource to
> be selected by /x/y/z.html.
> 
> But that means that any subsequent attempt to get an exclusive lock
> an *any* resource with a URL beginning /x/ will fail, because of
> the prior exclusive lock on /x/.
> 
> This kind of behavior is even more disastrous in the presence of
> versioned URL namespaces, where the whole point is to allow
> multiple people to use the same URL (combined with a Version-Name
> or Workspace header) to access different resources.
> 
> The alternative, which says that a lock on /x/y/z.html locks the
> *resource* that this URL refers to, but does not lock the binding
> of that URL to that resource, avoids this problem, and furthermore,
> is consistent with access control on file systems (those file systems
> guys were actually pretty smart when they decided on these kinds of
> issues).
> 
>    > > I read the spec a couple of times 
>    > > and I still
>    > > don't get it. For example, imagine an RFC 2518 client 
>    > issued a lock on
>    > > http://foo/bar which is a direct reference to
>    > > http://bar/blaz. To the RFC 2518 client it appears 
> that they have 
>    > > locked http://foo/bar which will act exactly as 
>    > http://bar/blaz. This
>    > seems > the much more reasonable behavior.
>    > > I'm sure there is a scenario here I'm missing but whatever 
>    > it is, I wasn't
>    > > able to discern it from the spec. I apologize if the 
>    > scenario is staring
>    > me
>    > > in the face and I am just failing to see it.
> 
> No, the scenario (especially the versioned namespace scenario) is
> not staring you in the face (unless you've ever tried to implement
> a versioned namespace!).
> 
>    The current situation is, in my opinion, a clear violation 
> of RFC 2518. RFC
>    2518 is crystal clear that locking a resource means that 
> the resource is
>    locked.
> 
> Not at all a clear violation.  A URL is a handle on a resource, it is
> not the resource.  This is made very clear by the fact that multiple
> URL's can refer to the same resource.  So if 2518 said "you lock a
> URL", then it would be crystal clear, and I would have objected
> strenuously to the spec, because that definition of locking is
> incompatible with advanced versioning, where users must have the
> ability to use the same URL (plus a header) to refer to different
> resources.
> 
> No, 2518 got it right.  What you are locking is a resource, not the
> binding of a URL to a resource.
> 
>    Your current definition does not do this. In fact someone locking a
>    direct reference, which actually locks the target, could 
> end up with the
>    reference changed underneath them, thus leading to the violation.
> 
> The alternative is worse (i.e. having a lock on one resource 
> preventing
> you from locking any other resource in that tree).  This is 
> why a "lock"
> on a file in a file system (e.g. making it read-only except 
> for the owner),
> does not "pin" that inode to that pathname.  Again, those file system
> guys knew what they were doing.
> 
>    Whatever
>    solution you choose the reference MUST be locked or this 
> specification is in
>    violation of RFC 2518 and must therefore choose a new 
> method name rather
>    than LOCK.
> 
>    Personally I think you should just accept that LOCKing 
> references can be a
>    bit wacky and will result in locking both the reference 
> and the target.
> 
> We do accept that LOCK'ing references will be a bit wacky, and
> they will lock only the target (:-).
> 
>    > Thanks again for (as always) prompt and insightful comments.
> 
> Me too!!
> 
> Cheers,
> Geoff
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:28:21 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00591
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:28:21 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA07008
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:28:19 -0500 (EST)
Received: from tantalum by gw.atria.com id <BAA11130@gw.atria.com> Fri, 26 Feb 1999 01:28:19 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA06992; Fri, 26 Feb 1999 01:28:17 -0500
Date: Fri, 26 Feb 1999 01:28:17 -0500
Message-Id: <9902260628.AA06992@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F94@RED-MSG-59> (message
	from Yaron Goland on Thu, 25 Feb 1999 22:08:13 -0800)
Subject: Re: Locking a Resource or Locking a URL?


   From: Yaron Goland <yarong@microsoft.com>

   [Larry, stop laughing.]

[Actually, keep laughing ... a little laughter it's good for the soul
 ... now we just have to figure out which of us he's laughing at :-]

   You perceive a differentiation where none exists. URLs exist solely to
   address resources. That a resource has multiple URLs is irrelevant. When a
   method is sent to a URL the end result is an interaction with a resource.

I agree.

   Thus, using your language, #2 is correct.

One of us has stayed up too late (:-).  #2 says (and I quote :-):
"if the resource currently selected at that URL also appears at
 another URL, then the lock does not apply to accesses through
 that other URL"

So aren't you saying that you agree with me that #2 is *incorrect* ?

   Any other interpretation would
   mean that someone locking a resource through one URL could still see the
   resource changed simply because someone addressing the same resource through
   another URL made a change.

Right.  That's what #2 says, and that would be silly.  So #2 is wrong.

   I believe the WebDAV spec to be crystal clear on
   this point but if somehow the language has lead you astray please point out
   the language that confused you and I will make sure it is properly edited
   before we move on to draft status.

Well, assuming you agree that #2 is wrong, I agree that the spec is clear
on the "wrongness of #2".

The *important* part of the discussion only comes when we chose between
#1 and #3, but I'll wait for you to confirm that #2 is definitely out.

Cheers,
Geoff

   > -----Original Message-----
   > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   > Sent: Thursday, February 25, 1999 8:35 PM
   > To: w3c-dist-auth@w3.org
   > Subject: Locking a Resource or Locking a URL?
   > 
   > 
   > 
   > One of the key topics in the recent thread on the Adv. 
   > Versioning Collection
   > protocol was the question of what gets locked when you lock a 
   > resource.
   > 
   > There are (at least :-) three interpretations:
   > 
   > (1) You are locking only the resource.
   > 
   > (2) You are locking what appears at a given URL (i.e. if the resource
   > currently selected at that URL also appears at another URL, then the
   > lock does not apply to accesses through that other URL).
   > 
   > (3) You are locking both the resource and the fact that the resource
   > appears at the given URL.
   > 
   > In my message in the Adv. Coll. thread, I gave arguments for why
   > (3) does not work in the context of references and versioning.
   > 
   > In this message, I would like to confirm that nobody believes that
   > (2) is the correct interpretation.  In particular, I would like to
   > confirm that if /a/x.html and /b/y.html happen to be the same resource
   > (by some quirk of the server, say), and /a/x.html is locked, then
   > a PUT to /b/y.html would fail without the appropriate lock token.
   > 
   > There also is the question of whether lock discovery would detect this
   > implicit lock on /b/y.html.  This question has two parts ... what do
   > you think the spec currently says, and what did the spec authors
   > intend?
   > 
   > Cheers,
   > Geoff
   > 
   > 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:34:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00793
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:34:23 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA07044
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:34:22 -0500 (EST)
Received: from tantalum by gw.atria.com id <BAA11553@gw.atria.com> Fri, 26 Feb 1999 01:34:21 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA07017; Fri, 26 Feb 1999 01:34:20 -0500
Date: Fri, 26 Feb 1999 01:34:20 -0500
Message-Id: <9902260634.AA07017@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F96@RED-MSG-59> (message
	from Yaron Goland on Thu, 25 Feb 1999 22:21:01 -0800)
Subject: Re: Collections Protocol Review

Yup, I'll be there (Minneapolis in March, who could skip it :-).

Anyone who'd like to join us, we usually do it poolside, with
Jim Amsden as referee.  The survivors (if any :-). will report
back to the mailing list.

Cheers,
Geoff

   From: Yaron Goland <yarong@microsoft.com>

   Geoffrey, having read your letter I believe the gulf between us in our
   understanding of the most fundamental design principals of the HTTP and
   WebDAV object models to be so vast that attempting to resolve this issue by
   e-mail will prove futile.

   E-mail, I have found, is only useful when substantive common understanding
   exist and remaining issues address mere detail. 

   Such is not the case here.

   Previous experience leads me to guess that you will be attending the next
   IETF. If so, I will try my best to finish my review of the collections spec
   by then and perhaps we can get together to discuss the matter in person.

			   Yaron


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:34:55 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA00875
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:34:55 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA07050
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:34:53 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FCC7K3QR>; Thu, 25 Feb 1999 22:34:54 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F97@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: w3c-dist-auth@w3.org
Date: Thu, 25 Feb 1999 22:34:47 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Locking a Resource or Locking a URL?

O.k. I'm completely lost. Let's try this again.

I have a resource which is available through two names, http://foo/bar and
http://iggy/pop. Someone requests and receives an exclusive write lock
against http://foo/bar. I assert that the immediate consequence is that
http://iggy/pop is ALSO write locked by the same principal.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 10:28 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Locking a Resource or Locking a URL?
> 
> 
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    [Larry, stop laughing.]
> 
> [Actually, keep laughing ... a little laughter it's good for the soul
>  ... now we just have to figure out which of us he's laughing at :-]
> 
>    You perceive a differentiation where none exists. URLs 
> exist solely to
>    address resources. That a resource has multiple URLs is 
> irrelevant. When a
>    method is sent to a URL the end result is an interaction 
> with a resource.
> 
> I agree.
> 
>    Thus, using your language, #2 is correct.
> 
> One of us has stayed up too late (:-).  #2 says (and I quote :-):
> "if the resource currently selected at that URL also appears at
>  another URL, then the lock does not apply to accesses through
>  that other URL"
> 
> So aren't you saying that you agree with me that #2 is *incorrect* ?
> 
>    Any other interpretation would
>    mean that someone locking a resource through one URL could 
> still see the
>    resource changed simply because someone addressing the 
> same resource through
>    another URL made a change.
> 
> Right.  That's what #2 says, and that would be silly.  So #2 is wrong.
> 
>    I believe the WebDAV spec to be crystal clear on
>    this point but if somehow the language has lead you astray 
> please point out
>    the language that confused you and I will make sure it is 
> properly edited
>    before we move on to draft status.
> 
> Well, assuming you agree that #2 is wrong, I agree that the 
> spec is clear
> on the "wrongness of #2".
> 
> The *important* part of the discussion only comes when we 
> chose between
> #1 and #3, but I'll wait for you to confirm that #2 is definitely out.
> 
> Cheers,
> Geoff
> 
>    > -----Original Message-----
>    > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>    > Sent: Thursday, February 25, 1999 8:35 PM
>    > To: w3c-dist-auth@w3.org
>    > Subject: Locking a Resource or Locking a URL?
>    > 
>    > 
>    > 
>    > One of the key topics in the recent thread on the Adv. 
>    > Versioning Collection
>    > protocol was the question of what gets locked when you lock a 
>    > resource.
>    > 
>    > There are (at least :-) three interpretations:
>    > 
>    > (1) You are locking only the resource.
>    > 
>    > (2) You are locking what appears at a given URL (i.e. if 
> the resource
>    > currently selected at that URL also appears at another 
> URL, then the
>    > lock does not apply to accesses through that other URL).
>    > 
>    > (3) You are locking both the resource and the fact that 
> the resource
>    > appears at the given URL.
>    > 
>    > In my message in the Adv. Coll. thread, I gave arguments for why
>    > (3) does not work in the context of references and versioning.
>    > 
>    > In this message, I would like to confirm that nobody 
> believes that
>    > (2) is the correct interpretation.  In particular, I 
> would like to
>    > confirm that if /a/x.html and /b/y.html happen to be the 
> same resource
>    > (by some quirk of the server, say), and /a/x.html is locked, then
>    > a PUT to /b/y.html would fail without the appropriate lock token.
>    > 
>    > There also is the question of whether lock discovery 
> would detect this
>    > implicit lock on /b/y.html.  This question has two parts 
> ... what do
>    > you think the spec currently says, and what did the spec authors
>    > intend?
>    > 
>    > Cheers,
>    > Geoff
>    > 
>    > 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 01:35:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA01079
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 01:35:41 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA07063
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 01:35:40 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FCC36BC0>; Thu, 25 Feb 1999 22:35:39 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F98@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: w3c-dist-auth@w3.org
Date: Thu, 25 Feb 1999 22:35:35 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Collections Protocol Review

Just make sure you bring the cool markers again!

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 10:34 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Collections Protocol Review
> 
> 
> Yup, I'll be there (Minneapolis in March, who could skip it :-).
> 
> Anyone who'd like to join us, we usually do it poolside, with
> Jim Amsden as referee.  The survivors (if any :-). will report
> back to the mailing list.
> 
> Cheers,
> Geoff
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    Geoffrey, having read your letter I believe the gulf 
> between us in our
>    understanding of the most fundamental design principals of 
> the HTTP and
>    WebDAV object models to be so vast that attempting to 
> resolve this issue by
>    e-mail will prove futile.
> 
>    E-mail, I have found, is only useful when substantive 
> common understanding
>    exist and remaining issues address mere detail. 
> 
>    Such is not the case here.
> 
>    Previous experience leads me to guess that you will be 
> attending the next
>    IETF. If so, I will try my best to finish my review of the 
> collections spec
>    by then and perhaps we can get together to discuss the 
> matter in person.
> 
> 			   Yaron
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 10:26:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA09447
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 10:26:22 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA10909
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 10:26:21 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA25478;
	Fri, 26 Feb 1999 10:26:17 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <FQS4AHQZ>; Fri, 26 Feb 1999 10:26:16 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D0F@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
Date: Fri, 26 Feb 1999 10:30:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Delete, Move, and Copy for References (Yaron's Issue #9)

I think that Yaron, Geoff, and I are all in agreement about everything
except the default behavior of COPY.  Let me summarize what the advanced
collections design team has done:

For all methods, we try to choose the default behavior to be what is
intuitively right for down-level clients, since they have access *only* to
the default behavior.  Other considerations can override this one, but we
always give heavy weight to the rule of least surprise for down-level
clients.

Reference-aware clients can always override the default behavior.  If the
default behavior is to pass the method through to the target (automatically
for direct references, via a 302 for redirect references), a reference-aware
client can use the No-Passthrough header to apply it to the reference
instead.  If the default behavior is to apply the method to the reference,
the reference-aware client can look up the value of the DAV:reftarget
property on the reference, and send the request to that target instead.

For DELETE and MOVE, the default behavior is to apply the method to the
reference rather than to its target.  This is true both for direct
references and for redirect references.  Reference-aware clients can force
these methods to apply to the target by looking up the value of
DAV:reftarget and sending the request to the target.  I think we all agree
that this is right, though maybe not all for the same reasons.

Now, what about COPY?  The spec says that the default behavior for direct
references is to apply the method to the target.  I think we all agree that
this is right.  What a down-level client expects is to end up with an
independent resource that can be modified without affecting the original --
COPY would have to be applied to the target to get this result.

For COPY on redirect references, I think Yaron likes what the spec currently
says: that the COPY request applies by default to the redirect reference, so
that there will be no 302.  This is a point where I think the spec is wrong
(and I think Geoff agrees with me).

What behavior is surprising for any method is the same for direct and
redirect references.  In the case of COPY, it is surprising if you think you
have created an independent resource, and it turns out that when you modify
that resource you have also modified the original that it was copied from.
This is true whether you used a direct reference or a redirect reference to
access it.  Getting a 302 response to a COPY request is not in itself
surprising -- it just looks to the down-level client as if the resource it
is trying to copy has been temporarily moved, and it still makes sense to
ask the user whether he wants to copy that resource.  The answer will almost
certainly be "Yes".

I don't quite get Geoff's comment that "The client needs to be warned that
there really will *not* be a copy made," since I thought the position we
were both supporting is that there *will* really be a copy made, both for
direct references and for redirect references.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 11:45:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA11278
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 11:45:53 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA11718
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 11:45:51 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id LAA00848;
	Fri, 26 Feb 1999 11:45:47 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <FQS4A2VK>; Fri, 26 Feb 1999 11:45:46 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D10@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, w3c-dist-auth@w3.org
Date: Fri, 26 Feb 1999 11:50:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Locking a Resource or Locking a URL?

I really think it's a mistake to understand the question whether a LOCK
locks just the reference or just the target or both as a question about
whether it's a resource or a URI or both getting locked.

A reference is a resource, as is its target.  They are just two different
resources.  The issue the design team was addressing was which resource(s)
get(s) locked when you send a LOCK request with a request-URI that
identifies a reference.

I think the design team agreed that the most intuitive behavior in this case
would be for both the reference resource and the target resource to be
locked.  The design team let some other consistency considerations over-ride
the law of least surprise in this case.  We ended up with the position that
for redirect references, just the reference gets locked; and for direct
references, just the target gets locked.

----------

I want to say that Geoff's examples are not really relevant to this
question.

We never explicitly addressed the question what happens if you submit a LOCK
request with a request-URI that has buried in it somewhere a segment that
identifies a reference.  This is a different case, and I don't think it is
relevant to the question whether, if the request-URI as a whole identifies a
reference, the reference or the target or both should get locked.

Here's an example.  We have URI /x/y/z.html.  Suppose /x/ identifies a
reference, whose target is collection /a/.  Suppose /x/y/z.html also
identifes a reference, whose target is /a/y/c.html.  It's like this:

/x/ references collection /a/
/a/ contains collection y/
y/ contains reference z.html
z.html references ordinary resource c.html

I think Geoff is arguing that neither the reference /x/ nor its target /a/
gets locked.  That's fine.  It makes perfectly good sense to say that
neither /x/ nor /a/ gets locked, but both /x/y/z.html and /a/y/c.html do get
locked.  (Or, as the spec currently says for direct references, the only
thing that gets locked is /a/y/c.html.)

In Goeff's example, /x/y/z.html is *not* a reference, so the collections
spec has nothing to say about it.  But /x/ is a reference, so we can
perfectly well say that when a LOCK request is submitted on /x/y/z.html,
neither the reference identified by /x/ nor its target (identified by /a/)
gets locked.

--Judy

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 11:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Locking a Resource or Locking a URL?
> 
> 
> 
> One of the key topics in the recent thread on the Adv. 
> Versioning Collection
> protocol was the question of what gets locked when you lock a 
> resource.
> 
> There are (at least :-) three interpretations:
> 
> (1) You are locking only the resource.
> 
> (2) You are locking what appears at a given URL (i.e. if the resource
> currently selected at that URL also appears at another URL, then the
> lock does not apply to accesses through that other URL).
> 
> (3) You are locking both the resource and the fact that the resource
> appears at the given URL.
> 
> In my message in the Adv. Coll. thread, I gave arguments for why
> (3) does not work in the context of references and versioning.
> 
> In this message, I would like to confirm that nobody believes that
> (2) is the correct interpretation.  In particular, I would like to
> confirm that if /a/x.html and /b/y.html happen to be the same resource
> (by some quirk of the server, say), and /a/x.html is locked, then
> a PUT to /b/y.html would fail without the appropriate lock token.
> 
> There also is the question of whether lock discovery would detect this
> implicit lock on /b/y.html.  This question has two parts ... what do
> you think the spec currently says, and what did the spec authors
> intend?
> 
> Cheers,
> Geoff
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 12:22:50 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12099
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 12:22:50 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id MAA12203
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 12:22:48 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <52645(2)>; Fri, 26 Feb 1999 09:22:42 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147483>; Fri, 26 Feb 1999 09:22:33 PST
Message-Id: <3.0.3.32.19990226092124.00961100@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Feb 1999 09:21:24 PST
To: w3c-dist-auth@w3.org
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F97@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Locking a Resource or Locking a URL?

At 10:34 PM 2/25/99 PST, Yaron Goland wrote:
>O.k. I'm completely lost. Let's try this again.
>
>I have a resource which is available through two names, http://foo/bar and
>http://iggy/pop. Someone requests and receives an exclusive write lock
>against http://foo/bar. I assert that the immediate consequence is that
>http://iggy/pop is ALSO write locked by the same principal.

Yaron, this is a really great question because it exposes an underlying
conceptual unclarity [*] that has been plaguing our discussion for months.

Is a direct reference 
 1. a *synonym* for the resource it points to, or
 2. a *resource* (albeit one whose semantics are defined so as to make it
act, in almost all cases, like a synonym.)

When you write about "two names [for the same resource]", you're using the
"synonym" metaphor, and I think this is why you are lost. 

For most operations, there's no difference between these two.  They act the
same.  But the locking discussion exposes one such difference, so now we
have to decide.

If a reference is a synonym, then it just makes no sense to speak of a lock
on the "reference" that is not on the "target".   They are just different
names for the same thing.   If a reference is a resource, then it at least
makes sense to speak of distinct locks.  It may or may not be the *right*
design choice, but at least one can talk about it.

I think our discussion to date has mostly, but not entirely, been based on
the assumption that a reference is in fact a second resource.  But it's
never been clearly settled.  But note, for instance, the discussion on your
issue #5, proposing a complex value for the DAV:resourcetype property of
the reference.  If a reference were merely a synonym, this wouldn't make
sense.

If a reference is in fact a distinct resource from the target, then it's
possibe, at least in principle, to have different locks on the reference
and on the target.  You could decide that the protocol should be such that
a lock on the reference always must also lock the target, and/or that a
lock on the target must also lock (all) references to it.  These are at
least conceptually separable design choices.

If you want to push on the "synonym" interpretation, then there is a second
issue that arises, but I won't go into it now.  

[*] One can trace this unclarity back to some old problems in philosophy of
language.  Is "the morning star" the same object as "the evening star"?  Is
"the president of the united states" the same person as "Bill Clinton"?
How fortunate we are that the design team is led by one actually trained as
a true philosopher.  You may think WebDAV had to face some ratholes, but I
tell you that Wittgenstein is to these rats as Moby Dick is to a trout.

trying to swim

Jim


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 12:30:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12188
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 12:30:50 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA12276
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 12:30:49 -0500 (EST)
Received: from tantalum by gw.atria.com id <MAA16615@gw.atria.com> Fri, 26 Feb 1999 12:30:49 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA07312; Fri, 26 Feb 1999 12:30:47 -0500
Date: Fri, 26 Feb 1999 12:30:47 -0500
Message-Id: <9902261730.AA07312@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F97@RED-MSG-59> (message
	from Yaron Goland on Thu, 25 Feb 1999 22:34:47 -0800)
Subject: Re: Locking a Resource or Locking a URL?

   From: Yaron Goland <yarong@microsoft.com>

   O.k. I'm completely lost. Let's try this again.

   I have a resource which is available through two names, http://foo/bar and
   http://iggy/pop. Someone requests and receives an exclusive write lock
   against http://foo/bar. I assert that the immediate consequence is that
   http://iggy/pop is ALSO write locked by the same principal.

Good, this means we can rule out #2 as being clearly wrong.
I believe we also agree that #1 is true (after all, that's what
the spec says).

So all that's left (and that was the actual intent of this thread),
is to determine if it is legal for an RFC-2518 compliant server to allow
a *different* resource to appear at http://foo/bar after a
"LOCK http://foo/bar" request has been issued.

I believe the answer is "yes", since RFC-2518 only talks about
what it means when a resource is locked, so if a server associates
a different (unlocked) resource with a URL (or if some extended protocol
allows a client to associate a different resource with a URL),
then this does not violate locking behavior as defined in
RFC-2518.

Another way of phrasing this is that the URL(s) currently used
to reference a resource are *not* a property or attribute of the
resource, so changing the URL that is used to reference a resource
does *not* violate any locks that might be on that resource.

Both references and versioning introduce mechanisms for the client
to explicitly modify the association of a specific resource with
a specific URL, and I believe this subtlety is at the heart of
our disconnect on advanced collection locking.

Yaron: We may need to add this to our "Minneapolis Poolside Agenda"
if email isn't cutting it (and yes, I *always* bring my cool markers
to IETF conferences :-).

Cheers,
Geoff

   > -----Original Message-----
   > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   > 
   > ...  the question of what gets locked when you lock a resource.
   > 
   > There are (at least :-) three interpretations:
   > 
   > (1) You are locking only the resource.
   > 
   > (2) You are locking what appears at a given URL (i.e. if 
   > the resource
   > currently selected at that URL also appears at another 
   > URL, then the
   > lock does not apply to accesses through that other URL).
   >
   > (3) You are locking both the resource and the fact that 
   > the resource appears at the given URL.
   > 
   > ...
   > In this message, I would like to confirm that nobody 
   > believes that
   > (2) is the correct interpretation.  In particular, I 
   > would like to
   > confirm that if /a/x.html and /b/y.html happen to be the 
   > same resource
   > (by some quirk of the server, say), and /a/x.html is locked, then
   > a PUT to /b/y.html would fail without the appropriate lock token.



From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 12:52:09 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12885
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 12:52:08 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA12576
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 12:52:06 -0500 (EST)
Received: from tantalum by gw.atria.com id <MAA18667@gw.atria.com> Fri, 26 Feb 1999 12:52:06 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA07329; Fri, 26 Feb 1999 12:52:04 -0500
Date: Fri, 26 Feb 1999 12:52:04 -0500
Message-Id: <9902261752.AA07329@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: JSlein@crt.xerox.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: 
	<201BB34B3A73D1118C1F00805F1582E801BA4D0F@x-wb-0128-nt8.wrc.xerox.com>
	(JSlein@crt.xerox.com)
Subject: Re: Delete, Move, and Copy for References (Yaron's Issue #9)


   From: "Slein, Judith A" <JSlein@crt.xerox.com>

   <...>

I agree with everything Judy said up to here, but cut it out for brevity.

   I don't quite get Geoff's comment that "The client needs to be warned that
   there really will *not* be a copy made," since I thought the position we
   were both supporting is that there *will* really be a copy made, both for
   direct references and for redirect references.

(This was a comment on invoking a COPY on a redirect reference.)

For a redirect reference COPY, you could either return the 302 and not do
anything (letting the client decide whether to do a "no-passthrough
copy" or copy the target explicitly), or you could return the 302
*and* actually do a "no-passthrough copy.

I slightly prefer the former (since normally a "302" means that the
operation did not happen, right?), but either one is fine with me.

Cheers,
Geoff
	


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:04:14 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13097
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:04:14 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA12690
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:04:13 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <54556(2)>; Fri, 26 Feb 1999 10:04:07 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147468>; Fri, 26 Feb 1999 10:04:05 PST
Message-Id: <3.0.3.32.19990226100330.0097fba0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Feb 1999 10:03:30 PST
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F59@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Issue #5: compound DAV:resourcetype property for references.

At 03:07 PM 2/22/99 PST, Yaron Goland wrote:

[Yaron sent one large message with many issues, but I think it will help to
address each one in a separate message.  Indeed, all things being equal, I
would request all those who comment to keep to one issue per message,
otherwise the messages get quite lengthy, and the threads become tangled.
but I am very grateful for the comments, and given a choice between one
omnibus message and silence, I must prefer the big one.  thanks YG]

>> > (Issue #5) Section 4.3.1 - ... 
>> > DAV:reftarget, DAV:reftype
>> > and DAV:refintegrity ...  
>> >  values [should be] 
>> > included inside the DAV:reference element in the 
>> > DAV:resourcetype property?

I agree with Yaron, at least for reftype and refintegrity.

An example
<dav:resourcetype>
  <dav:reference>
   <dav:reftype><dav:direct/></dav:reftype>
   <dav:refintegrity/>
  </dav:reference>
</dav:resourcetype>

but as for the reftarget, my intuition says it does not part of the "type".
 if I have two different references, with different targets, but otherwise
the same (both are direct references with no integrity) then they should be
exactly the same "resourcetype".

Judy's rebuttal (that DASL oesn't (yet) support searches on structured
properties) is best answered by saying that that is a problem (perhaps) for
DASL.   The DASL team choose (wisely, I think) to postpone addressing this,
but this is no reason that all of WebDAV must forever be restricted in
design choices.



From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:07:39 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13149
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:07:39 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA12712
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:07:38 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <54560(3)>; Fri, 26 Feb 1999 10:07:28 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147470>; Fri, 26 Feb 1999 10:07:20 PST
Message-Id: <3.0.3.32.19990226100713.009807e0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Feb 1999 10:07:13 PST
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F4A@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Issue #4: ref-integrity interoperabilityu

At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
>(Issue #4) Section 4.3.1 - ... I propose that the Ref-Integrity header
MUST be included in
>all requests and that the only defined value be DAV:do-not-enforce. A server
>receiving this header with an unrecognized value MUST fail the request. 

I agree.

No need to repeat his reasoning.



From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:38:54 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13670
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:38:54 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA13052
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:38:52 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <52252(2)>; Fri, 26 Feb 1999 10:38:47 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147488>; Fri, 26 Feb 1999 10:38:44 PST
Message-Id: <3.0.3.32.19990226103824.009802d0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Feb 1999 10:38:24 PST
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792F4A@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Issue #2 Definition of the term Referential Resource

At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
>
>(Issue #2) Section 2- Definition of the term Referential Resource - It
>should be explicitly pointed out that this is a new resource type. I think
>this would make the definition clearer.

Good idea

>	The term "body" as used in RFC 2068 and 2518 refer exclusively to
>messages, not resources. Hence the phrase "body of its own" does not have a
>definition in either spec.

I agree.

> First off, I think
>we need to cease viewing direct references and redirect references as
>children of the same mother. They are two very different creatures with
>largely unrelated functionality. It would probably be in everyone's interest
>if they were given names which shared no common words.

I am afraid I don't agree, and you are wrong to assume that our inspiration
comes from file system links.  Indeed, I was more inspired by the ability
of some Web servers to define aliases by means of suitable statements in
their configuration files.  The purpose of MKREF is to allow ordinary web
clients to cause such behavior without having to be superuser on the web
server.

>From the standpoint of a human using a web client, there's no important
difference in behavior between
 GET foo.html
 GET direct-to-foo.html
 GET redirect-to-foo.html

In all three cases, the human ends up seeing the contents of the resource
foo.html  (in the third case, the client app processes the 302 automatically).

We have direct references because that's (I claim) what most applications
want. We have redirect references because in the most general case,
implementing direct references is either expensive or opens security problems.

these are differences in the mechanism by which the desired end is
achieved, not differences in the ends.  We should follow good CS practice,
and identify these abstractions by their intended purpose, not the
mechanism by which such purpose is realized.

[PS thanks for all the thoughtful comments.  I have thus far only answered
the easy ones.  more on Monday.]


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:50:42 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA14075
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:50:42 -0500 (EST)
Received: from web604.mail.yahoo.com (web604.mail.yahoo.com [128.11.68.168])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA13195
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:50:39 -0500 (EST)
Message-ID: <19990226185147.22121.rocketmail@web604.mail.yahoo.com>
Received: from [209.102.20.221] by web604.mail.yahoo.com; Fri, 26 Feb 1999 10:51:47 PST
Date: Fri, 26 Feb 1999 10:51:47 -0800 (PST)
>From: Imran Khan <imrank123@yahoo.com>
To: w3c-dist-auth@w3.org, www-webdav-dasl@w3.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Why is DASL restricted to SELECT query or no conditional PROPPATCH...

Hi,
I am confused because of SEARCH, PROPFIND and PROPPATCH and find
myself in a situation where everything I see almost seems to solve the
problem but never completely does.

My goal is to be able to do conditional PROPFIND and PROPPATCH not
based on some If: header stuff but based on some property values etc.
I see that SEARCH is basically PROPFIND with filter, so I guess I
don't need to use PROPFIND anymore, am I right?

Now looking at DASL draft it seems like it supports only SELECT....,
and not the whole gamut of SQL stuff like UPDATE...WHERE or
INSERT...WHERE etc. My point is that why was PROPFIND and PROPPATCH
not retrofitted with SQL search syntax (could be XML-based). To me
extending SEARCH method with INSERT, UPDATE etc doesn't seem to be
right thing because as it says SEARCH seems mean read-only.

I guess I could always some kind of XML-based filter syntax to
PROPFIND, but just out of curiosity I was wondering why this didn't
come up? Am I missing something here.

Thanks,
Imran





_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:52:58 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA14425
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:52:58 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA13273
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:52:56 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FWQMQBSQ>; Fri, 26 Feb 1999 10:52:55 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792F9F@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 26 Feb 1999 10:52:48 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Issue #2 Definition of the term Referential Resource

RFCs are not written for users.
RFCs are not written for academics.
RFCs are written for implementers.

While I agree that from an academic point of view there is no difference
between direct and indirect references the RFC isn't interested in the
academic point of view. It is strictly interested in good implementation and
the implementation here is crystal clear, 3xx. We need to make that
absolutely clear. Any other distinction makes for a good article in the
Journal of the ACM, not an IETF RFC.

	I'm looking out for the implementers here,

			Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 10:38 AM
> To: WEBDAV WG
> Subject: Re: Issue #2 Definition of the term Referential Resource
> 
> 
> At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> >
> >(Issue #2) Section 2- Definition of the term Referential 
> Resource - It
> >should be explicitly pointed out that this is a new resource 
> type. I think
> >this would make the definition clearer.
> 
> Good idea
> 
> >	The term "body" as used in RFC 2068 and 2518 refer 
> exclusively to
> >messages, not resources. Hence the phrase "body of its own" 
> does not have a
> >definition in either spec.
> 
> I agree.
> 
> > First off, I think
> >we need to cease viewing direct references and redirect references as
> >children of the same mother. They are two very different 
> creatures with
> >largely unrelated functionality. It would probably be in 
> everyone's interest
> >if they were given names which shared no common words.
> 
> I am afraid I don't agree, and you are wrong to assume that 
> our inspiration
> comes from file system links.  Indeed, I was more inspired by 
> the ability
> of some Web servers to define aliases by means of suitable 
> statements in
> their configuration files.  The purpose of MKREF is to allow 
> ordinary web
> clients to cause such behavior without having to be superuser 
> on the web
> server.
> 
> From the standpoint of a human using a web client, there's no 
> important
> difference in behavior between
>  GET foo.html
>  GET direct-to-foo.html
>  GET redirect-to-foo.html
> 
> In all three cases, the human ends up seeing the contents of 
> the resource
> foo.html  (in the third case, the client app processes the 
> 302 automatically).
> 
> We have direct references because that's (I claim) what most 
> applications
> want. We have redirect references because in the most general case,
> implementing direct references is either expensive or opens 
> security problems.
> 
> these are differences in the mechanism by which the desired end is
> achieved, not differences in the ends.  We should follow good 
> CS practice,
> and identify these abstractions by their intended purpose, not the
> mechanism by which such purpose is realized.
> 
> [PS thanks for all the thoughtful comments.  I have thus far 
> only answered
> the easy ones.  more on Monday.]
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 13:55:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA14552
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 13:55:15 -0500 (EST)
Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA13305
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:55:14 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id NAA27324
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 13:55:12 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <FWX4HXXD>; Fri, 26 Feb 1999 13:59:40 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D11@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "Davis, Jim <jdavis@parc.xerox.com>" <jdavis@parc.xerox.com>,
        WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 26 Feb 1999 13:59:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Issue #4: ref-integrity interoperabilityu

I'd like to emphasize again that this choice would make it for all practical
purposes impossible for a client to create a reference except with
Ref-Integrity: do-not-enforce.  The only references that can really be
created would be ones for which the server promises *not* to enforce
referential integrity.  That seems to me unacceptable.  

I would be willing to go along with this *only if* we provide some way for
the client to discover what other values of Ref-Integrity a given server
understands.  We could do that with OPTIONS.  Then, even if the client
doesn't understand what the acceptable values mean, it can just pick an
arbitrary one if it wants referential integrity enforced, assuming that
every value the server advertises will be some flavor of enforcing
referential integrity.  I think the most common case will be that the server
offers only one policy for enforcing referential integrity.

Then we can still hope that in the long run a common set of referential
integrity policies will emerge and be standardized, but in the short run
clients will be able to request referential integrity if they want it.  And
it will be possible for compliant servers to insist on enforcing referential
integrity.

--Judy

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 1:07 PM
> To: WEBDAV WG
> Subject: Re: Issue #4: ref-integrity interoperabilityu
> 
> 
> At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> >(Issue #4) Section 4.3.1 - ... I propose that the 
> Ref-Integrity header
> MUST be included in
> >all requests and that the only defined value be 
> DAV:do-not-enforce. A server
> >receiving this header with an unrecognized value MUST fail 
> the request. 
> 
> I agree.
> 
> No need to repeat his reasoning.
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 14:13:38 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15239
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 14:13:38 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13512
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 14:13:37 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FWQMQ1D3>; Fri, 26 Feb 1999 11:13:36 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA0@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 26 Feb 1999 11:13:26 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Issue #5: compound DAV:resourcetype property for references.

Hum.... Jim's argument definitely gives me food for thought.

Let's look at this from an implementation point of view:

A reference resource type isn't something you can just layer on top of an
existing resource. You need to take over ALL the methods so as to make sure
you do the right thing in forwarding/not-forwarding. In the case of ISAPI,
however, it is possible to register DLLs in order. Thus I could imagine
implementing a reference by having the reference DLL go first and if the
message is a no-passthrough then letting it continue to the underlying
implementation of features such as PROPPATCH. Either way the DLL
implementing the reference is going to have to have some relationship with
the property system (either because it implements its own or re-uses someone
else's) so it can set properties.

So in terms of implementing a reference there doesn't seem to be a big
difference between putting reftarget in resourcetype and putting reftarget
in its own property.

For the purposes of search the question becomes more interesting. I would
really like resourcetype to be one stop shopping for a complete description
of the resource's type. Thus it is likely to be filled with lots of stuff.
Hence the hope that two resources with the same reftype and refintegrity
will have the same resourcetype is probably unrealistic. Who knows what
other information will be in there. Search mechanisms will have to be able
to just pick out the parts of the resourcetype that they are interested in.
Thus putting reftarget into resourcetype doesn't seem to have any downside
from a search point of view.

I suspect the main reason that I really dislike having reftarget as its own
property is that some brilliant person will come up with the astoundingly
original suggestion that one can change the reftarget by doing a PROPPATCH
on the reftarget property. For reasons I have beat to death in the WebDAV
Book of Why
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html) I
think this is a bad idea. Hence I sleep better at night knowing that
reftarget is inside of a read only property, resourcetype.

But, unfortunately, you can't ban idiots. If they can do something stupid,
they will do something stupid. So it would appear that in the end this is
really just a matter of esthetics. Which sounds like a coin flip and coin
flips should always go to the authors.

			Yaron


> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 10:04 AM
> To: WEBDAV WG
> Subject: Issue #5: compound DAV:resourcetype property for references.
> 
> 
> At 03:07 PM 2/22/99 PST, Yaron Goland wrote:
> 
> [Yaron sent one large message with many issues, but I think 
> it will help to
> address each one in a separate message.  Indeed, all things 
> being equal, I
> would request all those who comment to keep to one issue per message,
> otherwise the messages get quite lengthy, and the threads 
> become tangled.
> but I am very grateful for the comments, and given a choice 
> between one
> omnibus message and silence, I must prefer the big one.  thanks YG]
> 
> >> > (Issue #5) Section 4.3.1 - ... 
> >> > DAV:reftarget, DAV:reftype
> >> > and DAV:refintegrity ...  
> >> >  values [should be] 
> >> > included inside the DAV:reference element in the 
> >> > DAV:resourcetype property?
> 
> I agree with Yaron, at least for reftype and refintegrity.
> 
> An example
> <dav:resourcetype>
>   <dav:reference>
>    <dav:reftype><dav:direct/></dav:reftype>
>    <dav:refintegrity/>
>   </dav:reference>
> </dav:resourcetype>
> 
> but as for the reftarget, my intuition says it does not part 
> of the "type".
>  if I have two different references, with different targets, 
> but otherwise
> the same (both are direct references with no integrity) then 
> they should be
> exactly the same "resourcetype".
> 
> Judy's rebuttal (that DASL oesn't (yet) support searches on structured
> properties) is best answered by saying that that is a problem 
> (perhaps) for
> DASL.   The DASL team choose (wisely, I think) to postpone 
> addressing this,
> but this is no reason that all of WebDAV must forever be restricted in
> design choices.
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 14:23:49 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15482
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 14:23:49 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13619
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 14:23:47 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FWHGCT3X>; Fri, 26 Feb 1999 11:23:48 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA1@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "Davis, Jim <jdavis@parc.xerox.com>" <jdavis@parc.xerox.com>,
        WEBDAV WG
	 <w3c-dist-auth@w3.org>
Date: Fri, 26 Feb 1999 11:23:45 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Issue #4: ref-integrity interoperabilityu

I will go you one better. Not only should the client be able to discover
what types of referential integrity the server supports but the answer
should be properly scoped with the class of integrity. For example:

<d:supportedtypes>
	<d:referencetype>
	
<d:referencetypename><m:xeroxintegrity/></d:referencetypename>
		<d:enforced/>
	</d:referencetype>
</d:supportedtypes>

The client will only understand the "d" scoped elements. So the client knows
that the reference uses some sort of referential integrity which is
identified by the m:xeroxintegrity element but has no idea what the actual
policy is. The client is then free to submit the URL which matches
m:xeroxintegrity as an argument to the Ref-Integrity header when creating
the reference.

In this case the client is choosing to intentionally enter a
non-interoperable situation. That is always their right. But the protocol
must be written so that entering this situation is a clear and obvious
action. I believe that requiring the client to parse supportedtypes,
referencetype, pull out the name from referentypename and match it to
enforced more than adequately demonstrates that the client really wants to
shoot itself in the head.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Friday, February 26, 1999 11:00 AM
> To: Davis, Jim <jdavis@parc.xerox.com>; WEBDAV WG
> Subject: RE: Issue #4: ref-integrity interoperabilityu
> 
> 
> I'd like to emphasize again that this choice would make it 
> for all practical
> purposes impossible for a client to create a reference except with
> Ref-Integrity: do-not-enforce.  The only references that can really be
> created would be ones for which the server promises *not* to enforce
> referential integrity.  That seems to me unacceptable.  
> 
> I would be willing to go along with this *only if* we provide 
> some way for
> the client to discover what other values of Ref-Integrity a 
> given server
> understands.  We could do that with OPTIONS.  Then, even if the client
> doesn't understand what the acceptable values mean, it can 
> just pick an
> arbitrary one if it wants referential integrity enforced, 
> assuming that
> every value the server advertises will be some flavor of enforcing
> referential integrity.  I think the most common case will be 
> that the server
> offers only one policy for enforcing referential integrity.
> 
> Then we can still hope that in the long run a common set of 
> referential
> integrity policies will emerge and be standardized, but in 
> the short run
> clients will be able to request referential integrity if they 
> want it.  And
> it will be possible for compliant servers to insist on 
> enforcing referential
> integrity.
> 
> --Judy
> 
> > -----Original Message-----
> > From: Jim Davis [mailto:jdavis@parc.xerox.com]
> > Sent: Friday, February 26, 1999 1:07 PM
> > To: WEBDAV WG
> > Subject: Re: Issue #4: ref-integrity interoperabilityu
> > 
> > 
> > At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> > >(Issue #4) Section 4.3.1 - ... I propose that the 
> > Ref-Integrity header
> > MUST be included in
> > >all requests and that the only defined value be 
> > DAV:do-not-enforce. A server
> > >receiving this header with an unrecognized value MUST fail 
> > the request. 
> > 
> > I agree.
> > 
> > No need to repeat his reasoning.
> > 
> > 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 14:55:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16375
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 14:55:22 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13979
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 14:55:21 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FWQMQJQ5>; Fri, 26 Feb 1999 11:55:20 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA2@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, JSlein@crt.xerox.com
Cc: w3c-dist-auth@w3.org
Date: Fri, 26 Feb 1999 11:55:10 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Delete, Move, and Copy for References (Yaron's Issue #9)

What really scares me is a scenario where I have a directory filled with
references but I'm using an RFC 2518 client. If I copy the directory I will
go from a directory that took up a few kilobytes (just to record the
references) to one of any random and potentially huge size. The source
directory ate 30Kb and the destination eats up 6 Gig. I would call that
surprising.

I would also invoke precedent here. In every system I have ever heard of
that supports references (read: links) a COPY always copies the link not the
destination. I would be very hesitant to go against three decades of
accumulated experience without a good reason.

Hence I believe that the default action should be no-passthrough on COPY.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, February 26, 1999 9:52 AM
> To: JSlein@crt.xerox.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Delete, Move, and Copy for References (Yaron's Issue #9)
> 
> 
> 
>    From: "Slein, Judith A" <JSlein@crt.xerox.com>
> 
>    <...>
> 
> I agree with everything Judy said up to here, but cut it out 
> for brevity.
> 
>    I don't quite get Geoff's comment that "The client needs 
> to be warned that
>    there really will *not* be a copy made," since I thought 
> the position we
>    were both supporting is that there *will* really be a copy 
> made, both for
>    direct references and for redirect references.
> 
> (This was a comment on invoking a COPY on a redirect reference.)
> 
> For a redirect reference COPY, you could either return the 
> 302 and not do
> anything (letting the client decide whether to do a "no-passthrough
> copy" or copy the target explicitly), or you could return the 302
> *and* actually do a "no-passthrough copy.
> 
> I slightly prefer the former (since normally a "302" means that the
> operation did not happen, right?), but either one is fine with me.
> 
> Cheers,
> Geoff
> 	
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 14:55:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16421
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 14:55:53 -0500 (EST)
Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13985
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 14:55:51 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id OAA20295;
	Fri, 26 Feb 1999 14:55:50 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <FWX4HYGT>; Fri, 26 Feb 1999 15:00:09 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D12@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@microsoft.com>,
        "Slein, Judith A"
	 <JSlein@crt.xerox.com>,
        "Davis, Jim <jdavis@parc.xerox.com>"
	 <jdavis@parc.xerox.com>,
        WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 26 Feb 1999 15:00:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Issue #4: ref-integrity interoperabilityu

I like it.

--Judy

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Friday, February 26, 1999 2:24 PM
> To: 'Slein, Judith A'; Davis, Jim <jdavis@parc.xerox.com>; WEBDAV WG
> Subject: RE: Issue #4: ref-integrity interoperabilityu
> 
> 
> I will go you one better. Not only should the client be able 
> to discover
> what types of referential integrity the server supports but the answer
> should be properly scoped with the class of integrity. For example:
> 
> <d:supportedtypes>
> 	<d:referencetype>
> 	
> <d:referencetypename><m:xeroxintegrity/></d:referencetypename>
> 		<d:enforced/>
> 	</d:referencetype>
> </d:supportedtypes>
> 
> The client will only understand the "d" scoped elements. So 
> the client knows
> that the reference uses some sort of referential integrity which is
> identified by the m:xeroxintegrity element but has no idea 
> what the actual
> policy is. The client is then free to submit the URL which matches
> m:xeroxintegrity as an argument to the Ref-Integrity header 
> when creating
> the reference.
> 
> In this case the client is choosing to intentionally enter a
> non-interoperable situation. That is always their right. But 
> the protocol
> must be written so that entering this situation is a clear and obvious
> action. I believe that requiring the client to parse supportedtypes,
> referencetype, pull out the name from referentypename and match it to
> enforced more than adequately demonstrates that the client 
> really wants to
> shoot itself in the head.
> 
> 			Yaron
> 
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Friday, February 26, 1999 11:00 AM
> > To: Davis, Jim <jdavis@parc.xerox.com>; WEBDAV WG
> > Subject: RE: Issue #4: ref-integrity interoperabilityu
> > 
> > 
> > I'd like to emphasize again that this choice would make it 
> > for all practical
> > purposes impossible for a client to create a reference except with
> > Ref-Integrity: do-not-enforce.  The only references that 
> can really be
> > created would be ones for which the server promises *not* to enforce
> > referential integrity.  That seems to me unacceptable.  
> > 
> > I would be willing to go along with this *only if* we provide 
> > some way for
> > the client to discover what other values of Ref-Integrity a 
> > given server
> > understands.  We could do that with OPTIONS.  Then, even if 
> the client
> > doesn't understand what the acceptable values mean, it can 
> > just pick an
> > arbitrary one if it wants referential integrity enforced, 
> > assuming that
> > every value the server advertises will be some flavor of enforcing
> > referential integrity.  I think the most common case will be 
> > that the server
> > offers only one policy for enforcing referential integrity.
> > 
> > Then we can still hope that in the long run a common set of 
> > referential
> > integrity policies will emerge and be standardized, but in 
> > the short run
> > clients will be able to request referential integrity if they 
> > want it.  And
> > it will be possible for compliant servers to insist on 
> > enforcing referential
> > integrity.
> > 
> > --Judy
> > 
> > > -----Original Message-----
> > > From: Jim Davis [mailto:jdavis@parc.xerox.com]
> > > Sent: Friday, February 26, 1999 1:07 PM
> > > To: WEBDAV WG
> > > Subject: Re: Issue #4: ref-integrity interoperabilityu
> > > 
> > > 
> > > At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> > > >(Issue #4) Section 4.3.1 - ... I propose that the 
> > > Ref-Integrity header
> > > MUST be included in
> > > >all requests and that the only defined value be 
> > > DAV:do-not-enforce. A server
> > > >receiving this header with an unrecognized value MUST fail 
> > > the request. 
> > > 
> > > I agree.
> > > 
> > > No need to repeat his reasoning.
> > > 
> > > 
> > 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 15:22:44 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17135
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 15:22:43 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA14251
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 15:22:41 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <FWHQRGXA>; Fri, 26 Feb 1999 12:22:41 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA3@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: w3c-dist-auth@w3.org
Date: Fri, 26 Feb 1999 12:22:37 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Locking a Resource or Locking a URL?

RFC 2518 requires that a LOCK lock a resource. A reference is a resource. A
LOCK against a reference MUST lock the reference. The current spec states
that the default behavior for locks against direct references is to lock the
target and not the reference. This is a violation of RFC 2518.

Let us say, for the sake of argument, that the advanced collection spec was
changed such that the default behavior was to lock the reference and not the
target. This would seem to satisfy my previous point. However, I would still
argue that the advanced collection spec is non-compliant with RFC 2518. My
reasoning is as follows:

Meet my RFC 2518 compliant word processor. The user goes to the file open
dialog and types in the URL of a reference. The word processor proceeds to
take out a write LOCK on the reference and to GET its contents. The word
processor now assumes that the contents of the resource will not change as
long as the write LOCK is outstanding, RFC 2518 makes this assumption
completely legal. In reality, however, the word processor has only locked
the reference, not the target. Thus it is possible for two GET requests on
the resource to return different results even though a write LOCK is
outstanding. Thus the word processor's legal assumption that as long as the
write LOCK is outstanding the GET response won't change has been violated.

Thus it is a violation of RFC 2518 to have the default behavior of LOCKs on
references be to only lock the reference. The default behavior must be to
lock both the reference and the target.

Which brings us to redirect references. I suspect the only thing we can do
there is to have the default behavior be that the LOCK fails with a 302.
This is reasonable, especially in the case of collections, because RFC 2518
is crystal clear that a depth LOCK on a collection ATOMICALLY locks all its
contents. Clearly a redirect reference can not enforce the atomic
requirement so failure is the only option. However, once you send in a
no-passthrough header, all bets are off and you are free to just lock the
redirect reference.

				Yaron Y. Goland
				Commissioner
				WebDAV Police Department (WPD)

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, February 26, 1999 9:31 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Locking a Resource or Locking a URL?
> 
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    O.k. I'm completely lost. Let's try this again.
> 
>    I have a resource which is available through two names, 
> http://foo/bar and
>    http://iggy/pop. Someone requests and receives an 
> exclusive write lock
>    against http://foo/bar. I assert that the immediate 
> consequence is that
>    http://iggy/pop is ALSO write locked by the same principal.
> 
> Good, this means we can rule out #2 as being clearly wrong.
> I believe we also agree that #1 is true (after all, that's what
> the spec says).
> 
> So all that's left (and that was the actual intent of this thread),
> is to determine if it is legal for an RFC-2518 compliant 
> server to allow
> a *different* resource to appear at http://foo/bar after a
> "LOCK http://foo/bar" request has been issued.
> 
> I believe the answer is "yes", since RFC-2518 only talks about
> what it means when a resource is locked, so if a server associates
> a different (unlocked) resource with a URL (or if some 
> extended protocol
> allows a client to associate a different resource with a URL),
> then this does not violate locking behavior as defined in
> RFC-2518.
> 
> Another way of phrasing this is that the URL(s) currently used
> to reference a resource are *not* a property or attribute of the
> resource, so changing the URL that is used to reference a resource
> does *not* violate any locks that might be on that resource.
> 
> Both references and versioning introduce mechanisms for the client
> to explicitly modify the association of a specific resource with
> a specific URL, and I believe this subtlety is at the heart of
> our disconnect on advanced collection locking.
> 
> Yaron: We may need to add this to our "Minneapolis Poolside Agenda"
> if email isn't cutting it (and yes, I *always* bring my cool markers
> to IETF conferences :-).
> 
> Cheers,
> Geoff
> 
>    > -----Original Message-----
>    > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>    > 
>    > ...  the question of what gets locked when you lock a resource.
>    > 
>    > There are (at least :-) three interpretations:
>    > 
>    > (1) You are locking only the resource.
>    > 
>    > (2) You are locking what appears at a given URL (i.e. if 
>    > the resource
>    > currently selected at that URL also appears at another 
>    > URL, then the
>    > lock does not apply to accesses through that other URL).
>    >
>    > (3) You are locking both the resource and the fact that 
>    > the resource appears at the given URL.
>    > 
>    > ...
>    > In this message, I would like to confirm that nobody 
>    > believes that
>    > (2) is the correct interpretation.  In particular, I 
>    > would like to
>    > confirm that if /a/x.html and /b/y.html happen to be the 
>    > same resource
>    > (by some quirk of the server, say), and /a/x.html is locked, then
>    > a PUT to /b/y.html would fail without the appropriate lock token.
> 
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 15:25:49 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17200
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 15:25:48 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA14284
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 15:25:47 -0500 (EST)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0)
	id <FWHQRHAF>; Fri, 26 Feb 1999 12:25:47 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA4@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Date: Fri, 26 Feb 1999 12:25:39 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Locking a Resource or Locking a URL?

A reference is a resource. A target is a resource. A reference and its
target are two different resources.

The example below only applies to a resource with two names. It does not
necessarily apply to a reference and its target because these are two
separate resources.

However, because a reference masquerades as the target for down level
clients it is necessary to carefully control the reference's behavior in
order to ensure that down level client expectations are met. Please refer to
the thread on LOCK and references for an excellent example of where these
expectations can clash with reality.

		Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 9:21 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Locking a Resource or Locking a URL?
> 
> 
> At 10:34 PM 2/25/99 PST, Yaron Goland wrote:
> >O.k. I'm completely lost. Let's try this again.
> >
> >I have a resource which is available through two names, 
> http://foo/bar and
> >http://iggy/pop. Someone requests and receives an exclusive 
> write lock
> >against http://foo/bar. I assert that the immediate 
> consequence is that
> >http://iggy/pop is ALSO write locked by the same principal.
> 
> Yaron, this is a really great question because it exposes an 
> underlying
> conceptual unclarity [*] that has been plaguing our 
> discussion for months.
> 
> Is a direct reference 
>  1. a *synonym* for the resource it points to, or
>  2. a *resource* (albeit one whose semantics are defined so 
> as to make it
> act, in almost all cases, like a synonym.)
> 
> When you write about "two names [for the same resource]", 
> you're using the
> "synonym" metaphor, and I think this is why you are lost. 
> 
> For most operations, there's no difference between these two. 
>  They act the
> same.  But the locking discussion exposes one such 
> difference, so now we
> have to decide.
> 
> If a reference is a synonym, then it just makes no sense to 
> speak of a lock
> on the "reference" that is not on the "target".   They are 
> just different
> names for the same thing.   If a reference is a resource, 
> then it at least
> makes sense to speak of distinct locks.  It may or may not be 
> the *right*
> design choice, but at least one can talk about it.
> 
> I think our discussion to date has mostly, but not entirely, 
> been based on
> the assumption that a reference is in fact a second resource. 
>  But it's
> never been clearly settled.  But note, for instance, the 
> discussion on your
> issue #5, proposing a complex value for the DAV:resourcetype 
> property of
> the reference.  If a reference were merely a synonym, this 
> wouldn't make
> sense.
> 
> If a reference is in fact a distinct resource from the 
> target, then it's
> possibe, at least in principle, to have different locks on 
> the reference
> and on the target.  You could decide that the protocol should 
> be such that
> a lock on the reference always must also lock the target, 
> and/or that a
> lock on the target must also lock (all) references to it.  
> These are at
> least conceptually separable design choices.
> 
> If you want to push on the "synonym" interpretation, then 
> there is a second
> issue that arises, but I won't go into it now.  
> 
> [*] One can trace this unclarity back to some old problems in 
> philosophy of
> language.  Is "the morning star" the same object as "the 
> evening star"?  Is
> "the president of the united states" the same person as "Bill 
> Clinton"?
> How fortunate we are that the design team is led by one 
> actually trained as
> a true philosopher.  You may think WebDAV had to face some 
> ratholes, but I
> tell you that Wittgenstein is to these rats as Moby Dick is 
> to a trout.
> 
> trying to swim
> 
> Jim
> 


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 17:25:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA18943
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 17:25:15 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA15456;
	Fri, 26 Feb 1999 17:25:14 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <54738(1)>; Fri, 26 Feb 1999 14:25:04 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147486>; Fri, 26 Feb 1999 14:24:55 PST
Message-Id: <3.0.3.32.19990226142456.00995580@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Feb 1999 14:24:56 PST
To: Imran Khan <imrank123@yahoo.com>
>From: Jim Davis <jdavis@parc.xerox.com>
Cc: w3c-dist-auth@w3.org, www-webdav-dasl@w3.org
In-Reply-To: <19990226185147.22121.rocketmail@web604.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Why is DASL restricted to SELECT query or no conditional   PROPPATCH...

At 10:51 AM 2/26/99 PST, Imran Khan wrote:
>My goal is to be able to do conditional PROPFIND and PROPPATCH not
>... based on some property values etc. ... 
> looking at DASL draft it seems like it supports only SELECT....,
>and not the whole gamut of SQL stuff like UPDATE...WHERE or
>INSERT...WHERE etc. My point is that why was PROPFIND and PROPPATCH
>not retrofitted with SQL search syntax (could be XML-based). To me
>extending SEARCH method with INSERT, UPDATE etc doesn't seem to be
>right thing because as it says SEARCH seems mean read-only.

This is a very interesting and worthy goal, but I regret that it is not
likely to be supported by DASL.  The DASL effort was intended, from the
beginning, to address the problem of search only, not updates.  In general,
IETF working groups have to restrict the set of problems that they attempt
to address, or they can't make any progress at all.  When DASL was begun,
we chose to consider only search.

Please consult the charter for this working group,
http://www.ietf.org/html.charters/dasl-charter.html

At this point in the process, that charter has been set, and can't be
changed without a great deal of effort.  

If you'd think it is important that WebDAV provide means of doing
conditional PROPPATCH, you should probably start a discussion on the topic
on the webdav mailing list.  Perhaps you can convene an informal BOF at the
next IETF meeting (Minneapolis, March.)  Eventually you would issue
internet drafts stating the requirements for such functionality and a
proposed design meeting those requirements, and then form a working group
to address this.

I regret though that it is unlikely that DASL will be able to support your
desired functionality.

By the way, please don't be misled by the similar use of "select" in SQL
and DASL.  While this word and concept is similar in the two designs, there
are many differences in other areas. DASL is not intended to be a "SQL for
the Web".

best wishes.
Jim Davis


From w3c-dist-auth-request@www10.w3.org  Fri Feb 26 19:49:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA20471
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Feb 1999 19:49:27 -0500 (EST)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA16583
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 19:49:25 -0500 (EST)
>From: ccjason@us.ibm.com
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21])
	by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id TAA20136
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 19:49:07 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35])
	by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id TAA231640
	for <w3c-dist-auth@w3.org>; Fri, 26 Feb 1999 19:49:22 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256725.00048435 ; Fri, 26 Feb 1999 19:49:19 -0500
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256725.000483B0.00@D51MTA07.pok.ibm.com>
Date: Fri, 26 Feb 1999 19:51:57 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: Delete, Move, and Copy for References (Yaron's Issue #9)


Yaron writes...
> What really scares me is a scenario where I have a directory filled with
> references but I'm using an RFC 2518 client...

Good observation...


> I would also invoke precedent here. In every system I have ever heard of
> that supports references (read: links) a COPY always copies the link not
the
> destination. I would be very hesitant to go against three decades of
> accumulated experience without a good reason.

I philosophically agree and that this is this is the way that I'd want it
to work when I use it...


But the other folks seem to have a good point also.  Let me toss a
hand-grenade that way though.  Not expecting a modification of one resource
to affect another is a universal problem for down-level clients.
Regardless of COPY.  If someone builds up a site with a newer tool and
creates (direct) references... and if someone with an older tool starts
working on the site... the person with the older client is going to
experience aliasing... which he and his tool don't expect.  And if we
design the spec to avoid the aliasing for downlevel tools... the user will
unknowingly do (less dangerous, but still unsatisfactory) things like
turning references back into resources.     A person with this older tool
and older expectactions is going to make a mess of the site one way or
another... regardless of COPY.   And a person with an old client, but new
expectations, will quickly upgrade tools...

So I'm sort of supporting Yaron here...  but...

And I'm also suggesting that perhaps (I don't know) that some of our
"downlevel-client" arguments might be red-herrings.   It's something to
recheck.   ...and if not a red herrings... perhaps (shudder) we should take
the philosophy of limiting the operations that a downlevel client can
perform in the presence of references... rather than trying to guess at the
least dangerous or least inconsistant behavior.   As a site administrator,
that's REALLY what I'd want the server to do.

Jason.



From w3c-dist-auth-request@www10.w3.org  Sat Feb 27 09:20:52 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA28830
	for <w3c-dist-auth@www19.w3.org>; Sat, 27 Feb 1999 09:20:52 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id JAA20169
	for <w3c-dist-auth@w3.org>; Sat, 27 Feb 1999 09:20:51 -0500 (EST)
Received: from tantalum by gw.atria.com id <JAA06544@gw.atria.com> Sat, 27 Feb 1999 09:20:50 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA07794; Sat, 27 Feb 1999 09:20:48 -0500
Date: Sat, 27 Feb 1999 09:20:48 -0500
Message-Id: <9902271420.AA07794@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792FA2@RED-MSG-59> (message
	from Yaron Goland on Fri, 26 Feb 1999 11:55:10 -0800)
Subject: Re: Delete, Move, and Copy for References (Yaron's Issue #9)

   From: Yaron Goland <yarong@microsoft.com>

   What really scares me is a scenario where I have a directory filled with
   references but I'm using an RFC 2518 client. If I copy the directory I will
   go from a directory that took up a few kilobytes (just to record the
   references) to one of any random and potentially huge size. The source
   directory ate 30Kb and the destination eats up 6 Gig. I would call that
   surprising.

What really scares me is when I create a copy, and it turns out that it's
not really a copy, so every change I make to the copy trashes my original.
Apparently we're scared by different things.

   I would also invoke precedent here. In every system I have ever heard of
   that supports references (read: links) a COPY always copies the link not the
   destination. I would be very hesitant to go against three decades of
   accumulated experience without a good reason.

So you've never even *heard* of Unix?  If you're looking for decades of
experience with links, you might want to consider it.

Every Unix system I've ever used (and I've used *a lot*), copy by default
the target of both hard and soft links, not the link itself.  This is
try for both "cp" and "tar".

So I agree with your appeal to precedent, but I suggest you drew the
wrong conclusion.  Among the various reasons why the link target is
copied by default, is that any relative links outside of the
collection you are copying will break if you just copy the link
itself.  Converting the link to an absolute link to work around this
would be even worse.

   Hence I believe that the default action should be no-passthrough on COPY.

I could live with either one, but I'd be careful about going against
three decades of precedent that says otherwise (:-).

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Sat Feb 27 11:02:46 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA00005
	for <w3c-dist-auth@www19.w3.org>; Sat, 27 Feb 1999 11:02:46 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA20649
	for <w3c-dist-auth@w3.org>; Sat, 27 Feb 1999 11:02:45 -0500 (EST)
Received: from tantalum by gw.atria.com id <LAA09927@gw.atria.com> Sat, 27 Feb 1999 11:02:44 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA07848; Sat, 27 Feb 1999 11:02:42 -0500
Date: Sat, 27 Feb 1999 11:02:42 -0500
>From: gclemm@atria.com (Geoffrey M. Clemm)
Message-Id: <9902271602.AA07848@tantalum>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
Subject: RE: Delete, Move, and Copy for References (Yaron's Issue #9)

One more point on the "space of a COPY" issue.

When a downlevel client asks "what is the size of this GIF resource",
and the answer came back "20 bytes" (because the resource was actually
a direct reference to a GIF resource and the server is just telling
it how much space the reference takes), that downlevel client will
probably be a bit surprised when it allocates a read-buffer based on
this size answer, and then tries to GET that GIF file into a 20
byte buffer.

Similarly, if that client asks "how big is this collection of GIF
resources", and the answer comes back "200 bytes" (because it is just
10 references to GIF resources), the allocation of a 200 byte buffer
to store that GIF collection won't work much better.

So I will argue that a "size" query, like all other queries in the
context of references, should take a NO-PASSTHROUGH header (so an
uplevel client can ask for both flavors of "size"), but that the
default "size" query should be passed through to the targets, and then
a downlevel client would be surprised if Yaron's copy did not take 6 gig!

Cheers,
Geoff

> From: Yaron Goland <yarong@microsoft.com>
> 
> What really scares me is a scenario where I have a directory filled with
> references but I'm using an RFC 2518 client. If I copy the directory I will
> go from a directory that took up a few kilobytes (just to record the
> references) to one of any random and potentially huge size. The source
> directory ate 30Kb and the destination eats up 6 Gig. I would call that
> surprising.


From w3c-dist-auth-request@www10.w3.org  Sat Feb 27 13:10:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01085
	for <w3c-dist-auth@www19.w3.org>; Sat, 27 Feb 1999 13:10:51 -0500 (EST)
Received: from pump2.york.ac.uk (pump2.york.ac.uk [144.32.128.12])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA21143
	for <w3c-dist-auth@w3.org>; Sat, 27 Feb 1999 13:10:49 -0500 (EST)
Received: from tower.york.ac.uk (tower.york.ac.uk [144.32.128.102])
	by pump2.york.ac.uk (8.8.7/8.8.7) with SMTP id SAA18484
	for <w3c-dist-auth@w3.org>; Sat, 27 Feb 1999 18:10:48 GMT
Date: Sat, 27 Feb 1999 18:10:48 +0000 (GMT)
>From: Joe Orton <jeo101@york.ac.uk>
To: w3c-dist-auth@w3.org
Message-ID: <Pine.SOL.3.95L.990227180630.19049C-100000@tower.york.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: collections-03: Minor nitpicks


5.3.3, 5.5.4: Destination: takes absoluteURI, no <angle brackets> allowed? 

6.1: Coded-url is defined in [WebDAV] 9.4 not 8.4, and is called Coded-URL
if that matters.

Also, several places where Host: is in upper case (e.g. 4.3.3, 5.3.3)

joe

-- 
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/


From w3c-dist-auth-request@www10.w3.org  Sat Feb 27 20:00:32 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA03762
	for <w3c-dist-auth@www19.w3.org>; Sat, 27 Feb 1999 20:00:32 -0500 (EST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA22879
	for <w3c-dist-auth@w3.org>; Sat, 27 Feb 1999 20:00:31 -0500 (EST)
Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <FWRYTVXD>; Sat, 27 Feb 1999 17:00:30 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FAD@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: w3c-dist-auth@w3.org
Date: Sat, 27 Feb 1999 17:00:29 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Delete, Move, and Copy for References (Yaron's Issue #9)

That's what I get for working for MS too long. Lost all my UNIX skills.

Far from me to argue with precedent without a killer reason, pending new
revelations consider my objection to copies of direct references by RFC 2518
clients resulting in copying the target rather than the reference removed.

				Yaron


> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Saturday, February 27, 1999 6:21 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Delete, Move, and Copy for References (Yaron's Issue #9)
> 
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    What really scares me is a scenario where I have a 
> directory filled with
>    references but I'm using an RFC 2518 client. If I copy the 
> directory I will
>    go from a directory that took up a few kilobytes (just to 
> record the
>    references) to one of any random and potentially huge 
> size. The source
>    directory ate 30Kb and the destination eats up 6 Gig. I 
> would call that
>    surprising.
> 
> What really scares me is when I create a copy, and it turns 
> out that it's
> not really a copy, so every change I make to the copy trashes 
> my original.
> Apparently we're scared by different things.
> 
>    I would also invoke precedent here. In every system I have 
> ever heard of
>    that supports references (read: links) a COPY always 
> copies the link not the
>    destination. I would be very hesitant to go against three 
> decades of
>    accumulated experience without a good reason.
> 
> So you've never even *heard* of Unix?  If you're looking for 
> decades of
> experience with links, you might want to consider it.
> 
> Every Unix system I've ever used (and I've used *a lot*), 
> copy by default
> the target of both hard and soft links, not the link itself.  This is
> try for both "cp" and "tar".
> 
> So I agree with your appeal to precedent, but I suggest you drew the
> wrong conclusion.  Among the various reasons why the link target is
> copied by default, is that any relative links outside of the
> collection you are copying will break if you just copy the link
> itself.  Converting the link to an absolute link to work around this
> would be even worse.
> 
>    Hence I believe that the default action should be 
> no-passthrough on COPY.
> 
> I could live with either one, but I'd be careful about going against
> three decades of precedent that says otherwise (:-).
> 
> Cheers,
> Geoff
> 


From w3c-dist-auth-request@www10.w3.org  Sun Feb 28 07:16:52 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA08079
	for <w3c-dist-auth@www19.w3.org>; Sun, 28 Feb 1999 07:16:51 -0500 (EST)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id HAA25678
	for <w3c-dist-auth@w3.org>; Sun, 28 Feb 1999 07:16:50 -0500 (EST)
>From: jamsden@us.ibm.com
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id HAA19332;
	Sun, 28 Feb 1999 07:17:44 -0500
Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35])
	by southrelay01.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id HAA109896;
	Sun, 28 Feb 1999 07:16:45 -0500
Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256726.004373E0 ; Sun, 28 Feb 1999 07:16:45 -0500
X-Lotus-FromDomain: IBMUS
To: Jim Davis <jdavis@parc.xerox.com>
cc: w3c-dist-auth@w3.org
Message-ID: <85256726.0043723B.00@d54mta03.raleigh.ibm.com>
Date: Sun, 28 Feb 1999 07:10:10 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Issue #2 Definition of the term Referential Resource



Jim Davis says "identify these abstractions by their intended purpose, not
the
mechanism by which such purpose is realized."

Love it!



