[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                         J. Reschke
Internet-Draft                                                greenbytes
Updates: 2518 (if approved)                                 May 21, 2004
Expires: November 19, 2004


   Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
                    draft-reschke-webdav-locking-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 19, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   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.

   [[anchor1: Note that this document is not a product of the WebDAV
   working group.
        It is just an experiment to study the
   feasability of extracing the
        locking feature into a separate



Reschke                Expires November 19, 2004                [Page 1]


Internet-Draft           WebDAV URL constraints                 May 2004


   specification. --reschke]][[anchor2: This version of this document
   doesn't yet contain any new or
        rewritten text - it only
   contains text copied verbatim fro RFC2518
        and GULP.  It's
   sole purpose is be a reference point for
        all future changes.
   --reschke]]

   Distribution of this document is unlimited.  Please send comments to
   the WebDAV working group at <mailto:w3c-dist-auth@w3.org>, which may
   be joined by sending a message with subject "subscribe" to
   <mailto:w3c-dist-auth-request@w3.org?subject=subscribe>.

   Discussions of the WEBDAV working group are archived at URL: <http://
   lists.w3.org/Archives/Public/w3c-dist-auth/>.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.   Overview of Locking  . . . . . . . . . . . . . . . . . . . .   5
   3.   Properties . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   LOCK Method  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.   UNLOCK Method  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.   Additional status codes  . . . . . . . . . . . . . . . . . .   5
   7.   Additional method semantics for other Methods  . . . . . . .   5
   8.   Capability discovery . . . . . . . . . . . . . . . . . . . .   5
   9.   Security considerations  . . . . . . . . . . . . . . . . . .   5
   10.  Internationalization Considerations  . . . . . . . . . . . .   5
   11.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .   5
   12.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   5
   13.  Normative References . . . . . . . . . . . . . . . . . . . .   6
        Author's Address . . . . . . . . . . . . . . . . . . . . . .   6
   A.   Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . .   6
     A.1  Removed/Deprecated features  . . . . . . . . . . . . . . .   6
     A.2  Additional features features . . . . . . . . . . . . . . .   6
     A.3  Compatibility considerations . . . . . . . . . . . . . . .   6
   B.   Text to be integrated from RFC2518 . . . . . . . . . . . . .   6
     B.1  Introduction . . . . . . . . . . . . . . . . . . . . . . .   6
     B.2  Locking  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       B.2.1  Exclusive Vs. Shared Locks . . . . . . . . . . . . . .   7
       B.2.2  Required Support . . . . . . . . . . . . . . . . . . .   8
       B.2.3  Lock Tokens  . . . . . . . . . . . . . . . . . . . . .   8
       B.2.4  opaquelocktoken Lock Token URI Scheme  . . . . . . . .   9
       B.2.5  Lock Capability Discovery  . . . . . . . . . . . . . .  11
       B.2.6  Active Lock Discovery  . . . . . . . . . . . . . . . .  12
       B.2.7  Usage Considerations . . . . . . . . . . . . . . . . .  12
     B.3  Write Lock . . . . . . . . . . . . . . . . . . . . . . . .  13
       B.3.1  Methods Restricted by Write Locks  . . . . . . . . . .  13
       B.3.2  Write Locks and Lock Tokens  . . . . . . . . . . . . .  13
       B.3.3  Write Locks and Properties . . . . . . . . . . . . . .  13



Reschke                Expires November 19, 2004                [Page 2]


Internet-Draft           WebDAV URL constraints                 May 2004


       B.3.4  Write Locks and Null Resources . . . . . . . . . . . .  13
       B.3.5  Write Locks and Collections  . . . . . . . . . . . . .  14
       B.3.6  Write Locks and the If Request Header  . . . . . . . .  14
       B.3.7  Write Locks and COPY/MOVE  . . . . . . . . . . . . . .  15
       B.3.8  Refreshing Write Locks . . . . . . . . . . . . . . . .  16
     B.4  HTTP Headers for Distributed Authoring . . . . . . . . . .  16
       B.4.1  LOCK Method  . . . . . . . . . . . . . . . . . . . . .  16
       B.4.2  UNLOCK Method  . . . . . . . . . . . . . . . . . . . .  23
     B.5  HTTP Headers for Distributed Authoring . . . . . . . . . .  24
       B.5.1  DAV Header . . . . . . . . . . . . . . . . . . . . . .  24
       B.5.2  Depth Header . . . . . . . . . . . . . . . . . . . . .  24
       B.5.3  If Header  . . . . . . . . . . . . . . . . . . . . . .  24
       B.5.4  Lock-Token Header  . . . . . . . . . . . . . . . . . .  24
       B.5.5  Timeout Request Header . . . . . . . . . . . . . . . .  24
     B.6  Status Code Extensions to HTTP/1.1 . . . . . . . . . . . .  25
       B.6.1  423 Locked . . . . . . . . . . . . . . . . . . . . . .  25
     B.7  XML Element Definitions  . . . . . . . . . . . . . . . . .  26
       B.7.1  activelock XML Element . . . . . . . . . . . . . . . .  26
       B.7.2  lockentry XML Element  . . . . . . . . . . . . . . . .  27
       B.7.3  lockinfo XML Element . . . . . . . . . . . . . . . . .  27
       B.7.4  lockscope XML Element  . . . . . . . . . . . . . . . .  27
       B.7.5  locktype XML Element . . . . . . . . . . . . . . . . .  28
       B.7.6  owner XML Element  . . . . . . . . . . . . . . . . . .  29
     B.8  DAV Properties . . . . . . . . . . . . . . . . . . . . . .  29
       B.8.1  lockdiscovery Property . . . . . . . . . . . . . . . .  29
       B.8.2  supportedlock Property . . . . . . . . . . . . . . . .  31
     B.9  DAV Compliance Classes . . . . . . . . . . . . . . . . . .  32
       B.9.1  Class 2  . . . . . . . . . . . . . . . . . . . . . . .  32
     B.10   Security Considerations  . . . . . . . . . . . . . . . .  32
       B.10.1   Authentication of Clients  . . . . . . . . . . . . .  32
       B.10.2   Privacy Issues Connected to Locks  . . . . . . . . .  33
     B.11   IANA Considerations  . . . . . . . . . . . . . . . . . .  33
   C.   GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
   D.   Resolved issues (to be removed by RFC Editor before
        publication) . . . . . . . . . . . . . . . . . . . . . . . .  34
     D.1  040_LOCK_ISSUES  . . . . . . . . . . . . . . . . . . . . .  34
     D.2  058_LOCK_SEIZURE . . . . . . . . . . . . . . . . . . . . .  34
     D.3  093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK  . . . .  35
     D.4  096_SHARED_LOCKS_INTEROP_NOT_TESTED  . . . . . . . . . . .  35
   E.   Open issues (to be removed by RFC Editor prior to
        publication) . . . . . . . . . . . . . . . . . . . . . . . .  35
     E.1  extract-locking  . . . . . . . . . . . . . . . . . . . . .  35
     E.2  updated-rfc2068  . . . . . . . . . . . . . . . . . . . . .  35
     E.3  import-rfc3253-stuff . . . . . . . . . . . . . . . . . . .  36
     E.4  008_URI_URL  . . . . . . . . . . . . . . . . . . . . . . .  36
     E.5  015_MOVE_SECTION_6.4.1_TO_APPX . . . . . . . . . . . . . .  36
     E.6  022_COPY_OVERWRITE_LOCK_NULL . . . . . . . . . . . . . . .  36
     E.7  025_LOCK_REFRESH_BY_METHODS  . . . . . . . . . . . . . . .  37



Reschke                Expires November 19, 2004                [Page 3]


Internet-Draft           WebDAV URL constraints                 May 2004


     E.8  037_DEEP_LOCK_ERROR_STATUS . . . . . . . . . . . . . . . .  37
     E.9  039_MISSING_LOCK_TOKEN . . . . . . . . . . . . . . . . . .  37
     E.10   040_LOCK_ISSUES_01 . . . . . . . . . . . . . . . . . . .  38
     E.11   040_LOCK_ISSUES_02 . . . . . . . . . . . . . . . . . . .  38
     E.12   040_LOCK_ISSUES_03 . . . . . . . . . . . . . . . . . . .  38
     E.13   040_LOCK_ISSUES_04 . . . . . . . . . . . . . . . . . . .  39
     E.14   040_LOCK_ISSUES_05 . . . . . . . . . . . . . . . . . . .  39
     E.15   040_LOCK_ISSUES_06 . . . . . . . . . . . . . . . . . . .  40
     E.16   040_LOCK_ISSUES_07 . . . . . . . . . . . . . . . . . . .  40
     E.17   040_LOCK_ISSUES_08 . . . . . . . . . . . . . . . . . . .  41
     E.18   043_NULL_LOCK_SLASH_URL  . . . . . . . . . . . . . . . .  42
     E.19   044_REPORT_OTHER_RESOURCE_LOCKED . . . . . . . . . . . .  42
     E.20   052_LOCK_BODY_SHOULD_BE_MUST . . . . . . . . . . . . . .  43
     E.21   053_LOCK_INHERITANCE . . . . . . . . . . . . . . . . . .  43
     E.22   054_IF_AND_AUTH  . . . . . . . . . . . . . . . . . . . .  44
     E.23   056_DEPTH_LOCK_AND_IF  . . . . . . . . . . . . . . . . .  44
     E.24   057_LOCK_SEMANTICS . . . . . . . . . . . . . . . . . . .  44
     E.25   060_LOCK_REFRESH_BODY  . . . . . . . . . . . . . . . . .  44
     E.26   063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY . . . .  45
     E.27   065_UNLOCK_WHAT_URL  . . . . . . . . . . . . . . . . . .  45
     E.28   066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL  . . . . . .  46
     E.29   067_UNLOCK_NEEDS_IF_HEADER . . . . . . . . . . . . . . .  46
     E.30   068_UNLOCK_WITHOUT_GOOD_TOKEN  . . . . . . . . . . . . .  46
     E.31   070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER  . . . . . . .  46
     E.32   072_LOCK_URL_WITH_NO_PARENT_COLLECTION . . . . . . . . .  47
     E.33   073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE . . . . . . . . .  47
     E.34   077_LOCK_NULL_STATUS_CREATION  . . . . . . . . . . . . .  48
     E.35   079_UNLOCK_BY_NON_LOCK_OWNER . . . . . . . . . . . . . .  48
     E.36   080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC  . . . . . . . . .  48
     E.37   088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED . . . . . . . . .  49
     E.38   089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK . . . . . . . . . .  49
     E.39   099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION  . . . . .  49
     E.40   100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . .  49
     E.41   101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS . . .  50
     E.42   109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK . . . . . . . . . . .  50
     E.43   111_MULTIPLE_TOKENS_PER_LOCK . . . . . . . . . . . . . .  50
        Index  . . . . . . . . . . . . . . . . . . . . . . . . . . .  52
        Intellectual Property and Copyright Statements . . . . . . .  54













Reschke                Expires November 19, 2004                [Page 4]


Internet-Draft           WebDAV URL constraints                 May 2004


1.  Introduction

2.  Overview of Locking

3.  Properties

4.  LOCK Method

5.  UNLOCK Method

6.  Additional status codes

7.  Additional method semantics for other Methods

8.  Capability discovery

9.  Security considerations

10.  Internationalization Considerations

   All internationalization considerations mentioned in [RFC2518] also
   apply to this document.

11.  IANA Considerations

   All IANA considerations mentioned in [RFC2518] also apply to this
   document.

12.  Acknowledgements

   This document is the collaborative product of

   o  the authors,

   o  the maintainers of the RFC2518bis - Jason Crawford and Lisa
      Dusseault - and

   o  the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron
      Goland, Del Jensen and Jim Whitehead.

   This document has also benefited from thoughtful discussion by Mark
   Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing,
   Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias
   Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV
   working group.






Reschke                Expires November 19, 2004                [Page 5]


Internet-Draft           WebDAV URL constraints                 May 2004


13  Normative References

   [ISO-11578]
              International Organization for Standardization, "ISO/IEC
              11578:1996. Information technology - Open Systems
              Interconnection - Remote Procedure Call (RPC)", 1996.

   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
              RFC 2068, January 1997.

   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
              Jensen, "HTTP Extensions for Distributed Authoring --
              WEBDAV", RFC 2518, February 1999.

   [RFC3253]  Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
              Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
              March 2002.

   [3]  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>


Author's Address

   Julian F. Reschke
   greenbytes GmbH
   Salzmannstrasse 152
   Muenster, NW  48159
   Germany

   Phone: +49 251 2807760
   Fax:   +49 251 2807761
   EMail: julian.reschke@greenbytes.de
   URI:   http://greenbytes.de/tech/webdav/

Appendix A.  Changes to RFC2518

A.1  Removed/Deprecated features

A.2  Additional features features

A.3  Compatibility considerations

Appendix B.  Text to be integrated from RFC2518

B.1  Introduction

   Locking: The ability to keep more than one person from working on a



Reschke                Expires November 19, 2004                [Page 6]


Internet-Draft           WebDAV URL constraints                 May 2004


   document at the same time.  This prevents the "lost update problem,"
   in which modifications are lost as first one author then another
   writes changes without merging the other author's changes.

B.2  Locking

   The ability to lock a resource provides a mechanism for serializing
   access to that resource.  Using a lock, an authoring client can
   provide a reasonable guarantee that another principal will not modify
   a resource while it is being edited.  In this way, a client can
   prevent the "lost update" problem.

   This specification allows locks to vary over two client-specified
   parameters, the number of principals involved (exclusive vs.  shared)
   and the type of access to be granted.  This document defines locking
   for only one access type, write.  However, the syntax is extensible,
   and permits the eventual specification of locking for other access
   types.

B.2.1  Exclusive Vs. Shared Locks

   The most basic form of lock is an exclusive lock.  This is a lock
   where the access right in question is only granted to a single
   principal.  The need for this arbitration results from a desire to
   avoid having to merge results.

   However, there are times when the goal of a lock is not to exclude
   others from exercising an access right but rather to provide a
   mechanism for principals to indicate that they intend to exercise
   their access rights.  Shared locks are provided for this case.  A
   shared lock allows multiple principals to receive a lock.  Hence any
   principal with appropriate access can get the lock.

   With shared locks there are two trust sets that affect a resource.
   The first trust set is created by access permissions.  Principals who
   are trusted, for example, may have permission to write to the
   resource.  Among those who have access permission to write to the
   resource, the set of principals who have taken out a shared lock also
   must trust each other, creating a (typically) smaller trust set
   within the access permission write set.

   Starting with every possible principal on the Internet, in most
   situations the vast majority of these principals will not have write
   access to a given resource.  Of the small number who do have write
   access, some principals may decide to guarantee their edits are free
   from overwrite conflicts by using exclusive write locks.  Others may
   decide they trust their collaborators will not overwrite their work
   (the potential set of collaborators being the set of principals who



Reschke                Expires November 19, 2004                [Page 7]


Internet-Draft           WebDAV URL constraints                 May 2004


   have write permission) and use a shared lock, which informs their
   collaborators that a principal may be working on the resource.

   The WebDAV extensions to HTTP do not need to provide all of the
   communications paths necessary for principals to coordinate their
   activities.  When using shared locks, principals may use any out of
   band communication channel to coordinate their work (e.g.,
   face-to-face interaction, written notes, post-it notes on the screen,
   telephone conversation, Email, etc.)  The intent of a shared lock is
   to let collaborators know who else may be working on a resource.

   Shared locks are included because experience from web distributed
   authoring systems has indicated that exclusive locks are often too
   rigid.  An exclusive lock is used to enforce a particular editing
   process: take out an exclusive lock, read the resource, perform
   edits, write the resource, release the lock.  This editing process
   has the problem that locks are not always properly released, for
   example when a program crashes, or when a lock owner leaves without
   unlocking a resource.  While both timeouts and administrative action
   can be used to remove an offending lock, neither mechanism may be
   available when needed; the timeout may be long or the administrator
   may not be available.

B.2.2  Required Support

   A WebDAV compliant server is not required to support locking in any
   form.  If the server does support locking it may choose to support
   any combination of exclusive and shared locks for any access types.

   The reason for this flexibility is that locking policy strikes to the
   very heart of the resource management and versioning systems employed
   by various storage repositories.  These repositories require control
   over what sort of locking will be made available.  For example, some
   repositories only support shared write locks while others only
   provide support for exclusive write locks while yet others use no
   locking at all.  As each system is sufficiently different to merit
   exclusion of certain locking features, this specification leaves
   locking as the sole axis of negotiation within WebDAV.

B.2.3  Lock Tokens

   A lock token is a type of state token, represented as a URI, which
   identifies a particular lock.  A lock token is returned by every
   successful LOCK operation in the lockdiscovery property in the
   response body, and can also be found through lock discovery on a
   resource.

   Lock token URIs MUST be unique across all resources for all time.



Reschke                Expires November 19, 2004                [Page 8]


Internet-Draft           WebDAV URL constraints                 May 2004


   This uniqueness constraint allows lock tokens to be submitted across
   resources and servers without fear of confusion.

   This specification provides a lock token URI scheme called
   opaquelocktoken that meets the uniqueness requirements.  However
   resources are free to return any URI scheme so long as it meets the
   uniqueness requirements.

   Having a lock token provides no special access rights.  Anyone can
   find out anyone else's lock token by performing lock discovery.
   Locks MUST be enforced based upon whatever authentication mechanism
   is used by the server, not based on the secrecy of the token values.

B.2.4  opaquelocktoken Lock Token URI Scheme

   The opaquelocktoken URI scheme is designed to be unique across all
   resources for all time.  Due to this uniqueness quality, a client may
   submit an opaque lock token in an If header on a resource other than
   the one that returned it.

   All resources MUST recognize the opaquelocktoken scheme and, at
   minimum, recognize that the lock token does not refer to an
   outstanding lock on the resource.

   In order to guarantee uniqueness across all resources for all time
   the opaquelocktoken requires the use of the Universal Unique
   Identifier (UUID) mechanism, as described in [ISO-11578].

   Opaquelocktoken generators, however, have a choice of how they create
   these tokens.  They can either generate a new UUID for every lock
   token they create or they can create a single UUID  and then add
   extension characters.  If the second method is selected then the
   program generating the extensions MUST guarantee that the same
   extension will never be used twice with the associated UUID.

   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
   production is the string representation of a UUID, as defined in
   [ISO-11578].  Note that white space (LWS) is not allowed between
   elements of this production.

   Extension = path  ; path is defined in section 3.2.1 of RFC 2068
   [RFC2068]

B.2.4.1  Node Field Generation Without the IEEE 802 Address

   UUIDs, as defined in [ISO-11578], contain a "node" field that
   contains one of the IEEE 802 addresses for the server machine.  As
   noted in Appendix B.10.2, there are several security risks associated



Reschke                Expires November 19, 2004                [Page 9]


Internet-Draft           WebDAV URL constraints                 May 2004


   with exposing a machine's IEEE 802 address.  This section provides an
   alternate mechanism for generating the "node" field of a UUID which
   does not employ an IEEE 802 address.  WebDAV servers MAY use this
   algorithm for creating the node field when generating UUIDs.  The
   text in this section is originally from an Internet-Draft by Paul
   Leach and Rich Salz, who are noted here to properly attribute their
   work.

   The ideal solution is to obtain a 47 bit cryptographic quality random
   number, and use it as the low 47 bits of the node ID, with the most
   significant bit of the first octet of the node ID set to 1.  This bit
   is the unicast/multicast bit, which will never be set in IEEE 802
   addresses obtained from network cards; hence, there can never be a
   conflict between UUIDs generated by machines with and without network
   cards.

   If a system does not have a primitive to generate cryptographic
   quality random numbers, then in most systems there are usually a
   fairly large number of sources of randomness available from which one
   can be generated.  Such sources are system specific, but often
   include:

   o  the percent of memory in use

   o  the size of main memory in bytes

   o  the amount of free main memory in bytes

   o  the size of the paging or swap file in bytes

   o  free bytes of paging or swap file

   o  the total size of user virtual address space in bytes

   o  the total available user address space bytes

   o  the size of boot disk drive in bytes

   o  the free disk space on boot drive in bytes

   o  the current time

   o  the amount of time since the system booted

   o  the individual sizes of files in various system directories

   o  the creation, last read, and modification times of files in
      various system directories



Reschke                Expires November 19, 2004               [Page 10]


Internet-Draft           WebDAV URL constraints                 May 2004


   o  the utilization factors of various system resources (heap, etc.)

   o  current mouse cursor position

   o  current caret position

   o  current number of running processes, threads

   o  handles or IDs of the desktop window and the active window

   o  the value of stack pointer of the caller

   o  the process and thread ID of caller

   o  various processor architecture specific performance counters
      (instructions executed, cache misses, TLB misses)

   (Note that it is precisely the above kinds of sources of randomness
   that are used to seed cryptographic quality random number generators
   on systems without special hardware for their construction.)

   In addition, items such as the computer's name and the name of the
   operating system, while not strictly speaking random, will help
   differentiate the results from those obtained by other systems.

   The exact algorithm to generate a node ID using these data is system
   specific, because both the data available and the functions to obtain
   them are often very system specific.  However, assuming that one can
   concatenate all the values from the randomness sources into a buffer,
   and that a cryptographic hash function such as MD5 is available, then
   any 6 bytes of the MD5 hash of the buffer, with the multicast bit
   (the high bit of the first byte) set will be an appropriately random
   node ID.

   Other hash functions, such as SHA-1, can also be used.  The only
   requirement is that the result be suitably random _ in the sense that
   the outputs from a set uniformly distributed inputs are themselves
   uniformly distributed, and that a single bit change in the input can
   be expected to cause half of the output bits to change.

B.2.5  Lock Capability Discovery

   Since server lock support is optional, a client trying to lock a
   resource on a server can either try the lock and hope for the best,
   or perform some form of discovery to determine what lock capabilities
   the server supports.  This is known as lock capability discovery.
   Lock capability discovery differs from discovery of supported access
   control types, since there may be access control types without



Reschke                Expires November 19, 2004               [Page 11]


Internet-Draft           WebDAV URL constraints                 May 2004


   corresponding lock types.  A client can determine what lock types the
   server supports by retrieving the supportedlock property.

   Any DAV compliant resource that supports the LOCK method MUST support
   the supportedlock property.

B.2.6  Active Lock Discovery

   If another principal locks a resource that a principal wishes to
   access, it is useful for the second principal to be able to find out
   who the first principal is.  For this purpose the lockdiscovery
   property is provided.  This property lists all outstanding locks,
   describes their type, and where available, provides their lock token.

   Any DAV compliant resource that supports the LOCK method MUST support
   the lockdiscovery property.

B.2.7  Usage Considerations

   Although the locking mechanisms specified here provide some help in
   preventing lost updates, they cannot guarantee that updates will
   never be lost.  Consider the following scenario:

   Two clients A and B are interested in editing the resource '
   index.html'.  Client A is an HTTP client rather than a WebDAV client,
   and so does not know how to perform locking.

   Client A doesn't lock the document, but does a GET and begins
   editing.

   Client B does LOCK, performs a GET and begins editing.

   Client B finishes editing, performs a PUT, then an UNLOCK.

   Client A performs a PUT, overwriting and losing all of B's changes.

   There are several reasons why the WebDAV protocol itself cannot
   prevent this situation.  First, it cannot force all clients to use
   locking because it must be compatible with HTTP clients that do not
   comprehend locking.  Second, it cannot require servers to support
   locking because of the variety of repository implementations, some of
   which rely on reservations and merging rather than on locking.
   Finally, being stateless, it cannot enforce a sequence of operations
   like LOCK / GET / PUT / UNLOCK.

   WebDAV servers that support locking can reduce the likelihood that
   clients will accidentally overwrite each other's changes by requiring
   clients to lock resources before modifying them.  Such servers would



Reschke                Expires November 19, 2004               [Page 12]


Internet-Draft           WebDAV URL constraints                 May 2004


   effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
   resources.

   WebDAV clients can be good citizens by using a lock / retrieve /
   write /unlock sequence of operations (at least by default) whenever
   they interact with a WebDAV server that supports locking.

   HTTP 1.1 clients can be good citizens, avoiding overwriting other
   clients' changes, by using entity tags in If-Match headers with any
   requests that would modify resources.

   Information managers may attempt to prevent overwrites by
   implementing client-side procedures requiring locking before
   modifying WebDAV resources.

B.3  Write Lock

   This section describes the semantics specific to the write lock type.
   The write lock is a specific instance of a lock type, and is the only
   lock type described in this specification.

B.3.1  Methods Restricted by Write Locks

   A write lock MUST prevent a principal without the lock from
   successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
   DELETE, or MKCOL on the locked resource.  All other current methods,
   GET in particular, function independently of the lock.

   Note, however, that as new methods are created it will be necessary
   to specify how they interact with a write lock.

B.3.2  Write Locks and Lock Tokens

   A successful request for an exclusive or shared write lock MUST
   result in the generation of a unique lock token associated with the
   requesting principal.  Thus if five principals have a shared write
   lock on the same resource there will be five lock tokens, one for
   each principal.

B.3.3  Write Locks and Properties

   While those without a write lock may not alter a property on a
   resource it is still possible for the values of live properties to
   change, even while locked, due to the requirements of their schemas.
   Only dead properties and live properties defined to respect locks are
   guaranteed not to change while write locked.





Reschke                Expires November 19, 2004               [Page 13]


Internet-Draft           WebDAV URL constraints                 May 2004


B.3.4  Write Locks and Null Resources

   It is possible to assert a write lock on a null resource in order to
   lock the name.

   A write locked null resource, referred to as a lock-null resource,
   MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
   any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
   LOCK, and UNLOCK.  A lock-null resource MUST appear as a member of
   its parent collection.  Additionally the lock-null resource MUST have
   defined on it all mandatory DAV properties.  Most of these
   properties, such as all the get* properties, will have no value as a
   lock-null resource does not support the GET method.  Lock-Null
   resources MUST have defined values for lockdiscovery and
   supportedlock properties.

   Until a method such as PUT or MKCOL is successfully executed on the
   lock-null resource the resource MUST stay in the lock-null state.
   However, once a PUT or MKCOL is successfully executed on a lock-null
   resource the resource ceases to be in the lock-null state.

   If the resource is unlocked, for any reason, without a PUT, MKCOL, or
   similar method having been successfully executed upon it then the
   resource MUST return to the null state.

B.3.5  Write Locks and Collections

   A write lock on a collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URIs of the collection by non-lock owners.  As a consequence,
   when a principal issues a PUT or POST request to create a new
   resource under a URI which needs to be an internal member of a write
   locked collection to maintain HTTP namespace consistency, or issues a
   DELETE to remove a resource which has a URI which is an existing
   internal member URI of a write locked collection, this request MUST
   fail if the principal does not have a write lock on the collection.

   However, if a write lock request is issued to a collection containing
   member URIs identifying resources that are currently locked in a
   manner which conflicts with the write lock, the request MUST fail
   with a 423 (Locked) status code.

   If a lock owner causes the URI of a resource to be added as an
   internal member URI of a locked collection then the new resource MUST
   be automatically added to the lock.  This is the only mechanism that
   allows a resource to be added to a write lock.  Thus, for example, if
   the collection /a/b/ is write locked and the resource /c is moved to
   /a/b/c then resource /a/b/c will be added to the write lock.



Reschke                Expires November 19, 2004               [Page 14]


Internet-Draft           WebDAV URL constraints                 May 2004


B.3.6  Write Locks and the If Request Header

   If a user agent is not required to have knowledge about a lock when
   requesting an operation on a locked resource, the following scenario
   might occur.  Program A, run by User A, takes out a write lock on a
   resource.  Program B, also run by User A, has no knowledge of the
   lock taken out by Program A, yet performs a PUT to the locked
   resource.  In this scenario, the PUT succeeds because locks are
   associated with a principal, not a program, and thus program B,
   because it is acting with principal A's credential, is allowed to
   perform the PUT.  However, had program B known about the lock, it
   would not have overwritten the resource, preferring instead to
   present a dialog box describing the conflict to the user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by other programs with the
   same authorization.

   In order to prevent these collisions a lock token MUST be submitted
   by an authorized principal in the If header for all locked resources
   that a method may interact with or the method MUST fail.  For
   example, if a resource is to be moved and both the source and
   destination are locked then two lock tokens must be submitted, one
   for the source and the other for the destination.

B.3.6.1  Example - Write Lock

   >>Request

      COPY /~fielding/index.html HTTP/1.1
      Host: www.ics.uci.edu
      Destination: http://www.ics.uci.edu/users/f/fielding/index.html
      If: <http://www.ics.uci.edu/users/f/fielding/index.html>
          (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

   >>Response

      HTTP/1.1 204 No Content

   In this example, even though both the source and destination are
   locked, only one lock token must be submitted, for the lock on the
   destination.  This is because the source resource is not modified by
   a COPY, and hence unaffected by the write lock.  In this example,
   user agent authentication has previously occurred via a mechanism
   outside the scope of the HTTP protocol, in the underlying transport
   layer.






Reschke                Expires November 19, 2004               [Page 15]


Internet-Draft           WebDAV URL constraints                 May 2004


B.3.7  Write Locks and COPY/MOVE

   A COPY method invocation MUST NOT duplicate any write locks active on
   the source.  However, as previously noted, if the COPY copies the
   resource into a collection that is locked with "Depth: infinity",
   then the resource will be added to the lock.

   A successful MOVE request on a write locked resource MUST NOT move
   the write lock with the resource.  However, the resource is subject
   to being added to an existing lock at the destination, as specified
   in Appendix B.3.5.  For example, if the MOVE makes the resource a
   child of a collection that is locked with "Depth: infinity", then the
   resource will be added to that collection's lock.  Additionally, if a
   resource locked with "Depth: infinity" is moved to a destination that
   is within the scope of the same lock (e.g., within the namespace tree
   covered by the lock), the moved resource will again be a added to the
   lock.  In both these examples, as specified in Appendix B.3.6, an If
   header must be submitted containing a lock token for both the source
   and destination.

B.3.8  Refreshing Write Locks

   A client MUST NOT submit the same write lock request twice.  Note
   that a client is always aware it is resubmitting the same lock
   request because it must include the lock token in the If header in
   order to make the request for a resource that is already locked.

   However, a client may submit a LOCK method with an If header but
   without a body.  This form of LOCK MUST only be used to "refresh" a
   lock.  Meaning, at minimum, that any timers associated with the lock
   MUST be re-set.

   A server may return a Timeout header with a lock refresh that is
   different than the Timeout header returned when the lock was
   originally requested.  Additionally clients may submit Timeout
   headers of arbitrary value with their lock refresh requests.
   Servers, as always, may ignore Timeout headers submitted by the
   client.

   If an error is received in response to a refresh LOCK request the
   client SHOULD assume that the lock was not refreshed.

B.4  HTTP Headers for Distributed Authoring

B.4.1  LOCK Method

   The following sections describe the LOCK method, which is used to
   take out a lock of any access type.  These sections on the LOCK



Reschke                Expires November 19, 2004               [Page 16]


Internet-Draft           WebDAV URL constraints                 May 2004


   method describe only those semantics that are specific to the LOCK
   method and are independent of the access type of the lock being
   requested.

   Any resource which supports the LOCK method MUST, at minimum, support
   the XML request and response formats defined herein.

B.4.1.1  Operation

   A LOCK method invocation creates the lock specified by the lockinfo
   XML element on the Request-URI.  Lock method requests SHOULD have a
   XML request body which contains an owner XML element for this lock
   request, unless this is a refresh request.  The LOCK request may have
   a Timeout header.

   Clients MUST assume that locks may arbitrarily disappear at any time,
   regardless of the value given in the Timeout header.  The Timeout
   header only indicates the behavior of the server if "extraordinary"
   circumstances do not occur.  For example, an administrator may remove
   a lock at any time or the system may crash in such a way that it
   loses the record of the lock's existence.  The response MUST contain
   the value of the lockdiscovery property in a prop XML element.

   In order to indicate the lock token associated with a newly created
   lock, a Lock-Token response header MUST be included in the response
   for every successful LOCK request for a new lock.  Note that the
   Lock-Token header would not be returned in the response for a
   successful refresh LOCK request because a new lock was not created.

B.4.1.2  The Effect of Locks on Properties and Collections

   The scope of a lock is the entire state of the resource, including
   its body and associated properties.  As a result, a lock on a
   resource MUST also lock the resource's properties.

   For collections, a lock also affects the ability to add or remove
   members.  The nature of the effect depends upon the type of access
   control involved.

B.4.1.3  Locking Replicated Resources

   A resource may be made available through more than one URI.  However
   locks apply to resources, not URIs.  Therefore a LOCK request on a
   resource MUST NOT succeed if can not be honored by all the URIs
   through which the resource is addressable.






Reschke                Expires November 19, 2004               [Page 17]


Internet-Draft           WebDAV URL constraints                 May 2004


B.4.1.4  Depth and Locking

   The Depth header may be used with the LOCK method.  Values other than
   0 or infinity MUST NOT be used with the Depth header on a LOCK
   method.  All resources that support the LOCK method MUST support the
   Depth header.

   A Depth header of value 0 means to just lock the resource specified
   by the Request-URI.

   If the Depth header is set to infinity then the resource specified in
   the Request-URI along with all its internal members, all the way down
   the hierarchy, are to be locked.  A successful result MUST return a
   single lock token which represents all the resources that have been
   locked.  If an UNLOCK is successfully executed on this token, all
   associated resources are unlocked.  If the lock cannot be granted to
   all resources, a 409 (Conflict) status code MUST be returned with a
   response entity body containing a multistatus XML element describing
   which resource(s) prevented the lock from being granted.  Hence,
   partial success is not an option.  Either the entire hierarchy is
   locked or no resources are locked.

   If no Depth header is submitted on a LOCK request then the request
   MUST act as if a "Depth:infinity" had been submitted.

B.4.1.5  Interaction with other Methods

   The interaction of a LOCK with various methods is dependent upon the
   lock type.  However, independent of lock type, a successful DELETE of
   a resource MUST cause all of its locks to be removed.

B.4.1.6  Lock Compatibility Table

   The table below describes the behavior that occurs when a lock
   request is made on a resource.

   +-------------------------+--------------------+--------------------+
   | Current lock state /    | Shared Lock        | Exclusive Lock     |
   | Lock request            |                    |                    |
   +-------------------------+--------------------+--------------------+
   | None                    | True               | True               |
   | Shared Lock             | True               | False              |
   | Exclusive Lock          | False              | False*             |
   +-------------------------+--------------------+--------------------+

   Legend: True = lock may be granted.  False = lock MUST NOT be
   granted.  *=It is illegal for a principal to request the same lock
   twice.



Reschke                Expires November 19, 2004               [Page 18]


Internet-Draft           WebDAV URL constraints                 May 2004


   The current lock state of a resource is given in the leftmost column,
   and lock requests are listed in the first row.  The intersection of a
   row and column gives the result of a lock request.  For example, if a
   shared lock is held on a resource, and an exclusive lock is
   requested, the table entry is "false", indicating the lock must not
   be granted.

B.4.1.7  Status Codes

   200 (OK) - The lock request succeeded and the value of the
   lockdiscovery property is included in the body.

   412 (Precondition Failed) - The included lock token was not
   enforceable on this resource or the server could not satisfy the
   request in the lockinfo XML element.

   423 (Locked) - The resource is locked, so the method has been
   rejected.

B.4.1.8  Example - Simple Lock Request

   >>Request

      LOCK /workspace/webdav/proposal.doc HTTP/1.1
      Host: webdav.sb.aol.com
      Timeout: Infinite, Second-4100000000
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx
      Authorization: Digest username="ejw",
         realm="ejw@webdav.sb.aol.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

      <?xml version="1.0" encoding="utf-8" ?>
      <D:lockinfo xmlns:D='DAV:'>
        <D:lockscope><D:exclusive/></D:lockscope>
        <D:locktype><D:write/></D:locktype>
        <D:owner>
             <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
        </D:owner>
      </D:lockinfo>










Reschke                Expires November 19, 2004               [Page 19]


Internet-Draft           WebDAV URL constraints                 May 2004


   >>Response

      HTTP/1.1 200 OK
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:prop xmlns:D="DAV:">
        <D:lockdiscovery>
             <D:activelock>
                  <D:locktype><D:write/></D:locktype>
                  <D:lockscope><D:exclusive/></D:lockscope>
                  <D:depth>Infinity</D:depth>
                  <D:owner>
                       <D:href>
                            http://www.ics.uci.edu/~ejw/contact.html
                       </D:href>
                  </D:owner>
                  <D:timeout>Second-604800</D:timeout>
                  <D:locktoken>
                       <D:href>
                  opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                       </D:href>
                  </D:locktoken>
             </D:activelock>
        </D:lockdiscovery>
      </D:prop>

   This example shows the successful creation of an exclusive write lock
   on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
   The resource http://www.ics.uci.edu/~ejw/contact.html contains
   contact information for the owner of the lock.  The server has an
   activity-based timeout policy in place on this resource, which causes
   the lock to automatically be removed after 1 week (604800 seconds).
   Note that the nonce, response, and opaque fields have not been
   calculated in the Authorization request header.















Reschke                Expires November 19, 2004               [Page 20]


Internet-Draft           WebDAV URL constraints                 May 2004


B.4.1.9  Example - Refreshing a Write Lock

   >>Request

      LOCK /workspace/webdav/proposal.doc HTTP/1.1
      Host: webdav.sb.aol.com
      Timeout: Infinite, Second-4100000000
      If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
      Authorization: Digest username="ejw",
         realm="ejw@webdav.sb.aol.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

   >>Response

      HTTP/1.1 200 OK
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:prop xmlns:D="DAV:">
        <D:lockdiscovery>
             <D:activelock>
                  <D:locktype><D:write/></D:locktype>
                  <D:lockscope><D:exclusive/></D:lockscope>
                  <D:depth>Infinity</D:depth>
                  <D:owner>
                       <D:href>
                       http://www.ics.uci.edu/~ejw/contact.html
                       </D:href>
                  </D:owner>
                  <D:timeout>Second-604800</D:timeout>
                  <D:locktoken>
                       <D:href>
                  opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                       </D:href>
                  </D:locktoken>
             </D:activelock>
        </D:lockdiscovery>
      </D:prop>

   This request would refresh the lock, resetting any time outs.  Notice
   that the client asked for an infinite time out but the server choose
   to ignore the request.  In this example, the nonce, response, and
   opaque fields have not been calculated in the Authorization request
   header.





Reschke                Expires November 19, 2004               [Page 21]


Internet-Draft           WebDAV URL constraints                 May 2004


B.4.1.10  Example - Multi-Resource Lock Request

   >>Request

      LOCK /webdav/ HTTP/1.1
      Host: webdav.sb.aol.com
      Timeout: Infinite, Second-4100000000
      Depth: infinity
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx
      Authorization: Digest username="ejw",
         realm="ejw@webdav.sb.aol.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

      <?xml version="1.0" encoding="utf-8" ?>
      <D:lockinfo xmlns:D="DAV:">
        <D:locktype><D:write/></D:locktype>
        <D:lockscope><D:exclusive/></D:lockscope>
        <D:owner>
             <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
        </D:owner>
      </D:lockinfo>

   >>Response

      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:">
        <D:response>
             <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
             <D:status>HTTP/1.1 403 Forbidden</D:status>
        </D:response>
        <D:response>
             <D:href>http://webdav.sb.aol.com/webdav/</D:href>
             <D:propstat>
                  <D:prop><D:lockdiscovery/></D:prop>
                  <D:status>HTTP/1.1 424 Failed Dependency</D:status>
             </D:propstat>
        </D:response>
      </D:multistatus>

   This example shows a request for an exclusive write lock on a
   collection and all its children.  In this request, the client has
   specified that it desires an infinite length lock, if available,



Reschke                Expires November 19, 2004               [Page 22]


Internet-Draft           WebDAV URL constraints                 May 2004


   otherwise a timeout of 4.1 billion seconds, if available.  The
   request entity body contains the contact information for the
   principal taking out the lock, in this case a web page URL.

   The error is a 403 (Forbidden) response on the resource
   http://webdav.sb.aol.com/webdav/secret.  Because this resource could
   not be locked, none of the resources were locked.  Note also that the
   lockdiscovery property for the Request-URI has been included as
   required.  In this example the lockdiscovery property is empty which
   means that there are no outstanding locks on the resource.

   In this example, the nonce, response, and opaque fields have not been
   calculated in the Authorization request header.

B.4.2  UNLOCK Method

   The UNLOCK method removes the lock identified by the lock token in
   the Lock-Token request header from the Request-URI, and all other
   resources included in the lock.  If all resources which have been
   locked under the submitted lock token can not be unlocked then the
   UNLOCK request MUST fail.

   Any DAV compliant resource which supports the LOCK method MUST
   support the UNLOCK method.

B.4.2.1  Example - UNLOCK

   >>Request

      UNLOCK /workspace/webdav/info.doc HTTP/1.1
      Host: webdav.sb.aol.com
      Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
      Authorization: Digest username="ejw",
         realm="ejw@webdav.sb.aol.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

   >>Response

      HTTP/1.1 204 No Content

   In this example, the lock identified by the lock token
   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
   successfully removed from the resource
   http://webdav.sb.aol.com/workspace/webdav/info.doc.  If this lock
   included more than just one resource, the lock is removed from all
   resources included in the lock.  The 204 (No Content) status code is
   used instead of 200 (OK) because there is no response entity body.



Reschke                Expires November 19, 2004               [Page 23]


Internet-Draft           WebDAV URL constraints                 May 2004


   In this example, the nonce, response, and opaque fields have not been
   calculated in the Authorization request header.

B.5  HTTP Headers for Distributed Authoring

B.5.1  DAV Header

   [[anchor47: Add description of compliance class "2". --reschke]]

B.5.2  Depth Header

   [[anchor48: Add "Depth" header considerations: --reschke]]

   If a resource, source or destination, within the scope of the method
   with a Depth header is locked in such a way as to prevent the
   successful execution of the method, then the lock token for that
   resource MUST be submitted with the request in the If request header.

B.5.3  If Header

   [[anchor49: Add "If" header considerations: --reschke]]

B.5.4  Lock-Token Header

      Lock-Token = "Lock-Token" ":" Coded-URL

   The Lock-Token request header is used with the UNLOCK method to
   identify the lock to be removed.  The lock token in the Lock-Token
   request header MUST identify a lock that contains the resource
   identified by Request-URI as a member.

   The Lock-Token response header is used with the LOCK method to
   indicate the lock token created as a result of a successful LOCK
   request to create a new lock.

B.5.5  Timeout Request Header

      TimeOut = "Timeout" ":" 1#TimeType
      TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
      DAVTimeOutVal = 1*digit
      Other = "Extend" field-value   ; See section 4.2 of [RFC2068]

   Clients may include Timeout headers in their LOCK requests.  However,
   the server is not required to honor or even consider these requests.
   Clients MUST NOT submit a Timeout request header with any method
   other than a LOCK method.

   A Timeout request header MUST contain at least one TimeType and may



Reschke                Expires November 19, 2004               [Page 24]


Internet-Draft           WebDAV URL constraints                 May 2004


   contain multiple TimeType entries.  The purpose of listing multiple
   TimeType entries is to indicate multiple different values and value
   types that are acceptable to the client.  The client lists the
   TimeType entries in order of preference.

   Timeout response values MUST use a Second value, Infinite, or a
   TimeType the client has indicated familiarity with.  The server may
   assume a client is familiar with any TimeType submitted in a Timeout
   header.

   The "Second" TimeType specifies the number of seconds that will
   elapse between granting of the lock at the server, and the automatic
   removal of the lock.  The timeout value for TimeType "Second" MUST
   NOT be greater than 2^32-1.

   The timeout counter SHOULD be restarted any time an owner of the lock
   sends a method to any member of the lock, including unsupported
   methods, or methods which are unsuccessful.  However the lock MUST be
   refreshed if a refresh LOCK method is successfully received.

   If the timeout expires then the lock may be lost.  Specifically, if
   the server wishes to harvest the lock upon time-out, the server
   SHOULD act as if an UNLOCK method was executed by the server on the
   resource using the lock token of the timed-out lock, performed with
   its override authority.  Thus logs should be updated with the
   disposition of the lock, notifications should be sent, etc., just as
   they would be for an UNLOCK request.

   Servers are advised to pay close attention to the values submitted by
   clients, as they will be indicative of the type of activity the
   client intends to perform.  For example, an applet running in a
   browser may need to lock a resource, but because of the instability
   of the environment within which the applet is running, the applet may
   be turned off without warning.  As a result, the applet is likely to
   ask for a relatively small timeout value so that if the applet dies,
   the lock can be quickly harvested.  However, a document management
   system is likely to ask for an extremely long timeout because its
   user may be planning on going off-line.

   A client MUST NOT assume that just because the time-out has expired
   the lock has been lost.

B.6  Status Code Extensions to HTTP/1.1

B.6.1  423 Locked

   The 423 (Locked) status code means the source or destination resource
   of a method is locked.



Reschke                Expires November 19, 2004               [Page 25]


Internet-Draft           WebDAV URL constraints                 May 2004


B.7  XML Element Definitions

B.7.1  activelock XML Element

   Name: activelock

   Namespace: DAV:

   Purpose: Describes a lock on a resource.


      <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
      locktoken?) >


B.7.1.1  depth XML Element

   Name: depth

   Namespace: DAV:

   Purpose: The value of the Depth header.

   Value: "0" | "1" | "infinity"


      <!ELEMENT depth (#PCDATA) >


B.7.1.2  locktoken XML Element

   Name: locktoken

   Namespace: DAV:

   Purpose: The lock token associated with a lock.  Description: The
      href contains one or more opaque lock token URIs which all refer
      to the same lock (i.e., the OpaqueLockToken-URI production in
      Appendix B.2.4).


      <!ELEMENT locktoken (href+) >


B.7.1.3  timeout XML Element






Reschke                Expires November 19, 2004               [Page 26]


Internet-Draft           WebDAV URL constraints                 May 2004


   Name: timeout

   Namespace: DAV:

   Purpose: The timeout associated with a lock

   Value: TimeType ;Defined in Appendix B.5.5


      <!ELEMENT timeout (#PCDATA) >


B.7.2  lockentry XML Element

   Name: lockentry

   Namespace: DAV:

   Purpose: Defines the types of locks that can be used with the
      resource.


      <!ELEMENT lockentry (lockscope, locktype) >


B.7.3  lockinfo XML Element

   Name: lockinfo

   Namespace: DAV:

   Purpose: The lockinfo XML element is used with a LOCK method to
      specify the type of lock the client wishes to have created.


      <!ELEMENT lockinfo (lockscope, locktype, owner?) >


B.7.4  lockscope XML Element

   Name: lockscope

   Namespace: DAV:

   Purpose: Specifies whether a lock is an exclusive lock, or a shared
      lock.





Reschke                Expires November 19, 2004               [Page 27]


Internet-Draft           WebDAV URL constraints                 May 2004


      <!ELEMENT lockscope (exclusive | shared) >


B.7.4.1  exclusive XML Element

   Name: exclusive

   Namespace: DAV:

   Purpose: Specifies an exclusive lock


      <!ELEMENT exclusive EMPTY >


B.7.4.2  shared XML Element

   Name: shared

   Namespace: DAV:

   Purpose: Specifies a shared lock


      <!ELEMENT shared EMPTY >


B.7.5  locktype XML Element

   Name: locktype

   Namespace: DAV:

   Purpose: Specifies the access type of a lock.  At present, this
      specification only defines one lock type, the write lock.


      <!ELEMENT locktype (write) >


B.7.5.1  write XML Element

   Name: write

   Namespace: DAV:






Reschke                Expires November 19, 2004               [Page 28]


Internet-Draft           WebDAV URL constraints                 May 2004


   Purpose: Specifies a write lock.


      <!ELEMENT write EMPTY >


B.7.6  owner XML Element

   Name: owner

   Namespace: DAV:

   Purpose: Provides information about the principal taking out a lock.

   Description: The owner XML element provides information sufficient
      for either directly contacting a principal (such as a telephone
      number or Email URI), or for discovering the principal (such as
      the URL of a homepage) who owns a lock.


      <!ELEMENT owner ANY>


B.8  DAV Properties

B.8.1  lockdiscovery Property

   Name: lockdiscovery

   Namespace: DAV:

   Purpose: Describes the active locks on a resource

   Description: The lockdiscovery property returns a listing of who has
      a lock, what type of lock he has, the timeout type and the time
      remaining on the timeout, and the associated lock token.  The
      server is free to withhold any or all of this information if the
      requesting principal does not have sufficient access rights to see
      the requested data.


      <!ELEMENT lockdiscovery (activelock)* >









Reschke                Expires November 19, 2004               [Page 29]


Internet-Draft           WebDAV URL constraints                 May 2004


B.8.1.1  Example - Retrieving the lockdiscovery Property

   >>Request

      PROPFIND /container/ HTTP/1.1
      Host: www.foo.bar
      Content-Length: xxxx
      Content-Type: text/xml; charset="utf-8"

      <?xml version="1.0" encoding="utf-8" ?>
      <D:propfind xmlns:D='DAV:'>
        <D:prop><D:lockdiscovery/></D:prop>
      </D:propfind>

   >>Response

      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:'>
        <D:response>
             <D:href>http://www.foo.bar/container/</D:href>
             <D:propstat>
                  <D:prop>
                       <D:lockdiscovery>
                            <D:activelock>
                                 <D:locktype><D:write/></D:locktype>
                                 <D:lockscope><D:exclusive/></D:lockscope>
                                 <D:depth>0</D:depth>
                                 <D:owner>Jane Smith</D:owner>
                                 <D:timeout>Infinite</D:timeout>
                                 <D:locktoken>
                                      <D:href>
                  opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
                                      </D:href>
                                 </D:locktoken>
                            </D:activelock>
                       </D:lockdiscovery>
                  </D:prop>
                  <D:status>HTTP/1.1 200 OK</D:status>
             </D:propstat>
        </D:response>
      </D:multistatus>

   This resource has a single exclusive write lock on it, with an
   infinite timeout.



Reschke                Expires November 19, 2004               [Page 30]


Internet-Draft           WebDAV URL constraints                 May 2004


B.8.2  supportedlock Property

   Name: supportedlock

   Namespace: DAV:

   Purpose: To provide a listing of the lock capabilities supported by
      the resource.

   Description: The supportedlock property of a resource returns a
      listing of the combinations of scope and access types which may be
      specified in a lock request on the resource.  Note that the actual
      contents are themselves controlled by access controls so a server
      is not required to provide information the client is not
      authorized to see.


      <!ELEMENT supportedlock (lockentry)* >


B.8.2.1  Example - Retrieving the supportedlock Property

   >>Request

      PROPFIND  /container/ HTTP/1.1
      Host: www.foo.bar
      Content-Length: xxxx
      Content-Type: text/xml; charset="utf-8"

      <?xml version="1.0" encoding="utf-8" ?>
      <D:propfind xmlns:D="DAV:">
        <D:prop><D:supportedlock/></D:prop>
      </D:propfind>


















Reschke                Expires November 19, 2004               [Page 31]


Internet-Draft           WebDAV URL constraints                 May 2004


   >>Response

      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:">
        <D:response>
             <D:href>http://www.foo.bar/container/</D:href>
             <D:propstat>
                  <D:prop>
                       <D:supportedlock>
                            <D:lockentry>
                                 <D:lockscope><D:exclusive/></D:lockscope>
                                 <D:locktype><D:write/></D:locktype>
                            </D:lockentry>
                            <D:lockentry>
                                 <D:lockscope><D:shared/></D:lockscope>
                                 <D:locktype><D:write/></D:locktype>
                            </D:lockentry>
                       </D:supportedlock>
                  </D:prop>
                  <D:status>HTTP/1.1 200 OK</D:status>
             </D:propstat>
        </D:response>
      </D:multistatus>


B.9  DAV Compliance Classes

B.9.1  Class 2

   A class 2 compliant resource MUST meet all class 1 requirements and
   support the LOCK method, the supportedlock property, the
   lockdiscovery property, the Time-Out response header and the
   Lock-Token request header.  A class "2" compliant resource SHOULD
   also support the Time-Out request header and the owner XML element.

   Class 2 compliant resources MUST return, at minimum, the values "1"
   and "2" in the DAV header on all responses to the OPTIONS method.

B.10  Security Considerations

B.10.1  Authentication of Clients

   Furthermore, the introduction of locking functionality requires
   support for authentication.



Reschke                Expires November 19, 2004               [Page 32]


Internet-Draft           WebDAV URL constraints                 May 2004


B.10.2  Privacy Issues Connected to Locks

   When submitting a lock request a user agent may also submit an owner
   XML field giving contact information for the person taking out the
   lock (for those cases where a person, rather than a robot, is taking
   out the lock).  This contact information is stored in a lockdiscovery
   property on the resource, and can be used by other collaborators to
   begin negotiation over access to the resource.  However, in many
   cases this contact information can be very private, and should not be
   widely disseminated.  Servers SHOULD limit read access to the
   lockdiscovery property as appropriate.  Furthermore, user agents
   SHOULD provide control over whether contact information is sent at
   all, and if contact information is sent, control over exactly what
   information is sent.

B.11  IANA Considerations

   This specification also defines a URI scheme for the encoding of lock
   tokens, the opaquelocktoken URI scheme described in Appendix B.2.4.

Appendix C.  GULP

   *Copied from *[3].

   o  A lock either directly or indirectly locks a resource.

   o  A LOCK request with a non-empty body creates a new lock, and the
      resource identified by the request-URL is directly locked by that
      lock.  The "lock-root" of the new lock is the request-URL.  If at
      the time of the request, the request-URL is not mapped to a
      resource, a new resource with no content MUST be created by the
      request.

   o  If a collection is directly locked by a depth:infinity lock, all
      members of that collection (other than the collection itself) are
      indirectly locked by that lock.  In particular, if an internal
      member resource is added to a collection that is locked by a
      depth:infinity lock, and if the resource is not locked by that
      lock, then the resource becomes indirectly locked by that lock.
      Conversely, if a resource is indirectly locked with a
      depth:infinity lock, and if the result of deleting an internal
      member URI is that the resource is no longer a member of the
      collection that is directly locked by that lock, then the resource
      is no longer locked by that lock.

   o  An UNLOCK request deletes the lock with the specified lock token.
      The request-URL of the request MUST identify the resource that is
      directly locked by that lock.  After a lock is deleted, no



Reschke                Expires November 19, 2004               [Page 33]


Internet-Draft           WebDAV URL constraints                 May 2004


      resource is locked by that lock.

   o  A lock token is "submitted" in a request when it appears in an If
      header.

   o  If a request would modify the content for a locked resource, a
      dead property of a locked resource, a live property that is
      defined to be lockable for a locked resource, or an internal
      member URI of a locked collection, the request MUST fail unless
      the lock-token for that lock is submitted in the request.  An
      internal member URI of a collection is considered to be modified
      if it is added, removed, or identifies a different resource.

   o  If a request causes a directly locked resource to no longer be
      mapped to the lock-root of that lock, then the request MUST fail
      unless the lock-token for that lock is submitted in the request.
      If the request succeeds, then that lock MUST have been deleted by
      that request.

   o  If a request would cause a resource to be locked by two different
      exclusive locks, the request MUST fail.


Appendix D.  Resolved issues (to be removed by RFC Editor before
            publication)

   Issues that were either rejected or resolved in this version of this
   document.

D.1  040_LOCK_ISSUES

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Jason Crawford's list of lock issues
   sent to the list.

   Resolution: Replace with list of distinct issues 040_LOCK_ISSUES_??.

D.2  058_LOCK_SEIZURE

   Type: change

   (): Should it be possible to seize a lock, or for any principal to
   unlock a lock, thus making it easier for another client to begin
   working on a locked resource.



Reschke                Expires November 19, 2004               [Page 34]


Internet-Draft           WebDAV URL constraints                 May 2004


   Resolution: Duplicated by UNLOCK_BY_NON_LOCK_OWNER issue.

D.3  093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0127.html>


   dbrotsky@adobe.com (): How does a client determine if a given lock
   was created by it?

   Resolution: It was resolved that this type of info would not be
   provided by the server.  The client creating the lock could store
   owner info in the DAV:owner field (or some field defined in the
   future) if it wishes.  The querying client can also check ACL's to
   get similar info.

D.4  096_SHARED_LOCKS_INTEROP_NOT_TESTED

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0165.html>


   lisa@xythos.com (): There might not be any implementations of shared
   locks.  If so, remove them.

   Resolution: The thread did conclude that shared locks interoperate
   although it doesn't look like they get used much.  Also see:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0139.html.


Appendix E.  Open issues (to be removed by RFC Editor prior to
            publication)

E.1  extract-locking

   Type: change

   julian.reschke@greenbytes.de (2004-04-14): Locking extracted from
   RFC2518.

E.2  updated-rfc2068

   Type: change

   julian.reschke@greenbytes.de (2004-04-25): Update references of



Reschke                Expires November 19, 2004               [Page 35]


Internet-Draft           WebDAV URL constraints                 May 2004


   RFC2068 to either RFC2396 or RFC2616.

E.3  import-rfc3253-stuff

   Type: change

   julian.reschke@greenbytes.de (2004-04-25): Import error marshalling
   and terminology from RFC3253.

E.4  008_URI_URL

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0142.html>


   masinter@parc.xerox.com (1998-11-09): Perform a thorough review of
   the specification to ensure that URI and URL are used correctly, and
   consistently throughout.

   Resolution: Seems to have been deferred:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html,
    but there is some follow on discussion on what exactly needs to be
   clarified:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html,
    but no specific action was concluded besides the fact that we don't
   need to wait for RFC2396 to be updated or request any changes/
   clarifications to that.

E.5  015_MOVE_SECTION_6.4.1_TO_APPX

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html>


   mda@discerning.com (1998-11-24): The discussion of generating UUID
   node fields without using the IEEE 802 address in section 6.4.1 can
   be moved to an appendix.

   julian.reschke@greenbytes.de (2004-04-24): Plan: get rid of the
   section altogether and refer to draft-mealling-uuid-urn.

E.6  022_COPY_OVERWRITE_LOCK_NULL

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0244.html>



Reschke                Expires November 19, 2004               [Page 36]


Internet-Draft           WebDAV URL constraints                 May 2004




   jdavis@parc.xerox.com (1998-11-29): If URL Ub is locked, creating a
   lock-null resource, then if a COPY is performed listing Ub as the
   destination, COPY will remove the lock-null resource, removing the
   lock, then perform the copy.  A note needs to be added stating that
   the delete performed by the Overwrite header is atomic with the rest
   of the operation.

   Resolution: LNRs removed.  See discussions preceding conclusion:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html.


E.7  025_LOCK_REFRESH_BY_METHODS

   Type: change

   (): Jim Amsden: The specification requires a lock to be refreshed if
   any method is executed, by anybody, on a locked resource.  This can
   cause some performance problems.  More importantly, the semantics of
   this refresh do not seem to be right -- why should a random GET by a
   third party cause all locks to be refreshed?

   Resolution: We should remove the mention of this behavior in 2518:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0137.html


E.8  037_DEEP_LOCK_ERROR_STATUS

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html>


   wiggs@wiggenout.com (1999-05-18): Section 8.10.4 states that if a
   lock cannot be granted to all resources in a hierarchy, a 409 status
   response must be issued.  Yet, the example in section 8.10.10 which
   demonstrates this uses a 207.

   julian.reschke@greenbytes.de (2004-04-24): Comment: 207 is correct,
   fix the bad spec text.

E.9  039_MISSING_LOCK_TOKEN

   Type: change

   <http://dav.lyra.org/pipermail/dav-dev/1999-June/000277.html>




Reschke                Expires November 19, 2004               [Page 37]


Internet-Draft           WebDAV URL constraints                 May 2004


   (1999-06-15): Keith Wannamaker: Section 8.10.1 explicitly states that
   the response from a successful lock request MUST include the
   Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10
   aren't compliant with this requirement, and should be updated.

   Resolution: Make obvious editing changes to the examples:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0229.html


E.10  040_LOCK_ISSUES_01

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Section 6.3: ""Having a lock token
   provides no special access rights..." I suggest that the phrase
   "owned by another party" be added in this first sentence to
   distinguish between owning and having.  It speaks of "having" in this
   sentence but not subsequently.  In fact "submitting" might be an even
   better word than having.

   julian.reschke@greenbytes.de (2004-04-24): Agreed, use "submitting".

E.11  040_LOCK_ISSUES_02

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Section 6.3: "...  However resource
   are free to return any URI scheme so long as it meets the uniqueness
   requirements." This is technically correct, but it might also be
   useful to say that the scheme should make the URI  be readily
   recognizable as a *LOCK* state token in the event that other types of
   state tokens exist.  I mention this because we seem to have created
   the possibility of other types of state tokens.  -- Your call.  :-)

   julian.reschke@greenbytes.de (2004-04-24): Disagreement: any URI
   scheme can be used as a lock token.  Specifications that define other
   types of state tokens will have to take care of distinguishing them
   inside an "If" header.

E.12  040_LOCK_ISSUES_03

   Type: change



Reschke                Expires November 19, 2004               [Page 38]


Internet-Draft           WebDAV URL constraints                 May 2004


   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Section 7.1 Write lock.  I believe
   this definition of a write lock is not right...  or not complete...
   judging from what I read elsewhere.  I believe one can do these
   operations without a write lock...  as long as someone else doesn't
   have a write lock on the resources effected.  I also believe it
   doesn't prevent LOCK requests in the case of shared locks.

   julian.reschke@greenbytes.de (2004-04-24): Clarify as part of
   rewriting the general semantics.  The point about shared locks is
   correct, though.

E.13  040_LOCK_ISSUES_04

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Section 7.5 Write Locks and
   Collections.  It says that if members are locked in a conflicting
   manner, then their collection can't be locked.  That seems
   ambiguously safe to say, but I suspect that text should mention depth
   since if the parent lock request is depth 0, I don't think we let the
   members lock state effect the success of the LOCK request.  The
   possible exception is what we said about protecting a URI that was
   used to perform a lock (of a member of the collection).  I'm not sure
   what we'd like to say for that.  In the advanced collection meetings
   we refered to these being "protected" and avoided speaking about
   "lock"ing the URI.  This creates an odd situation though.

E.14  040_LOCK_ISSUES_05

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): 7.7 Write Locks and COPY/MOVE It
   says that a lock doesn't move with a moved resource.  Of course if
   the lock is on the resource, not the URI, it should move with the
   resource.  But then we have the caveat that we are also protecting
   the LOCK'd URI.  I think the rule should be that if we submit the
   locktoken with the MOVE request, we are allowed to have the LOCK move
   with the resource and the lock will now protect a different URI.
   Also, ALL locks in the subtree must be submitted or the MOVE must



Reschke                Expires November 19, 2004               [Page 39]


Internet-Draft           WebDAV URL constraints                 May 2004


   fail because otherwise it would break our URI protection rule.

   julian.reschke@greenbytes.de (2004-04-24): Clarify as part of
   incorporating GULP (locks do not MOVE).

E.15  040_LOCK_ISSUES_06

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Upon cursory reading of the rfc 2518
   sec 8.10.4 through 8.11   I was confused by the plethoria of error
   codes.  Nothing seems to unify them.  8.10.4 speaks of a return code
   of 409 Conflict if a lock can't be granted.  - Firstly, I can't tell
   if it is saying that the 409 is within the multistatus body...  or in
   the response header.  - Secondly, later text seems to use a different
   status codes and never mentions this one again.  8.10.7 lists status
   codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed,
   but 409 Conflict (mentioned above) is not.  - In the case of 412
   Precondition Failed, the description the follows doesn't seem to
   describe a "precondition failed".  And it sounds like it's talking
   about an access request that includes a "locktoken", not a LOCK
   request that generates one.  - The 423 Locked condition also sort of
   sounds like it's talking about an access request rather than a LOCK
   request.  8.10.10 lists LOCK status codes - 207 Multistatus which was
   not mentioned above -  403 Forbidden which was not mentioned above.
   -  424 Failed dependency which was not mentioned above.  8.11 UNLOCK
   - we don't mention what the failure response should look like.  -
   comment: 200 OK seems like a better response than 204 No Content.
   The brief explanation isn't persuasive and seems to say that the
   response code should serve the purpose of the Content-Length.
   header.  - we should probably explicitly say if an UNLOCK can only be
   done on the original resource...  and will fail even if the resource
   specified is locked by virtue of being a child of the original
   resource.  Or is this too obvious?  I know it's something easy to
   goof up in an implementation.

E.16  040_LOCK_ISSUES_07

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): 9.4 If header - BNF suggests that
   IF's content must be all tagged or all untagged.  - doesn't say if



Reschke                Expires November 19, 2004               [Page 40]


Internet-Draft           WebDAV URL constraints                 May 2004


   there can be two If headers in a request.  Might we want a tagged one
   and an untagged one? - I must be misunderstanding this, but it sounds
   to me like that state of a resource(s) must match one of the
   locktokens listed in the request.  But what if some of the resources
   are locked and others are not.  The unlocked resources definitely
   won't contain state that's listed.  Are we precluding operations on
   regions that might not be entirely locked?  -- Is this a valid
   observation or a red herring? 9.4.1.1 If header - untagged example -
   See my comment about regions that are not entirely locked.  9.4.2 If
   header -tagged state - So if we've applied a lock with depth....  and
   now we're doing a DELETE on a subtree of that tree and we've tagged
   the locktoken we've submitted, will this prevent that locktoken from
   apply'ing to ALL the resources of the subtree...  and thus prevent
   the COPY from succeeding?  Or are we supposed to tag the lock token
   with the root of the LOCK even if that is not part of what we are
   deleting?   Or should the request use untagged locktokens? 9.4.3 If
   header - NOT operator - Why do we want this?   of course...  why not?
   :-) Overall, the If header seems backwards for locktokens.  It's
   client driven rather than server semantics driven.  The only feature
   it seems to provide is perhaps the ability for the client to request
   that the request be aborted if the resource no longer is locked.
   Other than that it seems to complicate the simple process of letting
   the server know what tokens you hold.  I'd think we'd just want a
   different header to declare what lock tokens we hold and let the
   server (not the client) decide how they affect the success of the
   request.

   julian.reschke@greenbytes.de (2004-04-24): This issue needs to be
   handled in the base protocol.

E.17  040_LOCK_ISSUES_08

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>


   ccjason@us.ibm.com (1999-06-07): Shared locks...  read locks...  Our
   justifcation for shared locks  ("Shared locks are included
   because....") seems faulty.  It's not a mechansim for dealing with
   programs that forget to release their locks.  That remains a problem
   with shared locks.  In this case they'd forget to release a shared
   lock and block exclusive lock users.  Timeouts and administrative
   action are the solutions to this problem...  not shared locks.  BTW,
   I'd think that the use of exclusive locks is just fine.  I do have a
   problem with shared locks though...  or at least shared write locks.
   Although they were relatively easy to define, I see them as solving a
   red herring problem of multiple entites cooperatively writing using



Reschke                Expires November 19, 2004               [Page 41]


Internet-Draft           WebDAV URL constraints                 May 2004


   distinct locks.  I say it's a red herring because they don't know
   each other well enough to use the same lock but they do know each
   other well enough to not step on each other.  This seems unlikely.
   As does the managing a compatibility matrix and getting all the
   entities to abide by it.  OTOH I see another more common problem that
   is being overlooked.  I see a class of folks whose purpose is to not
   actually write to a (set of) resource(s), but to simply prevent
   others from writing to it while they are looking at it.  Shared write
   locks do not necessarily do that because with a shared write lock.
   someone else could grab a shared lock and go ahead and write.  The
   only way to block that is to get an exclusive write lock.  But doing
   that prevents anyone else from doing what you're doing despite it
   being pretty benign.  An expedient solution is to say that a shared
   write lock should not necessarily give one the right to modify a
   resource.  All it should do is prevent others from writing.  And then
   the purpose of an exclusive write lock is just to insure that others
   can't get a lock and block you from writing.  Now is this the right
   solution?  Probably not.  There probably should be something called a
   read lock that actually prevents writes as a side effect....  and
   would tend to get used in shared mode.  Anyway, as it is, I think the
   shared write locks are a red herring and we're missing something we
   are more likely to need...  shared read locks.

   julian.reschke@greenbytes.de (2004-04-24): Agreement that the
   rational for shared locks either needs to be rewritten or deleted.
   However shared locks are a fact, and we shouldn't change the
   semantics given in RFC2518.

E.18  043_NULL_LOCK_SLASH_URL

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html>


   wiggs@xythos.com (1999-07-23): If a URL ending in a slash is null
   locked, is it legal to do a PUT to it? That is, does the URL ending
   in slash set the resource type to a collection, or does the first
   PUT/MKCOL set the resource to a ordinary, or collection resource.

   Resolution: LNRs removed.  See discussions preceding conclusion:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html


E.19  044_REPORT_OTHER_RESOURCE_LOCKED

   Type: change




Reschke                Expires November 19, 2004               [Page 42]


Internet-Draft           WebDAV URL constraints                 May 2004


   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html>


   wiggs@xythos.com (1999-07-23): In some cases, such as when the parent
   collection of a resource is locked, a 423 (Locked) status code is
   returned even though the resource identified by the Request-URI is
   not locked.  This can be confusing, since it is not possible for a
   client to easily discover which resource is causing the locked status
   code to be returned.  An improved status report would indicate the
   resource causing the lock message.

   julian.reschke@greenbytes.de (2004-04-25): Proposal to define a
   specific precondition element plus specific child elements similar to
   ACL, section 7.1.1.

E.20  052_LOCK_BODY_SHOULD_BE_MUST

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0224.html>


   gstein@lyra.org (1999-11-23): Section 8.10.1 states that a LOCK
   method request SHOULD have an XML request body.  This SHOULD should
   instead be MUST.

   julian.reschke@greenbytes.de (2004-04-25): Clarify that for creating
   LOCKs, it MUST have a request body which SHOULD have the DAV:owner
   element.  For LOCK refreshes, no body is required.

E.21  053_LOCK_INHERITANCE

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0250.html>


   jrd3@alum.mit.edu (1999-11-26): Section 7.5 states, "If a lock owner
   causes the URI of a resource to be added as an internal member URI of
   a locked collection then the new resource MUST be automatically added
   to the lock." However, though this is the intent, the specification
   does not explicitly state that this behavior only applies to depth
   infinity locked collections.  The words "Depth infinity" should be
   added before the word "locked" in this sentence.

   julian.reschke@greenbytes.de (2004-04-25): Clarify as part of
   integrating GULP.




Reschke                Expires November 19, 2004               [Page 43]


Internet-Draft           WebDAV URL constraints                 May 2004


E.22  054_IF_AND_AUTH

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0211.html>


   geoffrey.clemm@rational.com (2000-01-27): The fact that use of
   authentication credentials with submission of lock tokens is required
   should be strengthened in the document.

   julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token
   in an If header (usages != UNLOCK) SHOULD be restricted to whatever
   the server thinks the "owner" of the lock is.

E.23  056_DEPTH_LOCK_AND_IF

   Type: change

   <http://dav.lyra.org/pipermail/dav-dev/2000-March/000830.html>

   joe@orton.demon.co.uk (2000-03-04): The specification is currently
   silent on how to use the If header for submitting a locktoken when
   performing a DELETE in a Depth infinity locked collection.  Should
   the If header have both the collection URL and the Request-URI, or
   just the Request-URI? An example of this is needed.

   julian.reschke@greenbytes.de (2004-04-25): Clarify as part of
   integrating GULP.  May need to test interop with existing
   implementations.

E.24  057_LOCK_SEMANTICS

   Type: change

   (): At present, the WebDAV specification is not excruciatingly
   explicit that writing to a locked resource requires the combination
   of the lock token, plus an authentication principal.  At one point,
   the spec.  discusses an "authorized" principal, but "authorized" is
   never explicitly defined.

   julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token
   in an If header (usages != UNLOCK) SHOULD be restricted to whatever
   the server thinks the "owner" of the lock is.

E.25  060_LOCK_REFRESH_BODY

   Type: change



Reschke                Expires November 19, 2004               [Page 44]


Internet-Draft           WebDAV URL constraints                 May 2004


   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html>


   rickard.falk@excosoft.se (2000-07-11): Section 7.8 of RFC 2518
   indicates that clients may submit a lock refresh without a body.
   However, it implies that clients could submit a lock refresh with a
   body.  Server implementations have been disallowing a lock refresh
   with a body.  It might make sense to codify this practice, and
   disallow submission of a body on a lock refresh.

   julian.reschke@greenbytes.de (2004-04-25): Clarify that LOCK refresh
   MUST NOT have a request body.  Also clarify Lock-Token header vs If
   header.

E.26  063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

   Type: change

   jrd3@alum.mit.edu (): Is the complexity of the IF header appropriate
   for the simple task o verifying that a client knowingly owns a lock?
   The IF header seems to serve a different purpose.  One of those
   purposes is for the server to verify that you have the lock token
   (and that you know the root of it?).  Another is for the client to
   check some preconditions before doing an action.  Another seems to be
   to specify what lock to refresh in a lock refresh request.  This
   seems to create ambiguity in our definition of the semantics of the
   IF: header.

   ccjason@us.ibm.com (): It is felt by the group that it's important
   that the client not just own and hold the lock token, but that it
   also know where the lock is rooted before it does tasks related to
   that lock.  This still leaves the lock referesh issue unresolved.

   julian.reschke@greenbytes.de (2004-04-25): Need Lock-Token header to
   indicate the lock to be refreshed.

E.27  065_UNLOCK_WHAT_URL

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0086.html>


   Juergen.Pill@softwareag.com (): What do you return if the unlock
   request specifies a URL on which the lock does not reside?  What if
   it's on a URL that is locked by the lock, but it's not the resource
   where the lock is rooted?




Reschke                Expires November 19, 2004               [Page 45]


Internet-Draft           WebDAV URL constraints                 May 2004


   Resolution: Resolved that you can specify any URL locked by the lock
   you want to unlock.
   (http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html)
    We should resolve the issue of UNLOCK'ing other URLs in a few days.

E.28  066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL

   Type: change

   (): Right now the server uses the IF: header to verify that a client
   knows what locks it has that are affected by an operation before it
   allows the operation.  Must the client provide the root URL of a
   lock, any URL for a pertainent loc, or some specific URL  in the IF:
   header.

   ccjason@us.ibm.com (): It is felt by the group that it's important
   that the client not just own and hold the lock token, but that it
   also know where the lock is rooted before it does tasks related to
   that lock.  This is just a point of info.  The issue itself still
   needs to be brought up and answered.still

E.29  067_UNLOCK_NEEDS_IF_HEADER

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html>


   dbrotsky@Adobe.COM (): Shouldn't we be using an IF header to do an
   UNLOCK seeing as you need to prove you are holding a lock before you
   can remove it?  (This might be contingent on
   LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)

E.30  068_UNLOCK_WITHOUT_GOOD_TOKEN

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html>


   dbrotsky@Adobe.COM (): What should UNLOCK return if a bad token is
   provided or no token.  (This might be contingent on
   UNLOCK_NEEDS_IF_HEADER.)

E.31  070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER

   Type: change




Reschke                Expires November 19, 2004               [Page 46]


Internet-Draft           WebDAV URL constraints                 May 2004


   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0109.html>


   dbrotsky@Adobe.COM (): The LOCK renewal request should not us an IF
   header to specify what lock is being renewed.  This limits the use of
   the IF header.

   julian.reschke@greenbytes.de (2004-04-25): Need Lock-Token header to
   indicate the lock to be refreshed.

E.32  072_LOCK_URL_WITH_NO_PARENT_COLLECTION

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0134.html>


   dbrotsky@Adobe.COM (): If a LOCK request is submitted to a URL that
   doesn't have a parent collection, what should be the correct
   response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409
   response in this case.  Seems like LOCK should have this requirement
   as well.

   Resolution: Resolved that since LNRs no longer exist (see
   NULL_RESOURCE_CLARIFY) the server should return 409.  We should
   insure that the new text we add to replace LNRs does not create an
   ambiguity:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html


E.33  073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0128.html>


   hwarncke@Adobe.COM (): If the DAV:lockdiscovery property is requested
   from an unlocked resource, what is the correct response? Apache
   mod_dav responds with an empty mod_dav sends an empty lockdiscovery
   element (<D:lockdiscovery/>) while IIS sends an empty prop element
   (<D:prop/>), that is, it sends no lockdiscovery element at all.

   julian.reschke@greenbytes.de (2004-04-25): The difference shouldn't
   matter for clients, and they need to expect both.  In general,
   servers that DO support locks on that resource should return an empty
   element.




Reschke                Expires November 19, 2004               [Page 47]


Internet-Draft           WebDAV URL constraints                 May 2004


E.34  077_LOCK_NULL_STATUS_CREATION

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0267.html>


   lisa@xythos.com (): What status code should be returned when a lock
   null resource is created - 200 OK or 201 Created? A related issue is
   what status code should be returned by a PUT or MKCOL on a lock-null
   resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201
   seems like a slightly better choice).

   Resolution: Resolved via the proposal to remove LNR and replace them
   with ordinary resources and by the following wording:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html.


E.35  079_UNLOCK_BY_NON_LOCK_OWNER

   Type: change

   lisa@xythos.com (): At present, the specification is not explicit
   about who might be capable of grabbing a lock token via lock
   discovery and the submitting it in UNLOCK (and/or for a subsequent
   write operation).  It is OK for the resource owner to grab the lock
   token and do UNLOCK/write? Is it OK to have a "grab lock token"
   privilege that can be assigned to anyone?

   Resolution: Resolved in part by putting it under ACL control: http://
   lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html and
   the response that follows it.

E.36  080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC

   Type: change

   (): Proposal to remove lock null resources from the spec until we are
   motivated to have them or something equivalent.  In the meantime,
   keep the spec silent on the topic in order to avoid precluding LNR or
   the equivalent in a future version of WebDAV.

   Resolution: LNRs removed.  See discussions preceding conclusion:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html and

   http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html.





Reschke                Expires November 19, 2004               [Page 48]


Internet-Draft           WebDAV URL constraints                 May 2004


E.37  088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED

   Type: change

   (): The DAV:owner field of a lock is controlled by the locking client
   and should not be manipulated by the server.  This is the only place
   the client can store info.  The roundtrip details should match what
   we resolve for the PROP_ROUNDTRIP issue.  Examples should also be
   checked.

   Resolution: Resolved by repeated statement and no disagreement.

E.38  089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0047.html>


   gclemm@rational.com (): It would be good if a client could look at a
   locked resource that it was planning to unlock and also find out if
   it's depth locked and where the depth lock is rooted.

   Resolution: Proposed solution:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html
    approved.

E.39  099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html>


   ccjason@us.ibm.com (): What resource should be flagged in the
   multistatus response to locking issues in COPY/MOVE requests?

   Resolution: Resolved to flag the locking errors at the source
   resource that was affected by the problem.  The details of how to
   describe the error was deferred to a subsequent version of WebDAV.  -
   6/15/02 - 2518bis does not reflect this.

E.40  100_COPYMOVE_LOCKED_STATUS_DESCRIPTION

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html>




Reschke                Expires November 19, 2004               [Page 49]


Internet-Draft           WebDAV URL constraints                 May 2004


   (): The method of describing the details of (beyond what resolved by
   COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of
   various locking and ACL  COPY/MOVE problems is deferred.  Two
   proposals were outlined in the discussion, but interest was not great
   and we clearly don't have interoperability to take these proposals
   forward.

E.41  101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0215.html>


   julian.reschke@greenbytes.de (): There is some confusion on how a
   PROPFIND response should express the fact that a resource has
   multiple shared locks on it.  It was suggested that the spec become
   clearer.

   Resolution: Resolved trivially that it's probably worthwhile to
   demonstrate a correc response for this situation in one of the
   examples.

E.42  109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html>


   julian.reschke@greenbytes.de (): If one finds a locked resource, it
   might be one of several resource locked by a depth lock.  How does
   one determine the root of the lock?

   Resolution: Resolved to support a dav:lockroot element in the lock
   discovery property:
   http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html


E.43  111_MULTIPLE_TOKENS_PER_LOCK

   Type: change

   <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0050.html>


   julian.reschke@greenbytes.de (): 12.1.2 states that a dav:locktoken
   tag can have multiple <dav:href> tags in it.  Is this right?  And is



Reschke                Expires November 19, 2004               [Page 50]


Internet-Draft           WebDAV URL constraints                 May 2004


   it trying to suggest that a single (shared) lock might have multiple
   locktokens?

   Resolution: It is resolved that section 12.1.2 was incorrect and that
   only a single lock token URI should be allowed there.  Also it is
   resolved that a lock only has a single lock token.













































Reschke                Expires November 19, 2004               [Page 51]


Internet-Draft           WebDAV URL constraints                 May 2004


Index

A
   activelock
      XML element  26

D
   DAV header
      compliance class '2'  32
   DAV:lockdiscovery property  29
   DAV:supportedlock property  31
   depth
      XML element  26

E
   exclusive
      XML element  28

H
   Headers
      Lock-Token  24
      Timeout  24

L
   LOCK method  16
   Lock-Token header  24
   lockentry
      XML element  27
   lockinfo
      XML element  27
   lockscope
      XML element  27
   locktoken
      XML element  26
   locktype
      XML element  28

M
   Methods
      LOCK  16
      UNLOCK  23

O
   owner
      XML element  29

P
   Properties



Reschke                Expires November 19, 2004               [Page 52]


Internet-Draft           WebDAV URL constraints                 May 2004


      DAV:lockdiscovery  29
      DAV:supportedlock  31

S
   shared
      XML element  28

T
   Timeout header  24
   timeout
      XML element  26

U
   UNLOCK method  23

W
   write
      XML element  28

































Reschke                Expires November 19, 2004               [Page 53]


Internet-Draft           WebDAV URL constraints                 May 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Reschke                Expires November 19, 2004               [Page 54]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/