LOCKing an unmapped URL

If a write lock is successfully created on an unmapped URL, should an 
ETag (with associated Location header) be returned for the empty 
resource in the 201 response?

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

If header field and conditional precedence

Happy Holidays to All!

I'm trying to figure out where the If header field fits in the 
precedence order outlined in:
http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-5

I assume that the If header field should be evaluated in a step 0, but 
my question is what should happen when the If header is present and 
evaluates to true?  Should processing continue to step 3 or step 1?  In 
other words, does If completely supersede If-Match, where a client 
wishing to submit both a state token and an ETag MUST only use If, or is 
a client allowed to submit a state token with If AND submit an ETag with 
If-Match?

In text, the two options might look something like this:

    0.  When If is present, evaluate it:

        *  if true, continue to step 3

        *  if false, respond 412 (Precondition Failed)

    1.  When If is not present and If-Match is present,
        evaluate it:

    ...

OR

    0.  When If is present, evaluate it:

Ambiguous example for COPY in RFC 4918

Dear all,

this is my first post to this list so, if this is not the correct
mailing list to discuss the topic, please, just tell me and I'll forward
it to a more appropriate forum.

We're working at a C# implementation of RFC 4918 and while most parts of
it are quite clear we found one example that, if taken with the text
preceding it, is quite puzzling. About a COPY operation with infinite
Depth and Overwrite:T the RFC says:

    9.8.4 COPY and Overwriting Destination Resources

    [...]
    When a collection is overwritten, the membership of the destination
    collection after the successful COPY request must be the same
    membership as the source collection immediately before the COPY.
    Thus, merging the membership of the source and destination
    collections together in the destination is not a compliant behavior.
    [...]

But the example "9.8.8 Example - COPY of a Collection" says that
"[...]Because there was an error copying R2, none of R2's members were
copied.[...]". Our understanding is that in the destination tree
/othercontainer/R2/ is still the member from the original
/othercontainer/ collection while R2 siblings in the source collection
/container/ have been copied correctly.

E.g., if we're asked to COPY

Microsoft Mini-Redirector Bug with respect to handling DAV:href

Hi there,

reporting here so it get's archived:

Version: Microsoft-WebDAV-MiniRedir/6.1.7601

Problem: client is doing a PROPFIND request without payload, thus 
defaulting to DAV:allprop.

Server returns a custom property than *contains* a DAV:href child 
element, like that:

<D:response>
   <D:href>/foo/bar.txt</D:href>
   <D:propstat>
     <D:prop>
       <D:displayname>bar.txt</D:displayname>
       <D:creationdate>2012-06-01T12:52:57Z</D:creationdate>
       <D:resourcetype/>
       <D:lockdiscovery/>
       <D:getcontenttype>text/plain; charset=UTF-8</D:getcontenttype>
       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>
       <D:getetag>"7248-1338555179558"</D:getetag>
       <D:getlastmodified>Fri, 01 Jun 2012 12:52:59 GMT</D:getlastmodified>
       <D:supportedlock>
         <D:lockentry>
           <D:lockscope><D:exclusive/></D:lockscope>
           <D:locktype><D:write/></D:locktype>

Re: webDAV apple open source

webDAV apple open source

New Version Notification for draft-daboo-webdav-sync-07.txt (fwd)

Hi folks,
FYI We have posted a new -07 version of the sync report draft that 
addresses the last call, IESG review etc comments. Please take a look at 
the changes and make sure these are OK.

------------ Forwarded Message -----------
Date: January 19, 2012 8:18:19 AM -0800
From: internet-drafts <at> ietf.org
To: cyrus <at> daboo.name
cc: cyrus <at> daboo.name, arnaud.quillaud <at> oracle.com
Subject: New Version Notification for draft-daboo-webdav-sync-07.txt

A new version of I-D, draft-daboo-webdav-sync-07.txt has been successfully
submitted by Cyrus Daboo and posted to the IETF repository.

Filename:	 draft-daboo-webdav-sync
Revision:	 07
Title:		 Collection Synchronization for WebDAV
Creation date:	 2012-01-19
WG ID:		 Individual Submission
Number of pages: 32

Abstract:
   This specification defines an extension to Web Distributed Authoring
   and Versioning (WebDAV) that allows efficient synchronization of the
   contents of a WebDAV collection.

Editorial Note (To be removed by RFC Editor before publication)

   Please send comments to the Distributed Authoring and Versioning
   (WebDAV) working group at &lt;mailto:w3c-dist-auth <at> w3.org&gt;, which may
be    joined by sending a message with subject &quot;subscribe&quot; to
&lt;mailto:w3c-dist-auth-request <at> w3.org&gt;.  Discussions of the WEBDAV
working group are archived at
   &lt;http://lists.w3.org/Archives/Public/w3c-dist-auth/&gt;.

The IETF Secretariat

---------- End Forwarded Message ----------

--

-- 
Cyrus Daboo

About COPY Overwrite:T Depth:0

RFC 4918 section 9.8.4 defines overwrite with Depth:infinity (When a
collection is overwritten, the membership of the destination collection after
the successful COPY request MUST be the  same membership as the source
collection immediately before the COPY), but the exact meaning of an overwrite
copy with Depth:0 is not defined.

I would like to know what is the expected behavior of a COPY with Overwrite:T
and Depth:0? i.e. whether /dst/bar exists or not, after the following methods
are executed in order:

MKCOL /src
MKCOL /src/foo
MKCOL /dst
MKCOL /dst/bar
COPY /src to /dst with Depth:0 and Overwrite:F

>From RFC 4918, section 9.8.3: A COPY of "Depth: 0" only instructs that the
collection and its properties, but not resources identified by its internal
member URLs, are to be copied.

The Litmus test suite (v0.13) does not check this behavior. There is a fork of
Litmus that expects the resource to exists after the Depth:0 copy (test
depth_zero_copy in http://github.com/tolsen/litmus/), but the test suite of
PerlDAV v0.45 takes the opposite approach (test 6_dav_copy_move.t). What is
the correct interpretation?

Best Regards

Javier

WebDAV sync report client support

Does anybody know which clients support sync-collection?  I know that 
Lightning does, and the version of iCal that I have (4.0.4) doesn't 
appear to.

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

WebDAV sync report w/invalid sync token

Folks,

What is the proper response code for a sync-collection report if the 
sync-token is either invalid or out of date?  The I-D doesn't seem to 
specify, so looking at RFC 3253 section 1.6 it appears that 403 and 409 
are the two options for a precondition failure, with 409 presumably 
being the correct choice in this case.  Am I missing something?

Thanks,
Ken

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

If Header interaction with If-Match, etc

What, if any, interaction does the If header have with the other 
conditional headers?  HTTPbis part 4 
(http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional) 
specifically states which headers can't/shouldn't be used together.

I assume that If-Match and If-None-Match shouldn't be used with If, but 
what about If-[un]modified-Since and If?  Should an implementation just 
look for and use If when specified and ignore all other conditionals?

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University