W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: Re (2): Status of RFC2518Bis

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Wed, 7 Apr 2004 14:56:15 -0700
Message-ID: <009401c41ceb$26578a20$1baa2382@us.oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>, "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>

I guess I'd vote for Julian's option #2:

"Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore. "


----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
Sent: Wednesday, April 07, 2004 12:12 PM
Subject: Re: Re (2): Status of RFC2518Bis

> Jim Luther wrote:
> > Who needs locking? Apple's Mac OS X WebDAV file system client needs it.
> > Whenever a file (a non-collection resource on the WebDAV server) is
> > opened with write access, the WebDAV file system obtains a lock. The
> > lock is held until the file is closed. If a WebDAV server does not
> > support locks (i.e., it is not class 2 compliant), the WebDAV file
> > system mounts it read-only.
> Yes. Many applications need locking, and most servers provide it.
> However, it is optional right now, and will have to remain so.
> So what's the best way to come up with an updated/upgraded locking spec,
> if we can't wait for RFC2518bis?
> Discussion started back here:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>.
> More feedback appreciated.
> Regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 7 April 2004 17:57:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC