- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 03 Jun 2004 09:03:36 +0200
- To: w3c-dist-auth@w3.org
Hi,
as far as I can tell, the working group hasn't come to a conclusion
about how to proceed with the BIND spec (see summary
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#49>
from almost two months ago). Also note that the updated charter
(<http://www.ietf.org/html.charters/webdav-charter.html>) for the
working group had a goal for last-calling BIND last month that we've
already missed.
To speed things up, I have experimentally extracted LOCKING from RFC2518
and added all open issues related to locking from the RFC2518 issues
list. This is
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-00.html>.
The derived issues list is here:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>.
In general, it should match the locking related part of the original
issues list.
Revision 01 (just published:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-01.html>)
has some of the trivial issues resolved; also reorganizing the content
has started. In particular:
Add and resolve issue "rfc2606-compliance". Resolve issues
"extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL",
"025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS",
"039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02",
"040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL",
"065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION",
"080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC",
"089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK",
"101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS",
"109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and
"111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work
on moving text from RFC2518 excerpts into new sections. Define new
compliance class "locking" (similar to "bis" in RFC2518bis, but only
relevant to locking). Reformatted "GULP" into separate subsections
for easier reference.
As usual, edits are ongoing on
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>.
My goals are to drive all locking-related open issues to conclusion as
soon as possible: this may either mean agreeing on a specific protocol
or text change; or by explicitly rejecting the issue. This activity is
useful to the working group no matter whether we actually *do* a
stand-alone locking spec, or we keep it inside RFC2518bis.
Personally I think that extracting it from RFC2518 makes a lot of sense,
and I'll try to demonstrate the benefits while I'm working on this
(non-working-group) draft.
Best regards, Julian
-------- Original Message --------
From: - Thu Jun 03 08:08:42 2004
X-UIDL: 02676066e63b0b9c6baea229004c1384
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-Path: <i-d-announce-bounces@ietf.org>
X-Flags: 0000
Delivered-To: GMX delivery to julian.reschke@gmx.de
Received: (qmail 26364 invoked by uid 65534); 3 Jun 2004 04:19:06 -0000
Received: from megatron.ietf.org (EHLO megatron.ietf.org) (132.151.6.71)
by mx0.gmx.net (mx015) with SMTP; 03 Jun 2004 06:19:06 +0200
Received: from localhost.localdomain ([127.0.0.1]
helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id
1BViS7-00066r-AZ; Wed, 02 Jun 2004 22:59:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by
megatron.ietf.org with esmtp (Exim 4.32) id 1BVc6B-00072t-Ji for
i-d-announce@megatron.ietf.org; Wed, 02 Jun 2004 16:12:31 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
(8.9.1a/8.9.1a) with ESMTP id QAA16333 for <i-d-announce@ietf.org>; Wed,
2 Jun 2004 16:12:14 -0400 (EDT)
Message-Id: <200406022012.QAA16333@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Wed, 02 Jun 2004 16:12:14 -0400
Subject: I-D ACTION:draft-reschke-webdav-locking-01.txt
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
Author(s) : J. Reschke
Filename : draft-reschke-webdav-locking-01.txt
Pages : 52
Date : 2004-6-2
This document specifies a set of methods and headers ancillary to
HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
RFC2518) for the management of resource locking (collision
avoidance). It updates those sections from RFC2518 that specify
WebDAV's locking features.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-01.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
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-reschke-webdav-locking-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-reschke-webdav-locking-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.
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 3 June 2004 03:04:11 UTC