From w3c-dist-auth-request@w3.org  Thu Jun  1 07:29:07 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20010
	for <webdav-archive@odin.ietf.org>; Thu, 1 Jun 2000 07:29:06 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id HAA07515;
	Thu, 1 Jun 2000 07:24:21 -0400 (EDT)
Resent-Date: Thu, 1 Jun 2000 07:24:21 -0400 (EDT)
Resent-Message-Id: <200006011124.HAA07515@www19.w3.org>
Date: Thu, 1 Jun 2000 04:23:55 -0700 (PDT)
From: Greg Stein <gstein@lyra.org>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <200005301244.IAA23646@tantalum.atria.com>
Message-ID: <Pine.LNX.4.10.10005311227440.30220-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: If: header and "parent" resource checking
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4325
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

[ clarification note: when Geoff says "lock state of the resource", I am
  assuming that he means "the [part of] state in the resource which is
  subjected to write-lock conditions." ]

On Tue, 30 May 2000, Geoffrey M. Clemm wrote:
>    From: jamsden@us.ibm.com
> 
>    <geoff>
>    The fact that they show up in a PROPFIND does not require that their
>    addition and removal from a collection affect the lock state of that
>    collection.  I'll appeal again to live properties here.  They are
>    properties of a resource, but they can be changed without affecting
>    the lock state of the resource.
>    </geoff>
> 
>    <jra>
>    But they're not live properties.
> 
> I didn't mean to imply that they were.  I was just using the way we handle
> live properties as an analogy.  A live property appears to be part of the
> state of a resource, but we allow it to be modified without modifying the
> lock state of the resource.  Analogously, I propose that a lock null resource
> should appear to be part of the state of a collection, but that we allow
> them to be added and deleted without modifying the lock state of the resource.

I see the point and the analogy. However, I disagree that it makes sense
in this context.

Consider the purpose of a locknull resource: to reserve a member within a
collection. If I create a locknull within collection C, then it will
appear within a PROPFIND against C. But that is wrong, when principal P
has taken a lock against C to prevent that very thing!

>    <jra>
>    For example, lock-null resources can be
>    the request-URL of PROPFIND and UNLOCK. The problem is that lock-null
>    resources are only lock-null resources: a bunch of special cases that make
>    sense when you look at them one way and not form another. I think they were
>    a good idea that didn't semantically scale.
>    </jra>
> 
> I agree that lock-null resources are just a bunch of special cases.
> What I'd like to do is minimize their impact on the rest of the
> protocol.  One way to do so is to say that only PROPFIND and UNLOCK
> have to deal with them as a special case, i.e. all other methods do
> not have to treat them as normal resources (in fact, according to
> 2518, most other methods are not *allowed* to treat them as normal
> resources).
> 
> This then means that only the implementation of PROPFIND and UNLOCK
> needs to treat a name lock as if it were a resource.  All the other
> methods do not.  This I believe is the simplest and cleanest way of
> handling lock null resources (and is consistent with what 2518
> currently says).

Euh... they can also be the Destination of a MOVE/COPY. Not sure if that
truly means MOVE/COPY needs to be aware of their special nature, but it
doesn't seem that we can simply shove all knowledge of them into PROPFIND
and UNLOCK.

But, this seems to be a tangent. I consider the original motivation (name
reservation) as the determination for the semantics for a locknull
resource. This means that the parent must allow the name to be reserved,
which means satisfying its locks.

Cheers,
-g

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







From w3c-dist-auth-request@w3.org  Thu Jun  1 11:27:16 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25725
	for <webdav-archive@odin.ietf.org>; Thu, 1 Jun 2000 11:27:16 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA12599;
	Thu, 1 Jun 2000 11:22:18 -0400 (EDT)
Resent-Date: Thu, 1 Jun 2000 11:22:18 -0400 (EDT)
Resent-Message-Id: <200006011522.LAA12599@www19.w3.org>
Message-Id: <s9362966.012@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 01 Jun 2000 09:14:09 -0600
From: "Dan Burton" <DPBURTON@novell.com>
To: "<"<w3c-dist-auth@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA12579
Subject: RE: Passwords and WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4326
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 8bit

In my original message I said this may be out of the scope of WebDAV, but now I think it is critical to WebDAV. We a currently working on this issue with a large customer. With a normal HTTP client (one that renders html) it is possible to solve the expired password problem. However, with WebDAV clients there currently is no way to solve this problem. This is currently THE issue that is preventing the adoption of WebDAV for this customer. If we want to have people use the WebDAV protocol we have to be willing to solve problems like this one.

>>> "Kevin Dyer" <kevin.dyer@matrix-one.com> 05/26/00 05:56AM >>>
Changing passwords may be out-of-scope but providing a return code 
mechanism for revoking credentials, or to inform the user that their 
password/temporary password must be renewed is not.  About a year and a 
half ago I made a suggestion to the HTTP-WG that we add a return code
or set of return codes to do just that.  Provide a mechanism to the
underlying authentication and authorization systems that allows the
system to notify it's users in a standardized manner that something 
needs to be addressed.  The suggestion was tabled due to the timing
and where 1.1 was in the loop.

As Dan points out most of the new clients that are interfacing with
a WebDAV server are not browsers so they are incapable of displaying
HTML pages. So what do we put into the protocol to allow such 
interoperability?





From w3c-dist-auth-request@w3.org  Thu Jun  1 18:29:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05827
	for <webdav-archive@odin.ietf.org>; Thu, 1 Jun 2000 18:29:35 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA01089;
	Thu, 1 Jun 2000 18:24:09 -0400 (EDT)
Resent-Date: Thu, 1 Jun 2000 18:24:09 -0400 (EDT)
Resent-Message-Id: <200006012224.SAA01089@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: Dan Burton <DPBURTON@novell.com>, WebDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 1 Jun 2000 15:21:21 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJOEIODEAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <s9362966.012@prv-mail20.provo.novell.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: Passwords and WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4327
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Hmm, well I can see how this is an important deployment issue. I think the
problem of notifying the user that their password has expired would be
easier than providing a password modification protocol.

It seems to be this problem isn't inherent to authoring -- regular Web
access could run into this problem as well.  For example, if my subscription
to an online magazine, or digital library runs out, I might want to receive
a message as well.  But, authoring certainly does bring in clients that do
not have HTML rendering capability.

I think the best way to address this would be for someone to volunteer to
write up an Internet Draft describing a new status code, and its meaning, to
cover the password expiration, and password refresh cases.  I think it
should scrupulously avoid functionality that would allow a user to reset
their password, unless it involved returning the URL of a Web page that
would allow the password to be reset.

But, this wouldn't affect existing WebDAV clients fast enough to affect your
current situation -- for that, one option is to use email as a notification
service, telling users their passwords have expired.

- Jim


> In my original message I said this may be out of the scope of
> WebDAV, but now I think it is critical to WebDAV. We a currently
> working on this issue with a large customer. With a normal HTTP
> client (one that renders html) it is possible to solve the
> expired password problem. However, with WebDAV clients there
> currently is no way to solve this problem. This is currently THE
> issue that is preventing the adoption of WebDAV for this
> customer. If we want to have people use the WebDAV protocol we
> have to be willing to solve problems like this one.




From w3c-dist-auth-request@w3.org  Thu Jun  1 18:57:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06263
	for <webdav-archive@odin.ietf.org>; Thu, 1 Jun 2000 18:57:01 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA02366;
	Thu, 1 Jun 2000 18:50:06 -0400 (EDT)
Resent-Date: Thu, 1 Jun 2000 18:50:06 -0400 (EDT)
Resent-Message-Id: <200006012250.SAA02366@www19.w3.org>
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 gremlin-relay.ics.uci.edu
Date: Thu, 1 Jun 2000 15:47:23 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJMEJADEAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Pine.LNX.4.10.10005311212010.30220-100000@nebula.lyra.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: does this use of 424 seem reasonable?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4328
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

The error minimization rules in Section 8.6.2, 6th paragraph, were intended
to cover this situation by eliminating repetition of 424s.

I heartily concur that, if a server can support atomic copy/move/delete,
then they should do so.  I suspect I will spend a day in purgatory for every
person who was misled on this point by the language in RFC 2518.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein
> Sent: Wednesday, May 31, 2000 12:16 PM
> To: w3c-dist-auth@w3.org
> Subject: Q: does this use of 424 seem reasonable?
>
>
> Hi all...
>
> One more question: in the current mod_dav architecture, I am unable to do
> a "best effort" delete/move/copy when a lock exists somewhere in the
> affected resources. As a result, the only real option available is to fail
> the entire request.
>
> However, this would effectively mean returning a 207 (Multistatus) that
> contains an entry for every single resource stating (in some way) that it
> was not deleted/moved/copied.
>
> I would much rather do the following:
>
> *) return 424 (Failed Dependency)
> *) include a body in the 424 response, which contains a DAV:multistatus
>    element which refers to the locked resource
>
>
> Does this seem reasonable?
>
> Thanx,
> -g
>
> p.s. and no, fixing it to do best-effort is not an option
>
> --
> Greg Stein, http://www.lyra.org/
>



From w3c-dist-auth-request@w3.org  Mon Jun  5 13:34:54 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07181
	for <webdav-archive@odin.ietf.org>; Mon, 5 Jun 2000 13:34:54 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA23526;
	Mon, 5 Jun 2000 13:25:26 -0400 (EDT)
Resent-Date: Mon, 5 Jun 2000 13:25:26 -0400 (EDT)
Resent-Message-Id: <200006051725.NAA23526@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 5 Jun 2000 10:22:39 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJAELEDEAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: FW: 48th IETF: Registration Now Open
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4329
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

FYI.  Rooms in the conference hotel tend to get reserved very quickly for
IETF meetings.  At present, there are plans to hold at least one WebDAV
session (on access control), and one DeltaV session.  At present I have no
information on when, during the week, these sessions will be scheduled.

- Jim

-----Original Message-----
From: mbeaulie@cnri.reston.va.us [mailto:mbeaulie@cnri.reston.va.us]On
Behalf Of ietf-registrar@ietf.org
Sent: Friday, June 02, 2000 12:35 PM
To: IETF-Announce: ;
Subject: 48th IETF: Registration Now Open


Registrations are now being accepted for the 48th IETF
Meeting in Pittsburgh, Pennsylvania.

The meeting dates are 30 July - 4 August 2000.

For more information on the 48th IETF meeting, please visit
our web page at: http://www.ietf.org/meetings/IETF-48.html



From w3c-dist-auth-request@w3.org  Tue Jun 13 10:04:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08721
	for <webdav-archive@odin.ietf.org>; Tue, 13 Jun 2000 10:04:56 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA07410;
	Tue, 13 Jun 2000 09:55:53 -0400 (EDT)
Resent-Date: Tue, 13 Jun 2000 09:55:53 -0400 (EDT)
Resent-Message-Id: <200006131355.JAA07410@www19.w3.org>
Date: Tue, 13 Jun 2000 06:56:04 -0700
From: Greg Stein <gstein@lyra.org>
To: w3c-dist-auth@w3.org, new-httpd@apache.org, editors@apacheweek.com
Message-ID: <20000613065604.D19484@lyra.org>
Mail-Followup-To: w3c-dist-auth@w3.org, new-httpd@apache.org,
	editors@apacheweek.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
X-URL: http://www.lyra.org/greg/
Subject: [ANN] mod_dav 1.0 released!
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4330
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

mod_dav 1.0 is now gold! It can be found at http://www.webdav.org/mod_dav/

A press release has been issued by the Apache Software Foundation and
"webdav.org", talking about the release:

    http://www.webdav.org/mod_dav/press-release.html


Of particular note, is that mod_dav is going to become a standard part of
Apache 2.0, now that we have passed the 1.0 release milestone.

Cheers,
-g

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



From w3c-dist-auth-request@w3.org  Fri Jun 16 15:19:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21764
	for <webdav-archive@odin.ietf.org>; Fri, 16 Jun 2000 15:19:31 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA28825;
	Fri, 16 Jun 2000 15:09:46 -0400 (EDT)
Resent-Date: Fri, 16 Jun 2000 15:09:46 -0400 (EDT)
Resent-Message-Id: <200006161909.PAA28825@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 16 Jun 2000 12:06:30 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJMEFIDFAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: FW: Internet-Draft Cut-off for Pittsburgh IETF
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4331
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

FYI.

- Jim

-----Original Message-----
From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On
Behalf Of Internet-Draft Administrator
Sent: Thursday, June 15, 2000 3:41 AM
To: IETF-Announce: ;
Subject: Internet-Draft Cut-off for Pittsburgh IETF


--------

The cut-off for Interntet-Draft submissions prior to the
Pittsburgh, PA, USA IETF meeting is Friday, July 14, 2000
at 5 pm US-ET. Internet-Drafts received after this time will NOT
be announced nor made available in the Internet-Drafts
Directories.

We will begin accepting Internet-Draft submissions the week
of the meeting, though announcements will NOT be sent until
the IETF meeting is over.

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


NOTE: All initial submissions (-00.txt) with a filename
      beginning with a draft-ietf MUST be approved by the
      appropriate WG Chair prior to processing and announcing.
      WG Chair approval must be received prior to the I-D cut-off
      date.

      As such, -00 submissions received the day of the cut-off
      will NOT be processed as WG documents. Do NOT wait until
      the last minute.


FYI:  These and other significant date can be found at 
      http://www.ietf.org/meetings/cutoff_dates_48.html



From w3c-dist-auth-request@w3.org  Mon Jun 19 14:11:15 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19208
	for <webdav-archive@odin.ietf.org>; Mon, 19 Jun 2000 14:11:13 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA14644;
	Mon, 19 Jun 2000 14:01:05 -0400 (EDT)
Resent-Date: Mon, 19 Jun 2000 14:01:05 -0400 (EDT)
Resent-Message-Id: <200006191801.OAA14644@www19.w3.org>
Message-ID: <65B141FB11CCD211825700A0C9D609BC03093BCE@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: "'Greg Stein'" <gstein@lyra.org>,
        "Geoffrey M. Clemm"
	 <geoffrey.clemm@Rational.Com>
Cc: w3c-dist-auth@w3.org, "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
Date: Mon, 19 Jun 2000 13:53:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFDA17.393CEBA0"
Subject: RE: If: header and "parent" resource checking
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4332
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFDA17.393CEBA0
Content-Type: text/plain;
	charset="iso-8859-1"

Just to follow-up on this thread from a versioning perspective:

There are other reasons to allow "private" members of a versioned
collection (i.e. members that can be added/deleted without checking
out the versioned collection, or remembering the members in the
history of the versioned collection), so with this as additional
motivation, I've proposed that the versioning protocol support the
notion of "private" members of a versioned collection, and used
lock-null resources as one of the motivations.

So assuming that "private members of versioned collections" passes
muster with the versioning design team, I have no problem with the
current 2518 model that Greg (and others) have proposed to support.

Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, June 01, 2000 7:24 AM
To: Geoffrey M. Clemm
Cc: w3c-dist-auth@w3.org
Subject: Re: If: header and "parent" resource checking


[ clarification note: when Geoff says "lock state of the resource", I am
  assuming that he means "the [part of] state in the resource which is
  subjected to write-lock conditions." ]

On Tue, 30 May 2000, Geoffrey M. Clemm wrote:
>    From: jamsden@us.ibm.com
> 
>    <geoff>
>    The fact that they show up in a PROPFIND does not require that their
>    addition and removal from a collection affect the lock state of that
>    collection.  I'll appeal again to live properties here.  They are
>    properties of a resource, but they can be changed without affecting
>    the lock state of the resource.
>    </geoff>
> 
>    <jra>
>    But they're not live properties.
> 
> I didn't mean to imply that they were.  I was just using the way we handle
> live properties as an analogy.  A live property appears to be part of the
> state of a resource, but we allow it to be modified without modifying the
> lock state of the resource.  Analogously, I propose that a lock null
resource
> should appear to be part of the state of a collection, but that we allow
> them to be added and deleted without modifying the lock state of the
resource.

I see the point and the analogy. However, I disagree that it makes sense
in this context.

Consider the purpose of a locknull resource: to reserve a member within a
collection. If I create a locknull within collection C, then it will
appear within a PROPFIND against C. But that is wrong, when principal P
has taken a lock against C to prevent that very thing!

>    <jra>
>    For example, lock-null resources can be
>    the request-URL of PROPFIND and UNLOCK. The problem is that lock-null
>    resources are only lock-null resources: a bunch of special cases that
make
>    sense when you look at them one way and not form another. I think they
were
>    a good idea that didn't semantically scale.
>    </jra>
> 
> I agree that lock-null resources are just a bunch of special cases.
> What I'd like to do is minimize their impact on the rest of the
> protocol.  One way to do so is to say that only PROPFIND and UNLOCK
> have to deal with them as a special case, i.e. all other methods do
> not have to treat them as normal resources (in fact, according to
> 2518, most other methods are not *allowed* to treat them as normal
> resources).
> 
> This then means that only the implementation of PROPFIND and UNLOCK
> needs to treat a name lock as if it were a resource.  All the other
> methods do not.  This I believe is the simplest and cleanest way of
> handling lock null resources (and is consistent with what 2518
> currently says).

Euh... they can also be the Destination of a MOVE/COPY. Not sure if that
truly means MOVE/COPY needs to be aware of their special nature, but it
doesn't seem that we can simply shove all knowledge of them into PROPFIND
and UNLOCK.

But, this seems to be a tangent. I consider the original motivation (name
reservation) as the determination for the semantics for a locknull
resource. This means that the parent must allow the name to be reserved,
which means satisfying its locks.

Cheers,
-g

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





------_=_NextPart_001_01BFDA17.393CEBA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: If: header and &quot;parent&quot; resource checking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Just to follow-up on this thread from a versioning perspective:</FONT>
</P>

<P><FONT SIZE=2>There are other reasons to allow &quot;private&quot; members of a versioned</FONT>
<BR><FONT SIZE=2>collection (i.e. members that can be added/deleted without checking</FONT>
<BR><FONT SIZE=2>out the versioned collection, or remembering the members in the</FONT>
<BR><FONT SIZE=2>history of the versioned collection), so with this as additional</FONT>
<BR><FONT SIZE=2>motivation, I've proposed that the versioning protocol support the</FONT>
<BR><FONT SIZE=2>notion of &quot;private&quot; members of a versioned collection, and used</FONT>
<BR><FONT SIZE=2>lock-null resources as one of the motivations.</FONT>
</P>

<P><FONT SIZE=2>So assuming that &quot;private members of versioned collections&quot; passes</FONT>
<BR><FONT SIZE=2>muster with the versioning design team, I have no problem with the</FONT>
<BR><FONT SIZE=2>current 2518 model that Greg (and others) have proposed to support.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Geoff</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Greg Stein [<A HREF="mailto:gstein@lyra.org">mailto:gstein@lyra.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, June 01, 2000 7:24 AM</FONT>
<BR><FONT SIZE=2>To: Geoffrey M. Clemm</FONT>
<BR><FONT SIZE=2>Cc: w3c-dist-auth@w3.org</FONT>
<BR><FONT SIZE=2>Subject: Re: If: header and &quot;parent&quot; resource checking</FONT>
</P>
<BR>

<P><FONT SIZE=2>[ clarification note: when Geoff says &quot;lock state of the resource&quot;, I am</FONT>
<BR><FONT SIZE=2>&nbsp; assuming that he means &quot;the [part of] state in the resource which is</FONT>
<BR><FONT SIZE=2>&nbsp; subjected to write-lock conditions.&quot; ]</FONT>
</P>

<P><FONT SIZE=2>On Tue, 30 May 2000, Geoffrey M. Clemm wrote:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; From: jamsden@us.ibm.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &lt;geoff&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The fact that they show up in a PROPFIND does not require that their</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; addition and removal from a collection affect the lock state of that</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; collection.&nbsp; I'll appeal again to live properties here.&nbsp; They are</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; properties of a resource, but they can be changed without affecting</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the lock state of the resource.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &lt;/geoff&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &lt;jra&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; But they're not live properties.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I didn't mean to imply that they were.&nbsp; I was just using the way we handle</FONT>
<BR><FONT SIZE=2>&gt; live properties as an analogy.&nbsp; A live property appears to be part of the</FONT>
<BR><FONT SIZE=2>&gt; state of a resource, but we allow it to be modified without modifying the</FONT>
<BR><FONT SIZE=2>&gt; lock state of the resource.&nbsp; Analogously, I propose that a lock null resource</FONT>
<BR><FONT SIZE=2>&gt; should appear to be part of the state of a collection, but that we allow</FONT>
<BR><FONT SIZE=2>&gt; them to be added and deleted without modifying the lock state of the resource.</FONT>
</P>

<P><FONT SIZE=2>I see the point and the analogy. However, I disagree that it makes sense</FONT>
<BR><FONT SIZE=2>in this context.</FONT>
</P>

<P><FONT SIZE=2>Consider the purpose of a locknull resource: to reserve a member within a</FONT>
<BR><FONT SIZE=2>collection. If I create a locknull within collection C, then it will</FONT>
<BR><FONT SIZE=2>appear within a PROPFIND against C. But that is wrong, when principal P</FONT>
<BR><FONT SIZE=2>has taken a lock against C to prevent that very thing!</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &lt;jra&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; For example, lock-null resources can be</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the request-URL of PROPFIND and UNLOCK. The problem is that lock-null</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; resources are only lock-null resources: a bunch of special cases that make</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; sense when you look at them one way and not form another. I think they were</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; a good idea that didn't semantically scale.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &lt;/jra&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree that lock-null resources are just a bunch of special cases.</FONT>
<BR><FONT SIZE=2>&gt; What I'd like to do is minimize their impact on the rest of the</FONT>
<BR><FONT SIZE=2>&gt; protocol.&nbsp; One way to do so is to say that only PROPFIND and UNLOCK</FONT>
<BR><FONT SIZE=2>&gt; have to deal with them as a special case, i.e. all other methods do</FONT>
<BR><FONT SIZE=2>&gt; not have to treat them as normal resources (in fact, according to</FONT>
<BR><FONT SIZE=2>&gt; 2518, most other methods are not *allowed* to treat them as normal</FONT>
<BR><FONT SIZE=2>&gt; resources).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This then means that only the implementation of PROPFIND and UNLOCK</FONT>
<BR><FONT SIZE=2>&gt; needs to treat a name lock as if it were a resource.&nbsp; All the other</FONT>
<BR><FONT SIZE=2>&gt; methods do not.&nbsp; This I believe is the simplest and cleanest way of</FONT>
<BR><FONT SIZE=2>&gt; handling lock null resources (and is consistent with what 2518</FONT>
<BR><FONT SIZE=2>&gt; currently says).</FONT>
</P>

<P><FONT SIZE=2>Euh... they can also be the Destination of a MOVE/COPY. Not sure if that</FONT>
<BR><FONT SIZE=2>truly means MOVE/COPY needs to be aware of their special nature, but it</FONT>
<BR><FONT SIZE=2>doesn't seem that we can simply shove all knowledge of them into PROPFIND</FONT>
<BR><FONT SIZE=2>and UNLOCK.</FONT>
</P>

<P><FONT SIZE=2>But, this seems to be a tangent. I consider the original motivation (name</FONT>
<BR><FONT SIZE=2>reservation) as the determination for the semantics for a locknull</FONT>
<BR><FONT SIZE=2>resource. This means that the parent must allow the name to be reserved,</FONT>
<BR><FONT SIZE=2>which means satisfying its locks.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>-g</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Greg Stein, <A HREF="http://www.lyra.org/" TARGET="_blank">http://www.lyra.org/</A></FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFDA17.393CEBA0--



From w3c-dist-auth-request@w3.org  Fri Jun 30 15:05:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24512
	for <webdav-archive@odin.ietf.org>; Fri, 30 Jun 2000 15:05:13 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA12642;
	Fri, 30 Jun 2000 14:57:34 -0400 (EDT)
Resent-Date: Fri, 30 Jun 2000 14:57:34 -0400 (EDT)
Resent-Message-Id: <200006301857.OAA12642@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Cc: dav-dev@lyra.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Fri, 30 Jun 2000 11:53:33 -0700
Message-ID: <NDBBIKLAGLCOPGKGADOJKECKDGAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: FW: MS IE/Office/Web Folder Behaviors with WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4333
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.  I've also cc'ed the DAV developers
list dav-dev@lyra.org.

- Jim

-----Original Message-----
From: Gary M Gershon [mailto:gershon@celsus.net]
Sent: Wednesday, June 28, 2000 4:35 PM
To: WebDAV List
Subject: [Moderator Action] MS IE/Office/Web Folder Behaviors with
WebDAV


We're making progress with a fresh WebDAV implementation for document
management using a large-scale EDMS backend.  One of the drivers of this
project is the out-of-the-box availability of MS Office and MS Web Folder
support.  If someone could shed some light on some of the behaviors of the
MS Office products in a WebDAV environment, it would be helpful in
directing our work efforts.

1.  Using IE, when launching an MS Office product (Word/Excel) from a web
page URL pointing to a WebDAV server, the File>Save menu choice is
disabled.  One can, however, do a File>Save As...  (Word and Excel are
windowed within IE.)  Can (how does) one enable the File>Save menu
item?  (IE 5.5, Windows 2000, Office 2000).

2.  Using Windows Explorer (on W2K) , the directories do not show the
Modified Date, although the date was returned in the XML stream.  Why not?

3. Is there a way to customize Windows Explorer to add other columns of
properties and file attributes returned via the XML stream?  Is there a
toolkit or documentation to build an alternative desktop-integrated Web
Folder view similar to the Windows Explorer experience?

4.  An Adobe PDF file cannot be saved to a Web Folder using Acrobat 4.06,
although one can save to a temp directory and drag-drop the file into the
WebDAV Web Folder.  Does writing from a Windows app to a WebDAV Web Folder
require special File>Save API coding? (Or conversely, is it likely that
Adobe is using non-standard tests/coding that reject Web Folders as a
File>Save destination?)

Gary



--------------------------------------------------------------------
Gary M. Gershon  -- gershon@celsus.net



From w3c-dist-auth-request@w3.org  Fri Jun 30 16:07:58 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25572
	for <webdav-archive@odin.ietf.org>; Fri, 30 Jun 2000 16:07:58 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA15904;
	Fri, 30 Jun 2000 16:01:49 -0400 (EDT)
Resent-Date: Fri, 30 Jun 2000 16:01:49 -0400 (EDT)
Resent-Message-Id: <200006302001.QAA15904@www19.w3.org>
Date: Fri, 30 Jun 2000 13:03:01 -0700
From: Greg Stein <gstein@lyra.org>
To: gershon@celsus.net
Cc: WebDAV WG <w3c-dist-auth@w3.org>, dav-dev@lyra.org
Message-ID: <20000630130301.W29590@lyra.org>
Mail-Followup-To: gershon@celsus.net, WebDAV WG <w3c-dist-auth@w3.org>,
	dav-dev@lyra.org
References: <NDBBIKLAGLCOPGKGADOJKECKDGAA.ejw@ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <NDBBIKLAGLCOPGKGADOJKECKDGAA.ejw@ics.uci.edu>; from ejw@ics.uci.edu on Fri, Jun 30, 2000 at 11:53:33AM -0700
X-URL: http://www.lyra.org/greg/
Subject: Re: [dav-dev] FW: MS IE/Office/Web Folder Behaviors with WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4334
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Hi Gary,

The first three are best answered by somebody from Microsoft who is
intimately familiar with the products. I really don't know the answers
there.

Regarding the last question: yes, an application must take special measures
to be able to save to a DAV folder. Acrobat 4 is simply not DAV-enabled, so
it is unable to do the save. Adobe's upcoming GoLive (v5) product will be
able to save to a DAV server; I don't know if they have publicly announced
whether Acrobat 5 (or their other authoring products) will be able to.

Cheers,
-g

On Fri, Jun 30, 2000 at 11:53:33AM -0700, Jim Whitehead wrote:
>...
> From: Gary M Gershon [mailto:gershon@celsus.net]
> Sent: Wednesday, June 28, 2000 4:35 PM
> To: WebDAV List
> Subject: [Moderator Action] MS IE/Office/Web Folder Behaviors with
> WebDAV
> 
> 
> We're making progress with a fresh WebDAV implementation for document
> management using a large-scale EDMS backend.  One of the drivers of this
> project is the out-of-the-box availability of MS Office and MS Web Folder
> support.  If someone could shed some light on some of the behaviors of the
> MS Office products in a WebDAV environment, it would be helpful in
> directing our work efforts.
> 
> 1.  Using IE, when launching an MS Office product (Word/Excel) from a web
> page URL pointing to a WebDAV server, the File>Save menu choice is
> disabled.  One can, however, do a File>Save As...  (Word and Excel are
> windowed within IE.)  Can (how does) one enable the File>Save menu
> item?  (IE 5.5, Windows 2000, Office 2000).
>
> 2.  Using Windows Explorer (on W2K) , the directories do not show the
> Modified Date, although the date was returned in the XML stream.  Why not?
> 
> 3. Is there a way to customize Windows Explorer to add other columns of
> properties and file attributes returned via the XML stream?  Is there a
> toolkit or documentation to build an alternative desktop-integrated Web
> Folder view similar to the Windows Explorer experience?
> 
> 4.  An Adobe PDF file cannot be saved to a Web Folder using Acrobat 4.06,
> although one can save to a temp directory and drag-drop the file into the
> WebDAV Web Folder.  Does writing from a Windows app to a WebDAV Web Folder
> require special File>Save API coding? (Or conversely, is it likely that
> Adobe is using non-standard tests/coding that reject Web Folders as a
> File>Save destination?)
> 
> Gary
> 
> 
> 
> --------------------------------------------------------------------
> Gary M. Gershon  -- gershon@celsus.net
> 
> 
> _______________________________________________
> dav-dev maillist  -  dav-dev@lyra.org
> http://dav.lyra.org/mailman/listinfo/dav-dev

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



From w3c-dist-auth-request@w3.org  Fri Jun 30 16:11:07 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25629
	for <webdav-archive@odin.ietf.org>; Fri, 30 Jun 2000 16:11:06 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA16075;
	Fri, 30 Jun 2000 16:05:36 -0400 (EDT)
Resent-Date: Fri, 30 Jun 2000 16:05:36 -0400 (EDT)
Resent-Message-Id: <200006302005.QAA16075@www19.w3.org>
To: WebDAV WG <w3c-dist-auth@w3.org>
Cc: dav-dev@lyra.org
X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999
Message-ID: <OF7BF007C0.797436A0-ON8525690E.006CA828@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Fri, 30 Jun 2000 16:03:13 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at
 06/30/2000 04:03:13 PM,
	Serialize complete at 06/30/2000 04:03:13 PM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: MS IE/Office/Web Folder Behaviors with WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4335
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>We're making progress with a fresh WebDAV implementation
>for document management using a large-scale EDMS backend.
>One of the drivers of this project is the out-of-the-box
>availability of MS Office and MS Web Folder support.  If
>someone could shed some light on some of the behaviors of
>the MS Office products in a WebDAV environment, it would
>be helpful in directing our work efforts.

I'll take a shot, but I'm no expert (just a bruised user ;-)

>1.  Using IE, when launching an MS Office product
>(Word/Excel) from a web page URL pointing to a WebDAV
>server, the File>Save menu choice is disabled.  One can,
>however, do a File>Save As... (Word and Excel are windowed
>within IE.)  Can (how does) one enable the File>Save menu
>item?  (IE 5.5, Windows 2000, Office 2000).

My understanding is that you cannot enable File>Save since the clients are 
not doing LOCKing, and therefore there is no guarantee that you have 
exclusive access to the resource.  The semantics of Save are not supported 
without LOCK, so you have to choose File>Save As... and explicitly accept 
the consequences of overwriting an existing resource (i.e., are you 
sure?...)

>2.  Using Windows Explorer (on W2K) , the directories do
>not show the Modified Date, although the date was returned
>in the XML stream.  Why not?

Beats me?  It doesn't show up on NT4.0 either.

>3. Is there a way to customize Windows Explorer to add other
>columns of properties and file attributes returned via the XML
>stream?  Is there a toolkit or documentation to build an
>alternative desktop-integrated Web Folder view similar to
>the Windows Explorer experience?

I don't know about customizing the existing window (you can't do it 
through the UI), but there is a description of the WebFolder object and 
related methods available on MS developers network 
(http://msdn.microsoft.com/library/officedev/off2000/fpobjWebFolder.htm), 
so presumably you can roll your own.

>4.  An Adobe PDF file cannot be saved to a Web Folder using
>Acrobat 4.06, although one can save to a temp directory and
>drag-drop the file into the WebDAV Web Folder.  Does writing
>from a Windows app to a WebDAV Web Folder require special
>File>Save API coding? (Or conversely, is it likely that Adobe
>is using non-standard tests/coding that reject Web Folders as
>a File>Save destination?)

The web folders are not a file system mount to a dav server, so apps do 
not get webdav 'for free'.  In your suggestions, a windows app would 
require special File>Save coding.


Tim
p.s. I'm sure more people know much more about this than I do.